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
Análise de relatório statspack
Re: Análise de relatório statspack
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.
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.
-
mtorres
Re: Análise de relatório statspack
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;
* 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.
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;
* 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.
Re: Análise de relatório statspack
Ok!
Por favor, me dê notícias assim que mudar algo... ou se não mudar.
Por favor, me dê notícias assim que mudar algo... ou se não mudar.