|Subject||Re: Re: [firebird-support] Broken databases|
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 transactionmanagement - long running transactions that block garbage collection. Use gstat with the -a and -rswitches to check the number of back versions of records you've got. The MON$ tables are also helpfulin 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 anythingit 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 databasestart out OK after a successful backup/restore or after you've fixed it, but then deteriorate graduallyover a day/week/month? Does a database that's become slow every speed up spontaneously - forexample after a successful backup? Do small, low use databases take longer to slow down? Areyou 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 collectionsometimes allows a successful backup. That works when there is some corruptionthat involves old versions of records, not the current version. Using the -g switchon the backup won't help at all if the problem is in the restore. Restore fails whenthere 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 physicaldatabase 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 someof 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 thedatabase. In theory, Firebird should generate errors that tell you which indexesand constraints are violated so you don't have to rebuild everything by hand. Butwithout the text of the errors it's hard to know.Good luck,Ann