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 leonardopedroso » Qua Dez 21, 2016 9:15 pm

Portilho,
Segue meu AWR para análise. Gerei num período de muita utilização do sistema, que é de 9:00 as 13:00!
Anexos
awrrpt_2_19287_19291.rar
(103.09 KiB) Baixado 71 vezes
leonardopedroso
 
Mensagens: 0
Registrado em: Dom Nov 20, 2016 2:58 pm

Re: Análise AWR

Mensagempor portilho » Qui Dez 29, 2016 3:16 pm

- É uma máquina respeitável, 40 Cores e 1TB de RAM. E como é um RAC, uma análise completa teria que ver o AWR Global e o da outra instância também.
- A relação de Elapsed (240 minutos) x Cores (40) está bem inferior ao DB Time, então não trata-se de uma lentidão generalizada.
- O Time Model mostra que 4.59% (ou 3.200 segundos) foram gastos em conexão. Não é um grande problema, mas é um ponto a verificar - a aplicação se conecta e desconecta?
- O Time Model mostra 61.35% em CPU, então temos menos que 40% em Waits.
- A maior Wait é "db file sequential read".
- A segunda maior Wait é "enq: TM - contention". Verificar se os SQLs que esperam por esta Wait utilizam objetos em índices em FKs.
- Por conta do "db file sequential read", vamos ver "SQL ordered by Gets". O SQL ID "hqr8au9f33na" é responsável por 13.63% deste tempo, e utiliza funções no WHERE (UPPER e REGEXP). O SQL ID "1fj89gknxssm3" é responsável por 9.33%, e também utiliza as mesmas funções. O SQL ID "5dusggy1790gk" é responsável por 3.78%, e utiliza as mesmas funções. Verificar se pode ser utilizado um índice de função, ou alterada a aplicação.
- Por conta dos 61.35% em CPU no Time Model, vamos ver "SQL ordered by CPU Time". O SQL ID "hqr8au9f33na" é responsável por 13.64% da CPU, e utiliza as mesma funções do item anterior. Veja que o SQL ID "agg4pny1wdy39" é responsável por 8.23% da CPU, mas parece ser uma aplicação a parte para monitorar sessões, liberar acessos, algo assim. O SQL ID "a5faspxq77v0r" é responsável por 8.05% da CPU, e pelo texto, e por ter sido executado exatamente a mesma quantidade de vezes do SQL ID anterior (35,012), deve ser utilizado pela mesma função. O SQL ID "1fj89gknxssm3" consume 4.81% da CPU e também utiliza as funções UPPER e REGEXP.
- O "Buffer Pool Advisory" não mostra ganhos expressivos em aumentar o Cache, e o "Segments by Logical Reads" também não tem um grande vilão. Ou seja, tem que trabalhar na aplicação mesmo.
- Não parece ser um problema, mas parece desnecessário um log_buffer de 256M.
- Não parece ser um problema, mas o CURSOR_SHARING está em SIMILAR, mas a aplicação parece utilizar BINDs. E o valor SIMILAR não é mais válido no 11gR2.
- Não parece ser um problema, mas porque o MEMORY_TARGET está menor que o MEMORY_MAX_TARGET? E por que o MEMORY_MAX_TARGET está em apenas 300GB, sendo que a máquina tem 1TB? Há outras instâncias no servidor?
- Não parece ser um problema, mas OPEN_CURSORS em 9000 é muito alto, outro indício de um problema (já corrigido ou não) na aplicação.
portilho
Site Admin
 
Mensagens: 436
Registrado em: Qua Mai 29, 2013 11:51 am

Re: Análise AWR

Mensagempor leonardopedroso » Qua Jan 18, 2017 8:25 pm

Portilho, obrigado pela análise, em relação aos itens:

- A segunda maior Wait é "enq: TM - contention". Verificar se os SQLs que esperam por esta Wait utilizam objetos em índices em FKs.
**vou localizar os SQL_ID com essa WAIT e analisar os objetos, índices e FK, é trabalho pra muito tempo.

- Por conta do "db file sequential read", vamos ver "SQL ordered by Gets". O SQL ID "hqr8au9f33na" é responsável por 13.63% deste tempo, e utiliza funções no WHERE (UPPER e REGEXP). O SQL ID "1fj89gknxssm3" é responsável por 9.33%, e também utiliza as mesmas funções. O SQL ID "5dusggy1790gk" é responsável por 3.78%, e utiliza as mesmas funções. Verificar se pode ser utilizado um índice de função, ou alterada a aplicação.
**Interessante esse índice de função, em um primeiro momento vou utiliza-lo para não ter que alterar a aplicação e ganhar tempo. É um plus que eu não conhecia, depois o time de dev altera a query.

E por fim a memória:
- Não parece ser um problema, mas porque o MEMORY_TARGET está menor que o MEMORY_MAX_TARGET? E por que o MEMORY_MAX_TARGET está em apenas 300GB, sendo que a máquina tem 1TB? Há outras instâncias no servidor?

** Só há 1 instância rodando no servidor, realmente o valor está baixo mesmo. Eu vou aumentá-los na próxima janela de manutenção. Os parâmetros setados são:

MEMORY_TARGET = 200G
MEMORY_MAX_TARGET = 300G
SGA_TARGET = 0
SGA_MAX_TARGET = 300G

A ideia seria aumentar para 800G, ficando assim:

MEMORY_TARGET = 800G
MEMORY_MAX_TARGET = 800G
SGA_TARGET = 0
SGA_MAX_TARGET = 800G

Teria mesmo a necessidade do SGA_MAX_TARGET estar com 800G? Por ser 11G eu poderia desconsiderar os dois parametros da SGA e deixar só os de memory?
leonardopedroso
 
Mensagens: 0
Registrado em: Dom Nov 20, 2016 2:58 pm

Re: Análise AWR

Mensagempor portilho » Qua Jan 25, 2017 11:22 am

Muito obrigado pelo retorno, sempre é mais produtivo para ambos os lados saber mais detalhes a respeito.

Pela quantidade de memória deveria ser utilizado HugePages, certamente. E isso proíbe o uso de MEMORY_MAX_TARGET / MEMORY_TARGET.
Eu colocaria 512em SGA_MAX_SIZE / SGA_TARGET, e 50GB em PGA, e acompanharia a memória livre do sistema operacional e uso da PGA (pela V$PGASTAT), e então planejaria um novo aumento se possível.
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