Can I Fix a Corrupted Database in Lookout 4?
Primary Software: Lookout
Primary Software Version: 4.0.1
Primary Software Fixed Version: N/A
Secondary Software: N/A
Problem: I am getting an unexpected behavior in Lookout 4, but if I move database files to a different directory, then the problem disappears. This indicates that the database files may be corrupted. I would like to get as much data as I can from the database. What should I do?
Solution: Lookout is using the Citadel database to store all historical data, alarms, and events. Unfortunately, there is no easy way to find out which files are corrupted. National Instruments is continuously improving the Citadel server to make it more robust. It has a built-in functionality to automatically recover from a corruption. Currently there is a newer version of the Citadel server available for download. Refer to the Related Links below to get the donwload.
This newer version has improved robustness and can recover from a higher level of database corruption.
Note: Citadel is part of the Logos installer. Logos is National Instruments proprietary mechanism for inter-process communication used by our automation software products (Lookout, LabVIEW Datalogging and Supervisory Control). Logos also implements the Citadel server and the time synchronization server.
Please note this section from the README file:
Logos 4.2 is compatible with Lookout 4.0.1, 4.5 and LabVIEW DSC 6.0. Starting from this version Citadel uses an improved format for Alarm & Event storage. If you open a database generated with a 4.0 Logos (Citadel) version it will be automatically converted. This operation can take several minutes. During this time Citadel server does not respond. An example of a symptom is the alarm Client disconnected from Citadel in Lookout. The time depends on the number of alarms in your database. Rule of thumb: For every AleNNNNN.ale file count about 30 seconds.
In case the new upgrade does not solve the problem, please follow these steps (we have to use a "try and see" method to narrow down the list. In some cases, the corruption might not be recoverable):
Before operating with the database files,
back up your database and make sure that the Citadel service is not running. Exit Lookout and
stop all services.
Go through each of the following steps, until you see favorable results:
- Delete all index files (they will be regenerated):
Remove mdx.mdx and tdx.tdx
Relaunch Lookout, and see if it helped.
If not, exit Lookout, and stop all services again.
- Restore the database master file:
Backup tdb.tdb and rename tdb.bak to tdb.tdb
Relaunch Lookout, and see if it helped.
If not, exit Lookout, and stop all services again.
At this point we cannot fix the database without loosing part of the data or sending it to National Instruments for further investigation. It is customer's decision if loosing part of the Alarms & Events or part of historical data is acceptable. If yes, then please follow the steps below:
- Remove alarm and event files:
The alarm and event files are tracked independently of the historical data. Backup the following files before deleting them: all the *.ale, *.adx, *.mdx, and areas.dat files. This will leave the historical data unaffected.
Relaunch Lookout, and see if it helped. If not, exit Lookout, and stop all services again.
- Remove corrupted historical data files:
If removing the alarm and event files did not help, you may have corrupted historical data files. Backup the following files before deleting them: all the *.thd, *.tdx, *.tdb and tdb.bak files.
Relaunch Lookout, and see if this helped. At this point there are no other files in the folder that can be corrupted, so you should be able to successfully log data to historical database. If it is working, then we can now try to isolate the corrupted *.thd file(s) and remove them from the database. If the Citadel problems started recently, then the last *.thd files are the most likely ones to be corrupted. Stop Lookout and try to delete last file from the sequence. Relaunch Lookout. Repeat this procedure until you are able to log data.
Note: It is not true that only the last file in the sequence is open when Lookout is logging data. Potentially any file in the database can be open while Lookout is logging, but the last few files are most likely the to be the open files. For example: if the sequence contains 10 files: thd00001.thd, thd00002.thd, ...., thd00010.thd, it is possible that 1st, 5th, 9th and 10th files are open while Lookout is running. If there is a crash on your computer and Lookout is currently streaming data to 9th file, then this file can get corrupted.
The purpose of this procedure is to identify what
*.thd files are corrupted and then remove them from the sequence. We have to keep the sequence uninterrupted otherwise Lookout won't consider the database consistent. Rename the files at the end so that the sequence is not interrupted. For example: if you have ten files in the sequence and the 9th (
thd00009.thd) is corrupted then you can still kept all other files, but the sequence is going to be broken: ...,
thd00008.thd, ??? ,
thd00010.thd. Rename the
thd00010.thd to
thd00009.thd to fix this problem.
You can still try to move the alarm and event files back, and see if they are still valid. Make sure that Lookout and the Citadel server are not running when you do so.
Related Links: Drivers and Updates: Logos Services (Citadel & Time Synchronization Servers)
Attachments:
Report Date: 08/28/2000
Last Updated: 05/06/2008
Document ID: 20RFHFJ6
