Porque a x$bh é um CACHE, de onde as coisas podem e saem de lá A QUALQUER
MOMENTO, enquanto o OEM se baseia no HISTÓRICO, E a v$latch_children mostra o
latch que está ocorrendo ** neste instante ** apenas ? Aliás, um acesso a um
bloco (sem locks envolvidos) dura FRAÇÕES DE SEGUNDO, a chance de vc rodar o
SQL no exato instante em que o acesso está acontecendo é pequena, essa query
que vc mostra é útil SE vc a executar muitas e muitas vezes, aumentado a chance
de "pegar" o momento em que blocos estão sendo acessados, MAS é por amostragem,
sempre... Para vc detectar hot blocks em excesso, o negócio é mesmo ir pelos
waits de latches, a própria nota "How To Identify a Hot Block Within The
Database Buffer Cache" , Doc ID: Note:163424.1 (que deve ser a que vc usou,
imagino) nos diz :
"Possible hot blocks in the buffer cache normally can be identified by a high or
rapid increasing wait count on the CACHE BUFFERS CHAINS latch."
Então é isso, quando vc diz "Mas esta é a questão...nos dois últimos selects,
os sleeps estavam zerados e
nesta última consulta, não veio nada...como se não houvessem este latch..." o
que imagino é que REALMENTE, no exato instante em que vc executou esse SQL o
latch não estava acontecendo e/ou o bloco não estava mais no cache,
provavelmente se vc executase muitas vezes vc ia pegar ele, mas torno a dizer,
é melhor vc monitorar as quantidades de waits. *** ALIÁS ***, , um ponto
importante : o OEM tá mostrando waits por latches, sinal de que eles estão
acontecendo, ** MAS ** qual é o nível disso, porcentualmente QUANTO dos waits é
por latches... Executando repetidas vezes uma consulta tipo :
SELECT event, time_waited,
round(time_waited*100/ SUM (time_waited) OVER(),2) wait_pct
FROM (SELECT event, time_waited
FROM v$system_event
WHERE event NOT IN
('Null event',
'client message',
'rdbms ipc reply',
'smon timer',
'rdbms ipc message',
'PX Idle Wait',
'PL/SQL lock timer',
'file open',
'pmon timer',
'WMON goes to sleep',
'virtual circuit status',
'dispatcher timer',
'SQL*Net message from client',
'parallel query dequeue wait',
'pipe get'
) UNION
(SELECT NAME, VALUE
FROM v$sysstat
WHERE NAME LIKE 'CPU used when call started'))
ORDER BY 2 DESC;
o resultado quase sempre, sempre é algo tipo :
EVENT TIME_WAITED WAIT_PCT
------------------------------ ----------- ----------
latch free 40144 31.67
CPU used when call started 30341 23.94
control file sequential read 12341 9.74
direct path read 11933 9.41
control file parallel write 6487 5.12
file identify 5666 4.47
log file sync 3492 2.75
log file parallel write 3213 2.53
instance state change 3064 2.42
log file switch completion 3049 2.41
db file sequential read 2290 1.81
??? Se sim, OK, não só uma fração significativa dos waits foi por latch como o
tempo em wait (comparado com os outros) é significativo também, é razoável
supor que latches são sim significativa do seu problema....
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiuru...@...> escreveu
>
> Grandes amigos...
>
> Problema resolvido...na verdade foi uma PKG que estava sendo muito acessada
> ontem...algo novo implementado pelo pessoal de desenvolvimento (Grrrrrrrrr)
> que ja foi resolvido...
>
>
> Mas fica a dúvida, pq no último select, que seria para me mostrar o hotblock,
> ele nãpo mostrou nada e no EM estava la, sendo exibido bem alto, o Latch ?
>
> Fiquei na dúvida...
>
>
> --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiurudba@> escreveu
> >
> > Opa colegas...
> >
> > Dei mais uma procurada na net..mas desta vez no metalnk e achei um DOC
> > sobre este latch..mas, segundo as verificações que são solicitadas, não
> > encontrei o bendito Hotblock..
> >
> > 01) Verifiquei os wait relacionados ao wait no banco para testificar o latch
> >
> > 02)Verificação dos hight sleep
> > select CHILD# "cCHILD"
> > , ADDR "sADDR"
> > , GETS "sGETS"
> > , MISSES "sMISSES"
> > , SLEEPS "sSLEEPS"
> > from v$latch_children
> > where name = 'cache buffers chains'
> > order by 5, 1, 2, 3;
> >
> > 03) Verificação dos hitblocks
> >
> > select /*+ RULE */
> > e.owner ||'.'|| e.segment_name segment_name,
> > e.extent_id extent#,
> > x.dbablk - e.block_id + 1 block#,
> > x.tch,
> > l.child#
> > from
> > sys.v$latch_children l,
> > sys.x$bh x,
> > sys.dba_extents e
> > where
> > x.hladdr = 'ADDR' and
> > e.file_id = x.file# and
> > x.hladdr = l.addr and
> > x.dbablk between e.block_id and e.block_id + e.blocks -1
> > order by x.tch desc ;
> >
> >
> > Mas esta é a questão...nos dois últimos selects, os sleeps estavam zerados
> > e nesta última consulta, não veio nada...como se não houvessem este
> > latch...mas o OEM esta acusando, meus nucleos da minha CPU estão em 100% e
> > ja tenho lentidão....
> >
> > Alguem tem alguma ideia ?
> >
> >
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, "candiurudba" <candiurudba@> escreveu
> > >
> > > Boa tarde colegas,
> > >
> > > Verifiquei o inicio de um latch que na verdade ainda não tinha visto e
> > > dei uma procurada rapida na net e percebi que se tratavam de bloco /
> > > blcoos que sofreriam alterações "simultaneamente". Seria mesmo isso ?
> > >
> > > Como resolver este problema ? Tentei ler alguns relatos na net mas nada
> > > muito convicente....
> > >
> >
>
