Snapshot and archive counters

The Point Count is the number of points that are currently defined in the Point Database. It is incremented when a point is created and decremented when a point is deleted.

An "r;event" is the fundamental Historian data element. It represents a value or status of a unique data source at a specific time. Specifically an event is a Value, Timestamp, and PointID. Most events come from Historian API- or Historian SDK-based interfaces. The Historian subsystems ("r;Applications" Historian Batch, Historian Performance Equations, Historian Total, and Historian Alarm), as well as manual input and laboratory systems are also event sources.

Every Snapshot event increments the Snapshot Events Counter. The Snapshot Subsystem applies a compression algorithm to every event. The compression algorithm determines if the previous Snapshot event is passed on to the archive.

Events older than the current Snapshot event are out-of-order events. These events bypass compression and are sent directly to the archive. This counter shows the number of times this has occurred.

Count of all Snapshot reads. This is a simple measurement of how many Snapshot values are read by all applications.

Events that pass compression, or are out of order, are sent to the Event Queue, and thus increment this counter. Under normal operating conditions, this count indicates the number of events that passed the compression test (that is, the events were different from existing events and could not be eliminated) and are being sent to the archive.

The ratio of Snapshot events to Events Sent to Queue is the system aggregate compression ratio. This ratio gives a quick view of overall system compression tuning. Ratios less than 2:1 indicate low compression; a compression tuning evaluation should be performed. Ratios greater than 10:1 indicate over-compression; a compression tuning evaluation should also be performed.

Three Point Database attributes affect compression: CompDev, CompMin, and CompMax. These are known as the compression specifications.

If a point has its Compressing point attribute set to FALSE, all new events are sent to the Archive Subsystem.

Events passed to the EventQueue are put in the First-In-First-Out order. The Events in Queue

Counter is incremented when the event is put in the Queue; it is decremented when the

Archive Subsystem successfully retrieves and processes the event.

When the system is shut down, the Event Queue is preserved in the file

PI\dat\pimapevq.dat

.

This assures no data loss when the system shuts down, or when the archive subsystem is not processing events at the same rate as they come in.

If the queue

PI\dat\pimapevq.dat

becomes completely full, a new queue is created. This should not occur under normal circumstances and this number will be 0. However, if the archive is not processing events, a number of such queues (up to 65536) can be created. This counter shows how many queues were created. These additional queues are automatically deleted after the archive subsystem processes them.

Note:

When multiple Event Queues exist, the file

pimapevq.dat

is renamed to

pimq0000.dat

, and additional queues are named

pimq<id>.dat

where id is the queue number in the hexadecimal representation (from 0000 to FFFF). The piartool &endash;qs command always shows information from the queue to which the Snapshot Subsystem is writing (primary queue).

This is the total number of events in all Overflow Queues. The sum of this counter and the Events in Queue counter are all the events not yet processed by the archive.

Estimated maximum number of events with the current queue file.

The Archived Events counter is incremented for every new event written to the archive (via the archive cache). This count includes delete and edit events.

The Archive Subsystem receives events from the Snapshot Subsystem. If the timestamp of the event is older than the last event in the target record, it is considered an out-of-order event and is added to this counter.

Excessive out-of-order events might lead to system problems such as excess processor consumption, excessive disk I/O, and archives filling faster than expected.

Out-of-order events are inserted into the target record. The insert requires moving other events within the record. If the record is full, one or more events are forced out of the record into the adjacent record. This counter is incremented each time an insertion forces an event out of a record. This counter is an indication of the impact of out-of-order events on the archive.

Number of events read by all applications. For example, a trending application requests an array of events over a specified time period. This counter is incremented for each event returned.

Number of archive read requests. Each archive read request increments this counter once, regardless of the number of events returned.

Archive cache records in memory.

Rate at which archive cache records are created in seconds.

Rate of archive cache memory hits in seconds.

Rate at which archive cache records are removed from memory.

Rate of archive record disc reads in seconds.

Rate of archive record disc writes in seconds.

Indicates the total number of events not yet flushed to disk.

Indicates the number of points with any number of events not yet flushed.

Number of points flushed to disk. Busy points might get flushed several times per cycle.

The archive receiving current data is called the Primary Archive. When the Primary Archive becomes full, an Archive Shift occurs and the next available archive becomes the new Primary Archive.

The primary number is the internal index number of archive currently assigned to the primary position.

Archive Shift (hr) estimates the predicted time to the next archive shift. Use piartool -al to list the target archive file for shift. The target archive will be initialized on shift; if it contains data, make sure it is backed up. If this data is required to remain online, a new archive of adequate size should be created and registered.

When the current archive is less than 20% full, the estimate is 0. In order to determine whether a zero estimate means the archive is nearly full or not, run piartool -al. The message will tell you if there is not enough data for a prediction.

Shift Time: Not enough information for prediction

The shift prediction in piartool -as differs slightly from the one in piartool -al. The piartool -al figure is calculated when called. The

piartool -as

command shows the latest 10 minutes average. The latter number is available as a Windows Performance Counter.

Indicates whether events may be written to the archive.

A value of 1 indicates that events may be written. A value of 0 indicates that events may not be written.

The Archiving Flag is set to 1 when there is a mounted Primary Archive. A Primary Archive may be registered but not mounted, for example during an archive shift. In this case, the Archiving Flag would be set to 0. This flag is also set to 0 when in backup mode.

All registered archives may be viewed using piartool -al. The Archive Flag is set to 0 if the

Primary Archive becomes full and there is no other archive file available into which to shift.

Note that the Primary Archive will never overwrite itself.

This flag is set to 1 when the archive is in the backup mode. The value is 0 when the archive is available for normal access.

To enter the backup mode, run the

piartool -bs

command.

To exist the backup mode, run the

piartool -be

command.

This flag is 1 when a valid primary archive is mounted. It is 0 if the primary archive is not mounted.

This flag is 1 when the archive is in the shift mode or the Archive Subsystem has been placed in the backup mode. The shifts occur automatically or can be forced via the

piartool -fs

command. System backup mode is entered with the

piartool -systembackup

command.

Set to 1 when a shift should occur but no shiftable archive exists. Under normal conditions, this flag is 0.

Number of index records. Index records speed up access to overflow records. Index records are created when two overflow records for a point are full, and the third one is being created. This counter is a measurement of archive file consumption.

Number of non-primary data records. Each archive has a primary record for each point. When this record is full, data is written to overflow the records. This counter gives a measurement of archive consumption.