[firebase-br] SQL Trava no FB2.0 e funciona no FB1.5

[Caio Oliveira]

Olá novamente Cantú,

Eu montei novamente a estrutura de testes para realizar a SQL 
problemática e, para minha surpresa a consulta não deu problema dessa 
vez; no início fiquei confuso, mas em seguida me lembrei de que havia 
apagado alguns índices devido à outra manutenção estrutural no banco. E, 
acho que deu resultado!.

Na tabela onde o sistema buscava o custo havia um indice repetido 
(exatamente da coluna "destino" a qual retirei da cláusula where do 
select para resolver o problema anteriormente), o que provavelmente era 
a causa do problema. Vou fazer mais testes e passo qualquer nova 
informação que encontrar.

abraços!

Caio Oliveira escreveu:
> Olá Cantú,
> 
> Olha, eu havia desmontado essa estrutura de testes, mas, vou fazer 
> novamente e te envio.
> 
> abraços!
> 
> Carlos H. Cantu (TeamFB) escreveu:
>> Caio, dá pra postar o PLANO gerado pelo 1.5 e pelo 2.0? Algo me diz
>> que o otimizador do FB 2.0 se perdeu no seu select... de qq forma, a
>> RC4 está para sair... teste nela assim que estiver disponível.
>>
>> []s
>> Cantu (Membro do TeamFB - FireBase)
>> http://www.warmboot.com.br
>> FireBase - http://www.FireBase.com.br
>>
>> CO> Olá amigos,
>>
>> CO> Ontem estava testando algumas SQLs no FB2.0 quando percebí uma delas 
>> CO> fazia com que o fbserver consumisse 100% de CPU (acabei interrompendo 
>> CO> depois de alguns minutos por que ela não completava); Porêm achei 
>> CO> estranho que essa mesma SQL no FB1.5 executava normalmente.
>>
>> CO> Fui rever essa SQL e descobri o que fazia com que ela demorasse tanto no
>> CO> FB2; porêm não entendi ainda porque no FB1.5 o problema não apareçe, 
>> CO> visto que houveram várias implementações de recursos tanto na 
>> CO> seletividade dos "Índices" como no "Otimizador" do FB2; então, 
>> CO> teoricamente deveria funcionar melhor ou igual.
>>
>> CO> Vou procurar exemplificar no trecho abaixo como solucionei o problema 
>> CO> dessa SQL em questão:
>>
>> CO> SQL Original
>> CO> (causa pane no FB2 - 100% CPU; porêm, resposta quase imediata
>> CO> no FB1.5)
>> CO> -----------------------------------------------------------------
>> CO> select a.id_emp AS NUM, e.slogan AS LOJA, sum(a.nf_vtotal) AS FATURAmto,
>> CO>    sum((select custo from getcustonota(a.id_emp, a.nf_nota, a.nf_serie,
>> CO> a.destino))) AS CUSTO from cepnt001 a
>> CO> left join cepemp01 e ON (e.id_cepemp01 = a.id_emp)
>> CO> where
>> CO> (a.nf_data between '01.07.2006'  and '31.07.2006') and
>> CO> (a.operacao=0 ) and
>> CO> (not a.nf_ncli in ( select tmp.codcli from cepemp01 tmp GROUP by
>> CO> codcli HAVING COUNT(tmp.codcli) > 0 ))
>> CO>   group by 1,2
>> CO> -----------------------------------------------------------------
>>
>> CO> SQL Modificada (funcionou OK também no FB2
>> CO> resposta quase imediata nos dois FB (1.5 e 2.0)
>> CO> -----------------------------------------------------------------------
>> CO> select a.id_emp AS NUM, e.slogan AS LOJA, sum(a.nf_vtotal) AS FATURAmto,
>> CO>    sum((select custo from getcustonota(a.id_emp, a.nf_nota, 
>> CO> a.nf_serie))) AS CUSTO from cepnt001 a
>> CO> left join cepemp01 e ON (e.id_cepemp01 = a.id_emp)
>> CO> where
>> CO> (a.nf_data between '01.07.2006'  and '31.07.2006') and
>> CO> (a.operacao=0 ) and
>> CO> (not a.nf_ncli in ( select tmp.codcli from cepemp01 tmp GROUP by
>> CO> codcli HAVING COUNT(tmp.codcli) > 0 ))
>> CO>   group by 1,2
>> CO> ------------------------------------------------------------------------
>>
>> CO> Observações: Repare que a modificação feita foi que retirei um parametro
>> CO> do procedure "destino"; embora esse campo e todos os outros usados na 
>> CO> SQL estivessem indexados na tabela origem.
>>
>>
>> CO> Procedure GETCUSTONOTA (antes)
>> CO> ------------------------------
>> CO> Begin
>> CO> for select sum(e.cust_rep*e.quant) from cepsa001 e
>> CO> where (e.id_emp = :idemp and e.nota = :nota and e.notaserie = :serie and
>> CO> e.destino = :destino)
>> CO> into :custo do
>> CO> Begin
>> CO>      IF (custo IS NULL) THEN custo = 0.00;
>> CO>      SUSPEND;
>> CO> End
>> CO> END
>>
>> CO> Procedure GETCUSTONOTA (depois)
>> CO> -------------------------------
>> CO> Begin
>> CO> /* Verifica Ultimo Codigo Registrado */
>> CO> for select sum(e.cust_rep*e.quant) from cepsa001 e
>> CO> where (e.id_emp = :idemp and e.nota = :nota and e.notaserie = :serie)
>> CO> into :custo do
>> CO> Begin
>> CO>      IF (custo IS NULL) THEN custo = 0.00;
>> CO>      SUSPEND;
>> CO> End
>> CO> END
>>
>>
>> CO> Obs.: Lembrando que a tabela CEPSA001 possui um índice para cada campo
>> CO> de dados usado na SQL.
>>
>> CO> abraços!
>>
>> CO> Caio Oliveira
>>
>>
>> CO> ______________________________________________
>> CO> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> CO> Para editar sua configuração na lista, use o endereço
>> CO> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>> CO> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
>>
>> ______________________________________________
>> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
>> Para editar sua configuração na lista, use o endereço http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
>> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>>
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para editar sua configuração na lista, use o endereço http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>