Menu de navegação

[brunopbParticipante]

amigos,

preciso de uma ajuda, imagino que seja coisa simples…

seguinte, tenho uma tabela com 9milhoes de registros, essa tabela tem registros de jan/09 até dez/09, cada mes possui 800.000 linhas.

fiz o particionamento desta tabela pelo campo mes, criei uma particao para cada mes, o que me ajudou bastante na questão de performance.

o problema é o seguinte, quando faço a consulta de um mes ou 2, a consulta é rapida e me responde de imediato, agora quando pego um range maior ou quase tudo, a consulta fica extremamente lenta… e na aplicacao os usuarios insistem em fazer essa consulta… não sei como posso otimizar…

existe algum procedimento que vcs tomariam?

obrigado

[rwarstatParticipante]

Brunopb,

Uma pergunta que deve ser feita é se realmente os teus usuários precisam fazer a pesquisa por todos os meses. Muitas vezes eles fazem por que é mais cômodo fazer assim, pois o sistema já traz aquele período setado. Verifica se o sistema não pdoe ser modificado para trazer sempre os últimos 30 dias, por exemplo.

Abraço,
Roberto

[fsitjaParticipante]

Quando eles fazem a pesquisa para todos meses, que outros filtros eles usam, no lugar da data? Porque se for buscar tudo, não tem mágica que se possa fazer. Índice inclusive vai deixar mais lento, pois o percentual retornado torna mais barato um full table scan, que terá menos overhead de I/O nos índices.

Tem que fazer filtros obrigatórios mesmo, que corte a pesquisa ou agregue o output de alguma forma. Nenhum ser humano vai analisar 9 milhões de linhas de qualquer forma, é difícil justificar uma consulta ad-hoc que retorne tantas linhas.

Se o usuário disser que é para colocar numa planilha Excel para “brincar” com os dados e fazer cálculos faz de conta que não ouviu e dá 2 mil linhas para ele brincar. 🙄

[Leonardo LitzParticipante]

Olá brunopb

Oque vou dizer parece meio trash…
Como vc disse, quando puxado mês a mês, fica extremamente rápido.

Ao invés de vc puxar um range grande, puxe mês a mês, acumule em uma temporary table e depois apresente o resultado ao usuário.
Cuidado com as funções de agrupamente se houver.
Talvez melhore a performace.

Vlw Leonardo Litz

[brunopbParticipante]

entendi.

acontece que a ferramenta naturalmente faz uma serie de consolidaçòes nos numeros…

o resultado dessa query é agrupada por mes, no que resulta em 12 linhas de retorno… entao o usuario nao tem a sensibilidade do ‘peso’ da consulta…

até agora, não existe uma segunda opção de filtro, só a de mês mesmo…

eu andei procurando novas possibilidades e vi que podia usar o hint de parallel, fiz uns testes mas não achei que valesse a pena…

[vieriParticipante]

O ferramenta é de 3º? tem suporte?
Existem N soluções pra isso no lado da plicação.

Se a resposta for não, faça um doc com o resumo de tudo
oque o pessoal aqui te falou.

Extrair muitas linhas com rapidez, exige um disco
muito rápido e muita memôria disponivel no buffer cache
para pode trazer os dados rapidamente(como exigem seus usuários), derrepente vc tem uma limitação de hardware ai.

A idéia do Litz é boa, mas se o Oracle tiver pouco cachê
vai fazer I/O do mesmo jeito.

Fazer full table scan em uma tab part é mais caro que um
fts numa Organizada por heap que é o padrão.

Uma idéia é qdo o cara fizer por mês usar a part,
qdo fazer full usar a “normal”. Mas exige disco.

consegue colocar a query e o plano de execução aqui?

[]s

[fsitjaParticipante]

Uma saída poderia ser montar uma materialized view em cima dessa tabela, agregando o valor pré-calculado.

Essa sua tabela é uma tabela de ambiente de data warehousing ou é transacional, com muitos inserts, updates e deletes? Se for um ambiente mais “comportado” daria para habilitar uma MV com fast refresh aí, já que você teria cargas esporádicas (uma vez por dia por exemplo) fora de horários de pico.
Se for uma tabela transacional fica mais complicado.

[Autor]

Posts