Bom dia Pessoal, Obrigada jlchiappa pelo retorno. Estou em processo de desenvolvimento nesta parte de tuning. Desculpe se não fui clara o suficiente com as informações necessárias.
1.Coloquei na mensagem anterior a tabela com essas informações. SEGMENT_NAME SEGMENT_TYPE BLOCKS EXTENTS GB ROWS TB_ESTOQUE_ENTRADA2 TABLE 5.438.208 850 41,49 414.612.027 Average rows per data block= 193 2. Sim, a tabela possui muitas colunas. Então, para diminuir o I/O desta query nesta tabela, seria melhor encontrar outras formas como o Particionamento,compressão,tabela em cluster do que melhorar o CF? ---Em oracle_br@yahoogrupos.com.br, <jlchiappa@...> escreveu: Bom, primero pergunto, quanto é 400KK - seria 400 mil milhares, ie, 400 milhões ?? E segundo sorry, mas NÚMERO DE LINHAS não é significativo pra gente isoladamente - esse X de linhas representa QUANTOS BYTES/megabytes/gigabytes efetivamente ?? E terceiro ponto, como está a Média de linhas por bloco físico nessa tabela ? Mas de qquer maneira : a primeira coisa que TENHO que observar é que o CLUSTER FACTOR é relacionado com a localização Física dos dados indexados na tabela : Obviamente, não tem como Fisicamente a mesma tabela ter os dados ordenados pela coluna X ** e ** pela coluna Y ao mesmo tempo, então fique CIENTE que se vc alterar/melhorar o cluster factor da tabela em relação a um índice A, muito certamente vc vai PIORAR em relação a um índice B... Lógico.... Julgando por esse nome de IN_ESTENTRADA_LOTEAPRES2 , me parece que esse Não É o único índice dessa tabela, então VEJA LÁ se mexendo no CF de um ídnice vc Não Estraga o de outro índice, usado por OUTRAs Consultas.... Legal ?? Isso posto, aí sim a sua resposta... Primeiro teste, cfrme http://www.oracle.com/technetwork/issue-archive/2012/12-sep/o52asktom-1735913.html e https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:9524251800346726054 (e os links deste último) demonstram sim, para vc alterar o CF é fisicamente recriar a tabela.... Tenta em primeiro lugar ao invés de TRUNCAR a tabela e reinserir os dados (o que vai reaproveitar o mesmo segmento MAS adicionando novos extents) criar uma NOVA tabela (chame de TAB_ORGANIZED) com os dados vindos da tabela em análise ordenados num CREATE TABLE AS SELECT e depois criando um índice , como mostrado no primeiro link... Pra ser mais seguro ainda, faça isso numa tablespace LMT com gerenciamento automático... ==> SE esse teste não resultar em alteração nenhuma do CF a gente começa a suspeitar de algum atributo físico que esteja 'forçando' os dados a se espalhar por N blocos : talvez um registro lógico extenso ?? Montes e montes de colunas na tabela em questão ?? OBVIAMENTE, se os dados não couberem com muuuuita folga dentro do bloco, algum tipo de row chaining/row migration vai ser quase certo, aí o CF vai pras picas... []s Chiappa
