Oracle Cluster Registry (OCR) in Oracle 11gR2-RAC- Airy’s Notes

Oracle Cluster Registry (OCR) in Oracle 11gR2-RAC- Airy’s Notes:

Oracle cluster Registry (OCR) is the central repository for CRS, which maintains the metadata, configuration and state information of all cluster resources defined in clusterware and cluster database.
OCR is the repository of configuration information for the cluster that manages information like, the cluster node list and cluster database instance-to-node mapping information and CRS application resource profile.
It is a cluster registry used to maintain application resources and their availability within the RAC environment. It also stores configuration information for CRS daemons and clusterware managed applications.
This configuration information is used by many of the processes that make up the CRS, as well as other cluster-aware applications which use this repository to share information among them.
OCR also maintains dependency and status information for application resources defined within CRS, specifically databases, instances, services and node applications.
The OCR uses a file-based repository to store configuration information in a series of key-value pairs, using a directory tree-like structure.
The OCR must reside on a shared disk(s) that is accessible by all of the nodes in the cluster.
Starting with Oracle Clusterware 10g R2, we are allowed to multiplex the OCR and Oracle recommends that you use this feature to ensure cluster high availability.
Oracle Clusterware allows for a maximum of 5 OCR locations; one is the primary and the other will be OCR mirror.
If you define a single OCR, then you should use external mirroring to provide redundancy.
OCR can be replaced online .You can replace a failed OCR online, and you can update the OCR through supported APIs such as Enterprise Manager, the Server Control Utility (SRVCTL), or the Database Configuration Assistant (DBCA).
It is highly recommended to take a backup of OCR file before making any changes.
To view the contents of the OCR in a human-readable format, we have to run the ocrdump This will dump the contents of the OCR into an ASCII text file in the current directory named OCRDUMPFILE.
The name of the configuration file is ocr.loc and the configuration file variable is ocrconfig.loc.

What Information Exist in OCR?

There are some of the main components, which are included in the OCR :

Node membership information.
The cluster node list and instance-to-node mapping information.
Starting with Oracle 11g, OCR also contain the information about the location of voting disk.
Server, Network, RAC Database, Instance, Node and Listener UP/Down and other mapping information
ASM Instance and Disk groups Information.
Cluster and Application resource profiles Information (such as RAC database, listener, Instance, VIP, Scan IP, Serverpool and Services etc ).
Database Service characteristics like preferred and available nodes.
TAF Policy, Load Balancing information.
Details of the network interfaces held by the cluster network.
Information about processes that Oracle Clusterware controls.
Information about any third-party applications controlled by CRS.
Information about OCR Backups.
Software active version.
OCR also maintains information regarding Dependencies, Management policy (automatic/manual), Callout Scripts and Retries.

Name of Process and Utilities, Who Updates OCR?

CSSd at the time of cluster setup to update the status of the servers.
CSS during node addition and Node Deletion.
CRSd about status of nodes during failures and reconfiguration.
Utilities OUI, SRVCTL, CRSCTL, OEM, NETCA, DBCA, DBUA, ASMCA.

How OCR Updated?

Oracle uses a distributed shared cache architecture during cluster management to optimize queries against the cluster repository.
For better performance each node in the cluster maintains an in-memory copy of OCR, along with an OCR process that accesses its OCR cache. Every time each node is required to update the OCR as required.
Oracle Clusterware uses a background process to access the OCR cache.
The CRSd process is responsible for reading and writing to the OCR files as well as refreshing the local OCR cache and the caches on the other nodes in the cluster.
Only one CRSd process (designated as the master) in the cluster performs any disk read/write activity.
Once any new information is read by the master CRSd process, it performs a refresh of the local OCR cache and the OCR cache on other nodes in the cluster.
Since the OCR cache is distributed across all nodes in the cluster, OCR client application needs to update the OCR, they communicate through their local OCR process via the local CRSd process, to the OCR process that is performing input/output (I/O) for writing to the physical OCR binary file on disk.
The OCR client applications are Oracle Universal Installer (OUI), SRVCTL, Enterprise Manger (EM), Database Configuration Assistant (DBCA), Database Upgrade Assistant(DBUA), NetCA and Virtual Internet Protocol Configuration assistant (VIPCA).

Where OCR be stored?

We can find the location of the OCR in a file on each individual node of the cluster. This location varies by platform but on Linux the location of the OCR is stored in the file /etc/oracle/ocr.loc
The OCR must reside on a shared disk(s) that is accessible by all of the nodes in the cluster.
Prior to oracle 11g R2, we had to create Oracle Cluster Repository (OCR) on raw devices. Since in Oracle 11g R2, the raw devices have been deprecated, so now we can choose in between a cluster file system or an ASM disk group.
The OCR and voting disk must be on a shared device so putting it on local file system is not going to work.
Now if we have a choice to choose between a cluster file system or an ASM disk group for keeping OCR: Clustered file systems may not be an option due to high cost. Other options may include network file systems but NFS are usually slow and unreliable. So, ASM remains the best choice.
The OCR and voting disks could be on any available ASM disk group so there is no need to create exclusively disk groups for them.
The OCR is striped and mirrored (if we have a redundancy other than external), similar to ordinary Database Files. So we can now have leverage the mirroring capabilities of ASM to mirror the OCR also, without having to use multiple RAW devices for that purpose only.
The OCR is replicated across all the underlying disks of the disk group, so failure of a disk does not bring the failure of the disk group.
Considering the criticality of the OCR contents to the cluster functionality, Oracle strongly recommends us to multiplex the OCR file. In Oracle 11g R2, we can have up to five OCR copies.
Due to its shared location, from a single location, all the components running on all nodes and instances of Oracle can be administrated, irrespective of the node on which the registry was created.

What is the need of OCR?

Oracle Clusterware reads the ocr.loc file for the location of the registry and to determine which applications resources need to be started and the nodes on which to start them.
It is used to bootstrap the CSS for port info, nodes in the cluster and similar info.
The CRSd, or Oracle Clusterware daemon’s function is to define and manage resources managed by Clusterware. Resources have profiles that define metadata about them. This metadata is stored in the OCR. The CRS reads the OCR and manages and Implement the following:

Manages the application resources: starts, stops, monitors and manages their failover
Maintains and tracks information pertaining to the definition, availability, and current state of the services.
Implements the workload balancing and continuous availability features of services.
Generates events during cluster state changes.
Maintains configuration profiles of resources in the OCR.
Records the currently known state of the cluster on a regular basis and provides the same when queried (using srvctl, crsctl etc.)

How is the information stored in OCR?

The OCR uses a file-based repository to store configuration information in a series of key-value pairs, using a directory tree-like structure.
It contains information pertaining to all tiers of the clustered database.
Various parameters are stored as name-value pairs used and maintained at different levels of the architecture.
Each tier is managed and administrated by daemon processes with appropriate privileges to manage them. For example:
All SYSTEM level resource or application definitions would require root or superuser privileges to start, stop, and execute resources defined at this level.
Those defined at the DATABASE level will require dba privileges to execute.

Backup of OCR:

Starting from Oracle Clusterware 11g Release 2, Oracle backs up the OCR automatically in every four hours on a schedule that is dependent on when the node started (not clock time).
The default location where OCR backups are made is GRID_HOME/cdata/<cluster name> directory on the node performing the backups, where the <cluster_name> is the name of your cluster and GRID_HOME is the home directory of your Oracle GRID installation.
One node known as the master node is dedicated to these backups, but in case master node is down, some other node may become the master. Hence, backups could be spread across nodes due to outages.
These backups are named as follows:

4-hour backups (3 max) : backup00.ocr, backup01.ocr, and backup02.ocr.
Daily backups (2 max) : day.ocr and day_.ocr
Weekly backups (2 max) : week.ocr and week_.ocr

Oracle Clusterware maintains the last three backups, overwriting the older backups. Thus, you will have three 4-4hour backups, (i) the current one, (ii) one four hours old and (iii) one eight hours old. Therefore no additional clean-up tasks are required of the DBA.
Oracle Clusterware will also take a backup at the end of the day. The last two of these backups are retained. Finally, at the end of each week Oracle will perform another backup, and again the last two of these backups are retained. You should make sure that your routine file system backups backup the OCR location.
There is no way to customize the backup frequencies or the number of files that Oracle Grid Infrastructure retains while automatically backing OCR.
Point to be noted RMAN does not backup the OCR.
You can use the ocrconfig command to view the current OCR backups:

[root@paw-racnode1 bin]# ocrconfig -showbackup
racnode1  2016/07/21 17:16:03 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup00.ocr
racnode1  2016/07/21 17:16:03 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/day.ocr
racnode1  2016/07/21 17:16:03 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/week.ocr
racnode1  2016/07/21 16:14:00 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_161400.ocr
racnode1  2016/07/21 15:59:15 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155915.ocr
racnode1  2016/07/21 15:58:50 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155850.ocr
racnode1  2016/07/21 15:58:39 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155839.ocr

[root@paw-racnode1 app]# ocrconfig -showbackup auto
racnode1     2016/07/21 17:16:03     /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup00.ocr
racnode1     2016/07/21 17:16:03     /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/day.ocr
racnode1     2016/07/21 17:16:03     /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/week.ocr

[root@paw-racnode1 ~]# ocrconfig -showbackup manual
racnode1 2016/07/21 16:14:00  /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_161400.ocr
racnode1 2016/07/21 15:59:15  /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155915.ocr
racnode1 2016/07/21 15:58:50  /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155850.ocr
racnode1 2016/07/21 15:58:39  /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155839.ocr

It is recommended that OCR backups may be placed on a shared location which can be configured using ocrconfig -backuploc <new location>

[root@paw-racnode1 named]# ocrconfig -backuploc /u01/app/ocr-backup

If your cluster is shutdown, then the automatic backups will not occur (nor will the purging). The timer restarts from the beginning when the cluster is restarted. When you start the cluster backup, a backup will not be taken immediately. Hence, if you are stopping and starting your cluster that you could impact the OCR backups and the backup period could go long beyond 4 hours.
If you feel that you need to backup the OCR immediately (for example, you have made a number of cluster related changes) then you can use the ocrconfig command to perform a manual backup:

[root@paw-racnode1 named]# ocrconfig -manualbackup
racnode1  2016/07/21 17:27:02 /u01/app/ocr-backup/backup_20160721_172702.ocr
racnode1  2016/07/21 16:14:00 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_161400.ocr
racnode1  2016/07/21 15:59:15 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155915.ocr
racnode1  2016/07/21 15:58:50 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155850.ocr
racnode1  2016/07/21 15:58:39 /u01/app/grid/product/11.2.0/grid/cdata/rac01-scan/backup_20160721_155839.ocr

Thank you for reading… This is Airy…Enjoy Learning 🙂

Leave a Reply Cancel reply