ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle9i RAC性能调整(一)

oracle9i RAC性能调整(一)

原创 Linux操作系统 作者:cc59 时间:2007-06-07 00:00:00 0 删除 编辑
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<<----faster
2 .636687318<<----slower


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/,如需转载,请注明出处,否则将追究法律责任。

上一篇: bitmap的锁机制
请登录后发表评论 登录
全部评论

注册时间:2007-12-21

  • 博文量
    132
  • 访问量
    288300