Rapid database growth

Products

CA Automic Workload Automation - Automation Engine

Issue/Introduction

Environment

Release: AOATAM99000-9.0-Automic-One Automation Tools-Application Manager
Component:

Resolution

Detailed Description and Symptoms

Customers report that their Automic database is growing at an unusual rate. Since all customer databases are different, this is up to the customer to decide and monitor how large the database is during a normal cycle and how much growth is 'too much.'

Investigation

The Automic database maintenance plan is well documented in the Automic Operations Manager documentation. This includes running your Automic.Archive, Automic.Reorg, and Automic.Unload utilities on all clients (including Client 0). If you are not running this on a regular, consistent basis then this is your first order of business. Maintenance should be run daily, weekly or monthly depending upon your business cycle and enterprise size.

If you are already set up to run a Automic Maintenance program then the first place to look is in your log Utility log files. These are usually found in the Utility/temp directory on the machine that has the Utilities installed on them. The relevant log files will be the ucybdbar_log_XX.txt (archive), ucybdbre_log_XX.txt (reorg), and ucybdbun_log_XX.txt (unload) files.

Solution

ARCHIVE
The first file to look at will be the archive log file. This utility sets the flag that will determine which files will be marked for reorganization. The line near the bottom of the log file like this:
U0003549 ' 2075' 'UPDATE
Tells you how many records were archived.
If the files are archiving correctly, then the second file to look at will be the reorganization log file.

REORG
In order for the reorg to run successfully, the archive must have been run successfully UNLESS the UCYBDBre.ini file has set:
no_archive_check=1
One of the entries to look for will be the number of deletion flags set:
U0032190 Number of deletion flags set in table 'MELD': '0'
The above entry tells us that the reorg did not actually flag anything to be unloaded. This could point to an archive failure.

UNLOAD
The unload log file should have records in it that state which records are being deleted from the significant tables like this:
U0037109 Reorganize table 'AH', records '965967' / '975723' reorganized
This tells us that the unload has deleted almost a million records and seems to be running correctly.