Storage Foundation for Oracle® RAC 8.0 Administrator's Guide - Solaris
- Section I. SF Oracle RAC concepts and administration
- Overview of Storage Foundation for Oracle RAC
- Component products and processes of SF Oracle RAC
- About Virtual Business Services
- Administering SF Oracle RAC and its components
- Administering SF Oracle RAC
- Starting or stopping SF Oracle RAC on each node
- Administering VCS
- Administering I/O fencing
- About the vxfentsthdw utility
- About the vxfenadm utility
- About the vxfenswap utility
- Administering the CP server
- Administering CFS
- Administering CVM
- Changing the CVM master manually
- Administering Flexible Storage Sharing
- Backing up and restoring disk group configuration data
- Administering SF Oracle RAC global clusters
- Administering SF Oracle RAC
- Overview of Storage Foundation for Oracle RAC
- Section II. Performance and troubleshooting
- Troubleshooting SF Oracle RAC
- About troubleshooting SF Oracle RAC
- Troubleshooting I/O fencing
- Troubleshooting CP server
- Troubleshooting server-based fencing on the SF Oracle RAC cluster nodes
- Issues during online migration of coordination points
- Troubleshooting Cluster Volume Manager in SF Oracle RAC clusters
- Troubleshooting CFS
- Troubleshooting VCSIPC
- Troubleshooting Oracle
- Troubleshooting ODM in SF Oracle RAC clusters
- Prevention and recovery strategies
- Tunable parameters
- Troubleshooting SF Oracle RAC
- Section III. Reference
Limitations of Flexible Storage Sharing
Note the following limitations for using Flexible Storage Sharing (FSS):
FSS is only supported on clusters of up to 8 nodes.
Disk initialization operations should be performed only on nodes with local connectivity to the disk.
FSS does not support the use of boot disks, opaque disks, and non-VxVM disks for network sharing.
Hot-relocation is disabled on FSS disk groups.
FSS does not support non-SCSI3 disks connected to multiple hosts.
Dynamic LUN Expansion (DLE) is not supported.
FSS only supports instant data change object (DCO), created using the vxsnap operation or by specifying "logtype=dco dcoversion=20" attributes during volume creation.
By default creating a mirror between SSD and HDD is not supported through vxassist, as the underlying mediatypes are different. To workaround this issue, you can create a volume with one mediatype, for instance the HDD, which is the default mediatype, and then later add a mirror on the SSD.
For example:
# vxassist -g diskgroup make volume size init=none
# vxassist -g diskgroup mirror volume mediatype:ssd
# vxvol -g diskgroup init active volume