К сожалению, поиск в Google ничего не изменил, поскольку в большинстве результатов указывается синтаксис для подключения базы данных после использования gfix -shut -force 30
(или любое другое количество секунд) как gfix -online dbname
, и я сбежал gfix -online dbname
с учетными данными для входа в соответствующую БД и без них.
Сообщение, которое я получаю:
database dbname shutdown
Это нормально, за исключением того, что я хочу вывести его сейчас в онлайн. Не может быть и речи о том, чтобы закрыть fbserver.exe (работает на Windows, например, это Classic Server 2.1.1, но он может be Super), так как у нас есть другие базы данных, которые требуют круглосуточной работы без выходных. Сообщение от другого gfix -shut -force
или -attach или -tran Target shutdown mode is invalid for database dbname
что похоже на документацию о том, что произойдет, если база данных уже полностью отключена. В Target shutdown mode invalid
сообщение также появляется, если я использую -online single
или -online multi
, но нет -online
/-online normal
.
Мы очень ценим идеи и вклад, особенно потому, что на данный момент время является для меня фактором. Спасибо!
РЕДАКТИРОВАТЬ: вся причина, по которой я закрыл БД, состоит в том, чтобы очистить «активные» транзакции, которые были связаны с определенным IP-адресом, и этот компьютер является моим терминалом разработчика (на самом деле виртуальная машина, на которой я разрабатываю интерфейсы для программного обеспечения базы данных), но я в то время не было процессов, подключающихся к базе данных. Мне они казались бесхозными транзакциями, и они не были в подвешенном состоянии. Выполнение ручной очистки не очистило их, удаление строк из MON $ STATEMENTS не сработало, хотя Firebird 2.1 предположительно поддерживает отмену запросов таким образом. Моим последним средством было «перезапустить» базу данных, отсюда и возникшая выше проблема.
РЕДАКТИРОВАТЬ 2: Только что заметил это в примечаниях к выпуску 2.1.3:
Проблема регрессии возникла при реализации новых режимов выключения gfix, когда выключение вызывается с параметрами -attach или -tran. Если соединения все еще активны, когда истечет указанный тайм-аут, механизм возвращает сообщение, указывающее, что завершение работы было неудачным. Однако вместо того, чтобы оставить базу данных в оперативном состоянии, как это должно быть, она переводит базу данных в неопределенное «автономное» состояние, и дальнейшие соединения отклоняются.
я использовал -shut -force 30
так что это не должно повлиять. Однако через 30 секунд вызов не вернулся должным образом, и примерно через 3 минуты я закрыл свой tty на сервере (виртуальная машина Linux на сервере Windows), что могло или не могло прервать операцию gfix. Бег ps
не показывает никаких процессов gfix. Хотите знать, не привело ли это к "неопределенному состоянию" базы данных ...
использовать онлайн
gfix -user "SYSDBA" -password "masterkey" -online DATA.FDB
после использования базы данных повторить попытку
gfix -user "SYSDBA" -password "masterkey" -shut -force 0 DATA.FDB
У меня также была такая же проблема, недавно я сначала остановил службу FB, а затем убил все подключения fbclient на сервере. Перезапустил fbservice и использовал cmd подключения сервера. надеюсь это поможет