Sybase : types de données, objets et opérations pris en charge

Cette section contient des informations sur les types de données, les objets et les opérations pris en charge pour Oracle GoldenGate for Sybase.

Types de données Sybase pris en charge

Entiers

• BIGINT

• BIT

• DECIMAL

• INT (signé et non signé)

• TINYINT (signé et non signé)

• NUMERIC

• SMALLINT (signé et non signé)

Limites de prise en charge

• NUMERIC et DECIMAL (point fixe) sont pris en charge sans perte d'intégrité lors du déplacement de données vers une colonne cible du même type de données sans nécessiter de calculs ou de transformation. Lorsque des calculs ou des transformations doivent être effectués, Oracle GoldenGate prend en charge la valeur maximale d'un entier long signé (32 bits).

• BIT est pris en charge pour le mapping automatique entre les bases de données Sybase. Pour déplacer des données BIT entre Sybase et un autre type de base de données, Oracle GoldenGate traite les données BIT comme des données binaires. Dans ce cas, les éléments suivants sont requis :

  • La colonne BIT doit être mise en correspondance avec la colonne source ou cible correspondante avec une clause COLMAP dans une instruction TABLE ou MAP.

• Pour les versions Sybase 15.7 et supérieures, les types de données suivants ne peuvent pas être répliqués :

  • BIGINT (en tant que colonne de clé)

  • BIGDATETIME

  • BIGTIME

• Lorsque vous répliquez TINYINT et que le processus Extract ne se trouve pas dans la même version du processus Replicat, vous devez créer un fichier sourcedef et/ou targetdef, même si vous effectuez la réplication entre des versions Sybase identiques.

  Voir aussi Types de données Sybase non pris en charge.

Nombres à virgule flottante

• DOUBLE

• FLOAT

• REAL

Limites de prise en charge

La prise en charge de la plage et de la précision pour les nombres à virgule flottante dépend 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.

Données alphanumériques

• CHAR

• NCHAR

• NVARCHAR

• VARCHAR

• UNICHAR

• UNIVARCHAR Limites de Support

• Ces types de données sont pris en charge jusqu'à la longueur maximale prise en charge par la base de données, c'est-à-dire la taille de page maximale.

• L'extraction des résultats de réplication NVARCHAR à l'aide des fonctions Sybase char_length ou datalength lorsqu'une base de données Sybase est la cible et que la source est une base de données hétérogène et que vous effectuez une réplication de la source vers la cible peut entraîner un problème d'intégrité des données. Cela se produit lorsque vous utilisez une version Sybase antérieure à Adaptive Server Enterprise 15.5 pour la plate-forme Windows x64 EBF 21262 : 15.5 ESD #5.3.

Dates et horaires

• BIGDATETIME

• BIGTIME

• DATE

• DATETIME

• SMALLDATETIME

• TIME

Limites de 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 un dépassement de la limite inférieure ou supérieure prise en charge.

• Oracle GoldenGate ne prend pas en charge les dates négatives.

Objets LOB

• BINARY

• IMAGE

• TEXT

• UNITEXT

• VARBINARY

Limites de prise en charge

• TEXT, UNITEXT et IMAGE sont pris en charge jusqu'à 2 Go de longueur.

• Les objets LOB répliqués à partir d'autres bases de données (comme Oracle BLOB et CLOB) peuvent être mis en correspondance avec les colonnes Sybase CHAR, VARCHAR, BINARY et VARBINARY. Pour empêcher l'abandon du processus Replicat si l'objet LOB répliqué est plus grand que la taille de la colonne cible, utilisez le paramètre DBOPTIONS avec l'option ALLOWLOBDATATRUNCATE dans le fichier de paramètres du processus Replicat. Pour plus d'informations, reportez-vous à Référence pour Oracle GoldenGate pour Windows et UNIX.

• Pour déplacer des données vers une cible Sybase à partir d'une base de données source qui autorise les colonnes LOB vides, utilisez le paramètre DBOPTIONS avec l'option EMPTYLOBSTRING dans le fichier de paramètres de réplication. Ce paramètre accepte une valeur de chaîne et empêche le processus Replicat de définir la colonne cible sur NULL, ce qui n'est pas autorisé par Sybase. Pour plus d'informations, reportez-vous à Référence pour Oracle GoldenGate pour Windows et UNIX.

• Lorsqu'une table source contient plusieurs lignes identiques, cela peut entraîner des incohérences LOB dans la table cible. Cela se produit lorsque la table source n'a pas de clé primaire ou d'autre identificateur de ligne unique. Les lignes sont insérées par le processus Replicat sur la cible, mais si les données LOB sont mises à jour lors d'une opération source ultérieure, elles ne seront répliquées que sur la première ligne insérée sur la cible.

• N'utilisez pas de contraintes NOT NULL sur la colonne LOB de la ligne. Pour utiliser des contraintes NOT NULL, utilisez-les sur la colonne LOB hors ligne.

• Si vous devez extraire les données LOB de la ligne directement de la table, vous devez utiliser FETCHCOLS/FETCHMODCOLS.

• Oracle GoldenGate pour Sybase 15.7 et versions ultérieures ne prend pas en charge la réplication de colonne LOB dans la ligne (cependant, il peut toujours transférer les données dans la colonne LOB dans la ligne dans la base de données Replicat). Cela signifie que les tables incluses dans la réplication ne peuvent pas comporter de colonnes LOB dans la ligne. Oracle GoldenGate abandonne si une table de réplication inclut une colonne LOB dans la ligne. Si vous avez besoin d'une prise en charge intégrée des objets LOB, contactez le support technique Oracle pour plus d'informations.

Types de monnaie

• MONEY

• SMALLMONEY

Limites de fournituret

Les types de données monétaires sont pris en charge sans perte d'intégrité lors du déplacement de données vers une colonne cible du même type de données sans nécessiter de calculs ou de transformation. Lorsque des calculs ou des transformations doivent être effectués, Oracle GoldenGate prend en charge la valeur maximale d'un entier long signé (32 bits).

Type d'entité

Le type de données IDENTITY est pris en charge pour la réplication dans un seul sens, mais pas pour une configuration bidirectionnelle.

types de données texte, image et unitext

Avec la version Sybase 15.7, les types de données texte, image et unitext de LOB sont désormais pris en charge en mode BATCHSQL. La longueur des données de l'objet LOB est limitée à 4K. Si les enregistrements qui contiennent des colonnes LOB et que la taille dépasse 4K, ces enregistrements sont exclus des batches et sont exécutés un par un. Les colonnes LOB sont désormais liées, tandis que dans la version Sybase précédente (15.5 ou 15.0), les LOB n'étaient pas liés. Vous pouvez utiliser un comportement plus ancien en utilisant le paramètre DBPOTIONS LEGACYLOBREPLICATION. Cette prise en charge s'applique uniquement à la réplication exécutée sur Sybase version 15.7 et ultérieure.

Types de données définis par l'utilisateur

Les types de données définis par l'utilisateur sont entièrement pris en charge.

Types de données Sybase non pris en charge

Cette section répertorie les types de données Sybase qu'Oracle GoldenGate ne prend pas en charge.

• Les données TIMESTAMP ne sont pas prises en charge. Les données des colonnes d'horodatage sont capturées, mais elles ne peuvent pas être appliquées à la colonne d'horodatage Sybase en raison d'une limitation de la base de données. La base de données alimente automatiquement cette colonne une fois que la ligne correspondante est insérée ou mise à jour. Pour exclure les colonnes d'horodatage de la capture par Oracle GoldenGate, utilisez l'option COLSEXCEPT du paramètre TABLE. Comme le système génère les horodatages, les valeurs source et cible sont différentes.

• Le type de données Java rowobject n'est pas pris en charge.

Opérations et objets pris en charge pour Sybase

Cette section répertorie les opérations de données et les objets de base de données pris en charge par Oracle GoldenGate.

• Extraction et réplication des opérations d'insertion, de mise à jour et de suppression sur les tables Sybase qui contiennent des lignes d'une longueur maximale de 512 ko.

• Nombre maximal de colonnes et taille maximale de colonne par table prises en charge par la base de données.

• Insertions différées, insertions indirectes différées, mises à jour différées et suppressions différées. Il est possible que l'utilisation de mises à jour différées entraîne des violations de contrainte de clé primaire pour l'instruction SQL affectée sur la cible. Si ces erreurs se produisent, utilisez le paramètre de réplication HANDLECOLLISIONS.

• TRUNCATE TABLE si les noms des tables affectées sont uniques dans tous les schémas. Si les noms de table ne sont pas uniques dans tous les schémas, utilisez le paramètre IGNORETRUNCATES de ces tables pour empêcher l'abandon du processus Replicat.

• GETTRUNCATES et IGNORETRUNCATES par extraction et réplication.

• Données chiffrées avec un mot de passe chiffré par le système.

• Extraction de tableau lors des chargements initiaux, contrôlée par le paramètre FETCHBATCHSIZE.

• Fonctionnalité de réplication BATCHSQL sur ASE 15.7 SP110 et versions ultérieures sur les plates-formes suivantes :

  • AIX

  • Linux x64

  • Sun Solaris SPARC

  • Sun Solaris x64

  • Windows x64

  Dans certains scénarios, les types de données CS_NUMERIC et CS_DECIMAL ne sont pas pris en charge par BatchSQL en raison d'un bogue dans la bibliothèque CT spécifique de Sybase. La réplication LOB est prise en charge en mode BatchSql pour la version 157 SP110 de la base de données Sybase. Cela améliore les performances de réplication des LOB. Il est limité à 16384 octets de données LOB, ce qui signifie que si les données LOB dépassent 16384 octets, les données ne seront pas traitées via le mode BATCHSQL à la place du mode passé à Normal.

• Les limites de la prise en charge des colonnes calculées sont les suivantes :

  • Prend entièrement en charge les colonnes calculées persistantes. Les valeurs de modification sont présentes dans le journal des transactions et peuvent être capturées dans la trace.

  • Vous ne pouvez pas utiliser de contraintes NOT NULL sur les colonnes LOB de ligne. Si vous devez utiliser des contraintes NOT NULL, ne le faites qu'avec des colonnes LOB hors ligne.

  • Tables avec des colonnes calculées non persistantes, mais ne capturent pas les données de modification pour ces colonnes car la base de données ne les écrit pas dans le journal des transactions. 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 différences dues à des différences dans les valeurs de données entre le moment où la colonne a été modifiée dans la base de données et le moment où le processus Extract extrait les données de l'enregistrement de transaction en cours de traitement.

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

  • Aucune colonne calculée persistante définie en tant que colonne de clé, colonne d'index ou faisant partie d'une clause KEYCOLS dans une instruction TABLE ou MAP n'est utilisée. Si une clé ou un index unique inclut une colonne calculée et qu'Oracle GoldenGate doit utiliser cette clé, la colonne calculée est ignorée. En outre, si une clé ou un index unique contient une colonne calculée et qu'il s'agit du seul identificateur unique de la table, toutes les colonnes sont utilisées, à l'exception de la colonne calculée, comme identificateur pour rechercher la ligne cible. Par conséquent, la présence d'une colonne calculée dans une clé ou un index affecte l'intégrité des données si les autres colonnes n'imposent pas l'unicité. Sybase ne prend pas en charge les colonnes calculées non persistantes dans le cadre d'une clé. Oracle GoldenGate non plus.

  • Pour prendre en charge TRUNCATE TABLE, tous les noms de table doivent être uniques dans tous les schémas d'une base de données. Cette règle s'applique à l'extraction et à la réplication.

• Les limites de la prise en charge de la table de signal d'activité automatique sont les suivantes :

  • La fréquence de signal d'activité est acceptée en minutes et doit être un entier compris entre 1 et 133 (tous deux inclus).

  • La troncation des données se produit avec un abandon de réplication lorsqu'il dépasse 1500 caractères pour les tables incoming_routing_path et outgoing_routing_path des tables GG_HEARTBEAT_SEED, GG_HEARTBEAT et GG_HEARTBEAT_HISTORY. La taille incoming_routing_path et outgoing_routing_path de ces tables est définie sur 1500 caractères en ASCII et est de 500 octets au maximum en caractères multioctets. Assurez-vous que les chaînes de chemin de routage entrant et sortant sont dans la limite indiquée.

  • Le planificateur de travaux Sybase doit être configuré sur le serveur ASE avant d'exécuter la fonctionnalité de signal d'activité Oracle GoldenGate.

  • Pour que la fonctionnalité de table de signal d'activité fonctionne correctement, l'utilisateur de connexion doit disposer des rôles replication_role, js_admin_role et js_user_role.

Opérations et objets non pris en charge pour Sybase

Cette section répertorie les opérations de données et les objets de base de données qu'Oracle GoldenGate ne prend pas en charge.

• La réplication des vues matérialisées ou des jeux de résultats précalculés n'est pas prise en charge. Par conséquent, vous ne pouvez pas ajouter de trandata pour les vues matérialisées. Pour plus d'informations, reportez-vous à la documentation Sybase ASE.

• Données cryptées avec un mot de passe défini par l'utilisateur.

• Extraction ou réplication d'opérations LDD (langage de définition de données).

• Configuration multi-extraction. Une seule extraction peut réserver un contexte pour lire les journaux de transactions Sybase.

• SHOWSYNTAX étant pris en charge en mode DYNSQL, NODYNSQL est en phase d'abandon.

• Les noms de table qui contiennent des données avec un trait de soulignement suivi de certains caractères, puis un espace (par exemple, 'zzz_j') ne sont pas pris en charge. Oracle GoldenGate ne peut pas traiter les enregistrements contenant ce type de chaîne de caractères avec GGSCI, DEFGEN, EXTRACT ou REPLICAT. En outre, ce type de données ne peut pas être utilisé avec le caractère générique Oracle GoldenGate (*). Si ce type de données figure dans le nom de la table, vous devez supprimer ce type de nom de table de la base de données, puis redémarrer l'application pour traiter et respecter le caractère générique Oracle GoldenGate.