SQL Server : Types de données, objets et opérations pris en charge

Découvrez les informations de prise en charge d'Oracle GoldenGate sur la base de données SQL Server.

Oracle GoldenGate for SQL Server prend en charge la capture et la distribution des données de chargement initial et transactionnelles pour les versions de base de données SQL Server prises en charge.

Oracle GoldenGate for SQL Server prend en charge la mise en correspondance, le filtrage et la transformation des données source, sauf indication contraire dans ce document, ainsi que la réplication des données dérivées d'autres bases de données source prises en charge par Oracle GoldenGate en bases de données SQL Server.

Exigences relatives à l'instance

Le nom du serveur SQL Server (@@SERVERNAME) ne doit pas être NULL.
(Extract) Pour qu'Oracle GoldenGate capture les données transactionnelles, l'agent SQL Server doit être exécuté sur l'instance SQL Server source et le travail SQL Server Change Data Capture doit être exécuté sur la base de données. Si la réplication transactionnelle SQL Server est également activée pour la base de données, l'agent SQL Server Log Reader doit être en cours d'exécution.
Si vos données pour les colonnes TEXT, NTEXT, IMAGE, ou VARCHAR(MAX), NVARCHAR(MAX) et VARBINARY(MAX) dépassent la taille par défaut de SQL Server définie pour l'option max text repl size, augmentez la taille. Utilisez sp_configure pour visualiser ou ajuster la valeur en cours de max text repl size. Remarque : pour Amazon RDS for SQL Server, pour ajuster les paramètres d'instance, vous devez utiliser des groupes de paramètres au lieu de sp_configure.

Il est recommandé d'installer le Service Pack ou la mise à jour cumulative le plus récent pour votre instance SQL Server afin de garantir le bon fonctionnement. Pour SQL Server 2012, 2014, 2016 et 2017, Microsoft a identifié et résolu plusieurs problèmes importants qui affectent directement la fonctionnalité de capture des données de modification de SQL Server. Cette situation a une incidence sur la capacité d'Oracle GoldenGate à capturer correctement les données. Les problèmes connus actuels qui nécessitent des patches Microsoft incluent KB3030352, KB3166120 et KB 4073684.

Configuration requise pour la base de données

Respectez les exigences et limites suivantes pour la prise en charge d'Oracle GoldenGate :

Seules les bases de données utilisateur sont prises en charge pour la capture et la distribution.
Assurez-vous que Auto Create Statistics et Auto Update Statistics sont activés pour la base de données.
La base de données doit être définie sur le niveau de compatibilité de la version d'instance SQL Server.
Oracle GoldenGate prend en charge les bases de données SQL Server configurées avec le cryptage transparent des données (TDE).
(Extract) La base de données source peut être définie sur n'importe quel modèle de récupération prenant en charge la fonctionnalité de capture des données de modification dans Microsoft SQL Server.
Si la base de données source a été créée en restaurant une sauvegarde à partir d'une autre instance, vous devez synchroniser le SID du propriétaire de la base de données avec le SID de la nouvelle instance. Vous pouvez également utiliser sp_changedbowner pour définir la base de données restaurée sur une connexion en cours.
La capture à partir de bases de données SQL Server (SQL Server 2017 CU15 et versions ultérieures) avec OLTP en mémoire (optimisation en mémoire) est prise en charge, avec les versions 21.15 et 23.5 d'Oracle GoldenGate. Toutefois, seule la capture à partir de tables sur disque est prise en charge, et non à partir de tables optimisées pour la mémoire.
(AlwaysOn) Le processus Extract prend en charge la capture à partir de la base de données principale, ou un mode de validation synchrone en lecture seule. Le mode de validation asynchrone n'est pas pris en charge pour la capture.
Considération des performances de réplication : à partir de SQL Server 2016, Microsoft a modifié le paramètre par défaut de l'option de base de données TARGET_RECOVERY_TIME de 0 à 60 secondes. Il a été démontré lors de tests internes que cela peut réduire le débit du processus Replicat. Si vous constatez une dégradation du débit de la réplication, envisagez d'ajuster le paramètre TARGET_RECOVERY_TIME à 0.

Limites :

Oracle GoldenGate ne prend pas en charge la capture ou la distribution des bases de données système.
Oracle GoldenGate ne prend pas en charge la capture à partir de bases de données contenues.
Les noms de base de données source ne peuvent pas dépasser 121 caractères. Cette limitation est due aux procédures stockées SQL Server qui sont utilisées pour activer la journalisation supplémentaire.
Si vous configurez la fonctionnalité de signal d'activité Oracle GoldenGate, le nom de la base de données SQL Server ne doit pas dépasser 107 caractères.
(AlwaysOn) La capture à partir de bases de données configurées en mode asynchrone-commit d'un groupe de disponibilité AlwaysOn n'est pas prise en charge.

Conditions requises pour la table

Les tables à inclure pour la capture et la distribution doivent inclure uniquement les types de données répertoriés dans Types de données SQL Server pris en charge.

Oracle GoldenGate prend en charge la capture des instructions LMD transactionnelles à partir des tables utilisateur, ainsi que la distribution aux tables utilisateur et aux vues accessibles en écriture.
Les opérations LDD ne sont pas prises en charge.
Oracle GoldenGate prend en charge le nombre maximal autorisé de noms de table et de longueurs de colonne pour les tables qui font l'objet d'un suivi par la capture des données de modification SQL Server.
La somme de toutes les longueurs de colonne d'une table à capturer ne doit pas dépasser la longueur autorisée par SQL Server pour l'activation de la capture de données de modification pour la table. Si la somme de toutes les longueurs de colonne dépasse ce qui est autorisé par la procédure SQL Server sys.sp.cdc_enable_table, ADD TRANDATA ne peut pas être activé pour cette table. La longueur d'enregistrement maximale autorisée diminue à mesure que davantage de colonnes sont présentes. Il existe donc une relation inverse entre la longueur d'enregistrement maximale et le nombre de colonnes dans la table.

Types de données SQL Server pris en charge

Les types de données suivants sont pris en charge pour la capture et la distribution, sauf indication contraire dans les limitations suivantes :

Types de données binaires
- (binary, varbinary, varbinary (max))
- (varbinary (max)avec FILESTREAM)
Types de données de caractère
- (char, nchar, nvarchar, nvarchar (max), varchar, varchar (max))
Types de données Date et Heure
- (date, datetime2, datetime, datetimeoffset, smalldatetime, time)
Types de données numériques
- (bigint, bit, decimal, float, int, money, numeric, real, smallint, smallmoney, tinyint)
Domaines d'activité
- (image, ntext, text)
Autres types de données
- (timestamp, uniqueidentifier, hierarchyid, geography, geometry, sql_variant (Delivery only), XML)
Oracle GoldenGate for SQL Server peut répliquer les données de colonne contenant les paramètres SPARSE.

Limites :

Oracle GoldenGate ne prend pas en charge le filtrage, la mise en correspondance de colonnes ou la manipulation des objets LOB de plus de 4 ko. La fonctionnalité complète d'Oracle GoldenGate peut être utilisée pour les objets d'une taille maximale de 4 ko.
Oracle GoldenGate traite les données XML comme un objet LOB (Large Object), tout comme SQL Server lorsque le code XML ne tient pas dans une ligne. Les améliorations XML étendues de SQL Server (telles que la validation laxiste, DATETIME, fonctionnalité d'union) ne sont pas prises en charge.
Une colonne TIMESTAMP affectée par le système ou une colonne calculée non matérialisée ne peut pas faire partie d'une clé. Une table contenant une colonne TIMESTAMP doit comporter une clé, qui peut être une clé primaire ou une contrainte unique, ou une clé de substitution indiquée avec une clause KEYCOLS dans les instructions TABLE ou MAP. Pour plus d'informations, voir Affecter des identificateurs de ligne.
Oracle GoldenGate prend en charge les types de données à plusieurs octets et les données à plusieurs octets stockées dans des colonnes de caractères. Les données multioctets ne sont prises en charge que dans une configuration SQL Server similaire. La transformation, le filtrage et d'autres types de manipulation ne sont pas pris en charge pour les données à plusieurs octets.
Si la capture des données pour les colonnes TEXT, NTEXT, IMAGE, VARCHAR (MAX), NVARCHAR(MAX) et VARBINARY (MAX) dépasse la taille par défaut de SQL Server définie pour l'option max text repl size, augmentez la taille. Utilisez sp_configure pour visualiser la valeur en cours de max text repl size et ajustez l'option selon vos besoins. Remarque : Amazon RDS for SQL Server ne permet pas à max text repl size d'être supérieur à 64 Mo. { : .infoboxnote}
Les colonnes des types de données IMAGE, NTEXT et TEXT sont journalisées en tant que valeur NULL pour les opérations de suppression et de mise à jour d'image avant. Les colonnes de VARBINARY(MAX), VARCHAR(MAX) et NVARCHAR(MAX) sont journalisées en tant que valeur NULL pour les opérations de mise à jour d'image avant, sauf si la colonne a été mise à jour.

Pour plus d'informations, consultez le contenu Types de données de LOB dans le document Microsoft suivant :

https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/cdc-capture-instance-ct-transact-sql?view=sql-server-ver15
Oracle GoldenGate prend en charge les données UDT et UDA d'une taille maximale de 2 Go. Tous les UDT sauf SQL_Variant sont pris en charge.
L'exécution Common Language Runtime (CLR), y compris les types de données CLR intégrés SQL Server (tels que la géométrie, la géographie et l'ID de hiérarchie), est prise en charge. Les types de données CLR ne sont pris en charge que dans une configuration SQL Server similaire. La transformation, le filtrage et d'autres types de manipulation ne sont pas pris en charge pour les données CLR.
Les colonnes VARBINARY (MAX) avec l'attribut FILESTREAM sont prises en charge jusqu'à une taille de 4 Go. Le processus Extract utilise les fonctions de fichier Win32 standard pour lire le fichier FILESTREAM.
La plage et la précision des nombres à virgule flottante dépendent de la machine hôte. En général, la précision est de 16 chiffres significatifs, mais vous devez consulter la documentation de la base de données pour déterminer les approximations attendues. Oracle GoldenGate arrondit ou tronque les valeurs dépassant la précision prise en charge.
Oracle GoldenGate prend en charge les données d'horodatage de 0001/01/03 :00:00:00 à 9999/12/31 :23:59:59. Si un horodatage est converti de GMT en heure locale, ces limites s'appliquent également à l'horodatage résultant. Selon le fuseau horaire, la conversion peut ajouter ou soustraire des heures, ce qui peut entraîner le dépassement de la limite inférieure ou supérieure prise en charge.

Limites relatives aux colonnes calculées :

Les colonnes calculées, persistantes ou non, ne sont pas prises en charge par la fonction de capture des données de modification de Microsoft. Par conséquent, aucune donnée n'est écrite dans la trace pour les colonnes qui contiennent des colonnes calculées. Pour répliquer des données pour des colonnes calculées non persistantes, utilisez l'option FETCHCOLS ou FETCHMODCOLS du paramètre TABLE pour extraire les données de colonne de la table.

Gardez à l'esprit qu'il peut y avoir des divergences causées par des différences dans les valeurs de données entre l'heure à laquelle la colonne a été modifiée dans la base de données et l'heure à laquelle le processus Extract extrait les données de l'enregistrement de transaction en cours de traitement.
Lorsqu'une colonne avec le type de données non pris en charge sql_variant est utilisée dans les options FETCHCOLS ou FETCHMODCOLS, l'extraction est abandonnée avec l'erreur suivante :
```
ERROR   OGG-25230 Unsupported datatype '*column-name* (sql_variant)' used with 'FETCHCOLS/FETCHCOLSEXCEPT' in table '*table-name>*.
```
Le processus Replicat n'applique aucune instruction LMD à une colonne calculée, même si les données de cette colonne figurent dans la trace (trail), car la base de données n'autorise aucune instruction LMD sur ce type de colonne. Les données d'une colonne calculée persistante source ou d'une colonne non persistante extraite peuvent être appliquées à une colonne cible qui n'est pas une colonne calculée.
Lors d'un chargement initial, toutes les données sont sélectionnées directement dans les tables source, et non dans le journal des transactions. Par conséquent, lors d'un chargement initial, les valeurs de données de toutes les colonnes, y compris les colonnes calculées non persistantes, sont écrites dans la trace ou envoyées à la cible, selon la méthode utilisée. Toutefois, comme lors de l'application des données de modification, le processus Replicat n'applique pas les données de chargement initial aux colonnes calculées, car la base de données n'autorise pas les opérations LMD sur ce type de colonne.
Oracle GoldenGate ne permet pas l'utilisation d'une colonne calculée non persistante dans une clause KEYCOLS dans une instruction TABLE ou MAP.
Si une clé unique inclut une colonne calculée non persistante et qu'Oracle GoldenGate doit l'utiliser, la colonne calculée non persistante est ignorée. Cela peut affecter l'intégrité des données si les colonnes restantes n'imposent pas l'unicité.
Si un index unique est défini sur des colonnes calculées non persistantes, il n'est pas utilisé.
Si une clé ou un index unique contient une colonne calculée non persistante et qu'il s'agit du seul identificateur unique d'une table, Oracle GoldenGate doit utiliser toutes les colonnes comme identificateur pour rechercher les lignes cible. Etant donné qu'une colonne calculée non persistante ne peut pas être utilisée dans cet identificateur, le processus Replicat peut appliquer des opérations contenant cet identificateur aux lignes cible incorrectes.

Types de données et fonctionnalités SQL Server non pris en charge

Le type de données SQL_Variant n'est pas pris en charge pour la capture.
Les tables qui contiennent des types de données non pris en charge peuvent entraîner l'abandon du processus Extract. Pour contourner le problème, vous devez enlever TRANDATA de ces tables et les enlever de l'instruction TABLE de l'extraction, ou utiliser le paramètre TABLEEXCLUDE de l'extraction pour la table.

Objets et opérations pris en charge pour SQL Server

Les objets et opérations suivants sont pris en charge :

Le processus Replicat parallèle est pris en charge avec Oracle GoldenGate for SQL Server.
Oracle GoldenGate prend en charge la capture des instructions LMD transactionnelles à partir des tables utilisateur et leur distribution aux tables utilisateur et aux vues accessibles en écriture.
Les colonnes TEXT, NTEXT, IMAGE, VARBINARY, VARBINARY (MAX) VARCHAR (MAX) et NVARCHAR (MAX) sont prises en charge dans leur taille complète pour les opérations journalisées par SQL Server Chang Data Capture. Par exemple, les colonnes des types de données IMAGE, NTEXT et TEXT sont journalisées en tant que valeur NULL pour les opérations de suppression. Pour plus d'informations, consultez le contenu Types de données de LOB dans le document Microsoft suivant :

https://docs.microsoft.com/en-us/sql/relational-databases/system-tables/cdc-capture-instance-ct-transact-sql?view=sql-server-ver15
Oracle GoldenGate prend en charge les tailles de ligne maximales autorisées pour les tables activées pour la capture des données de modification SQL Server.
Oracle GoldenGate prend en charge la capture à partir de tables activées avec la compression PAGE et ROW. Pour les tables partitionnées qui utilisent la compression, toutes les partitions doivent être activées avec le même type de compression.
Oracle GoldenGate prend en charge la capture pour les tables partitionnées si la table présente la même disposition physique dans toutes les partitions.
La somme de toutes les longueurs de colonne d'une table à capturer ne doit pas dépasser la longueur autorisée par SQL Server pour l'activation de la capture de données de modification pour la table. Si la somme de toutes les longueurs de colonne dépasse ce qui est autorisé par la procédure SQL Server sys.sp.cdc_enable_table, ADD TRANDATA ne peut pas être ajouté pour cette table. La longueur d'enregistrement maximale autorisée diminue à mesure que davantage de colonnes sont présentes. Il existe donc une relation inverse entre la longueur d'enregistrement maximale et le nombre de colonnes dans la table.

Objets et opérations non pris en charge pour SQL Server

Les objets et opérations suivants ne sont pas pris en charge :

Prenons une relation parent-enfant entre deux tables, dans laquelle une clé primaire de la table parent est référencée par une clé étrangère de la table enfant avec la clause ON UPDATE SET DEFAULT. La mise à jour de clé primaire différée sur la table parent entraîne la suppression et l'insertion de paires. Il n'est pas possible d'identifier de manière fiable les opérations DELETE et INSERT correspondantes sur la table parent. Lorsqu'une telle mise à jour différée est effectuée sur la table parent, l'extraction Oracle GoldenGate peut ne pas capturer tous les événements de manière fiable.
Pour les bases de données source, opérations qui ne sont pas prises en charge par SQL Server Change Data Capture, telles que les instructions TRUNCATE. Reportez-vous à la documentation de Microsoft SQL Server pour obtenir la liste complète des opérations qui sont limitées en activant SQL Server Change Data Capture.
Oracle GoldenGate for SQL Server ne prend pas en charge la capture ou la distribution des modifications LDD pour SQL Server. Des étapes supplémentaires sont requises pour que les processus Oracle GoldenGate sur la source et la cible gèrent les modifications LDD au niveau de la table, y compris les opérations de reconstruction d'index de table. Reportez-vous à Conditions requises pour les modifications LDD de niveau table.
Les vues ne sont pas prises en charge.
Opérations effectuées par l'utilitaire TextCopy et les instructions WRITETEXT et UPDATETEXT. Ces fonctionnalités effectuent des opérations qui ne sont pas journalisées par la base de données ou qui ne sont que partiellement journalisées. Elles ne peuvent donc pas être prises en charge par le processus Extract.
Tables partitionnées qui ont plusieurs dispositions physiques entre les partitions.
La partition bascule sur une table source. SQL Server Change Data Capture traite les commutateurs de partition comme des opérations LDD et les données déplacées d'une partition à une autre ne sont pas consignées dans les tables CDC. Vous devez donc suivre les procédures décrites dans la section Requirements for Table Level DDL Changes pour implémenter manuellement un commutateur de partition lorsque la table est activée pour la journalisation supplémentaire.
En raison d'une limitation avec la capture de données de modification de SQL Server, les classements au niveau des colonnes qui sont différents du classement de la base de données peuvent entraîner l'écriture de données incorrectes dans les tables CDC pour les données alphanumériques et le processus Extract les capture au fur et à mesure de leur écriture dans les tables CDC. Il est recommandé d'utiliser le type de données NVARCHAR, NCHAR ou NTEXT pour les colonnes contenant des données non ASCII ou d'utiliser le même classement pour les colonnes de table que la base de données. Pour plus d'informations, reportez-vous à A propos de la capture des données de modification (SQL Server).
En raison d'une limitation de la capture des données de modification de SQL Server, NOOPUPDATES n'est pas capturé par l'agent de capture des données de modification de SQL Server. Il n'existe donc aucun enregistrement à capturer pour les opérations de mise à jour sans opération.
Les tables temporelles ne sont pas prises en charge pour l'activation de la capture des données de modification. Par conséquent, elles ne peuvent pas être configurées pour l'extraction pour les implémentations source.

Exigences relatives aux modifications LDD de niveau table

Oracle GoldenGate for SQL Server ne prend pas en charge la capture ou la distribution des modifications LDD. Cependant, à partir d'Oracle GoldenGate 21c, les modifications apportées aux tables activées avec TRANDATA n'entraîneront pas l'abandon du processus Extract. Le processus d'extraction continuera à traiter les données de modification pour la table telles qu'elles existaient lorsque TRANDATA a été activé.

Les opérations considérées comme des modifications LDD au niveau de la table incluent, sans toutefois s'y limiter : ALTER TABLE, TRUNCATE TABLE, les reconstructions d'index et les commutateurs de partition.

Pour éviter les incohérences de données dues à des modifications LDD au niveau de la table, procédez comme suit.

Source : Mettre en pause ou arrêter les données de l'application dans la ou les tables à modifier.
Source : assurez-vous qu'il n'y a pas de transactions en cours sur la table à modifier.
Source : Assurez-vous que le travail SQL Server CDC Capture traite toutes les transactions restantes pour la table à modifier.
Source : Assurez-vous que le processus Extract traite toutes les transactions de la table à modifier avant d'apporter des modifications LDD.
Cible : assurez-vous que le processus Replicat traite toutes les transactions de la table à modifier avant d'apporter des modifications LDD.
Eventuellement, l'implémentation d'une table de marqueurs d'événements peut être utilisée pour déterminer quand toutes les transactions restantes ont été traitées pour la table à modifier et gérer la coordination du moment où arrêter correctement l'extraction et la réplication.
Source : Arrêter le processus d'extraction.
Cible : arrêtez le processus Replicat.
Source : désactivez la journalisation supplémentaire pour la table à modifier en exécutant DELETE TRANDATA.
Source : Apportez des modifications LDD à la table source.
Cible : Apportez des modifications LDD à la table cible.
Source : réactivez la journalisation supplémentaire en exécutant ADD TRANDATA sur les tables une fois les modifications effectuées.
Source : Démarrez l'extraction.
Cible : lancez le processus Replicat.
Source : Reprendre les données de l'application dans la ou les tables modifiées.

Schémas système pour SQL Server

Les schémas système suivants ne sont pas pris en charge pour la réplication :

sys
cdc
INFORMATION_SCHEMA

Le schéma guest n'est pas pris en charge à l'aide de mappings avec caractères génériques, mais il est pris en charge lorsqu'il est explicitement répertorié, tel que TABLE guest.employees.