Topic 1.3.1 – Overview
This section contains general configuration requirements for Historian Server. It also explains how to track configuration and historical data changes.
Committing Changes
Different types of dynamic changes to the database affect the system in different ways and depending on the change, some require you to commit the changes. Committing database changes is the action that makes Historian Server aware of changes in the Runtime database.
When you modify the Runtime database while the Historian Server is running, Historian Server is unaware of the changes until you commit the changes. For changes done from the IDE, the deployment takes care of modifying the historian configuration if necessary. However some changes done directly from the SMC require those changes to be committed, such as changes in the System Parameters values.
Changes cannot be committed:
- During the first five minutes after starting the historian
- During the creation of a new data block because of a prior change
- While a previous dynamic configuration is still in progress
System Parameters
A system parameter is a parameter that controls some aspect of the overall Historian Server behavior. For example:
|
Name |
Description |
|
AutoStart |
Starts the historian automatically when the computer on which the historian is running is started: 1 = Autostart enabled 0 = Autostart disabled |
|
EventStorageDuration |
Maximum duration, in hours, that event records are stored in the EventHistory table |
|
HoursPerBlock |
Duration, in hours, for history blocks. Valid values are 1, 2, 3, 4, 6, 8, 12, 24. The default is 24 hours. The history block size must always be greater than the highest scan rate. |
|
Name |
Description |
|
QualityRule |
Indicates whether the system should use values having a quality of Good and Uncertain, or having only a quality of Good. 0 = Good and Uncertain 1 = Good only The default is 0. |
|
TimeStampRule |
Used to determine which timestamp within a retrieval cycle to use for a data value. 0 = Use the timestamp at the start of the cycle 1 = Use the timestamp at the end of the cycle The default is 1. |
|
TimeSyncMaster |
Name of the computer that Historian will use as a time synchronization source. |
|
HeadroomXXXX |
Number of tags for which to pre-allocate memory in the system. This parameter is important because some types of modifications require a new history block to be created. To reduce the need to create new history blocks, the system includes headroom tags, which allocate extra space in the blocks to accommodate new tags. |
|
ModLogTrackingStatus |
Turns modification tracking on or off. The value you specify will determine what modifications are tracked. |
Modification Tracking
Historian Server tracks modifications (inserts, updates, and deletions) to columns in the Runtime database. If your plant tracks changes for compliance with regulatory agencies, you can configure the historian to use modification tracking.
Modification tracking is system-wide; it is controlled by the ModLogTrackingStatus system parameter. You cannot turn modification tracking on or off at a table level. This is due to the extra work and space required to track the changes. However, there is no performance degradation during run-time operation.
You can track two types of modifications:
- Changes to configuration data, such as additions or changes to tag, I/O Server, and storage location definitions
- Changes to history data, such as data inserts and updates by Transact-SQL statements or CSV imports
The types of changes that are tracked are controlled by the ModLogTrackingStatus system parameter. You can track inserts, updates, and deletes, as well as various combinations.
When a modification is made to a table in the database, a record for the modification is inserted into the ModLogTable table of the Runtime database. One row will be inserted for each separate type of modification, either an insert, update, or delete.
Turning Modification Tracking On/Off
Use the ModLogTrackingStatus system parameter to configure modification tracking. The following table describes the allowable values:
|
Value |
Type of Modification(s) Tracked |
|
1 |
Inserts |
|
2 |
Updates |
|
3 |
Inserts + Updates |
|
4 |
Deletions |
|
5 |
Inserts + Deletions |
|
6 |
Updates + Deletions |
|
7 |
Inserts + Updates + Deletions |
Viewing Database Modifications
You can search for all database modifications or apply filtering to return modifications for only those tables and columns you specify. You can use the following filters to retrieve specific modifications:
- All Modification Dates – Returns all changes to table columns made since modification tracking was first enabled
- Between – Returns all modifications between the start date and end date that you specify
- Modification Type – Type(s) of modifications for which to search
- Table Name – Returns modifications for all tables in the database or for a specified table. Only tables that currently have modifications appear in the list.
- Column Name – Returns modifications for a specified column in the selected table. This option is only available if you select to filter on a single table.