Accéder au contenu principal Passer au contenu complémentaire

Restrictions et considérations générales

Vous devez connaître les limitations et les considérations générales suivantes lorsque vous utilisez une source Microsoft SQL Server (Log-Based) :

Restrictions et considérations générales concernant l'ensemble des tâches de données

  • Les définitions de Microsoft SQL Server Replication Publisher pour la base de données qui a été utilisée dans la tâche ne sont pas supprimées si vous supprimez la tâche. Un administrateur système de Microsoft SQL Server doit supprimer ces définitions de Microsoft SQL Server.
  • La réplication des tables Sparse n'est prise en charge en Chargement complet qu'en mode landing.Landing
  • La réplication de données à partir de vues indexées n'est pas prise en charge. Landing
  • Les événements TRUNCATE ne seront pas capturés.
  • Landing de colonnes calculées est pris en charge uniquement dans les tâches de landing pour chargement complet. Pendant le traitement CDC, les opérations INSERT des colonnes calculées apparaissent comme NULL dans la cible et les opérations UPDATE sont ignorées.

  • La commutation de partitions Microsoft SQL Server n'est pas prise en charge.
  • Lorsque vous utilisez les utilitaires WRITETEXT et UPDATEXT, les événements appliqués à la base de données source ne seront pas capturés.
  • Le modèle DML suivant n'est pas pris en charge :

    select <*> into <new_table> from <existing_table>

  • Le chiffrement au niveau des colonnes n'est pas pris en charge.
  • Les limitations suivantes s'appliquent à l'accès aux journaux des transactions de sauvegarde :
    • Les sauvegardes chiffrées ne sont pas prises en charge.
    • Les sauvegardes stockées à une URL ou sur Windows Azure ne sont pas prises en charge.
  • La sauvegarde de Microsoft SQL Server sur plusieurs disques (c.-à-d. MIRROR TO DISK) n'est pas prise en charge.
  • Lors de l'insertion d'une valeur dans les types de données spatiales de SQL Server (GEOGRAPHY et GEOMETRY), on peut soit ignorer la propriété SRID (Spatial Reference System Identifier) - auquel cas le SRID par défaut sera utilisé (0 pour GEOMETRY et 4326 pour GEOGRAPHY), soit spécifier un numéro différent. Lors de la réplication de tables avec des types de données spatiales, le SRID qui a été inséré par l'utilisateur sera remplacé par le SRID par défaut. landing
  • Les index de type Columnstore ne sont pas pris en charge.
  • Les tables optimisées pour la mémoire (utilisant In-Memory OLTP) ne sont pas prises en charge.
  • Les tables temporelles ne sont pas prises en charge.
  • La durabilité retardée n'est pas prise en charge.
  • Le suivi des modifications de table n'est pas pris en charge.
  • Les données masquées sont créées dans la cible sans masque.
  • OpenLDAP n'est pas pris en charge.
  • Répliquer directement à partir d'une base de données secondaire Microsoft SQL Server n'est pas pris en charge. Landing Par conséquent, Microsoft SQL Server connector doit être configuré pour pouvoir se connecter à la base de données principale ou à AlwaysOn Listener.

  • Landing à partir des bases de données pour utiliser l'ADR (Accelerated Database Recovery, récupération de base de données accélérée) n'est pas pris en charge.

  • Landing une table ou un schéma qui contient une apostrophe (') dans son nom n'est pas pris en charge.

  • Les modifications appliquées à la base de données utilisant DACPAC ne sont pas capturées.

  • CDC n'est pas pris en charge à partir de tables qui ont des partitions compressées et non compressées.

  • Les vues et les tables système ne sont pas prises en charge.

Restrictions et considérations générales concernant uniquement les tâches Replicate

  • Le renommage des tables via sp_rename n'est pas pris en charge (par ex., sp_rename 'Sales.SalesRegion', 'SalesReg;).
  • Le renommage des colonnes via sp_rename n'est pas pris en charge (par ex., sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';).
  • Les limitations suivantes s'appliquent à l'accès aux journaux de transactions de sauvegarde au niveau des fichiers :

    • Les journaux des transactions de sauvegarde doivent résider dans un dossier partagé avec les permissions et les droits d'accès appropriés.
    • L'accès aux journaux des transactions actives se fait par l'intermédiaire de l'API de Microsoft SQL Server (et non au niveau des fichiers).
    • Les postes Data Movement gateway et Microsoft SQL Server doivent résider sur le même domaine.
    • Le chiffrement transparent des données (TDE) n'est pas pris en charge. Notez que lorsque vous accédez aux journaux des transactions de sauvegarde en utilisant la fonctionnalité native de SQL Server (c'est-à-dire sans utiliser l'accès au niveau du fichier), le chiffrement TDE est pris en charge.
    • Les plateformes Unix ne sont pas prises en charge.
    • La lecture des journaux de sauvegarde à partir de plusieurs bandes n'est pas prise en charge.
  • La réplication des types de données GEOGRAPHY et GEOMETRY n'est prise en charge qu'en mode LOB limité.
  • Si votre base de données n'est pas configurée pour MS-REPLICATION ou MS-CDC, vous pouvez toujours capturer les tables qui n'ont pas de clé principale, mais gardez à l'esprit que dans une telle configuration, seuls les événements INSERT/DELETE DML seront capturés. Les événements UPDATE seront ignorés.
  • La captures des instructions DDL et DML dans une seule transaction n'est pas prise en charge.

  • Les opérations UPDATE d'une clé primaire/un index unique qui affectent plusieurs lignes peuvent entraîner des conflits lors de l'application des modifications à la cible. Cela peut se produire, par exemple si les opérations UPDATE sont appliquées à la cible comme des opérations INSERT/DELETE plutôt qu'une opération unique UPDATE. Dans un scénario de ce type (où les opérations UPDATE sur une clé primaire/un index unique affectent plusieurs lignes), l'utilisation du mode de traitement des modifications avec application optimisée par lot n'est pas prise en charge, car, sinon, la table risquerait d'être ignorée. Cependant, l'utilisation du mode de traitement des modifications avec application transactionnelle peut provoquer des violations de contraintes.

    Dans ce cas, vous devez soit actualiser la table pertinente, soit localiser les enregistrements problématiques dans la table de contrôle Appliquer les exceptions et les éditer manuellement dans la base de données cible. Voir également : Change processing tuning.

Fonctionnalités de sécurité de Microsoft SQL Server non prises en charge

Les tables qui utilisent les fonctionnalités de sécurité Microsoft SQL Server suivantes ne sont pas prises en charge :

  • Always Encrypted
  • Row-Level Security

Types de données non pris en charge

Les types de données suivants ne sont pas pris en charge :

  • CURSOR
  • SQL_VARIANT
  • TABLE
Note Informations

Les types de données définis par l'utilisateur sont pris en charge en fonction de leur type de base. Par exemple, les types de données définis par l'utilisateur en fonction de DATETIME sont traités comme un type de données DATETIME.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – dites-nous comment nous améliorer !