How to Clean Up the Task Persistence Database for Performance Tuning

Often in Identity Manager implementations, the concept of “cleaning up the database” is overlooked or not done as often as it should be. The consequence of not cleaning up the database is degraded performance the longer an organization goes without cleansing the environment. At some point, it’s possible that the database tables would fill up, and if there have not been regular cleanups, then all the records in the tablespace(s) would have to be purged. This post will describe how to clean up the task persistence database, and the recommended frequency as to when the cleanup job should be executed.

There are 5 tables (as of version 14.3) that are directly involved with task persistence activity.

  • Tasksession12_5
  • Object12_5
  • Event12_5
  • Event_Object12_5
  • Lock12_5


  • The Task Persistence Database and the Archive Database are pointing to the same datastore. 

Tasks and Steps

Task 1: Verify the datasource pointers for the Task Persistence and Archive Database

1. Log into the server where the application is installed

2. Navigate to the following location: <IDM Home Folder>/standalone/configuration

3. Open the “standalone-full.xml (For standalone environments)” or “standalone-full-ha.xml (For clustered environments)”.

4. Verify that the datasource settings for Task Persistence and Archive look like the following:
Note: The user and password entries for each datasource should be the same.

5. The “security domain” section specifies which datasource is being referenced for each database. With Oracle, the schema that is being used for both datasources is the same.
Note: If these two are different, an IDM administrator will need to have the Archive database backed up (if there is any data) and change the file.

Task 2: Check the Database and Message Health

1. Log into the Identity Manager Console
Note: Make sure the account being used has permission to perform “Task Runtime Management” tasks.

2. Click on the “Task Persistence Monitor” task under the System 🡪 Task Run Time Management menu.

3. Click “Check Database” and “Check Message Health
a. Note: The “Check Database” button will give row counts for some of the tables. Ignore the colored bars on the right as they do not provide anything meaningful.
b. Note: The “Check Message Health” button will run a single task with 300 events to test the JMS infrastructure. If the completed tasks do not show a value of 300, then there is an issue with JMS or a database with high row counts or both. For JMS issues, refer to the following post:
How to Check JMS Journals with JBoss/Wildfly (This should link to the other blog post with this title)


a. Note: Row counts greater than 50,000 are not recommended. The table that will fill the quickest is the “Lock12_5” table since that table is involved in every aspect of task and event processing.
b. Note: If the number of rows gets to be in the millions, it is better to delete all the entries in the table. Do not delete the table itself as that will negatively affect the schema.

Task 3: Run the Cleanup Task

1. Click on the “Cleanup Submitted Tasks” task under the System menu.

2. Select “Execute Now” or “Schedule new job

3. Specify a minimum age that will determine which tasks get deleted and which ones remain

4. Check the “Cleanup via Stored Procedure” option


a. Note: The “Cleanup via Stored Procedure” option only works if the Task Persistence and Archive databases are pointing to the same datasource.
b. Note: For additional information about the values on this screen, please refer to the following documentation:

6. Click “Finish” and the task with either run immediately (if Execute Now was selected) or will run in the future (if Schedule new job was selected).
Note: Once the job has finished, Task 1 can be repeated, and the health of the database and message queue can be validated post-cleanup.

Recommendations and Considerations for Cleaning Up Submitted Tasks


At Information Security Xperts, Inc. we recommend daily cleanup tasks to be done on the database. The number of tasks that should be processed vary depending on how many tasks the system processes in a day. 


A few considerations to keep on the forefront:

  1. Once a task is archived, a certain checkbox must be selected with Viewing Submitted Tasks that allow for archived tasks to appear.
  2. Any archived task that went through workflow approval will be split into separate databases: The Archive database and the WPDS database. This means that the workflow approval for archived tasks cannot be seen in the UI, and direct database queries must be run to retrieve that data.
  3. If the Archive and Task Persistence databases do not reference the same datasource, cleanup via “Stored Procedure” will not work and the task will hang in progress. 

Summary of Cleaning Up The Task Persistence Database

In conclusion, every organization that utilizes Symantec Identity Manager should be cleaning up the Task Persistence database to maintain a high performance in the environment. While there are plenty of other tuning methods that can enhance performance, regularly scheduled cleanups will provide a benefit to performance for years to come. 

Looking for additional help with the cleanup of the Tas Persistence Database? ISX Consulting is an elite IAM security firm that offers boundless expertise in a range of cybersecurity and business process services, including Symantec Identity Manager. Take your interoperability to the next level, and contact an ISX consultant today.

ISXHow to Clean Up the Task Persistence Database for Performance Tuning

Related Posts

Leave a Reply

Your email address will not be published.