Transmite datos desde bases de datos de SQL Server

En esta página, se incluye información sobre lo siguiente:

  • El comportamiento de Datastream en relación con el manejo de los datos que se extraen de una base de datos de origen de SQL Server
  • Los métodos de captura de datos modificados (CDC) que admite Datastream
  • Las versiones de bases de datos de SQL Server que admite Datastream
  • Las limitaciones conocidas para usar la base de datos de SQL Server como fuente

Comportamiento

Datastream hace un seguimiento de los cambios del lenguaje de manipulación de datos (DML) con uno de los siguientes métodos de CDC:

Cambiar tablas

El método de CDC para cambiar tablas permite a los usuarios conservar los registros durante un período más corto y, por lo tanto, ahorrar espacio de almacenamiento, pero admite una capacidad de procesamiento más baja en comparación con el método de registros de transacciones. El método tiene menos limitaciones que los registros de transacciones. Por ejemplo, elimina el riesgo de que el truncamiento de registros provoque fallas permanentes en las transmisiones y admite la replicación de tablas encriptadas. Para obtener más información, consulta Limitaciones conocidas.

Cuando se usa este método de CDC, los cambios en la fuente se rastrean con tablas de cambios dedicadas. Los registros de transacciones aún se usan, pero de forma limitada, y no es necesario conservarlos durante períodos más largos. A medida que se aplican eventos DML a las tablas de origen, los cambios se replican en las tablas de cambios correspondientes. Las tablas de cambios tienen la misma estructura que las tablas de origen, pero con columnas adicionales para incluir los metadatos de los cambios. Solo las transacciones confirmadas se agregan a las tablas de cambios, junto con el número de secuencia de registro (LSN) de la operación de confirmación.

Cómo Datastream maneja los cambios de DDL en el esquema de origen

Cuando usas el método de CDC para cambiar tablas, se crean instancias de captura para cada tabla de cambios. Cada instancia de captura está asociada con una lista de columnas que captura y rastrea. De forma predeterminada, cuando se produce un cambio en el lenguaje de definición de datos (DDL) en la fuente después de que se crea la instancia de captura, la instancia ignora el cambio. Sin embargo, puedes configurar tu transmisión de SQL Server para replicar las columnas agregadas al esquema de origen después de que se creen la transmisión y la instancia de captura.

Antes de comenzar
  • Asegúrate de que tu usuario de Datastream tenga asignado el permiso db_owner.

Replica las columnas agregadas al esquema de origen

Para que Datastream admita la replicación de columnas agregadas al esquema de origen después de que se creó una transmisión, debes agregar la etiqueta enable_ddl_support_for_ct a tu transmisión:

  1. Ve a la página Transmisiones en la Google Cloud consola.

    Ir a la página Transmisiones

  2. Haz clic en la transmisión de SQL Server que deseas editar.

  3. En la página Detalles de la transmisión, haz clic en Pausar.

  4. Haz clic en Editar > Editar configuración de la transmisión.

  5. Haz clic en Agregar etiqueta.

  6. En el campo Clave, escribe enable_ddl_support_for_ct.

  7. En el campo Valor, escribe true.

  8. Haz clic en Guardar.

  9. Haz clic en Iniciar para reanudar la transmisión.

Datastream verifica la cdc.ddl_history tabla para ver si hay DDL nuevos cada cinco minutos. Si se agrega una columna nueva a una tabla incluida en la configuración de la transmisión, Datastream verifica si la tabla tiene dos instancias de captura:

  • Si no es así, Datastream crea una instancia de captura nueva, lee los datos de la instancia de captura original hasta el momento en que ocurrió el DDL y, luego, comienza a leer desde la instancia de captura nueva.

  • Si es así, se agrega una entrada de registro que indica que no se puede controlar el cambio de DDL porque se alcanzó la cantidad máxima de instancias de captura.

Registros de transacciones

Cuando se usa este método de CDC, Datastream lee los cambios en la fuente directamente desde los registros de transacciones. Este método requiere menos recursos y permite una recuperación de datos más rápida, pero tiene más limitaciones.

Para evitar la pérdida de datos, es importante que los registros no se trunquen antes de que Datastream los lea. Por otro lado, si conservas los archivos de registro durante demasiado tiempo, ocuparán espacio de almacenamiento, lo que podría hacer que la instancia de base de datos entre en modo de solo lectura.

Para asegurarte de que el lector de CDC tenga suficiente tiempo para leer los registros y, al mismo tiempo, permitir el truncamiento de registros para liberar espacio de almacenamiento, debes aplicar pasos de configuración adicionales, como cambiar los intervalos de sondeo y configurar una protección de truncamiento. Estos pasos proporcionan una capa adicional de protección para garantizar que Datastream pueda leer los datos, incluso si hay tiempo de inactividad en el lado de Datastream o un problema de conectividad entre la base de datos de origen y Datastream.

Para obtener instrucciones detalladas sobre cómo aplicar estas medidas adicionales, consulta la página Configura una base de datos de origen de SQL Server y selecciona el tipo de base de datos.

Versiones

Datastream admite las siguientes versiones y ediciones de bases de datos de SQL Server:

  • Autoadministrado (local o alojado en la nube) con las siguientes versiones:
    • Enterprise: 2008 y versiones posteriores
    • Standard: 2016 SP1 y versiones posteriores
    • Developer: 2008 y versiones posteriores
  • Amazon RDS for SQL Server

  • Azure SQL Database (nivel S3 y superiores)

  • Cloud SQL para SQL Server

Datastream no admite las siguientes versiones de bases de datos de SQL Server:

  • SQL Server Standard Edition de la versión 2008 a la 2014
  • SQL Server Express
  • SQL Server Web

Limitaciones conocidas

Entre las limitaciones conocidas para usar la base de datos de SQL Server como fuente, se incluyen las siguientes:

  • Las transmisiones se limitan a 10,000 tablas.
  • No se puede reabastecer una tabla que tenga más de 500 millones de filas, a menos que se cumplan las siguientes condiciones:
    1. La tabla tiene un índice único.
    2. Ninguna de las columnas de índice puede aceptar valores nulos.
    3. Todas las columnas del índice se incluyen en la transmisión.
  • No se admiten las bases de datos con durabilidad retrasada o recuperación acelerada de la base de datos (ADR) habilitada.
  • No se admite la transmisión de cambios a las tablas del sistema.
  • No se admite la autenticación de Active Directory (AD) de Windows.

  • Datastream admite todas las intercalaciones de SQL Server, excepto las que tienen la página de códigos 0. Para verificar la página de códigos de una intercalación específica, ejecuta la siguiente consulta en tu instancia de SQL Server:

    SELECT *, CAST(COLLATIONPROPERTY(name, 'CodePage') AS INT) FROM sys.fn_helpcollations() WHERE name = COLLATION_NAME;

  • No se admiten los siguientes tipos de datos y no se replican en el destino:

    • SQL_VARIANT
    • HIERARCHYID
    • GEOMETRY
    • GEOGRAPHY

  • Datastream replica los tipos de datos definidos por el usuario. Sin embargo, es el tipo de datos base del que derivas tu tipo definido por el usuario el que se almacena en el destino. Por ejemplo, si defines un tipo de datos USERNAME basado en el tipo de datos VARCHAR(50), los datos se almacenan en el destino como VARCHAR(50).

  • Datastream no admite CDC para columnas grandes de objetos (TEXT, NTEXT, XML, IMAGE) ni columnas de longitud variable máxima (VARCHAR(MAX), VARBINARY(MAX), NVARCHAR(MAX)) en tablas sin un índice único.

    Si las columnas grandes de objetos no se incluyen en la transmisión, se admite CDC.

  • No se admite la replicación de los siguientes cambios de esquema de origen cuando se usa el método de CDC para cambiar tablas, y puede causar daños en los datos o fallas en el procesamiento de eventos:

    • Eliminar columnas: Los datos de estas columnas se reemplazan por valores NULL.
    • Cambiar el nombre de las columnas: No se admite para SQL Server cuando CDC está habilitado.

    • Modificar tipos de datos: El trabajo de captura de CDC de SQL Server propaga solo los siguientes cambios de tipo de datos:

      • Cambiar la longitud máxima de las cadenas: Por ejemplo, cambiar el tipo de datos VARCHAR(50) a VARCHAR(100). La columna STRING de BigQuery no tiene una longitud fija y acepta la cadena más larga.
      • Aumentar el rango de valores enteros: Por ejemplo, cambiar el INT tipo de datos a BIGINT. El tipo de datos INT64 de BigQuery admite el tipo nuevo sin requerir un cambio de esquema.
      • Cambiar la precisión y la escala de los valores numéricos: Por ejemplo, cambiar el tipo de datos DECIMAL(10, 2) a DECIMAL(18, 4). El tipo NUMERIC de BigQuery tiene una precisión (38) y una escala (9) fijas grandes, y se admite ese cambio.

      Para otras modificaciones de tipo de datos, Datastream intenta insertar los datos en el destino y genera un error si se rechazan los datos.

  • Datastream no admite la replicación de tablas que incluyen columnas con enmascaramiento de datos. Los datos se replican sin enmascaramiento.

  • Datastream no admite la replicación de cambios aplicados a la base de datos con el paquete de Data Tier Application Package (DACPAC).

  • Datastream no replica los cambios realizados con las instrucciones WRITETEXT o UPDATETEXT.

  • Si usas la etiqueta enable_ddl_support_for_ct para replicar las columnas agregadas al esquema de origen, no puedes tener varias transmisiones adjuntas a la misma tabla de origen de SQL Server. Debido a que SQL Server admite un máximo de dos instancias de captura por tabla, los cambios de esquema pueden causar condiciones de carrera en las que Datastream intenta crear instancias de captura, lo que puede provocar fallas en las transmisiones.

  • Datastream no admite la replicación de columnas calculadas, a menos que la columna esté marcada como PERSISTED.

  • Datastream no admite los tipos de compresión PAGE, COLUMNSTORE ni COLUMNSTORE ARCHIVE.

Limitaciones adicionales cuando se usa el método de registros de transacciones

Si usas el método de CDC de registros de transacciones, se aplican las siguientes limitaciones adicionales:

  • No se admite la encriptación de datos transparente (TDE).
  • No se admite la encriptación a nivel de columna. Los datos de estas columnas se reemplazan por valores NULL.
  • Cuando se usa el método de CDC de registros de transacciones, Datastream no admite la replicación de columnas agregadas al esquema de origen después de que se crea una transmisión. Las columnas nuevas no se replican en el destino.
  • Datastream no admite la instrucción ROLLBACK TO SAVEPOINT. Esos eventos de reversión se ignoran y no se replican en el destino.
  • Datastream no admite CDC para filas superiores a 8 KB en los siguientes tipos de tablas:
    • Tablas sin un índice único
    • Tablas que contienen solo un índice único no agrupado en clústeres con una o más columnas de longitud variable (VARCHAR, VARBINARY, NVARCHAR)

  • Datastream no admite CDC para columnas grandes de objetos (TEXT, NTEXT, XML, IMAGE) en los siguientes tipos de tablas:

    • Tablas sin un índice único
    • Tablas que contienen solo un índice único no agrupado en clústeres con una o más columnas de longitud variable (VARCHAR, VARBINARY, NVARCHAR)

    Si las columnas grandes de objetos no se incluyen en la transmisión, CDC solo se admite para esas tablas si tienen índices válidos.

  • Cuando se usa el método de registros de transacciones, Datastream debe consultar la base de datos de origen para recuperar los valores faltantes en un momento determinado (en un proceso de búsqueda activa llamado complementación) para los tipos de datos XML, TEXT, NTEXT y IMAGE, así como para los tipos de longitud variable (como VARCHAR(MAX) o VARBINARY) cuando las filas superan el límite de página de 8 KB. Debido a que Datastream complementa estas columnas consultando la base de datos, es posible que no se capturen los cambios intermedios en situaciones que impliquen actualizaciones rápidas y consecutivas o una eliminación rápida después de una inserción. Ten en cuenta que las operaciones DELETE no activan la complementación. Esta limitación es especialmente relevante cuando se usa el modo de escritura de solo anexar, que espera que se capturen todos los cambios intermedios.

¿Qué sigue?