Manage OCR(Oracle Cluster Repository)

1. Backup

You must be logged in as the root user, because root owns the OCR files.

- To see the recent copy of OCR file

# ocrconfig -showbackup

export OCR file

# ocrconfig -export /oracle/backup/cluster/backup01.ocr -s online

2. Restore

import OCR file

If you should need to recover this file, the following command can be used.
# ocrconfig -import /oracle/backup/cluster/backup01.ocr

To see whether your OCR’s are in sync and healthy run an ocrcheck, which should return with “succeeded“, like below.

# ocrcheck Status of Oracle Cluster Registry is as follows : Version : 2 Total space (kbytes) : 280908 Used space (kbytes) : 4612 Available space (kbytes) : 276296 ID : 1065955458 Device/File Name : /dev/raw/ocr01.dat Device/File integrity check succeeded Device/File Name : /dev/raw/ocr02.dat Device/File integrity check succeededCluster registry integrity check succeeded

Retore from your OCR backup

You system automatically backup the OCR periodically. So, you can just resotre if it you need to.

# ocrconfig -restore /home/app/oracle/product/crs/cdata/crs/backup02.ocr

3. Add or replace OCR files

If you setup only one OCR file during the RAC configuration and need to add additional mirrored file(s). You can apply same rule to convert OCR raw devices into OCR block devices.(Please refer metalink doc 428681.1 for OCR/Vote disk maintenance Operations)

* This command replaces your primary OCR file with /dev/cciss/ocr01.dat
# ocrconfig -replace ocr /dev/cciss/ocr01.dat

* This command replaces your mirrored OCR file with /dev/cciss/ocr02.dat
# ocrconfig -replace ocrmirror /dev/cciss/ocr02.dat

Dynamic Resource Mastering

In database releases before 10g (10.1.0.2) once a cache resource is mastered on an instance, a re-mastering or a change in the master would take place only during a reconfiguration that would happen automatically during both normal operations like instance startup or instance shutdown or abnormal events like Node eviction by Cluster Manager. So if Node B is the master of a cache resource, this resource will remain mastered on Node B until reconfiguration.

10g introduces a concept of resource remastering via DRM. With DRM a resource can be re-mastered on another node say from Node B to Node A if it is found that the cache resource is accessed more frequently from Node A. A reconfiguration is no longer the only reason for a resource to be re-mastered.

Oracle 10g Release 1 performs resource re-mastering on file level but from Oracle 10g Release 2 it performs on segment level. You can monitor dynamic resource mastering through V$GCSPMASTER_INFO view.

SQL> select file_id,object_id,current_master,previous_master,remaster_cnt
from v$gcspfmaster_info;

FILE_ID OBJECT_ID CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
———- ———- ————– ————— ————
0                        65763                                         1                                32767                          1
0                       65949                                          1                                 32767                         1
0                       91316                                          1                                            0                         5
0                     107842                                       0                                   32767                        1

You can perform resource mastering manually by using oradebug lkdebug command. Below command changes master of objectid 91316 to the node that you execute this command.

SQL> oradebug lkdebug -m pkey 91316

Hidden Parameters
_GC_AFFINITY_LIMIT – Default value is 50(times) which means that if there is more than 50 times access difference between the nodes for a specific object then it changes master to more frequently accessed node.
_GC_AFFINITY_MINIMUN – Default value is 600(times) which means a object must be accesses at least 600 times per minutes to be qualified as a new master.
_GC_AFFINITY_TIME – It defines how often oracle will execute resource re-mastering. Default is 10(minutes). You can disable resource re-mastering by setting this value to 0.

The main processes on RAC

GCS : Global Cache Service, physically provides by LMS process.

         LMS process manages lock information for buffers and it also manager buffer transfe between the nodes.
         You can specify specific number of LMS processes by settnig GCS_SERVER_PROCESSES.
         Oracle's recommendation: # of CPU / 4

GES : Global Enqueue Service. This managed by LMD and LCK processes.

          On RAC, since LMS manages BL lock, there is only one LCK process.
          LMD manages messages between the nodes. For example, messages which requesting block transfer or response.
          The other important role of LMD process is deadlock detection.

CGS : Cluster Group Service.  Managed by LMON process

          LMON process manages cluster membership and monitors cluster status.