Certo, Entendido! Parabéns pela dedicação em responder a lista com tanta dedicação!
To: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Sat, 15 Sep 2007 01:21:22 +0000Subject: [oracle_br] Re: Estatisticas / Histogramas / Outlines Éverton, primeiro sobre o uso de ANALYZE TABLE nn STATISTICS versusexecução da DBMS_STATS, isso é muito simples, via de regra deve serSEMPRE preferido o DBMS_STATS porque ele normalmente é maisperformático (pois pode ser paralelizado,entre outras coisas) ele é ocomando mais recente (pelo menos até a 9i não há que eu saiba, mas aqquer momento em tese podem haver estatísticas não coletadas pelocacareco do ANALYZE), é por essas & outras que nos manuais maisrecentes (9i em diante) a Oracle já recomenda a DBMS_STATS, podeconferir....Agora, avançando um pouco, a opção "FOR ALL COLUMNS SIZE 1" nadbms_stats gera histogramas (mínimos no caso mas gera), então deduzoque vc quer obter uma recomendação sobre se é conveniente ou não secoletar histogramas, e se mínimos ou não, com que tamanho deamostra.... A resposta só pode ser DEPENDE, como sempre : o fato é que** SE ** após a análise dos seus dados (que apenas ** VOCÊ ** podefazer, não é a gente daqui!) vc descobriu que nas maiores e maisimportantes tabelas as principais colunas mais usadas nos seus SQLstem distribuição de dados altamente irregular (veja, NÂO é umadiferença mínima, é alguma coisa estatisticamente significativa, tipopra uma ocorrência de valor na coluna há digamos 5 registros, praoutra ocorrência há 5 mil, coisa grande), ** ENTÃO ** sim, vale a penavc coletar histogramas. Quanto ao tamanho, isso depende dadistribuição em cada tabela, o ideal e recomendado(mais uma vez...) évc TER CONHECIMENTO dos seus dados pra saber quantos valores distintoshá nas colunas irregulares , sabendo isso se possível o ótimo seria vcusar essa quantidade como SIZE, mas além do limite máximo de 255 noSIZE do banco Oracle, essa coleta é computacionalmente ** CARÍSSIMA**, queima uma CPU lascada e faz I/O pracas, então muitas vezes vc temque aplicar um ponto de compromisso, testando tempo/esforço de coletaversus melhoria obtida nos planos com SIZE de 10, 30, 60, até achar umponto de equilíbrio razoável. Outra opção pra determinar SIZE é usar a opção de AUTO doGATHER_TABLE_STATS, com ela (usando um algoritmo próprio interno) obanco faz uns chutes educados e tenta após breve análise "adivinhar"um SIZE razoável, a opção é testar primeiro coletando todos oshistogramas que julgar necessário com SIZE AUTO, e apenas pros SQLsque não ficarem OK aí fazer o teste especificando SIZE manualmente....Quanto aos OUTLINES : eles nada mais são do que um montão de HINTs , esabemos sim que via HINTs vc pode sim influenciar um SQL pra obter omesmo plano, então ** SIMULAR ** vc pode (e não só com eles, mastambém via outros métodos, tal como "importando" as estatísticas deProdução em desenvolvimento), mas quase certamente essa "simulação",com aspas TOTAIS, vai ser MÁ e PORCA, a ** única ** maneira 100%garantida de vc testar a performance é ter um hardware IGUAL àprodução, rodando o MESMO SO, com carga (simulada que seja) o maisidêntica possível à produção, PONTO. A máquina de contingência daprodução seria uma boa pra isso...MAS SE por roça total vc tiver que ir fazer a tal "simulação", aomenos saiba que obter o mesmo plano em produção e em desenvolvimentoNÂO É garantia de obter a mesma performance, pois mesmo se vc obtiveracesso pelo mesmo índice X nas duas máquinas, ** EVIDENTEMENTE ** sehardware de disco é diferente, o TEMPO DESSE ACESSO pode (e muitoprovavelmente VAI) ser diferente... Uma vez lido, o dado TEM QUE serenviado pro cliente, e isso é feito PELA REDE, obviamente que se ohardware de rede for diferente, ** ou ** se a banda de rede estivercom consumo diferente nas duas máquinas, óbvio que o tempo pra issoVAI SER DIFERENTE!! ==> E o pior de tudo, o que normalmente INVALIDA "simulações" dessetipo : mesmo que vc obtenha planos IDÊNTICOS, um plano de execução écomposto por uma série de passos, SE na produção há muitos usuáriossimultâneos fazendo I/Os ao mesmo tempo, em produção logicamente obanco Oracle vai ter que enfileirar os "pedidos" e dar um pouco de"atenção" pra cada um, assim tranquilamente vc PODE ter a mesmavelocidade de I/O nas duas máquinas, o mesmo plano, MAS em produçãopelo fato de muitos outros usuários estarem sendo atendidos, entrecada passo haveria um WAIT palpável, uma vez atendido o seu passo doplano, a sessão teria que esperar os OUTROS serem atendidos também,pra só depois voltar à vez dela....[]sChiappa--- Em oracle_br@yahoogrupos.com.br, Everton Dias <[EMAIL PROTECTED]>escreveu>> > > Pessoal, qual a forma que vocês normalmente coletam estatisticas nobanco? > > Quero dizer, qual seria a melhor forma:> > - ANALYZE table owner.tabela COMPUTE statistics FOR table for allindexes;> ou> - execute DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => 'owner', TABNAME=> 'TABLE_NAME', CASCADE => TRUE, method_opt => 'FOR ALL COLUMNS SIZE 1');> > Ou até mesmo alguma outra forma ou combinação dos métodos? > > Uma segunda pergunta, Alguém já usou os tais outlines? Com outlineseu poderia usar em um banco de desenvolvimento as mesmas estatisticascoletadas em produção, a fim de simular a performance?> > Qualquer sugestão é bem vinda.> > __________________________________________________________> Encontre o que procura com mais eficiência! Instale já a Barra deFerramentas com Windows Desktop Search GRÁTIS!> http://desktop.msn.com.br/> > [As partes desta mensagem que não continham texto foram removidas]> _________________________________________________________________ Encontre o que procura com mais eficiência! Instale já a Barra de Ferramentas com Windows Desktop Search GRÁTIS! http://desktop.msn.com.br/ [As partes desta mensagem que não continham texto foram removidas]
