Partager via

Abonnés IBM DB2

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 Microsoft SQL Server 2012 Enterprise, dans la page Web téléchargements SQL Server 2008 , dans la section Téléchargements connexes , cliquez sur le lien vers la dernière version du Pack de fonctionnalités Microsoft SQL Server 2008. Dans la page Web Microsoft SQL Server 2008 Feature Pack , recherchez le fournisseur Microsoft OLE DB pour DB2.

    • Si vous utilisez SQL Server 2012 Standard, 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 2012 Enterprise). 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 la documentation HIS.

  2. Créez une chaîne de connexion pour l’Abonné. La chaîne de connexion peut être créée dans n’importe quel éditeur de texte, mais nous vous recommandons 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, Programmes, 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, suivez les étapes pour fournir des informations sur le serveur DB2. Une fois l’outil terminé, un lien de données universel (UDL) est créé avec une chaîne de connexion associée (l’UDL n’est pas réellement utilisée par la réplication, mais la chaîne de connexion est).

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

    La chaîne de connexion est similaire à (les sauts de ligne sont à des fins de 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;Units of Work=RUW;DBMS Platform=DB2/NT;  
Persist Security Info=False;Connection Pooling=True;

    La plupart des options de la chaîne sont spécifiques au serveur DB2 que vous configurez, mais l’option Process Binary as Character doit toujours être définie sur False. Une valeur est requise pour l’option Initial Catalog permettant d’identifier la base de données d’abonnement. La chaîne de connexion sera entrée dans l’assistant Nouvel abonnement lorsque vous créez 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, consultez Créer un abonnement pour un abonné non-SQL Server.

  4. Si vous le souhaitez, spécifiez un script de création personnalisé pour un ou plusieurs articles. Lorsqu’une table est publiée, 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 de Transact-SQL existant ou créez un script complet qui utilise le dialecte SQL DB2 ; 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 peuvent être modifiés pour plusieurs raisons, mais la raison la plus courante consiste à modifier les mappages de types de données. Pour plus d’informations, consultez la section « Considérations relatives au mappage des types de données » 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 requises, créez un script DB2.

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

    1. Une fois que l’instantané a été généré pour la composition, accédez au dossier d’instantanés de la composition.

    2. Recherchez le fichier .sch portant le même nom que l’article, tel que 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 spécifiant le chemin d’accès et le nom du fichier pour 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 à l’aide du dialecte SQL DB2. Vérifiez que la première ligne du fichier est bypass_translation, sans rien d’autre sur la ligne.

    2. Exécutez sp_changearticle, en spécifiant le chemin d’accès et le nom du fichier pour la propriété creation_script .

Considérations relatives aux abonnés IBM DB2

En plus des considérations abordées dans la rubrique Abonnés non-SQL Server, tenez compte des problèmes suivants lors de la réplication vers les abonnés DB2 :

  • Les données et les index de chaque table répliquée sont affecté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 de ligne maximale des tables appartenant à l’espace de table. Vérifiez que l’espace de table associé aux tables répliquées est approprié en fonction du nombre de colonnes répliquées et de la taille maximale des lignes des tables.

  • Ne publiez pas de tables sur les abonnés DB2 à l’aide de la réplication transactionnelle si une ou plusieurs colonnes clés primaires de la table sont de 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 ; cela peut entraîner des échecs, 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 par instantanés.

  • Si vous souhaitez précréer des tables sur l’Abonné plutôt que de les laisser être créées par la réplication, utilisez l’option de prise en charge uniquement pour la réplication. 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 inclut des tables avec des noms plus longs que ceux pris en charge sur la version DB2 de l’abonné, spécifiez un nom alternatif 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 n’est pas possible de spécifier d’autres noms de colonnes. Vous devez vous assurer que les tables publiées n’incluent pas de noms de colonnes plus longs que ceux pris en charge par la version DB2 à l’Abonné.

Mappage des types de données de SQL Server à IBM DB2

Le tableau suivant montre les mappages de types de données utilisés lorsque les données sont répliquées sur un Abonné exécutant IBM DB2.

Type de données SQL Server Type de données IBM DB2
bigint DECIMAL(19,0)
binary(1-254) CHAR(1-254) POUR LES DONNÉES EN FORMAT BINAIRE
binary(255-8000) VARCHAR(255-8000) POUR LES DONNÉES BIT
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)
decimal(1-31, 0-31) DECIMAL(1-31, 0-31)
decimal(32-38, 0-38) VARCHAR(41)
float(53) DOUBLE
float FLOTTER
geography IMAGE
geometry IMAGE
hierarchyid IMAGE
image VARCHAR(0) FOR BIT DATA1
into INT
money DECIMAL(19,4)
nchar(1-4000) VARCHAR(1-4000)
ntext VARCHAR(0)1
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)1
real RÉEL
smalldatetime HORODATAGE
smallint SMALLINT
smallmoney DECIMAL(10,4)
sql_variant N/A
sysname VARCHAR(128)
text VARCHAR(0)1
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 BINAIRES
varchar(1-8000) VARCHAR(1-8000)
varbinary(max) VARCHAR(0) POUR DONNÉES BINAIRES1
varchar(max) VARCHAR(0)1
xml VARCHAR(0)1

1 Consultez la section suivante pour plus d’informations sur les correspondances à VARCHAR(0).

Considérations relatives au mappage des types de données

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

  • Lors du mappage de SQL Server char, varcharbinary 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.

    Cela permet à la table générée d’être créée avec succès sur l’Abonné, tant que la contrainte de taille de page DB2 est suffisamment grande pour prendre en charge la taille maximale de la ligne. Vérifiez que la connexion utilisée pour accéder à la base de données DB2 dispose des autorisations nécessaires pour accéder aux espaces de table d’une taille suffisante pour les tables répliquées vers 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, SQL Server text, varchar(max), ntextet nvarchar(max) les colonnes sont mappées à VARCHAR(0) dans les scripts de création générés. La valeur de longueur de 0 doit être modifiée en une valeur appropriée avant d’appliquer le script à l’Abonné. Si la longueur du type de données n’est pas modifiée, DB2 génère l’erreur 604 lorsque la table crée est tentée sur l’Abonné DB2 (l’erreur 604 indique que l’attribut de précision ou de longueur 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é, consultez l’étape 5 de la section « Configuration d’un abonné IBM DB2 » dans cette rubrique.

    Remarque

    La longueur spécifiée pour le type DB2, lorsqu’elle est combinée à d’autres longueurs de colonne, ne peut pas dépasser la taille maximale de ligne en fonction de l’espace de table DB2 auquel les données de la table sont affectées.

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

  • Lors de la réplication de SQL Server nchar 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, 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 SQL Server char 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 le décalage des caractères etles déplacer s’ils sont nécessaires. Si vous répliquez des tables avec et nvarchar des nchar colonnes, vous devrez peut-être spécifier une longueur maximale supérieure 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é, consultez 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

  • Last updated on