On Fri, Nov 15, 2013 at 5:37 AM, <[email protected]> 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 > > >
