Chiappa... perfeita explicação.... muito obrigado!

2009/9/14 jlchiappa <jlchia...@yahoo.com.br>

>
>
> Colega, é o seguinte : SIM, necessariamente e obrigatoriamente SE as
> estatísticas de um dado segmento foram coletadas corretamente ENTÃO a coluna
> LAST_ANALYZED da DBA_TABLES, DBA_INDEXES, etc TEM QUE estar atualizada,
> sim... No teu caso, porém, como vc usa o cacareco do GATHER_SCHEMA_STATS, o
> que a Documentação 10g correspondente (manual Oracle® Database Performance
> Tuning Guide 10g Release 2 (10.2), cap. 14 Managing Optimizer Statistics)
> nos diz é
>
> "The GATHER_DATABASE_STATS or GATHER_SCHEMA_STATS procedures gather new
> statistics for tables with stale statistics when the OPTIONS parameter is
> set to GATHER STALE or GATHER AUTO."
>
> OU SEJA, esse sujeito NÃO calcula/coleta estats de todo mundo, mas APENAS
> das tabelas que estiverem marcadas como MONITORING e que tem estats
> velhas(stale) - ie, sofreram mais de 10% de linhas alteradas/inseridas.
>
> Muito bem, sendo assim a primeira hipótese é que simplesmente esses
> segmentos que vc não vê a LAST_ANALYZED mudar ou não tiveram alterações
> nesse montante ou não estavam marcadas como monitoring...
>
> Uma segunda possibilidade é a seguinte : eu chamei o monstrengo de cacareco
> porque, ENTRE OUTRAS FALHAS, esse sujeito é SERIAL, ie, ele olha a tabela 1
> dum dado schema, só depois que acabou com ela aí ela passa pra tabela 2,
> assim por diante - num ambiente de Produção, isso é DESPERDÍCIO puro de
> servidor, é via de regra muito mais eficiente vc ter ao mesmo tempo uma
> sessão coletando stats da tabela A, junto com outra sessão na tabela B,
> outra na C... Muito bem, sabendo da ineficiência do GATHER_SCHEMA, pode se
> teorizar que talvez a coleta de estatísticas esteja demorando muito, e
> ultrapassando a JANELA reservada para a rotina, sendo portanto abortada, não
> indo até o final, por isso vc está vendo objs com LAST_ANALYZED não
> atualizado...
>
> É isso então, cheque ambas as possibiliaddes e veja aí o que está
> ocorrendo...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>, Luiz
> Antonio Camargo <luizla...@...> escreveu
> >
> > Quero emendar uma questão.
> >
> > Onde trabalho, não fui eu que montei o banco, e na verdade estou
> começando
> > agora a me responsabilizar por funções de DBA (que era terceirizado).
> >
> > O scipt de analise de tabelas está da seguinte forma:
> > exec dbms_stats.gather_schema_stats(ownname=>'PRODUCAO',degree=>
> > 4,cascade=>true,method_opt=>'FOR ALL INDEXED COLUMNS SIZE 1');
> > .. e se repete dessa forma para todos os "ownname" que temos no banco,
> > rodando diariamente durante a noite.
> >
> > Só que se verifico quando foram executadas as analises das tabelas,
> muitas
> > não têm a analise executada durante a noite, sendo que sempre aos finais
> de
> > semana, é quando ele analisa um maior volume de tabelas.
> >
> > Como é controlado isso? Imaginei que ele "analisava" a necessidade de
> rodar
> > o "analyze" na tabela antes de proceder isso.... é isso? ou tem algo
> errado
> > e todas as tabelas deveriam ter as datas de analise "atualizadas" no dic.
> de
> > dados.
> >
> > Desculpe, mas nem sei o que são os parametro. Sei que deveria dar uma
> > pesquisada antes, mas quis aproveitar a duvida do nosso amigo que é
> > relacionada ao mesmo assunto.
> >
> > Obrigado
> >
> >
> > 2009/9/14 Jean Carlo - Hotmail <jcthebrot...@...>
> >
> > >
> > >
> > > Com essa observação ai vai uma dúvida minha.
> > >
> > > Tem um cliente onde duas vezes ao dia é feita uma carga para uma tabela
> com
> > > 40mil registros sendo adicionado em cada carga.
> > >
> > > Com essa observação, devo coletar estatísticas novas para essa tabela
> cada
> > > vez que essa carga for feita??
> > >
> > > SO: Windows 2003.
> > >
> > > Banco: Oracle9i Enterprise Edition Release 9.2.0.5.0
> > >
> > > De: oracle_br@yahoogrupos.com.br 
> > > <oracle_br%40yahoogrupos.com.br><oracle_br%
> 40yahoogrupos.com.br> [mailto:
> > > oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br><oracle_br%
> 40yahoogrupos.com.br>] Em
> > > nome de jlchiappa
> > > Enviada em: segunda-feira, 14 de setembro de 2009 15:05
> > > Para: oracle_br@yahoogrupos.com.br 
> > > <oracle_br%40yahoogrupos.com.br><oracle_br%
> 40yahoogrupos.com.br>
> > > Assunto: [oracle_br] Re: Percentual de Crescimento em uma Tabela
> > >
> > > Escrevo de cabeça, mas iirc em lugar NENHUM a Oracle indica que as
> > > estatísticas devem ser consideradas stale obrigatoriamente com x% de
> > > mudanças nos dados, o que os manuais e os artigos do metalink a
> respeito
> > > falavam é que assim que for estatisticamente relevante a mudança, se
> deve
> > > fazer a coleta... Via de regra, o default de 10% que internamente o bd
> > > Oracle utiliza é bem razoável, penso que vc pode sem medo começar com
> > > ele...
> > > ÓBVIO, sempre frisando que estamos falando de OLTP aqui, num sistema
> > > DW/batch é óbvio quando calcular estats, é imediatamente DEPOIS da
> carga
> > > dos
> > > dados e antes delem serem usados...
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > --- Em oracle_br@yahoogrupos.com.br 
> > > <oracle_br%40yahoogrupos.com.br><oracle_br%
> 40yahoogrupos.com.br><mailto:
> > > oracle_br%40yahoogrupos.com.br <oracle_br%2540yahoogrupos.com.br>>
> > > , "Welvis Douglas" <welvis@> escreveu
> > > >
> > > > Olá pessoal, gostaria de saber se tem algum artigo ou documentação
> que
> > > diz
> > > > quando devo estar coletanto as estatisticas de uma tabela ?
> > > >
> > > >
> > > >
> > > > Alguem sabe de alguma coisa? Algum tempo ouvi algo em torno de 10%,
> 10%
> > > da
> > > > quantidade de linhas da tabela que fosse inc. ou deletada teria que
> > > coletar
> > > > as estatisticas.
> > > >
> > > >
> > > >
> > > > Alguem sabe me dizer se tem algum doc. Para fazer isso ?
> > > >
> > > >
> > > >
> > > > Att,
> > > >
> > > >
> > > >
> > > > Welvis Douglas
> > > >
> > > >
> > > >
> > > > [As partes desta mensagem que não continham texto foram removidas]
> > > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> > >
> > >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]

Responder a