Kbase P121374: Does the Last transaction number re-set
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
28/12/2006 |
|
Status: Unverified
GOAL:
Does the Last transaction number re-set
GOAL:
Is there a max number of transactions in a database
GOAL:
How to reset the Last transaction number
FACT(s) (Environment):
Progress 8.x
Progress 9.x
OpenEdge 10.x
FIX:
It is not necessary to re-set the transaction number. The last transaction number is never re-set (for example, by restarting the database, truncating or rebuilding indexes), it continues to increment until it reaches 2,147,483,647, when it rolls over to 1 and begins incrementing again.
- Last transaction number is a large 32-bit number: 2^31 (2,147,483,647)
- Negative transaction numbers are reserved for deleted recid placeholders in the index
- should the Last transaction number reach 2^31 then it will automatically reset to 1
Theoretically a problem could only exist if there are active transactions with duplicate transaction numbers. ie an application that leaves transactions open for a **very** long period of time. The amount of time it takes for the rollover to occur and transaction numbers to be re-used is expected to be greater than the length of any active transaction. For example, at 3 million transactions per day, it would take almost 2 years for the rollover to occur which would be longer than any active transaction. When the Last transaction number rolls over therefore, we start reusing the lower number slots keeping them away from the higher numbers that were in use more recently.