Storage Foundation for Oracle® RAC 7.3.1 Administrator's Guide - Linux
- Section I. SF Oracle RAC concepts and administration
- Overview of Storage Foundation for Oracle RAC
- About 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
- Testing the coordinator disk group using the -c option of vxfentsthdw
- About the vxfenadm utility
- About the vxfenclearpre 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
- Fencing startup reports preexisting split-brain
- 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 interconnects
- Troubleshooting Oracle
- Troubleshooting ODM in SF Oracle RAC clusters
- Prevention and recovery strategies
- Tunable parameters
- Troubleshooting SF Oracle RAC
- Section III. Reference
About the I/O fencing registration key format
The keys that the vxfen driver registers on the data disks and the coordinator disks consist of eight bytes. The key format is different for the coordinator disks and data disks.
The key format of the coordinator disks is as follows:
Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
Value | V | F | cID 0x | cID 0x | cID 0x | cID 0x | nID 0x | nID 0x |
where:
VF is the unique identifier that carves out a namespace for the keys (consumes two bytes)
cID 0x is the LLT cluster ID in hexadecimal (consumes four bytes)
nID 0x is the LLT node ID in hexadecimal (consumes two bytes)
The vxfen driver uses this key format in both sybase mode of I/O fencing.
The key format of the data disks that are configured as failover disk groups under VCS is as follows:
Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
Value | A+nID | V | C | S |
|
where nID is the LLT node ID
For example: If the node ID is 1, then the first byte has the value as B ('A' + 1 = B).
The key format of the data disks configured as parallel disk groups under Cluster Volume Manager (CVM) is as follows:
Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
Value | A+nID | P | G | R | DGcount | DGcount | DGcount | DGcount |
where DGcount is the count of disk groups in the configuration (consumes four bytes).
By default, CVM uses a unique fencing key for each disk group. However, some arrays have a restriction on the total number of unique keys that can be registered. In such cases, you can use the same_key_for_alldgs tunable parameter to change the default behavior. The default value of the parameter is off. If your configuration hits the storage array limit on total number of unique keys, you can change the value to on using the vxdefault command as follows:
# vxdefault set same_key_for_alldgs on # vxdefault list KEYWORD CURRENT-VALUE DEFAULT-VALUE ... same_key_for_alldgs on off ...
If the tunable is changed to on, all subsequent keys that the CVM generates on disk group imports or creates have '0000' as their last four bytes (DGcount is 0). You must deport and re-import all the disk groups that are already imported for the changed value of the same_key_for_alldgs tunable to take effect.