use online
gfix -user "SYSDBA" -password "masterkey" -online DATA.FDB
após o banco de dados ser usado novamente
gfix -user "SYSDBA" -password "masterkey" -shut -force 0 DATA.FDB
Pesquisando este, não faz muita diferença, infelizmente, já que a maioria dos resultados especificam a sintaxe para onlining de um banco de dados após usar gfix -shut -force 30 (ou qualquer outro número de segundos) como gfix -online dbname , e eu executei gfix -online dbname com e sem credenciais de login para o DB em questão.
A mensagem que recebo é:
database dbname shutdown
O que é bom, exceto que eu quero trazê-lo online agora. Está fora de questão fechar o fbserver.exe (rodando em uma caixa do Windows, o afaik é o Classic Server 2.1.1 mas pode ser Super) já que temos outros bancos de dados rodando fora do que precisa de quase 24 / 7 uptime. A mensagem de fazer outro gfix -shut -force ou -attach ou -tran é Target shutdown mode is invalid for database dbname , que parece corresponder à documentação do que acontece se o banco de dados já estiver totalmente desligado. A mensagem Target shutdown mode invalid também aparece se eu usar -online single ou -online multi , mas não -online / -online normal .
Idéias e sugestões muito apreciadas, especialmente porque no momento o tempo é um fator importante para mim. Obrigado!
EDIT: O motivo de eu desligar o banco de dados é limpar as transações "ativas" que estavam vinculadas a um endereço IP específico, e esse computador é meu terminal dev (na verdade, uma máquina virtual onde desenvolvo frontends para o software de banco de dados ) mas não tive nenhum processo de conexão ao banco de dados no momento. Eles pareciam transações órfãs para mim, e eles não estavam no limbo afaik. A execução de uma varredura manual não as eliminou, pois a exclusão das linhas do MON $ STATEMENTS não funcionou, embora o Firebird 2.1 supostamente suporte o cancelamento de consultas dessa maneira. Meu último recurso foi "reiniciar" o banco de dados, daí a questão acima.
EDIT 2: Apenas notei isso em 2.1.3 notas da versão:
A regression issue surfaced with the implementation of the new gfix shutdown modes when shutdown is called with the -attach or -tran options. If connections are still alive when the specified timeout expires, the engine returns a message indicating that the shutdown was unsuccessful. However, instead of leaving the database in the online state, as it should, it puts the database into some uncertain “off-line” state and further connections are refused.
Eu usei -shut -force 30 para que não seja afetado. No entanto, após os 30 segundos a chamada não retornou corretamente, e depois de esperar aproximadamente 3 minutos eu fechei meu tty para o servidor (máquina virtual linux na caixa do servidor Windows), que pode ou não ter abortado a operação gfix. A execução de ps não mostra nenhum processo de gfix. Querendo saber se isso colocou o banco de dados em um "estado incerto" ...
Eu também tive o mesmo problema, recentemente o que eu fiz foi primeiro eu parei o serviço FB e então eu matei todas as conexões fbclient no servidor. Reiniciei o fbservice e usei o cmd do servidor virtual. espero que isso ajude