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

Analisis 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 Seg Fev 10, 2014 4:03 pm

Mensagens: 0
Ricardo bom dia,
Por favor, poderiame ajudar com a interpretação do relatório AWR anexado.

Desde agradeço.

Ate,

Luis
Anexos
awrJCRDB10022014.zip
(44.92 KiB) Baixado 268 vezes

Mensagem Seg Mar 10, 2014 5:09 pm
portilho Site Admin

Mensagens: 463
Cabeçalho
O Oracle Database está atualizado (11.2.0.4), o que é uma boa notícia para começar a análise. É um servidor médio (2 Sockets x 6 Cores), mas a quantidade de memória é estranha (94.4 GB), trata-se se um servidor virtual?
A coleta trata de apenas uma hora da manhã, e as sessões começaram em 57, e chegaram às 10:00 com 102, o que indica que o dia comercial devia estar começando.

Wait Events
Em "Foregroung Wait Events", a maior é "log file sync", mas são apenas 5 segundos gastos em uma hora, ou seja, irrelevante. E em "Backgroung Wait Events" a maior é "log file parallel write", com apenas 4 segundos, também irrelevante. Ou seja, não tinha praticamente nada acontecendo neste servidor. E pela seção "Operating System Statistics" não parece ter outra instância em atividade de produção nesta máquina (IDLE_TIME de 8,307,227 x USER_TIME de 174,046)

Parâmetros
O db_recovery_file_dest_size está com apenas 5GB, o que parece um espaço muito pequeno para a geração de Archives.
O memory_max_target está com apenas 4GB, despediçando muito a memória da máquina, a não ser que existam outras instâncias. O memory_target está menor que o memory_max_target, o que não faz sentido.
O número de sessions parece perigosamente baixo (360), já que vimos mais de 100 sessões na instância no início da manhã.

Conclusão
O ambiente parece precisar de uma boa revisão de parâmetros, e não apresenta nenhum gargalo, a não er que o horário de coleta não tenha sido bem escolhido, ou o ambiente ainda não esteja em completa produção.

Mensagem Seg Mar 10, 2014 7:53 pm

Mensagens: 0
Boa tarde Ricardo,
Antes de tudo agradeço pelo retorno.
O servidor é uma máquina física e possui 96G de RAM. O horário do snapshot foi entre as 9 e 10 da manhã porque teoricamente seria o tempo de maior uso da aplicação.
Este servidor é novo, pois recém migre 24 base de dados para este servidor, foi ai, que aproveite e subi a versão do Oracle para 11.2.0.4.
Pelo fato de ter 24 bases de dados é que o parâmetro memory_max_target esta com 4G. Deixe o memory_max_target maior que o memory_target, porque segundo tenho entendido me permitiria aumentar o memory_target até o valor da memory_max_target sem necessidade de baixar a instancia. Mas ao parecer não seria uma boa pratica?
Recém foi migrada a base e ainda não esta em modo de archivamento, por esa razão ainda não mexi no tamanho do parâmetro db_recovery_file_dest_size. Os backups físicos são criados usando o RMAN e tem como destino outro disco.
Vou aumentar o numero de sesions e revisar alguns parâmetros conforme indica em sua conclusão.
Então, considerando que ninguém reclama da aplicação e que não apresenta wait events significativos e logicamente realizando suas recomendações, posso pensar que por enquanto é uma base de dados saudável?
Muito obrigado Ricardo pelo sua ajuada!!!


Att.

Luis

Mensagem Qua Mar 12, 2014 10:00 am
portilho Site Admin

Mensagens: 463
Ah sim, a máquina tem 96GB de RAM, não é o tamanho de memória mais usual, mas faz sentido.

Caramba, 24 bases de dados? como eu suspeitava, iso explicou a memória baixa para a instância. Funciona, mas a lentidão de uma pode impactar todas as outras.

A ideia do memory_target é justamente o contrário, você pode baixar sem precisar baixar a instância, se faltar memória na máquina. Se não, o memory_target mais baixo é apenas um desperdício.

Realmente, acho que este é um banco de dados saudável.

Mensagem Sex Mai 22, 2015 12:52 pm

Mensagens: 0
Localização: Santos/SP

portilho escreveu:
Cabeçalho

A coleta trata de apenas uma hora da manhã, e as sessões começaram em 57, e chegaram às 10:00 com 102, o que indica que o dia comercial devia estar começando.



Haveria uma forma de alterar a configuração/periodicidade na coleta destes dados, do job do AWR ?

Foi uma questão que foi levantada e estive procurando, como proceder neste caso.

Agradeço desde já se puder(em) enviar um passo-a-passo, detalhado.

Abraços.

Mensagem Seg Mai 25, 2015 10:18 am
portilho Site Admin

Mensagens: 463
Segue abaixo.
No exemplo, estou alterando para armazenar por 30 dias (retention, em minutos), coletar a cada 30 minutos (interval, também em minutos) e guardar os top 100 SQLs (topnsql).

Alteração de intervalo de coleta e retenção
$ sqlplus / AS SYSDBA
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
(retention => 43200, Interval => 30, topnsql => 100);
END;
/

Para visualizar as configurações, utilize a View DBA_HIST_WR_CONTROL.

Mensagem Seg Mai 25, 2015 1:57 pm

Mensagens: 0
Localização: Santos/SP

portilho escreveu:
Segue abaixo.
No exemplo, estou alterando para armazenar por 30 dias (retention, em minutos), coletar a cada 30 minutos (interval, também em minutos) e guardar os top 100 SQLs (topnsql).

Alteração de intervalo de coleta e retenção
$ sqlplus / AS SYSDBA
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
(retention => 43200, Interval => 30, topnsql => 100);
END;
/

Para visualizar as configurações, utilize a View DBA_HIST_WR_CONTROL.


OK, Grato por comentar. Vou implementar conforme sugerido, para checar os resultados...

Abraços

Mensagem Qua Mai 27, 2015 10:10 am
portilho Site Admin

Mensagens: 463
Ok !


Voltar para Workshop Análise de AWR

cron