Pavel Císaø wrote:

> > GFIX -v -n -f reports (only) orphan pages in database. The
> > questions is: Is it safe to remove these orphans, i.e. are these
> > pages benign or can contain data ? How to check that and what's
> > the best strategy for recovery in this situation ?

Firebird uses a careful write ordering to keep the database
consistent on disk. When allocating a page, the order is this:

1) Find a PIP (page information page) with an unused page.
The page may have been used and released or it may be
a new page being added to the database.

2) Change the PIP to indicate that the page is no longer
available and schedule it to be written.

3) Format and fill the page as required. Schedule it to
be written and note that it must follow the PIP.

4) Insert a pointer to the page into the structure that
will hold it. If it's a data page, that involves writing
the page number on a pointer page. If it's a pointer page
or a generator, that involves writing a record to RDB$PAGES.
If it's an index page, the prior page is rewritten with
a pointer to the new page. When this write (of whatever)
is scheduled, it is marked as following the page itself.
...
27) Write the transaction inventory page to commit the transaction.
The TIP write is marked as following all data pages altered by
the transaction.

If the server crashes after the PIP is written and before the
final pointer is written, you get orphans. In the case of a
data page, the data can not be committed because step 27 hasn't
happened.

Ann