Lentidão Módulo NF Venda
Causa
Indices inativos na base de dados eram a consequência da base de dados estar corrompida.
IMPORTANTE:
- - Os processos que foram passados são um modelo básico, não serve para todas as situações, contudo, pode ser usado como ponto de partida, desde que entenda-se os riscos.
- - Entender o erro, como no caso dos erros gerados ao fazer o restore, são essenciais para saber o que fazer. Só fazer os passos que foram descritos sem saber o que está acontecendo pode se tornar um problema ainda maior.
- - Não sabemos dizer o que pode ter causado esse problema, mas aí entram aquelas questões de sempre: desligamento incorreto do micro, ficar copiando a base de dados em uso de um lado para outro, entre outros que vocês já conhecem.
Procedimento
O primeiro passo é tentar fazer o backup através do GBAK do Firebird. Nesse processo irá acusar qual o problema na base, que nesse caso era esse:
.png)
A partir daí tem alguns outros procedimentos que podem ser realizados através do GFIX quando ocorrem erros de inconsistência (consistency):
1 - Validar a base. Aqui irá aparecer, caso existam, os registros danificados:
.png)
2 - Corrigir corrupção. Nesse processo os registros danificados serão ignorados. De forma geral, esse processo irá ocasionar a exclusão de informações da base:
.png)
Após esses dois procedimentos, faça o backup da base novamente. Para verificar se ainda há problemas em registros.
Nesse momento faça o backup utilizando a gravação do log em arquivo (parâmetro "-y" do GBAK). Dessa forma você pode pesquisar no arquivo pela palavra "erro", por exemplo, para verificar se teve alguma inconsistência ao realizar o backup.
Conforme exemplo:
.png)
Em seguida deve ser feito o "restore". Também utilizando o parâmetro para gravar o log em txt:
.png)
De forma geral esses procedimentos resolvem o problema de corrupção, mas geralmente ocorre perda de dados, como foi o caso dessa base.
Após o "restore", entrei no arquivo de log e procurei pela palavra "erro", e encontrei algumas inconsistências no momento de ativar os índices:
.png)
Índices de FK (chave estrangeira) não ativam quando não é localizado o registro na tabela relacionada. Ex.: Na TB_NFV_ITEM_ICMS não foi possível ativar o índice FK_NFV_ITEM_PIS que se refere à ligação com a TB_NFV_ITEM, da qual a TB_NFV_ITEM_ICMS tem dependência.
Nesse caso, por meio de selects (Ex.: select * from TB_NFV_ITEM_ICMS tpv where tpv.id_nfvitem not in (select id_nfvitem from tb_nfv_item), foi localizado os registros que não existiam na TB_NFV_ITEM e tive que excluir da TB_NFV_ITEM_ICMS. Esse procedimento foi realizado em cada uma das tabelas que acusaram erro ao criar o índice durante o "restore".
Após apagar os registros que não possuem referência, realize novamente o processo de backup e restore, conforme os passos já descritos acima.