Walter R. Ojeda Valiente wrote:
Windows 7, 32 bits, SuperServer, Firebird 2.5.2
When nobody was using a database, writing the command GSTAT -h I saw the following numbers:
OIT = 30287 OAT = 30288 OST = 30288 NT = 30289
After a cycle backup/restore (using GBAK -b and GBAK -c) in the new database the numbers were:
OIT = 1 OAT = 2 OST = 2 NT = 304
Why the Next Transaction is 304? I was expecting 3
After connecting to the new database with ISQL.EXE and writing a SELECT with its COMMIT, the numbers were:
OIT = 306 OAT = 307 OST = 307 NT = 309
Why? I can not understand those numbers.
Why the Next Transaction was 304 and not 3? Why after a SELECT the OIT, OAT and OST had changed so much?
Can someone explain it to me?
Dmitry Yemanov answers:
Without connections to the database, OAT/OIT/OST means virtually nothing. They may be outdated as nothing depend on them. Only the Next Transaction counter is always actual. However, when a new transaction is started, OAT/OIT/OST are recalculated and updated on the header page, hence they start to match the Next Transaction counter.
This explanation is a bit simplified but you should get the idea.
Walter R. Ojeda Valiente continues:
Thank you very much for your answer Dmitry. However my first question remains: why after a cycle backup/restore the Next Transaction was 304 and not 3?
My understanding so far is that after a cycle backup/restore the ID of all transactions in the backup is put in 1. So, the Next Transaction would be 3 or a number very close to 3.
Why it was 304?
Dmitry Yemanov answers:
Nope. The Next Transaction number is reset to 1 when a new database is created. This is a very beginning of the restore process. Then gbak restores metadata and data, and it can be done in multiple transactions, depending on switches. IIRC, -o[nce] starts transaction per every restored table and -v[erbose] starts transaction per every restored index. There may be other side effects I'm not aware of.