SQL statement auditing may be enabled and configured using either the Web UI or the Limits API. The following limits can be used to enable and configure SQL statement auditing.

  • SQLAuditing (21): Used to enable or disable the feature. May be enabled at the system, tenant, user, and data source levels. The feature is disabled by default.
  • SQLAuditingRetentionDays (22): The number of days records are retained in the SQLAudit table. May only be applied at the system level. The default setting is 30 days.
  • SQLAuditingMaxAge (23): The maximum number of seconds the service waits before inserting auditing records into the SQLAudit table. A lower setting will increase the frequency with which records are written to the SQLAudit table. May only be applied at the system level. The default is 60 seconds.
The following examples show how to enable SQL statement auditing at each level using the SQLAuditing limit, and how to further configure the feature with the SQLAuditingRetentionDays and SQLAuditingMaxAge limits.
Note: To enable and configure SQL statement auditing, the administrator must have either the Administrator (12) or the Limits (27) permission.

System level

SQL statement auditing can be enabled at the system level with either the Web UI or with the Limits API. For details on using the Web UI, see Manage Limits view.

The following POST enables SQL statement auditing at the system level, where the number 21 is the ID of the SQLAuditing limit.

POST https://<myserver>:<port>/api/admin/limits/system/21
    {
      "value": 1
    }

Tenant level

SQL statement auditing can be enabled at the tenant level with either the Web UI or with the Limits API. When using the Web UI, you can enable SQL statement auditing through either the Manage Tenants view or the Manage Limits view.

The following POST enables SQL statement auditing at the tenant level. In this example, the number 32 is the ID of the tenant, and the number 21 is the ID of the SQLAuditing limit.

POST https://<myserver>:<port>/api/admin/limits/tenants/32/21
    {
      "value": 1
    }

User level

SQL statement auditing can be enabled at the user level either with the Web UI or with the Limits API. For details on using the Web UI, see Manage Users view.

The following POST enables SQL statement auditing for a user. In this example, the number 86 is the ID of the user, and the number 21 is the ID of the SQLAuditing limit.

POST https://<myserver>:<port>/api/admin/limits/users/86/21
    {
      "value": 1
    }

Data source level

SQL statement auditing can only be enabled at the data source level using the Limits API. The following POST enables SQL statement auditing on a data source. In this example, the number 86 is the ID of the user who owns the data source, the number 14 is the ID of the data source, and the number 21 is the ID of the SQLAuditing limit.

POST https://<myserver>:<port>/api/admin/limits/users/86/datasources/14/21
    {
      "value": 1
    }

Set SQLAuditingRetentionDays

Once SQL statement auditing is enabled, you can then set SQLAuditingRetentionDays (22) at the system level to specify the number of days rows are retained in the SQLAudit table. (SQLAuditingRetentionDays can also be set via the Web UI. See Manage Limits view for details.)

POST https://<myserver>:<port>/api/admin/limits/system/22
    {
      "value": 90
    }

Set SQLAuditingMaxAge

Once enabled, you can also set SQLAuditingMaxAge (23) to specify the maximum number of seconds the service waits before inserting the auditing records into the SQLAudit table. (SQLAuditingMaxAge can also be set via the Web UI. See Manage Limits view for details.)

POST https://<myserver>:<port>/api/admin/limits/system/23
    {
      "value": 30
    }