Auditing Overview
Auditing provides visibility on what actions were performed or attempted in the SAP HANA database. This allows you, for example, to log and monitor read access to sensitive data. It is therefore recommended to create a basic set of policies.
Auditing can be enabled and disabled per tenant database, you can configure auditing independently for each database using SAP HANA cockpit or SQL statements. Changes to the auditing configuration in one database have no effect on auditing in other databases in an SAP HANA system.
Audit logging is not enabled by default.

The auditing service of the SAP HANA database allows you to monitor and record selected actions that are performed in your database. To use this service, first activate it for the database. You can then create and activate the required audit policies.
Audit trails are configured only in the system database and cannot be changed later in a tenant database. Audit entries are created in one or more audit trails (database table, linux syslog, CSV file, or kernel trace) when an audit policy is triggered.
Audit Policies
An audit policy defines the actions to be audited. It also outlines the conditions under which the action must occur for it to be relevant for auditing. When an action occurs, the policy is triggered and an audit event is written to the audit trail. Audit policies are database-specific.
An audit policy can specify any number of actions to be audited, but not all actions can be combined together in the same policy. In addition to the actions to be audited, an audit policy specifies parameters that further narrow the number of events actually audited. You define the audited action status (successful or unsuccessful), determine the target objects like schemas or tables. Also, the audited users and the audit level (ALERT, WARNING, INFO, and so on) need to be set.
When the audit policy is triggered, an audit entry of the corresponding level is written to the audit trail. This allows tools that check audited actions to find the most important information.
Audit Actions
An action corresponds to the execution of an action in the database by SQL statement. For example, to track user provisioning in your system, create an audit policy that audits the execution of the SQL statements CREATE USER and DROP USER.
Although most actions correspond to the execution of a single SQL statement, some actions cover the execution of multiple SQL statements. For example, the action GRANT ANY audits the granting of multiple entities for the SQL statements GRANT PRIVILEGE, GRANT ROLE, GRANT STRUCTURED PRIVILEGE, and GRANT APPLICATION PRIVILEGE.
Other actions that are typically audited are, for example, creating objects, querying or manipulating data in the database, changes to user authorization, or access and changes to the system configuration or data, and so on.
Both successful and unsuccessful actions can be recorded.
Some sample auditable actions for changes in the SAP HANA database on users, roles, and authorization events are as follows:
Create or drop user, and create or drop role
Grant or revoke role
Grant or revoke SQL privilege, system privilege, and analytical privilege
Create or drop analytical privilege
Authentication of users like connection attempts to the database
Changes to system configuration, for example, .ini file, uploading license keys, set or unset system license for all, or changes to the data volume encryption are actions that can be logged. When you enable audit logging for configuration changes, the previous values of parameters are written to the audit trail.
Access to or changing of sensitive data in schemas, tables, views, and procedures can be audited. Both write and read access (select, insert, update, delete and execute statements) to data can be recorded.
Mandatory Audit Actions
If auditing is active, certain actions are always audited and are therefore not available for inclusion in user-defined audit policies. In the audit trail, these actions are labeled with the internal audit policy Mandatory Audit Policy.
Mandatory audit actions include the creation, modification, or deletion of audit policies, also the deletion of audit entries from the audit trail, if they are written to column store database tables. Changes to auditing configuration, like enabling or disabling auditing, changing the audit trail target, or changing the location of the audit trail target if it is a CSV text file will also be logged as an audit action.
Unauditable Events
Only actions that take place inside the database engine can be audited. If the database engine is not online when an action occurs, it cannot be detected, and therefore cannot be audited. These actions include, for example, an upgrade of an SAP HANA database instance, or direct changes to system configuration files using operating system commands.
An upgrade is triggered when the instance is offline. When it becomes available online again, you cannot determine which user triggered the upgrade and when.
Only changes that are made using SQL are visible to the database engine. You can change configuration files when the system is offline.
Audit Trails
When an audit policy is triggered, that is, when an action in the policy occurs under the conditions defined in the policy, an audit entry is created in one or more audit trails.
The following audit trail targets are supported for production systems:
Audit Trails
Audit Trail Target | Description |
---|---|
Internal database table | Makes it possible to query and analyze auditing information quickly. It also provides a secure and tamper-proof storage location. Audit entries are only accessible through the public system views. |
Linux syslog | Default log daemon in UNIX systems. Secure storage location for the audit trail because not even the database administrator can access or change it. |
CSV text file | This should only be used for test purposes in non-production systems. |
Separate audit trail targets may be configured for the audit level, that is, the severity of the action being audited.
Audit entries from audit policies with the audit level EMERGENCY, CRITICAL, or ALERT are written to the audit trail targets specified for the audit level in question. If no audit trail target is configured for an audit level, entries are written to the audit trail target configured for the database.
Audit policy-specific targets are also possible in the system database. In this case, audit entries from a particular policy are written to the specified audit trail targets. If no audit trail target is configured for an audit policy, entries are written to the audit trail target for the audit level if configured, or the audit trail target configured for the database. Several audit trail targets can be configured for each individual policy.
Note
By default, tenant database administrators cannot configure audit trail targets independently for their database since the underlying system properties are in the default configuration change blocklist (multidb.ini). The default target for all audit trails in tenant databases is internal database table. Although not recommended, it is possible to change the audit trail target of a tenant database.
Caution
To ensure the privacy of tenant database audit trails, it is recommended that you do not change the default audit trail target (internal database table) of tenant databases.