Índice do fórum Workshops Workshop Análise de AWR Análise de AWR

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.

Mensagem Qui Dez 14, 2017 2:09 pm

Mensagens: 0
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,
Anexos
maior_load.zip
(66.82 KiB) Baixado 112 vezes

Mensagem Qua Jan 03, 2018 1:14 pm
portilho Site Admin

Mensagens: 463
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/

Mensagem Qua Fev 07, 2018 9:00 pm

Mensagens: 0
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.

Mensagem Qua Fev 14, 2018 9:02 am
portilho Site Admin

Mensagens: 463
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. :-)


Voltar para Workshop Análise de AWR

cron