In Power Monitoring Expert 8.0, there were a number of changes made to how power quality data is processed. This was done both to improve the Alarms application, and to eliminate the PQ Aggregator service from the product. As a result, the ION_Data database upgrade from PME 7.2.2 to PME 8.0 can take a long time to complete. The time it will take is dependent on the size of the ION_Data database, the number of events in EventLog2, the types of events in EventLog2 and the amount of PQ data included in DataLog2 (all the Sag/Swell and transient durations and magnitudes).
It can be difficult to determine during the upgrade process how much more is left to do, and it can look as if the Installer is just stuck on the 'Create Database...' step and nothing is happening.
This article includes some SQL queries that can be used during the upgrade to determine how far along it is, and much more is left to do.
It can be difficult to determine during the upgrade process how much more is left to do, and it can look as if the Installer is just stuck on the 'Create Database...' step and nothing is happening.
This article includes some SQL queries that can be used during the upgrade to determine how far along it is, and much more is left to do.
For example, to determine if it's still processing PQ data, you would run the following query maybe 5-10 seconds apart a few times to see if the count changes:
USE ION_DATA
SELECT COUNT(*) FROM PQ_EVENTS
If it's not changing, is non-zero, and the DB upgrade step has been in progress for at least 10 minutes, then it's a good bet the upgrade has moved on to the event/alarm processing. Unfortunately it's an expensive query to figure out how much PQ data to expect total, because we do not have any indexing on Datalog2 to facilitate non-source-centric queries. Such indexing would be very expensive in terms of space and negatively impact overall performance, so don't ask!
Next, once we're sure the PQ_Events count is no longer changing, we would check the event/alarm processing by running this query a few times, maybe 10 seconds apart:
USE ION_DATA
SELECT COUNT(*) FROM AlarmLog
Now in this case we can set an upper limit for how high the count might go, by comparing it to the count of the EventLog2 table:
USE ION_DATA
SELECT COUNT(*) FROM EventLog2
Events are processed into alarms, with unary events processed 1 to 1, and binary events processed 2 to 1 (2 events per alarm, assuming a match-up was possible).
Thus we expect AlarmLog to have 50-100% of the number of records, once done, that EventLog2 has. Simply run the above queries to determine how far along it is.
NOTE: on reasonable hardware you could be looking at something like an hour of alarm processing per 10 million events (this is a very rough number, your mileage may vary!).
The PQ processing will be about 10 minutes per million PQ_Events records, though again your mileage may vary.
Testing indicates reasonably consistent processing performance between small and large datasets, though specific characteristics in the data may influence processing speed in unanticipated ways.
Finally, the overall size of ION_Data is not really correlated with the sizes of these two tables and how much processing needs to be done during upgrades. As such it is HIGHLY recommended that you avoid providing time estimates to customers based on the ION_Data size, since this will disappoint all too often. If their DB is larger than 10 GB, check the PQ_Events and EventLog2 table sizes pre-upgrade and compare against the times I listed above to get a rough idea - that should get you into the right ballpark. The disclaimer here is that the hardware spec must be as per the System Design guide; if the hard drive specs are poor (hey, my 100+ GB DB is in a single drive system, woohoo!), prepare for the worst.