captura de datos modificados (CDC) en Azure SQL Database
Se aplica a:
Azure SQL Database
En este artículo, obtenga información sobre cómo se implementa la captura de datos modificados (CDC) en Azure SQL Database para registrar actividad en una base de datos cuando se modifican tablas y filas. Para obtener más información sobre la característica de CDC, incluido cómo se implementa en SQL Server y Azure SQL Managed Instance, consulte CDC con SQL Server.
Información general
En Azure SQL Database, un planificador de captura de datos modificados sustituye a los trabajos del Agente SQL Server que capturan y limpian los datos modificados en las tablas de origen. El planificador ejecuta los procesos de captura y limpieza automáticamente en el ámbito de la base de datos y garantiza la confiabilidad y el rendimiento sin dependencias externas. Los usuarios conservan la opción de iniciar manualmente los procesos de captura y limpieza según sea necesario.
Un buen ejemplo de consumidor de datos que utiliza esta tecnología es una aplicación de extracción, transformación y carga de datos (ETL). Una aplicación ETL carga incrementalmente los datos modificados de las tablas de origen de SQL Server en un almacenamiento de datos o data mart. Aunque la representación de las tablas de origen dentro del almacén de datos debe reflejar los cambios en las tablas de origen, una tecnología de extremo a extremo que actualice una réplica del origen no resulta adecuada en este caso. En su lugar, necesita un flujo de datos modificados confiable y estructurado de forma que los consumidores puedan aplicarlo a representaciones de destino dispares de los datos. La captura de datos modificados de SQL Server proporciona esta tecnología.
Para obtener más información sobre la captura de datos modificados en Azure SQL Database, consulte este episodio de Data Exposed:
Flujo de datos
En la ilustración siguiente se muestra el flujo de datos principal de la captura de datos modificados con Azure SQL Database:
Requisitos previos
Permisos
Es necesario el rol db_owner para habilitar la captura de datos modificados de Azure SQL Database.
Requisitos de proceso de Azure SQL Database
Puede habilitar la CDC en Azure SQL Database para cualquier nivel de servicio en el modelo de compra basado en núcleo virtual para bases de datos únicas y grupos elásticos.
En el caso de las bases de datos del modelo de compra basado en DTU, la CDC es compatible con las bases de datos del nivel S3 o uno superior. No se admite la CDC en los niveles de subnúcleos (Basic, S0, S1 y S2).
Habilitación de la CDC para Azure SQL Database
Para poder crear una instancia de captura para tablas individuales, debe habilitar la CDC para su base de datos de Azure SQL.
Para habilitar la CDC, conecte su base de datos de Azure SQL mediante Azure Data Studio o SQL Server Management Studio (SSMS). Abra un nuevo período de consulta y ejecute el siguiente T-SQL para habilitar la CDC:
EXEC sys.sp_cdc_enable_db;
GO
Nota:
Para determinar si una base de datos ya está habilitada, consulte la columna is_cdc_enabled en la vista de catálogo sys.databases.
Al habilitar la captura de datos modificados para una base de datos, se crean para la base de datos cdc schema, cdc user, las tablas de metadatos y otros objetos de sistema. cdc schema contiene las tablas de metadatos de la captura de datos modificados y, una vez que la CDC se habilita para las tablas de origen, las tablas de cambios individuales sirven como repositorio de los datos modificados. cdc schema también contiene las funciones del sistema asociadas que se usan para consultar los datos modificados.
Importante
La captura de datos modificados requiere el uso exclusivo de cdc schema y cdc user. Si en una base de datos existe un esquema o un usuario de base de datos denominado cdc, no puede habilitar la CDC para esa base de datos hasta que el esquema o el usuario se quiten o se cambien de nombre.
Habilitación de la CDC para una tabla
Después de habilitar la CDC para su base de datos de Azure SQL, puede habilitar la CDC en el nivel de tabla; para ello, seleccione una o varias tablas para realizar un seguimiento de los cambios de datos. Cree una instancia de captura para las tablas de origen individuales con el procedimiento almacenado sys.sp_cdc_enable_table.
A fin de habilitar la CDC para una tabla, ejecute el siguiente T-SQL:
EXEC sys.sp_cdc_enable_table
@source_schema = N'SchemaName',
@source_name = N'TableName',
@role_name = NULL;
GO
Sugerencia
En el ejemplo anterior no se usa un valor de @role_name explícito al establecer el parámetro en NULL, pero puede usar un rol de acceso para limitar el acceso a los datos modificados.
Columnas de la tabla de origen que se van a capturar
De forma predeterminada, todas las columnas de la tabla de origen se identifican como columnas capturadas. Si solo es necesario realizar el seguimiento de un subconjunto de las columnas, por ejemplo, por motivos de privacidad o de rendimiento, use el parámetro @captured_column_list para especificar el subconjunto de columnas.
A fin de habilitar la CDC para una lista específica de columnas de una tabla, ejecute el siguiente T-SQL:
EXEC sys.sp_cdc_enable_table
@source_schema = N'SchemaName',
@source_name = N'TableName',
@role_name = NULL,
@captured_column_list = N'Column1, Column2, Column3';
GO
Sugerencia
Observe que en el ejemplo anterior no se usa un valor de @role_name explícito al establecer el parámetro en NULL, pero puede usar un rol de acceso para limitar el acceso a los datos modificados.
Un rol para controlar el acceso a una tabla de cambios
La finalidad del rol con nombre es controlar el acceso a los datos de cambios. El rol especificado puede ser un rol fijo de servidor existente o un rol de base de datos. Si el rol especificado todavía no existe, se crea automáticamente un rol de base de datos con ese nombre. Los demás usuarios deben tener el permiso SELECT en todas las columnas capturadas de la tabla de origen. Además, cuando se especifica un rol, los usuarios que no sean miembros del rol sysadmin o db_owner también deben ser miembros del rol especificado.
A fin de habilitar la CDC para la tabla que especifica un rol de acceso, ejecute el siguiente T-SQL:
EXEC sys.sp_cdc_enable_table
@source_schema = N'SchemaName',
@source_name = N'TableName',
@role_name = N'RoleName'
GO
Si no desea usar un rol de acceso, debe establecer explícitamente el parámetro @role_name en NULL.
Una función para consultar los cambios netos
Una instancia de captura siempre incluye una función con valores de tabla para devolver todas las entradas de la tabla de cambios que se produjeron durante un intervalo definido. Para denominar esta función, se anexa el nombre de la instancia de captura a cdc.fn_cdc_get_all_changes_. Para obtener más información, consulte cdc.fn_cdc_get_all_changes.
Si el parámetro supports_net_changes está establecido en 1, también se genera una función de cambios netos para la instancia de captura. Esta función devuelve solo un cambio por cada fila distinta que haya cambiado en el intervalo especificado en la llamada. Para obtener más información, consulte cdc.fn_cdc_get_net_changes.
Para poder usar las consultas net changes, la tabla de origen debe tener una clave principal o un índice único que identifique las filas de forma única. Si se usa un índice único, el nombre del índice se debe especificar con el parámetro @index_name . Las columnas definidas en la clave principal o índice único deben estar incluidas en la lista de columnas de origen que se van a capturar.
A fin de habilitar la CDC para una tabla compatible con los cambios netos, ejecute el siguiente T-SQL:
EXEC sys.sp_cdc_enable_table
@source_schema = N'SchemaName',
@source_name = N'TableName',
@role_name = NULL,
@supports_net_changes = 1
GO
Si la captura de datos modificados está habilitada en una tabla con una clave principal existente y el parámetro @index_name no se usa para identificar un índice único alternativo, la característica de captura de datos modificados usará la clave principal. Los cambios subsiguientes en la clave principal no se permiten sin deshabilitar primero la captura de datos modificados para la tabla. Esto es así independientemente de si se solicitó compatibilidad con las consultas net changes cuando se configuró la captura de datos modificados.
Si no hay ninguna clave principal en una tabla en el momento en que se habilita para la captura de datos modificados, la captura de datos modificados omite la incorporación posterior de una clave principal. Dado que la captura de datos modificados no utiliza ninguna clave principal que se cree una vez habilitada la tabla, las columnas de clave y la clave se pueden quitar sin restricciones.
Para obtener más información sobre los argumentos del procedimiento almacenado sys.sp_cdc_enable_table, consulte sys.sp_cdc_enable_table (Transact-SQL).
Sugerencia
Para determinar si una tabla de origen ya está habilitada para la captura de datos modificados, examine la columna is_tracked_by_cdc en la vista de catálogo sys.tables.
Deshabilitación de la CDC para Azure SQL Database
Al deshabilitar la CDC para Azure SQL Database, se quitan todos los metadatos de captura de datos modificados asociados, incluido cdc user, cdc schema, el esquema y los procesos externos de captura y limpieza del planificador. Pero los roles de acceso creados por la captura de datos modificados no se quitan automáticamente y se deben eliminar de forma explícita.
Nota:
Para determinar si CDC está habilitada en una base de datos, consulte la columna is_cdc_enabled en la vista de catálogo sys.databases.
No es necesario deshabilitar la CDC para tablas individuales antes de deshabilitar la CDC en el nivel de base de datos.
Para deshabilitar la CDC en el nivel de base de datos, ejecute el siguiente T-SQL:
EXEC sys.sp_cdc_disable_db;
GO
Sugerencia
Al deshabilitar la CDC en el nivel de base de datos, deberá habilitar la CDC para tablas individuales de nuevo si desea usar la característica de CDC una vez más.
Administración de la CDC
En Azure SQL Database, la CDC es una característica fundamental para administrar los cambios de las tablas de bases de datos y realizar un seguimiento de estos. A diferencia de los entornos tradicionales de SQL Server, Azure SQL Database emplea un planificador de captura de datos modificados para gestionar las tareas de CDC en lugar de confiar en trabajos del Agente SQL Server. Este planificador inicia automáticamente procesos de captura y limpieza periódicos para tablas de CDC de la base de datos, lo que garantiza la confiabilidad y el rendimiento sin dependencias externas.
Captura y limpieza automáticas de la CDC
El trabajo de captura de la CDC en Azure SQL Database funciona sin problemas y se ejecuta cada 20 segundos para realizar un seguimiento eficaz de los cambios. Simultáneamente, el trabajo de limpieza se ejecuta cada hora, lo que garantiza que las tablas de CDC permanezcan optimizadas. Los usuarios pueden estar seguros de que la administración de la CDC se produce automáticamente sin intervención manual.
Importante
Si una base de datos sin servidor tiene habilitada la CDC y está en pausa, la CDC no se ejecuta. El análisis de la CDC no afectará a la característica de pausa automática.
Control manual de la CDC
Mientras la CDC se ejecuta automáticamente, los usuarios mantienen la flexibilidad de realizar operaciones de CDC manuales a petición. Los procedimientos sp_cdc_scan y sp_cdc_cleanup_change_tables permiten desencadenar tareas de captura y limpieza según sea necesario.
Supervisión de la CDC
Azure SQL Database proporciona herramientas valiosas para supervisar las actividades de la CDC. Dos vistas de administración dinámica, sys.dm_cdc_log_scan_sessions y sys.dm_cdc_errors, ofrecen información sobre los procesos de la CDC, lo que garantiza que tiene visibilidad completa de los cambios de los datos.
Personalización de la CDC
Aunque Azure SQL Database simplifica la administración de la CDC, existen algunas limitaciones:
- No se puede personalizar la frecuencia de los trabajos de captura y limpieza de la CDC.
- Los valores de
pollingintervalycontinuousde los trabajos de captura y limpieza no se aplican en Azure SQL Database. - Al quitar la entrada del trabajo de captura de la tabla
cdc.cdc_jobs, no se detiene el trabajo de captura en segundo plano. - Quitar la entrada del trabajo de limpieza hace que se detenga.
- La tabla
cdc.cdc_jobsestá en el esquemacdc, no enmsdb.
A pesar de estas limitaciones, todavía puede personalizar las siguientes opciones:
- Consulte la tabla
cdc.cdc_jobspara obtener detalles de configuración actuales. - Ajuste las opciones
maxtransymaxscansmediante el procedimiento almacenadosp_cdc_change_job. - Administre los trabajos con
sp_cdc_drop_jobysp_cdc_add_jobsegún sea necesario.
Consideraciones y recomendaciones de rendimiento
La habilitación de la captura de datos modificados para Azure SQL Database tienen un efecto en el rendimiento comparable a la habilitación de la CDC para SQL Server o Azure SQL Managed Instance. Sin embargo, hay varios factores que influyen en el efecto en el rendimiento al habilitar la CDC, tales como los siguientes:
Número de tablas con la CDC habilitada en su base de datos de Azure SQL.
Frecuencia de cambios en las tablas con seguimiento o volumen de transacciones. Las transacciones activas evitan el truncamiento del registro hasta que la transacción se confirme y el análisis de la CDC se actualice o la transacción se anule. Esto puede dar lugar a que el registro de transacciones se rellene más de lo habitual y se debe supervisar para que el registro de transacciones no se rellene.
Asegúrese de que haya espacio disponible en la base de datos de origen, ya que los artefactos de la CDC (por ejemplo, tablas CT, cdc_jobs, etc.) se almacenan en la misma base de datos.
Tanto si tiene una base de datos única como si forma parte de un grupo elástico.
Las bases de datos de un grupo elástico comparten recursos entre sí (como el espacio en disco), por lo que si se habilita la CDC en varias bases de datos se corre el riesgo de alcanzar el tamaño máximo del disco del grupo elástico. Supervise los recursos, como el rendimiento del registro, la CPU y la memoria. Para más información, consulte Administración de recursos en grupos elásticos densos.
Al trabajar con bases de datos en grupos elásticos, es fundamental tener en cuenta el recuento de tablas con la CDC habilitada y el número de bases de datos a las que pertenecen esas tablas. Se recomienda evaluar la carga de trabajo y tomar las medidas necesarias, como escalar el grupo elástico. Para más información, consulte Escalar recursos de grupos elásticos en Azure SQL Database.
Importante
Estas consideraciones constituyen instrucciones generales. Si quiere obtener instrucciones precisas para optimizar el rendimiento de una carga de trabajo específica, póngase en contacto con el Soporte técnico de Microsoft.
Tenga en cuenta los siguientes procedimientos recomendados al usar la CDC con Azure SQL Database:
Pruebe la carga de trabajo exhaustivamente antes de habilitar la CDC en bases de datos en producción para determinar la opción de SLO adecuada para la carga de trabajo. Para más información sobre los tamaños de proceso de Azure SQL Database, consulte Niveles de servicio.
Considere la posibilidad de escalar el número de núcleos virtuales o de hacer la transición a un nivel de base de datos superior, como Hiperescala, para mantener el nivel de rendimiento anterior una vez que la CDC se haya habilitado en su base de datos de Azure SQL. Para obtener más información, consulte Modelo de compra de núcleo virtual: Azure SQL Database y Nivel de servicio Hiperescala.
Supervise estrechamente el uso del espacio. Para obtener más información, consulte Administración del espacio de archivo para bases de datos en Azure SQL Database.
Supervise la velocidad de generación de registros. Para más información, consulte Consumo de recursos por cargas de trabajo de usuario y procesos internos.
Los procesos de análisis y limpieza de la CDC forman parte de la carga de trabajo de base de datos normal (también consumen recursos). En función del volumen de transacciones, la degradación del rendimiento puede ser considerable debido a los procesos de análisis y limpieza que no se mantienen al día con la carga de trabajo, ya que se agregan filas completas a las tablas de cambios y, para las operaciones de actualización, también se incluye la imagen previa. Se recomienda evaluar la carga de trabajo y tomar las medidas necesarias según las recomendaciones anteriores. Para obtener más información, consulte la sección Administración de la CDC de este artículo.
Importante
El planificador ejecuta automáticamente la captura y la limpieza en SQL Database. El trabajo de captura de la CDC se ejecuta cada 20 segundos y el trabajo de limpieza se ejecuta cada hora.
Para evitar un aumento de la latencia, asegúrese de que el número de bases de datos con la CDC habilitada no supere el recuento de núcleos virtuales asignados a un grupo elástico. Para obtener más información, consulte Administración de recursos en grupos elásticos densos.
En función de la carga de trabajo y el nivel de rendimiento, considere la posibilidad de cambiar el período de retención de la CDC a un número menor que el valor predeterminado de tres días para asegurarse de que el proceso de limpieza pueda seguir el ritmo de los cambios de la tabla de cambios. Mantener un período de retención menor mientras se supervisa el tamaño de la base de datos es un procedimiento recomendado.
No se proporciona ningún Contrato de nivel de servicio (SLA) sobre cuándo se completan los cambios en las tablas de cambios. Tampoco se admite la latencia en subsegundos.
Problemas y limitaciones conocidos
Truncamiento de registro agresivo
Al habilitar la captura de datos modificados (CDC) en Azure SQL Database, la característica de truncamiento agresivo de registros de Recuperación acelerada de la base de datos (ADR) está deshabilitada. Esto se debe a que el análisis CDC accede al registro de transacciones de la base de datos. Las transacciones activas evitan el truncamiento del registro de transacciones hasta que la transacción se confirme y la CDC se actualice o la transacción se anule. Esto puede dar lugar a que el registro de transacciones se rellene más de lo habitual y se debe supervisar para que el registro de transacciones no se rellene.
Al habilitar la CDC, se recomienda usar la opción de índice reanudable al crear o volver a crear un índice. Los índices reanudables no mantienen abierta una transacción de larga duración y permiten el truncamiento del registro durante la operación para una mejor administración del espacio de registro. Para obtener más información, consulta Directrices para las operaciones de índice en línea: consideraciones sobre el índice reanudable.
Nivel de servicio de Azure SQL Database
Aunque la CDC es compatible con bases de datos y grupos elásticos de cualquier nivel de servicio del modelo de compra basado en núcleo virtual, las bases de datos inferiores a S3 (como Basic, S0, S1, S2) no se admiten en el modelo de compra basado en DTU.
Límites de registro de Azure SQL Database
La Recuperación acelerada de la base de datos y la CDC no son compatibles en Azure SQL Database. Esto se debe a que el análisis de la CDC accede al registro de transacciones de la base de datos e interactúa con él de forma activa, lo que puede entrar en conflicto con el comportamiento de truncamiento agresivo de registro de la ADR.
Para evitar problemas de escalabilidad y administración de espacio, supervise de cerca su base de datos de Azure SQL y considere la posibilidad de escalar a un nivel de base de datos superior y permitir que el registro de transacciones aumente según las necesidades de su carga de trabajo.
Sugerencia
Si la carga de trabajo requiere un mayor rendimiento general debido a una mayor capacidad de proceso del registro de transacciones y tiempos de confirmación de transacciones más rápidos, use el nivel de servicio Hiperescala.
Personalización de la captura y la limpieza
No es posible configurar la frecuencia de captura y los procesos de limpieza de CDC en Azure SQL Database. El planificador ejecuta automáticamente la captura y la limpieza.
Conmutación por error en Azure SQL Database
En caso de escenarios de conmutación por error local o de GeoDR, si la base de datos tiene la CDC habilitado, el proceso de captura y limpieza de los cambios de datos se producirá automáticamente en la nueva base de datos principal después de que se produzca la conmutación por error.
Microsoft Entra ID
Nota:
Microsoft Entra ID era conocido anteriormente como Azure Active Directory (Azure AD).
Si crea una base de datos de Azure SQL Database como usuario de Microsoft Entra y habilita la CDC en ella, un usuario de SQL (por ejemplo, incluso uno con el rol sysadmin) no puede deshabilitar los artefactos de la CDC ni realizar cambios en ellos. Aun así, otro usuario de Microsoft Entra puede habilitar o deshabilitar la CDC en la misma base de datos.
De forma similar, si crea una base de datos como usuario de SQL, la habilitación o deshabilitación de la captura de datos modificados como usuario de Microsoft Entra no funciona.
Se produce un error al habilitar la CDC si crea una base de datos en Azure SQL Database como usuario de Microsoft Entra, no habilita la CDC y, a continuación, intenta habilitar la CDC después de restaurar la base de datos.
Para resolver este problema, conéctese a la base de datos con su cuenta de administrador de Microsoft Entra y ejecute el siguiente T-SQL:
ALTER AUTHORIZATION ON DATABASE::[<restored_db_name>] TO [<azuread_admin_login_name>];
EXEC sys.sp_cdc_enable_db;
Restauración a un momento dado
Si ha habilitado la CDC en su base de datos de Azure SQL como usuario de SQL, la restauración a un momento dado (PITR) conserva la CDC en la base de datos restaurada, a menos que se restaure en un SLO de subnúcleo. Si la restauración se realiza en el SLO de subnúcleo, los artefactos CDC no están disponibles.
Si habilita la CDC en la base de datos como usuario de Microsoft Entra, no es posible realizar la restauración a un momento dado (PITR) en un SLO de subnúcleo. Restaure la base de datos al mismo SLO que el origen o a uno superior y, a continuación, deshabilite la CDC si es necesario.
Solución de problemas
En esta sección se proporcionan instrucciones y pasos de solución de problemas asociados a la CDC en Azure SQL Database. Los errores relacionados con CDC pueden obstruir el funcionamiento adecuado del proceso de captura y provocar la expansión del registro de transacciones de la base de datos.
Para examinar estos errores, puede consultar la vista de administración dinámica sys.dm_cdc_errors. Si la vista de administración dinámica sys.dm_cdc_errors devuelve errores, consulte la sección siguiente para comprender los pasos de mitigación.
Nota:
Para obtener más información sobre un código de error determinado, consulte Eventos y errores del motor de base de datos.
Estas son las distintas categorías de solución de problemas incluidas en esta sección:
| Category | Descripción |
|---|---|
| Metadatos modificados | Incluye información sobre cómo mitigar los problemas relacionados con la CDC cuando se ha modificado o quitado la tabla de seguimiento. |
| Administración del espacio de base de datos | Incluye información sobre cómo mitigar los problemas cuando se ha agotado el espacio de base de datos. |
| Limitación de la CDC | Incluye información sobre cómo mitigar los problemas causados por las limitaciones de la CDC. |
Metadatos modificados
Error 200/208: nombre de objeto no válido
Causa: el error puede producirse cuando se han quitado los metadatos de la CDC. Para que la CDC funcione correctamente, no debe modificar manualmente ningún metadato de CDC como
CDC schema, tablas de cambios, procedimientos almacenados del sistema CDC, permisos decdc userpredeterminados (sys.database_principals) o cambiar el nombre decdc user.Recomendación: para solucionar este problema, debes deshabilitar y volver a habilitar CDC para la base de datos. Cuando se habilita la captura de datos modificados para una base de datos, crea el esquema cdc, el usuario cdc, las tablas de metadatos y otros objetos de sistema para la base de datos. Deberá volver a habilitar manualmente la CDC para tablas individuales después de habilitar la CDC para la base de datos.
Nota:
Los objetos encontrados en la vista de catálogo del sistema sys.objects con is_ms_shipped=1 y schema_name=cdc no deben modificarse ni quitarse.
Error 1202: la entidad de seguridad de base de datos no existe o el usuario no es miembro
Causa: el error puede producirse cuando se ha quitado el usuario de la CDC. Para que la CDC funcione correctamente, no debe modificar manualmente ningún metadato de CDC como
CDC schema, tablas de cambios, procedimientos almacenados del sistema CDC, permisos decdc userpredeterminados (sys.database_principals) o cambiar el nombre decdc user.Recomendación: asegúrate de que el usuario
cdcexiste en la base de datos y también tiene asignado el roldb_owner. Para crear el usuariocdc, consulte el ejemplo Creación de un usuario CDC y asignación de roles.
Error 15517: no se puede ejecutar como entidad de seguridad de base de datos porque la entidad de seguridad no existe
Causa: este tipo de entidad de seguridad no se puede suplantar o bien no tiene permiso. El error puede producirse cuando se han quitado los metadatos CDC o ya no forma parte del rol
db_owner. Para que la CDC funcione correctamente, no debes modificar manualmente ningún metadato de CDC comoCDC schema, tablas de cambios, procedimientos almacenados del sistema CDC, permisos decdc userpredeterminados (sys.database_principals) o cambiar el nombre decdc user.Recomendación: asegúrate de que el usuario
cdcexiste en la base de datos y también tiene asignado el roldb_owner. Para crear el usuariocdc, consulte el ejemplo Creación de un usuario CDC y asignación de roles.
Error 18807: no se puede encontrar un id. de objeto para la tabla del sistema de replicación
Causa: este error se produce cuando SQL Server no encuentra la tabla del sistema de replicación "%s" o no tiene acceso a ella. Esto podría deberse a que falta la tabla o a que no es accesible. Para que la CDC funcione correctamente, no debe modificar manualmente ningún metadato de CDC como
CDC schema, tablas de cambios, procedimientos almacenados del sistema CDC, permisos decdc userpredeterminados (sys.database_principals) o cambiar el nombre decdc user.Recomendación: compruebe que la tabla del sistema existe y que se puede obtener acceso a ella consultándola directamente. Consulte el catálogo del sistema sys.objects y establezca la cláusula predicado con
is_ms_shipped=1yschema_name=cdcpara enumerar todos los objetos relacionados con CDC. Si la consulta no devuelve ningún objeto, debe deshabilitar y volver a habilitar CDC para la base de datos. La habilitación de la captura de datos modificados para una base de datos crea las tablas de metadatoscdc schema,cdc usery otros objetos de sistema para la base de datos. Deberá volver a habilitar manualmente la CDC para tablas individuales después de habilitar la CDC para la base de datos.
Error 21050: solo los miembros del rol fijo de servidor sysadmin o db_owner pueden realizar esta operación
Causa: el usuario
cdcse ha quitado del rol de base de datosdb_ownero del rol del servidorsysadmin.Recomendación: asegúrate de que el usuario
cdctiene asignado el roldb_owner. Para crear el usuariocdc, consulte el ejemplo Creación de un usuario CDC y asignación de roles.
Administración del espacio de base de datos
Error 1105: no se pudo asignar espacio para el objeto de la base de datos porque el grupo de archivos está lleno
Causa: este error se produce cuando el grupo de archivos principal de una base de datos se queda sin espacio y SQL Database no puede asignar más espacio para un objeto (como una tabla o índice) dentro de ese grupo de archivos.
Recomendación: Para resolver este problema, elimine los datos innecesarios de la base de datos para liberar espacio. Identifica tablas, índices u otros objetos no usados en el grupo de archivos que se pueden quitar de forma segura. Supervise con detalle el uso del espacio. Para obtener más información, consulte Administración del espacio de archivos para las bases de datos en Azure SQL Database.
En caso de que quitar datos u objetos innecesarios no sea una opción, considere la posibilidad de escalar a un nivel de base de datos superior.
Importante
Para obtener información detallada sobre los tamaños de proceso (SLO) de Azure SQL Database (base de datos única), consulte Límites de recursos para bases de datos únicas mediante el modelo de compra de núcleo virtual y Límites de recursos para bases de datos únicas mediante el modelo de compra de DTU: Azure SQL Database.
Error 1132: el grupo elástico ha alcanzado su límite de almacenamiento
Causa: este error se produce cuando la utilización del almacenamiento en el grupo elástico ha superado el límite asignado.
Recomendación: Para resolver este problema, implemente estrategias de archivado y purga de datos para mantener solo los datos necesarios en las bases de datos que forman parte del grupo elástico. Supervise estrechamente el uso del espacio. Para obtener más información, consulte Administración del espacio de archivo para bases de datos en Azure SQL Database.
En caso de que archivar datos o quitar datos u objetos innecesarios no sea una opción, considere la posibilidad de escalar a un nivel de base de datos superior.
Importante
Para obtener información detallada sobre los tamaños de proceso (SLO) de Azure SQL Database (base de datos única), consulte Límites de recursos para grupos elásticos mediante el modelo de compra de núcleo virtual y Límites de recursos para grupos elásticos mediante el modelo de compra de DTU.
Limitación de la CDC
Error 2628: los datos binarios o de tipo cadena se truncarían en una tabla
Causa: cambiar el tamaño de las columnas de una tabla con la CDC habilitada mediante instrucciones DDL puede provocar problemas con el proceso de captura de la CDC posterior. La vista de administración dinámica (DMV) de
sys.dm_cdc_errorses útil para comprobar los problemas notificados de CDC, como los errores números 2628 y 8115.Recomendación: antes de realizar cambios en el tamaño de columna, debes evaluar si la alteración es compatible con los datos existentes en las tablas de cambios CDC. Para solucionar este problema, debe deshabilitar y volver a habilitar la CDC para la base de datos. Para obtener más información sobre cómo habilitar la CDC para una base de datos o una tabla, consulte Habilitación de la CDC para Azure SQL Database y Habilitación de la CDC para una tabla en este artículo.
Error 22830: la función integrada “SUSER_SNAME” en el contexto de suplantación no se admite en esta versión de SQL Server.
Causa: este error se produce durante la habilitación de CDC si existe un desencadenador de usuario en la base de datos, que tiene una llamada a
SUSER_SNAME()encreate_table. Puede enumerar desencadenadores con la siguiente secuencia de comandos de Transact-SQL. Este comando proporciona los detalles del desencadenador de objeto y el elemento correspondienteobject_id:SELECT name, object_id FROM sys.triggers WHERE parent_class_desc = 'DATABASE' AND is_disabled = 0;Una vez que obtenga las definiciones de desencadenadores, puede buscar llamadas a
SYSTEM_USERcon la siguiente secuencia de comandos:SELECT OBJECT_DEFINITION(object_id) AS trigger_definition;Recomendación: para resolver este problema, siga estos pasos para cada desencadenador de usuario obtenido de la secuencia de comandos anterior.
- Deshabilitar el desencadenador
- Habilitación de CDC
- Volver a habilitar el desencadenador
Para obtener más información, consulte DISABLE TRIGGER (Transact-SQL).
Error 913: se produce un error en el trabajo de captura de la CDC al procesar los cambios de una tabla con el tipo de datos CLR del sistema
Causa: este error se produce al habilitar la CDC en una tabla con el tipo de datos CLR del sistema, realizar cambios de DML y, a continuación, realizar cambios de DDL en la misma tabla mientras el trabajo de captura de la CDC procesa los cambios relacionados con otras tablas.
Recomendación: Los pasos recomendados son poner DML en modo inactivo en la tabla, ejecutar un trabajo de captura para procesar los cambios, ejecutar DDL para la tabla, ejecutar un trabajo de captura para procesar los cambios de DDL y, a continuación, volver a habilitar el procesamiento de DML. Para obtener más información, consulte Se produce un error en el trabajo de captura CDC al procesar los cambios.
Creación de usuarios y asignación de roles
Si cdc user se quitó, puede volver a agregar el usuario manualmente.
Use el siguiente script de T-SQL para crear un usuario (cdc) y asignar el rol adecuado (db_owner).
IF NOT EXISTS (
SELECT *
FROM sys.database_principals
WHERE NAME = 'cdc'
)
BEGIN
CREATE USER [cdc] WITHOUT LOGIN
WITH DEFAULT_SCHEMA = [cdc];
END
EXEC sp_addrolemember 'db_owner', 'cdc';
Comprobación y adición de pertenencia a roles
Para comprobar si el usuario cdc pertenece al rol sysadmin o db_owner, ejecute la siguiente consulta de T-SQL:
EXECUTE AS USER = 'cdc';
SELECT is_srvrolemember('sysadmin'), is_member('db_owner');
Si el usuario cdc no pertenece a ninguno de los roles, ejecute la siguiente consulta de T-SQL para agregar el rol db_owner al usuario cdc.
EXEC sp_addrolemember 'db_owner' , 'cdc';
Contenido relacionado
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de