Transmite datos desde bases de datos de SQL Server

Para mantener sincronizadas tus bases de datos de estadísticas y downstream, puedes usar Datastream para replicar datos históricos y cambios continuos de una base de datos de SQL Server.

Para las fuentes de SQL Server en Datastream, revisa el comportamiento de replicación y los métodos de captura de datos modificados (CDC), las versiones y ediciones compatibles, y las limitaciones conocidas.

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 de tablas de cambios permite que los usuarios retengan los registros durante un período más corto y, por lo tanto, ahorren espacio de almacenamiento, pero admite una capacidad de procesamiento menor en comparación con el método de registros de transacciones. Este método tiene menos limitaciones que los registros de transacciones. Por ejemplo, elimina el riesgo de que el truncamiento de registros provoque que las transmisiones fallen de forma permanente 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 registran con tablas de cambios dedicadas. Los registros de transacciones se siguen usando, pero de forma limitada, y no es necesario que los conserves por períodos más largos. A medida que los eventos de DML se aplican 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 controla los cambios de DDL en el esquema de origen

Cuando usas el método CDC de tablas de cambios, se crean instancias de captura para cada tabla de cambios. Cada instancia de captura está asociada con una lista de columnas que captura y supervisa. 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 consola de Google Cloud .

    Ir a la página Transmisiones

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

  3. En la página Detalles de las transmisiones, 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 tabla cdc.ddl_history en busca de DDL nuevas 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 se produjo 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 usas 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 recuperar datos con mayor rapidez, 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 la 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 que el truncamiento de registros libere 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 SQL Server de origen y selecciona tu 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
    • Desarrollador: 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 que tiene el uso de la base de datos de SQL Server como fuente, se incluyen las siguientes:

  • Las transmisiones están limitadas a 10,000 tablas.
  • Una tabla que tiene más de 500 millones de filas no se puede reabastecer, a menos que se cumplan las siguientes condiciones:
    1. La tabla tiene un índice único.
    2. Ninguna de las columnas de índice puede ser nula.
    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 bases de datos (ADR) habilitadas.
  • No se admite la transmisión de cambios en 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 aquellas con 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;
    
  • Los siguientes tipos de datos no se admiten y no se replican en el destino:

    • SQL_VARIANT
    • HIERARCHYID
  • Datastream replica los tipos de datos definidos por el usuario, pero es el tipo de datos base del que derivas el tipo definido por el usuario que se almacena en el destino. Por ejemplo, si defines un tipo de datos USERNAME según el tipo de datos VARCHAR(50), los datos se almacenan en el destino como VARCHAR(50).

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

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

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

    • Se descartan columnas: los datos de estas columnas se reemplazan por valores NULL.
    • Cambiar el nombre de las columnas: No se admite en SQL Server cuando la CDC está habilitada.
    • Modifica los 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 de números enteros: por ejemplo, cambiar el tipo de datos INT a BIGINT. El tipo de datos INT64 de BigQuery se adapta al tipo nuevo sin necesidad de cambiar el 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 fija grande (38) y una escala (9), y se admite ese cambio.

      Para otras modificaciones de tipos 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 los cambios aplicados a la base de datos con el paquete de aplicación de capa de datos (DACPAC).

  • Datastream no replica los cambios realizados con las declaraciones 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 que las transmisiones fallen.

  • 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 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 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 sentencia ROLLBACK TO SAVEPOINT. Estos eventos de reversión se ignoran y no se replican en el destino.
  • Datastream no admite CDC para filas de más de 8 KB en los siguientes tipos de tablas:
    • Tablas sin un índice único
    • Tablas que contienen solo un índice único no agrupado con una o más columnas de longitud variable (VARCHAR, VARBINARY, NVARCHAR, GEOMETRY, GEOGRAPHY)
  • Datastream no admite CDC para columnas de objetos grandes (TEXT, NTEXT, XML, IMAGE, GEOMETRY, GEOGRAPHY) en los siguientes tipos de tablas:

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

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

  • Cuando se usa el método de registros de transacciones, Datastream consulta la base de datos de origen para recuperar los valores faltantes en un momento determinado en un proceso de búsqueda activo llamado complementación. La complementación se aplica a los tipos de datos XML, TEXT, NTEXT, IMAGE, GEOMETRY y GEOGRAPHY, y a 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 con consultas a 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. 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?