| Subject | Re: [firebird-support] firebird.log error |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2009-10-19T17:13:49Z |
toddmxz wrote:
orphan back version is an old record version that's not associated
with a newer record version - in short, wasted space. Normally,
versions of a record are linked together, with the newest version
pointing to the next most recent pointing to the third most recent
and so on. When the oldest versions are so old that no running
transaction can read them, they're removed and the space they use
is released. Firebird removes old versions by zeroing the pointer
to them in the previous record, and releases the space by marking
their slot in the page index (see below) as zero length, zero offset.
So, releasing an old record version can require two page writes if
the versions are on different pages. If there's a system crash
(or hard shutdown of the server) between the two writes, the old
record version becomes an orphan - no record points to it, but it
still takes up space. Orphans have no effect on backup or restore
because the backup reads only record versions that are current when
the backup started.
There are two related benign errors - orphan pages and orphan record
fragments. Orphan pages occur when a page is taken off the free space
list (aka page inventory page) but not added to a table or index because
of a crash. Orphan record fragments occur when removing a record that
has been split over two or more pages - the first part is removed but
the back part lingers.
Regards,
Ann
A Firebird data page starts with an index - an array of pairs of
integers that indicate the length of a record on the page and its
offset on the page. When records are removed, the space on page
can be reclaimed by shuffling the records around and changing the
offsets in the index. The record identifier (RDB$DB_KEY) decomposes
into the page number in the table and the offset of the index for
the record.
>The error is benign. A back version is an old record version. An
> I am getting an error on a database. Specifics Firebird(ver 2.0.3.12981)
> superserver WindowsXPro(x86) I have not seen before nor do I know how
> it got into this state. Interestingly it fails validation but I can
> run a backup and restore and it corrects the problem. I then can validate
> the restored database successfully. I just need to know what causes this
> so I can take preemptive action on this issue. Below is the exact error
> from the log. As always your insight is appreciated.
>
> TODD (Server) Mon Oct 19 12:19:23 2009
> Database: C:\CHRONICLE\DATA\CHRON.CTI
> Relation has 12 orphan backversions (0 in use) in table SERVERSETTING (404)
>
orphan back version is an old record version that's not associated
with a newer record version - in short, wasted space. Normally,
versions of a record are linked together, with the newest version
pointing to the next most recent pointing to the third most recent
and so on. When the oldest versions are so old that no running
transaction can read them, they're removed and the space they use
is released. Firebird removes old versions by zeroing the pointer
to them in the previous record, and releases the space by marking
their slot in the page index (see below) as zero length, zero offset.
So, releasing an old record version can require two page writes if
the versions are on different pages. If there's a system crash
(or hard shutdown of the server) between the two writes, the old
record version becomes an orphan - no record points to it, but it
still takes up space. Orphans have no effect on backup or restore
because the backup reads only record versions that are current when
the backup started.
There are two related benign errors - orphan pages and orphan record
fragments. Orphan pages occur when a page is taken off the free space
list (aka page inventory page) but not added to a table or index because
of a crash. Orphan record fragments occur when removing a record that
has been split over two or more pages - the first part is removed but
the back part lingers.
Regards,
Ann
A Firebird data page starts with an index - an array of pairs of
integers that indicate the length of a record on the page and its
offset on the page. When records are removed, the space on page
can be reclaimed by shuffling the records around and changing the
offsets in the index. The record identifier (RDB$DB_KEY) decomposes
into the page number in the table and the offset of the index for
the record.