Olá Nino, Pelo que vc está falando infelizmente não sei se vc vai ter muito como trabalhar em cima dessa query, já que o índice já está sendo usado pelo otimizador. Acho que o principal problema aí é o >=, que leva vc a selecionar um número muito grande de registros simultaneamente, e isso não tem mesmo como ser muito rápido. Comprove essa hipótese substituindo >= por = apenas, e veja se a query fica rápida. Vc também pode experimentar trazer só as colunas que precisa ao invés de *, mas creio que isso não deve impactar em muita melhora não...
Em situações como essa, normalmente a melhor saída é mudar a forma como a rotina que faz essa query trabalha. Praticamente não existe situação onde você precisa realmente listar para o usuário 120 mil registros... Normalmente o que acontece são sistemas que usam frameworks de persistência (como o hibernate para o Java, por exemplo), que fazem queries simples no banco e realizam todo o processamento em cima destes dados no servidor de aplicação. Nessa situação, a melhor idéia é passar parte do processamento para a query, pensando em queries um pouco mais complexas que já trazem resultados mais resumidos e mastigados para a aplicação. Se vc utilizar, por exemplo, funções de grupo como SUM ou COUNT (se isso fizer sentido para a lógica da rotina, claro), isso pode diminuir muito o tempo da query e ainda diminuir o tempo de processamento no servidor de aplicação. O difícil é só convencer a equipe de desenvolvimento a utilizar uma query escrita à mão, fugindo assim da "arquitetura do sistema". Isso é um purismo besta que sempre leva a problemas de performance. É uma situação recorrente na minha vida: projetos que não querem nenhum processamento no banco para conseguir independência em relação à tecnologia do banco, em outras palavras, balela... Se o cara tá gastando uma grana pra usar Oracle, é burrice cair em problemas de performance pq não quer escrever uma query à mão... Na situação mais rara de vc realmente ter que mostrar para o usuário esses 120 mil registros, uma alternativa é trazer os registros de blocos em blocos (utilizando rownum), partindo do pressuposto que o usuário não vai conseguir visualizar os 120 mil registros de uma só vez. É a lógica do youtube, por exemplo, que não espera baixar todo o vídeo para começar a reproduzi-lo. Se se tratar de um "export" do banco, uma coisa que em tese é realizada de tempos em tempos, acho que vc vai ter que amargar nessa lentidão mesmo, e dar a desculpa de que não tem mesmo como fugir nesses casos... Já trabalhei importando dados vindos do SAP, e a rotina de export que os caras fizeram em ABAP demorava mais de 24h para rodar. E olha que não eram tantos dados assim... Volumes de dados muito grandes trazem grandes reponsabilidades... kkkkkk []s Marcos Em 9 de janeiro de 2012 16:39, Nino <ninoba...@gmail.com> escreveu: > ** > > > Srs, > > estou executando o seguinte select: > > SELECT * > FROM CN_COMMISSION_HEADERS_ALL D > WHERE D.PROCESSED_DATE >= ADD_MONTHS(SYSDATE, -6 ) ) > > e tal consulta está demorando aproximadamente uma hora pra retornar. > > a tabela tem índice por este campo PROCESSED_DATE (que é tipo date mesmo) e > o índice está sendo usado pelo otimizador. > > esta tabela tem aproximadamente 25 milhões de registros e o select traz em > torno de 120 mil registros. > > Minha pergunta é: > esse tempo de execução está dentro do esperado pela quantidade de registros > envolvida? > alguém tem uma idéia de algo que eu possa fazer pra melhorar esse tempo? > > versao do banco: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 > - 64bi > > Muito Obrigado! > > [As partes desta mensagem que não continham texto foram removidas] > > > [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -------------------------------------------------------------------------------------------------------------------------- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ 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: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
