Vou responder em ordem inversa : primeiro, vc compara é a proporção de LIOs x linhas efetivamente retornadas - por exemplo, digamos que vc vá fazer um acesso via índice direto, vc vai fazer um I/O do bloco de header do índice, depois ao menos um I/O de bloco branch (tipicamente na verdade em produção ao menos 2 blocos branch, em produção com tabs grandes é comum vc ter índices "altos") ,depois outro I/O do bloco leaf, que aí sim aponta pro bloco desejado com o registro na tabela, bloco esse que será lido também - assim, ao menos 5 I/Os pra se obter uma linha via índice é um mínimo comum. Assim, no seu exemplo, se esses 1000 LIOs trouxeram (digamos) , cento e tantas linhas, perfeito, fez uma média próxima disso de I/O por linha, é uma boa indicação de eficiência. Agora, imagine que esses mesmos 1000 LIOs trouxeram apenas meia dúzia de linhas, isso está muito muito longe do ideal, algo está TERRIVELMENTE errado aí, talvez um HWM alto, talvez um plano ineficiente, algo não tá bem.. =====>>>>>> EVIDENTE, esse tipo de análise não é aplicável sempre, por exemplo se vc tem algum tipo de agrupação, como um COUNT, óbvio que agrupação significa ler largas porções da tabela fazendo trocentos I/Os pra te trazer só uma linha que é o resultado da contagem, óbvio que a relação entre LIOs x resultado estará NATURALMENTE distorcida aqui..... Casos deste tipo aí sim, é mesmo empírico, é vc testar vários planos, re-escrever o SQL (com analytics, com o que puder) e ir comparando pra ver qual faz menos LIOs.... Quanto ao nested loops, ele NÃO é sempre bom, e nem (pra citar o caso típico) o full table scan é sempre ruim, tudo SEMPRE SEMPRE depende do caso, depende doseu objetivo.... Sabendo-se a teoria por trás do método (que no caso de nested loop basicamente é : escolhe-se uma tabela drive que será lida até o fim, pra cada linha lida busca- se os detalhes na outra tab do join), fica claro que isso é ultra- eficiente quando a tabela drive é ** pequena **, ou no caso em que a tab drive é grande MAS vc quer obter as primeiras linhas mais rapidamente (por exemplo, aquelas queries de paginação, onde vc mostra os primeiros 10 regs, depois que o usuário aperta 1 botão mostra mais 10). Claro que se o seu objetivo é processar tudo o mais rapidamente E a tabela não é de tamanho trivial, é via de regra *** muito mais *** eficiente vc processar múltiplas linhas por vez, ao invés de uma por uma que é o que o NL faz... No "Effective Oracle by Design" o Tom Kyte discute isso com exemplinhos muito bons, eu *** RECOMENDO ENFATICAMENTE *** que vc o adquira e o use, pra Ontem.... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto <[EMAIL PROTECTED]> escreveu > > Bom dia Lista! > > Como sempre Chiappa, boas explicações. > É verdade que em meu sistema tenho muitas querys com nested loop. Muitas > mesmo. > Mas isso não é bom? Ou nem sempre é bom? > > Como o meu número de logical reads é muito maior que o physical reads, > vou começar a investigar > pelos consumidores de logical reads. > > Existe algum valor aceitável para logical reads por query? Por exemplo, > como vou saber se 1000 logical reads é muito ou pouco? > Só testando? > > Valeu amigos. > Thiago. > > > jlchiappa escreveu: > > > --- Em oracle_br@yahoogrupos.com.br > > <mailto:oracle_br%40yahoogrupos.com.br>, Thiago Lazzarotto > > <thiago.lazzarotto@> escreveu > > > > > > Pelo SO tem como ver qual o processo que está fazendo mais > > > I/O? > > > Ou somente pelo banco? > > > > Até tem, mas como disse a análise pelo SO normalmente tem dois > > problemas : o SO não te mostra o histórico , só te mostra os top > > processos , E só se estiverem fazendo o I/O exatamente na hora que vc > > está analisando... Até existem ferramentas à parte do SO normalmente > > que permitem vc acompanhar o histórico de I/O dum processo, que dizem > > pra cada processo quantos % de I/O consumiu (tipo, existiam x > > processos na máquina, foram feitos n I/Os no sistema no total, assim > > se um dado processo fez y I/Os isso representa tantos % do I/O > > servido)mas normalmente isso não é parte integrante do SO... > > Então, se omo a maioria dos sistemas o seu basicamente processe o que > > veio do banco, I/O do banco está sempre envolvido, recomendaria > > começar olhando no banco, mesmo. > > > > > > > > > > > O que notei analisando os statspack é que o número de waits não > > aumentou > > > > muito, mas o tempo de wait, esse sim aumentou bastante nas últimas > > > > semanas... > > > > Ou seja, teve sim processos/programas/alguma coisa nova que entrou > > (senão nada mudaria), e na média o tempo que os I/Os levam pra ser > > completados aumentou... Tranquilamente pode ser que o(s) > > programa(s)/processos mal-comportados estejam (por exemplo) fazendo > > nested loop, aí ele só faz I/Os curtos (PORTANTO não aperecriam em > > TOPs e coisas do tipo), mas são I/Os constantes, cabou um I/O pequeno > > imediatamente ele pede outro e logo em seguida outro e logo em > > seguida outro, ou seja, não tem um think time pra dar chance pro banco > > servir outro processo.... Um cara desse vc só pega NO HISTÓRICO, > > anaálise com vmstat/top/glance/similares é um instantãneo, não serviria. > > É como eu disse, análise de processo como um todo E analisar os > > principais processos.... Acho que seria MUITO muito interessante aí > > tentar se confirmar a performance do sub-sistema de disco per se, tipo > > : com o banco e aplicação parados vc faz uma medida, sobe o banco e > > ainda sem usuários faz outra, aí cfrme os usuários vão entrando vc vai > > fazendo novas medidas, E finalmente quando em modo normal de processo > > faz mais uma... http://www.acnc.com/benchmarks.html > > <http://www.acnc.com/benchmarks.html> tem algumas tools > > free pra isso, das que ele cita quando eu precisei uma vez eu usei o > > iozone. Mas isso é informação complementar, pra mim o pono aí AINDA é > > processo fazendo LIOs feito doido. > > E só complementando : não só eu como o resto do pessoal que tá > > conversando com vc, estamos todos focando em I/O - de repente > > tranquilamente PODE ser que hajam outras questões aí... Eu sugiro que > > vc passe o teu trace 10046 dos principais processos também pela > > ferramenta ORASRP, ele monta um relatóriozinho mais detalhado do que o > > tkprof, de repente outras coisas podem aparecer. Tem uma versão nova > > dela em http://oracledba.ru/orasrp/ <http://oracledba.ru/orasrp/> > > > > []s > > > > Chiappa > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
