Chiapa / Wilson, obrigado pela ajuda....! Depois de alguns testes da interface descobri que o "latch cache buffer chain" estava sendo causado por um indice que foi criado. Após a criação desse indice a interface passou a demorar 10x mais....eu desabilitei o indice e na execução seguinte a interface voltou para seu tempo de execução normal.... Mas não entendi como um indice pode causar o latch nesssa interface....as estatisticas dele estao atualizas, o indice é um Btree global composto por um unico campo campo number(3) com baixa cardinalidade....e a tabela é particionada por data....
Não tenho acesso ao usuário SYS, por isso nao consegui consultar a tabela X$BH para identificar os blocos em latch.... Respondendo ao Chiapa o SEQ# da v$session_wait troca constantemente, porém com com endereço de memória passado no P1, só consegui fazer join com as v$latchXXXXXXX, só que em nenhuma eu consegui referenciar um objeto que poderia ter seu bloco "preso" em memória. Não sei se pode estar relacionado, mas essa interface é disparada por uma arquitetura atravéz de um EXECUTE IMMEDIATE ' Call Procedure', qnd tento acompanhar oq essa sessao esta executando através da v$session, v$sql ou v$sqlarea o Sqlid sempre aponta para a chamada da proc 'Call Procedure' e não ao que a session está exatamente executando. Pra exemplificar, digamos que a procedure que chamei esteja fazendo um insert, nao visualizo esse insert na v$sqlarea, mas sei q ele esta sendo executado, pois estou utilizando a dbms_application_info.set_module para identificar em que ponto a procedure esta... Vocês poderiam tentar me explicar os pontos acima??? Mt obrigado pela atenção!!! Abçs!!! Thiago Azevedo 2008/6/17 wilson teixeira <[EMAIL PROTECTED]>: > Há pouco tempo me deparei com este evento de espera e o diagnostico foi: > Query mal escrita. Havia uma inner query consultando uma tabela e a query > mais externa consultava a mesma tabela. Elas disputavam os mesmos blocos na > SGA, vc pode consultar a X$BH para identificar quais são os blocos deste > latch... > > _____ > > De: oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br> [mailto: > oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>] Em > nome de jlchiappa > Enviada em: segunda-feira, 16 de junho de 2008 19:53 > Para: oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br> > Assunto: [oracle_br] Re: Wait event: latch: cache buffers chains > > > Seguinte : > > a) primeiro, em desconhecendo versão 10.0.2, suponho que vc fala sobre > banco 10.2.0.x : sendo isso, é VITAL vc indicar exatamente QUAL é o x > : desconheço bugs específicos para esse latch, mas sei (de ouvir > falar, já que fui direto pro 10.2.0.3), que no 10.2.0.1 e .2 houveram > uns tantos bugs diversos sobre performance (especialmente com SGA e > PGA automáticas), de repente é um desses que vc está enfrentando e o > latch é consequ~encia da má performance, não a causa > > b) exatamente QUAL é esse bug que vc diz que viu ? Numa busca simples > no metalink só achei bugs referentes à latch em situações muito muito > específicas, como o bug 4742607 > > => e ÓBVIO, antes de sair caçando bugs, SEMPRE é reconedado e > recomendável se verificar EXATAMENTE o que está acontecendo : > > c) recomendaria o estudo da nota Subject:How to Identify Which Latch > is Associated with a "latch free" wait, Doc ID: Note:413942.1, ela > discorre sobre os métodos para se identificar EXATAMENTE o que ocorre > na situação de latch > > d) a nota não fala, mas (se o wait pelo latch é maior do que o tempo > de refresh das tabs internas refletidas nas v$), vc : > > 1. na v$session_wait vc tem o SEQ#, pra saber se entre duas > consultas o wait event de cache buffer chain que vc está vendo é o > mesmo que AINDA não foi atendido ou se é outro > 2. pode consultar a v$access, as views de latch e o p1, p2 e p3 para > tentar identificar o objeto sendo acessado > 3. pode usar o trace + tkprof, esse é um dos métodos MAIS eficientes > pra vc avaliar waits > > e sendo banco 10g vc : > > 4. pode checar o SQL_ID e o PREV_SQL_ID na V$SESSION para a sessão > que está tendo esse wait, será que é o mesmo SQL ou não ? > 5. se tiver direito, pode usar o ASH pra ter um HISTÓRICO de quais > waits a tua sessão enfrentou, até pra saber se esse latch wait está > MESMO sendo relevante ou não > > []s > > Chiappa > > --- Em [EMAIL PROTECTED] > <mailto:oracle_br%40yahoogrupos.com.br<oracle_br%2540yahoogrupos.com.br> > > > os.com.br, "Thiago Azevedo" > <[EMAIL PROTECTED]> escreveu > > > > Pessoal, > > > > Uma das interfaces de um bade de produção 10.0.2, constantemente > "trava" e > > fica com wait event de "latch: cache buffers chains", lendo sobre > isso eu > > encontrei alguns textos que pode ser um bug da versão 10.0.2, > inclusive no > > metalink, porém o bug em questão está como privado e não tenho como > ler oq > > pode ser feito. > > > > Caso eu mate a sessão e restart a interface ela é executada rapidamente. > > > > Alguém já teve esse problema? > > > > -- > > Thiago Azevedo > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > [As partes desta mensagem que não continham texto foram removidas] > > > -- Thiago Azevedo Accenture Brazil Services - AO Carrefour Work: 55 11 51888492 Mobile: 55 13 81453524 email: [EMAIL PROTECTED] MSN IM: [EMAIL PROTECTED] [As partes desta mensagem que não continham texto foram removidas]
