Problemas com consulta lenta

Pensando um pouco mais sobre seu problema, eu vejo tres possiveis alternativas para serem testadas:

1) Use "group by" ao inves do distinct:

2) Crie uma nova tabela chamada "DATA_ARQUIVO_FORNECEDOR", popule esta tabela com uma consulta parecida com a acima e depois crie uma trigger na tabela CADCTRL.GDD para inserir um registro na DATA_ARQUIVO_FORNECEDOR caso a data nao exista para o fornecedor em questao. Entao, na sua aplicacao, vc seleciona a partir desta nova tabela.

3) Caso nenhuma das acima seja viavel/possivel, vc pode ler sobre "query caching" no Hibernate. Mas para isso funcionar direito, voce deve ter pouco movimento na tabela CADCTRL.GDD e ela deve sofrer alteracoes apenas por sua aplicacao.

Caso nenhuma das tres seja possivel/viavel, entao realmente acho que vc precisa consultar um profissional Oracle

This message was edited 1 time. Last update was at 29/06/2010 17:11:18

entanglement wrote:Você precisa consultar o DBA Oracle da tal empresa para checar se um índice

DATA_ARQUIVO_FONTE + FORNECEDOR + sei lá o quê

ou coisa parecida pode melhorar o resultado da sua consulta. (Eu sou um zero à esquerda em SQL, portanto não sei exatamente que consulta seria boa para essa sua situação em particular.) Deve haver algum índice que não piore os resultados das inserções/atualizações em geral, e melhore sua consulta em particular.

Ok.. pensei em algumas coisas. Como limitar a consulta para o último mês somente, para ver se resolve. Se fosse necessário fazer uma consulta extensiva, o cara selecionava para buscar os registros de todos os anos. Preciso testar algum critério desse tipo.

This message was edited 1 time. Last update was at 29/06/2010 17:13:27

partenon wrote:Pensando um pouco mais sobre seu problema, eu vejo tres possiveis alternativas para serem testadas:

1) Use "group by" ao inves do distinct:
SELECT DATA_ARQUIVO_FONTE FROM CADCTRL.GDD WHERE FORNECEDOR = ? GROUP BY DATA_ARQUIVO_FONTE

Eu já tinha tentado essa tática mas deu na mesma...

partenon wrote:
2) Crie uma nova tabela chamada "DATA_ARQUIVO_FORNECEDOR", popule esta tabela com uma consulta parecida com a acima e depois crie uma trigger na tabela CADCTRL.GDD para inserir um registro na DATA_ARQUIVO_FORNECEDOR caso a data nao exista para o fornecedor em questao. Entao, na sua aplicacao, vc seleciona a partir desta nova tabela.

Essa idéia parece boa... na hora de atualizar, geralmente insiro 10 mil registros diários. Acho que não haverá grandes problemas em colocar um trigger.

partenon wrote:
3) Caso nenhuma das acima seja viavel/possivel, vc pode ler sobre "query caching" no Hibernate. Mas para isso funcionar direito, voce deve ter pouco movimento na tabela CADCTRL.GDD e ela deve sofrer alteracoes apenas por sua aplicacao.

Funciona dessa forma: Ao clicar em um botão, a aplicação atualiza uma lista (JList) com os nomes dos arquivos txt que preciso importar. Para esse processo, ele roda a consulta. Atualmente só a aplicação que faz a atualização e só por via de uma operação, mas eventualmente pode ser necessária carga manual (imprevistos ou quando são migrados de outra fonte). Por isso que tava querendo evitar usar algum cache - mas não estou vendo muita saída. Talvez um cache seria uma boa alternativa.

JavaEvangelist Membro desde: 21/11/2004 16:40:00 Mensagens: 424 Offline

Se eu entendi certo, somente a sua aplicação altera esta tabela, certo?
Então não há necessidade de se criar uma trigger para isso. Basta vc cuidar na sua aplicação mesmo os pontos de INSERT nessa tabela, e popular essa nova tabela.
Eu até faria de uma maneira um pouco diferente está ideia: criaria está outra tabela tabela, mas não duplicaria a informação do caminho do arquivo. Faria a tabela GDD ter uma FK apontando para a tabela DATA_ARQUIVO_FONTE e somente nesta ter a informação do caminho do arquivo. Mas isto é como eu faria. Vc deve fazer como melhor lhe convier.

Thread.start() Membro desde: 11/01/2010 21:11:07 Mensagens: 46 Offline

algumas dúvidas (e sugestões):

- que indices você criou para esta tabela?

criando um indice utilizando os campos retornados + os campos filtrados a consulta se resumiria ao indice, o que deveria retornar rapidamente (leria bem menos blocos)

- já analisou o plano de execução desta query?

possivelmente ele pode estar dando um table scan, que numa tabela desse tamanho é terrível

se for testar o plano recomendo criar uma versão menor desta tabela (100k registros), para agilizar os testes.

- você tem acesso full a este banco? tem usuário para rodar qualquer comando?

pode mandar atualizar estatísticas da tabela e fazer testes com indices.
mas isso num horário de pouco movimento, pois criar um indice nessa tabela deve demorar muito.

- que edição/ versão de oracle está utilizando?

dependendo da edição/versão você pode criar uma materialized view com esta query.
seria a mesma coisa de criar esta tabela auxiliar, mas o oracle se encarregaria de mantê-la atualizada de tempos em tempos...

Precisas realmente de aceder a tantos milhões de registos? Não há informação a mais que deveria ir passando para histórico?

Notícias, artigos e o maior fórum brasileiro sobre Java