SAP cannot guarantee data integrity unless you enable I/O fencing. If you do not use I/O fencing, data loss or other data corruption may occur in rare instances. Only test and development environments that can accept this risk should be deployed without I/O fencing.
The shared-disk cluster can detect the presence of a noncooperating instance and remove it from the cluster. In rare situations, however, the cluster cannot stop the noncooperating instance from writing to the shared disk, even though the instance is no longer part of the cluster. For example, if an instance has been removed from the cluster, but has not released resources and shut down, it may still be capable of writing to the shared disk. Use I/O fencing to prevent the noncooperating instance from making data writes.
In the Cluster Edition, SAP supports the SCSI-3 Persistent Group Reservation (PGR) feature of SCSI-3 devices to provide I/O fencing. PGR is the SCSI-3 standard for managing disk access in an environment where a single disk is shared by multiple hosts for read and write access.
The I/O fencing provided by the SCSI-3 PGR feature operates only on devices, not on partitions. For example, /dev/sda1 and /dev/sda2 are partitions of the device /dev/sda. A fencing operation targeted to a raw device bound to /dev/sda1 affects all partitions of /dev/sda, so any file systems or other applications (including another Adaptive Server ) using partitions on that device are also affected. For this reason, the device must be used exclusively by the cluster instance.