Auditing policy at the server and database level

This article highlights auditing policies for Azure SQL Database at the server level and the database level.

Define server-level vs. database-level auditing policy

You can define an auditing policy for a specific database or as a default server policy in Azure SQL Database:

A server policy applies to all existing and newly created databases on the server.
If server auditing is enabled, it always applies to the database. The database is audited regardless of the database auditing settings.
When an auditing policy is defined at the database-level to a Log Analytics workspace or an Event Hubs destination, the following operations don't keep the source database-level auditing policy:
- Database copy
- Point-in-time restore
- Geo-replication (secondary database doesn't have database-level auditing)
Enabling auditing on the database in addition to enabling auditing on the server doesn't override or change any of the settings of the server auditing. Both audits exist side by side. In other words, the database is audited twice in parallel; once by the server policy and once by the database policy.
Note

You should avoid enabling both server auditing and database blob auditing together, unless:
- You want to use a different storage account, retention period or Log Analytics Workspace for a specific database.
- You want to audit event types or categories for a specific database that differ from the rest of the databases on the server. For example, you might have table inserts that need to be audited only for a specific database.
Otherwise, we recommended that you enable only server-level auditing and leave the database-level auditing disabled for all databases.

For information about server-level and database-level auditing in Azure Synapse Analytics, see Server-level and database-level auditing.

Was this page helpful?