> On 9/8/2013 5:53 PM, Helen Borrie wrote: >> >> At 11:53 a.m. 9/09/2013, W O wrote: >> >> >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. >> >> 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. >> >> >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? >> >> 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. >> >> Helen Borrie, Support Consultant, IBPhoenix (Pacific) >> Author of "The Firebird Book" and "The Firebird Book Second Edition" >> http://www.firebird-books.net >> __________________________________________________________ >> > OK, this is scary. How do I query the TID to determine if my DB is > approaching the limit?
Either with gstat or in an ODS 11.1 (or higher) database via the MON$DATABASE monitoring table. -- With regards, Thomas Steinmaurer http://www.upscene.com/ Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
