1 EVENT ARCHIVING CONFIGURATION:
1.In windows explorer navigate to your second partition and set full access to MNGR user account
- Right click on Partition itself and select properties
- Navigate to Security Tab
- Click “Edit” button , then “Add” and add MNGR user
- Allow MNGR for full access
2.On your second partition create new folder and rename it to “EventArchive”
3.Share the folder created in point 2 and provide MNGR user with Full access to the share
- Right click on the folder and select properties
- Navigate to “Sharing” tab and click “Advanced Sharing” button
- Check “Scare this folder” check box
- Select “Permissions”, then “Add” and add MNGR user with Full control
4.Once done, configure this share in Event Archive Config page in Station as a place to store the archives ( e.g \\serverA\EventArchive )
5.Verify that the Online/Archive period are set to the same period for optimal performance
6.Configure a time for the archive, not 00:00 or 01:00 (time of scheduled task in Experion), also verify that it does not clash with a scheduled backup.
7.Verify that the archive is set to “Start Automatically”.
2 HISTORY ARCHIVING MOVE CONFIGURATION
1.In windows explorer navigate to your second partition and set full access to MNGR user account
- Right click on Partition itself and select properties
- Navigate to Security Tab
- Click “Edit” button , then “Add” and add MNGR user
- Allow MNGR for full access
2.On your second partition create new folder and rename it to “HintArchive”
3.Share the folder created in point 2 and provide MNGR user with Full access to the share
-
- Right click on the folder and select properties
- Navigate to “Sharing” tab and click “Advanced Sharing” button
- Check “Scare this folder” check box
- Select “Permissions”, then “Add” and add MNGR user with Full control
4.Configure the Share in Station for the History archive move path:
5. Get familiar with technote 269 or 294 and configure your history archive strategy. It is important that you should not exceed 100 folders across all History search path.
3 BEST PRACTIE
3.1 TPR about Event archiving fail(initialize the events database)：
description of the problem
In the third Uzbekistan China gas pipeline project, 3 stations server events archiving fail. Can’t manually events archiving. The online events totally 31999 items reach the maximum level.
Resolution Details/ Workarounds found
initialize the events database：
1.Change the backup serve as database only.
2.Input the command “hisint -event”
3.Restart the backup server but not Synchronous
4.Switchover the backup as primary
5.Change the new backup server as database only
6.Input the command ”hisint –event ” in new backup server
7.Restart the new backup server
8.After both servers running normal then synchronous the server.
Event arching normal, manually event archiving success.
3.2 How to set R400 event online period appropriately and estimate emsevents file size
Questions:
For prior R4xx, we recommend to keep both online and archive settings between 2 to 4 weeks. Now, for R400, is there any recommended settings? if yes is there any specific reason for this?
What is the event record size per record to use as estimation of calculation of emsevents file size?
Answers:
For R400 the PCT (Performance, Capacity, & Topology) recommendation is for a maximum of 1.2 million events in the online events file (i.e. the Events table), and that customers should choose their online/archive settings so that their database can stay within this limit. The appropriate online/archive period setting depends on the site’s event rate: a high event rate will cause the database to reach the 1.2 million event maximum sooner, so such a site would have to archive more often than a site with a low event rate.
For example, if a site has over 8,000 pieces of event per hour which can be observed on station event archiving display, 1200000 ÷8000÷24 = 6.25 (days), then we should choose at most 6 days as event online keeping.
The maximum event record size is around 2700 bytes – this is the size of an event which has a value for every column, and uses the maximum capacity for all string columns. Such an event almost never occurs, so 2700 bytes can be used to give a very conservative (over)estimate of how much space is required for the Events table (EMSEvents.mdf). There is also some overhead for the indexes, which are the EMS*.ndf files.