Thursday, February 9, 2012

11.1.0.6 vs 11.2.0.2


Existing 10gR2 RAC setup (Before Upgrade)

Target 11gR2 RAC Setup (After Upgrade)

Clusterware

Oracle 11g R1 Clusterware 11.1.0.6

Oracle 11gR2 Grid Infrastructure 11.2.0.1

ASM Binaries

11g R1 RAC 11.1.0.6

Oracle 11gR2 Grid Infrastructure 11.2.0.1

Cluster Name

Lab

lab

Cluster Nodes

node1, node2, node3

node1, node2, node3

Clusterware Home

/u01/app/oracle/crs (CRS_HOME)

/u01/app/grid11201 (GRID_HOME)

Clusterware Owner

oracle:(oinstall, dba)

oracle:(oinstall, dba)

VIPs

node1-vip, node2-vip, node3-vip

node1-vip, node2-vip, node3-vip

SCAN

N/A

lab-scan.hingu.net

SCAN_LISTENER Host/port

N/A

Scan VIPs Endpoint: (TCP:1525)

OCR and Voting Disks Storage Type

Raw Devices

Raw Devices OR ASM diskgroup

OCR Disks

/dev/raw/raw1, /dev/raw/raw2

/dev/raw/raw1, /dev/raw/raw2 OR +OCRVDBKP

Voting Disks

/dev/raw/raw3, /dev/raw/raw4, /dev/raw/raw5

/dev/raw/raw3, /dev/raw/raw4, /dev/raw/raw5 OR +OCRVDBKP

ASM_HOME

/u01/app/oracle/asm11gr1

/u01/app/grid11201

ASM_HOME Owner

oracle:(oinstall, dba)

oracle:(oinstall, dba)

ASMLib user:group

oracle:oinstall

oracle:oinstall

ASM LISTENER

LISTENER (TCP:1521)

LISTENER (TCP:1521)




DB Binaries

Oracle 11gR1 RAC (11.1.0.6)

Oracle 11gR2 RAC (11.2.0.1)

DB_HOME

/u01/app/oracle/db11gr1

/u01/app/oracle/db11201

DB_HOME Owner

oracle:(oinstall, dba)

oracle:(oinstall, dba)

DB LISTENER

LAB_LISTENER

LAB_LISTENER

DB Listener Host/port

node1-vip, node2-vip, node3-vip (port 1530)

node1-vip, node2-vip, node3-vip (port 1530)

DB Storage Type, File Management

ASM with OMFs

ASM with OMFs

ASM diskgroups for DB and FRA

DATA, FRA

DATA, FRA

OS Platform

Oracle Enterprise Linux 5.5 (32 bit)

Oracle Enterprise Linux 5.5 (32 bit)


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). One node is dedicated to these backups, but the node dedicated to the backups might change should the node that was doing the backups go down. OCR backups are made to the GRID_HOME/cdata/ directory on the node performing the backups. 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

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 as seen in this example:

Ocrconfig –showbackup auto

One thing to be aware of is that 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. Be aware then, 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:

Ocrconfig –manualbackup

You can list the manual backups with the ocrconfig command too:

Ocrconfig –showbackup manual

Ocrconfig also supports the creation of a logical backup of the OCR as seen here:

Ocrconfig –export /tmp/ocr.exp

It is recommended that the OCR backup location be on a shared file system and that the cluster be configured to write the backups to that file system. To change the location of the OCR backups, you can use the ocrconfig command as seen in this example:

Ocrconfig –backuploc /u01/app/oracle/ocrloc

The Voting Disk Files are used by Oracle Clusterware to determine which nodes are currently members of the cluster. The voting disk files are also used in concert with other Cluster components such as CRS to maintain the clusters integrity.

As with most everything else Clusterware/RAC related, you need to consider redundancy in your architecture. Oracle expects that you will configure at least 3 voting disks for redundancy purposes. You should always configure an odd number of voting disks >= 3. This is because loss of more than half your voting disks will cause the entire cluster to fail.

You should plan on allocating 280MB for each voting disk file. For example, if you are using ASM and external redundancy then you will need to allocate 280MB of disk for the voting disk. If you are using ASM and normal redundancy you will need 560MB.

Oracle Database 11g Release 2 provides the ability to store the voting disks in ASM along with the OCR. Oracle Clusterware can access the OCR and the voting disks present in ASM even if the ASM instance is down. As a result CSS can continue to maintain the Oracle cluster even if the ASM instance has failed. By default Oracle will create three voting disk files in ASM. This requires that the ASM diskgroup that will store the voting disk file be configured with three failure groups. If you are upgrading to Oracle Database 11g you can migrate your voting disks to ASM easily with the crsctl replace command.

You can also use the crsctl query command to locate the voting disks as seen in this example:

Crsctl query css votedisk

You can also migrate voting disks between NAS and ASM or ASM to NAS using the crsctl replace command.

Starting with Oracle Clusterware 11g Release 2 you no longer need to backup the voting disks. The voting disks are automatically backed up as a part of the OCR. In fact, Oracle explicitly indicates that you should not use a backup tool like dd to backup or restore voting disks. Doing so can lead to the loss of the voting disk.

Time Synchronization on Oracle RAC

Oracle Clusterware 11g release 2 (11.2) requires time synchronization across all nodes within a cluster when Oracle RAC is deployed.

You can use one of the following options for time synchronizaion:

  • Your operating system-configured network time protocol (NTP)

  • Oracle Cluster Time Synchronization Service (new in 11gR2)

Hangcheck_timer module is required to run a supported configuration in Oracle Real Application Clusters environments on Linux, with Oracle releases 9i, 10g, or 11gR1 RAC.

Note : Hangheck timer is not required starting with Oracle Clusterware 11gR2

Reference:
http://www.oracledba.org/upgrade/Upgrade_11gR1_RAC_to_11gR2_RAC.htm
http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/RACR2ARC6/Default.aspx

No comments:

Post a Comment