Inherited a site with an Ignition 8.1 historian on it, about 300 tags off two ControlLogix and a handful of remote pump sites over radio, all landing in SQL Server. The database has gone from 3 GB to 43 GB in five weeks and the disk is at 90%.
So I checked the tag history settings and every analog is On Change, deadband 0, no minimum time between samples, sitting in the 1 second scan class. That's a row a second per tag on the noisy ones.
I turned partition pruning on to drop anything older than 90 days. Buys time, does nothing about the rate. IT offered more disk, which is the same thing again.
I know the answer is deadbands. What I want is a rule of thumb per tag type so I'm not guessing 300 times. One deadband across the lot to stop the bleeding and refine it later, or does that lose me the thing I'll actually want when something breaks?
What happens on the radio sites when the link drops and comes back? If those are store and forward at 1 second you get a burst of every sample when the link returns, and that's a chunk of your 40 GB on its own. Check one pump site's row count against a local tag of the same type.
Checked. Pump site tags have about 4 times the rows of a local tag of the same type, and the bursts line up with link drops in the gateway log. So I reckon the radios are part of it and the deadband is the rest.
Numbers we run, for what they're worth. Deadband off the alarm band rather than the range: about a tenth of the gap between normal and the alarm limit. A pressure sitting at 5 bar that alarms at 6 gets 0.1 bar. Flows, log the totaliser and not the rate, once a minute. Temperatures 0.5 degrees with a minimum of 10 s between samples, levels 1 percent and 30 s. Discretes on change, they're cheap.
Min Time Between Samples on every analog is the one that kills the every scan rows on its own. And average anything noisy in the PLC first, then the deadband stops chasing noise.
Someone did a decent article on the monitoring side: https://plctr.com/utilizing-plc-for-condition-monitoring-and-predictive-maintenance-in-manufacturing/
Applied that to the 60 worst tags by row count. Growth dropped from 1.3 GB a day to about 200 MB. Still more than I'd like, and the remote sites are still bursting on every reconnect.
Drop the radio sites to a 10 s scan class, pretty sure nothing on a pump changes faster than that, and the burst shrinks with it. Ours log at 10 s with 1% on a level and that's plenty.
Remote sites on a 10 s class, and all 300 tags now have a deadband and a minimum time. Growth is about 60 MB a day, from 1.3 GB. Disk went from 90% to 75% once pruning caught up.
So it was every analog on change with no deadband and no minimum time on a 1 s scan, and the radio sites dumping a backlog on top each time a link came back. Deadband at roughly a tenth of the alarm band, a minimum time everywhere, totalisers instead of rates, 10 s on the radio sites.
Two vibration tags genuinely need 1 s and I've left them, so they're about 30% of the rows now. Not sure what to do there, might be a job for their own database.
Thanks redgum, wandak.
1.3 GB a day down to 60 MB. IT can keep their disk.