Condividi tramite

IBM DB2 Subscribers

  • Articolo

SQL Server supporta le sottoscrizioni push a IBM DB2/AS 400, DB2/MVS e DB2/Universal Database tramite i provider OLE DB inclusi in Microsoft Host Integration Server.

Configurazione di un Sottoscrittore IBM DB2

Per configurare un Sottoscrittore IBM DB2, eseguire la procedura seguente:

  1. Installare la versione più recente del provider Microsoft OLE DB per DB2 nel server di distribuzione:

    • Se si usa Microsoft SQL Server 2012 Enterprise, nella pagina Web download di SQL Server 2008 fare clic sul collegamento alla versione più recente del Feature Pack di Microsoft SQL Server 2008. Nella pagina Web Feature Pack di Microsoft SQL Server 2008 cercare Provider Microsoft OLE DB per DB2.

    • Se si usa SQL Server 2012 Standard, installare la versione più recente del server Microsoft Host Integration Services (HIS), che include il provider.

    Oltre a installare il provider, è consigliabile installare lo strumento di accesso ai dati, che viene usato nel passaggio successivo(viene installato per impostazione predefinita con il download per SQL Server 2012 Enterprise). Per ulteriori informazioni sull'installazione e sull'utilizzo dello strumento di accesso ai dati, vedere la documentazione del provider o di HIS.

  2. Creare una stringa di connessione per il Sottoscrittore. La stringa di connessione può essere creata in qualsiasi editor di testo, ma è consigliabile utilizzare lo strumento di accesso ai dati. Per creare la stringa nello strumento di accesso ai dati:

    1. Fare clic sul menu Start, scegliere Programmi, Provider Microsoft OLE DB per DB2e quindi Strumento di accesso ai dati.

    2. In Strumento di accesso ai datieseguire la procedura per fornire informazioni sul server DB2. Al termine della procedura, verrà creato un collegamento dati universale (UDL) con una stringa di connessione associata. Sarà tale stringa a essere utilizzata dalla replica e non il collegamento UDL.

    3. Accedere alla stringa di connessione: fare clic con il pulsante destro del mouse sul collegamento UDL nello strumento di accesso ai dati e scegliere Visualizza stringa di connessione.

    La stringa di connessione sarà simile alla seguente (le interruzioni di linea sono state inserite per favorire la leggibilità):

    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 maggior parte delle opzioni nella stringa è specifica per il server DB2 configurato, ma è necessario che l'opzione Process Binary as Character sia sempre impostata su False. È necessario specificare un valore per l'opzione Initial Catalog per identificare il database di sottoscrizione. La stringa di connessione verrà immessa nella Creazione guidata nuova sottoscrizione durante la creazione della sottoscrizione.

  3. Creare una pubblicazione snapshot o transazionale, abilitarla per sottoscrittori non SQL Server e quindi creare una sottoscrizione push per il Sottoscrittore. Per altre informazioni, vedere Creazione di una sottoscrizione per un Sottoscrittore non SQL Server.

  4. Se necessario, specificare uno script di creazione personalizzato per uno o più articoli. Quando viene pubblicata una tabella, viene creato uno script CREATE TABLE per la tabella. Per i Sottoscrittori non SQL Server, lo script viene creato nel dialetto Transact-SQL e quindi viene convertito in un dialetto SQL più generico dal agente di distribuzione prima di essere applicato nel Sottoscrittore. Per specificare uno script di creazione personalizzato, modificare lo script Transact-SQL esistente o creare uno script completo che usa il dialetto SQL DB2; se viene creato uno script DB2, usare la direttiva bypass_translation in modo che il agente di distribuzione applicherà lo script nel Sottoscrittore senza traduzione.

    Gli script possono essere modificati per numerosi motivi, ma quello più comune consiste nella necessità di modificare i mapping dei tipi di dati. Per ulteriori informazioni, vedere la sezione "Considerazioni sui mapping dei tipi di dati" di seguito in questo argomento. Se si modifica lo script Transact-SQL, le modifiche devono essere limitate alle modifiche al mapping dei tipi di dati e lo script non deve contenere commenti. Se sono necessarie modifiche più sostanziali, creare uno script DB2.

    Per modificare lo script di un articolo e fornirlo come script di creazione personalizzato

    1. Dopo avere generato uno snapshot per la pubblicazione, passare alla cartella snapshot per la pubblicazione.

    2. Individuare il file sch che ha lo stesso nome dell'articolo, ad esempio MyArticle.sch.

    3. Aprire il file utilizzando il Blocco note o un altro editor di testo.

    4. Modificare il file e salvarlo in una directory diversa.

    5. Eseguire sp_changearticle specificando il percorso e il nome del file per la proprietà creation_script. Per altre informazioni, vedere sp_changearticle (Transact-SQL).

    Per creare lo script di un articolo e fornirlo come script di creazione personalizzato

    1. Creare lo script di un articolo utilizzando il sottolinguaggio DB2 SQL. Verificare che la prima riga del file sia bypass_translatione non contenga altro.

    2. Eseguire sp_changearticle specificando il percorso e il nome del file per la proprietà creation_script.

Considerazioni per i Sottoscrittori IBM DB2

Oltre alle considerazioni riportate nell'argomento Non-SQL Server Subscribers, quando si esegue una replica nei Sottoscrittori DB2 tenere presenti gli aspetti seguenti:

  • I dati e gli indici per ogni tabella replicata sono associati a un spazio tabella DB2. La dimensione della pagina di uno spazio tabella DB2 controlla il numero massimo di colonne e la dimensione massima delle righe delle tabelle che appartengono allo spazio tabella. Verificare che lo spazio tabella associato alle tabelle replicate sia appropriato al numero di colonne replicate e alla dimensione massima delle righe delle tabelle.

  • Non pubblicare tabelle nei Sottoscrittori DB2 utilizzando una replica transazionale se i dati di una o più colonne chiave primaria nella tabella sono di tipo DECIMAL(32-38, 0-38) o NUMERIC(32-38, 0-38). La replica transazionale identifica le righe utilizzando la chiave primaria. Ciò può dar luogo a errori, in quanto per i tipi di dati viene eseguito il mapping a VARCHAR(41) nel Sottoscrittore. Le tabelle con chiavi primarie che utilizzano questi tipi di dati possono essere pubblicate tramite la replica snapshot.

  • Se si desidera creare tabelle nel Sottoscrittore evitando che vengano create dalla replica, utilizzare l'opzione replication support only. Per altre informazioni, vedere Inizializzazione di una sottoscrizione transazionale senza uno snapshot.

  • SQL Server consente nomi di tabella e nomi di colonna più lunghi rispetto a DB2:

    • Se il database di pubblicazione include tabelle con nomi più lunghi di quelli supportati nella versione DB2 del Sottoscrittore, specificare un nome alternativo per la proprietà dell'articolo destination_table. Per altre informazioni sull'impostazione delle proprietà durante la creazione di una pubblicazione, vedere Creare una pubblicazione e Definire un articolo.

    • Non è possibile specificare nomi di colonna alternativi. È necessario verificare che le tabelle pubblicate non includano nomi di colonna più lunghi di quelli supportati nella versione DB2 del Sottoscrittore.

Mapping dei tipi di dati tra SQL Server e IBM DB2

Nella tabella seguente vengono illustrati i mapping dei tipi di dati utilizzati quando si esegue la replica dei dati in un Sottoscrittore in cui è in esecuzione IBM DB2.

Tipo di dati di SQL Server Tipo di dati 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 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 real
smalldatetime timestamp
smallint SMALLINT
smallmoney DECIMAL(10,4)
sql_variant N/D
sysname VARCHAR(128)
text VARCHAR(0)1
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 DATA1
varchar(max) VARCHAR(0)1
xml VARCHAR(0)1

1 Vedere la sezione successiva per altre informazioni sui mapping a VARCHAR(0).

Considerazioni sui mapping dei tipi di dati

Quando si esegue la replica nei Sottoscrittori DB2, considerare gli aspetti seguenti relativi ai mapping dei tipi di dati:

  • Quando si esegue il mapping SQL Server char, varchare varbinarybinary a DB2 CHAR, VARCHAR, CHAR FOR BIT DATA e VARCHAR FOR BIT DATA, rispettivamente, la replica imposta la lunghezza del tipo di dati DB2 come quella del tipo di SQL Server.

    In questo modo, la tabella generata viene creata correttamente nel Sottoscrittore, a condizione che il vincolo relativo alla dimensione della pagina DB2 consenta di supportare la dimensione massima delle righe. Verificare che l'account di accesso al database DB2 disponga delle autorizzazioni per utilizzare gli spazi tabella con dimensioni sufficienti per le tabelle replicate in DB2.

  • DB2 può supportare colonne VARCHAR di dimensioni pari a 32 kilobyte (KB); è quindi possibile che alcune colonne SQL Server oggetti di grandi dimensioni possano essere mappate in modo appropriato alle colonne VARCHAR DB2. Tuttavia, il provider OLE DB utilizzato dalla replica per DB2 non supporta il mapping SQL Server oggetti di grandi dimensioni a oggetti di grandi dimensioni db2. Per questo motivo, SQL Server textcolonne , varchar(max), ntexte nvarchar(max) vengono mappate a VARCHAR(0) negli script di creazione generati. È necessario modificare il valore di lunghezza 0 in un valore appropriato prima di applicare lo script nel Sottoscrittore. Se la lunghezza del tipo di dati non cambia, in DB2 viene generato l'errore 604 quando si tenta di creare la tabella nel Sottoscrittore DB2. L'errore 604 indica che l'attributo di precisione o di lunghezza di un tipo di dati non è valido.

    In base alla conoscenza della tabella di origine da replicare, determinare se è appropriato eseguire il mapping di un oggetto SQL Server di grandi dimensioni a un elemento DB2 a lunghezza variabile e specificare una lunghezza massima appropriata in uno script di creazione personalizzato. Per informazioni sulla definizione di uno script di creazione personalizzato, vedere il passaggio 5 nella sezione "Configurazione di un Sottoscrittore IBM DB2" in questo argomento.

    Nota

    La lunghezza specificata per il tipo DB2, se associata ad altre lunghezze di colonna, non può superare la dimensione massima delle righe basata sullo spazio tabella DB2 cui sono assegnati i dati della tabella.

    Se non esiste alcun mapping appropriato per una colonna LOB, valutare l'opportunità di applicare filtri colonne nell'articolo affinché la colonna non venga replicata. Per altre informazioni, vedere Filtrare i dati pubblicati.

  • Quando si esegue la replica di SQL Server nchar e nvarchar in DB2 CHAR e VARCHAR, la replica usa lo stesso identificatore di lunghezza per il tipo DB2 come per il tipo di SQL Server. La lunghezza del tipo di dati, tuttavia, potrebbe essere troppo ridotta per la tabella DB2 generata.

    In alcuni ambienti DB2, un elemento di dati SQL Server char non è limitato a caratteri a byte singolo. La lunghezza di un elemento CHAR o VARCHAR deve tenere conto di questo. È inoltre necessario considerare i caratteri di controllo SI e i caratteri di controllo SO , se richiesti. Se si esegue la replica di tabelle con nchar colonne e nvarchar , potrebbe essere necessario specificare una lunghezza massima maggiore per il tipo di dati in uno script di creazione personalizzato. Per informazioni sulla definizione di uno script di creazione personalizzato, vedere il passaggio 5 nella sezione "Configurazione di un Sottoscrittore IBM DB2" in questo argomento.

Vedere anche

Non-SQL Server Subscribers
Sottoscrizione delle pubblicazioni