Subject | Can't find tip page |
---|---|
Author | Ann W. Harrison |
Post date | 2001-06-08T19:07:14Z |
While performing a necropsy on a database recently,
I ran into a bug which may be of interest to some
people.
Attempts to attach to the database failed with the
error "gds internal consistency check, can't find tip."
Checking the database header showed that the next
transaction number was 131,596,294 and the page size
was 1024. As it happens, a 1024 byte page will hold
4016 transaction states. Dividing the next transaction
number by 4016 to get the tip page sequence number
gives 32768.001494. A very interesting number.
There is a bug in InterBase 5.6, 6.01, and the current
Firebird beta that causes the lookup of a transaction
inventory page to fail if there are more than 32767
transaction pages. That makes the maximum safe
transaction id for a database with:
1024 byte pages 131,596,287.
2048 byte pages 265,814,016.
4096 byte pages 534,249,472.
8192 byte pages 1,071,120,384.
Although those are large numbers, this particular
database exceeded 131 million transactions in six
months.
Suggestions:
1) don't use a 1024 byte page size.
2) do check your next transaction number from
time to time.
3) if you see the next transaction number
approaching the limit, backup and restore
the database.
Gfix won't cure the problem, but it can be cured.
Regards,
Ann
www.ibphoenix.com
We have answers.
I ran into a bug which may be of interest to some
people.
Attempts to attach to the database failed with the
error "gds internal consistency check, can't find tip."
Checking the database header showed that the next
transaction number was 131,596,294 and the page size
was 1024. As it happens, a 1024 byte page will hold
4016 transaction states. Dividing the next transaction
number by 4016 to get the tip page sequence number
gives 32768.001494. A very interesting number.
There is a bug in InterBase 5.6, 6.01, and the current
Firebird beta that causes the lookup of a transaction
inventory page to fail if there are more than 32767
transaction pages. That makes the maximum safe
transaction id for a database with:
1024 byte pages 131,596,287.
2048 byte pages 265,814,016.
4096 byte pages 534,249,472.
8192 byte pages 1,071,120,384.
Although those are large numbers, this particular
database exceeded 131 million transactions in six
months.
Suggestions:
1) don't use a 1024 byte page size.
2) do check your next transaction number from
time to time.
3) if you see the next transaction number
approaching the limit, backup and restore
the database.
Gfix won't cure the problem, but it can be cured.
Regards,
Ann
www.ibphoenix.com
We have answers.