[oracle_br] Re: Performance do banco de dados!

[jlchiappa]

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 
> > , 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 o

[oracle_br] Re: Performance do banco de dados!

[hribeiro01]

 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 
> > , 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 
> >  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/ 
> >
> > []s
> >
> > Chiappa
> >
> >  
> 
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

Re: [oracle_br] Re: Performance do banco de dados!

[Thiago Lazzarotto]

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 
> , Thiago Lazzarotto
> <[EMAIL PROTECTED]> 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 
>  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/ 
>
> []s
>
> Chiappa
>
>  



[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance do banco de dados!

[jlchiappa]

--- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto
<[EMAIL PROTECTED]> 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 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/

[]s

 Chiappa

Re: [oracle_br] Re: Performance do banco de dados!

[Thiago Lazzarotto]

Uma pergunta? Pelo SO tem como ver qual o processo que está fazendo mais 
I/O?
Ou somente pelo banco?

Obrigado
Thiago.

Thiago Lazzarotto escreveu:

> 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...
>
> Vou ver o que descubro e mando pro grupo.
>
> Valeu.
>
> jlchiappa escreveu:
>
> > Bem, análise de performance é um trabalho que tem que ser feito
> > LOCALMENTE, e que consome tempo pra se fazer, sem dúvida nenhuma um e-
> > mail curto E escrito à distância não vai te dar solução, mas seguem
> > alguns comentários que podem ter ajudar - a maioria deles são tópicos
> > que pretendo abordar no Workshop de SQL que a gente citou no ENPO,
> > que está em progresso, mas é o seguinte : veja vc, o uso de
> > statspack e tools gerais, que te dão visão geral do banco como um
> > todo, é limitado, se a análise rápida e rasteira não te indicou nada
> > óbvio nos SQLs top, isso por si só é uma indicação de que vc OU tem
> > alguns ** poucos ** processos ruins que bagunçam geral o I/O mas
> > são "escondidos" na análise de top pelos outros muitos bons ou
> > neutros, OU que realmente o hardware não está dando conta. Pra vc
> > poder concluir o hardware, vc ** TEM QUER SE TER ASSEGURADO ** que
> > não há nenhum processo importante que esteja desperdiçando I/O, é
> > isso. É aquela história, se vc tiver processos fazendo MONTES e
> > MONTES de I/O desnecessários feito loucos, vc pode ter o hardware de
> > I/O mais poderoso que quiser que provavelmente ele não dará
> > conta. Como normalmente (a não ser nos casos mais raros e fáceis)
> > não é o sistema como um todo que está ruim, então NÃO HÁ "análise que
> > pode ser feita pelo banco para identificar isso"... NÃO TEM JEITO, vc
> > terá que identificar todos os processos importantes e comuns (veja,
> > NÂO ESTOU falando de SQLs , mas sim de PROCESSOS DE NEGÓCIO) e ver
> > pra cada um deles se está bem de I/O, se não está fazendo mais I/Os
> > que o mínimo necessário... Uma das tools que vc pode usar pra isso
> > para os processos que fundamentalmente processem dados vindos dum bd
> > Oracle é gerar um trace+tkprof e ver como é a proporção de LIOs x
> > linhas efetivamente recuperadas, ** se ** houver algo absolutamente
> > desproporcional (tipo, poucas centenas de linhas resultando de
> > centenas de milhares de LIOs) esse cara é suspeito de poder ser
> > melhorado (seja com alteração nas estruturas físicas, como
> > particionamento ou GTTs, resetando um eventual HWM muito alto, seja
> > mesmo re-escrevendo o SQL de modo que faça menos LIOs - por exemplo,
> > usando Analytics, usando alguma feature que elimine sub-queries por
> > exemplo, seja mudando o plano via stats melhores, seja mesmo via
> > hints em ** último caso **). De referência, recomendaria o estudo do
> > paper "Why You Should Focus on LIOs Instead of PIOs" no site
> > hotsos.com
> > >>> UMA VEZ realmente feito um esforço ** SÉRIO ** e completo
> > pra reduzir I/O e realmente não tendo sido possível, aí sim vc pode
> > concluir não há desperdício, e que o subsistema de I/O não está
> > adendendo à demanda . E note que pelos motivos citados no paper, o
> > alvo é diminuir o total de I/Os Oracle, os LIOs, SE os PIOs estão
> > baixos (por causa do cache do storage, por exemplo), ** MAS ** a mal-
> > comportada da aplicação faz montes de LIOs isso FATALMENTE causa
> > waits e FATALMENBET não aparecerá nas tools de SO, talvez dai
> > o "pelas ferramentas da EMC,vejo que o Storage está sobrando" que vc
> > diz...
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br 
> 
> > , Thiago Lazzarotto
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > Olá pessoal! Tudo bem?
> > >
> > > Gostaria que vocês me ajudassem.
> > > Estamos com problemas de performance no banco de dados. Versao 91R2
> > > Enterprise com RAC
> > > As 2 máquinas são 2xIntel Xeon Dual Core com 12 gb de memória.
> > > O meu problema está relacionado com I/O.
> > > Quase todas as sessões ficam fazendo db file sequential read (70%
> > do
> > > total de wait).
> > > Vendo pelo top no Linux (RH4.0 U3), percebo que o % de cpu
> > aguardando
> > > I/O está muito alto (em torno de 40%).
> > > E ainda tenho cpu idle (mais de 30%)
> > >
> > > Não tenho problemas com latches nem locks.
> > >
> > > A dúvida é onde está o problema, porque a máquina está esperando
> > por I/O
> > > e tem CPU sobrando...
> > > Há alguma análise que pode ser feita pelo banco para identificar
> > isso?
> > > Vcs acham que pode ser problema no Storage? Pelas ferramentas da
> > EMC,
> > > vejo que o Storage está sobrando...
> > >
> > > Agradeço qualquer dica!!!
> > >
> > > Obrigado.
> > > Thiago.
> > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  



[As partes 

Re: [oracle_br] Re: Performance do banco de dados!

[Thiago Lazzarotto]

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

Vou ver o que descubro e mando pro grupo.

Valeu.

jlchiappa escreveu:

> Bem, análise de performance é um trabalho que tem que ser feito
> LOCALMENTE, e que consome tempo pra se fazer, sem dúvida nenhuma um e-
> mail curto E escrito à distância não vai te dar solução, mas seguem
> alguns comentários que podem ter ajudar - a maioria deles são tópicos
> que pretendo abordar no Workshop de SQL que a gente citou no ENPO,
> que está em progresso, mas é o seguinte : veja vc, o uso de
> statspack e tools gerais, que te dão visão geral do banco como um
> todo, é limitado, se a análise rápida e rasteira não te indicou nada
> óbvio nos SQLs top, isso por si só é uma indicação de que vc OU tem
> alguns ** poucos ** processos ruins que bagunçam geral o I/O mas
> são "escondidos" na análise de top pelos outros muitos bons ou
> neutros, OU que realmente o hardware não está dando conta. Pra vc
> poder concluir o hardware, vc ** TEM QUER SE TER ASSEGURADO ** que
> não há nenhum processo importante que esteja desperdiçando I/O, é
> isso. É aquela história, se vc tiver processos fazendo MONTES e
> MONTES de I/O desnecessários feito loucos, vc pode ter o hardware de
> I/O mais poderoso que quiser que provavelmente ele não dará
> conta. Como normalmente (a não ser nos casos mais raros e fáceis)
> não é o sistema como um todo que está ruim, então NÃO HÁ "análise que
> pode ser feita pelo banco para identificar isso"... NÃO TEM JEITO, vc
> terá que identificar todos os processos importantes e comuns (veja,
> NÂO ESTOU falando de SQLs , mas sim de PROCESSOS DE NEGÓCIO) e ver
> pra cada um deles se está bem de I/O, se não está fazendo mais I/Os
> que o mínimo necessário... Uma das tools que vc pode usar pra isso
> para os processos que fundamentalmente processem dados vindos dum bd
> Oracle é gerar um trace+tkprof e ver como é a proporção de LIOs x
> linhas efetivamente recuperadas, ** se ** houver algo absolutamente
> desproporcional (tipo, poucas centenas de linhas resultando de
> centenas de milhares de LIOs) esse cara é suspeito de poder ser
> melhorado (seja com alteração nas estruturas físicas, como
> particionamento ou GTTs, resetando um eventual HWM muito alto, seja
> mesmo re-escrevendo o SQL de modo que faça menos LIOs - por exemplo,
> usando Analytics, usando alguma feature que elimine sub-queries por
> exemplo, seja mudando o plano via stats melhores, seja mesmo via
> hints em ** último caso **). De referência, recomendaria o estudo do
> paper "Why You Should Focus on LIOs Instead of PIOs" no site
> hotsos.com
> >>> UMA VEZ realmente feito um esforço ** SÉRIO ** e completo
> pra reduzir I/O e realmente não tendo sido possível, aí sim vc pode
> concluir não há desperdício, e que o subsistema de I/O não está
> adendendo à demanda . E note que pelos motivos citados no paper, o
> alvo é diminuir o total de I/Os Oracle, os LIOs, SE os PIOs estão
> baixos (por causa do cache do storage, por exemplo), ** MAS ** a mal-
> comportada da aplicação faz montes de LIOs isso FATALMENTE causa
> waits e FATALMENBET não aparecerá nas tools de SO, talvez dai
> o "pelas ferramentas da EMC,vejo que o Storage está sobrando" que vc
> diz...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br 
> , Thiago Lazzarotto
> <[EMAIL PROTECTED]> escreveu
> >
> > Olá pessoal! Tudo bem?
> >
> > Gostaria que vocês me ajudassem.
> > Estamos com problemas de performance no banco de dados. Versao 91R2
> > Enterprise com RAC
> > As 2 máquinas são 2xIntel Xeon Dual Core com 12 gb de memória.
> > O meu problema está relacionado com I/O.
> > Quase todas as sessões ficam fazendo db file sequential read (70%
> do
> > total de wait).
> > Vendo pelo top no Linux (RH4.0 U3), percebo que o % de cpu
> aguardando
> > I/O está muito alto (em torno de 40%).
> > E ainda tenho cpu idle (mais de 30%)
> >
> > Não tenho problemas com latches nem locks.
> >
> > A dúvida é onde está o problema, porque a máquina está esperando
> por I/O
> > e tem CPU sobrando...
> > Há alguma análise que pode ser feita pelo banco para identificar
> isso?
> > Vcs acham que pode ser problema no Storage? Pelas ferramentas da
> EMC,
> > vejo que o Storage está sobrando...
> >
> > Agradeço qualquer dica!!!
> >
> > Obrigado.
> > Thiago.
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>  



[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance do banco de dados!

[jlchiappa]

Bem, análise de performance é um trabalho que tem que ser feito 
LOCALMENTE, e que consome tempo pra se fazer, sem dúvida nenhuma um e-
mail curto E escrito à distância não vai te dar solução, mas seguem 
alguns comentários que podem ter ajudar - a maioria deles são tópicos 
que pretendo abordar no Workshop de SQL que a gente citou no ENPO, 
que está em progresso, mas é o seguinte  : veja vc, o uso de 
statspack e tools gerais, que te dão visão geral do banco como um 
todo, é limitado, se a análise rápida e rasteira não te indicou nada 
óbvio nos SQLs top, isso por si só é uma indicação de que vc OU tem 
alguns ** poucos ** processos ruins que bagunçam geral o I/O mas 
são "escondidos" na análise de top pelos outros muitos bons ou 
neutros, OU que realmente o hardware não está dando conta. Pra vc 
poder concluir o hardware, vc ** TEM QUER SE TER ASSEGURADO ** que 
não há nenhum processo importante que esteja desperdiçando I/O, é 
isso. É aquela história, se vc tiver processos fazendo MONTES e 
MONTES de I/O desnecessários feito loucos, vc pode ter o hardware de 
I/O mais poderoso que quiser que provavelmente ele não dará 
conta. Como normalmente (a não ser nos casos mais raros e fáceis) 
não é o sistema como um todo que está ruim, então NÃO HÁ "análise que 
pode ser feita pelo banco para identificar isso"... NÃO TEM JEITO, vc 
terá que identificar todos os processos importantes e comuns (veja, 
NÂO ESTOU falando de SQLs , mas sim de PROCESSOS DE NEGÓCIO) e ver 
pra cada um deles se está bem de I/O, se não está fazendo mais I/Os 
que o mínimo necessário... Uma das tools que vc pode usar pra isso 
para os processos que fundamentalmente processem dados vindos dum bd 
Oracle é gerar um trace+tkprof e ver como é a proporção de LIOs x 
linhas efetivamente recuperadas, ** se ** houver algo absolutamente 
desproporcional (tipo, poucas centenas de linhas resultando de 
centenas de milhares de LIOs) esse cara é suspeito de poder ser 
melhorado (seja com alteração nas estruturas físicas, como 
particionamento ou GTTs, resetando  um eventual HWM muito alto, seja 
mesmo re-escrevendo o SQL de modo que faça menos LIOs - por exemplo, 
usando Analytics, usando alguma feature que elimine sub-queries por 
exemplo, seja mudando o plano via stats melhores, seja mesmo via 
hints em ** último caso **). De referência, recomendaria o estudo do 
paper "Why You Should Focus on LIOs Instead of PIOs" no site 
hotsos.com 
 >>> UMA VEZ realmente feito um esforço ** SÉRIO ** e completo 
pra reduzir I/O e realmente não tendo sido possível, aí sim vc pode 
concluir não há desperdício, e que o subsistema de I/O não está 
adendendo à demanda . E note que pelos motivos citados no paper, o 
alvo é diminuir o total de I/Os Oracle, os LIOs, SE os PIOs estão 
baixos (por causa do cache do storage, por exemplo), ** MAS ** a mal-
comportada da aplicação faz montes de LIOs isso FATALMENTE causa 
waits e FATALMENBET não aparecerá nas tools de SO, talvez dai 
o "pelas ferramentas da EMC,vejo que o Storage está sobrando" que vc 
diz...
 
 []s
 
   Chiappa
   
--- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto 
<[EMAIL PROTECTED]> escreveu
>
> Olá pessoal! Tudo bem?
> 
> Gostaria que vocês me ajudassem.
> Estamos com problemas de performance no banco de dados. Versao 91R2 
> Enterprise com RAC
> As 2 máquinas são 2xIntel Xeon Dual Core com 12 gb de memória.
> O meu problema está relacionado com I/O.
> Quase todas as sessões ficam fazendo db file sequential read (70% 
do 
> total de wait).
> Vendo pelo top no Linux (RH4.0 U3), percebo que o % de cpu 
aguardando 
> I/O está muito alto (em torno de 40%).
> E ainda tenho cpu idle (mais de 30%)
> 
> Não tenho problemas com latches nem locks.
> 
> A dúvida é onde está o problema, porque a máquina está esperando 
por I/O 
> e tem CPU sobrando...
> Há alguma análise que pode ser feita pelo banco para identificar 
isso?
> Vcs acham que pode ser problema no Storage? Pelas ferramentas da 
EMC, 
> vejo que o Storage está sobrando...
> 
> Agradeço qualquer dica!!!
> 
> Obrigado.
> Thiago.
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: Performance do banco de dados!

[mcampo132001]

Thiago,

Incremente o parametro "db_cache_size" para utilizar mais memória


Marcos Campos