Am I running out of transaction numbers?
Here's an email I sent to everyone in my company who deals with InterBase when I found out about this issue. It explains how to determine the next transaction ID and how to reset it.
The following is information on how to determine the next available transaction ID on an InterBase server. This is important because there is an upper limit on the transaction number; once reached, it will trigger an InterBase bug that causes database corruption.
Although it is a very large number, we should use this information to emphasize the importance of periodically backing up and restoring their InterBase database so that the transaction ID gets reset.
To view the next transaction ID in IB 6, run IBConsole. Connect to the server and attach to the database. On the database, right-click and select Maintenance, then Database Statistics.
On IB 5.6, run gstat {fully_qualified_path_and_database_filename} from a DOS prompt. This works in IB 6 as well.
You will see something that looks like this:
Database header page information:
Flags 0
Checksum 12345
Generation 783158
Page size 4096
ODS version 9.1
Oldest transaction 783145
Oldest active 783146
Oldest snapshot 783146
Next transaction 783149
The following table lists the maximum safe transaction number based on your page size:
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.
If your transaction number is nearing its limit, back up and restore your database immediately to avoid data corruption.
This bug has been fixed in Firebird V1.0.
Am I running out of transaction numbers?
Am I running out of transaction numbers? : Multi-thousand tips to make your life easier.
Here's an email I sent to everyone in my company who deals with InterBase when I found out about this issue. It explains how to determine the next transaction ID and how to reset it.
The following is information on how to determine the next available transaction ID on an InterBase server. This is important because there is an upper limit on the transaction number; once reached, it will trigger an InterBase bug that causes database corruption.
Although it is a very large number, we should use this information to emphasize the importance of periodically backing up and restoring their InterBase database so that the transaction ID gets reset.
To view the next transaction ID in IB 6, run IBConsole. Connect to the server and attach to the database. On the database, right-click and select Maintenance, then Database Statistics.
On IB 5.6, run gstat {fully_qualified_path_and_database_filename} from a DOS prompt. This works in IB 6 as well.
You will see something that looks like this:
Database header page information:
Flags 0
Checksum 12345
Generation 783158
Page size 4096
ODS version 9.1
Oldest transaction 783145
Oldest active 783146
Oldest snapshot 783146
Next transaction 783149
The following table lists the maximum safe transaction number based on your page size:
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.
If your transaction number is nearing its limit, back up and restore your database immediately to avoid data corruption.
This bug has been fixed in Firebird V1.0.
Am I running out of transaction numbers?
By Howtodotips
Am I running out of transaction numbers? : Multi-thousand tips to make your life easier.