Traiter des flux de données à partir de bases de données SQL Server

Cette page contient des informations sur les éléments suivants :

  • Le comportement de Datastream lors de la gestion des données extraites d'une base de données source SQL Server.
  • Les méthodes de capture des données modifiées (CDC, Change Data Capture) compatibles avec Datastream.
  • Les versions de bases de données SQL Server compatibles avec Datastream.
  • Les limites connues d'utilisation de la base de données SQL Server en tant que source.

Comportement

Datastream suit les modifications du langage de manipulation de données (LMD) à l'aide de l'une des méthodes CDC suivantes :

Tables de modifications

La méthode CDC des tables de modifications permet aux utilisateurs de conserver les journaux pendant une période plus courte et ainsi d'économiser de l'espace de stockage, mais elle est compatible avec un débit inférieur à celui de la méthode des journaux de transactions. Cette méthode présente moins de limites que les journaux de transactions. Par exemple, elle élimine le risque de troncature des journaux entraînant l'échec permanent des flux et est compatible avec la réplication des tables chiffrées. Pour en savoir plus, consultez la section Limitations connues.

Lorsque vous utilisez cette méthode CDC, les modifications apportées à la source sont suivies à l'aide de tables de modifications dédiées. Les journaux de transactions sont toujours utilisés, mais dans une mesure limitée, et vous n'avez pas besoin de les conserver pendant de longues périodes. Lorsque des événements LMD sont appliqués aux tables sources, les modifications sont répliquées dans les tables de modifications correspondantes. Les tables de modifications ont la même structure que les tables sources, mais avec des colonnes supplémentaires pour inclure les métadonnées des modifications. Seules les transactions validées sont ajoutées aux tables de modifications, ainsi que le numéro de séquence de journal (LSN) de l'opération de validation.

Comment Datastream gère les modifications LDD apportées au schéma source

Lorsque vous utilisez la méthode CDC des tables de modifications, des instances de capture sont créées pour chaque table de modifications. Chaque instance de capture est associée à une liste de colonnes qu'elle capture et suit. Par défaut, lorsqu'une modification du langage de définition de données (LDD) se produit dans la source après la création de l'instance de capture, l'instance ignore la modification. Toutefois, vous pouvez configurer votre flux SQL Server pour répliquer les colonnes ajoutées au schéma source après la création du flux et de l'instance de capture.

Avant de commencer
  • Assurez-vous que l'autorisation db_owner est attribuée à votre utilisateur Datastream.

Répliquer les colonnes ajoutées au schéma source

Pour que Datastream soit compatible avec la réplication des colonnes ajoutées au schéma source après la création d'un flux, vous devez ajouter le libellé enable_ddl_support_for_ct à votre flux :

  1. Accédez à la page Flux dans la Google Cloud console.

    Accéder à la page "Flux"

  2. Cliquez sur le flux SQL Server que vous souhaitez modifier.

  3. Sur la page Détails des flux, cliquez sur Mettre en veille.

  4. Cliquez sur Modifier > Modifier les paramètres du flux.

  5. Cliquez sur Ajouter une étiquette.

  6. Dans le champ Clé, saisissez enable_ddl_support_for_ct.

  7. Dans le champ Value (Valeur), saisissez true.

  8. Cliquez sur Enregistrer.

  9. Cliquez sur Démarrer pour reprendre votre flux.

Datastream vérifie la présence de nouveaux LDD dans la cdc.ddl_history table toutes les cinq minutes. Si une nouvelle colonne est ajoutée à une table incluse dans la configuration du flux, Datastream vérifie si la table comporte deux instances de capture :

  • Si ce n'est pas le cas, Datastream crée une instance de capture, lit les données de l'instance de capture d'origine jusqu'au moment où le LDD s'est produit, puis commence à lire à partir de la nouvelle instance de capture.

  • Si c'est le cas, une entrée de journal est ajoutée indiquant que la modification LDD ne peut pas être gérée, car le nombre maximal d'instances de capture est atteint.

Journaux de transactions

Lorsque vous utilisez cette méthode CDC, Datastream lit les modifications dans la source directement à partir des journaux de transactions. Cette méthode nécessite moins de ressources et permet une récupération plus rapide des données, mais elle présente plus de limites.

Pour éviter toute perte de données, il est important que les journaux ne soient pas tronqués avant que Datastream ne les lise. D'un autre côté, si vous conservez les fichiers journaux trop longtemps, ils occupent de l'espace de stockage, ce qui peut finir par entraîner le passage de l'instance de base de données en mode lecture seule.

Pour vous assurer que le lecteur CDC dispose de suffisamment de temps pour lire les journaux tout en permettant la troncature des journaux afin de libérer de l'espace de stockage, vous devez appliquer des étapes de configuration supplémentaires, telles que la modification des intervalles d'interrogation et la configuration d'une protection contre la troncature. Ces étapes offrent une couche de protection supplémentaire pour s'assurer que Datastream peut lire les données même en cas de temps d'arrêt du côté de Datastream ou de problème de connectivité entre la base de données source et Datastream.

Pour obtenir des instructions détaillées sur l'application de ces mesures supplémentaires, consultez la page Configurer une base de données source SQL Server et sélectionnez votre type de base de données.

Versions

Datastream est compatible avec les versions et éditions suivantes des bases de données SQL Server :

  • Autogérées (sur site ou hébergées dans le cloud) à l'aide des versions suivantes :
    • Enterprise : 2008 et versions ultérieures
    • Standard : 2016 SP1 et versions ultérieures
    • Developer : 2008 et versions ultérieures
  • Amazon RDS pour SQL Server

  • Azure SQL Database (niveau S3 et supérieur).

  • Cloud SQL pour SQL Server

Datastream n'est pas compatible avec les versions suivantes des bases de données SQL Server :

  • SQL Server Standard Edition de la version 2008 à 2014
  • SQL Server Express
  • SQL Server Web

Limitations connues

Les limites connues d'utilisation de la base de données SQL Server en tant que source incluent les suivantes :

  • Les flux sont limités à 10 000 tables.
  • Une table contenant plus de 500 millions de lignes ne peut pas être remplie, sauf si les conditions suivantes sont remplies :
    1. La table comporte un index unique.
    2. Aucune des colonnes d'index ne peut être laissée vide.
    3. Toutes les colonnes de l'index sont incluses dans le flux.
  • Les bases de données pour lesquelles la durabilité retardée ou la récupération de base de données accélérée (ADR) sont activées ne sont pas compatibles.
  • La diffusion en flux des modifications apportées aux tables système n'est pas compatible.
  • L'authentification Windows Active Directory (AD) n'est pas compatible.

  • Datastream est compatible avec tous les classements SQL Server, à l'exception de ceux dont la page de codes est 0. Pour vérifier la page de codes d'un classement spécifique, exécutez la requête suivante sur votre instance SQL Server :

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

  • Les types de données suivants ne sont pas compatibles et ne sont pas répliqués dans la destination :

    • SQL_VARIANT
    • HIERARCHYID
    • GEOMETRY
    • GEOGRAPHY

  • Datastream réplique les types de données définis par l'utilisateur. Toutefois, c'est le type de données de base à partir duquel vous dérivez votre type défini par l'utilisateur qui est stocké dans la destination. Par exemple, si vous définissez un type de données USERNAME basé sur le type de données VARCHAR(50), les données sont stockées dans la destination sous la forme VARCHAR(50).

  • Datastream n'est pas compatible avec la CDC pour les colonnes d'objets volumineux (TEXT, NTEXT, XML, IMAGE) et les colonnes de longueur variable maximale (VARCHAR(MAX), VARBINARY(MAX), NVARCHAR(MAX)) dans les tables sans index unique.

    Si les colonnes d'objets volumineux ne sont pas incluses dans le flux, la CDC est compatible.

  • La réplication des modifications de schéma source suivantes n'est pas compatible lorsque vous utilisez la méthode CDC des tables de modifications et peut entraîner une corruption des données ou l'échec du traitement des événements :

    • Suppression de colonnes : les données de ces colonnes sont remplacées par des valeurs NULL.
    • Renommage des colonnes : non compatible avec SQL Server lorsque la CDC est activée.

    • Modification des types de données : la tâche de capture CDC SQL Server ne propage que les modifications de type de données suivantes :

      • Modification de la longueur maximale des chaînes : par exemple, modification du type de données VARCHAR(50) en VARCHAR(100). La colonne BigQuery STRING n'a pas de longueur fixe et accepte la chaîne la plus longue.
      • Augmentation de la plage de valeurs entières : par exemple, modification du INT type de données en BIGINT. Le type de données BigQuery INT64 s'adapte au nouveau type sans nécessiter de modification de schéma.
      • Modification de la précision et de l'échelle des valeurs numériques : par exemple, modification du type de données DECIMAL(10, 2) en DECIMAL(18, 4). Le type BigQuery NUMERIC a une précision (38) et une échelle (9) fixes élevées, et une telle modification est compatible.

      Pour les autres modifications de type de données, Datastream tente d'insérer les données dans la destination et génère une erreur si les données sont rejetées.

  • Datastream n'est pas compatible avec la réplication des tables qui incluent des colonnes avec masquage des données. Les données sont répliquées sans masquage.

  • Datastream n'est pas compatible avec la réplication des modifications appliquées à la base de données à l'aide du package DACPAC (Data Tier Application Package).

  • Datastream n'est pas compatible avec la réplication des modifications apportées à l'aide des instructions WRITETEXT ou UPDATETEXT.

  • Si vous utilisez le libellé enable_ddl_support_for_ct pour répliquer les colonnes ajoutées au schéma source, vous ne pouvez pas associer plusieurs flux à la même table source SQL Server. Étant donné que SQL Server est compatible avec un maximum de deux instances de capture par table, les modifications de schéma peuvent entraîner des conditions de concurrence dans lesquelles Datastream tente de créer des instances de capture, ce qui peut entraîner l'échec des flux.

  • Datastream n'est pas compatible avec la réplication des colonnes calculées, sauf si la colonne est marquée comme PERSISTED.

  • Datastream n'est pas compatible avec les types de compression PAGE, COLUMNSTORE ni COLUMNSTORE ARCHIVE.

Limites supplémentaires lors de l'utilisation de la méthode des journaux de transactions

Si vous utilisez la méthode CDC des journaux de transactions, les limites supplémentaires suivantes s'appliquent :

  • Le chiffrement transparent des données (TDE) n'est pas compatible.
  • Le chiffrement au niveau des colonnes n'est pas compatible. Les données de ces colonnes sont remplacées par des valeurs NULL.
  • Lorsque vous utilisez la méthode CDC des journaux de transactions, Datastream n'est pas compatible avec la réplication des colonnes ajoutées au schéma source après la création d'un flux. Les nouvelles colonnes ne sont pas répliquées dans la destination.
  • Datastream n'est pas compatible avec l'instruction ROLLBACK TO SAVEPOINT. Ces événements de rollback sont ignorés et ne sont pas répliqués dans la destination.
  • Datastream n'est pas compatible avec la CDC pour les lignes de plus de 8 Ko dans les types de tables suivants :
    • Tables sans index unique
    • Tables ne contenant qu'un seul index unique non clusterisé avec une ou plusieurs colonnes de longueur variable (VARCHAR, VARBINARY, NVARCHAR)

  • Datastream n'est pas compatible avec la CDC pour les colonnes d'objets volumineux (TEXT, NTEXT, XML, IMAGE) dans les types de tables suivants :

    • Tables sans index unique
    • Tables ne contenant qu'un seul index unique non clusterisé avec une ou plusieurs colonnes de longueur variable (VARCHAR, VARBINARY, NVARCHAR)

    Si les colonnes d'objets volumineux ne sont pas incluses dans le flux, la CDC n'est compatible avec ces tables que si elles comportent des index valides.

Étape suivante