Hey guys,
At 7:13 this morning most if not all of my history tags created duplicate ID’s in the sqlth_te table. If I query these ID’s in the history partition table there is one row associated with it with quality 600. This is the same for all of the history tags I changed. It caused all of the trends to spike down to 0 because of the null value in this row. I checked the console and there was a message about some kind of loss of communication to the backup server at this time but not much else. Any ideas what could have caused this? I have to go through and manually delete these ID’s to get the trends to look normal. Thanks!
Hi,
Sorry for the late reply! This is a tad tough to answer without a little more info. I would have to guess that the backup node must have become active temporarily, and that that is responsible for the new entries, but it’s hard to say why it did that.
You mentioned, “This is the same for all of the history tags I changed.”. Were you changing tags at the time? What do you mean exactly by that?
And does that screen shot represent 1 single tag, or perhaps a few? Id 48 appears to have been retired back in october, I’m guessing due to an upgrade (the change from querymode 1 to 3 was something that happened in 7.3+).
Id 662 was created on 12/5, apparently. This is the one I’m curious about, could it possibly be a different tag? Id 673 seems to be from the failover.
Ignoring everything else, it’s basically acting like the scan class has been changed. Did you change that recently (perhaps on 12/5?)?
Regards,
Also, as a sanity check, we should look at the internal databases on both sides to verify that they’re properly in sync.
On both sides, go to Console>Advanced. Pick one tag, and look it up on both sides in SQLTAG and SQLTAGPROP. Something like:
SELECT * FROM SQLTAG where path like 'haccp temperatures%' and name like 'tagname'
SELECT * FROM SQLTAGPROP where tagid={Tag ID From Above}
Make sure that the data looks identical on both sides.
Regards,
Actually, I’ve had a realization, and think I know what happened. It think it’s a problem with caching in the tag history system in relation to redundancy.
You changed the scan class of some tags on the 5th. On the 6th, the system briefly failed over. The backup had the old values cached, so it thought the scan class was wrong, and inserted a new row. Basically, the backup node needs to update its cache with the latest values when failover occurs.
Besides confirming that you did change the scan class, I don’t think you need to anything else. I’m pretty sure this is what happen.
Regards,
And also, I should point out, that there really isn’t any critical problem to this, as the history system is built to handle multiple ids for a specific tag path. Your problem is still that quality 600 values are causing the charts to display 0, and that quality was probably logged on the failover because the real value hadn’t come in yet. Still, we’ll try to get this fixed for the 7.5.5 final release.
Whew, ok, 4 unanswered posts in a row is a new record for me, obviously you can tell I’m a bit hyper this morning.
Haha, wow… yeah, that was a lot of information…
Yes, you are correct. I did change the scan class for those tags recently (I had them at 5 seconds and changed them to 1 minute). And you are also correct that the problem seems to be the 600 quality. Seems to be the same problem as the other related post of mine.
I’m still waiting for another 600 quality row to come in so I can get you that information that you wanted but it hasn’t happened yet. It seems to come and go randomly.
