Merge pull request #37128 from MicrosoftDocs/main

Auto Publish – main to live - 2026-04-23 17:30 UTC

Author: learn-build-service-prod[bot]

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

@@ -5,7 +5,7 @@ description: Bring Your Own Key (BYOK) support for transparent data encryption (
 author: Pietervanhove
 ms.author: pivanho
 ms.reviewer: wiassaf, vanto, mathoma, randolphwest
-ms.date: 03/05/2026
+ms.date: 04/22/2026
 ms.service: azure-sql
 ms.subservice: security
 ms.topic: concept-article
@@ -217,7 +217,7 @@ Auditors can use Azure Monitor to review managed HSM AuditEvent logs, if logging
 
 - Keep all previously used keys in Azure Key Vault or Azure Managed HSM even after switching to service-managed keys. It ensures database backups can be restored with the TDE protectors stored in Azure Key Vault or Azure Managed HSM. TDE protectors created with Azure Key Vault or Azure Managed HSM have to be maintained until all remaining stored backups have been created with service-managed keys. Make recoverable backup copies of these keys using [Backup-AzKeyVaultKey](/powershell/module/az.keyvault/backup-azkeyvaultkey).
 
-- To remove a potentially compromised key during a security incident without the risk of data loss, follow the steps in the article [Remove a Transparent Data Encryption (TDE) protector using PowerShell](transparent-data-encryption-byok-remove-tde-protector.md).
+- To remove a potentially compromised key during a security incident without the risk of data loss, follow the steps in the article [Remove a Transparent Data Encryption (TDE) protector using PowerShell](transparent-data-encryption-byok-remove-tde-protector.md). Always rotate to a new TDE protector and verify that all databases are using the new key before deleting or disabling the compromised key. Deleting or disabling the key without rotating first causes all encrypted databases to become inaccessible, and does not invalidate any key copies that were previously backed up and restored to another vault.
 
 > [!TIP]
 > **Using versioned and versionless Azure Key Vault keys for TDE**

azure-sql/database/transparent-data-encryption-byok-remove-tde-protector.md

@@ -5,7 +5,7 @@ description: Learn how to respond to a potentially compromised TDE protector for
 author: Pietervanhove
 ms.author: pivanho
 ms.reviewer: wiassaf, vanto, mathoma
-ms.date: 03/05/2026
+ms.date: 04/22/2026
 ms.service: azure-sql-database
 ms.subservice: security
 ms.topic: how-to
@@ -24,7 +24,7 @@ This article describes how to respond to a potentially compromised TDE protect f
 > [!CAUTION]
 > The procedures outlined in this article should only be done in extreme cases or in test environments. Review the steps carefully, as deleting actively used TDE protectors from Azure Key Vault will result in **database becoming unavailable**.
 
-If a key is ever suspected to be compromised, such that a service or user had unauthorized access to the key, it's best to delete the key.
+If a key is ever suspected to be compromised, such that a service or user had unauthorized access to the key, the recommended response is to first rotate to a new TDE protector and migrate all databases before deleting the old key. Deleting or disabling a key without first rotating the TDE protector causes all encrypted databases to become inaccessible. In addition, deleting or disabling a key does not invalidate any copies that were previously backed up and restored to another vault. Those copies remain fully functional. For more information about Key Vault backup copy behavior, see [Backup security considerations](/azure/key-vault/general/backup#security-considerations).
 
 Keep in mind that once the TDE protector is deleted in Azure Key Vault, in up to 10 minutes, all encrypted databases will start denying all connections with the corresponding error message and change its state to [Inaccessible](./transparent-data-encryption-byok-overview.md#inaccessible-tde-protector).
 

docs/relational-databases/system-views/queryinsights-exec-requests-history-transact-sql.md

@@ -4,7 +4,7 @@ description: "The queryinsights.exec_requests_history in Microsoft Fabric provid
 author: WilliamDAssafMSFT
 ms.author: wiassaf
 ms.reviewer: mariyaali, randolphwest, emtehran
-ms.date: 03/12/2026
+ms.date: 04/23/2026
 ms.service: sql
 ms.topic: "reference"
 ms.custom:
@@ -53,6 +53,7 @@ The `queryinsights.exec_requests_history` in [!INCLUDE [fabric](../../includes/f
 | `data_scanned_memory_mb` | **decimal(18,3)** | Shows how much data was scanned from local memory. Data scanned from disk and memory together indicates how much data was read from cache. |
 | `data_scanned_disk_mb` | **decimal(18,3)** | Shows how much data was scanned/read from local disk. Data scanned from disk and memory together indicates how much data was read from cache. |
 | `command` | **varchar(max)** | Complete text of the executed query. |
+| `error_code` | **int** | Error code if query failed after beginning execution. `0` if no error encountered. |
 
 ## Permissions