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/
