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.

Good.

 

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

OK. 

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,

Ann