A system administrator asks: Upon reviewing the space being used by various tables in the PegaRULES database, we noticed that the following tables were large.
Can you provide some guidelines on purging these tables periodically for space management? Should they be purged? What is the recommended time frame? What are the recommended selection criteria?
Caution: In general, do not use native SQL operations to purge PegaRULES database tables, as the related Index- records may then contain dangling references to rows that have been deleted, and other database integrity requirements may be broken. Rather, follow the guidance below or advice from Global Customer Support.
The PegaRULES agent, one of three standard agents in every Process Commander system, ordinarily trims rows from certain tables, including the
PR_LOG table, on a scheduled basis.
As a first step, confirm that this agent is running regularly and the activity that performs the purging is enabled. To do this:
- Access the Rules by Type Explorer. Select SysAdmin > Agent Schedule to list Data-Agent-Queue instances.
- Review the Data-Agent-Queue instance named Pega-RULES.
- On the Schedule tab, confirm that the agent-wide Enabled check box is checked, and that the row containing the System-Cleaner activity is enabled. (In a multimode system, the agent needs to be enabled on only one node.) Update the check boxes and save the form if necessary.
- This agent normally runs every 86,400 seconds (once a day); you can choose a higher or lower frequency.
- Then, use the System Console (prMonitorServlet) to confirm that the agent is running and not failing.
To purge tables other than those purged by the PegaRULES agent, create an agent in your application RuleSet, following these steps:.
The standard activity Code-.SystemCleaner calls Log-.TrimLog to purge older records from specific tables. Create an activity or activities similar to Log-.TrimLog that selects and deletes the rows of the desired table(s), being careful about dependencies and relationships among database records.
- Create an activity (similar to Code-.SystemCleaner) that calls the activities you created in Step 1.
- Create a Rule-Agent-Queue instance named with your application RuleSet that calls the activity created in Step 2. Choose a schedule for this activity. In the Access Group field, choose an access group that provides all the application RuleSets needed to the agent.
Before you can enable the new agent, there must exist a Data-Agent-Queue instance (on one node) with the same name as the Rule-Agent-Queue rule. NOTE: Data-Agent-Queue instances are automatically created when a new Rule-Agent-Queue record is added and the agent manager recognizes the new agent. In a multinode system, update the Data-Agent-Queue records created by the agent manager to enable the queue on only one node.
Use the System Console to confirm that the new agent is running as scheduled.