Merge pull request #34276 from MicrosoftDocs/main

06/02/2025 AM Publishing

Author: v-alje

azure-sql/database/transparent-data-encryption-byok-overview.md

@@ -175,17 +175,21 @@ To avoid issues while establishing or during geo-replication, when automatic rot
 
 ## Inaccessible TDE protector
 
-When TDE is configured to use a customer-managed key, continuous access to the TDE protector is required for the database to stay online. If the server loses access to the customer-managed TDE protector in AKV, in up to 10 minutes a database starts denying all connections with the corresponding error message and change its state to *Inaccessible*. The only action allowed on a database in the Inaccessible state is deleting it.
+When TDE is configured to use a customer-managed key, continuous access to the TDE protector is required for the database to stay online. If the server loses access to the customer-managed TDE protector in Azure Key Vault, in up to 10 minutes a database starts denying all connections with the corresponding error message and change its state to *Inaccessible*. The only action allowed on a database in the Inaccessible state is deleting it.
 
-> [!NOTE]  
-> If the database is inaccessible due to an intermittent networking outage, there's no action required and the databases will come back online automatically. To mitigate the impact of network errors or outages while trying to access the TDE protector in Azure Key Vault, a 24 hour buffer has been introduced before the service attempts to move the database to an inaccessible state. If a failover occurs before reaching the inaccessible state, the database becomes unavailable due to the loss of the encryption cache.
+### Inaccessible state
 
-After access to the key is restored, taking database back online requires extra time and steps, which might vary based on the time elapsed without access to the key and the size of the data in the database:
+If the database is inaccessible due to an intermittent networking outage (such as a 5XX error), no action is required, as the databases will come back online automatically. To reduce the impact of network errors or outages when accessing the TDE protector in Azure Key Vault, a 24-hour buffer has been introduced before the service attempts to move the database to an inaccessible state. If a failover occurs before reaching the inaccessible state, the database becomes unavailable due to the loss of the encryption cache.
 
-> [!NOTE]
-> - If key access is restored within 30 minutes, the database will autoheal within the next hour.
-> - If key access is restored after more than 30 minutes, autoheal of the database isn't possible. Bringing back the database requires extra steps on the Azure portal and can take a significant amount of time depending on the size of the database.
-> - Once the database is back online, previously configured server-level settings that might include [failover group](failover-group-sql-db.md) configuration, tags, and database-level settings such as elastic pools configuration, read scale, auto pause, point-in-time-restore history, long term retention policy, and others will be lost. Therefore, it's recommended that customers implement a notification system that identifies loss of encryption key access within 30 minutes. Once the 30-minutes window has expired, we recommend validating all server and database level settings on the recovered database.
+If the server loses access to the customer-managed TDE protector in Azure Key Vault due to any [Azure Key Vault error](#accidental-tde-protector-access-revocation) (such as a 4XX error), the database will be moved to an inaccessible state after 30 minutes.
+
+### Restore database access after an Azure Key Vault error
+
+After access to the key is restored, bringing the database back online requires additional time and steps, which may vary based on the duration of key unavailability and the size of the data within the database.
+
+If key access is restored within 30 minutes, the database will automatically heal within the subsequent hour. However, if key access is restored after more than 30 minutes, automatic healing of the database is not possible. In such cases, restoring the database involves extra procedures through the Azure portal and can be time-consuming, depending on the database's size.
+
+Once the database is back online, previously configured server-level settings, including failover group configurations, tags, and database-level settings such as elastic pool configurations, read scale, auto pause, point-in-time restore history, long-term retention policy, and others will be lost. Hence, it's recommended that customers implement a notification system to detect the loss of encryption key access within 30 minutes. After the 30-minute window has expired, we advise validating all server and database level settings on the recovered database.
 
 Below is a view of the extra steps required on the portal to bring an inaccessible database back online.
 
@@ -317,6 +321,8 @@ For more information, see [Azure Key Vault availability and redundancy](/azure/k
 
 - Use failover groups for Azure SQL MI and Azure SQL DB for disaster recovery to a secondary region. For more information, see [Failover groups overview & best practices](failover-group-sql-db.md).
 
+- When a database is part of active geo-replication or failover groups and becomes [inaccessible](#inaccessible-tde-protector), the SQL control plane breaks the link and converts the database into a standalone database. After fixing the key permissions, the primary database can typically be brought back online. The secondary database cannot be brought back online because Azure SQL does not take full backups for secondary databases by design. The recommendation is to drop the secondary databases and re-establish the link.
+
 - The configuration might require a more complex DNS zone if private endpoints are used in Azure SQL (for example, it can't create two private endpoints to the same resource in the same DNS zone).
 
 - Ensure applications leverage retry logic.

azure-sql/toc.yml

@@ -1935,7 +1935,7 @@
     - name: SQLCMD
       href: /sql/tools/sqlcmd-utility
     - name: SqlPackage
-      href: /sql/tools/sqlpackage/sqlpackage-utility
+      href: /sql/tools/sqlpackage/
 
   - name: Languages & code
     items: 

docs/relational-databases/resource-governor/tempdb-space-resource-governance.md

@@ -5,7 +5,7 @@ author: dimitri-furman
 ms.author: dfurman
 ms.service: sql
 ms.topic: concept-article
-ms.date: 05/19/2025
+ms.date: 05/30/2025
 monikerRange: " >= sql-server-ver17 || >= sql-server-linux-ver17 "
 ---
 
@@ -225,6 +225,10 @@ When using `tempdb` space resource governance, consider the following best pract
 
     This approach prevents each workload group from consuming all space in `tempdb` by leaving 20 GB for other workload groups. At the same time, you avoid unnecessary query aborts when free `tempdb` space is still available because workload groups *A* and *B* aren't likely to consume a large amount of `tempdb` space at the same time.
 
+## Known issues
+
+- When a workfile is deallocated, the increase in the available `tempdb` space might be counted against the `internal` workload group instead of the workload group that is allocated to the workfile.
+
 ## Related content
 
 - [Resource governor](resource-governor.md)

docs/tools/sqlpackage/sqlpackage-publish.md

@@ -183,7 +183,7 @@ SqlPackage /at:$($AccessToken_Object.Token) /Action:Publish /SourceFile:"C:\Adve
 |**/p:**|IgnoreDatabaseWorkloadGroups=(BOOLEAN 'False')|Specifies whether to exclude workload groups that exist on the target during deployment.  No Database Workload Groups will be added, modified, or dropped.|
 |**/p:**|IgnoreDdlTriggerOrder=(BOOLEAN 'False')|Specifies whether differences in the order of Data Definition Language (DDL) triggers should be ignored or updated when you publish to a database or server.|
 |**/p:**|IgnoreDdlTriggerState=(BOOLEAN 'False')|Specifies whether differences in the enabled or disabled state of Data Definition Language (DDL) triggers should be ignored or updated when you publish to a database.|
-|**/p:**|IgnoreDefaultSchema=(BOOLEAN 'False')|Specifies whether differences in the default schema should be ignored or updated when you publish to a database.|
+|**/p:**|IgnoreDefaultSchema=(BOOLEAN 'False')|Specifies whether differences in the DEFAULT_SCHEMA option on users and application roles should be ignored or updated when you publish to a database.|
 |**/p:**|IgnoreDmlTriggerOrder=(BOOLEAN 'False')|Specifies whether differences in the order of Data Manipulation Language (DML) triggers should be ignored or updated when you publish to a database.|
 |**/p:**|IgnoreDmlTriggerState=(BOOLEAN 'False')|Specifies whether differences in the enabled or disabled state of DML triggers should be ignored or updated when you publish to a database.|
 |**/p:**|IgnoreExtendedProperties=(BOOLEAN 'False')|Specifies whether differences in the extended properties should be ignored or updated when you publish to a database.|