Subject Re: Re: [firebird-support] Broken databases
Author Ann Harrison
On Fri, Nov 15, 2013 at 5:37 AM, <markovdmitri@...> wrote:

 Broken DB decrease performance.

A decrease in performance on an unchanged application normally suggests problems with transaction
management - long running transactions that block garbage collection.  Use gstat with the -a and -r 
switches to check the number of back versions of records you've got.  The MON$ tables are also helpful
in finding long running transactions.   

I don't find any dessapeared records of value of fields, but if I try to validate database, I see errors in DB.

OK, what errors?  How have you tried to fix them?  Gfix -m is a very crude tool - it just gets rid of anything
it considers unhealthy, and may not check for foreign key dependencies.  Have you looked at IBFirstAid?

Hardware and OS always different,

Could you be more specific?  Is there any pattern to the problems?  For example, does a database
start out OK after a successful backup/restore or after you've fixed it, but then deteriorate gradually
over a day/week/month?  Does a database that's become slow every speed up spontaneously - for
example after a successful backup?  Do small, low use databases take longer to slow down?  Are
you actually running Windows, MacOS, and Linux or just a variety of Linuxes?

Firebird 2.5 with different architecture(cometimes classic, sometimes superserver).

OK.  Are there any differences between architectures?  Does SuperServer take longer to get slow?

Force writes I check first and it's ON on for all servers.


Some servers used RAID, but some others used only one HDD, it's depend from number of users and consumer abilities.


When I restore DB I see the constraint error.

Could you be more specific?  Foreign key constraint?  Check constraint? 

For the first I try backup and restore without garbage collection,

OK, if your failure is on the backup, not the restore, turning off garbage collection
sometimes allows a successful backup.  That works when there is some corruption
that involves old versions of records, not the current version.  Using the -g switch
on the backup won't help at all if the problem is in the restore.  Restore fails when
there is logical corruption in the backed up data. 

than try different options of using gfix,

Err, as I said above, gfix -m is a very primitive tool.   It understands the physical
database structure but knows nothing about the logical integrity of the database.
So if it finds a page that looks corrupt, it deletes everything on the page.  If some
of the records on the page happen to be referenced in foreign key relationships,
gfix -m will result in logical inconsistency.

But more to the point, what does gfix report as errors?

last I try gbak -b -v -ig -g database.gdb database.gbk, than I try to restore without activating Indexes, than I try to delete all indexes, and FK, and than spep-by-step create FK and than indexes.

That sounds painful.  I gather that you can produce a "data only" restore of the
database.   In theory, Firebird should generate errors that tell you which indexes
and constraints are violated so you don't have to rebuild everything by hand.  But
without the text of the errors it's hard to know.

Good luck,