Análise 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.

Análise AWR

Mensagempor portilho » Dom Ago 25, 2013 1:09 pm

Enviado por Cesar Moraes.

Cabeçalho (o cabeçalho nos ajuda a conhecer o ambiente, saber onde estamos pisando):
- Vemos que está na versão 11.2.0.2, mal sinal. Atualize rapidamente para 11.2.0.3, último PSU.
- Não é RAC, então só precisamos analisar esta instância.
- É um servidor grande (24 Cores e 125.85 GB de RAM) para o tamanho da memória utilizada por esta instância (7 GB). Então precisamos saber se este servidor é compartilhado com outras instâncias, o que pode alterar toda a análise. Devemos ver também se trata-se de uma virtualização, devido a quantidade estranha de RAM Total.
- O período analisado são 30 minutos, excelente para conseguirmos encontrar alguma causa específica.
- A quantidade de sessões conectadas é de mais ou menos 200, um servidor com boa utilização.

Wait Events:
- direct path read é o maior gargalo, de longe.
No "PGA Memory Advisory", vemos que hoje temos 1,696 MB de PGA (na coluna "Size Factr", na linha com valor 1.00), e se a aumentarmos em 20% (Size Factr 1.20), as leitruas e gravações em disco temporárias serão reduzidas de 1,195,461.37 para 835,308.01, uma quantidade não tão grande, mas viável pela pouca memória envolvida.
Mas não fiquei satisfeito com esta análise, e fui até os comandos SQL ("SQL ordered by ..."). Rapidamente vemos que o SQL_ID "3twygyr19x3h8", executado 2,544 no período analisado (apenas meia hora), é responsável por 25.27% de "Elapsed Time", 15.84% de "CPU Time", 47.26% (!) do "User I/O Wait Time", e ainda 69.28% (!) de "Reads". Observado seu código, vemos que deve ter vindo de um framework Java de contrução automática de SQLs. Então, este seria meu candidado para análise de Tuning.
Olhando em "Segment Statistics", vemos que uma tabela chamada "HYDRA_CONVERSATION" (este nome HYDRA aparece no SQL que falamos anteriormente) é responsável por 69.23% das leituras físicas, o que reforça nosso diagnóstico anterior, de que SQL é o maior consumidor de recursos. Em outras categorias do "Segment Statistics", esta tabela quase sempre é a maior ofensora.

Final
Os parâmetos no final do AWR nos ajudam a entender melhor o cenário analisado, e conhecer um pouco da "história" do banco de dados.
Algo que chama a atenção é o parâmetro "compatible" em 11.1.0.0.0, seria algo que eu perguntaria para o arquiteto sobre a razão desta alteração. O "optimizer_features_enable" está em 10.2.0.4, pode ser pela mesma razão.
Vemos também que o "memory_max_target" é maior que o "memory_target", porque estaria assim? O servidor estava utilizando swap, e/ou ele é compartilhado com outras instãncias?
Vemos também a alta quantidade de "processes" configurada, e que o parãmetro "optimizer_index_cost_adj" teve seu valor alterado para tender mais a utilizar índices do que FTS.
Anexos
AWR_REPORT.html.zip
(83.1 KiB) Baixado 190 vezes
portilho
Site Admin
 
Mensagens: 436
Registrado em: Qua Mai 29, 2013 11:51 am

Voltar para Workshop Análise de AWR

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron