Auditing policy at the server and database level
Applies to: Azure SQL Database Azure Synapse Analytics
This article highlights Auditing policies for Azure SQL Database and Azure Synapse Analytics at the server level and the database level.
Define server-level vs. database-level auditing policy
An auditing policy can be defined for a specific database or as a default server policy in Azure (which hosts SQL Database or Azure Synapse):
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.