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

Análise de relatório statspack

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 Ter Fev 02, 2016 4:15 pm

Mensagens: 0
snap_174_176.rar
Single instance com alto consumo de CPU
(37.49 KiB) Baixado 145 vezes
Boa Tarde.

Portilho,

Por favor verifica esse relatório de nosso servidor. Após a migração do 10g para o 11g (11.2.0.4), o consumo de CPU está permanecendo em 100% e os usuários estão reclamando de lentidão nos sistemas.

Não consegui enxergar relação entre os waits e o consumo excessivo de CPU;
A migração foi realizada com expdp/impdp por esquema;
As estatísticas estão atualizadas;

Agradeço antecipadamente.

Atenciosamente,

Marcelo Torres

Mensagem Qua Fev 03, 2016 9:30 am
portilho Site Admin

Mensagens: 448
Oi Marcelo.

Sim, este sistema está muito lento.
O que nos mostra isto é: "Elapsed: 120.03 (mins)", e "DB time: 1,187.04 (mins)".

Este é seu problema: "cursor: pin S".

O autor referência em Oracle Tanel Pôder tem um script chamado LatchProfX, para ajudar a identificar a origem deste tipo de problema.
http://blog.tanelpoder.com/files/Oracle ... ooting.pdf
http://blog.tanelpoder.com/2010/02/15/n ... nd-tuning/

Veja aqui que um caso bem parecido com o sintoma de seu ambiente, alto consumo de CPU:
http://blog.tanelpoder.com/2010/04/21/c ... eshooting/

Algumas considerações sobre seu ambiente:
- O RESULT CACHE não devia estar em uso antes, pois foi lançado no 11g. Eu desabilitaria ele (de FORCE para MANUAL).

- As estatísticas do dicionário de dados também foram coletadas?
EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

-Se esta migração também foi para um novo servidor, as estatísticas de sistema também foram coletadas?
EXEC DBMS_STATS.GATHER_SYSTEM_STATS('START');
EXEC DBMS_STATS.GATHER_SYSTEM_STATS('STOP');

- Há algum motivo para este conjunto de parâmetros? Se não, deixaria ambos em 11.2.0.4.
optimizer_features_enable 10.2.0.4
compatible 11.2.0.4.0

- Não deve ter a ver com seu problema, mas a SGA_TARGET está mais baixa do que a SGA_MAX_SIZE. Há um motivo para isto?

- Claro que não tem nada a ver com seu problema, mas você tem apenas um CONTROLFILE.

Mensagem Qua Fev 03, 2016 3:51 pm

Mensagens: 0
Obrigado imensamente pela sua análise Portilho. Em Abril estarei ai para mais um treinamento...

Quanto ao ambiente:

* O Result Cache foi habilitado como teste, mas como não funcionou vou alterar para Manual;

* O servidor é o mesmo, apenas foi modificado o S.O de Win2008R2 para Win2012, mesmo assim as estatísticas foram atualizadas:
dbms_stats.gather_system_stats (gathering_mode => 'noworkload');
dbms_stats.gather_dictionary_stats ();
dbms_stats.gather_fixed_objects_stats (no_invalidate => false);

* O parâmetro optimizer_features_enable 10.2.0.4 foi alterado como sugestão de um fornecedor que presta suporte aqui na empresa. Vou retornar ao valor default;

* SGA_TARGET e SGA_MAX_SIZE estão com os valores que estavam no ambiente antigo, realmente não tem motivo para estarem diferentes; :oops:

* Os detalhes relacionados à multiplexação dos controlfiles e redologs foram postegados para após resolvermos os problemas de desempenho. :)

Outros detalhes do ambiente:

* Large Pages do Windows foi habilitado.
* O Oracle foi atualizado até o patch 22310544 (Windows DB Bundle Patch 11.2.0.4.160119);
* O servidor tem 02 processadores INTEL XEON E5-2660 de 8 Cores cada/16 Threads com 196 GB de memória.

Vou consultar as informações que você passou.

Mais uma vez obrigado.

Mensagem Qui Fev 04, 2016 8:05 am
portilho Site Admin

Mensagens: 448
Ok!
Por favor, me dê notícias assim que mudar algo... ou se não mudar.


Voltar para Workshop Análise de AWR

cron