Lentidão em uma consulta simples no FIREBIRD
Bom dia,
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:
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!
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
Curtidas 0
Respostas
Rafael Bosco
08/06/2016
Eu tinha um problema parecido, no meu caso era os INDICES da tabela, que por algum motivo, ficavam DESATIVADOS, e no Backup/Restore o Firebird, ativava os indices, aí resolvia o meu problema...
GOSTEI 0
Adriano
08/06/2016
Pelo IBExpert da para ver que o índice esta ativo. Não sei se ele esta desativando durante a Query. Tem alguma dica ?
GOSTEI 0
Thiago Nunes
08/06/2016
Boa tarde,
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.
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
Adriano
08/06/2016
Bom dia,
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.
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
Thiago Nunes
08/06/2016
E ai Adriano, beleza?
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.
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
Adriano
08/06/2016
Thiago, muito obrigado pela atenção.
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.
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
Huidemar Costa
08/06/2016
Será que o problema não está relacionado ao Sweepe ?
GOSTEI 0
Adriano
08/06/2016
Será que o problema não está relacionado ao Sweepe ?
Pois é, estou desenvolvendo uma aplicação aqui para rodar ele todo dia de madrugada.
Quero ver se resolve...
GOSTEI 0
Huidemar Costa
08/06/2016
Você vai fazer o sweepe manual então?
GOSTEI 0
Adriano
08/06/2016
Pretendo, estou pesquisando como fazer isso via delphi. Tem alguma dica ?
Achei um link que explica usando o componente IBConfigService mais não está funcionando.
Achei um link que explica usando o componente IBConfigService mais não está funcionando.
GOSTEI 0
Huidemar Costa
08/06/2016
Não fiz o teste mas acredito que este post pode te ajudar -> https://www.devmedia.com.br/forum/sweep-automatico/50433
Talvez utilizando o shellExecute deva funcionar:
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
Adriano
08/06/2016
Muito obrigado!
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/
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