Why is the Guardium internal database is filling up

If the Guardium internal database is filling up, you can purge the data manually or as part of the regular purge strategy.

Symptoms

  • Cannot log in to GUI.
  • tomcat error on GUI.
  • Size of DB from System View approaching 100%.
  • Receiving alerts that indicate the database size is getting larger.

Causes

The Guardium internal database can fill up for many reasons. For more information about a general approach to resolving the situation, see: Managed unit database is filling up. Use the guidelines in Resolving the problem along with Managed unit database is filling up to help resolve the problem. If you are unable to take any of the actions, use the general steps in Managed unit database is filling up to lower the database size.
The reason that the internal database fills 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.

Resolving the problem

  1. Check the largest tables in CLI. Enter: 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
  2. Start with your largest table. Use the actions to help reduce the size in the long term. The most common largest tables are listed here, with the causes for filling up, and the actions to stop the problem in the long term. The list is not exhaustive. Use this information along with an overall purging strategy.
    GDM_CONSTRUCT_TEXT
    Cause
    • All data that is captured by a policy rule with Log full details action is written to this table.
    Actions
    • Use Log full details as little as possible in the policy. If this table is constantly filling up, 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, and they send alerts by the defined method (for example, 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 simultaneously with alert once per session. If data needs to be forwarded to remote SIEM, but not seen in Guardium reports, use the action alert only.
    • Check in the policy violations report Comply > Reports > Incident Management for the most common alerts. A recent change in the environment might cause a spike in alerts. For example, a new application might create thousands 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 when:
      • They are cleared from all receiver to-do lists.
      • 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 a purge that is started in the GUI.
    Action
    One or more of GDM_CONSTRUCT, GDM_FIELD, GDM_OBJECT, GDM_SENTENCE
    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
    • Many types of exceptions are logged in this table. The first step is to identify which are the most common. You can use predefined reports in the Exceptions domain to find which exceptions are most common.
    • The report Exceptions Type Distribution shows the number of each exception. Double-click the chart to drill down into further details, like a breakdown per server or client. You can also define your own query in the 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.