Fórum Lentidão em uma consulta simples no FIREBIRD #556840
08/06/2016
0
estou com um problema no firebird que já procurei de todas as formas entender e nada. Espero que vocês me ajudem, o problema é o seguinte:
Existe uma tabela no meu banco que uso em um select simples:
select count(v.cod_pneu) qtde from op_vulca v where v.encerrado<>'S' and v.cod_auto = 1
Esse select funciona perfeitamente, só que de tempos em tempos ele simplesmente trava. Sem explicação. E apenas volta a funcionar com backup e restore do banco.
Alguém já passou por essa situação?
Estatistificas do Banco:
Database header page information:
Flags 0
Checksum 12345
Generation 29720510
Page size 4096
ODS version 11.2
Oldest transaction 28541648
Oldest active 28548576
Oldest snapshot 28548576
Next transaction 28548577
Bumped transaction 1
Sequence number 0
Next attachment ID 1193934
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Feb 27, 2012 9:39:44
Attributes force write, multi-user maintenance
Variable header data:
Sweep interval: 20000
*END*
Estatísticas da tabela:
OP_VULCA (332)
Primary pointer page: 753, Index root page: 754
Data pages: 10981, data page slots: 16977, average fill: 52%
Fill distribution:
0 - 19% = 4557
20 - 39% = 125
40 - 59% = 106
60 - 79% = 492
80 - 99% = 5701
Index FK_OP_VULCA_1 (1)
Depth: 2, leaf buckets: 101, nodes: 62841
Average data length: 0.00, total dup: 62838, max dup: 23555
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 37
60 - 79% = 43
80 - 99% = 20
Index FK_OP_VULCA_3 (2)
Depth: 2, leaf buckets: 102, nodes: 62841
Average data length: 0.00, total dup: 62840, max dup: 62840
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 41
60 - 79% = 39
80 - 99% = 21
Index FK_OP_VULCA_OP_CADPNEU (3)
Depth: 3, leaf buckets: 338, nodes: 62841
Average data length: 6.30, total dup: 9, max dup: 1
Fill distribution:
0 - 19% = 25
20 - 39% = 0
40 - 59% = 271
60 - 79% = 41
80 - 99% = 1
Index FK_OP_VULCA_OP_INIAUTO (4)
Depth: 2, leaf buckets: 82, nodes: 64027
Average data length: 0.57, total dup: 58941, max dup: 1185
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 3
60 - 79% = 1
80 - 99% = 78
Index PK_OP_VULCA (0)
Depth: 3, leaf buckets: 374, nodes: 62841
Average data length: 18.35, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 373
Espero que alguém me ajude... Pois não encontrei nada que me esclarecesse porque isso acontece.
Obrigado!
Adriano
Curtir tópico
+ 0Posts
08/06/2016
Rafael Bosco
Gostei + 0
08/06/2016
Adriano
Gostei + 0
08/06/2016
Thiago Nunes
Gostaria de sugerir a você alguma verificações que eu faria:
1 - Documente data e hora que a lentidão ocorreu.
Sabendo a data e hora que a lentidão se manifestou, você pode verificar se no servidor houve outros eventos que influenciaram, como por exemplo uma falha do SGDB ou algum serviço do sistema operacional que falhou, ou até mesmo o usuário que solicitou no sistema uma rotina que é mais custosa, seja por ser complexa ou por precisar ser melhorada, mas o que deixou o servidor mas sobrecarregado.
2 - Atributos da cláusula WHERE da sentença SQL
Os campos que estão na cláusula WHERE devem ser colocados em ordem mais restritiva do fim para o início. Análise o plano da consulta pra ver quais índices estão sendo utilizados. Verifique também se os campos da cláusula WHERE não possuem registros NULL.
Gostei + 0
09/06/2016
Adriano
1- Eu sempre estou anotando as hora que está acontecendo, o problema que isso acontece em apenas um cliente e muito aleatoriamente, e essa rotina não é trabalhosa, pelo contrario é só essa consulta que trava, que relativamente ao meu ver é uma consulta simples onde eu só conto os registros da tabela.
2- Nesse caso não entendi como vou colocar de maneira mais restritiva nesse sql, ele é pequeno e só tem duas condições, poderia me ajudar se for o caso me dando uma dica ?
A tabela parece que corrompe, e tudo que faço nela ela trava, e volta a funcionar depois de um tempo parada, tempo de em media 2 hrs ou fazendo backup/restore.
Gostei + 0
09/06/2016
Thiago Nunes
1 - Documente data e hora que a lentidão ocorreu.
Sabendo a data e hora que a lentidão se manifestou, você pode verificar se no servidor houve outros eventos que influenciaram, como por exemplo uma falha do SGDB ou algum serviço do sistema operacional que falhou, ou até mesmo o usuário que solicitou no sistema uma rotina que é mais custosa, seja por ser complexa ou por precisar ser melhorada, mas o que deixou o servidor mas sobrecarregado.
Talvez aqui não seja a consulta que você está achando que seja o problema. Pode ser que este cliente, que é o único que está apresentando o problema, realize algum procedimento que deixe o servidor sobrecarregado. E às vezes, quando ele vai executar a rotina que faz a consulta que você postou aqui, dá a impressão de ela ser problemática. Uma vez, um cliente reclamava de determinado relatório, onde o sistema ficava lento durante determinado momento do dia. O problema era que ele emitida o relatório no horário que o servidor executava uma rotina de backup.
2 - Atributos da cláusula WHERE da sentença SQL
Os campos que estão na cláusula WHERE devem ser colocados em ordem mais restritiva do fim para o início. Análise o plano da consulta pra ver quais índices estão sendo utilizados. Verifique também se os campos da cláusula WHERE não possuem registros NULL.
Sobre este ponto, foi só uma observação. Se você, que conhece bem o banco de dados já considera a instrução SQL otimizada, desconsidere este item.
Agora, sobre a tabela se corromper realmente é muito estranho.
Abraço.
Gostei + 0
10/06/2016
Adriano
O problema não é no servidor do cliente, pois eu pego a base dele e teste direto no interbase no meu computador.
Ele demora 11 minutos para rodar essa consulta e depois ela fica instantânea.
Estou com uma pulga na cabeça com esse problema, que não acho solução e nem tenho um porque disso acontecer.
Gostei + 0
10/06/2016
Huidemar Costa
Gostei + 0
10/06/2016
Adriano
Pois é, estou desenvolvendo uma aplicação aqui para rodar ele todo dia de madrugada.
Quero ver se resolve...
Gostei + 0
10/06/2016
Huidemar Costa
Gostei + 0
10/06/2016
Adriano
Achei um link que explica usando o componente IBConfigService mais não está funcionando.
Gostei + 0
10/06/2016
Huidemar Costa
Talvez utilizando o shellExecute deva funcionar:
caminho_do_gfix_comandos_banco := 'c:\firebird\bin\gfix -sweep arquivo.gdb'; ShellExecute(Handle,'open',pchar(caminho_do_gfix_comandos_banco),nil,nil,sw_show)
Gostei + 0
10/06/2016
Adriano
Vou fazer isso...
Eu achei um site que explica exatamente oque está acontecendo no meu banco de dados.
Esta em espanhol mais para quem usar o firebird é importante saber dessas informações.
https://firebird21.wordpress.com/tag/sweep/
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)