oracle9i RAC性能调整(一)

rac turning

工作中,一直在使用RAC环境的数据库,当然我是以9i见多.对于RAC的一些性能的调整,一直是一个比较大的问题.这里将部分自己的经验以及来自其他参考的文献写下这样的笔记.以方便自己,也方便别人.

我们知道,在RAC环境中，实例间是通过内联方式来相互传递信息的，如果期间出现问题，可能会造成数据库性能严重下降，
这里主要针对部分情况给出一些解决的方案。

9iRAC中通过cache funsion来减少由于ping block时所产生的磁盘竞争，
但都需要通过访问远程实例来写。相反，一个RAC副本dirty 从buffer中通过cf
同步到远程实例中进行写入。这个功能仅当dba使用:释放锁资源（为某一个datafile设置
gc_files_to_locks=0或者所有datafile都不设置gc_files_to_locks）
hash lock使用的ping机制和fixed lock在9iRAC环境中已经不再使用，新增了额外的RAC互连机制，
在这个情况下如何出现了性能问题，这样就需要你跨实例来进行调整了。

这里可以使用metalink中的一个脚本racdiag.sql或者statspack report

可以通过等待事件和global cache statistics 来监控数据库情况。
这包括了：
1、平均cr block receive时间很高. 这个值是'global cache cr block receive time'除以
'global cache cr blocks received'来计算出来 ,
在9.2的statspack报告,你也可以使用以下全局缓冲服务工作负载:
Ave receive time for CR block (ms): 4.1
可以使用以下脚本来进行监控：

set numwidth 20
column "AVG CR BLOCK RECEIVE TIME (ms)" format 9999999.9

column "GCS CR BLOCK RECEIVE TIME" format 999,999,999,999
column "GCS CR BLOCKS RECEIVED" format 999,999,999,999

select b1.inst_id, b2.value "GCS CR BLOCKS RECEIVED",
b1.value "GCS CR BLOCK RECEIVE TIME",
((b1.value / b2.value) * 10) "AVG CR BLOCK RECEIVE TIME (ms)"
from gv$sysstat b1, gv$sysstat b2
where b1.name = 'global cache cr block receive time'
and b2.name = 'global cache cr blocks received'
and b1.inst_id = b2.inst_id ;


INST_ID GCS CR BLOCKS RECEIVED GCS CR BLOCK RECEIVE TIME AVG CR BLOCK RECEIVE TIME (ms)
-------- ---------------------- ------------------------- ------------------------------
1 258600936 261025997 10.1
2 282050843 76239572 2.7

可以看出来，1(即为domea) 比2（即domeb）的响应速度慢5倍。

根据系统配置情况，平均cr block receive time或current block receive time 应该通常是小于15秒比较正常的。

这里有一点需要注意的，如果平均global cache current block receive time比较低，
而'global cache null to x' 却特别高的话，那么很可能是碰上bug(2130923)了，
当然这个只是统计数字上的问题，并不影响实际性能。

几种情况的诊断：

1、statspack中Ave receive time for current block 特别高

根据metalink文档243593.1中的描述，可检查global cache null to x的平均等待时间，如：
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
global cache null to x 11,198 85 40 4 0.5

如果arg wait小于15-20ms，而Ave receive time for current block 异常高的情况下，那么这个情况属于bug,
可升级至9205或者以上版本可解决此问题，当然也可以忽略掉此bug。

2、在top events中出现global cache cr request

这个等待事件表明了大量的时间在通过global cache进行一致性读取请求块.
当一个一致性读取无法在本地buffer中找到时，会试图从其他实例中得到这样一个可用块版本.

这里有三种情况：
a、一个cr block在获取到如从其它实例产生或获取到相应的版本,global cache cr blocks received统计值增加
b、其他实例也没有缓存block,这时需要从磁盘读取，但在请求共享锁的时候会增加"global cache gets".
c、接收到一个当前块,如当前块为一个有效的查询，global cache current blocks received统计值增加。

在这所有三种情况中的请求过程都可能等待global cache cr request。可通过查询视图x$kclcrst(CR statistic)
来获取诊断信息，如果请求数目位于data block（reqdata)或者undo header block(requndo)中，表示正在返回一个
装运中的CR block或者current block，并且指从磁盘读取返回的次数。
应当指出的是，出现global cache cr request等待事件有时候并不一定是RAC性能问题，因为数据同时在多个实例上进行
读取和修改是正常的。

另外，在出现global cache cr request的同时经常会出现buffer busy global CR

buffer busy global CR的解释：
当一个以上的会话在同一实例中排队等待缓冲区的一个CR副本，而该期待的CR副本来自远程instance时，
会话在buffer busy global cr（缓冲区忙全局一致读取）事件上等待。
一旦来自远程instance的CR副本到达本地缓存，在缓冲区可用之前将块的SCN（系统提交号）与快照的SCN进行对比。
buffer busy global cr的等待参数如下：
P1：ORACLE读取块的文件号
P2：ORACLE想从文件读入一个缓冲区的块号
P3：表示原因的数值型代码

如果在实例内联出现问题，可使用oradebug观察实例间通信情况：
oradebug setmypid
oradebug ipc
oradebug tracefile_name

可观察到trace文件中会有以下内容（部分）；
SSKGXPT 0x1a2932c flags SSKGXPT_READPENDING info for network 0
socket no 10 IP 172.16.193.1 UDP 43749
sflags SSKGXPT_WRITESSKGXPT_UP info for network 1
socket no 0 IP 0.0.0.0 UDP 0...

注意：有一些cluster软件是看不到的，如veritas cluster server.
由于oracle内部通信初始配置按照veritas cluster server 的低等待时间传输（llt）协议，
但是由于oracle 升级后libskgxp9.so（inter-node communication functions）
文件被升级oracle自己的库文件所覆盖，会造成oracle走了默认协议udp来通信，在网络流量过大或负载过高时，
由于cache funsion互ping过程中会出现问题，会引起oracle所有节点呈挂起状态。
以下是本人以前遇到地的，帖上来：

链接过程
cp /opt/VRTSvcs/rac/lib/libskgxp92_64.so 　$ORACLE_HOME/lib/libskgxp9.so
$ln -s $ORACLE_HOME/lib/libodm9.so $ORACLE_HOME/lib/libodmd9.so

当做完ln重启实例后，oradebug出来后正确的应该是如下：

Dump of unix-generic realm handle `/oracle/rac9i/productfsrac1', flags = 00000000
Area #0 `Fixed Size' containing Subareas 0-0
Total size 00000000000b4930 Minimum Subarea size 00000000
Area Subarea Shmid Stable Addr Actual Addr
0 0 6906 0000000380000000 0000000380000000
Subarea size Segment size
00000000000b6000 0000000181400000
Area #1 `Variable Size' containing Subareas 1-1
Total size 0000000180000000 Minimum Subarea size 01000000
Area Subarea Shmid Stable Addr Actual Addr
1 1 6906 00000003800b6000 00000003800b6000
Subarea size Segment size
0000000180f4a000 0000000181400000
Area #2 `Redo Buffers' containing Subareas 2-2
Total size 0000000000146000 Minimum Subarea size 00000000
Area Subarea Shmid Stable Addr Actual Addr
2 2 6906 0000000501000000 0000000501000000
Subarea size Segment size
0000000000146000 0000000181400000
Area #3 `skgm overhead' containing Subareas 3-3
Total size 0000000000004000 Minimum Subarea size 00000000
Area Subarea Shmid Stable Addr Actual Addr
3 3 6906 0000000501146000 0000000501146000
Subarea size Segment size
0000000000004000 0000000181400000
Dump of Solaris-specific skgm context
sharedmmu 00000001
shareddec 0
Maximum processes: = 1500
Number of semaphores per set: = 1504
Semaphores key overhead per set: = 4
User Semaphores per set: = 1500
Number of semaphore sets: = 1
Semaphore identifiers: = 1
Semaphore List=
2818052
-------------- system semaphore information -------------
IPC status from as of Sat Jan 6 10:40:20 CST 2007
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME
Semaphores:
s 0 0x710003c1 --ra-ra-ra- root root root root 1 10:31:17 15:46:31

RAC: Ave Receive Time for Current Block is Abnormally High in Statspack

SELECT a.inst_id "Instance",
(a.value+b.value+c.value)/decode(d.value,0,1, d.value) "LMS Service Time"
FROM gv$sysstat A,
gv$sysstat B,
gv$sysstat C,
gv$sysstat D
WHERE A.name = 'global cache cr block build time'
AND B.name = 'global cache cr block flush time'
AND C.name = 'global cache cr block send time'
AND D.name = 'global cache cr blocks served'
AND B.inst_id = A.inst_id
AND C.inst_id = A.inst_id
AND D.inst_id = A.inst_id
ORDER
BY a.inst_id;

Instance LMS Service Time
--------- ----------------
1 1.07933923< 2 .636687318<

SELECT A.VALUE "GC BLOCKS LOST 1",
B.VALUE "GC BLOCKS CORRUPT 1",
C.VALUE "GC BLOCKS LOST 2",
D.VALUE "GC BLOCKS CORRUPT 2"
FROM GV$SYSSTAT A, GV$SYSSTAT B, GV$SYSSTAT C, GV$SYSSTAT D
WHERE A.INST_ID=1 AND A.NAME='global cache blocks lost'
AND B.INST_ID=1 AND B.NAME='global cache blocks corrupt'
AND C.INST_ID=2 AND C.NAME='global cache blocks lost'
AND D.INST_ID=2 AND D.NAME='global cache blocks corrupt'
??
GC BLOCKS LOST 1 GC BLOCKS CORRUPT 1 GC BLOCKS LOST 2 GC BLOCKS CORRUPT 2
---------------- ------------------- ---------------- -------------------
0 0 652 0

表示实例2有出现过块丢失的情况，意味着net故障。

再查看造成块丢失的原因

SELECT A.INST_ID "INSTANCE", A.VALUE "GC BLOCKS LOST",
B.VALUE "GC CUR BLOCKS SERVED",
C.VALUE "GC CR BLOCKS SERVED",
A.VALUE/(B.VALUE+C.VALUE) RATIO
FROM GV$SYSSTAT A, GV$SYSSTAT B, GV$SYSSTAT C
WHERE A.NAME='global cache blocks lost' AND
B.NAME='global cache current blocks served' AND
C.NAME='global cache cr blocks served' and
B.INST_ID=a.inst_id AND
C.INST_ID = a.inst_id;
?
Instance gc blocks lost gc cur blocks served gc cr blocks served RATIO
---------- -------------- -------------------- ------------------- ----------
1 0 3923 2734 0
2 652 3008 4380 .088251218

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/104152/viewspace-140014/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/104152/viewspace-140014/