Googling this one hasn't made a bit of difference, unfortunately, as most results specify the syntax for onlining a database after using
gfix -shut -force 30 (or any other number of seconds) as
gfix -online dbname, and I have run
gfix -online dbname with and without login credentials for the DB in question.
The message that I get is:
database dbname shutdown
Which is fine, except that I want to bring it online now. It's out of the question to close fbserver.exe (running on a Windows box, afaik it's Classic Server 2.1.1 but it may be Super) since we have other databases running off of that which need almost 24/7 uptime. The message from doing another
gfix -shut -force or -attach or -tran is
Target shutdown mode is invalid for database dbname which appears to match with the documentation of what happens if the database is already fully shut down. The
Target shutdown mode invalid message also appears if I use
-online single or
-online multi, but not
Ideas and input greatly appreciated, especially since at the moment time is a factor for me. Thanks!
EDIT: The whole reason I shut down the DB is to clear out "active" transactions which were linked to a specific IP address, and that computer is my dev terminal (actually a virtual machine where I develop frontends for the database software) but I had no processes connecting to the database at the time. They looked like orphaned transactions to me, and they weren't in limbo afaik. Running a manual sweep didn't clear them out, deleting the rows from MON$STATEMENTS didn't work even though Firebird 2.1 supposedly supports cancelling queries that way. My last resort was to "restart" the database, hence the above issue.
EDIT 2: Just noticed this in 2.1.3 release notes:
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.
-shut -force 30 so that shouldn't be affected. However, after the 30 seconds the call did not return properly, and after waiting approximately 3 mins I closed my tty to the server (linux virtual machine on the Windows server box), which may or may not have aborted the gfix operation. Running
ps doesn't show any gfix processes. Wondering whether that has put the database in an "uncertain state"...