Pages

Saturday, September 10, 2011

Oracle Cluster Registry and Voting Disks

OCR and voting disks are shared files on a cluster filesystem. OCR contains the configuration information about the cluster resources. Voting Disks are used to monitor cluster node status. 

To display OCR locations
$ ocrcheck 
To replace the current OCR location
# ocrconfig -replace <current_location> -replacement <new_location>
To add new OCR location. Create empty file first with touch command.
# ocrconfig -add <new_location>
To delete OCR location. If only one OCR location configured and online, it cannot be deleted.
# ocrconfig -delete <current_location>

To retrieve the list of voting files.
$ crsctl query css votedisk 
To add a voting disk
$ crsctl add css votedisk <new_location>
To delete a voting disk. If only one vote disk configured and online, it cannot be deleted.
$ crsctl delete votedisk <Universal_File_Id>
If all voting disks are lost, start css in exclusive mode and replace voting disk.
# crsctl start crs -excl
# crsctl replace votedisk <location>

In Oracle Clusterware 11gR2, the voting disk data is automatically backed up in OCR as part of any configuration change and is automatically restored to any voting disk added. The CRSD process automatically creates the OCR backup every four hours in $GRID_HOME/cdata/<cluster_name>.

To list the backup files
$ ocrconfig -showbackup
To restore OCR backup. Stop clusterware on all nodes. Create empty OCR file with same name if the original file doesn't exist.
# ocrconfig -restore <backup_location>

To verify Clusterware version
$ crsctl query crs activeversion
To verify clusterware running on the node
$ crsctl check crs




Saturday, August 27, 2011

11g Snapshot Standby Database


A snapshot standby database is a temporarily opened real time production database for testing or reporting. It is a fully updateable standby database after conversion from physical standby. It receives redo data from primary, but does not apply. The redo data is applied after conversion back to physical standby to sync up with primary. It implicitly creates a guaranteed restore point during the conversion to snapshot standby and removes this guaranteed restore point during the conversion back to physical standby.

CONVERT TO SNAPSHOT STANDBY
1. Stop Redo Apply
SQL> recover managed standby database cancel;
2. Ensure the database is mounted, but not open.
3. Convert to Snapshot Standby. This creates the GRP and leaves the database in nomount mode.
SQL> alter database convert to snapshot standby.
4. Restart the database.
SQL> shutdown immediate
SQL> startup

CONVERT BACK TO PHYSICAL STANDBY
1.  Ensure the database is mounted, but not open.
SQL> shutdown immediate
SQL> startup mount
2. Convert to Physical Standby. This discards the changes made to the database, flashback the database to GRP, deletes the flashback logs in recovery area, drops GRP and leaves the database in nomount mode.
SQL> alter database convert to physical standby;
3. Restart the database in mount mode.
SQL> shutdown immediate
SQL> startup mount
4. Start Redo Apply.
SQL> recover managed standby database disconnect from session;