Fábio, boa tarde.
Tenho uma tabela em meu sistema, digamos, um pouco parecida com a sua. Tenho pouca experiência com tunning (comecei a desenvolver o meu lado dba a partir do meio desse ano), mas acho que aprendi coisas boas e acho que posso ajudá-lo, porém peço até que pessoas mais experientes, critiquem e opinem junto a mim. O que eu posso lhe sugerir é (e o que eu acho mais conveniente): 1 – apesar de os indices não conterem muitos extents, acho que seria legal (até mesmo pelo tamanho dos mesmos) você aumentar de 64MB para 128MB ou 256MB. 2 – Sobre os índices, poderia melhor dispor os dados sobre os índices, a formatação ficou um pouco ruim e não dá pra entender qual campo é referente ao valor do select que você fez. Informe também o tipo dos índices (BITMAP, NORMAL, etc). Gostaria de saber a quantidade total de linhas da tabela e a quantidade de valores distintos pras colunas dos índices. Poderia dar alguns exemplos do que é feito por exemplo nas operações de sua rotina que demora 3 horas? Grande abraço. De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Fábio Telles Rodriguez Enviada em: terça-feira, 11 de novembro de 2008 16:05 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Ajuste de desempenho em índices Senhores, tenho uma tabela num software de folha de pagamento de 9 mil funcionários que já tem quase 90 milhões de linhas e cresce rapidamente. Gostaria de algumas dicas para melhorar a performance desta tabela, já que ela é central no cálculo em batch, o que leva hoje umas 3 horas. Infelizmente eu não posso alterar a aplicação pois é um pacote de terceiros, o máximo que posso fazer são sugestões se eu encontrar algo muito grave. 1) Servidor: Oracle 10.2.0.3 SE rodando em Red Hat Linux 4.6. 2) Discos: 3x 146 GB SCSI em RAID 5 (eu sei, é ruim, mas só vou conseguir melhorar isso no ano que vem). 3) Tabela: quase 90 milhões de registros alocado num único tablespace ocupando hoje 3,5 GB. O tablespace dele utiliza alocação automática e está distribuído em 5 datafiles de 800MB com crescimento automático. Segue a descrição da tabela: desc resultado; Name Null Type ---------------------------------------------------- ID_RESULTADO NOT NULL NUMBER CONTA NOT NULL NUMBER TIPO_LANCAMENTO NOT NULL CHAR(1) CENTRO_CUSTO NOT NULL VARCHAR2(10) QUANTIDADE_RESULTADO NUMBER(11,2) VALOR_RESULTADO NOT NULL NUMBER(13,2) LANCAMENTO_MANUAL CHAR(1) A chave primária está nos campos: id_resultado, conta, tipo_lancamento e centro_custo 4) índices * ix_resultado_1 (conta) - Espaço ocupado: 1,5GB * ix_resultado_2 (centro_custo) - Espaço ocupado: 1,7GB * ix_resultado_3 (id_resultado) - Espaço ocupado: 1,9GB * pk_resultado (id_resultado, conta, tipo_lancamento, centro_custo) - Espaço ocupado: 2,8GB Índice Tablespace blevel leaf clustering num distinct blocks factor rows keys ---------------------------------------------------------- IX_RESULTADO_1 AHB_RESULTADO_INDEX_01 2 174580 30966921 83472061 253 IX_RESULTADO_2 AHB_RESULTADO_INDEX_02 3 190047 5492413 80199857 356 IX_RESULTADO_3 AHB_RESULTADO_INDEX_03 3 195895 5024216 83688346 3266453 PK_RESULT AHB_RESULTADO_PK 3 323181 22717985 83373902 83373902 *Pergunto:* * Valeria a pena utilizar alocação uniforme, ao invés da automática? Atualmente os meus extents estão todos com 64MB e com cerca de 30 a 40 extents por índice. * Nos índices IX_RESULTADO_1 e IX_RESULTADO_2 o meu número de distinct keys é muito baixo. Será que não estou com dois índices inúteis que apenas estão ajudando a diminuir o desempenho das minhas atualizações? * Valeria a pena tentar particionar os índices, mesmo não tendo um campo como "data" e armazenando todos os tablespaces no mesmo RAID? * Após realizar um REBUILD nos índices, o clustering factor diminuiu apenas uns 5%. É normal isso? * Com o blevel em 3, justificaria-se utilizar um tamanho de bloco maior? Mesmo em um sistema transacional? Senhores, desculpa se fui impertinente em minhas perguntas, estou estudando mais a parte de tuning e gostaria de aprender a fazer as coisas da melhor forma possível na prática. Agradeço a qualquer contribuição. Atenciosamente, Fábio Telles -- blog: http://www.midstorm.org/~telles/ <http://www.midstorm.org/%7Etelles/> e-mail / jabber: [EMAIL PROTECTED] <mailto:fabio.telles%40gmail.com> [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
