Commented by: @dyemanov

If you run FB as a service, check Windows Event Log to see whether the server crashed (if you specified the recovery rule there). Of, if you use SuperServer, you may use the FB guardian -- it logs all the server crashes into firebird.log.

Commented by: vander clock stephane (arkadia)

yes in the windows log i have : The Firebird Server - DefaultInstance service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 0 milliseconds: Restart the service.

the problem is that we must always check the firebird.log and the windows log ... I thing that all the log must be written in the firebird.log file, even the application crash ....

Commented by: Sean Leyne (seanleyne)

Separately, it is virtually impossible to corrupt a database, due to a server crash, if you have the "Forced Writes" set to ON. Accordingly, you need to review the database settings.

The only other source of corruption is bad hardware/disk controller/RAM.

Commented by: vander clock stephane (arkadia)

virtually impossible to corrupt a database ? you are kidding me :) all the time the database are corrupted (mostly the index).
by all the time i mean every week the database become corrupt !

sometime, the database corruption make the server hang up, sometime not. actually i can say that i have a corruption one time a week and a corruption that freeze the FBserver one time a month !

the bib big BIG probleme, is that to detect a database corruption we need to stop the service to run in exclusive the Gstat and Gstat take days to finish !!!
in other way, i try to stop the service, duplicate the database and restart the service and launch gstat, but this not work too because gstat use all the memory making the FB server crash. copy the database to another server is also very long process because the database is 80 GO in size.

the last day we discover that the fb server crash very often (so i guess again that the database is corrupted),
so today i try to backup restore the database and durring the restore i receive this :

SERVER323 (Client) Sun Oct 31 17:49:29 2010
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
Uncommitted work may have been lost

SERVER323 Sun Oct 31 18:39:55 2010
INET/inet_error: read errno = 10054

restore failled :(
relaunch it now, but it's take 24 hours to finish :(

by the way Forced Writes off it's a little crasy thing because every xxx commit the write will be done, it's make that if you do now an heavy commit and someone else come after just to do a very simple commit but unfortunatly for him it's the xxx commit then he will wait a long time because he will also commit all the xxx previous commit :( the xxx commit are not done in separate thread, they are done in the thread of one "unlucky" connection !

Commented by: Sean Leyne (seanleyne)

Our application is deployed on over 100 servers, and has been deployed for more than 8 years, with databases as large as 60GB. We have NEVER had a database corruption due to database errors (have had corruption due to disk controller failure).

By running with Forced Write = OFF you are simply "rolling the dice" and it will not be long before a database corruption occurs.

Do not run database inything other than orced Write = ON, period.

Commented by: vander clock stephane (arkadia)

> We have NEVER had a database corruption due to database errors

you are lucky :(

for exemple, for us, one of the raison of the database corruption was because of a bug in the way to read the Statistic database (corrected few month ago by vlad)
also in our case it's take more than 1 or 2 seconds to commit the data (mostly because we must update lot of index), so it's sure if during this time
the server crash then the database will be corrupted (and i think it's why probably most of the time the corruption appear in the index)

> By running with Forced Write = OFF you are simply "rolling the dice" and it will not be long before a database corruption occurs.
yes we are always in Forced Write ON