When data enters the system (i.e. point update from an outstation, manual handdress, etc) the data is stored in RAM before being flushed to disk.
In ClearSCADA 2005, the flush rate was configured by a number of data items to flush every configured interval. This meant that if more data items updated per interval than were configured to be flushed then not all the data would be flushed at once. For example if the flush interval was every 60 seconds (default value), flushing 100 data items each time with a system running at 1000 data items updating a second then it will take 10 minutes for the last bit of data to be written to disk. However, during those 10 minutes more data would have come in from the earlier points that had been flushed. All this data is stored in memory until flushed using a round-robin approach to ensure all data is flushed. During the flush, if it takes longer than 2 seconds to flush the configured data items the flush is aborted and the next flush starts where the previous one stopped.
What this means is that, with the above example, if the server failed, then at least 10 minutes worth of data for some points could not be stored (note this is talking about writing to the local historic store, not any standby servers) and is therefore "lost". If a server is shut down in a controlled manner then the data is fully flushed before the system stops (which is a reason why ClearSCADA can take some time to shut down).
This also means that memory usage can creep up whilst the data is waiting to be written, but assuming the data input rates are fairly constant then once it has got round all points then the memory levels should plateau. Below is a spreadsheet that will calculate how long until the memory plateaus and at what approximate value.
File: Memory_footprint_of_historic_cache.xls (See links below)
With the spreadsheet, enter the point updates a second and the currently configured flush interval and amount. See the "Minutes for a full cycle" and "Size (MBytes)" for the relevant information.
The flush process has been improved for ClearSCADA 2007. When the configured interval comes around, ClearSCADA writes as much historic data to disk as it can within 1 second and then waits until the next interval (note that adaptive flushing can increase the time per interval should there be too much data in memory awaiting flush). This has the advantage that if the historic is stored on fast disks (e.g. write cache enabled in a RAID or usage of a SAN) such as on systems that will process a large amount of data, then more data will be flushed in those seconds.
An unscheduled flush can be done using scxcmd's hisflush feature and the time given to the flush operation is logged in the DB log file, i.e.:
16-JUL-2007 15:51:47.052 10E4 [DBHIS] Flush files in up to 1000 mS...