February 22, 2008
What's Mean "reliable message"?
作者:eygle
出处:http://blog.eygle.com
今天客户的一套RAC环境出现问题双节点RAC环境中，一个节点因为锁竞争而挂起，shutdown之后无法启动。
故障出现时我正在路上，匆匆回到家中，处理故障。
解决之后查找故障原因。
检查当时的AWR信息发现Top 5 Timed Events显示如下信息：
Top 5 Timed Events Avg %Total这里最显著的事件是reliable message，这个事件Metalink的解释为:
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
reliable message 354 89 251 219.4 Other
CPU time 32 78.3
db file sequential read 2,223 12 6 30.3 User I/O
control file sequential read 29,151 8 0 20.9 System I/O
db file scattered read 36 2 62 5.5 User I/O
-------------------------------------------------------------
When you send a message using the 'KSR' intra-instance broadcast也就是说当跨实例发送消息时，发送者期望收到订阅者的回复信息，如果得不到可信回复，就会一直处于等待。等待以3秒为周期进行反复尝试，知道收到所有订阅者的回复或者被唤醒。
service, the message publisher waits on this wait-event until
all subscribers have consumed the 'reliable message' just sent.
The publisher waits on this wait-event for three seconds and
then re-tests if all subscribers have consumed the message, or
until posted.
那么在这个环境中，也就是说两个节点的通讯已经出现问题，一个节点得不到另外一个节点的回复。
这是一个可怕的故障，reliable message也是一个让人头疼的事件。
-The End-
Posted by eygle at 10:58 PM | Comments (10)
DMT之后SMON还需要coalesce么?
作者:eygle
出处:http://blog.eygle.com
在LMT之前，也就是说在DMT中，SMON的一个经常性工作是去合并（coalesce ）相邻的自由空间。那么在LMT之后，这个工作还需要么?
如果表空间创建是Extent的设置使用的是Uniform Size选项，那么显然在使用过程中自由空间不再需要被合并，因为请求的Extent将和现存的大小一致。
但是即使如此，在Oracle9i的某些版本中，仍然会存在Coalesce所带来的困然。
已知在Oracle 9.2.0.6数据库版本中，你可能会看到如下语句在Top SQL列表中出现：
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t whe re t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0
这个语句就是用于空间管理的，t.dflextpct!=0是查找那些pct_increase不等于0的表空间，t.bitmapped=0是查找那些非本地管理表空间的。
虽然在很多9i之后的数据库中，这个查询的返回值统统是0，但是查询仍然在消耗资源。
虽然这个语句的返回值为0，但是执行计划并不简单：
PARSING IN CURSOR #1 len=115 dep=1 uid=0 oct=3 lid=0 tim=13490086563004 hv=2095543314 ad='54e34f24'
select f.file#, f.block#, f.ts#, f.length from fet$ f, ts$ t where t.ts#=f.ts# and t.dflextpct!=0 and t.bitmapped=0
END OF STMT
PARSE #1:c=0,e=220,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=13490086562995
BINDS #1:
EXEC #1:c=0,e=95,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=13490086563299
FETCH #1:c=0,e=2591,p=0,cr=236,cu=0,mis=0,r=0,dep=1,og=4,tim=13490086565948
STAT #1 id=1 cnt=0 pid=0 pos=1 obj=0 op='NESTED LOOPS '
STAT #1 id=2 cnt=0 pid=1 pos=1 obj=16 op='TABLE ACCESS FULL TS$ '
STAT #1 id=3 cnt=0 pid=1 pos=2 obj=12 op='TABLE ACCESS CLUSTER FET$ '
对于LMT的UNIFORM SIZE和AUTOALLOCATE，两者的区别还是明显的。
在Oracle9i、10g中，可以通过DBA_FREE_SPACE_COALESCED视图来查看各表空间的空间合并情况：
SQL> select * from v$version;-The End-
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
SQL> select tablespace_name,extents_coalesced,blocks_coalesced from dba_free_space_coalesced;
TABLESPACE_NAME EXTENTS_COALESCED BLOCKS_COALESCED
------------------------------ ----------------- ----------------
SYSTEM 2 448
UNDOTBS1 15 4312
USERS 1 26416
EYGLE 1 12464
SQL> select tablespace_name,EXTENT_MANAGEMENT,ALLOCATION_TYPE from dba_tablespaces;
TABLESPACE_NAME EXTENT_MAN ALLOCATIO
------------------------------ ---------- ---------
SYSTEM LOCAL SYSTEM
UNDOTBS1 LOCAL SYSTEM
TEMP LOCAL UNIFORM
USERS LOCAL SYSTEM
EYGLE LOCAL SYSTEM
TEMP2 LOCAL UNIFORM
6 rows selected.
Posted by eygle at 12:04 AM | Comments (2)