Thiago,

  Intrometendo na conversa, como esta configurado as Lun's dentro da
Storage EMC? Vc usa multiplexação de FC? Qual eh a Capacidade de Block
Size da Lun? Q tipo de Storage vc usa? Symetrix ou Clariion? A Lun's
estão em TressPass?

--- 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]
>


Responder a