Failed to query Alarms & Events, alarms not logging

[MichaelBalzer]

Hi all,

I've recently run in to an issue with the DSC Alarm & Event logging. I have a number of shared variable libraries all setup to log both data and alarms to Citadel. I've double checked that the library itself is configured for logging data and alarms, as well as all the variables. Using the DSM, I can see all of the active alarms in the system across all libraries, and can receive all alarm change events programmatically.

For some reason, alarms for only one of the libraries are logging, and attempting to query the historical Alarms & Events through MAX throws an error roughly 14 out of 15 times (with no error code or indication of why it fails). I've also attempted to archive the Citadel database, with it failing with an unspecified error (presumably when archiving the alarms side of things, the data archive seemed to work).

Can anyone offer some insight on how to resolve the problem, preferably without data loss? Further, how can I prevent the issue in future?

[JoeySpinella]

Hi Michael,

I am sorry to hear you are having these issues with your Citadel database.

Here are some things we can try:

Have you explicitly deployed all of your libraries using the DSC Deploy Libraries VI or deploying them through the project explorer?

http://digital.ni.com/public.nsf/allkb/E188DF649546CEAC8625711D0003D46A?OpenDocument

When you use the DSC Examples installed with LabVIEW DSC, using "Read Historical Trend.vi", can you see the traces from the LabVIEW environment?

http://digital.ni.com/public.nsf/allkb/933A734E8141F5438625693C007B11DB?OpenDocument

Is the mdf file larger than 4 GB?

http://digital.ni.com/public.nsf/allkb/A9A702342A4E332C86257807006D3D5D?OpenDocument

Is your Citadel service running?

http://digital.ni.com/public.nsf/allkb/86CEE8BA7DA357A6862575A1005E7EDF?OpenDocument

http://digital.ni.com/public.nsf/allkb/E307C7F965B35C8B862574CD0073560D

Were the any recent events such as a power failure that could have interrupted a write process to the database? This could result in a temporarily corrupted database.

[MichaelBalzer]

Thanks for your reply Joey.

Libraries are being deployed using the DSC Deploy Libraries VI. The libraries also have data and alarm logging enabled programmatically. At the moment they're both being logged to the same database.

I can't find the "Read Historical Trend.vi" through the DSC Examples. The article was written in 2005 and I'm using DSC 2012 SP1, so I don't know if things have changed since then. I can view the data through MAX without issue if that's any consolation.

The mdf file is about 60MB, with the entire Citadel database at around 6GB.

The Citadel service is definitely running. I've also attempted restarting it (and the PC itself) but the issue is still present.

It's entirely possible there was a power failure, as this has been during a period of plant commissioning. When I can query the alarms through MAX there's a lot of data up to a certain point (end July), then it's very sporadic after that with only certain variable's alarms being logged.

I attempted another database archive and this time it managed to get all the way through, though the archived database also has the same problems querying alarms and events. So at this point I suspect the mdf/mds files are corrupt in some way.

Using the DSM, I've tried manually pointing the libraries to log alarms to a newly created database but this doesn't seem to work. No alarms or events are logged to the new database, and checking the library properties shows that the alarm database which I configured the library to log to had reverted to the original database. Am I missing something obvious here? Do I need to pre-create some traces in the new database before alarms and events will get logged there?

Given I have managed to make a 'good' archive of the database, I'd like to try just deleting the alarms and events portion of the database and start clean. Is there a correct way to do this? I did find this article, but am unsure if this will work with a potentially corrupted database: http://digital.ni.com/public.nsf/allkb/9D3A81218264C68686256DE1005D794F If I stop all of the Citadel and SQLServer related services, can I simply delete the mdf/mds files?

[MichaelBalzer]

I just tried using the Alarm & Event Archive VI to move the alarms to a new database, and delete the alarms from the source database. The archive process was successful and a query on the new database shows the alarms there, but a query on the old database also shows a few alarms which were not deleted. Of note, the alarms in the old database belong to libraries which aren't correctly logging alarms. This leads me to believe the tables for these libraries' alarms are corrupt (entries can't be written to or deleted).

So to re-iterate one of my previous questions, is there a proper way of deleting the entire alarms potion of the database (not just the alarm data)?

[JoeySpinella]

Did you try using the DeleteAlarms.vi from the DeleteAlarms_DSC85.llb? This is the method I would recommend.

[MichaelBalzer · Accepted solution]

Thanks for the suggestion. I tried the linked llb, but it failed to delete the existing data. That said, I've managed to sort the issue out.

Deleting the alarms database (not just the alarms) did the trick. My process was:

1. Stop all libraries through DSM

2. Create new Citadel database through MAX

3. Use DSC Archive Traces VI to archive traces from current database to newly created database

4. Delete current database

5. Detach new database

6. Move new database on disk to location of old database

7. Attach new database with same name as old database

8. Start all libraries

At this point all alarms began logging correctly and I can query the alarms without issue. The system is on a UPS now, so hopefully any future power failures don't affect things.