Opa : então, primeiro vou assumir aqui que vc não está detectando alto-consumo de CPu baseado em Uma Só medida, que na verdade vc fez *** MUITAS E DIVERSAS ** medidas, em diversas ocasiões/horas de vários dias (e isso tanto com tools de banco quanto com tools do Sistema Operacional) e CONSISTENTEMENTE vc encontrou sintomas de grande uso de CPU.... Pois bem, é bom que vc já tenha dito que encontrar índices não-usados é *** UM *** dos trabalhos , pois gasto de CPU pode vir de atualização de índices (principalmente por causa da Ordenação do índice, que potencialmente pode ter que ser refeita a cada DML) ** MAS ** via de regra de forma Alguma esse é o principal Culpado do consumo de CPU : coisas como SQLs fazendo muitos PARSES, uso frequente e em grandes volumes de REGEXP expressions nos SQLs, SQLs chamando funções PL/SQL frequentemente e em grandes volumes (por causa do context switch) e quetais costumam ser MUITO MAIS CULPADOS do que a Atualização de índices, então EM PARALELO a esse trabalho vc VAI ESTAR checando SQLs que gastam mais CPU, SQLs que fazem mais parses, usos de PL/SQL nos seus SQLs, Planos de Execução impróprios (que estejam fazendo muito sorting, digamos, ou que esteja fazendo conversão de b-tree para bitmap ou vice-versa nos acessos via índice, etc) : vc pode Inclusive obter info desse tipo nos Planos de Execução que ficam nas v$ do banco, ou pegar pelo AWR/ASH, ou implementar alguma monitoria custom sua.... E vc VAI ESTAR TAMBÉM (onde/como for viável, principalmente se não tem pool de conexões na parada) utilizando as opções do sistema operacional para detectar os processos que mais consomem CPU e relacionar esses processos com as sessões do banco, para encontrar quais SQLs tais sessões tão executando rotineiramente.... Sobre a sua pergunta, especificamente : a) antes de qualquer coisa vc ** TEM ** que fazer esse Cliente implementar algum tipo de Controle na produção dele, onde antes de neguim sair criando índices, alterando tabelas, etc, é feito um ** ESTUDO APROPRIADO ** : eu DUVIDEODÓ que um ambiente com vinte mil índices tá sendo Minimamente Organizado/controlado, pra chegar num número assim tá meio Evidente que é casa da mãe joana onde qquer um sai criando índices, ou criando tabela, ou alterando programas à lá volonté, sem nem testar o Custo pra isso nem documentar a Causa da criação b) até pensando no que falei acima, imagino que seja ALTA a possibilidade de índices Redundantes, ie, com as mesmas colunas em ordem diferente e/ou com diferença apenas em alguma colunas secundária... Pode valer a pena umas consultinhas na DBA_INDEXES procurando por casos assim - o ponto só é que se TEM que testar o efeito que a Remoção desse tipo de índice pode causar... Por exemplo : se vc tiver um índice A criado pelas col1, col2 e col3 e um outro índice B criado por col1 e col2, dropando o índice A a consulta que tinha WHERE col1 AND col2 AND col3 pode ser atendida blz pelo índice B ** mas ** o plano pode mudar de índice acess por rowid para index scan - não dá pra dizer se essa mudança vai ser Significativa ou não sem Testes... c) antes de se falar em INDEX MONITORING, uma ** outra ** opção pra vc ver se o índice tá sendo usado em consultas ou não é vc LEVANTAR OS PLANOS DE EXECUÇÃO dos SQLs e ver quais índices nunca estão presentes em nenhum plano de execução : NOVAMENTE, quando se fala de planos de Execução, vc pode obter isso com um script de monitoração/consulta de execução frequente seu, customizado, OU pode (SE tiver a Licença necessária) obter do AWR/ASH , OU pode tracejar as principais rotinas de importância d) seja via INDEX MONITORING, seja via obtenção de planos, o ponto Crítico para se evitar(ou ao menos Diminuir) a chance de falsos negativos é vc ter uma amostra ** grande **, de pelo menos um mês : senão, como vc garante que aquele índice X que não apareceu em lugar nenhum nas primeiras semanas não vai ser CRÍTICO pra aquela rotina de Fechamento de mês que vc não foi avisado mas era o Coração da Empresa ??? Esse é o ponto, ÓBVIO que o cliente quer resultado o mais rápido possível, pra Ontem se desse, mas quanto MENOR a tua massa de coleta MAIOR A CHANCE de vc deixar escapar algo, né não ??? NÃO TEM MILAGRE, vira pro teu cliente e manda a real, escolhendo entre Maior Precisão x maior Rapidez - não somos carpinteiros barbudos pra providenciar milagre... e) A monitoração tipicamente gasta *** muito pouco ** de CPU, pois o que ela faz é pequenos UPDATEs em tabelas internas que contém metadados sobre o índice : quase NADA de Ordenação nem de cálculo ocorre provocado por ele... O que eu diria pra vc fazer (no ambiente de HOMOLOGAÇÃO, que Obviamente o Cliente Possui ** e ** é bem similar á Produção, né :9 , é Ativar o Monitoring em, digamos, 1/5 dos índices, acompanhar o aumento/gasto de CPU (que deve ser minúsculo, SE existir), depois ativar o Monitoring em 1/3, depois em 3/4 dos índices, tipo assim...
[]s Chiappa
