Database Reference
In-Depth Information
Figure 8-14.
OEM Cloud Control 12c manage recovery_table_settings screen
OCR recovery
OCR is beyond a doubt one of the most critical components of Oracle Clusterware, and its uninterrupted availability is
necessary to the cluster resources function. Keeping in mind this criticality, Oracle offers several options to protect the
OCR file from physical or logical corruptions, unintentional human errors, and single points of failure. The OCR file
is automatically backed up every 4 hours by Oracle Clusterware and can also be backed up manually on demand.
To avoid a single point of failure, consider multiplexing the file up to a maximum of five copies.
You really need to understand and be aware of all possible methods to protect and recover OCR from different
failures. In this section, we shall highlight various OCR recovery scenarios.
Let's verify the existing OCR details. For that, you need to log in as root and execute the following to view OCR details:
# ocrcheck
Logical corruption verification will be skipped if the preceding command is executed as a nonprivileged user.
To view the OCR file name and path, use the following command:
# ocrcheck -config
Automatic/manual backup details are listed using the following command:
# ocrconfig -showbackup
The following are a few OCR restore procedures that can be used in the event of all OCR files being either
corrupted or lost.
Scenario 1:
The following demonstrates a procedure to restore OCR from autogenerated OCR backups:
As the root user, get the auto backup availability details using the following command:
# ocrconfig -showbackup
Stop Clusterware on all nodes using the following command as root user:
# crsctl stop crs [-f]
-- Use the -f option to stop the CRS forcefully in the event that the crs stack couldn't be
stopped normally due to various errors.
