这是oracle10g中开始出现的bug,当因为系统activity增加或者降低的时候,oracle SMON进程会自动ONLINE或者OFFLINE rollback segments。这样导致某些与undo segments相关的latch或者enqueue被hold住太长时间,导致系统很多活跃session都开始等待enq: US - contention。
可以同时使用以下解决方法:
1. 设置event让SMON不自动OFFLINE回滚段。
alter system set events ‘10511 trace name context forever, level 1′;
2. 设置参数_rollback_segment_count :表示有多少rollback segment要处于online的状态;可以将该数值设置为数据库最繁忙的时候的回滚段数目。
alter system set “_rollback_segment_count”=;
3. undo autotune bug多多。最好disable。
alter system set “_undo_autotune” = false;
4. 有一个patch: A fix to bug 7291739 is to set a new hidden parameter, _highthreshold_undoretention to set a high threshold for undo retention completely distinct from maxquerylen.
alter system set “_highthreshold_undoretention”=;
UNDO TABLESPACE是8i到9i最好的改进之一;可惜在10g中bug多多。
DTrace scripts:
Read more…
Shared server模式中,发现dispatcher process可比Shared server process重要的多; kill一个shared server process,顶多只有attach那个进程的session受影响;如果kill一个dispatcher, 被分配给这个dispatcher的所有session都会自动断开。
查看 v$dispatcher可以看每个dispatcher负责多少session.
ORACLE@SQL> select name,OWNED from v$dispatcher;
NAME OWNED
—- ———-
D000 283
D001 285
D002 282
MTS连接,一直查询v$session.paddr,发现并不会变化,说明session自从创建开始就一直存在于该dispatcher的队列中。DISPATCHER的队列模式为 多对一 模式,多个”事务”,一个CPU ( Dispatcher)。
通过查看busy rate和queue time,可以判断是否需要更多的dispatcher进程。
Select name, (busy / (busy + idle))*100
“Dispatcher % busy Rate”
From V$DISPATCHER;NAME Dispatcher % busy Rate
—- ———————-
D000 3.82924217
D001 3.71514979SELECT d.name,decode(totalq,0,’No Responses’,
wait/totalq) “Average Wait time”
FROM V$QUEUE q, V$DISPATCHER d
WHERE q.type = ‘DISPATCHER’
AND q.paddr = d.paddr;NAME Average Wait time (单位为1/100秒)
—- —————————————-
D001 .013183
D002 .013174
虽然搞不懂什么泊松方程(poisson),但是根据下文还是能正确的计算出erlangC.
编辑了一下orapub的 capacity-forcasting-excel, 基于erlangC计算RT和RQ,也不知道excel2011里面的poisson函数准不准。



