Chiappa, fazendo alguns testes aqui, percebi que o DBMS_GATHERER faz nada mais nada menos que um ANALYZE:
analyze table "SGCOM"."ESTRUTURA_PRODUTOS_PROPOSTAS" COMPUTE statistics FOR TABLE FOR ALL INDEXES FOR ALL INDEXED COLUMNS SIZE 4; Qual a diferença então de usar o analyze como eu tenho usado? Abraços. Thiago. jlchiappa escreveu: > --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto > <[EMAIL PROTECTED]> escreveu > > > > Bom, vamos por partes. > > Vamos lá. > > Nós fazemos coleta de estatísticas todas as noites. > > Tá, isso atende DESDE QUE vc faça realmente após as alterações : se > vc coleta estats às 01:00h (digamos), e às 03:00h começa um monte de > processos que fazem montes de DMLs logicamente essas stats ficarão > FURADAS pro dia de amanhã...Estats devem ser coletadas SEMPRE que > ocorrer um volume grande de DMLs. > > > Vou mudar essa noite e avaliar como o sistema vai se comportar. > > Como eu disse, CBO é tudo ou nada, OU se coleta pra todas OU dá furo. > E ** atenção ** à essa coleta, eu recomendo que vc faça coleta full > de tudo, TANTO tabelas quanto ÍNDICES, usando o > dbms_stats.gather_table_stats, em paralelo se viável, como mostrei, E > onde vc ache/saiba que há distribuição irregular. > ==> E já tinha dito em outras msgs, torno a repetir : ** ANTES ** de > mais nada, pra dar uma chance JUSTA pro CBO, vc TEM QUE ter setado > corretamente o banco (principalmente sort_area_size, hash_area_size, > parâmetros optimizer, enabled)... CBO sem esses caras bem ajustados > é FURO NA ÁGUA, praticamente SEMPRE. garbage in, garbage out ;) > Isso é IMPORTANTÉRRIMO, não sei como explicitar mais isso. > > > > > Como teste, eu coletei estatísticas de algumas tabelas envolvidas > > em uma query específica. Ainda não consegui entender o porquê > > se eu deleto as estatísticas de um índice em uma tabela que está > > fazendo access full o banco começa a usar o índice e o custo diminui > > drasticamente! > > PURA SORTE, eu diria : quando vc não tem estatísticas, o CBO faz > PALPITEs, e por PURA SORTE o palpite dele deu certo. Isso indica, > como eu falei, que as estats não estão sendo aproveitadas/ou não > existem as adequadas (histogramas provavelmente), MAS nesse caso > específico como eu disse no 8i , COM binds implica SEM uso de > histogramas. > > > > > Aí eu fico na dúvida de se devo ter estatísticas pra esse índice ou > nao... > > Não tem dúvida, estats SEMPRE devem exisrtir, sem estats o CBO passa > a chutar, e embora algumas vezes o chute até dê certo, muitas vezes > não. Via de regra, estats sempre, e completas, com CBO bem ajustado, > é o que oferece o melhor retorno. > > > Eu não gosto muito de usar HINTs pois prefiro que o banco escolha o > melhor > > caminho, afinal ele sempre avalia esse caminho e muda conforme as > > estatísticas > > mudam. Mas o que parece estar ocorrendo é que ele não está sabendo > > qual o melhor caminho para seguir. > > É o que eu falei, o meu palpite é que haja distribuição irregular, E > por ser 8i os histogramas não são usados com bind, num caso desses > fica difícil pro CBO, aí nesse caso sim o hint pode ser uma das > alternativas. > > > > > Na minha query, por exemplo, com as estatísticas coletadas a query > está > > com custo 199. > > Se deleto as estatísticas, fica com custo 66. > > Se ao invés de deletar as estatísticas eu uso um hint para o > índice, o > > custo sobre 741. > > Vide acima. > > > > > Para falar um pouco da configuração do banco, no caso que te passei > > usamos o ERP JDEdwards, que só usa campos CHAR para strings e não > possui > > constrains a não ser as primary keys... é uma nhaca! > > Nhaca completa, mas em sendo sistema de terceiros aí muda um pouco a > figura, antes de sair mexendo pra cima e pra baixo vale ** MUITO ** a > pena vc checar com o Suporte do fornecedor, fatalmente eles vão ter > recomendações próprias. Inclusive, iirc, a Oracle comprou esse cara, > então o próprio Suporte da Oracle (tanto metalink quanto Suporte live > via chamado) pode ter algo a respeito. > > > Ele foi criado assim porque é o padrão dele, mas já criamos muitas > > tabelas com varchar2 e > > não tem nenhum problema. > > Claro, problema de se criar VARCHAR dificilmente tem, só uma > aplicação meio esquisitona é que ao invés de simplesmente fazer > SELECT campo1, campo2 , antes checar o dicionário de dados pra ver se > a coluna é CHAR ou não. > > > Estou estudando a possibilidade de migrar as colunas CHAR para > VARCHAR2. > > A questão principal aí é que como eu disse os CHARs consomem espaço a > mais. > > > > > O tempo para analisar as tabelas da minha consulta foram poucos > segundos > > para cada uma. > > Então não tem conversa, estimate NUNCA pra todas. > > ==> Só uma obs a mais, ajustado banco, coletadas as estats, eu > RECOMENDARIA que vc fizesse um trace 10053 em algumas queries > significativas, no material que te indiquei tem papers mostrando os > detalhes, essa é a ferramenta PRINCIPAL pra vc saber o que o CBO está > fazendo, como está fazendo, que decisões ele tomou... > > []s > > Chiappa > > > > > [As partes desta mensagem que não continham texto foram removidas] -------------------------------------------------------------------------------------------------------------------------- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --------------------------------------------------------------------------------------------------------------------------__________________________________________________________________ Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine __________________________________________________________________ O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário. Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
