Menu de navegação

[Henrique GuelfiParticipante]

Realizamos a migração do nosso servidor de banco de dados para uma nova máquina, onde a versão que utilizávamos era a Oracle Database 11g Release 11.2.0.2.0 – 64bit Production, e trocamos pela Oracle Database 11g Release 11.2.0.4.0 – 64bit Production.

No dia da migração, o banco apresentou lentidão nas principais atividades dos usuários. Até então acreditávamos que se melhorasse a estrutura dos SQL’s, os processos iriam voltar a sua normalidade, no entanto isto não aconteceu.

Quanto mais o tempo passava, mais processos ficavam lentos, foi então que começamos a pensar que não se tratava de problema no sistema e sim algum problema de configuração do Oracle, ou até mesmo a falta das estatísticas.

Encontramos um comando que força a coleta das estatísticas do banco:
ANALYZE TABLE TABELA COMPUTE STATISTICS;

Começamos a executá-lo nas principais tabelas do sistema, onde a princípio nosso problema havia sido resolvido.

No entanto estamos enfrentando problemas com algumas tabelas, onde executamos o comando acima e elas voltam a responder rapidamente, porém, pouco tempo depois elas voltam a ficar lentas.

Gostaria de saber se há algo mais que posso fazer para as tabelas pararem de ficar lentas?

[José Laurindo ChiappaModerador]

Bom, antes de mais nada entenda o Conceito : o otimizador de SQL do RDBMS Oracle na hora que recebe um SQL qualquer, para descobrir o melhor método de execução (tipo, se vale mais a pena usar o índice X ou o índice Y, se na hora de reunir dados de múltiplas tabelas numa só query é melhor ler as linhas todas de uma e depois as linhas das outras, ou se é melhor uma linha por vez, enfim) o RDBMS *** tem que ter informações de volume ***, como quantas linhas existem para o valor-chave A num índice, quantas linhas existem para o valor B na tabela, e coisas assim….
Sim, se depois que ele fez o último levantamento desses volumes de dados as tabelas já sofreram Toneladas de INSERTs carregando novos dados, então SIM, por trabalhar com informações defasadas o Otimizador pode sim usar um índice impróprio, ler tabelas numa ordem não-ótima, ‘pensar’ que uma determinada tabela é ‘pequena’ quando na verdade depois das últimas cargas ela ficou ‘grande’…. Isso PODE SIM acontecer, mas imho ANTES DE MAIS NADA eu *** RECOMENDO FORTEMENTE *** que vc acione um DBA ** especializado ** em RDBMS Oracle, de modo que essa DBA VERIFIQUE E TESTE se é esse mesmo o problema – como eu disse é possível que sejam estatísticas defasadas MAS Não é Nada Impossível que essa ‘lentidão’ que vc vê seja decorrente de Outros Problemas…. Compreendido ???

===>>>> DEPOIS que o Especialista COMPROVAR que realmente o problema está sendo causado por estatísticas defasadas, sua próxima tarefa será identificar QUANDO as cargas de dados adicionais que deixam as estatísticas defasadas estão acontecendo E então acionar os procedimentos de coelta de estatística do RDBMS Oracle – entre muitos, um desses procedimentos é o JOB de banco chamado GATHER_STATS_JOB, que pode ser configurado para disparar na frequência que vc quiser….

Via de regra as cargas de dados na maior parte das Empresas acontece à noite, depois que os usuários deixam de usar os Sistemas da Empresa, então muitas vezes o pessoal costuma agendar esse JOB pra rodar de madrugada, mas isso Não É uma norma : como eu disse, UMA VEZ PROVADO que o problema dessa ‘lentidão’ é com 100% de certeza estatísticas defasadas, só AÍ que vc vai estabelecer data/hora para a coleta acontecer : o mesmo DBA especializado que te ajudou na análise da lentidão (E EXTRAIU os planos de Execução dos SQLs lentos), pode te ajudar nos detalhes de como estabelecer uma rotina de coleta automática periódica….

[]s

Chiappa

[C-S-RParticipante]

Opa Henrique blz?

Man pq vc esta usando o Analyze?
Acredito que o DBMS_STATS seja uma opção melhor de coleta de estatísticas.

Acredito que a melhor maneira de solucionar o problema e encontrar o gargalo, pq as querys estão lentas. Pode ser um plano ruin, falta de index ……..

Vcs verificaram se as configurações dos 2 servidores estão iguais?

[Henrique GuelfiParticipante]

Boa tarde,

Obrigado pela ajuda.

Então utilizávamos o Analyse porque foi a primeira opção que tivemos para tentar resolver o nosso problema, já executamos o DBMS_STATS porém obteve o mesmo comportamento e pouco tempo depois voltou a ficar lento.
Com relação aos index, estão todos corretos e sendo utilizados.
Quando realizamos uma consulta nas tabelas com problemas ele executa instantaneamente, porém operações como de Insert, Update e Delete ficam muito lentas, sendo resolvida somente quando executamos o DBMS_STATS ou ANALYSE.
Um outro caso que está acontecendo, é que se executarmos a procedure no SQL *PLUS, ela executa instantaneamente, porém se executarmos no PL/SQL Developer ela demora a executar, então coletamos as estatísticas com DBMS_STATS e ambas as execuções voltaram ao normal, porém pouco tempo depois a lentidão voltou, só que desta vez ao contrário, no SQL *PLUS lento, mas no PL/SQL instantâneo. Estamos nesse ciclo.

Com relação as configurações, as do Oracle continuam iguais, somente o Hardware que está diferente em uma máquina superior.

[José Laurindo ChiappaModerador]

Realmente, pelo que vc descreve até pode ser sim estatísticas defasadas, então REPITO : o primeiro Passo que vc VAI ter que fazer (provavelmente com a ajuda de um DBA especializado em Oracle) é *** OBTER *** os planos de Execução numa situação em que a execução é ‘rápida’ e numa em que a execução é ‘lenta’ E os comparar (descobrindo assim se é um índice que não está sendo usado, se ele está optando por acesso via LOOP em uma tabela ao invés de HASH TABLE, ou seja o que for)… Um dos MUITOS métodos que o DBA dispõe para isso é a package DISPLAY_CURSOR, veja http://allthingsoracle.com/execution-plans-part-1-finding-plans/ e https://oracle-base.com/articles/9i/dbms_xplan (além da DOCUMENTAÇÃO, óbvio) para refs….

TAMBÉM pode ser caso de espera (espera por LOCKs, por gravação de controlfile, por checkpoint, enfim), então eu recomendo Fortemente que (ainda com a ajuda de um DBA) vc obtenha Listagens de eventos de espera quando a execução está ‘rápida’ e quando a execuão está ‘lenta’ : SE vc tiver a Licença de uso necessária para tal, vc pode usar a tool nativa do Oracle chamada AWR (http://blog.orapub.com/20150602/how-to-create-awr-report-wait-event-based-histograms.html é um exemplo) ou se não tiver acesso/licença de uso do AWR vc pode consultar repetidamente as views de performance enquanto as execuções rolam, veja https://www.pythian.com/blog/tuning-log-file-sync-event-waits/ para um exemplo…. É possível obter a mesma informação também via TRACE de sessão, https://oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof traz um exemplo…

===>> UMA VEZ CONFIRMADO que quando há a ‘lentidão’ vc tem planos de execução diferentes sendo gerados E que não há esperas por WAITs internos aí sim, a questão é automatizar a coleta de estatísticas…. Para isso, Como Eu Disse, o método mais comum é vc setar o JOB atualizador de estatísticas para rodar mais frequentemente…

[]s

Chiappa

[Autor]

Posts