>--- Yusuf Celik wrote:
> > First items says stop the Firbird server.
> > If I stop it gfix comes with unavailable database msg.?

At 02:38 AM 8/09/2007, David Richmond wrote:

>You have to make sure gfix is accessing the database file directly and
>not via TCP/IP. Do not use the hostname: prefix in the path, i.e. use:
>
>gfix -validate /path/to/db.fdb
>
>instead of:
>
>gfix -validate localhost:/path/to/db.fdb

Not so. In fact, with Superserver on Linux you can't access a
database that way. At the same time, if you are running Classic on
Linux, direct access will make things a bit faster. But see further
comments below.

The essential thing is to prevent access TO THE DATABASE by any other
user, including other logins by SYSDBA or owner.

The FAQ article's instruction to "shut down the server" is simply
wrong, and potentially dangerous. What if it is Superserver and
there are multiple databases being accessed? What if it is Classic
and you kill xinetd while it is being used by attachments to other
databases, or by other applications altogether?

Shut down the DATABASE, using the -force switch (and a megaphone) if
necessary. This *needs* the server to be running. From Fb 2
onwards, gfix has shutdown "state" options and you will need the most
extreme one - full - initially. If the database is accessed by a
multi-tier application, shutting that down would be the first step
but that alone won't guarantee exclusive access in an environment
where every man and his dog is allowed to log in as SYSDBA or owner.

Make sure you shut down any client apps (including daemons) that you
run to monitor databases, as well as any database admin tools that
anyone keeps running under normal conditions or could have abandoned
through carelessness.

If you're doubtful about such loose cannons, you should rename the
database file temporarily after shutdown. If you can't rename the
database file, it means that someone out there is still
connected. *Then* you have a problem that would have to be solved by
the extreme recourse of shutting down (or otherwise disabling) the
server. But it should NOT be done until other databases have been
shut down in an orderly manner.

You should be using a filecopy of the database for the repair work
anyway. That can't be emphasised enough. Using gfix -mend at the
wrong time can convert a repairable database into dog
food. Fortunately for Yusuf, having followed your first instruction,
he wasn't able to connect to the damaged database at all. Let's hope
it didn't bust any other databases...

It's dangerous to publish an FAQ that "simplifies" an operation that
needs such extreme attention to detail and precise order. Softly,
softly. For now, your FAQ needs to direct users to the paper
"Diagnosing and Repairing InterBase Data Corruption" at
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_db_corr
at least until the FAQ article has been rewritten and its advice has
been properly tested on a variety of corrupt databases and server setups.

./heLen