Re: [firebird-support] Re: Number of the Next Transaction
Thank you very much again Dmitry. I now understand. It is very clear now. Greetings. Walter. On Sun, Oct 12, 2014 at 4:58 PM, Dmitry Yemanov dim...@users.sourceforge.net [firebird-support] wrote: > > > 13.10.2014 00:22, 'Walter R. Ojeda Valiente' wrote: > > > 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. > > 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. > > Dmitry > > >
[firebird-support] Re: Number of the Next Transaction
13.10.2014 00:22, 'Walter R. Ojeda Valiente' wrote: > 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. 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. Dmitry
Re: [firebird-support] Re: Number of the Next Transaction
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? Greetings. Walter. On Sun, Oct 12, 2014 at 3:47 PM, Dmitry Yemanov dim...@users.sourceforge.net [firebird-support] wrote: > > > 12.10.2014 23:25, 'Walter R. Ojeda Valiente' wrote: > > > 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? > > > > Someone can explain me? > > 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. > > Dmitry > > >
[firebird-support] Re: Number of the Next Transaction
12.10.2014 23:25, 'Walter R. Ojeda Valiente' wrote: > 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? > > Someone can explain me? 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. Dmitry
