2

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 -online/-online normal.

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.

I used -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"...

MDMarra
  • 100,183
  • 32
  • 195
  • 326
  • The problem has solved itself in that our internet was down this morning anyway, allowing me to quickly restart the server. This restarted fbserver.exe which, when it came up, seemed to bring the database online. I guess the objective has also been achieved, all of my orphaned transactions are gone. Still would like to know how to do this better though, or why it would have been saying "shutdown" when I tried to online it. –  Apr 29 '10 at 22:26

2 Answers2

4

use online

gfix  -user "SYSDBA" -password "masterkey"  -online DATA.FDB

after database is used retry

gfix  -user "SYSDBA" -password "masterkey"   -shut -force 0 DATA.FDB
dawud
  • 14,918
  • 3
  • 41
  • 61
kovarov
  • 56
  • 2
  • Cheers for the answer. Since writing this question I've changed jobs so I can't verify, but I'd be interested to hear if anyone else can fix the problem in this way. –  Jul 15 '13 at 04:25
1

I also had the same issue, recently what i did was first I stopped the FB service and then I killed all the fbclient connections on the server. Restarted fbservice and used the bring server online cmd. hope this helps

risheen
  • 11
  • 1