Hi Helen,

Thanks for responding. I omitted the full pathnames of
the commands and the db pathname, etc. only for brevity.

> Find out whether he has hyperthreading disabled, whether he
> has other applications competing for localhost sockets,

There _was_ unusually high demand from other processes for
sockets. Also, available memory was very low, and fbserver
was taking up a lot of it, even though investigation showed
very little activity or connections from processes that
access the database.

Hyperthreading is enabled. The CPU affinity mask is at
the default setting. Can disabling hyperthreading cause
problems in this case?

> The internal software consistency check in this case isn't
> necessarily from a corrupt database though.

That is very interesting information. Perhaps the database
is not corrupt, then - it has been working better so far
this morning.

Thanks,

Eric

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> 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
>