It is important to decide as soon as possible what history retention levels you want to maintain for your TES system because:
- History retention values play a LARGE part in TES 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.
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:
Step 1 Open the TES Web or Java Client.
Step 2 From the Activites menu, choose System Configuration.
Step 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.
Step 4 On the Logging tab, set these parameters:
Audits —The number of days to keep audits. Affects the audit log of Job Activity jobs, or the Operations->Logs. This corresponds to the msglog table in the database.
Errors —The number of days to keep the messages that show up as the "error" type, in Operations->logs. Also the msglog table.
Step 5 On the Defaults tab, set this parameter:
Job History Retention —The number of days to keep the job history retention for each of the job instances in the job activity. Every job instance that runs is assigned a date on which it is to be purged based off of it's job definition's Options tab -> History Retention value. So if a job ran when that number was 100, it won't expire until 100 days from now, even if the job's definition is edited, since the job instance information has already been written. Mass edits on the backend would compromise the stability of the database, so to avoid that, edits to the job retention values in the job definition do not affect job instances that have already run.