Environment
Novell eDirectory 8.7.3 for All Platform
Novell eDirectory 8.8 for All Platforms
NetIQ eDirectory 9.x for All Platforms
Situation
The ndsd.log file on Linux (*nix), or ndstrace screen with +RECM tag enabled, shows the following message:
-1323406432: RECM: [Wed Feb 4 20:10:17 2009] FATAL: DB : WARNING: the last transaction ID 0xXXXXXXXX
The dstrace screen on Netware/Windows with +RECM tag enabled, shows the following message:
RECM: [2009/04/02 20:10:17.504] DB : WARNING: The current transaction ID is 0xXXXXXXXX
Also when running new versions of eDirectory, we might see the following messages in ndsd.log file (on Linux) or dstrace/ndstrace screen:
The current transaction ID is 0xXXXXXXXX. Run local database repair with rebuild database option enabled
Transaction ID has exceeded the allowed limit of 0xFFFFE000. Run local database repair
Resolution
This message is usually informational and gives an idea where within the range of valid IDs the current system is. Many times this limitation is never reached within the lifetime of an eDirectory instance and unless the current ID is near the transaction limit the following should not be used. More details are included after these steps.
Once this message is identified and the current ID is near the ID maximum, the following dsrepair/ndsrepair procedure will help resetting/lowering the transaction IDs as much as possible.
Once this message is identified and the current ID is near the ID maximum, the following dsrepair/ndsrepair procedure will help resetting/lowering the transaction IDs as much as possible.
- On Linux (*nix):
- ndsrepair -R -i no -t no -r no -v no -c no
- Where:
[-R] - Repair the Local Database
[-i no] - Check eDir Database Structure and Index.
[-t no] - Tree Structure Check.
[-r no] - Repair all local replicas.
[-v no] - Validate stream files.
[-c no] - Check local references.
- On Netware/Windows:
- Repair all local replicas = "yes"
- Rebuild the entire database = "yes"
- All the other options set to = "no"
NOTE: For large databases that take a long time to repair, please contact Technical Support prior to running a database repair to resolve high transaction ID problems.
You may need to restart the ndsd process after running the above-mentioned ndsrepair procedure for the fix to take affect.
Should the Transaction ID have already exceeded the ID Limit and the database now fails to open, then the NDS service will need to be started without opening the database in order to execute the ndsrepair command to shrink the Transaction ID value. On SystemV, the NDS service can be started without opening the database by using the -ndb switch, eg. 'rcndsd start -ndb'. On SystemD, refer to TID # 7018431: How to pass startup parameters to eDirectory on systemd. Be sure to use only the 'NDSD_DONT_OPEN_AGENT=Y' parameter.
Should the Transaction ID have already exceeded the ID Limit and the database now fails to open, then the NDS service will need to be started without opening the database in order to execute the ndsrepair command to shrink the Transaction ID value. On SystemV, the NDS service can be started without opening the database by using the -ndb switch, eg. 'rcndsd start -ndb'. On SystemD, refer to TID # 7018431: How to pass startup parameters to eDirectory on systemd. Be sure to use only the 'NDSD_DONT_OPEN_AGENT=Y' parameter.
Additional Information
The Transaction ID is used to keep track of changes that happen in the database. Each write operation happens within a transaction (associated with a transactionID).
The read transactions that happen in parallel will have a transaction ID (last transaction that got completed successfully when the read started). Each database block will also have a transaction ID associated (the maximum transaction in the block).
The Transaction ID gets incremented for every write transaction, if there is/are one or more changes within the transaction. It is represented with an unsigned int 32 (uint32) and therefore its limit is: 4294967296 or 0xFFFFFFFF. At this point, no new transactions will be allowed.
Trying to avoid the server to completely stop writing transactions to the database, the following mechanism has been implemented to new eDirectory versions:
- As soon as the Transaction ID exceeds 0xF0000000 (4026531840), the following message is repeated after every 1000 new transactions:
The current transaction ID is 0xXXXXXXXX. Run local database repair with rebuild database option enabled to fix it before it reaches allowed limit of transactions 0xFFFFE000 (4294959104). - As soon as the Transaction ID exceeds 0xFFFFE000 (4294959104), the following message is shown:
Transaction ID has exceeded the allowed limit of 0xFFFFE000. Run local database repair. - In order to know the current Transaction ID we can run a local database repair, where the following message is shown:
Current transaction ID is 0xXXXXXXXX. Allowed limit of transaction is 0xFFFFE000.
Once this limit is reached, the eDirectory database won't open and we will see the following error:
FFFFFD96 (-618) Inconsistent Database
At this point, if this was the reason why we are facing a (-618) error, Novell Technical Support will need to be contacted and manually edit the transaction ID, followed by a database repair.
However, as a (-618) error code is used for some other causes or problems such as database corruptions, it should not be always associated with this specific transaction ID problem. Another important point is the fact that, this problem has not been seen with small databases where the number of transactions is low.