Archiving Options for Citadel Historical Databases

Overview

Data integrity through redundancy is often a necessary specification for supervisory control and data acquisition (SCADA) systems. The LabVIEW Datalogging and Supervisory Control (DSC) Module includes the National Instruments Citadel historical database, which provides archiving tools to create redundancy systems. This document discusses the features available within Citadel to create redundancy systems and the features and limitations of using third-party utilities for database replication.

Contents

Citadel Archiving Tools

You can use Citadel to perform the following archiving tasks:

  • Copy trace data from one location to another
  • Archive trace data within a database to another local database or to a remote database

To increase efficiency when archiving periodically, Citadel only archives data that it does not detect in the current archive for a particular trace. You can archive data manually or programmatically.

Manual Archiving Data

You can manually archive the data in Citadel by using the Historical Data Viewer in Measurement & Automation Explorer (MAX). Manually archiving data allows you to select between a partial or complete back-up of the Citadel historical database while the database is still actively logging data. 

Figure 1: Citadel's configuration-based archiving tool provides the flexibility to select a partial archive.

You also can manually archive data by copying or moving the database files from one location to another. Refer to the LabVIEW Help for information about copying and moving database files.

 

Programmatic Archiving Data

You can archive data programmatically by using the Database Management VIs in the DSC Module. These VIs enable you to create applications that access Citadel to create, archive, and delete databases. These VIs also enable you to develop a redundancy system that can copy databases locally, remotely, or to hard copy media.

Figure 2: The Archive Traces.vi included in LabVIEW DSC allows for programmatic full or partial archiving of a Citadel database to local or remote location.

You also can use the Database Management VIs to programmatically archive the alarm and event data stored in the Microsoft SQL Server Express database, which installs with the DSC Module.

 

Archiving Data Using Third-Party Utilities

Although third-party database back-up utilities are available, limitations for using them with Citadel may exist. Because Citadel uses a custom mechanism for data storage, third-party utilities might not support the internal format of the Citadel files. You can use third-party utilities to only access the Citadel historical database as an atomic unit and archive the database in whole each time the utility executes. Furthermore, third-party utilities cannot archive a database that is actively logging, because an open database keeps part of its data in memory buffers.

An alternative to atomic copying or archiving an entire database is to setup the Citadel historical database as an ODBC data source. The Citadel historical database includes an ODBC driver, which enables you to copy a Citadel historical database in whole or part and store the data in a third-party database, such as Oracle or MS SQL server. In addition, the ODBC driver can read data from an open database. One limitation of the ODBC driver is that it cannot access the alarms and events stored in the database and it does not support traces that have a binary string data type (BLOBs).

 

Archiving Use Cases

Two common use cases for archiving include simple replication and trace merging for redundancy.

Simple replication involves moving data from one database to another and is a common process when archiving older data to a more permanent or offline storage database. Because simple replication transfers the entire contents of a database, you can use any of the archiving methods previously described to implement simple replication.

Trace merging merges information from one trace into a trace with the same name. For example, assume that for redundancy purposes you have two computers in a system, computer A and computer B. Both computers log the same data source to a local database. All client applications reference the database on computer A. If computer A goes down, client computers switch to computer B to reference the database. Trace merging takes the redundant data from computer B and merges it into the trace data on computer A when computer A reboots. You can implement trace merging programmatically by using the Historical VIs.

 

Summary

Replication and redundancy are an important components of many high channel count systems in order to ensure system and data integrity. Both of these tasks can be achieved  with Citadel through the interactive Historical Data Viewer, the LabVIEW API or the ODBC driver.

 

Was this information helpful?

Yes

No