One other thing; if this does end up being an issue with disk space it is worth considering patch 5.3.0.40.6 or later since improves database management processes
This cumulative patch includes fixes/enhancements related to disk management to avoid following issue
CSCtz24314: ACS 5.x *still* runs out of disk space
and also fix for
CSCua51804: View backup fails even when there is space in disk
Following is taken from the readme for this patch
The Monitoring and Reporting database can increase when as records are collected. There are two mechanisms to reduce this size and prevent it from exceeding the maximum limit.
1. Purge: In this mechanism the data will be purged based on the configured data retention period or upon reaching the upper limit of the database.
2. Compress: This mechanism frees up unused space in the database without deleting any records.
Previously the compress option could only be run manually. In ACS 5.3 Patch 6 there are enhancements so it will run daily at a predefined time, automatically when specific criteria are met. Similarly by default purge job runs every day at 4 AM. In Patch 6 new option provided to do on demand purge as well.
- The new solution is to perform the Monitoring and Reporting database compress automatically.
2. New GUI option is provided to enable the Monitoring and Reporting database compress to run on every day at 5 AM. This can be configured under GUI Monitoring And Configuration -> System Operations -> Data Management -> Removal and Backup
3. Changed the upper and lower limit of purging of Monitoring and Reporting data. This is to make sure at lower limit itself ACS has enough space to take the backup. The maximum size allocated for monitoring and reporting database is 42% of /opt( 139 GB). The lower Limit at which ACS purges the data by taking the backup is 60% of maximum size Monitoring and Reporting database (83.42 GB). The upper limit at which ACS purges the data without taking backup is 80% of maximum size Monitoring and Reporting database (111.22 GB).
4. The acsview-database compress operation stops all services till 5.3 patch 5 , now only Monitoring and Reporting related services are stopped during this operation.
5. Provided “On demand purge” option in Monitoring and Reporting GUI. This option will not try to take any backup, it will purge the data based on window size configured.
6. Even if the “Enable ACS View Database compress” option is not enabled in GUI then also automatic view database compress will be triggered if the physical size of Monitoring and Reporting database reached to the upper limit of its size.
7. This automatic database compress takes place only when the “LogRecovery” feature is enabled, this is to make sure that the logging which happens during this operation will be recovered once this operation is completed. ACS generates alert when there is a need to do automatic database compress and also to enable this feature.
8. Before enabling “LogRecovery” feature configure the Logging Categories in such way that only mandatory data to log into Local Log Target and Remote Log Target as Log collector under System Administration > ... > Configuration > Log Configuration
This “LogRecovery” feature can recover the logs only if the logs are present under local log target.
9 This automatic database compress operation also performed only when the difference between actual and physical size of Monitoring and Reporting database size is > 50GB.
10 The new CLI “acsview” with option “show-dbsize” is provided to show the actual and physical size of the Monitoring and Reporting database. This is available in “acs-config” mode.
acsview show-dbsize Show the actual and physical size of View DB and transaction log file
