Citect Historian 2016 Tag Configuration.

Hello All,

I am not sure about weather its a right forum to discuss about citect historian 2016 configuration, I apologise for that.

Actually we had Citect Server as a Datasource for Citect historian2016. We added some Historize trend tag from citect scada into Historian.

Now upon polling for data for that perticular tags using citect historian excel tool, data is comming too late. To check further we LOGGED into SQL database and run qyuery there to pulled tag data however we are facing same performance of slow data retrival.

Further to improve performance, we run maintanance schedule of a databse as well but still perfomance not improved.

Kindyl advise any missing procedure/checkpoint on Citect Historian side we have to run when we modify the Historian Tags.

Warm regards

Hemant

Parents
  • Unfortunately, we don't have a topic specifically for Citect Historian on Heros HQ, so this one for AVEVA Historian (formerly Wonderware Historian) is fine to use, just be sure to include the "Citect" (as you have done). 

    Performance issues are generally better handled as a call/email to Tech Support because there are so many different aspects of performance and so many contributing factors that it is hard to handle in a post. 

    A few things to help clarify the scenario, though:

    1. Is the problem with latency (data is not available as soon as you expect--e.g. the "latest" value is always >5 minutes old, but returns quickly)?
    2. Is the problem more with response time (a query takes longer than you expect to complete--e.g. a query returning a few rows takes 5 minutes to complete). 
    3. This seems to be a change since adding the new tags. Is this a difference in the "new" tags or has it impacted performance of previously existing tags, too?
    4. Be sure you understand the actual data change rate for the tags with performance problems and how this might impact the workloads. For example, a tag stored at a 1-second update rate is much more demanding than one stored at a 1-minute rate--both in terms of the storage workload and the query workload. 
    5. From using Windows Perfmon and/or Task Manager, can you tell which key systems resources are the limiting factor (CPU, memory, disk)? How does that resource usage of the background storage load compare to the load when actively querying?

    Since Citect Historian is fundamentally a SQL database application, it will eventually be a victim of degrading performance as table sizes grow. Reindexing can help with that, but the only real way to alleviate that is to purge rows from the table (e.g. keep less historical data). 

    This isn't an immediate fix, but also consider migrating to AVEVA Historian. Although it does use SQL Server to hold relatively static configuration data, it stores the detailed historical data in external time-series files that avoid those limitations.

    Also be aware that ~3 years ago AVEVA announced the formal end-of-support for Citect Historian at the end of this year with AVEVA Historian as the recommended replacement. 

Reply
  • Unfortunately, we don't have a topic specifically for Citect Historian on Heros HQ, so this one for AVEVA Historian (formerly Wonderware Historian) is fine to use, just be sure to include the "Citect" (as you have done). 

    Performance issues are generally better handled as a call/email to Tech Support because there are so many different aspects of performance and so many contributing factors that it is hard to handle in a post. 

    A few things to help clarify the scenario, though:

    1. Is the problem with latency (data is not available as soon as you expect--e.g. the "latest" value is always >5 minutes old, but returns quickly)?
    2. Is the problem more with response time (a query takes longer than you expect to complete--e.g. a query returning a few rows takes 5 minutes to complete). 
    3. This seems to be a change since adding the new tags. Is this a difference in the "new" tags or has it impacted performance of previously existing tags, too?
    4. Be sure you understand the actual data change rate for the tags with performance problems and how this might impact the workloads. For example, a tag stored at a 1-second update rate is much more demanding than one stored at a 1-minute rate--both in terms of the storage workload and the query workload. 
    5. From using Windows Perfmon and/or Task Manager, can you tell which key systems resources are the limiting factor (CPU, memory, disk)? How does that resource usage of the background storage load compare to the load when actively querying?

    Since Citect Historian is fundamentally a SQL database application, it will eventually be a victim of degrading performance as table sizes grow. Reindexing can help with that, but the only real way to alleviate that is to purge rows from the table (e.g. keep less historical data). 

    This isn't an immediate fix, but also consider migrating to AVEVA Historian. Although it does use SQL Server to hold relatively static configuration data, it stores the detailed historical data in external time-series files that avoid those limitations.

    Also be aware that ~3 years ago AVEVA announced the formal end-of-support for Citect Historian at the end of this year with AVEVA Historian as the recommended replacement. 

Children