Abonnés IBM DB2

S’applique à :SQL Server

SQL Server prend en charge les abonnements push à IBM DB2/AS 400, DB2/MVS et DB2/Universal Database via les fournisseurs OLE DB inclus dans Microsoft Host Integration Server.

Configuration d'un Abonné 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 Enterprise Edition, dans la page Web téléchargements SQL Server, dans la section Téléchargements associés, cliquez sur le lien vers la dernière version du Pack de fonctionnalités Microsoft SQL Server. Sur la page web Microsoft SQL Server Feature Pack, recherchez Fournisseur Microsoft OLEDB pour DB2.

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

    Outre l’installation du fournisseur, nous vous recommandons d’installer l’outil d’accès aux données, qui est utilisé à l’étape suivante (il est installé par défaut avec le téléchargement pour SQL Server Enterprise Edition. 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é. Il est possible de créer la chaîne de connexion dans n'importe quel éditeur de texte mais il est conseillé d'utiliser l'outil d'accès aux données. Pour créer la chaîne dans l'outil d'accès aux données :

    1. Cliquez sur Démarrer, sur Programmes, sur Fournisseur Microsoft OLE DB pour DB2, puis sur 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. Après quoi, un lien UDL (Universal Data Link) est créé avec une chaîne de connexion associée (en fait, c'est la chaîne de connexion et non l'UDL qui est utilisée par la réplication).

    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 se présentera comme suit (des sauts de ligne ont été insérés pour faciliter la lecture) :

    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 de cette chaîne sont propres au serveur DB2 que vous configurez, mais vous devez attribuer aux options Process Binary as Character et Derive Parameters la valeur False. Une valeur est nécessaire afin que l'option Initial Catalog identifie la base de données d'abonnement. La chaîne de connexion sera indiquée dans l'Assistant Nouvel abonnement lorsque vous créerez l'abonnement.

  3. Créez une publication transactionnelle ou d’instantané, activez-la pour les abonnés non-SQL Server, puis créez un abonnement 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, le script est créé dans le dialecte Transact-SQL, puis traduit en dialecte SQL plus générique par l’Agent de distribution avant d’être appliqué à l’Abonné. Pour spécifier un script de création personnalisé, modifiez le script Transact-SQL existant ou créez un script complet qui utilise le dialecte DB2 SQL ; si un script DB2 est créé, utilisez la directive bypass_translation afin que l’Agent de distribution applique le script sur l’Abonné sans traduction.

    Les scripts sont modifiés pour diverses raisons mais le plus souvent pour changer les mappages des types de données. Pour plus d'informations, consultez la section « Considérations sur le mappage des types de données », plus loin dans cette rubrique. Si vous modifiez le script Transact-SQL, les modifications doivent être limitées aux modifications de mappage de type de données (et le script ne doit pas contenir de commentaires). Si des modifications plus importantes sont nécessaires, 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, accédez au dossier d'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 à l'aide du Bloc-notes ou d'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 langage 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 mentionnées dans la rubrique Non-SQL Server Subscribers, prenez en compte les points suivants lors de la réplication sur des Abonnés DB2 :

  • Les données et les index de chaque table répliquée sont assignées à un espace disque logique DB2. La taille de page d'un espace disque logique DB2 détermine le nombre maximal de colonnes et la taille de ligne maximale des tables appartenant à l'espace disque logique. 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 des tables sur des Abonnés DB2 à l'aide de la réplication transactionnelle si une ou plusieurs colonnes clés primaire a le type de données DECIMAL(32-38, 0-38) ou NUMERIC(32-38, 0-38). La réplication transactionnelle identifie les lignes à l'aide de la clé primaire ; des échecs peuvent se produire car ces types de données sont mappés à VARCHAR(41) sur l'Abonné. Les tables avec des clés primaires qui utilisent ces types de données peuvent être publiées à l'aide de la réplication d'instantané.

  • Si vous souhaitez créer préalablement ces tables sur l'Abonné plutôt qu'elles soient créées par la réplication, utilisez l'option Prise en charge de la réplication uniquement. Pour plus d’informations, consultez Initialiser un abonnement transactionnel sans instantané.

  • SQL Server autorise des noms de tables et des noms de colonnes plus longs que DB2 :

    • Si la base de données de publication comprend des tables dont les noms sont plus longs que ceux pris en charge par la version DB2 de l'Abonné, spécifiez un autre nom pour la propriété de l'article destination_table. 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.

    • Il est impossible de spécifier d'autres noms pour les colonnes. Vous devez vous assurer que les tables publiées ne contiennent pas des noms de colonne plus longs que ceux pris en charge par la version DB2 de l'Abonné.

Mappage des types de données SQL Server et 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) CHAR(1-254) FOR BIT DATA
binary(255-8000) VARCHAR(255-8000) FOR BIT DATA
bit SMALLINT
char(1-254) CHAR(1-254)
char(255-8000) VARCHAR(255-8000)
date DATE
datetime timestamp
datetime2(0-7) VARCHAR (27)
datetimeoffset(0-7) VARCHAR (34)
decimal(1-31, 0-31) DECIMAL(1-31, 0-31)
decimal(32-38, 0-38) VARCHAR (41)
float(53) DOUBLE
float FLOAT
Geography IMAGE
geometry IMAGE
hierarchyid IMAGE
image VARCHAR(0) FOR BIT DATA*
into INT
money DECIMAL(19,4)
nchar(1-4000) VARCHAR(1-4000)
ntext VARCHAR(0)*
numeric(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 timestamp
smallint SMALLINT
smallmoney DECIMAL(10,4)
sql_variant N/A
sysname VARCHAR (128)
texte VARCHAR(0)*
time(0-7) VARCHAR(16)
timestamp CHAR(8) FOR BIT DATA
tinyint SMALLINT
uniqueidentifier CHAR(38)
varbinary(1-8000) VARCHAR(1-8000) FOR BIT DATA
varchar(1-8000) VARCHAR(1-8000)
varbinary(max) VARCHAR(0) FOR BIT DATA*
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 le mappage des types de données

Lors de la réplication sur des Abonnés DB2, prenez en compte ce qui suit pour le mappage des types de données :

  • Lors du mappage de caractères SQL Server, varchar, binaire et varbinary à 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 comme celui du type de données SQL Server.

    La table générée est ainsi correctement créée sur l'Abonné, pour autant que la contrainte de taille de page DB2 soit suffisamment grande pour prendre en charge la taille maximale de la ligne. Vérifiez que le nom de connexion utilisé pour accéder à la base de données DB2 possède des autorisations d'accès à des espaces disque logiques d'une taille suffisante pour contenir les tables répliquées sur DB2.

  • DB2 peut prendre en charge les colonnes VARCHAR aussi grandes que 32 kilo-octets (Ko) ; Il est donc possible que certaines colonnes d’objets volumineuses SQL Server puissent être correctement mappées aux colonnes DB2 VARCHAR. Toutefois, le fournisseur OLE DB utilisé par la réplication pour DB2 ne prend pas en charge le mappage des objets volumineux SQL Server aux objets volumineux 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. La valeur de longueur 0 doit être changée en valeur appropriée avant d'appliquer le script sur l'Abonné. Si la longueur du type de données n'est pas modifiée, DB2 génère l'erreur 604 lors de la tentative de création de table sur l'Abonné DB2 (l'erreur 604 indique que l'attribut precision ou length d'un type de données n'est pas valide).

    En fonction de vos connaissances de la table source que vous répliquez, déterminez s’il convient de mapper un objet volumineux SQL Server à un élément DB2 de longueur variable et de spécifier une longueur maximale appropriée dans un script de création personnalisé. Pour plus d'informations sur la spécification d'un script de création personnalisé, reportez-vous à l'étape 5 de la section « Configuration d'un Abonné IBM DB2 » dans cette rubrique.

    Note

    La longueur spécifiée du type DB2, lorsqu'elle est combinée avec d'autres longueurs de colonne, ne peut pas dépasser la taille de ligne maximale évaluée en fonction de l'espace disque logique DB2 auquel sont assignées les données de table.

    En l'absence d'un mappage approprié pour une colonne d'objet volumineux, envisagez d'utiliser le filtrage de colonnes sur l'article afin que la colonne ne soit pas répliquée. Pour plus d’informations, consultez Filtrer des données publiées.

  • Lors de la réplication de nchar SQL Server et nvarchar vers DB2 CHAR et VARCHAR, la réplication utilise le même spécificateur de longueur pour le type DB2 que pour le type SQL Server. Toutefois, il se peut que la longueur du type de données soit trop petite pour la table DB2 générée.

    Dans certains environnements DB2, un élément de données char SQL Server n’est pas limité aux caractères d’un octet unique ; la longueur d’un élément CHAR ou VARCHAR doit prendre en compte cette valeur. Vous devez également prendre en compte les caractères en code et hors code , s'ils sont nécessaires. Si vous répliquez des tables avec des colonnes nchar et nvarchar , il se peut que vous deviez spécifier une longueur maximale plus élevée pour le type de données dans un script de création personnalisé. Pour plus d'informations sur la spécification d'un script de création personnalisé, reportez-vous à l'étape 5 de la section « Configuration d'un Abonné IBM DB2 » dans cette rubrique.

Voir aussi

Abonnés non SQL Server
S’abonner aux Publications