IBM Support

Why is my Guardium internal database filling up?

Question & Answer


Question

If I see my Guardium internal database filling up how can I find the cause? What actions can I take to reduce the size of the largest tables in my Guardium internal database?

Cause

The Guardium internal database can fill up for many reasons. A general approach to resolving the situation can be found here:
What can I do if I see my Guardium Appliance getting full?

This guide should be used in conjunction with the above link to help resolve the problem. If you are unable to take any of the actions below, you will have to use the general steps in the link to lower the database size.

Answer

The reason for the internal database filling up can often be determined by analyzing the largest tables in the database. Each table has different processes that cause it to grow and different strategies for managing its size.

The first step is to check the top tables in CLI:

  • support show db-top-tables all

Example output:
 Table Size (M) | I/D % |  Unused(M) | Est. Rows | Name      
 -------------- | ----- |  --------- | --------- | ----------
         132526 |    17 |      22621 |  46144369 | GDM_CONSTRUCT_TEXT
          20669 |   213 |         25 |   6738570 | GDM_CONSTRUCT_INSTANCE
          19399 |   126 |         11 |   1051215 | GDM_POLICY_VIOLATIONS_LOG
           1038 |   241 |          4 |    254991 | REPORT_RESULT_DATA_ROW
            987 |   172 |         24 |    166504 | GDM_SESSION
            860 |    29 |          0 |    516276 | GDM_FIELD
            743 |   248 |          7 |     90036 | GDM_OBJECT


Below is a list of the most common top tables, causes for filling up and actions to stop the problem in the long term. The list is not exhaustive and this information should be used in conjunction with an overall purging strategy. Starting with your largest table, use the actions below to help reduce the size in the long term.

GDM_CONSTRUCT_TEXT

Cause
  • All data captured by a policy rule with "log full details" action is written to this table.
Actions
  • "log full details" should be used as little as possible in the policy. If this table is constantly filling up you should review your reports and policy definition to ensure you are not capturing excess traffic with this action.

  •  
GDM_POLICY_VIOLATIONS_LOG

Cause
  • All policy rules with alerting action, except "alert only" write to this table as well as sending alert by the defined method (e.g. syslog). Correlation alerts log to this table if "log policy violation" is selected in the definition.
Actions
  • Review the alerting rules in your policy. Ensure that they are not alerting excessively, for example "alert per match" is not used when "alert once per session" would be appropriate. If data needs to be forwarded to remote SIEM, but not seen in Guardium reports, use "alert only" action.
  • Check in the policy violations report GUI->Incident Management->Policy Violations for the most common alerts. A recent change in the environment may cause a spike in alerts, for example a new application may be creating 1000s of failed login requests. Investigate the cause of the most common alerts and modify the policy if appropriate.

  •  
REPORT_RESULT_DATA_ROW

Cause
  • The results of audit processes are stored in this table. They are only purged once they have been cleared from all receiver to-do lists and the conditions for removal in the definition are met (by default the results of the last five runs are kept). This table is not purged by purge started in the GUI.
Actions One or more of GDM_CONSTRUCT, GDM_FIELD, GDM_OBJECT, GDM_SENTENCE

Cause
  • These tables are known as "static" as they are expected to be of roughly constant size. However, in some cases the size can increase rapidly, for example if a monitored application uses many temporary objects.
Actions
  • Static tables are cleaned regularly by the data archive or export purge. On older versions or aggregators in rare cases you may have to manually start a "static orphans cleanup" process to remove static data that is no longer in use. On any appliance you can run the process manually via CLI->diag->4. Perform Maintenance Actions->12. Clean Static Orphans.
  • On Aggregators you can check the CLI command "store aggregator orphan_cleanup_flag" details in the knowledge center: Aggregator CLI commands.

GDM_EXCEPTION

Cause
  • The exception table can be filled with Guardium created exceptions (for example - parser errors) or exceptions from the monitored database (for example - SQL errors).

Actions
  • There are many types of exception logged in this table. The first step is to identify which are the most common. You can use predefined reports in Exceptions domain to find which exceptions are most common.
  • "Exceptions Type Distribution" will show the number of each exception. Double clicking the chart will allow you to drill down into further details, like a breakdown per server or client. You could also define your own query in Exceptions Tracking domain. If the exceptions are coming from monitored traffic, consult with the service owner of that traffic in your organization. If not, you can contact Guardium support with details of your investigation.

[{"Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSMPHH","label":"IBM Security Guardium"},"ARM Category":[{"code":"a8m0z000000Gp0PAAS","label":"DATABASE"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)"}]

Document Information

Modified date:
16 November 2020

UID

swg21696497