Análise de AWR

Envie seu AWR para uma análise gratuita.
Podem ser enviados em formato texto ou html.

Procure sempre emitir o AWR para o menor período possível de análise em que seu problema de desempenho ocorre.

Se desejado, edite o texto e troque o nome do seu servidor, outra outras informações que julgue que não devam ser dilvulgadas.
Post Reply
Pcsilva

Análise de AWR

Post by Pcsilva » Thu Dec 14, 2017 12:09 pm

Fala Portilho!

O ambiente em questão é um RAC 5 nodes, mas este em especial tem sido o mais afetado no periodo.
temos 8 cores e um load avegage de 10 no momento dos snaps.

abraço,
Attachments
maior_load.zip
(66.82 KiB) Downloaded 250 times

portilho
Site Admin
Posts: 482
Joined: Wed May 29, 2013 8:51 am

Re: Análise de AWR

Post by portilho » Wed Jan 03, 2018 11:14 am

Oi !
Pontos a respeito deste AWR:
- A relação Elapsed x DB Time nos confirma que realmente há um problema de desempenho.
- Tradando-se de RAC, sempre é bom também verificar o Global AWR Report, para termos certeza de que o problema de desempenho se localiza apenas em determinado nó.
- A versão muito desatualizada, ainda mais em um ambiente complexo como estes, embora não deva ser a causa da lentidão, sempre é um ponto contra. Mais adiante veremos que o problema é SQL, e talvez o otimizador mais recente do Oracle nos ajudasse nisso.
- A Shared Pool grande, especialmente em relação ao Buffer Cache, indica um problema de SQLs repetitivos sem variáveis BIND. Não parece ser o problema agora, mas verifique a respeito.
- No Time Model, vemos que apenas 13.91% do tempo é gasto em CPU. Ou seja, o problema está em Wait Events.
- Ainda em Time Model, o percentual de "parse time elapsed" já é considerado alto. Realmente procure a respeito de SQLs repetitivos sem variáveis BIND.
- Em Wait Events (nosso foco, nosso problema), quase tudo é User I/O: "db file sequential read" e "db file scattered read".
- Por causa do User I/O, vamos para "SQL ordered by Gets". O campeão é um Job (SQL ID bvrm2h6wh30gj), que em apenas 2 execuções consumiu 24.52 % do User I/O. O segundo colocado (SQL ID gmnq2nhcn1923) é um SELECT, com HINT. O 3o colocado é outro Job. A seção "SQL ordered by Reads" mostra praticamente os mesmos Jobs e SELECTs Tem que partir para SQL Tuning destes itens.
- Em "Segments by Logical Reads", a tabela TVRDTCT é responsável por 23.30% do I/O. Seria uma boa candidata para ir para um disco mais rápido, mas a TABLESPACE chama-se DEVELOPMENT... (?).
- Em "init.ora Parameters", O parâmetro "commit_write" está em "IMMEDIATE, NOWAIT". Conhece o perigo a respeito deste parâmetro? Se não, leia aqui: http://nervinformatica.com.br/blog/inde ... em-nowait/

Pcsilva

Re: Análise de AWR

Post by Pcsilva » Wed Feb 07, 2018 7:00 pm

Pois é!

Essa é a maravilha em um ambiente que foi construído sem DBA! :(

Somente após terem problemas eles consideraram a questão de ter um DBA administrando, e seria redundante dizer quem deu o nome da tablespace DEVELOPMENT?
A Primeira coisa que perguntei foi sobre o upgrade e alegam que o ERP não suporta.

Muito obrigado pelas considerações ,
Irei questionar fortemente o commit nowait e ver o que me falam.

Obrigado.

portilho
Site Admin
Posts: 482
Joined: Wed May 29, 2013 8:51 am

Re: Análise de AWR

Post by portilho » Wed Feb 14, 2018 7:02 am

Um banco com Desenvolvedores e sem DBAs é como um carro de corrida com pilotos e sem mecânicos. Funciona muito bem, por um tempo.
Nos avise de qualquer novidade se puder. :-)

Post Reply