Abonnés IBM Db2

S'applique à :SQL Server

SQL Server prend en charge les abonnements de type push pour IBM Db2/AS 400, DB2/MVS et DB2/Universal Database via les fournisseurs OLE DB fournis avec Microsoft Host Integration Server.

Configuration d'un souscripteur IBM Db2

Pour configurer un Abonné IBM Db2, procédez comme suit :

  1. Installez la dernière version du fournisseur Microsoft OLE DB pour DB2 sur le serveur de distribution :

    • Si vous utilisez SQL Server Êdition Entreprise, sur la page Web SQL Server Téléchargements, dans la section Téléchargements associés, sélectionnez le lien vers la dernière version du Microsoft SQL Server Feature Pack. Sur la page web du Microsoft SQL Server Feature Pack, recherchez OLE DB Provider for DB2.

    • Si vous utilisez SQL Server Standard Edition, installez la dernière version du serveur Microsoft Host Integration Services (HIS), qui inclut le fournisseur.

    En plus d’installer le fournisseur, installez l’outil d’accès aux données, qui est utilisé à l’étape suivante. L’outil est installé par défaut avec le téléchargement pour SQL Server Êdition Entreprise. Pour plus d'informations sur l’installation et l'utilisation de l'outil d'accès aux données, consultez la documentation du fournisseur ou de HIS.

  2. Créez une chaîne de connexion pour l'Abonné. Vous pouvez créer la chaîne de connexion dans n’importe quel éditeur de texte, mais utilisez l’outil d’accès aux données. Pour créer la chaîne dans l'outil d'accès aux données :

    1. Sélectionnez Démarrer, Programmes, Fournisseur OLE DB pour DB2, puis Outil d’accès aux données.

    2. Dans l' Outil d'accès aux données, procédez comme suit pour fournir des informations sur le serveur DB2. Lorsque vous terminez l’outil, il crée un lien de données universel (UDL) avec une chaîne de connexion associée. L’UDL n’est pas utilisé par la réplication, mais la chaîne de connexion l’est.

    3. Accédez à la chaîne de connexion : cliquez avec le bouton droit sur l'UDL dans l'outil d'accès aux données et sélectionnez Afficher la chaîne de connexion.

      La chaîne de connexion est similaire à la suivante (les sauts de ligne sont pour la lisibilité) :

    Provider=DB2OLEDB;Initial Catalog=MY_SUBSCRIBER_DB;Network Transport Library=TCP;Host CCSID=1252;  
PC Code Page=1252;Network Address=MY_SUBSCRIBER;Network Port=50000;Package Collection=MY_PKGCOL;  
Default Schema=MY_SCHEMA;Process Binary as Character=False;Derive Parameters=False;Units of Work=RUW;DBMS Platform=DB2/NT;  
Persist Security Info=False;Connection Pooling=True;

    La plupart des options dans la chaîne sont spécifiques au serveur DB2 que vous configurez, mais vous devriez toujours définir les Process Binary as Character options et Derive Parameters sur False. Vous devez fournir une valeur pour l’option Initial Catalog d’identification de la base de données d’abonnement. Entrez la chaîne de connexion dans l’Assistant Nouvel Abonnement lors de la création de l’abonnement.

  3. Créez une publication d’instantané ou transactionnelle, activez-la pour les Abonnés autres que SQL Server, puis créez un abonnement de type push pour l’Abonné. Pour plus d’informations, voir Créer un abonnement pour un Abonné non-SQL Server.

  4. Éventuellement, spécifiez un script de création personnalisé pour un ou plusieurs articles. Lors de la publication d’une table, un script CREATE TABLE est créé pour cette table. Pour les abonnés non-SQL Server, vous créez le script dans le dialecte Transact-SQL, et le Agent de distribution le traduit en un dialecte SQL plus générique avant de l’appliquer à l’abonné. Pour spécifier un script de création personnalisé, soit modifier le script de Transact-SQL existant, soit créer un script complet utilisant le dialecte SQL DB2. Si vous créez un script DB2, utilisez la directive bypass_translation afin que le Agent de distribution applique le script à l’abonné sans traduction.

    Vous pouvez modifier des scripts pour plusieurs raisons, mais la raison la plus courante est de modifier les correspondances de types de données. Pour plus d’informations, consultez la section « Considérations sur la cartographie des types de données » dans cet article. Si vous modifiez le script Transact-SQL, limitez les modifications à celles du mappage des types de données et n’ajoutez aucun commentaire. Si vous avez besoin de changements plus substantiels, créez un script DB2.

    Pour modifier un script d'article et le fournir en tant que script de création personnalisé

    1. Après la génération de l’instantané pour la publication, allez dans le dossier des instantanés de la publication.

    2. Recherchez le fichier .sch portant le même nom que l’article, par exemple MyArticle.sch.

    3. Ouvrez ce fichier en utilisant Notepad ou un autre éditeur de texte.

    4. Modifiez le fichier et enregistrez-le dans un autre répertoire.

    5. Exécutez sp_changearticle, en indiquant le chemin d'accès et le nom de fichier de la propriété creation_script . Pour plus d’informations, consultez sp_changearticle (Transact-SQL).

    Pour créer un script d'article et le fournir en tant que script de création personnalisé

    1. Créez un script d’article en utilisant le dialecte SQL Db2. Vérifiez que la première ligne du fichier contient bypass_translationet rien d'autre.

    2. Exécutez sp_changearticle, en indiquant le chemin et le nom de fichier de la propriété creation_script.

Considérations relatives aux Abonnés IBM Db2

Outre les considérations abordées dans l’article Abonnés non-SQL Server, tenez compte des points suivants lors de la réplication vers des abonnés Db2 :

  • Les données et les index de chaque table répliquée sont attribués à un espace de table Db2. La taille de page d’un espace de table Db2 contrôle le nombre maximal de colonnes et la taille maximale de lignes des tables appartenant à cet espace. Vérifiez que l'espace disque logique associé aux tables répliquées est suffisant par rapport au nombre de colonnes répliquées et à la taille de ligne maximale des tables.

  • Ne publiez pas de tables aux abonnés Db2 en utilisant la réplication transactionnelle si une ou plusieurs colonnes clés primaires du tableau sont de type de données DECIMAL(32-38, 0-38) ou NUMERIC(32-38, 0-38). La réplication transactionnelle identifie les lignes en utilisant la clé primaire. Cette méthode peut entraîner des défaillances car ces types de données sont mappés à VARCHAR(41) au niveau de l’abonné. Vous pouvez publier des tables avec des clés primaires utilisant ces types de données en utilisant la réplication instantanée.

  • Si vous souhaitez créer des tables chez l’abonné, plutôt que de les faire créer par la réplication, utilisez l’option de support uniquement de la réplication. Pour plus d’informations, consultez Initialiser un abonnement transactionnel sans instantané.

  • SQL Server permet des noms de tables et de colonnes plus longs que Db2 :

    • Si la base de données de publication inclut des tables avec des noms plus longs que ceux pris en charge par la version Db2 chez l’abonné, spécifiez un nom alternatif pour la propriété destination_table article. Pour plus d’informations sur la définition des propriétés lors de la création d’une publication, consultez Créer une publication et Définir un article.

    • Vous ne pouvez pas spécifier d’autres noms de colonnes. Assurez-vous que les tables publiées n’incluent pas de noms de colonnes plus longs que ceux pris en charge par la version Db2 chez l’abonné.

Mappage des types de données de SQL Server vers IBM Db2

Le tableau suivant répertorie les mappages des types de données utilisés dans le cadre de la réplication des données sur un abonné IBM Db2.

Type de données SQL Server Type de données IBM Db2
bigint DECIMAL (19,0)
binary(1-254) CARACTÈRE(1-254) POUR DONNÉES BINAIRES
binary(255-8000) VARCHAR(255-8000) POUR DONNÉES BINAIRES
bit SMALLINT
char(1-254) CHAR(1-254)
char(255-8000) VARCHAR(255-8000)
date DATE
datetime Horodatage
datetime2(0-7) VARCHAR (27)
datetimeoffset(0-7) VARCHAR (34)
décimal(1-31, 0-31) DECIMAL(1-31, 0-31)
décimal(32-38, 0-38) VARCHAR (41)
float(53) DOUBLE
float Flottant
Geography IMAGE
geometry IMAGE
hierarchyid IMAGE
image VARCHAR(0) POUR LES BITS DE DONNÉES*
into INT
money DECIMAL(19,4)
nchar(1-4000) VARCHAR(1-4000)
ntext VARCHAR(0)*
numérique(1-31, 0-31) DECIMAL(1-31,0-31)
numeric(32-38, 0-38) VARCHAR (41)
nvarchar(1-4000) VARCHAR(1-4000)
nvarchar(max) VARCHAR(0)*
real RÉEL
smalldatetime Horodatage
smallint SMALLINT
smallmoney DECIMAL(10,4)
sql_variant N/A
sysname VARCHAR (128)
texte VARCHAR(0)*
time(0-7) VARCHAR(16)
timestamp CHAR(8) POUR DONNÉES BINAIRES
tinyint SMALLINT
uniqueidentifier CHAR(38)
varbinary(1-8000) VARCHAR(1-8000) POUR LES DONNÉES BIT
varchar(1-8000) VARCHAR(1-8000)
varbinary(max) VARCHAR(0) POUR LES BITS DE DONNÉES*
varchar(max) VARCHAR(0)*
xml VARCHAR(0)*
  • Pour en savoir plus sur les mappages au type VARCHAR(0), consultez la section suivante.

Considérations sur la cartographie des types de données

Tenez compte des problèmes suivants de mappage des types de données lors de la réplication vers des abonnés DB2 :

  • Lors du mappage des types SQL Server char, varchar, binary et varbinary vers les types Db2 CHAR, VARCHAR, CHAR FOR BIT DATA et VARCHAR FOR BIT DATA, respectivement, la réplication définit la longueur du type de données Db2 sur la même valeur que celle du type SQL Server.

    Cette approche permet de créer avec succès la table générée au niveau de l’abonné, à condition que la contrainte de taille de page DB2 soit suffisamment grande pour accueillir la taille maximale de la ligne. Assurez-vous que la connexion que vous utilisez pour accéder à la base de données Db2 possède des autorisations pour accéder à des espaces de tables de taille suffisante pour les tables à reproduire en Db2.

  • DB2 prend en charge des colonnes VARCHAR de 32 kilooctets (KB) ; par conséquent, certaines grandes colonnes objet de SQL Server peuvent être correctement mappées aux colonnes VARCHAR DB2. Cependant, le fournisseur OLE DB utilisé par la réplication pour DB2 ne supporte pas de mapper les gros objets de SQL Server sur les gros objets DB2. Pour cette raison, les colonnes SQL Server text, varchar(max),ntext et nvarchar(max) sont mappées à VARCHAR(0) dans les scripts de création générés. Vous devez changer la valeur de longueur de 0 en une valeur appropriée avant d’appliquer le script à l’Abonné. Si vous ne modifiez pas la longueur du type de données, DB2 génère l’erreur 604 lorsque la création de la table est tentée chez l’abonné DB2 (l’erreur 604 indique que l’attribut précision ou longueur d’un type de donnée n’est pas valide).

    En fonction de votre connaissance de la table source que vous répliquez, déterminez s'il est approprié de mapper un objet grand SQL Server à un élément DB2 de longueur variable, et spécifiez une longueur maximale appropriée dans un script de création personnalisé. Pour des informations sur la spécification d’un script de création personnalisé, voir l’étape 5 dans la section « Configuration d’un abonné IBM Db2 » dans cet article.

    Remarque

    La longueur spécifiée pour le type DB2, combinée aux autres longueurs de colonne, ne peut pas dépasser la taille maximale de ligne basée sur l’espace de table DB2 auquel les données de table sont attribuées.

    S’il n’existe pas de mappage approprié pour une colonne d’objet volumineux, envisagez d’utiliser le filtrage de colonnes sur l’article afin que cette colonne ne soit pas répliquée. Pour plus d’informations, consultez Filtrer des données publiées.

  • Lors de la réplication de SQL Server nchar et nvarchar en DB2 CHAR et VARCHAR, la réplication utilise la même longueur pour le type DB2 que pour le type SQL Server. Cependant, la longueur du type de données peut être trop petite pour la table DB2 générée.

    Dans certains environnements DB2, un élément de données de char SQL Server n'est pas limité aux caractères d'un seul octet ; la longueur d'un élément CHAR ou VARCHAR doit prendre en compte cette condition. Vous devez aussi prendre en compte les caractères shift in et shift out si nécessaire. Si vous répliquez des tables avec des colonnes nchar et nvarchar , vous devrez peut-être spécifier une longueur maximale plus grande pour le type de données dans un script de création personnalisé. Pour des informations sur la spécification d’un script de création personnalisé, voir l’étape 5 dans la section « Configuration d’un abonné IBM Db2 » dans cet article.

Contenu connexe

  • Last updated on