Subject Re: [firebird-support] gfix commands always result in "database PATH shutdown"
Author Helen Borrie
At 01:09 PM 18/01/2007, you wrote:
>Hi,
>
>I have a customer using Firebird 1.5.3 on linux.
>He has all the default settings in the config file,
>and connections are made via TCP/IP. Connections
>are only made on localhost - different processes
>on the same server read and write, but no other
>servers connect.
>
>He is having trouble accessing his database.
>He can attach to it, and sometimes write new
>records, but sometimes not. In some cases, he
>gets this error when attempting to write:
>
>internal gds software consistency check (can't continue after bugcheck)
>
>I've been assuming that there could be corruption,
>so I've been trying to use gfix to validate and repair
>the database. Unfortunately, all of the gfix
>commands give this result:
>
>"database FULL_PATH_TO_DB shutdown"

Weird - it doesn't look like a conventional Fb exception message at all.


>I've tried (for example)
>gfix -online
>gfix -validate -full
>gfix -mend -full
>
>Any thoughts on what could be causing gfix to act like this?

Well, if those examples are complete, you're trying to run gfix
without giving it as database to do it on.

And unless you provide the full path to the executable, you need to
run it from Firebird's ../bin directory with the dot-slash prefix.

E.g. to use gfix to get exclusive access (assuming Superserver):

./gfix -shut localhost:/home/firebird/databases/mydatabase.fdb -user
sysdba -password mypass

Note that most commands in gfix require you to connect as sysdba or
as the Firebird user that is the owner of the database.

The internal software consistency check in this case isn't
necessarily from a corrupt database though. If your report is
accurate, the engine isn't reporting any page faults....and the fact
that it is intermittent does rather suggest that, on these occasions,
the machine might be doing something unexpected with resources that
the engine doesn't know about. I think that, if gfix doesn't find
anything amiss, you should ask him to try and work out what's
different between the good sessions and the ones that don't
work; what turns up in the Firebird log file and, particularly, the
exact error messages he sees.

Ask whether he has Superserver or Classic installed and whether he's
using the right Firebird kit for his environment. Ask him to tell
you exactly the connection paths and command texts he is using, etc.
etc. blahblah.

Find out whether he has hyperthreading disabled, whether he has other
applications competing for localhost sockets, and so on. There's
more, but that should do to start with.

./heLen