Menu de navegação

[msantinoParticipante]

Fala pessoal, blz?

To querendo fazer um update statistics de uma base, porém o cenário está um pouco desencorajador pra isso! rs…

A base possui cerca de 1550 schemas/usuários e ninguém faz idéia da data da última atualização das estatísticas. Possivelmente deve ter cerca de 1 ano ou coisa assim…

Minha idéia era rodar um dbms_stats.gather_database_stats(), porém, não sei a melhor forma de parametrizar diante desse cenário.
Experimentei deixar rodando normal, sem passar nenhum parâmetro mas já faz mais de 48h que está rodando e tenho receio de não terminar “nunca”! rs…

Pensei também que talvez fosse mais útil fazer uma rotina que rode alguns schemas por dia (durante a madrugada) pra não onerar tanto o banco e não ficar algo muito extenso. Como são muitos schemas, poderia fazer tipo 20, 50 ou até mesmo 100 por dia dependendo da demora que cada um rodar.

O que vocês me indicariam nesse caso?

vlw pessoal

[rmanParticipante]

@msantino

Qual a versão do Oracle ?

[msantinoParticipante]

10g (10.2.0.2) em Linux (Red Hat)

[rmanParticipante]

@msantino

Acho que a estatística não está tão desatualizada quanto você imagina, no Oracle 10g existe job agendado que faz a coleta de estatística, me parece que no 11g esse job não existe, ai sim tem que se pensar como fazer a coleta.

Verifique se o job está habilitado, e veja a ultima execução.


SELECT *
FROM DBA_SCHEDULER_JOBS
WHERE JOB_NAME = 'GATHER_STATS_JOB'


[msantinoParticipante]

@rman,

Eu tinha visto essa parada já. O problema é que esse JOB consta como última duração de 3 minutos. Impossível a atualização full desse banco levar esse tempo, já que ele tem mais de 60GB. Bancos menores que esse levam mais tempo que isso…

Dá uma olhada nesse artigo http://www.dba-oracle.com/t_gather_stats_job.htm. Isso reforça a minha teoria de que esse JOB faz uma simples verificação superficial de algo que eu não sei explicar! hahahaha

Mas que não faz o trabalho pesado e completo…

Por isso queria fazer a atualização ou da base inteira ou dos schemas por grupos…

Que acha?

[rmanParticipante]

@msantino

Só para confirmar, verifique o LAST_ANALYZED:


SELECT *
FROM DBA_TABLES


Essa questão de atualizar as estatísticas é uma coisa muito delicada, se não souber o que está fazendo é melhor não fazer, o tiro pode sair pela culatra, o desempenho pode cair ao invés de aumentar.

Pergunta, qual é o problema inicial que você quer tratar atualizando as estatística ?

[msantinoParticipante]

@rman,

Semana passada gerei algumas estatísticas pelo AWR e listou alguns índices com % de leitura muito baixos. A princípio ia mandar um rebuild nesses índices mas como não é feito um update estatistics nessa base achei mais válido antes de mandar o rebuild rodar essa rotina.

A data do LAST_ANALYZED estava null em 100% das tabelas de usuários.

Como o gather_database_stats() está rodando há 2 dias, nesse momento muitas delas estão com data de ontem e hoje. E gradativamente aumentando… mas o resto continua null

[msantinoParticipante]

@rman,

Meu filtro estava errado.

São 937.574 tabelas de usuários no total.
402.089 delas possuem LAST_ANALYZED de mais de 6 meses ( 2011-12-10 (quando o meu analyze começou).

O resto está NULL.
MES TOT TABELAS
2011-12 492.995
2011-11 19.107
2011-10 5.725
2011-09 2.904
2011-08 7.573
2011-07 4.508
2011-06 1.856
2011-05 21.026
2011-04 8.506
2011-03 369.745
2008-12 1
2008-03 222

[rmanParticipante]

@msantino

O fato de o LAST_ANALYZED estar nulo em schemas de usuário está estranho.

Mas o fato de o índice ter pouca leitura ou nenhuma está relacionado a aplicação. Segue um artigo sobre monitoramento de índice, acho que vale a pena dar uma olhada:

http://mytracelog.blogspot.com/2011/09/ … racle.html

Se o índice não for utilizado é recomendado remove-lo. Lembre-se também que existe a possibilidade de um mal planejamento na criação do índice, isso explica a baixa leitura.

[rmanParticipante]

@msantino

Lembrei de um detalhe, o job GATHER_STATS_JOB ignora tabelas que não houveram muitas modificações, por isso tem tabelas analizadas a 6 meses atras. Imagine uma tabela estática, foi inserido tuplas mas depois nunca mais houve modificações.

[msantinoParticipante]

Pois é @rman, to ligado nisso, mas eis a questão: Para os índices serem devidamente utilizados, é necessário que o otimizador tenha as estatísticas atualizadas do banco, caso contrário de que adianta o índice estar bem construído?

Por outro lado, de que adianta você possuia as estatísticas atualizadas do banco se seus índices estão completamente fragmentados? Nesse caso, o ideal seria rodar um rebuild deles.

Ainda assim existe a opção de ser mal planejamento dos índices pelo desenvolvimento (maior hipótese de todas! rs…)

Mas como podemos ter certeza de qual será esse fator se temos um ambiente completamente “largado”?

Por isso optei por atualizar as estatísticas pra eliminar uma possibilidade. Depois o próximo passo é fazer um rebuild/reorg dos índices de acordo com as estatísticas de utilização.

Aí sim, no final vou poder concluir que era um dos 2 problemas ou então, jogar a bola pra estrutura dos índices.

Tá errado esse raciocínio?

[msantinoParticipante]

Maneiro esse link e essa forma de ver os índices usados. Mas seria necessário um tempo de monitoramento muito longo pra concluir quais índices são de fato usados ou não.

Dá uma olhada no resultado que eu postei na minha mensagem acima. São mais de 930 mil tabelas distribuídas em mais de 1500 usuários. Complicado escolher quais índices ou schemas vou monitorar. rs…

[fabiogaleraParticipante]

Vamos lá.

No 10g, por default existe sim um job que faz a coleta das estatisticas automaticamente, mas ele esta como GATHER AUTO (se não me engano).

Existe várias maneiras de se fazer a coleta, com as opções abaixo:

GATHER = Vai coletar tudo;
GATHER STALE = Apenas coleta estatisticas de objetos que tiveram alteraçãp de 10% das linhas;
GATHER EMPTY = Coleta estatisticas para as tabelas que possuem a coluna LAST_ANALYZED nula.
GATHER AUTO = Oracle vai decidir o que é melhor para cada tabela.

Dai caso você queira colegar em partições das tabelas, tem a opção granularity.

Para coletar os indices precisa especificar cascade = true;

Quanto ao fato da melhor forma para coletar isso, hehehe, a melhor forma era não deixar isso acontecer =).

Outra coisa que você precisa verificar é se histogramas é necessário, caso não, você já reduz pela metade o tempo hehe.

Mas vamos lá, você possui saídas até:

1-) Usar o ANALYZE TABLE

<

table> COMPUTE STATISTICS;
obs: Como você esta na versão 10g, o Oracle ainda utiliza estatisticas do ANALYZE para o CBO (optimizer), isso é útil para quando temos problemas de performance. Porém, isso é um calculo aproximado, o Oracle não irá calcular realmente as estatisticas, apenas irá fazer um valor aproximado, podendo ser BOM ou RUIM.

2-) Utilize PARALLEL (DEGREE option) no DBMS_STATS. Irá executar mais rápido, como óbvio =)
DEGREE=DBMS.AUTO_DEGREE <= Melhor opção;

[mpvargasParticipante]

Caros amigos,
gostaria de uma ajuda pois já não sei mais o que fazer…
já abri um tópico semelhante a um tempo atrás e chegamos a conclusão após um longo bate papo que o problema da minha base era o ERP…
pois bem… o tempo passou, o ERP continua e voltei a ter problemas com lentidão em alguns processos…
Gostaria de uma ajuda para tentar minimizar o meu problema.
Obrigado.

[rmanParticipante]

@mpvargas

Identifique quais processos são, dependendo como foi feito o gargalo pode estar no banco ou na aplicação. Se o gargalo for no banco, você verá o SQL nas principais atividades no enterprise manager. Analise o plano de cada SQL, consulte também o relatório ADDM.

[Autor]

Posts