Oracle Cluster Registry (OCR) is the critical component in Oracle RAC.
Ø OCR records cluster configuration information. If it fails, the entire clustered environment of Oracle RAC is affected and a possible outage is a result.
Ø It is the central repository for CRS, which stores its metadata, configuration and state information for all clusters defined in the clusterware.
Ø It is the cluster registry maintains application resources and their availability within the RAC environment.
Ø It also stores information of CRS daemons and cluster managed applications.
What is stored in OCR
We have the introduction of OCR, now we will see what are stored in OCR file.
Ø Node membership information, i.e, which nodes are part of the cluster.
Ø Software version
Ø Location of 11g voting disk
Ø Server pools
Ø Status of cluster resources such as RAC databases, listeners, instances and services.
· Server up/down
· Network up/down
· Database up/down
· Instance up/down
· Listener up/down
Ø Configuration of the cluster resources like RAC databases, listeners, instances and services.
· Dependencies,
· Management Policies (automatic/manual)
· Callout scripts
· Retries
Ø Cluster database instance to node mapping
Ø ASM instance, disk groups, etc
Ø CRS application resource profiles such as VIP address, service, etc.
Ø Database services characteristics eg., preferred/available nodes, TAF policy, load balancing goal, etc
Ø Information about clusterware processes
Ø Information about interaction and management of 3rd party applications controlled by CRS
Ø Communication settings where the clusterware daemons or background process listen.
Ø Information about OCR backups.
Let us see the contents in OCR file.
[root@rac1 ~]# ocrconfig -manualbackup
rac2 2014/01/18 01:03:40 /u01/app/grid/product/11.2.0.3/grid_1/cdata/cluster01/backup_20140118_010340.ocr
[root@rac2 ~]# strings /u01/app/grid/product/11.2.0.3/grid_1/cdata/cluster01/backup_20140118_010340.ocr| grep -v type |grep ora!
ora!LISTENER!lsnr
ora!host02!vip
rora!rac1!vip
;ora!oc4j
6ora!LISTENER_SCAN3!lsnr
ora!LISTENER_SCAN2!lsnr
ora!LISTENER_SCAN1!lsnr
ora!scan3!vip
ora!scan2!vip
ora!scan1!vip
ora!gns
ora!gns!vip
ora!registry!acfs
ora!DATA!dg
dora!asm
_ora!eons
ora!ons
ora!gsd
ora!net1!network
Who is updating OCR
It is updated and maintained by many client applications.
Ø CSSd during startup of cluster – to update the status of the servers.
Ø CSSd during node addition/deletion – to add/delete nodes
Ø CRSd about status of nodes during failure/reconfiguration
Ø OUI - Oracle universal Installer during installation/upgradation/deletion/addition
Ø Srvctl – ( to manage clusters and rac databases)
Ø Cluster control utility – crsctl (to manage cluster /local resources)
Ø Enterprise Manager (EM)
Ø Database Configuration Assistant (DBCA)
Ø Database upgrade Assistant (DBUA)
Ø Network Configuration Assistant (NETCA)
Ø ASM configuration assistant (ASMCA)
How the update is performed in OCR.
1. Each node in the cluster will have the copy of OCR in memory for better performance and each node is responsible for updating the OCR if required.
2. CRSd process is responsible for reading and writing to the OCR files as well as refreshing the local OCR cache and caches on the other nodes in the cluster.
3. Oracle uses distributed shared cache architecture during cluster management to optimize queries against the cluster repository and at the same time, each node maintains a copy of the OCR in memory.
4. Oracle clusterware uses the background process to access the OCR cache.
5. Only one CRSd process (designated as master) in the cluster performs any read/write activity. If any new information read by the CRSd master process, then it refresh the local OCR cache and the OCR cache on the others nodes of the cluster.
6. As the OCR cache is distributed across all nodes in the cluster, OCR clients like srvctl,crsctl,etc will communicate directly with the OCR process on the node to get required information.
7. Clients communicate via the local CRSd process for any updates on the physical OCR binary file.
During the above process, OCRCONFIG command cannot modify the OCR configuration information for nodes that are shut down or for nodes on which oracle clusterware is not running. So, we need to avoid shutting down the nodes while modifying the OCR using the ocrconfig command. We need to perform a repair on the stopped node before it can bring online to join the cluster.
OCRCONFIG –repair command change the OCR configuration only on the node from which we are executing this command.
Example : if the OCR mirror was relocated to a disk in rac2 which is down from /dev/raw/raw2 in rac1, then use ocrconfig –repair ocrmirror /dev/raw/raw2 command on rac2 while the CRS stack is down on that node to repair its OCR configuration.
Purpose of OCR
Ø Oracle clusterware reads the ocr.loc for the location of the registry and to know which application resources needs to be started and the nodes on which to start them.
Ø Used for bootstrap the CSS with port info, nodes in the cluster and other similar informations.
Ø CRSd and other clusterware daemons function is to define and manage resources managed by clusterware. Resources have profiles that define metadata about them. This metadata is stored in OCR. The CRS reads the OCR and manages the application resources, starts, stops, and monitor and manages their failover.
Ø Maintains and tracks the information pertaining to the definition, availability and current state of the services.
Ø Implements the workload balancing and continuous availability features of services.
Ø Generates event during state changes.
Ø Maintain configuration profiles of resources in OCR.
Ø Records the currently known state of the cluster at regular intervals and provides the same when reqeuested by client application like srvctl,crsctl,etc.
How the information is stored in OCR
Ø 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 in 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 administered by daemon process at different levels with appropriate privileges.
Eg. All system level resources or application definitions would require root, or superuser to start or stop.
Those defined at the database level will require dba privileges.
Where and how should OCR be stored ?
Ø Location of the OCR is found in a file on each individual node of the cluster. It varies depending on the flavors of unix. In Linux , /etc/oracle/ocr.loc
Ø OCR must reside on a shared disk that is accessible by all nodes in the cluster. It cannot be stored on raw filesystems as in 10g as it is deprecated. So, we are left with cluster filesystem (CFS) and ASM. But CFS will cost high and may not be an option. So, better to go for ASM. OCR and voting disks can be exclusively available on any disksgroups .
Ø OCR is striped and mirrored (if we have redundancy in the external) similar to other database files.
Ø OCR is replicated across all the underlying disks of the diskgroup, so failure of the disk does not bring the failure of the diskgroup.
Ø In 11gR2, we can have upto 5 OCR copies.
Ø Since it is in shared location, it can be administered from any nodes irrespective of the node on which the registry was created.
Ø A small disk of around 300MB-500MB is a good choice.
Utilities to manage OCR
Add an OCR file
—————-
Add an OCR file to an ASM diskgroup called +DATA
ocrconfig –add +DATA
Moving the OCR
————–
Move an existing OCR file to another location :
ocrconfig –replace /u01/app/oracle/ocr –replacement +DATA
Removing an OCR location
————————
- requires that at least one other OCR file must remain online.
ocrconfig –delete +DATA
OCR Backups
ü Oracle Clusterware 11g Release 2 backs up the OCR automatically every four hours on a schedule that is dependent on when the node started (not clock time).
ü OCR backups are made available in $GRID_HOME/cdata/<cluster name> directory on the node performing the backups.
ü 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
ü It is recommended that OCR backups may be placed on a shared location which can be configured using ocrconfig -backuploc <new location> command.
ü Oracle Clusterware maintains the last three backups, overwriting the older backups. Thus, you will have 3 4-hour backups, the current one, one four hours old and 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.
ü Note that RMAN does not backup the OCR.
You can use the ocrconfig command to view the current OCR backups:
#ocrconfig –showbackup auto
No comments:
Post a Comment