quarta-feira, 1 de janeiro de 2014

Investigando a lentidão do banco de dados da Oracle


Muitas vezes, o DBA poderá enfrentar um cenário em que o desempenho banco de dados Oracle apresentará lentidão. Neste artigo daremos uma ideia ao DBA por onde começar as verificações no banco de dados, a fim de monitorar e/ou corrigir o ambiente.

Podem existir muitas razões pelas quais o banco de dados pode apresentar um desempenho ruim. Para investigar um problema de desempenho, deve-se considerar as seguintes perguntas para tomar a ação apropriada.


Se o banco de dados está lento - o problema é constante ou pontual?

Se for um problema constante

Gerar um relatório do AWR ou do Statspack, dependendo da versão do banco de dados. Coletar as informações por um período de tempo em que ocorre o problema.

Se possível gerar um relatório de histórico que cubra a mesma hora do dia e o período em que o desempenho melhora para ajudar na identificação do problema.

Se for um problema pontual (algumas vezes)

Gerar um relatório do AWR ou Statspack dentro do período de tempo em que o problema ocorre (Por exemplo, se o problema ocorre entre às 12hs e às 15hs, o ideal é que seja gerado um relatório com um período de uma hora antes e uma hora depois do problema, para esse exemplo o período do relatório seria das 11hs às 16hs) .

É interessante gerar um relatório do AWR ou Statspack, num período igual período de tempo, quando o problema não ocorre. Com esses relatórios será possível realizar uma comparação - por exemplo , a mesma hora do dia ou a mesma carga de trabalho.

NOTAS IMPORTANTES

1.     É interessante que os relatórios tenham intervalos de no mínimo 10 minutos e no máximo de 30 minutos. Períodos mais longos podem distorcer as informações. Para os relatórios de AWR uma hora é aceitável.

2.    Muitas vezes, é interessante inicialmente gerar um relatório ADDM com o objetivo de obter sugestões dos principais problemas de desempenho a serem resolvidos. A partir do relatório ADDM pode-se encurtar soluções imediatas.

3.    Se o desempenho do SQL for a causa da lentidão em seguida, deve-se gerar um relatório ASH no mesmo período. Se um SQL específico é suspeito de lentidão , em seguida, executar um relatório ASH apenas para que a consulta identificada e também deve-se utilizar o SQLTXplain para diagnosticar os problemas identificados e ver mais detalhes.

Se o banco de dados estiver lento - E o problema afeta uma sessão, várias sessões ou todas as sessões?

Se for UMA SESSÃO - Gerar o "trace" com o evento - 10046 para a sessão;
Se forem VÁRIAS SESSÕES - Gerar "trace" com o evento - 10046 para o rastreamento de uma ou mais sessões;
Se forem TODAS AS SESSÕES - Gerar o relatório de AWR ou Statspack.

Se o banco de dados trava - Será que uma determinada sessão trava, várias sessões ou todas as sessões de travam?

Deve-se verificar os seguintes diagnósticos de acordo com o cenário específico:

Quando apenas UMA sessão parece estar  "travados".

Gerar o trace com o evento 10046 para a sessão específica;
Obter alguns "errorstacks" para a sessão específica;
Gerar um relatório de AWR ou Statspack por um período de tempo em que ocorre o problema.

Quando mais de uma sessão parece ser  "travadas"

Gerar o trace com o evento 10046 para a uma ou mais sessões que estão apresentando o problema;
Obter alguns "errorstacks" para uma sessão ou mais sessões que estão apresentando o problema;
Gerar um relatório de AWR ou Statspack por um período de tempo em que ocorre o problema.


NOTA FINAL

As siglas citadas no texto, estão descritas abaixo:

ADDM
Automatic Database Diagnostic Monitor, ferramenta que monitora e diagnostica o desempenho do banco de dados;
ASH
Active Session History, ferramenta que apresenta o histórico de uma sessão "ativa" no banco de dados;
AWR
Automatic Workload Repository, ferramenta que armazena as atividades e estatísticas gerais do banco de dados;
SQLTXplain
Ferramenta para diagnosticar problemas de desempenho em consultas SQLs;
Statspack
Ferramenta de monitoração do desempenho do banco de dados, predecessora ao AWR, para versões anteriores ao Oracle 10g.


Referências: Oracle® Database Administrator´s Guide 11gR2 (11.2)
         Oracle® Database Concepts 11gR2 (11.2)
         Oracle® Database Performance Tuning Guide 11gR2 (11.2)




MSc. Rubens Oliveira
DBA Oracle Consultor
olivert.dba@consultant.com