Errors can result from ctree database operations.
The following section lists the various types of errors that can be generated by ctree database operations.
Error 160(0) in NextLssnRec(): Unindexed sessions
You might see an error in the Application event log indicating that the session indexer is querying for an unindexed session that is currently being updated.
Here is an example of the error that might appear in the application event log:
Event Type: Error Event Source: Session Indexer Event Category: Indexer Event ID: 9864 Date: 10/9/2009 Time: 2:41:05 PM User: N/A Computer: TLDB01 Description: Failed to retrieve record from Canister. Error 160(0) in NextLssnRec(): retrieving first batch of unindexed LSSN records.. (Type: FAIRCOM; Code: 160).
If the Event Source is the Session Indexer as indicated above, the sessions are skipped for the indexing run and are picked up on the next one.
The sessions that are waiting for indexing are still indexed; there is no risk of data loss. However, the eventlog continues to receive these errors messages until the current day's data is fully indexed. If these errors continue to show up in the eventlog after a couple of days, contact Support.
Error 160(0) in NextLssnRec(): Broken reference between data files and indexes
When retrieving the first batch of unindexed sessions, the Canister is unable to pull any sessions.
- No errors are reported in the TLTMaint logs.
- Automated indexing processes are not able to run at all.
The following error may appear in the Application event log:
(11:29 Session Indexer) - Failed to retrieve record from Canister. Error 160(0) in NextLssnRec(): retrieving first batch of unindexed LSSN records.. (Type: FAIRCOM; Code: 160).
In cases where a system crash adds bad file information to the indexes, use the procedure documented here to fix the indexes.
To fix the indexes:
- Through TMS, shut down Canister services.
- On the Canister data volume, create the following directory at the root of the volume:
- From the Canister datastore, move the
LSSN_<Date>.files to the above directory, where
<Date>is the date of the server crash.Note: You must move the files out of the Canister datastore.
- Restart Canister Services.
- Check that the indexer error message is not longer present.
Recover missing data
After fixing indexing problems, perform the steps listed here to recover missing data.
Perform the following steps to recover the session data file moved into the
- Delete the
*.idxfiles from the
- Run the following command in a command shell:
tltmaint -v -noserver -archiver -localdir \lssnNote: Depending on the file size of the session data, it may take some time to complete the above command.
- When the command prompt returns, the last line indicates the status. A "no errors" message indicates that all is well.
- Copy files with
LSSN_prefix from the
\lssn\Canister.dbsdirectory back into the canister data directory.
- Restart Canister Services through TMS. The session data is now available.
- To test, search for sessions from the date of the server crash.
Error 69(0) typically indicates that the indexes in the specified
.dat file are corrupted. Use the procedure documented here to address the
Error 69(0) error.
The following error may appear repeatedly in the Application event log:
Failed to retrieve record from Canister. Error 69(0) in ProcessSesn(): Could not update session CANISTER.dbs\LSSN_20120815_MyServer.dat 469778184. isam_err = 69. (Type: FAIRCOM; Code: 69).
This error may appear even after recycling services and rebooting the Portal, and the Canisters are appearing to operate normally.
To repair this problem, complete the following steps to rebuild the indexes.
- Log in to the server hosting the Canister as an administrator.
- Navigate to the directory where the above file is located. Typically, this directory is
- Move all files (there should be 3) matching the following name pattern out of the
- Restart Canister Services through TMS.
- When the Canister restarts, it attempts to rebuild the indexes by reindexing all sessions that are stored on the Canister. Depending on the volume of data, this process can take several hours.