Welcome to the new Schneider Electric Community

It's your place to connect with experts and peers, get continuous support, and share knowledge.

  • Explore the new navigation for even easier access to your community.
  • Bookmark and use our new, easy-to-remember address (community.se.com).
  • Get ready for more content and an improved experience.

Contact SchneiderCommunity.Support@se.com if you have any questions.

Close
Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we’ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
84608members
353905posts

Reducing the size of historical / Alarm Summary files on PC.

EcoStruxure Geo SCADA Expert Forum

Find out how SCADA systems and networks, like EcoStruxure Geo SCADA Expert, help industrial organizations maintaining efficiency, processing data for smarter decision making with IoT, RTU and PLC devices.

Solved
hemanthv
Ensign
Ensign
0 Likes
5
1667

Reducing the size of historical / Alarm Summary files on PC.

Hi,

we have a systems with 24550 tags counts.  We have noticed that there are multiple number  of files in Journal folder and total size increase to 6GB. 

1. How to reduce the number of files.

2. How do I reduce the file size or increase the file size.

3. How to optimize the file size to improve data transfer between redundant servers.

4. Is it possible to get all historical enable tags using SQL script.

 


Accepted Solutions
geoffpatton
Commander
Commander
0 Likes
0
1660

Re: Reducing the size of historical / Alarm Summary files on PC.

If you are really just concerned with the Sync time then go into the Server configuration and set the Archive for the Event Journal and Historic Data to 1 week or a longer time frame that you are sure you won't want to edit the events or history. It won't have to sync anything that is older than the Archive setting, because that data is set to not be changeable so it can be archived if you want to archive it. Personally I don't archive anything, it is a pain in the butt because it is made to archive to removable media. Where history preservation is important my customers rely on system backups.

 

Size is controlled by how much is written to the Events or History.

On your points with history enabled, from the Historic tab, you can apply compression to limit how much is being written.

 

Points and other database objects that have events configured will record an event every time that condition is true.

If you think some of these events that are configured are unnecessary set them to None and this will reduce the quantity.

 

Yes, you can check for the History setting from SQL, but I don't remember what you need to do to get it.

I would just use the Bulk Edit tool. Check the entire database then select each point type and then check the historic enabled. Export it to an excel file.

See Answer In Context

JChamberlain
Schneider Alumni (Retired)
Schneider Alumni (Retired)
0 Likes
1
1653

Re: Reducing the size of historical / Alarm Summary files on PC.

It's kinda odd that you're talking about historic and alarm summary in your title but only the event journal in your post. Most of the above will apply to all three, but I'd encourage you to read the relevant help pages for each.

 

1. The number of files is a function of the number of objects and the time period, and the stream size. We don't usually recommend changing the stream size, this can have an impact on performance. These settings are on server config under Historic Configuration.

 

2. The file size is a function of the number of entries in the time period. You should identify overactive objects and resolve issues with them, whether that is a physically noisy point, inadequate compression or DNP3 event generations settings, or an outstation that is raising a lot of alarms. For existing data, running Compress Database from the server icon and the Start Historic Optimisation method on the root group historian aggregate can help (again, look them up in Help for details on what they do).

 

3. You can compress data that is sent between redundant servers by ticking the compress check box in the partner settings. This has a performance penalty associated - refer to Help for guidance.

 

4. Yes, but you would need to JOIN every table that has the aggregate on it. This will vary with what drivers you're using.

 

SELECT
FULLNAME, HISTORIC
FROM
<list of tables>

 

To get the tables you'll need to know how to use the schema. CDBPoint I think will have everything you're concerned with. From there dig down to find what is relevant to your system that has the historic aggregate.

See Answer In Context

sbeadle
Janeway Janeway
Janeway
0 Likes
0
1649

Re: Reducing the size of historical / Alarm Summary files on PC.

This query will list objects with historic data enabled:

SELECT FullName from CHistory INNER JOIN CDBObject ON CHistory.Id=CDBObject.Id

Edit this SQL into any query window - or use the QueryPad utility (remember to hit ctrl-Enter to run a query. 

See Answer In Context

BevanWeiss
Spock
Spock
0 Likes
1
1642

Re: Reducing the size of historical / Alarm Summary files on PC.

I would say that the most likely cause of incredibly large 'Historic' data is the incorrect setting of 'Event' severity.

It is an absolute bug-bear of mine when people use this setting.

 

An Event Journal entry takes up 768bytes.  A historical data entry takes 32bytes.

So my (not so humble) opinion is that you should NEVER set anything with 'Event' severity type.  If you care about the state of something enough, then it possibly should be an alarm.

If you only care about the state of it retrospectively (i.e. when you want to audit it, or similar later) then you can probably handle this entirely well with just historical data, and not having an Event entry.

 

I'd also follow the advice of the others 🙂


Lead Control Systems Engineer for Alliance Automation (VIC).
All opinions are my own and do not represent the opinions or policies of my employer, or of my cat..

See Answer In Context

5 Replies 5
geoffpatton
Commander
Commander
0 Likes
0
1661

Re: Reducing the size of historical / Alarm Summary files on PC.

If you are really just concerned with the Sync time then go into the Server configuration and set the Archive for the Event Journal and Historic Data to 1 week or a longer time frame that you are sure you won't want to edit the events or history. It won't have to sync anything that is older than the Archive setting, because that data is set to not be changeable so it can be archived if you want to archive it. Personally I don't archive anything, it is a pain in the butt because it is made to archive to removable media. Where history preservation is important my customers rely on system backups.

 

Size is controlled by how much is written to the Events or History.

On your points with history enabled, from the Historic tab, you can apply compression to limit how much is being written.

 

Points and other database objects that have events configured will record an event every time that condition is true.

If you think some of these events that are configured are unnecessary set them to None and this will reduce the quantity.

 

Yes, you can check for the History setting from SQL, but I don't remember what you need to do to get it.

I would just use the Bulk Edit tool. Check the entire database then select each point type and then check the historic enabled. Export it to an excel file.

JChamberlain
Schneider Alumni (Retired)
Schneider Alumni (Retired)
0 Likes
1
1654

Re: Reducing the size of historical / Alarm Summary files on PC.

It's kinda odd that you're talking about historic and alarm summary in your title but only the event journal in your post. Most of the above will apply to all three, but I'd encourage you to read the relevant help pages for each.

 

1. The number of files is a function of the number of objects and the time period, and the stream size. We don't usually recommend changing the stream size, this can have an impact on performance. These settings are on server config under Historic Configuration.

 

2. The file size is a function of the number of entries in the time period. You should identify overactive objects and resolve issues with them, whether that is a physically noisy point, inadequate compression or DNP3 event generations settings, or an outstation that is raising a lot of alarms. For existing data, running Compress Database from the server icon and the Start Historic Optimisation method on the root group historian aggregate can help (again, look them up in Help for details on what they do).

 

3. You can compress data that is sent between redundant servers by ticking the compress check box in the partner settings. This has a performance penalty associated - refer to Help for guidance.

 

4. Yes, but you would need to JOIN every table that has the aggregate on it. This will vary with what drivers you're using.

 

SELECT
FULLNAME, HISTORIC
FROM
<list of tables>

 

To get the tables you'll need to know how to use the schema. CDBPoint I think will have everything you're concerned with. From there dig down to find what is relevant to your system that has the historic aggregate.

sbeadle
Janeway Janeway
Janeway
0 Likes
0
1650

Re: Reducing the size of historical / Alarm Summary files on PC.

This query will list objects with historic data enabled:

SELECT FullName from CHistory INNER JOIN CDBObject ON CHistory.Id=CDBObject.Id

Edit this SQL into any query window - or use the QueryPad utility (remember to hit ctrl-Enter to run a query. 

BevanWeiss
Spock
Spock
0 Likes
1
1643

Re: Reducing the size of historical / Alarm Summary files on PC.

I would say that the most likely cause of incredibly large 'Historic' data is the incorrect setting of 'Event' severity.

It is an absolute bug-bear of mine when people use this setting.

 

An Event Journal entry takes up 768bytes.  A historical data entry takes 32bytes.

So my (not so humble) opinion is that you should NEVER set anything with 'Event' severity type.  If you care about the state of something enough, then it possibly should be an alarm.

If you only care about the state of it retrospectively (i.e. when you want to audit it, or similar later) then you can probably handle this entirely well with just historical data, and not having an Event entry.

 

I'd also follow the advice of the others 🙂


Lead Control Systems Engineer for Alliance Automation (VIC).
All opinions are my own and do not represent the opinions or policies of my employer, or of my cat..
hemanthv
Ensign
Ensign
0
1614

Re: Reducing the size of historical / Alarm Summary files on PC.

thank you all..!