Change Event Streaming (CES) en SQL Server 2025

Bienvenidos/as a un nuevo artículo en el blog de Aleson ITC. En el post de hoy hablaremos sobre CES(Change Event Streaming), para SQL Server 2025.

Explicaremos qué es, cómo funciona, para qué sirve y posibles utilidades dónde lo podríamos aplicar.

EL Change Event Streaming, en adelante CES, es una función actualizada de integración de datos entre SQL Server y Azure Event Hub. Esta funcionalidad va a capturar los cambios que se produzcan dentro de nuestra base de datos, y los va a cargar directamente en un Event Hub de Azure.

Para entender porqué decimos actualizada, vamos a explicar de dónde venimos. Lo más similar que tenemos hasta ahora sería el CDC, dónde de igual manera se capturaban estos cambios desde el Log, pero estos se quedaban a la espera registrados en tablas internas de la BBDD. Para conocer más sobre el CDC, siempre se puede revisar el post anterior.

Para verlo más claramente, vamos a poner una tabla comparativa y explicar las diferencias y ventajas de CES sobre el CDC

Ventajas y Desventajas del CES

Origen de Captura de Datos: Vemos que ambos leen de manera asíncrona desde el Log de Transacciones, lo que permite que no afecte al rendimiento propio de la tabla en origen, aunque con CES, ya no es necesario la figura del agente para capturar estos datos.

Destino de los Datos Capturados: A diferencia del CDC, que requería una sobrecarga de IO sobre una tabla auxiliar desde dónde luego se leerían los datos, con CES no es necesario guardar los datos en un nuevo sitio, si no que el propio SQL los lee directamente desde el LOG y los vuelva en el Azure Event Hub, consumiendo mucho menos IO.

Datos Capturados: En ambos nos llevaremos los datos, pero con CES también nos llevaremos los cambios de tipo DDL.

Método de Captura: Este punto es muy importante ya que es dónde se encuentra la principal desventaja de CES. Esta es que únicamente se puede configurar CES para un único destino por tabla, a diferencia de CDC que podríamos tener multiples destinos.

Disponibilidad: La disponibilidad de ambos es distinta. En CDC era el consumidor el que se conectaba a la BBDD y este iba requiriendo los datos. En cambio, en CES es el propio CES el que envía los datos nada más los tiene y lo sube. Aunque ambos métodos, funcionan muy cerca del tiempo real.

Casos de Uso: El CDC está más orientado para temas de DataWarehouse y auditoría, a diferencia de CES que al tener todos los datos directamente cargados sobre azure nos abre un sin fín de funcionalidades, como la posibilidad de tomar acciones frente a eventos, integración con microservicios, cargar los datos directamente para su análisis…

1. Configurar Master Key.(Siempre que trabajamos con seguridad, es necesario).

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<SecurePassword>'

2. Generar nuestro Hub en Azure Event Hub y generar nuestra clave SAS. (No detallamos todo el proceso, ya que no es el objetivo de este post).

3. Creamos nuestra Credencial en SQL Server. Adjuntamos también script de powershell por si hubiera problema al generarla.
   

CREATE DATABASE SCOPED CREDENTIAL [CREDENTIAL_CES] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'SharedAccessSignature sr=https%3a%2f%2...';

Script en Powershell en caso de problemas al Generar la SAS.

$namespace = "FranCESSQL"
$hub = "Hub_Name"
$resourceUri = "$namespace.servicebus.windows.net/$hub"
$uriEncoded = [System.Web.HttpUtility]::UrlEncode("https://$resourceUri")
$sasKey = "<PrincipalPass>=" # Tu clave
$policyName = "RootManageSharedAccessKey" 
$expiry = int + 3600) # 1h
$stringToSign = "$uriEncoded`n$expiry"
$hmacsha256 = New-Object System.Security.Cryptography.HMACSHA256
$hmacsha256.Key = [Text.Encoding]::UTF8.GetBytes($sasKey)
$signatureBytes = $hmacsha256.ComputeHash([Text.Encoding]::UTF8.GetBytes($stringToSign))
$signature = [System.Convert]::ToBase64String($signatureBytes)
$sasToken = "SharedAccessSignature 
$sasToken = "SharedAccessSignature sr=$uriEncoded&sig=$([System.Web.HttpUtility]::UrlEncode($signature))&se=$expiry&skn=$policyName"
write-host $sasToken

4. Crearemos nuestra tabla de ejemplo.

CREATE TABLE dbo.Productos (
Id INT PRIMARY KEY clustered identity ,
Nombre NVARCHAR(100),
Precio DECIMAL(10, 2),
Categoria NVARCHAR(50)
);

5. Activaremos CES en nuestra base de datos.

EXEC sys.sp_enable_event_stream

6. Definimos conexión desde SQL Server a Event Hub a través de la credencial.

EXEC sys.sp_create_event_stream_group
@stream_group_name = N'EventStreamGroupName',
@destination_type = N'AzureEventHubsAmqp',
@destination_location = N'FranCESSQL.servicebus.windows.net/Hub_Name',
@destination_credential = CREDENTIAL_CES

7. Activamos nuestra tabla a CES.

EXEC sys.sp_add_object_to_event_stream_group
N'EventStreamGroupName',
N'dbo.Productos'

8. Verificamos las configuraciones y que no tenemos errores.

EXEC sys.sp_help_change_feed_settings
EXEC sp_help_change_feed_table @source_schema = 'dbo', @source_name = 'Productos'
SELECT * FROM sys.dm_change_feed_errors

9. Insertamos un registro en nuestra tabla.

insert into dbo.Productos values('Manzanas','1','Fruta')

10. Verificamos que los datos se han replicado a nuestro Azure Event Hub correctamente.

Hasta aquí el post de hoy. Espero que te haya servido de ayuda para conocer las posibilidades de su futuro nuevo SQL Server.

Documentación

Microsoft

Microsoft Mechanics

SQL 2025 Change Event Streaming (CES)

Fran Aguado

Data Engineer.