Cisco Cisco Workload Automation 6.3 User Guide

Page of 42
19
Cisco Systems, Inc.
www.cisco.com
3
Initial Configuration Recommendations
This chapter describes some initial configuration tasks that are recommended for most CWA systems when getting 
started with CWA:
History Retention
It is important to decide as soon as possible what history retention levels you want to maintain for your CWA system 
because:
History retention values play a LARGE part in CWA performance.
Purging history files is a very manual process. 
So, it is recommended to only keep the amount of history required for live operation. Often users set up exports of certain 
fields in the database to be offloaded to an archival database in case audits need to be stored in and accessed in the 
future.
Note: 
Warning: If you are upgrading an existing system and already have a large amount of history you wish to purge, 
please open a case with TAC to review strategy for reducing history. There are minor mistakes that can bring your system 
down. There are methods for avoiding purging too much history at once. 
To configure history retention:
1.
Open the CWA Web or Java Client.
2.
From the Activites menu, choose System Configuration.
3.
On the Master tab, set these parameters:
Operator Alert Retention—The number of days to keep the alert history. Affects the Operations-> Alerts panel.
Trigger History Retention—The number of days to keep event trigger history. Affects the Event definitions, History 
tab.
Automatic Daily History Cleanup—The option that checks whether or not to purge history daily. If it is unchecked, 
you will keep history forever, but the information in the database will still be made with an expiry date in mind, it will 
just never be removed.
Warning:
 Since all information has an expiry date, if the Automatic Daily History Cleanup is checked, the first purge will 
wipe out a MASSIVE amount of data all at once, most likely clogging the transaction log and bringing down the system 
one way or another. The exception to this rule is msglog, which does not have an expiry date, so any changes to the 
"error" or "audit" values in "operations->logs" should be done incrementally, or massive amounts of msglog table 
history will be purged all at once, based on the value input during the previous date, filling up the transaction log and 
bringing your system completely down.