Привет всем!
Есть ситуация: две ноды в RAC (10.2.0.2) на HP-UX 11.23
работает куча джобов (около 100) на ОДНОМ из инстансов (второй просто бездельничает рядом). Большинство времени джобы ждут на DFS lock handle.
Кусок трейса говорит что:
=====================
PARSING IN CURSOR #89 len=69 dep=2 uid=119 oct=6 lid=119 tim=237078064849 hv=1574607469 ad='e344f4d8'
UPDATE ROAM_CALLS_012007 SET BILL_BILL_ID = :BILL WHERE ROWID = :ROWW
END OF STMT
PARSE #89:c=0,e=46,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=1,tim=237078064846
FETCH #88:c=0,e=22,p=0,cr=3,cu=0,mis=0,r=0,dep=2,og=1,tim=237078064971
STAT #88 id=1 cnt=0 pid=0 pos=1 obj=166193 op='TABLE ACCESS BY INDEX ROWID ROAM_CALLS_012007 (cr=3 pr=0 pw=0 time=39 us)'
STAT #88 id=2 cnt=0 pid=1 pos=1 obj=166195 op='INDEX RANGE SCAN ROAM_CALLS_012007_UK (cr=3 pr=0 pw=0 time=34 us)'
EXEC #86:c=0,e=11,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=1,tim=237078065829
WAIT #86: nam='DFS lock handle' ela= 489013 type|mode=1398145029 id1=28489 id2=0 obj#=-1 tim=237078555008
*** 2007-02-02 08:39:36.164
WAIT #86: nam='DFS lock handle' ela= 488246 type|mode=1398145029 id1=28489 id2=0 obj#=-1 tim=237079043291
WAIT #86: nam='DFS lock handle' ela= 488151 type|mode=1398145029 id1=28489 id2=0 obj#=-1 tim=237079531562
WAIT #86: nam='DFS lock handle' ela= 488257 type|mode=1398145029 id1=28489 id2=0 obj#=-1 tim=237080019851
WAIT #86: nam='DFS lock handle' ela= 488237 type|mode=1398145029 id1=28489 id2=0 obj#=-1 tim=237080508127
WAIT #86: nam='DFS lock handle' ela= 16968 type|mode=1398145029 id1=28489 id2=0 obj#=-1 tim=237080525130
WAIT #86: nam='latch: ges resource hash list' ela= 32 address=-4611685896082556400 number=65 tries=1 obj#=-1 tim=237080525256
FETCH #86:c=0,e=2459476,p=0,cr=0,cu=0,mis=0,r=1,dep=2,og=1,tim=237080525326
EXEC #86:c=0,e=11,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=1,tim=237080525498
WAIT #86: nam='latch: ges resource hash list' ela= 46 address=-4611685896082556400 number=65 tries=1 obj#=-1 tim=237080525641
WAIT #86: nam='DFS lock handle' ela= 490186 type|mode=1398145029 id1=28489 id2=0 obj#=-1 tim=237081015959
WAIT #86: nam='DFS lock handle' ela= 488206 type|mode=1398145029 id1=28489 id2=0 obj#=-1 tim=237081504219
Помотрел доку и запустил такой запрос:
select chr(bitand(p1,-16777216)/16777215)||
chr(bitand(p1, 16711680)/65535) "Lock",
bitand(p1, 65536) "Mode",
p2text, p2raw, p2,
p3text, p3raw, p3
from v$session_wait
where event = 'DFS lock handle';На что собственно получил мног таких записей:
SV 0 id1 0000000000006F49 28489 id2 00 0
SV 0 id1 0000000000006F49 28489 id2 00 0
SV 0 id1 0000000000006F49 28489 id2 00 0
SV 0 id1 0000000000006F49 28489 id2 00 0
Поискал объект 28489. Оказался SEQUENCE, который объявлен как ORDERED, CACHE 1000. Т.к. мне было сказано, что ORDERED обязателен, то начал изучать единственный доступный моему понимаю парамет cache 1000.
При выборке из dba_sequences, вижу что last_number увеличивается на 1000 приблизительно раз в 15-20 секунд.
На этом идеи как побороть это ожидание закончились.
Подскажите плз. что еще можно посмотреть попробовать...
Кстати, для эксперимента попробовал потушить второй инстанс (тоесть работал только один), никакого результата не дало.