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

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.

Mensagem Sáb Jul 27, 2013 4:14 pm
portilho Site Admin

Mensagens: 439
Enviado pelo usuário lmane.
AWR em anexo.
Anexos
awrREPASI220713.zip
(42.65 KiB) Baixado 201 vezes

Mensagem Qui Ago 01, 2013 4:08 pm
portilho Site Admin

Mensagens: 439
Cabeçalho
- Versão 11.2.0.1, a primeira do 11gR2. Extremamente cheia de Bugs. Faça Upgrade o mais rápido possível para o Patchset 11.2.0.3, PSU 11.2.0.3.7.
- Esta máquina possui várias instâncias? Se não, a memória para o Oracle (4 GB) está extremamente cautelosa para um servidor de 32 GB.
- Apenas 1 hora de análise, acho uma boa amostragem.
- A quantidade média de sessões está próxima de 50, uma carga que parece ser baixa.

Wait Events
O maior evento (devemos olhar ao mesmo tempo "Foreground Wait Events" e "Background Wait Events") é "db file sequential read" (575 segundos), seguido de perto por "read by other session" (504), sendo que este geralmente é consequência do primeiro.
O "db file sequential read" ocorre quando um bloco de índice é lido, quando um bloco de dados ou índice é lido do DB_CACHE_SIZE, ou durante a leitura do final de um Extent em um FTS. Como a Wait de FTS (db file scattered read) é irrelavante (35 segundos), a causa deve ser a 1a ou 2a opção.
Bem, a correção mais fácil para eventos de User I/O é o aumento do DB_CCHE_SIZE. Vamos então até o "Buffer Pool Advisory", que mostra que hoje este ambiente tem 1.072 MB de DB_CACHE_SIZE (se oriente pela coluna "Size Factor", e então pela "Size for Est (M)": o "Size Factor" 1.0 é o que você tem hoje). Se você aumentar seu DB_CACHE_SIZE em 79% ("Size Factor" de 1,79, a última linha), suas leituras físicas (coluna "Est Phys Read Factor") serão reduzidas em 52% ("Est Phys Read Factor" de 0,48)! Uma melhora linear, excelente, o que leva a crer que a causa do "db file sequential read" (e portanto do "read by other session") seja leitura de índices em disco.
Se aumentar o DB_CACHE_SIZE não for uma opção, vamos ver se é possível uma segregação do I/O. Descendo ate "Segments by Logical Reads", vemos que a tabela "BP_DEPRECIACAO" é responsável por 51,68% (!) das operações de LIO (Logical I/O), e logo abaixo, em "Segments by Physical Reads", vemos que esta mesma tabela é responsável por 35,02% das leituras físicas. Portanto, esta tabela é uma excelente candidata para ir para um I/O melhor (por exemplo, um disco SSD).
Se a melhoria do I/O não for uma opção, vamos para os SQLs. Em "SQL ordered by Gets", vemos que os primeiros 5 SQLs são muito parecidos, e cada um é responsável por exatamente de 10,48% dos Gets (coluna "%Total"). Curiosamente, todos, exceto o 1o deles, tem exatamente a mesma quantidade de 6.425.564 "Buffer Gets" e "Gets per Exec", e todos foram executados apenas 1 vez nesta hora analisada (coluna "Executions"). Ou seja, é o mesmo SQL com alguns valores da cláusula WHERE diferentes. Este SQLs seria nosso candidato para otimização, e os SUMs que vejo nele me levam a indicar, em uma análise rápida e suja, a criação de uma Materialized View ou mesmo apenas a ativação do Result Cache.

Final
- Nos parâmetros ni final do AWR, vejo um valor de PROCESSES de 1500 e o SESSIONS em 2304, o que não é um problema, só é estranho ser bem maior que a quantidade de sessões da hora analisada. Talvez em outro horário, ou outro dia, esta quantidade seja muito maior.
- Nesta seção também vejo que o banco têm 3 CONTROLFILEs no mesmo disco, o que não é uma boa prática, mas pode ter sido a única opção.
- Foi nesta seção também que vi o memory_target em 4 GB.

Mensagem Sáb Ago 24, 2013 9:25 pm

Mensagens: 0
Ricardo muito obrigado pelo analises, vou começar a tentar corrigir conforme as indicações. Obrigado :P

Mensagem Dom Ago 25, 2013 10:25 am
portilho Site Admin

Mensagens: 439
:-D

Mensagem Dom Nov 17, 2013 10:21 pm

Mensagens: 0
Portilho,

Achei muito interessante sua análise, vi esse relatório e achei umas coisas nela, veja se estou certo:

Vendo "Instance Efficiency Percentages (Target 100%)", me chamou atenção algumas métricas:

% Non-Parse CPU:
Soft Parse %
Library Hit %:
Execute to Parse %:

As métricas me parece que está um tanto quanto a quem do que deveria ser, isso pode ser falta de memória na shared pool, provavelmente por consequência do parâmetro memory_target (se aumentar memory_target resolveria!!)

Isso também pode ser percebido na PGA, parece que está um tanto quanto a quem do valor ideal.

Concorda?

Mensagem Qui Nov 21, 2013 2:43 pm
portilho Site Admin

Mensagens: 439
Oi.

O ponto de início da análise sempre são as Waits.
Como não há Waits relevantes a respeito de compilação (latch: Shared Pool, latch: Library Cache), não faz sentido analisar o Parse.
Pode ser que este sistema faça apenas Hard Parse, mas pode ter executado apena 1 SQL durante todo o período da análise.


Voltar para Workshop Análise de AWR

cron