Colega, pensando em FRAGMENTAÇÃO especificamente falando (ie, espaço
totalmente Impossível de ser reusado, normalmente por tamanhos de alocação
diferentes do pretendido no momento) eu acho muito, muito difícil, mas outras
issues referentes á armazenamento (como por exemplo white-space, ie, espaço
alocado para a tabela mas ainda não usado, sem dados - por exemplo, decorrente
de DELETEs massivos no passado ainda não seguidos por INSERTs de dados em
qtdade suficiente), ou mesmo cláusulas de STORAGE ou de paralelismo
inapropriadas nas tabelas/índices pode ser, sim...
mas nem de longe isso é a única possibilidade, nem a mais provável : entre
outras, vc pode ter aí :
- diferenças no SQL : vc TEM CERTEZA que o SQL em questão é RIGOROSAMENTE
idêntico entre os dois bancos ??? Inclusive nos bind values ou nos valores
fixos eventualmente em uso ??? E o ambiente/tool de programação aonde se
conecta em homo e em prod, são Exatamente iguais ???
- diferenças de hardware, ou de software (tipo versão do RDBMS, ou settings
diferentes - principalmente dos parâmetros relativos à CBO!, e/ou parâmetros de
sessão diferentes, via ALTER SESSION, profiles ou o que for) entre prod x homo
(e sim por mais absurdo que seja homologar num ambiente vastamente diferente ,
isso pode existir)... De hardware, nós lembramos que na versão 10g o nosso
amigo CBO já é capaz de levar em conta velocidade de I/O e capacidade de CPU
(principalmente através das nossas amigas SYSTEM STATISTICS), então Não É
impossível que o CBO esteja "pensando" que o hardware de produção é muito mais
capaz, que um I/O lá é muito mais rápido e portanto é mais performático fazer
acesso direto via scan ao invés de acessar , E de software aí as possibilidades
vão ás alturas, há n+1! settings de banco, de sessão ou similares que podem
influenciar CBO... Nem vou falar de versões/edições/patch levels, o mesmo
ajustes de SO diferentes do RDBMS entre prod x homo, é Ululantemente óbvio que
isso pode dar diferenças gritantes...
- diferença de estatísticas : estão sendo coletadas de modo Exatamente
idêntico as estatísticas de CBO nos dois databases ???? Será que não pode haver
(digamos) um job de coleta de estatísticas em homo Diferente do existente em
prod (seja em frequência, seja em amostragem, seja em método de coleta) ???
=> O meu Conselho é, uma vez PROVADO que os dois ambientes/hardwares/SOs/etc
estão Exatamente Iguais,que em ambos os bancos vc faça um trace+tkprof do SQL ,
E QUE peça um trace 10053 em ambos E QUE colete o plano de execução Real e com
estatísticas de execução de SQL e os compare...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Dalton Pereira <dalton@...> escreveu
>
> Boa tarde Pessoal!
>
> Gostaria de ouvir a opinião de vocês sobre um problema que estou tendo em um
> cleinte.
>
> E.E 10.2.0.4 64 Bits
>
> No ambiente de produção, que tem índices reconstruídos semanalmente e
> estatísticas coletadas diariamente, algumas query's que NÃO estão utilizando
> os índices corretos.
>
> Já no ambiente de Homologação, que foi recentemente criado a partir do de
> produção, os índices são utilizados corretamente.
>
> Será que o problema acontece porque as tabelas estão fragmentadas? Sei que
> fragmentação de tabelas gera problemas em querys que fazem TFS, não sei se
> alteraria o plano de execução.
>
> Foi executado shrink na tabela e o problema continuou... será que a execução
> de alter table move + rebuild nos índices resolverá o problema? ou vai ser
> necessário executar um exp + drop + imp?
>
> Att
>
>
> [cid:logogi29.jpg]
>
>
> Dalton Pereira
> Administrador de Banco de Dados
> Tel.: (71) 2103-5800
> www.sd2000.com.br<http://www.sd2000.com.br>
> dalton@...
>
> [cid:personal24823.jpg]
>
>
>
> AVISO DE CONFIDENCIALIDADE: A Informação Confidencial deverá ser utilizada
> única e exclusivamente no âmbito da relação com a Glauco Informática e não
> poderá ser repassada, reproduzida de qualquer outra forma, e nem revelada a
> terceiros.
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
