| Subject | Re: [firebird-support] Missing pointer page |
|---|---|
| Author | Ann W. Harrison |
| Post date | 2005-09-27T17:19:24Z |
Svein Erling Tysvær wrote:
specific table.
Data pages are located through a two stage lookup based on decomposing
part of a record's db_key. The db_key has four components, the last
three of which are some times called the record number. The first part
is the relation id. The second is the sequence number of a pointer page
for the table. The third is the offset on the pointer page of the data
page number. The last part is the offset on the data page of the index
entry for the record on the page.
Pointer pages are located through the RDB$PAGES table: that table
contains the page number and sequence number of pointer pages for every
table - along with transaction inventory pages, index root pages, and
generator pages. Each pointer page also contains the page number of the
next pointer page for that table.
One of those lookups got a wrong answer. The most common reason for
failure to locate a pointer page in Firebird 1.x is that the table so
many records that the decomposition algorithm rolled over - the number
of rows varies with the compressed record size, but it is on the order
of 600,000,000 for records compress to 100 bytes exclusive of blobs.
Firebird 2 (and Vulcan) use a larger part of the db_key for the record
number.
I don't know of another bug that causes that error - there could be
some, especially if you've just dropped a table.
If I were you, I'd backup and restore the database, using the verbose
switch and checking the number of records per table. If you've got
tables with more than 600,000,000 records, they should probably be split
and recreated as views using a union.
Regards,
Ann
> ... on our production server one hour ago ...Pointer pages contain an array of page numbers of data pages for a
>
> internal gds software consistency check (missing pointer page in
> DPM_data_pages (243))
>
> After restarting the server where Firebird runs things seem to behave
> normally again. But what does the error message actually mean? We
> expect the source of the error to be the deletion of a table (that
> particular table was not used by anyone).
>
specific table.
Data pages are located through a two stage lookup based on decomposing
part of a record's db_key. The db_key has four components, the last
three of which are some times called the record number. The first part
is the relation id. The second is the sequence number of a pointer page
for the table. The third is the offset on the pointer page of the data
page number. The last part is the offset on the data page of the index
entry for the record on the page.
Pointer pages are located through the RDB$PAGES table: that table
contains the page number and sequence number of pointer pages for every
table - along with transaction inventory pages, index root pages, and
generator pages. Each pointer page also contains the page number of the
next pointer page for that table.
One of those lookups got a wrong answer. The most common reason for
failure to locate a pointer page in Firebird 1.x is that the table so
many records that the decomposition algorithm rolled over - the number
of rows varies with the compressed record size, but it is on the order
of 600,000,000 for records compress to 100 bytes exclusive of blobs.
Firebird 2 (and Vulcan) use a larger part of the db_key for the record
number.
I don't know of another bug that causes that error - there could be
some, especially if you've just dropped a table.
If I were you, I'd backup and restore the database, using the verbose
switch and checking the number of records per table. If you've got
tables with more than 600,000,000 records, they should probably be split
and recreated as views using a union.
Regards,
Ann