Fórum Otimizacao #37371
14/07/2003
0
Tenho uns relatorios que acessam BD grandes (c/ muitos registros)
Como o select estava lento, eu criei um indice secundário c/ mesma condicao da clausula where do meu select e o select de 2 min. passou a ser feito em 3 segundos.
Bem, resolvido isso fui p/ um outro relatorio onde usa um select muito parecido c/ o do anterior, mas c/ uma diferenca, o primeiro selectiona pela ´data_prevista´ e o segundo pela ´data_realizada´
Entao, como este tb. estava lento, eu criei um indice secundário da mesma forma que fiz com o primeiro (só que usando a data secundária). Mas qdo executo o select ele nao pega este segundo indice que criei, ele pega o primeiro e entao fica lento do mesmo jeito. Alguem sabe pq.???
Eu estou testando no IBExpert.
grata,
Como o select estava lento, eu criei um indice secundário c/ mesma condicao da clausula where do meu select e o select de 2 min. passou a ser feito em 3 segundos.
Bem, resolvido isso fui p/ um outro relatorio onde usa um select muito parecido c/ o do anterior, mas c/ uma diferenca, o primeiro selectiona pela ´data_prevista´ e o segundo pela ´data_realizada´
Entao, como este tb. estava lento, eu criei um indice secundário da mesma forma que fiz com o primeiro (só que usando a data secundária). Mas qdo executo o select ele nao pega este segundo indice que criei, ele pega o primeiro e entao fica lento do mesmo jeito. Alguem sabe pq.???
Eu estou testando no IBExpert.
grata,
Renata
Curtir tópico
+ 0
Responder
Posts
14/07/2003
Afarias
vc pode colocar seu metadata para a TABELA e ÍNDICES e seu SQL que está lento?? Só assim dá pra dizer algo -- isso não ocorre normalmente.
Responder
Gostei + 0
15/07/2003
Renata
Não entendi o que vc. quiz dizer Afarias.
Eu já descobri o que eu tinha que fazer p/ resolver esse problema. Eu tinha que forçar o PLAN no select. Só que agora estou preocupada pq. conversando c/ um kra da Borland (do site oficial) ele mencionou que eu não devia usar o PLAN no SQL (principalmente no caso de indices que têm o nome gerado pelo IB - como RDB$PRIMARY143 - pq. assim que eu fizer um bkp-restore esses nomes mudam e dariam problemas, etc, etc...
Só que as vezes ele simplesmente não seleciona o indice correto no select. O que devo fazer???
grata,
Eu já descobri o que eu tinha que fazer p/ resolver esse problema. Eu tinha que forçar o PLAN no select. Só que agora estou preocupada pq. conversando c/ um kra da Borland (do site oficial) ele mencionou que eu não devia usar o PLAN no SQL (principalmente no caso de indices que têm o nome gerado pelo IB - como RDB$PRIMARY143 - pq. assim que eu fizer um bkp-restore esses nomes mudam e dariam problemas, etc, etc...
Só que as vezes ele simplesmente não seleciona o indice correto no select. O que devo fazer???
grata,
Responder
Gostei + 0
15/07/2003
Afarias
|Não entendi o que vc. quiz dizer Afarias.
Me referi aos scripts de criação da tabela e índices
|Eu já descobri o que eu tinha que fazer p/ resolver esse problema. Eu
|tinha que forçar o PLAN no select. Só que agora estou preocupada pq.
|conversando c/ um kra da Borland (do site oficial) ele mencionou que eu
|não devia usar o PLAN no SQL (principalmente no caso de indices que
|têm o nome gerado pelo IB - como RDB$PRIMARY143 - pq. assim que
|eu fizer um bkp-restore esses nomes mudam e dariam problemas, etc,
Correto.
* Note q o mesmo não deve acontecer com FB 1.5 q permite q vc defina os nomes dos índices das constraints -- más é verdade para o IB
|Só que as vezes ele simplesmente não seleciona o indice correto no
|select. O que devo fazer???
Bom, aconselho o seginte:
* Baixar na Internet um aplicativo chamado IBPlanAnalizer
* Ler as referências q estão no help do IBPlanAnalizer para entender o q está ocorrendo e ter melhores opções de otimização
* Usar o IBPlanAnalizer para procurar analizar a query e talvês otimizá-la (modificá-la)
...Por último, se realmente tiver que usar o PLAN, talvês seja boa idéia criar índices ´manuais´ para os campos e utilizá-los no PLAN (no lugar dos criados pelas constraints)
Abraço
Me referi aos scripts de criação da tabela e índices
|Eu já descobri o que eu tinha que fazer p/ resolver esse problema. Eu
|tinha que forçar o PLAN no select. Só que agora estou preocupada pq.
|conversando c/ um kra da Borland (do site oficial) ele mencionou que eu
|não devia usar o PLAN no SQL (principalmente no caso de indices que
|têm o nome gerado pelo IB - como RDB$PRIMARY143 - pq. assim que
|eu fizer um bkp-restore esses nomes mudam e dariam problemas, etc,
Correto.
* Note q o mesmo não deve acontecer com FB 1.5 q permite q vc defina os nomes dos índices das constraints -- más é verdade para o IB
|Só que as vezes ele simplesmente não seleciona o indice correto no
|select. O que devo fazer???
Bom, aconselho o seginte:
* Baixar na Internet um aplicativo chamado IBPlanAnalizer
* Ler as referências q estão no help do IBPlanAnalizer para entender o q está ocorrendo e ter melhores opções de otimização
* Usar o IBPlanAnalizer para procurar analizar a query e talvês otimizá-la (modificá-la)
...Por último, se realmente tiver que usar o PLAN, talvês seja boa idéia criar índices ´manuais´ para os campos e utilizá-los no PLAN (no lugar dos criados pelas constraints)
Abraço
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)