It is not recommended that Geo SCADA runs on systems which do not have the required exclusions configured. Doing so risks Geo SCADA database corruption and ongoing performance problems
Many defragmentation products claim to "transparently" defragment files without interfering with a process's access to files. In some cases however it is possible for these programs to still cause performance problems with the Geo SCADA database, and possibly leading to database corruption.
Simply put, exclusions similar to as documented in Anti-virus Scan Exclusions should be set for defragmentation software, however as the purpose of defragmentation software on Geo SCADA machines is typically to improve the performance of Geo SCADA then exclusions do not necessarily make sense. The rest of this article is designed to help diagnose possible issues.
Memory Resident Streams
The memory resident Streams, such as the Config and Data streams, are written to disk once a minute if changed. The data is saved to a temporary file, the existing file deleted and then the temporary file is renamed to the correct name. As this happens often then the chances of file fragmentation on disk are minimal and fairly transient, and as these files are only read during the database start-up the effects of fragmentation are also minimal. If you watch a directory containing the Config and Data streams you may very briefly see files named similar to 'TempDbConfig0001' or 'TempDbData0001'. These should disappear almost immediately. If these files exist for more than a minute then this is signs of something interfering with the file write. Any Temp files older than a hour can be deleted safely, any files more recently should be kept in case of a database restart and the database being corrupt.
Where possible any file storage of the memory resident streams should just be excluded from defragmentation as they are not necessary and causes more problems than they solve.\
Disk Resident Streams
Disk resident Streams such as historic data values will greatly benefit from defragmentation. These streams do not create a fresh file each minute and instead either creates new files or appends data to the existing files as necessarily which will cause heavy fragmentation long term. Refer to the Streams article for how the files are arranged for each stream.
For example, when a new historic value is received from the field it is first stored in memory. Once a minute Geo SCADA will flush the historic in memory to disk for a maximum period of 1 second (by default, can be changed). Any remaining data in memory will be flushed the following minute. When this flush happens to ensure all the data can be flushed successfully speed is important.
It is recommended that any defragmentation that does 'real time' defragmentation, such as Diskeeper, has the real-time function disabled as this has been shown to impact the flush speed of the data to disk. The file flush can be observed by enabling HISREC and JNLREC in the DB logging and observing each file written to disk, note that the event journal is slightly less impacted due to the way those files are structured.
Scheduled defragmentation can still occur, and suitable planning performed to perform the action at a time that does not conflict with other operations, such as backups and reporting.
Each defragmentation software works in different ways, and between different versions of the same product, as such we can't provide definitive information. The above information is provided to help you understand how the software works and the things you need to consider. Defragmentation software should not be installed without prior configuration, monitoring and testing within a suitable environment.