Subject | Re: [firebird-support] Two transactions can have the same TID? |
---|---|
Author | W O |
Post date | 2013-09-09T01:43:09Z |
Thank you very much for answering me, Helen
So, going back to the theme, if I am understanding you correctly:
1. The database has 2.000.000.000 of commited transactions
2. I do a cycle backup/restore
3. The restored database can have another 2.000.000.000 of commited transactions, doing a total of 4.000.000.000 of commited transactions. Is that right?
Greetings.
Walter.
On Sun, Sep 8, 2013 at 8:53 PM, Helen Borrie <helebor@...> wrote:
At 11:53 a.m. 9/09/2013, W O wrote:That sounds like nBackup. Restoring from nBackups does NOT reset the transaction counter. You need to do a gbak backup and RESTORE that backup to start a fresh counter cycle. How often depends on how fast you are eating TIDs. Use gstat to monitor that.
>Thank you very much for your answer Helen.
>
>I do backups every day, one full and several incrementals. Well, rather it is done automatically by my program.
A database restored from a gbak backup has no transaction artifacts left from the old database. If you let the TID counter go right up to the wire with active users then be prepared for corruption in some shape or form.
>I understand that each commited (and not commited, of course) row keeps the number of its TID, so that number is always present in the row. When after a cycle backup/restore the Next Transaction is 1 because all the integer numbers were used, what happens? that database cannot be used anymore for inserts, updates and deletes?
Helen Borrie, Support Consultant, IBPhoenix (Pacific)
Author of "The Firebird Book" and "The Firebird Book Second Edition"
http://www.firebird-books.net
__________________________________________________________