Article Content

This document explains how to determine if an RSA Identity Governance & Lifecycle database has tables which are large and may benefit from a purge.

Large tables in a database may have the following negative impacts to the product

Poor performance within the UI

Longer and larger database backups/restores

Long run times for database statistics

Tasks

The easiest way to get an understanding of the RSA Identity Governance & Lifecycle database size is to run a Statistics Report.

From the UI select Admin > System from the menu.

Click the Diagnostics tab.

Click Create Report as depicted below:

After clicking Create Report and refreshing the page, there will be a new report entry placed in the table below the button. Note that the View, Download and Delete buttons are greyed out during report compilation.

Once the report is complete the buttons will be enabled.

Upon clicking on the View button an HTML page will be displayed which includes a number of metrics about the current implementation. For this document the sections of interest are entitled

Aveksa Database Size Summary

Aveksa Internal Table Summary

From the screen shot above, specifically the Aveksa Database Size Summary, we learn that the size of all tables summed equals 37.51 GB and the sum of all tables is 38.92 GB. The Aveksa Internal Table Summary will then list all tables, alphabetically listed, and for each table the following is displayed

Table Name

Number of Rows

Last Analyze Date, which is the date when database statistics were run on the table

Table Size (MB)

Index Size (MB)

Number of Indexes

Number of valid Indexes

Number of non-valid indexes

One can either

Scan this table and look for tables which have a large Table Size (MB) value, or

Highlight and copy the entire table and paste it into a spreadsheet application, whereby one can then sort the data based upon the fourth column named Table Size (MB).

If the following tables are among your top N tables, they are eligible for a purge

Description: This table represents the same data represented in the aveksaServer.log. It is governed by Admin > System > Logs tab > Settings button and the field entitled Database Retention N days, as depicted:

Configuring N days will increase/decrease the table size, as will a change to debug levels captured.

Purge: To purge from this table one can configure Database Retention N days as described above

Description: This table represents the data which is displayed primarily within a job detail page as from Admin > Monitoring and specifically the link named Database Logs for Run ###, for example:

And the data represented behind the link Database Logs for Run ID ### is similar to what is seen here:

To which this data is used so as to understand the database packages and procedures, along with duration, that were called to complete the job. Often times, this is the largest table in the schema for a single job under Admin > Monitoring can add from hundreds to thousands of rows to this table.

Purge: To purge from this table one can run the following SQL statement as the Oracle database user avuser to remove all data in the T_AV_JOB_STATS table that is older than 90 days:

Description:If Access Fulfillment Express (AFX) is installed, this table holds log messages that are also logged in the connectors log file on the Linux host. Data from this tab is displayed in the UI at AFX > Servers > Logs tab and the AFX > Connectors tab:

Purge: To purge data from T_AV_AFX_LOG_MESSAGE one can do the following:

Prior to version 6.9.1

There is no procedure available to purge T_AV_AFX_LOG_MESSAGE table.

On version 6.9.1

As the oracle database user run the following SQL to remove all data in the T_AV_AFX_LOG_MESSAGE table that is older than 90 days.

EXECUTE Data_Retention_Pkg.Prune_Application_Log(SYSDATE-90);

On version 7.0 or later

T_AV_AFX_LOG_MESSAGE will be purged per the same parameter for purging T_AV_APPLICATION_LOG.