Merge pull request #36935 from MicrosoftDocs/main

Auto Publish – main to live - 2026-03-23 22:30 UTC

Author: Albertyang0

azure-sql/managed-instance/region-availability.md

@@ -101,50 +101,61 @@ Choosing a [maintenance window](maintenance-window.md) for Azure SQL Managed Ins
 
 ## Zone redundancy 
 
-[Zone redundancy](high-availability-sla-local-zone-redundancy.md#zone-redundant-availability) is available in the following regions: 
+[Zone redundancy](high-availability-sla-local-zone-redundancy.md#zone-redundant-availability) is supported in the following regions: 
 
 #### [Americas](#tab/americas)
 
 - Brazil South
 - Canada Central
-- Mexico Central
-- Spain Central
+- Central US
+- Chile Central
 - East US
 - East US 2
-- Central US
+- Mexico Central
+- North Central US
+- South Central US
 - West US 2 
 - West US 3
 
 #### [Asia Pacific](#tab/asia)
 
-- East Asia
-- Southeast Asia
 - Australia East
-- Central India
-- Korea Central
+- Australia Southeast
+- East Asia
+- India Central
+- Indonesia Central
 - Japan East
 - Japan West
+- Korea Central
+- Malaysia West
 - New Zealand North
+- Southeast Asia
 
 #### [Europe, the Middle East, and Africa](#tab/emea)
 
-- North Europe
-- West Europe
+- Austria East
+- Belgium Central
 - France Central
 - Germany West Central
-- Italy North
 - Israel Central
+- Italy North
+- North Europe
 - Norway East
 - Poland Central
 - Qatar Central
 - South Africa North
-- Switzerland North
+- Spain Central
 - Sweden Central
+- Switzerland North
 - UAE North
 - UK South
+- West Europe
 
 ---
 
+> [!NOTE]
+> Zone redundant deployments to create a new instance or modify an existing instance in a supported region might be temporarily disabled due to limited hardware capacity. Consider using an alternative hardware generation or an alternative Azure region which satisfies your data residency requirements.
+
 ## Database watcher
 
 [Database watcher](../database-watcher-overview.md) is a managed monitoring solution for Azure SQL Managed Instance and Azure SQL Database. It is available in the following regions:

docs/relational-databases/track-changes/change-event-streaming/configure.md

@@ -14,7 +14,7 @@ monikerRange: "=sql-server-ver17 || =sql-server-linux-ver17"
 
 # Configure change event streaming (preview)
 
-[!INCLUDE [sqlserver2025](../../../includes/applies-to-version/sqlserver2025-asdb.md)]
+[!INCLUDE [sqlserver2025](../../../includes/applies-to-version/sqlserver2025-asdb-asmi.md)]
 
 This article describes how to configure the [change event streaming (CES)](overview.md) feature introduced in [!INCLUDE [sssql25-md](../../../includes/sssql25-md.md)], Azure SQL Database, and Azure SQL Managed Instance.
 
@@ -515,6 +515,29 @@ The following table lists the stored procedures, system functions, and DMVs that
 | [sys.sp_help_change_feed_table_groups](../../system-stored-procedures/sp-help-change-feed-table-groups.md) | Returns metadata that is used to configure change event streaming groups. |
 | [sys.sp_help_change_feed_table](../../system-stored-procedures/sp-help-change-feed-table.md) | Provides the status and information of the streaming group and table metadata for change event streaming. |
 
+## Transaction log growth
+
+Because message delivery is guaranteed, the transaction log for a database that has CES enabled can continue to grow. Log truncation is prevented as long as there are CES changes to stream from the log. Once the transaction log size reaches the max defined limit, writes to the database fail. 
+
+To prevent this in Azure SQL Database and Azure SQL Managed Instance, when the transaction log size approaches the max defined limit, Microsoft might disable CES or kill long running transactions. For unmanaged SQL Server instances such as on-premises or on SQL Server on Azure VMs, you're responsible for monitoring the transaction log size and ensuring it doesn't reach the max defined limit, and manually disabling CES or killing long running transactions if needed.
+
+Once CES is disabled, or a long running transaction is killed, the transaction log is truncated to free up space. You must manually enable CES again after it has been disabled, or retry any long running transactions that were killed. Data changes made while CES was disabled aren't captured. Only changes made after CES is restarted are streamed.
+
+The following is a list of typical scenarios that can lead to transaction log growth with CES enabled:
+
+- Persistent errors. CES retries to send a message that is rejected repeatedly and CES can't continue. Reasons for persistent errors that can lead to rejected messages include:
+   - Network issues or misconfiguration.
+   - Credential misconfiguration.
+   - Misconfigured max message size that the destination rejects.
+- The destination throttles the incoming events. For example, Azure Event Hubs rate limits based on its SKU.
+- Long running transactions that generate a lot of log records and prevent log truncation.
+
+To ensure smooth operations, monitor the size of the transaction log and [CES delivery errors](../../system-dynamic-management-views/sys-dm-change-feed-errors.md) regularly.
+
+## Performance
+
+On SQL Server, Azure SQL Managed Instance and Azure SQL Database elastic pools, you can enable CES on multiple databases. Each CES-enabled database consumes server resources and competes with other server workload. Make sure that your server is adequately resourced for the expected workload and monitor the performance of your server and databases regularly.
+
 ## Limitations
 
 Change event streaming (CES) has the following limitations:
@@ -524,7 +547,8 @@ Change event streaming (CES) has the following limitations:
 - [Database-level limitations](#database-level-limitations)
 - [Table-level limitations](#table-level-limitations)
 - [Column-level limitations](#column-level-limitations)
-- [Permissions in the source database](#permissions-in-the-source-database)
+- [Permissions in the source database](#permissions-in-the-source-database-and-data-residency)
+- [Networking and connectivity](#networking-and-connectivity)
 
 ### Azure SQL Database
 
@@ -548,7 +572,7 @@ The following limitations apply when using CES with Azure SQL Database:
 - CES only supports databases configured with the full recovery model.
 - CES doesn't support databases configured with [Fabric Mirrored Databases for SQL Server](/fabric/database/mirrored-database/sql-server), [transactional replication](../../replication/transactional/transactional-replication.md), [change data capture](../about-change-data-capture-sql-server.md), or [Azure Synapse Link](/azure/synapse-analytics/synapse-link/sql-synapse-link-overview). [Change tracking](../about-change-tracking-sql-server.md) is supported on databases configured with CES.
 - CES can only stream from writable primary databases. Secondary databases that are part of Always On availability groups or that use the [Managed Instance link](/azure/azure-sql/managed-instance/managed-instance-link-feature-overview) can't be configured as streaming sources.
-- You can't enable CES on views or materialized views.
+- You can't enable CES on views or indexed views.
 
 ### Table-level limitations
 
@@ -584,11 +608,16 @@ The following limitations apply when using CES with Azure SQL Database:
   - **xml**
   - User-defined types (UDT)
 
-### Permissions in the source database
+### Permissions in the source database and data residency
 
 - For row-level security, CES emits changes from all rows, regardless of user permissions.
 - Dynamic data masking doesn't apply to data sent through CES. Data is streamed unmasked, even if masking is configured.
 - CES doesn't emit events related to object-level permission changes (for example, granting permissions to specific columns).
+- CES streams data to the configured destination if the network configuration allows it. If the destination is in a different region, CES streams the data across regions. Ensure this complies with your data residency and compliance requirements.
+
+### Networking and connectivity
+
+- Currently, CES can only stream to Azure Event Hubs public endpoints. Service endpoints and private endpoints aren't currently supported.
 
 ## Related content
 

docs/relational-databases/track-changes/change-event-streaming/frequently-asked-questions-faq.yml

@@ -12,7 +12,7 @@ metadata:
   ms.custom: build-2025
 title: Frequently Asked Questions (FAQ) for Change Event Streaming (CES)
 summary: |
-  [!INCLUDE [sqlserver2025](../../../includes/applies-to-version/sqlserver2025-asdb.md)]
+  [!INCLUDE [sqlserver2025](../../../includes/applies-to-version/sqlserver2025-asdb-asmi.md)]
   The following are answers to questions about the Change Event Streaming (CES) feature for [!INCLUDE [sssql25-md](../../../includes/sssql25-md.md)], Azure SQL Database, and Azure SQL Managed Instance.
 
   [!INCLUDE [change-event-streaming-preview](../../../includes/change-event-streaming-preview.md)]
@@ -68,11 +68,13 @@ sections:
         answer: No. CES can't be enabled on a database enabled with CDC.
       - question: Can CES be used with Fabric Mirrored Databases for SQL Server?
         answer: No. CES isn't supported with [Fabric Mirrored Databases for SQL Server](/fabric/database/mirrored-database/sql-server).
-      - question: If CES stops, does it resume from where it left off?
+      - question: What happens if CES is disabled? Does it resume from where it left off when reenabled?
         answer: |
-          If CES is manually stopped, it doesn't resume automatically. You must manually restart CES to continue streaming events. Changes made while CES was stopped won't be captured. Only changes made after CES is restarted will be streamed.
-          CES guarantees *at least once* delivery. If CES fails to deliver a message, it continues to retry until the message is successfully delivered, or CES is manually stopped. If CES isn't stopped, failed deliveries prevent log truncation until the error condition is resolved, and the message is successfully delivered. If CES is stopped manually, log truncation resumes, and events that occur during the downtime aren't captured.
+          If CES is disabled, it can't be resumed. You must manually reconfigure CES to continue streaming events. Data changes made while CES was disabled aren't captured. Only changes made after CES is restarted are streamed.
+          CES guarantees *at least once* delivery. If CES fails to deliver a message, it continues to retry until the message is successfully delivered, or CES is disabled. If CES isn't disabled, failed deliveries prevent log truncation until the error condition is resolved, and the message is successfully delivered. If CES is disabled, log truncation resumes, and events that occur during the downtime aren't captured.
 
+      - question: What happens if I do a restore (or another type of migration) of a database that was configured for CES?
+        answer: After restore (or other types of database migration), CES is disabled and stopped for the database. You have to reconfigure it to start streaming again.
       - question: Can CES do an initial snapshot ("seed") of existing data in tables when CES is enabled?
         answer: No. CES currently only streams changes to data that happen after CES is enabled. It doesn't stream data in a table that exists before CES is enabled.
       - question: How can I monitor CES activity (for example, events processed, errors)?

docs/relational-databases/track-changes/change-event-streaming/message-format.md

@@ -13,7 +13,7 @@ monikerRange: "=sql-server-ver17 || =sql-server-linux-ver17"
 ---
 
 # JSON message format - change event streaming
-[!INCLUDE [sqlserver2025](../../../includes/applies-to-version/sqlserver2025-asdb.md)]
+[!INCLUDE [sqlserver2025](../../../includes/applies-to-version/sqlserver2025-asdb-asmi.md)]
 
 This article describes the JSON format of a CloudEvents message that is streamed from SQL Server to Azure Event Hubs when using the [change event streaming (CES)](overview.md) feature introduced in [!INCLUDE [sssql25-md](../../../includes/sssql25-md.md)], Azure SQL Database, and Azure SQL Managed Instance
 
@@ -25,14 +25,14 @@ Events emitted by change event streaming follow the [CloudEvents](https://github
 
 ## Related specifications and resources
 
-When applicable, the descriptions in this section are taken from [CloudEvent specification](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md), which includes additional details.  
+When applicable, the descriptions in this section are taken from [CloudEvent specification](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md), which includes more details.  
 
 ## Attributes
 
 - **`specversion`**:
   - Data type: String
   - Required CloudEvent attribute
-  - The version of the CloudEvents specification which the event uses. This enables the interpretation of the context.
+  - The version of the CloudEvents specification that the event uses. This enables the interpretation of the context.
 
 - **`type`**
   - Data type: String
@@ -82,7 +82,7 @@ When applicable, the descriptions in this section are taken from [CloudEvent spe
 - **`finalsegment`**
   - Data type: Boolean
   - Extension attribute
-  - Tells if this segment is final segment of the sequence. This field is always present and helps to identify if a SQL event that was too large for configured max message size was split into sub-events.
+  - Tells if this segment is final segment of the sequence. This field is always present and helps to identify if a SQL event that was too large for configured max message size was split into subevents.
 
 - **`data`**
   - Data type: String