Auditing for Named replicas and Geo replicas of Hyperscale Azure SQL Database

Posted by

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

In this blog, we will explain how auditing works for some of the latest features for Hyperscale Azure SQL Database I.e. Hyperscale Named replicas and Geo replication & auto failover groups. 

 

Auditing for Named Replicas:  

 

We added auditing support for Hyperscale’s Named replicas. When you create a named replica for a database, the database-level audit configuration of the primary database is copied to the named replica and the configured actions will be audited. Server Level Auditing Policy for the Named Replica is picked up from the server on which the named replica is placed. 

 

Auditing for Hyperscale Geo Replicas  

 

We added auditing support for Hyperscale’s Geo Replicas. Server Level and Database Level Auditing works seamlessly across the entire lifecycle of Geo Replicas and their corresponding primaries at any point of time. When a new Geo Replica is created, it takes the database level auditing policy of its primary, and Server Level Auditing policy is picked up from the server on which the Geo Replica is placed. 

 

Auditing for Hyperscale Databases created using Copy / Restore

 

Azure portal provides an option to create a copy of your database or perform a Point-In-Time-Restore (PITR) for the database on the same server or different server. For Hyperscale databases, the resulting database takes the database level auditing policy of the original database, and Server Level Auditing policy is picked up from the server on which the resulting database is placed. 

 

To learn more about auditing please refer Auditing Overview  

  

 

  

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.