On Tue, Sep 29, 2015 at 4:50 PM, Jeferson Sisto jsis...@gmail.com [firebird-support] <firebird-support@yahoogroups.com> wrote:
> > > Ok, I know this full procedure about corrupt database. > > But, when the unique problem about corrupt database is ORPHAN PAGE. In > this especific situation, is necessary to execute all the steps, including > the backup/restore? > > Looking my situation, I'm having ONLY orphan page in a database that have > 20~30 GB. In this database, the backup/restore procedure delay > significative time... > Orphan pages are just lost space. If you've only got three or four (at 16KB per page) in a 20 GB database by all means ignore it. Orphan record versions are the same, but even less significant. Both those errors can occur when the database shuts down without writing out its cache completely. They're totally benign. For those who care deeply, here's the situation. Firebird uses careful write to maintain on-disk consistency. That translates to writing the thing pointed to before the pointer when creating objects and removing the pointer before the object when releasing objects. Consider the case of allocating a new page to a table. 1) the page number is released from the free page list, so it can't be allocated twice and the free page list is written. 2) the page is formatted to look like a data page for that table and written to the database. 3) the page number is entered into the list of page that belong to the table and that list is written to the database. If the database stops between 1 and 2 or 2 and 3, that page is neither free nor associated with a table, index, or internal structure. But it doesn't cause any problems either. It just sits there, wasting a small amount of space until gfix removes it or the database is restored from a backup. Similarly when Firebird garbage collects an old record version, it first clears the pointer to the version in the next newer version, then clears the entry on the data page that locates the actual record. Last, it removes index entries that are no longer valid. If there's a failure between clearing the record pointer and the entry on the data page, that record version sits there until gfix removes it or the database is restored. Good luck, Ann
