Skip to content

RAC

11g r2 模拟OCR和voting disk不可用，完整恢复过程，以及一些注意事项

环境：RHEL5.8 RAC 11.2.0.3.0

1：查看ORC和voting disk信息：

In 11g Release 2 your voting disk data is automatically backed up in the OCR whenever there is a configuration change.
所以恢复时恢复备份OCR即可，这里和10g是不同的，不需要备份voting disk，备份OCR即可

2：使用cluvfy 工具检查OCR完整性
[grid@rac1 ~]$ cluvfy comp ocr -n all
Verifying OCR integrity
Checking OCR integrity…

Checking the absence of a non-clustered configuration…
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc”…
OCR config file “/etc/oracle/ocr.loc” check successful
Disk group for ocr location “+CRSDATA” available on all the nodes

NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck’ as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

3：使用ocrcheck检测OCR内容的完整性
[grid@rac1 ~]$ ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3016
Available space (kbytes) : 259104
ID : 1236405787
Device/File Name : +CRSDATA
Device/File integrity check succeeded
Device/File not configured
Device/File not configured
Device/File not configured
Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check bypassed due to non-privileged user –如果使用root用户执行ocrcheck时，会显示Logical corruption check succeeded

4：检测voting disk的信息
[grid@rac1 ~]$ crsctl query css votedisk
## STATE File Universal Id File Name Disk group
— —– —————– ——— ———
1. ONLINE 2b1bd0c122584f5abf72033b2b2d26bd (/dev/asm-b_crs) [CRSDATA]
2. ONLINE 2bc03776cdd94f5cbfb9165c473fdb0e (/dev/asm-c_crs) [CRSDATA]
3. ONLINE 3b43c39513a64f2dbf7083a9510ada89 (/dev/asm-d_crs) [CRSDATA]
Located 3 voting disk(s).

从上面看出，OCR和voting disk都位于+CRSDATA磁盘组 ，注意+CRSDATA磁盘组还有ASM的启动参数文件，ASM启动是根据磁盘头的kfdhdb.spfile指向ASM上的此磁盘的UA NUMBER从而读取spfile文件

5：手动备份一份OCR信息：
[root@rac1 grid]# ocrconfig -export /tmp/ocr_20130717.dmp
[root@rac1 grid]# ll /tmp/ocr_20130717.dmp -h
-rw——- 1 root root 102K Jul 17 14:45 /tmp/ocr_20130717.dmp

6：查看OCR自动备份信息
[grid@rac1 ~]$ ocrconfig -showbackup

rac1 2013/07/16 15:45:24 /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup00.ocr
rac2 2013/07/16 08:13:38 /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup01.ocr
rac2 2013/07/16 04:14:09 /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup02.ocr
rac2 2013/07/16 00:14:38 /u01/app/11.2.0.3/grid/cdata/ad-cluster/day.ocr
rac2 2013/07/07 04:40:11 /u01/app/11.2.0.3/grid/cdata/ad-cluster/week.ocr
PROT-25: Manual backups for the Oracle Cluster Registry are not available

7：保存一份ASM参数文件，如果提前没保存，可以到$CRS_HOME/dbs/init.ora获取一份，后面此启动参数的详细内容

[grid@rac1 dbs]$ sqlplus / as sysasm

SQL> create pfile=’/tmp/asm_pfile_130717.txt’ from spfile;

File created.

8：破坏保存OCR信息的磁盘组+CRSDATA
[root@rac1 dev]# dd if=/dev/zero of=/dev/asm-b_crs bs=1024 count=1000
[root@rac1 dev]# dd if=/dev/zero of=/dev/asm-c_crs bs=1024 count=1000

9：破坏了磁盘b和c后，都检测通过，没报错，在rac1和rac2停止crs
[root@rac1 dev]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ‘rac1’
CRS-2673: Attempting to stop ‘ora.crsd’ on ‘rac1’
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on ‘rac1’
…………………
CRS-4133: Oracle High Availability Services has been stopped.

[root@rac2 dev]# crsctl stop crs
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ‘rac1’
CRS-2673: Attempting to stop ‘ora.crsd’ on ‘rac1’
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on ‘rac1’
…………………
CRS-4133: Oracle High Availability Services has been stopped.

[root@rac1 dev]# ps -ef |grep ora_
root 16189 32265 0 16:26 pts/0 00:00:00 grep ora_
[root@rac1 dev]# ps -ef |grep asm_
root 16195 32265 0 16:26 pts/0 00:00:00 grep asm_

10:再启动CRS,报错
[root@rac1 dev]# crsctl start crs
CRS-4123: Oracle High Availability Services has been started.

[root@rac1 ~]# tail -50f /u01/app/11.2.0.3/grid/log/rac1/alertrac1.log

[cssd(16559)]CRS-1637:Unable to locate configured voting file with ID 2b1bd0c1-22584f5a-bf72033b-2b2d26bd; details at (:CSSNM00020:) in /u01/app/11.2.0.3/grid/log/rac1/cssd/ocssd.log
2013-07-17 16:28:15.947
[cssd(16559)]CRS-1637:Unable to locate configured voting file with ID 2bc03776-cdd94f5c-bfb9165c-473fdb0e; details at (:CSSNM00020:) in /u01/app/11.2.0.3/grid/log/rac1/cssd/ocssd.log
2013-07-17 16:28:15.947
[cssd(16559)]CRS-1705:Found 1 configured voting files but 2 voting files are required, terminating to ensure data integrity; details at (:CSSNM00021:) in /u01/app/11.2.0.3/grid/log/rac1/cssd/ocssd.log
2013-07-17 16:28:15.948
[cssd(16559)]CRS-1656:The CSS daemon is terminating due to a fatal error; Details at (:CSSSC00012:) in /u01/app/11.2.0.3/grid/log/rac1/cssd/ocssd.log
2013-07-17 16:28:16.073
[cssd(16559)]CRS-1603:CSSD on node rac1 shutdown by user.

ocrcheck检测报错：
[root@rac1 dev]# ocrcheck
PROT-602: Failed to retrieve data from the cluster registry
PROC-26: Error while accessing the physical storage

11：强制关闭CRS:
[root@rac1 dev]# crsctl stop crs -f
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ‘rac1’

[root@rac1 dev]# crsctl stop crs -f
CRS-2797: Shutdown is already in progress for ‘rac1’, waiting for it to complete
CRS-2797: Shutdown is already in progress for ‘rac1’, waiting for it to complete
CRS-4133: Oracle High Availability Services has been stopped.

12：以独占模式启动rac1
[root@rac1 dev]# crsctl start crs -excl -nocrs
CRS-4123: Oracle High Availability Services has been started.
CRS-2672: Attempting to start ‘ora.mdnsd’ on ‘rac1’
CRS-2676: Start of ‘ora.mdnsd’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.gpnpd’ on ‘rac1’
CRS-2676: Start of ‘ora.gpnpd’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.cssdmonitor’ on ‘rac1’
CRS-2672: Attempting to start ‘ora.gipcd’ on ‘rac1’
CRS-2676: Start of ‘ora.cssdmonitor’ on ‘rac1’ succeeded
CRS-2676: Start of ‘ora.gipcd’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.cssd’ on ‘rac1’
CRS-2672: Attempting to start ‘ora.diskmon’ on ‘rac1’
CRS-2676: Start of ‘ora.diskmon’ on ‘rac1’ succeeded
CRS-2676: Start of ‘ora.cssd’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.drivers.acfs’ on ‘rac1’
CRS-2679: Attempting to clean ‘ora.cluster_interconnect.haip’ on ‘rac1’
CRS-2672: Attempting to start ‘ora.ctssd’ on ‘rac1’
CRS-2681: Clean of ‘ora.cluster_interconnect.haip’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.cluster_interconnect.haip’ on ‘rac1’
CRS-2676: Start of ‘ora.ctssd’ on ‘rac1’ succeeded
CRS-2676: Start of ‘ora.drivers.acfs’ on ‘rac1’ succeeded
CRS-2676: Start of ‘ora.cluster_interconnect.haip’ on ‘rac1’ succeeded
CRS-2672: Attempting to start ‘ora.asm’ on ‘rac1’
CRS-2676: Start of ‘ora.asm’ on ‘rac1’ succeeded

12：创建CRSVOTEDISK磁盘组以及spfile

[grid@rac1 ~]$ asmcmd

ASMCMD> ls
空的

[grid@rac1 ~]$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.3.0 Production on Wed Jul 17 16:58:18 2013

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Real Application Clusters and Automatic Storage Management options

SQL> show parameter spfile
NAME TYPEVALUE
———————————— ———– ——————————
spfile string

SQL> create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’, ‘/dev/asm-d_crs’
2 attribute ‘compatible.asm’=’11.2.0.0.0’, ‘compatible.rdbms’=’11.2.0.0.0’;
create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’, ‘/dev/asm-d_crs’
*
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-15033: disk ‘/dev/asm-d_crs’ belongs to diskgroup “CRSDATA” –这里报错是因为asm-d_crs没清除磁盘头信息

清除asm-d_crs磁盘头信息
[root@rac1 dev]# dd if=/dev/zero of=/dev/asm-d_crs bs=1024 count=1000

SQL> create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’,’/dev/asm-d_crs’
2 attribute ‘compatible.asm’=’11.2.0.0.0’, ‘compatible.rdbms’=’11.2.0.0.0′;

Diskgroup created.

SQL> create spfile=’+CRSVOTEDISK’ from pfile=’/tmp/asm_pfile_130717.txt’;

File created.

SQL> quit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Real Application Clusters and Automatic Storage Management options
[grid@rac1 ~]$ asmcmd
ASMCMD> ls
CRSVOTEDISK/
ASMCMD> ls CRSVOTEDISK
ad-cluster/
ASMCMD> ls CRSVOTEDISK/ad-cluster/
ASMPARAMETERFILE/
ASMCMD> ls CRSVOTEDISK/ad-cluster/ASMPARAMETERFILE
REGISTRY.253.821034567

13：Restore OCR from backup:
将原磁盘组+CRSDATA改为新建立的磁盘组 +CRSVOTEDISK
[root@rac1 dev]# vim /etc/oracle/ocr.loc

ocrconfig_loc=+CRSVOTEDISK
local_only=FALSE

[root@rac1 dev]# ocrconfig -restore /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup00.ocr

可以看到增加了一个OCRFILE文件夹
ASMCMD> ls CRSVOTEDISK/ad-cluster
ASMPARAMETERFILE/
OCRFILE/
ASMCMD> ls CRSVOTEDISK/ad-cluster/OCRFILE -l
Type Redund Striped Time Sys Name
OCRFILE MIRROR COARSE JUL 17 17:00:00 Y REGISTRY.255.821036449
ASMCMD> ls CRSVOTEDISK/ad-cluster/ASMPARAMETERFILE -l
Type Redund Striped Time Sys Name
ASMPARAMETERFILE MIRROR COARSE JUL 17 17:00:00 Y REGISTRY.253.821034567

检测成功
[root@rac1 dev]# ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3016
Available space (kbytes) : 259104
ID : 1236405787
Device/File Name : +CRSVOTEDISK
Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

14：Restore the Voting Disk:

[root@rac1 dev]# crsctl query css votedisk
## STATE File Universal Id File Name Disk group
— —– —————– ——— ———
1. OFFLINE 2b1bd0c122584f5abf72033b2b2d26bd () []
2. OFFLINE 2bc03776cdd94f5cbfb9165c473fdb0e () []
3. ONLINE 3b43c39513a64f2dbf7083a9510ada89 (/dev/asm-d_crs) [CRSDATA]
Located 3 voting disk(s).

[root@rac1 dev]# crsctl replace votedisk +CRSVOTEDISK
CRS-4602: Failed 27 to add voting file 5818c2c531394f45bff13c5a7532c8d4.
CRS-4602: Failed 27 to add voting file 1ce0436528624faabf7d4a1dd8dc978a.
CRS-4602: Failed 27 to add voting file 09def2b244af4f42bf13679a8aa0ff73.
Failure 27 with Cluster Synchronization Services while deleting voting disk.
Failure 27 with Cluster Synchronization Services while deleting voting disk.
Failure 27 with Cluster Synchronization Services while deleting voting disk.
Failed to replace voting disk group with +CRSVOTEDISK.
CRS-4000: Command Replace failed, or completed with errors.

这里报错是一开始asm-d_crs没清除磁盘头信息导致的

======================================== 到这里恢复voting disk失败了 ，下面重新开始再次尝试恢复============
下面恢复时要注意：

crsctl start crs -excl -nocrs 启动后，马上关闭ASM,不要立刻创建create diskgroup CRSVOTEDISK磁盘组，再使用参数启动ASM

不然创建磁盘组时可能会收入如下报错：

例如：（下面的操作看看就好了，直到 ：下面开始再次恢复操作）

[grid@rac1 ~]$ sqlplus / as sysasm
SQL> create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’,’/dev/asm-d_crs’
2 attribute ‘compatible.asm’=’11.2.0.0.0’, ‘compatible.rdbms’=’11.2.0.0.0’;
create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’,’/dev/asm-d_crs’
*
ERROR at line 1:
ORA-15018: diskgroup cannot be created
ORA-15031: disk specification ‘/dev/asm-d_crs’ matches no disks
ORA-15014: path ‘/dev/asm-d_crs’ is not in the discovery set
ORA-15031: disk specification ‘/dev/asm-c_crs’ matches no disks
ORA-15014: path ‘/dev/asm-c_crs’ is not in the discovery set
ORA-15031: disk specification ‘/dev/asm-b_crs’ matches no disks
ORA-15014: path ‘/dev/asm-b_crs’ is not in the discovery set –这里找不到设备应该也是和下面的情况是一样的，没指定扫描的路径

SQL> col PATH for a50
SQL> select group_number, disk_number, mount_status, header_status, path from v$asm_disk;
no rows selected
说明没识别出磁盘 ，这里为什么没磁盘现在是搞明白了，因为参数里面根本没设置

SQL> show parameter asm

NAME TYPE VALUE
———————————— ———– ——————————
asm_diskgroups stringDATA —这里使用默认参数文件启动时是空的，正常情况也不会显示保存OCR磁盘组名的
asm_diskstring string/dev/asm* —这里使用默认参数文件启动时是空的，没指定扫描的路径
asm_power_limit integer1
asm_preferred_read_failure_groups string

所以为了保险起见，应该crsctl start crs -excl -nocrs 启动后，马上关闭ASM,不要立刻创建create diskgroup CRSVOTEDISK磁盘组，再使用参数启动ASM
SQL> startup pfile=’/tmp/asm_pfile_130717.txt’;

[grid@rac1 ~]$ cat /tmp/asm_pfile_130717.txt
+ASM1.__oracle_base=’/u01/app/grid’#ORACLE_BASE set from in memory value
+ASM1.asm_diskgroups=’DATA’#Manual Mount
+ASM2.asm_diskgroups=’DATA’#Manual Mount
*.asm_diskstring=’/dev/asm*’
*.asm_power_limit=1
*.diagnostic_dest=’/u01/app/grid’
*.instance_type=’asm’
*.large_pool_size=12M
*.remote_login_passwordfile=’EXCLUSIVE’

这里再查下v$asm_disk就可以查询到磁盘，也可以顺利的创建磁盘组了。。。。。。。。。。，就是因为没立刻关闭ASM,使用修改好的参数文件，创建磁盘组时一直提示找不到磁盘，耽误了半天时间

下面开始再次恢复操作：

关闭crs后再启动
[root@rac1 dev]# crsctl stop crs
[root@rac1 dev]# crsctl start crs -excl -nocrs
[root@rac1 dev]# crsctl query css votedisk
Located 0 voting disk(s).

关闭rac1上的ASM，再使用参数文件启动ASM，创建CRS磁盘组，创建spfile

[grid@rac1 ~]$ sqlplus / as sysasm

SQL>shutdown immediate
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup pfile=’/tmp/asm_pfile_130717.txt’;
ASM instance started

SQL> col path for a50
SQL> set linesize 130
SQL> select group_number, disk_number, mount_status, header_status, path from v$asm_disk;

GROUP_NUMBER DISK_NUMBER MOUNT_S HEADER_STATU PATH
————————————– ———— —————- ——————————
0 0 CLOSED MEMBER /dev/asm-e_data
0 3 CLOSED CANDIDATE /dev/asm-b_crs
0 2 CLOSED CANDIDATE /dev/asm-c_crs
0 1 CLOSED CANDIDATE /dev/asm-d_crs

SQL> create diskgroup CRSVOTEDISK normal redundancy disk ‘/dev/asm-b_crs’,’/dev/asm-c_crs’,’/dev/asm-d_crs’
2 attribute ‘compatible.asm’=’11.2.0.0.0’, ‘compatible.rdbms’=’11.2.0.0.0’;

Diskgroup created.

SQL> create spfile=’+CRSVOTEDISK ‘ from pfile=’/tmp/asm_pfile_130717.txt’;

File created.

SQL> quit

恢复crs
[root@rac1 dev]# ocrconfig -restore /u01/app/11.2.0.3/grid/cdata/ad-cluster/backup00.ocr

恢复voting disk

[root@rac1 dev]# crsctl replace votedisk +CRSVOTEDISK

Successful addition of voting disk 1b00b0ec4e504f7fbf1f8d20fbbfaa4b.
Successful addition of voting disk 5a3b646433124fdcbf23c3c290de7fe3.
Successful addition of voting disk 5d27d80b96d74f09bf1756be6dee387f.
Successfully replaced voting disk group with +CRSVOTEDISK .
CRS-4266: Voting file(s) successfully replaced

检测
[root@rac1 ~]# ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 3
Total space (kbytes) : 262120
Used space (kbytes) : 3016
Available space (kbytes) : 259104
ID : 1236405787
Device/File Name : +CRSVOTEDISK
Device/File integrity check succeeded

Device/File not configured

Device/File not configured

Device/File not configured

Device/File not configured

Cluster registry integrity check succeeded

Logical corruption check succeeded

[root@rac1 ~]# crsctl query css votedisk
## STATE File Universal Id File Name Disk group
— —– —————– ——— ———
1. ONLINE 1b00b0ec4e504f7fbf1f8d20fbbfaa4b (/dev/asm-b_crs) [CRSVOTEDISK ]
2. ONLINE 5a3b646433124fdcbf23c3c290de7fe3 (/dev/asm-c_crs) [CRSVOTEDISK ]
3. ONLINE 5d27d80b96d74f09bf1756be6dee387f (/dev/asm-d_crs) [CRSVOTEDISK ]
Located 3 voting disk(s).

停止crs以正常方式启动：
[root@rac1 ~]# crsctl stop crs
[root@rac1 ~]# crsctl start crs

此时，crs和voting disk已经完成恢复，但要注意修改rac2上的/etc/oracle/ocr.loc里面的ocrconfig_loc=+CRSVOTEDISK ，不然启动报错：

[/u01/app/11.2.0.3/grid/bin/oraagent.bin(19510)]CRS-5019:All OCR locations are on ASM disk groups [CRSDATA], and none of these disk groups are mounted. Details are at “(:CLSN00100:)” in “/u01/app/11.2.0.3/grid/log/rac1/agent/ohasd/oraagent_grid/oraagent_grid.log”.
2013-07-18 00:10:33.678
[/u01/app/11.2.0.3/grid/bin/oraagent.bin(19510)]CRS-5019:All OCR locations are on ASM disk groups [CRSDATA], and none of these disk groups are mounted. Details are at “(:CLSN00100:)” in “/u01/app/11.2.0.3/grid/log/rac1/agent/ohasd/oraagent_grid/oraagent_grid.log”.
2013-07-18 00:11:03.614

[root@rac2 ~]# crsctl start crs

[root@rac1 ~]# crs_stat -t
Name Type Target State Host
————————————————————
ora.CRSDATA.dg ora….up.type ONLINE OFFLINE
ora.DATA.dg ora….up.type ONLINE ONLINE rac1
ora….ER.lsnr ora….er.type ONLINE ONLINE rac1
ora….N1.lsnr ora….er.type ONLINE ONLINE rac1
ora.asm ora.asm.type ONLINE ONLINE rac1
ora.chris.db ora….se.type ONLINE ONLINE rac1
ora.cvu ora.cvu.type ONLINE ONLINE rac1
ora.gsd ora.gsd.type OFFLINE OFFLINE
ora….network ora….rk.type ONLINE ONLINE rac1
ora.oc4j ora.oc4j.type ONLINE ONLINE rac1
ora.ons ora.ons.type ONLINE ONLINE rac1
ora….SM1.asm application ONLINE ONLINE rac1
ora….C1.lsnr application ONLINE ONLINE rac1
ora.rac1.gsd application OFFLINE OFFLINE
ora.rac1.ons application ONLINE ONLINE rac1
ora.rac1.vip ora….t1.type ONLINE ONLINE rac1
ora….SM2.asm application ONLINE ONLINE rac2
ora….C2.lsnr application ONLINE ONLINE rac2
ora.rac2.gsd application OFFLINE OFFLINE
ora.rac2.ons application ONLINE ONLINE rac2
ora.rac2.vip ora….t1.type ONLINE ONLINE rac2
ora….ry.acfs ora….fs.type ONLINE ONLINE rac1
ora.scan1.vip ora….ip.type ONLINE ONLINE rac1

Grid and Cluster Oracle 排障配置与调整 Oracle恢复 数据技术 | Guang Cai Li | |   OCR RAC

Rac 调优概念

1、CPU和wait time调节尺寸

当在调节system时，比较系统的CPU time 和wait time是十分重要的，从而确定在相应时间中多少是用于有效的工作时间，多少是在等待由其他进程占用的资源。

从一般规律来看，wait time占主要部分的系统比CPU time占主要部分的系统更需要调节。另一方面，CPU的大量使用可能是由不好的SQL写操作造成了。

尽管CPU time与wait time的比率总是随着系统装载的增加而趋于减小的，wait time的急剧增加是存在冲突的表现，必须被有效的处理。

给node增加更多的CPUs或是给cluster增加nodes，在资源竞争中提供的benefit是非常有限的。相反，当加载系统装载增加时，CPU time的比率没有大幅下降的系统可能规模较好，更可能通过添加CPUs或是RAC Instances获得更多的benefit。

note：如果CPU time比率在前五个事件中，则automatic workload repository（AWR）报告在Top 5 Event段中显示了CPU时间和wait 时间。

2、RAC特有的调节
尽管对于RAC有其特有的调节方法，例如互联的传输，但通过对每个Instance进行像single-Instance 系统那样的调节会带来较大的benefit。至少它应该tuning的第一步。

显然，如果在single-Instance环境中存在序列化问题，在RAC中，该问题会更加严重。

RAC-reactive调节工具主要有：特定的等待事件、系统和队列统计、database control 性能页面、statspack和AWR 报告

RAC-proactive调节工具：AWR snapshots、ADDM（Automatic Database Diagnostic Monitor）报告

如上，RAC的调节工具和single-Instance系统的基本类似。但部分特殊等待事件和统计信息的结合是RAC比较关键的调节情况。

3、分析在RAC中cache fusion（缓冲融合）的影响
在全局缓冲中访问blocks的影响和维护cache的相融合（coherency）是通过下面来表现的：

* 对当前和cr blocks的全局缓冲服务统计：例如，gc当前的blocks received、gc cr blocks received等。

* 全局缓冲服务等待事件（对gc 当前 block 3-way、gc cr grant 2-way等）

cache fusion传输的响应时间是由物理交换链接组件、IPC协议和GCS协议使用的messaging时间和processing 时间决定的。

除了相关的log写操作，它是不受磁盘I/O因素的影响的。cache fusion 协议不需要对data files进行I/O，从而确保缓冲的coherency。并且RAC并不会引起比非clustered Instance更多的I/O操作。

4、RAC操作特有的潜在因素
在RAC AWR报告中，在RAC统计一章包含了一个表，用于记录一些全局cache services和全局队列services操作的平均时间。该表被称作是Global cache and Enqueue services: workload characteristics。这些潜在因素应该得到定期的监控，并且应该对部分值的重大增加进行调查。基于经验观察，此表显示了一些代表值。引起这些潜在因素变更的因素主要有：

* IPC协议的使用。用户模式的IPC协议更快

* 当系统在CPU高效使用的情况下，时序安排的延迟

* 对当前blocks 服务的log flush

其他在AWR报告中，RAC潜在因素多数是从V$GES_STATISTICS中获得的，并可能对调试非常有效。但无需进行频繁的监控。

note：处理缓存中一致读（consistent read CR）block的时间与（build time+flush time+send time）一致；处理缓存中当前block请求的时间与（pin time+ flush time+ send time）一致。

5、RAC的等待事件
分析哪些sessions在等待是一个确定时间开销在哪里的重要方法。在RAC中，等待时间主要归因于影响获得实际请求结果的事件上。例如，当在某Instance上的一个session在Global cache查询某个block，并不知道是否将收到cache在其他Instance中的data或是是否将获得从disk上读取的消息。对于Global cache的等待事件反映了准确信息并等待全局缓冲block或是messages。它们主要是按照下述进行分类的：

* 在较广的分类的概括，被称作是cluster wait class

* 用占位符代表的临时事件，主要出现在block的等待

* 当获得请求结果的精确事件

RAC的等待事件对性能分析是非常重要的。它们被应用于ADDM中，从而获得cache fusion方面的精确诊断。

1）等待事件视图
对于一个事件的总的等待信息——V$SYSTEM_EVENT

一个session的等待事件分类——V$SESSION_WAIT_CLASS

一个session等待的事件——V$SESSION_EVENT

这三个视图汇集了等待时间、timeouts和特定事件等待次数。

最近活动的sessions的活动行为——V$ACTIVE_SESSION_HISTORY

每个活动的session最近10个等待事件——V$SESSION_WAIT_HISTORY

活动的sessions正在等待的事件——V$SESSION_WAIT

受到互联因素影响的一致的SQL语句——V$SQLAREA

这四个视图用于实时监控等待的sessions，包括最近的等待时间历史信息。

通过其name和假设的参数，来区分单个事件自己。对于多数Global cache等待事件，参数包括文件号、块号、块的类型和访问模式的配置（如held和request模式）。在这些视图中显示并统计的等待时间在调试相应时间时是非常有用的。注意，等待时间是累积计算的，有最大的该值的不一定就是问题所在。但可用的CPU被占尽或是一个Application的相应时间过长，top 等待事件提供了有效的性能诊断信息。

note：在V$SQLAREA中使用CLUSTER_WAIT_TIME字段辨别SQL语句受到互联因素的影响程度，或是在AWR snapshot上执行一个ADDM报告。

2）Global cache wait event概览
Oracle Database 10g中主要的Global cache等待事件的简要描述如下：

* gc current/cr request：当一个进程访问需要一个或者多个块时，oracle会首先检查自己的CACHE是否存在该块，如果发现没有，就会先通过global cache赋予这些块共享访问的权限，然后再访问。假如，通过global cache 发现这些块已经在另一个实例的CACHE里面，那么这些块就会通过CACHE FUSION,在节点之间直接传递，同时出现global cache cr request等待事件。current 和cr的不同，如果是读的话，那就是cr request，如果是更改的话，那就是current request。

* gc [current/cr] [2/3]-way：具体解释见后面实例

* gc [current/cr] block busy：一个current 或是 cr block被请求并收到，但LMS并没有立即发送，因为某些特定的推迟发送的情况被发现。

* gc [current/cr] grant 2-way：当请求一个block时，receive了一个message，该message应该是赋予了requester instance可以访问这个block。如果这个block没有在local cache中，则随后的动作就是去磁盘上读该block。（插一点别的，oracle的对数据的访问的控制，是在row级别和object级别，但是实际操作的对象却是block，传递的对象也是block，对于一个block，来说，会有一个master instance，也就是这个block的管理者，然后还有零到多个参与者，比如有的instance为了读一致性，可能会在自己的local cache中存着该block的过去某个时间的image，有的instace为了修改该block，可能会在自己的local cache中存着该block的past image）

* gc current grant busy：当请求一个current block时，收到grant message。该busy表示请求被阻塞，主要是其他请求在前面或是该请求不能马上被处理。

* gc [current/cr] [block/grant] congested ：无论是对于current还是cr类型block的请求，block或者grant都获得了，但是在过程中有拥堵。也就是在内部的队列中等待超过1msec（纳秒）。

* gc [current/cr] [failure/retry]：一个block被请求，却收到失败的状态或是有其他意外事件的发生。

* gc buffer busy：对此，我的理解就是gc的内存不足，有大量的block请求，需要等待将刚刚被pin入内存并使用的block unpin后再使用。（好像没理解对，看后面实例吧）

3）2-way block request实例

上图显示了当一个master Instance请求一个block，该block不在本地cache中时，具体的操作。这里假设master Instance为SGA1，SGA2中包含了请求的block。具体如下：

①SGA1向SGA2直接发送一个请求，此时，SGA1发生gc current block request等待事件

②当SGA2接到请求，它的本地LGWR进程需要flush 部分恢复信息到其本地redo log文件中。例如，如果缓冲的block被频繁的修改，该修改尚未被写入log中，LMS就需要在传输block前令LGWR对log进行flush。这可能会增加一个延迟，可能在请求的node上显示一个busy wait。

③随后，SGA2发送请求的block给SGA1。当该block到达SGA1，等待事件完成，这被反映为gs current block 2-way。

note：如果R表示在请求者的time，W为消息传输的time延迟，S为在server的time。则整个来回的总时间为：R(send) + W(small msg) + S(process msg, pocess block, send) + W(block) + R(receive block)

4）3-way block request的实例

在此，与上一个实例不同的就是block的请求者与block的master、block的缓冲不在同一个node上。所以总体时间为：

R(send) + W(small msg) + S(process msg, send) + W(small msg) + S(process msg, process block, send) + W(block) + R(receive block)

当远程读被挂起，任何在请求Instance上的尝试读写缓冲在buffer中的data 的进程将等待gc buffer busy事件，直到block到达。

5）2-way grant实例

6）considered “Lost“ Blocks实例

如图，此情况为：在请求的block到达前先收到了side channel message。在普通环境中，这是不会发生的。多数情况下它是转换问题的显示或是缺少私有互联。这常与OS或是网络的配置问题有关。

note：可尝试避免此类现象的发生，通过减小参数DB_FILE_MULTIBLOCK_READ_COUNT的值，使其低于16 。

7）Global 队列等待overview
队列等待并不是RAC特有的，但是在RAC环境中涉及到Global lock的操作。多数对队列的Global请求是同步的，并且有前台进程等待。因此，队列冲突在RAC环境中更明显。多数队列等待发生在下列类型的队列：

* TX：transaction 队列，用于事务的划分和追踪

* TM：table或是partition队列，用于保护DML执行期间table的定义

* HW：高水位线队列，取得用于新的block操作的同步

* SQ：sequence队列，用于Oracle sequence number的序列化增加

* US：undo segment 队列，主要用于自动undo 管理（AUM）的特性

* TA：主要用于事务恢复的队列

上述情况下，等待是同时的，可能造成严重的序列化，从而导致RAC环境的恶化。

6、session和system 统计
使用基于V$SYSSTAT的系统统计使得基于平均的Database描述成为可能。它是很多通过各种工具和方法获得Database的度量和比率的基础，例如AWR、statspack和Database control。

为了进一步对sessions进行深化的了解，V$SESSTAT视图是非常有用的。此外，如果使用了MODULE、ACTION模式的统计，将更有效。

V$SEGMENT_STATISTICS对于RAC环境也非常重要，因为它跟踪了CR的数量以及object当前获得的blocks

RAC相关的统计可以被分为以下几组：
* Global cache service 统计：gc cr blocks received, gc cr block recevie time等

* Global Enqueue service 统计：global enqueue gets等

* messages发送的统计：gcs messages sent和ges messages sent

可以通过查询V$ENQUEUE_STATISTICS确定哪个队列对Database service时间和最终的响应时间有最大的影响。

V$INSTANCE_CACHE_TRANSFER显示了每个block类中有多少current和CR blocks从Instance中接受，包括多少传输引起延迟。

7、RAC tuning的tips
首先，在RAC环境中，必须先利用传统的调节技术对每个Instance进行调节，此外，下面的内容也很重要：

* 尽量避免较长的全表扫描来缩小GCS的请求。由Global CR请求引起的开支主要是因为当所查询的结果在本地cache中不存在，先尝试在其他cache中尝试找到相应数据。

* 自动段空间管理可以给table blocks提供Instance 关联（affinity）

* 增加sequences的caches改善Instance关联的通过sequences获得索引关键字的值的性能。

* 当把range或是list类型的partitioning和data-dependent routing相结合，可以有效的提高性能。

* hash partitioning可有效降低buffer busy的冲突，使得buffer访问分布格局松散，可以使buffers用于更多的并发访问。

* 在RAC中，library cache和row cache操作都是全局协调的。所以过度的解析意味着额外的互联传输。当packages或是procedure需要被重新编译时，需要以排他模式获得library cache locks。

* 因为transaction locks 是全局协调的，在RAC中，也应的到特殊的对待。例如使用tables代替Oracle sequences产生唯一numbers是不推荐的，可能引起严重的冲突，即使是在single Instance系统中。

* 选择性不好的indexes不会提高查询性能，反而会降低DML操作的性能。在RAC环境中，unselective index blocks可能导致Instance间的冲突，增加cache对indexes传输的的频度。

8、index block冲突的思考
由于index多数是单调递增的，往往造成热块争用的问题；而且对于大量的insert操作，可能引起频繁的splits；所有leaf block的访问都是通过root block的。所以index可能造成性能的降低。对此：

* 全局索引hash partitioning

* 增加sequence cache，如果必要的话

9、undo block 考虑
当index blocks包含了从多个Instances发起的事务被频繁的读，过度的undo block传输和undo buffers的争用经常会发生。当一个select语句需要读取一个block，该block正被一个active的事务使用，就不得不用undo来重建一个CR版本。如果block所在的active 事务属于不只一个Instance，则需要结合本地和远程undo information用于一致读，依据被多个Instances修改的index blocks的数量和transaction的并发，undo block的传输可能成为瓶颈。

这多发生在频繁读取近期插入的数据但提交不频繁的应用中。对此应：

* 使用shorter transaction从而降低这样的可能性：从cache中获得的index block含有未提交的data，从而降低访问undo information用于一致读的可能

* 增加sequence cache size，从而减少需要进行远程undo 信息组合的需求。

10、高水位线的考虑
数据的insert操作是业务领域的主要功能，新的blocks需要频繁的分配给segment。如果data的insert操作比率较高，如果没有找到空闲空间时，需要申请新的blocks。这需要获得相应的high-water mark（HWM）队列。

因此，最为普遍的状况为：

* 较高比率的队列等待时间 enq: HW – contention

* 较高比率的等待时间对于 gc current grant events

前者是HWM队列序列化的结果，后者是由于当前访问新的data blocks是需要对新的blocks进行操作。在RAC环境中，这个空间管理操作的时间长短是与获得HW队列和获得所有新的blocks的Global locks所用的时间成比例的。这个时间在普通环境中比较小，因为在访问新的blocks时是不存在任何冲突的。然而，这种冲突可能会出现在有大量data load的业务需求中。对此，建议在本地管理及自动空间管理segments中定义一致的较大的extent size，从而适当解决相应的问题。

11、automatic workload repository

1）overview
AWR是Oracle Database 10g提供的基础服务工具，用于收集、维护和应用统计信息来检测问题并进行自我的调节。

AWR主要由两部分组成：
* 一个在内存的统计收集设施，由Oracle Database 10g使用并收集统计信息。这些统计被存储在内存中，可以通过动态性能视图查看到（V$）

* AWR snapshots 代表了设备的持久部分。可以通过data dictionary视图和Database control来访问。

处于以下几个原因，统计需要保存在永久的设备中：

* 统计需要用于激活Instance crashes

* 一些分析需要历史数据作为基线的比较

* 内存的溢出：当由于内存不足，旧的统计数据需要被新的统计数据替换时，可以将旧的统计数据存储在磁盘上以备后用

统计的内存版本由新的后台进程manageability monitor（MMON）定期的传输的disk上。通过AWR，Oracle Database提供了自动捕获历史统计data的方法，无需DBA干涉。

2）AWR tables

AWR包括两类表：
* 元数据表：用于控制、处理、描述AWR 表。例如，Oracle Database 使用元数据表来确定何时执行snapshots，并将什么数据捕获到disk上。此外，元数据包含了snapshots_id和相应通讯时间之间的映射。

* 历史统计表：存储了Oracle Database的历史统计信息。每个snapshots就是在特定时间点捕获的内存中的Database 统计数据。
AWR表的names都有 一个WRx$前缀，其中x指明了tables的种类：

* WRM$ 表存储了AWR中的元数据

* WRH$表中存储了历史数据和snapshots

可以是使用字典视图来查询AWR数据。在AWR中任何相关的历史信息有DBA_HIST_的前缀

AWR使用分区用于有效的查询和数据的清理。snapshots tables是按照以下分类组织的：file 统计、一般系统统计、并发统计、Instance调节统计、SQL 统计、segment 统计、 undo 统计、time-model 统计、恢复统计和RAC统计。

3）在RAC中的AWR snapshots
在RAC环境中，每个AWR snapshot是从所有的活动的Instances获得data的。从每个活动的Instances获得的每个snapshot数据集合是大致来自相同的时间点的。此外，每个Instance的数据是单独存储的，是以Instance的标识符来区分的。例如，buffer_busy_wait统计显示了在每个Instance上buffer waits的次数。AWR不会存储cluster中的合计数据。换句话说，data是存放在各自的Instance上的。

由AWR产生的统计snapshots可以用于评估、产生报告显示data 摘要。

12、statspack 和AWR
可以通过手工的对statspack操作获得历史统计数据。但是将statspack获得的数据迁移到AWR中是不支持的，也不存在为其创建的视图

13、Automatic Database diagnosis monitor
默认下，Database每隔60分钟，会自动的从SGA中捕获相应的统计信息，并将其以snapshots的形式存储在AWR中。这些snapshots被存储在disk上，和statspack snapshots是一致的，但比statspack的信息更精确。此外，ADDM是通过在每个Database Instance中的新的MMON进程自动运行相应的计划，来主动找到问题的所在。每次获得一个snapshot。ADDM会被触发执行一个与上一个snapshots进行阶段一致性比较的操作。

每个ADDM分析被存储在AWR中（WRI$表）也可通过EM访问。

1）ADDM问题分类
ADDM使用树形结构代表所有可能需要调节的问题。该tree是基于新的等待和时间统计模式的。树根代表的是Database当前的症状

Oracle | Guang Cai Li | |   RAC