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

Pour synchroniser vos bases de données d'analyse et en aval, vous pouvez utiliser Datastream pour répliquer les données historiques et les modifications en cours à partir d'une base de données SQL Server.

Pour les sources SQL Server dans Datastream, consultez le comportement de réplication et les méthodes de capture de données modifiées (CDC), les versions et éditions compatibles, ainsi que les limites connues.

Comportement

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

Modifier les tables

La méthode CDC des tables de modifications permet aux utilisateurs de conserver les journaux pendant une période plus courte et d'économiser ainsi de l'espace de stockage, mais elle offre 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, il élimine le risque de troncation des journaux entraînant l'échec permanent des flux et accepte la réplication des tables chiffrées. Pour en savoir plus, consultez Limites 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 commit.

Comment Datastream gère les modifications LDD du 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 accepte 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 console Google Cloud .

    Accéder à la page "Flux"

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

  3. Sur la page Détails du flux, cliquez sur Suspendre.

  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 diffusion.

Datastream vérifie la table cdc.ddl_history toutes les cinq minutes pour détecter les nouveaux LDD. Si une 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 pour indiquer que la modification du 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 de 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. En revanche, si vous conservez les fichiers journaux trop longtemps, ils occupent de l'espace de stockage, ce qui peut finir par faire passer 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 troncation 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 troncation. Ces étapes fournissent une couche de protection supplémentaire pour s'assurer que Datastream peut lire les données même en cas d'indisponibilité 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 SQL Server source 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é (sur site ou hébergé 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 à la version 2014
  • SQL Server Express
  • SQL Server Web

Limitations connues

Voici certaines des limitations connues affectant l'utilisation d'une base de données SQL Server comme source :

  • 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 possède un index unique.
    2. Aucune des colonnes d'index ne peut être nullable.
    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 accélérée de base de données (ADR) est activée ne sont pas compatibles.
  • La diffusion en continu des modifications apportées aux tables système n'est pas prise en charge.
  • L'authentification Windows Active Directory (AD) n'est pas prise en charge.

  • 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 acceptés et ne sont pas répliqués vers la destination :

    • SQL_VARIANT
    • HIERARCHYID

  • 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 en tant que VARCHAR(50).

  • Datastream n'est pas compatible avec la CDC pour les colonnes d'objets volumineux (TEXT, NTEXT, XML, IMAGE, GEOMETRY, GEOGRAPHY) 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 prise en charge.

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

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

    • Modification des types de données : le job de capture CDC SQL Server ne propage que les modifications de types de données suivantes :

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

      Pour les autres modifications de types 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 ne permet pas de répliquer des tables incluant des colonnes avec masquage des données. Les données sont répliquées sans masquage.

  • Datastream ne permet pas de répliquer les modifications appliquées à la base de données à l'aide du package DACPAC (Data Tier Application Package).

  • Datastream ne réplique pas les modifications apportées à l'aide des instructions WRITETEXT ou UPDATETEXT.

  • Si vous utilisez l'étiquette 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 n'accepte que deux instances de capture par table, les modifications de schéma peuvent entraîner des conditions de concurrence lorsque Datastream tente de créer des instances de capture, ce qui peut entraîner l'échec des flux.

  • Datastream ne permet pas de répliquer les colonnes calculées, sauf si la colonne est marquée comme PERSISTED.

  • Datastream n'accepte pas les types de compression PAGE, COLUMNSTORE ou 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 pris en charge. 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 ne permet pas de répliquer les 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 vers 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 index unique non groupé avec une ou plusieurs colonnes de longueur variable (VARCHAR, VARBINARY, NVARCHAR, GEOMETRY, GEOGRAPHY)

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

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

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

  • Lorsque vous utilisez la méthode des journaux de transactions, Datastream interroge la base de données source pour récupérer les valeurs manquantes à un moment précis dans un processus de recherche actif appelé "supplémentation". La supplémentation s'applique aux types de données XML, TEXT, NTEXT, IMAGE, GEOMETRY et GEOGRAPHY, ainsi qu'aux types de longueur variable tels que VARCHAR(MAX) ou VARBINARY lorsque les lignes dépassent la limite de 8 Ko par page. Étant donné que Datastream complète ces colonnes en interrogeant la base de données, les modifications intermédiaires peuvent ne pas être capturées dans les scénarios impliquant des mises à jour rapides et consécutives ou une suppression rapide après une insertion. Les opérations DELETE ne déclenchent pas de supplémentation. Cette limitation est particulièrement pertinente lorsque vous utilisez le mode d'écriture "Ajout uniquement", qui s'attend à ce que toutes les modifications intermédiaires soient capturées.

Étapes suivantes