Condividi tramite

Sottoscrittori IBM DB2

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, seguire questa procedura:

  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, nella sezione Download correlati, fare clic sul collegamento alla versione più recente del Feature Pack di Microsoft SQL Server 2008. Nella pagina Web Microsoft SQL Server 2008 Feature Pack 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 all'installazione del 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 altre informazioni sull'installazione e l'uso dello strumento di accesso ai dati, vedere la documentazione del provider o la documentazione his.

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

    1. Fare clic su Start, Programmi, Provider Microsoft OLE DB per DB2 e quindi strumento di accesso ai dati.

    2. Nello strumento di accesso ai dati seguire la procedura per fornire informazioni sul server DB2. Quando si completa lo strumento, viene creato un collegamento dati universale (UDL) con una stringa di connessione associata (il codice UDL non viene effettivamente usato dalla replica, ma la stringa di connessione è).

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

    La stringa di connessione sarà simile a (le interruzioni di riga sono per 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 del server DB2 che si sta configurando, ma l'opzione Process Binary as Character deve essere sempre impostata su False. È necessario un valore per l'opzione Initial Catalog per identificare il database di sottoscrizione. La stringa di connessione verrà immessa nella Creazione guidata di una nuova sottoscrizione al momento di creare la sottoscrizione.

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

  4. Facoltativamente, specificare uno script di creazione personalizzato per uno o più articoli. Quando viene pubblicata una tabella, viene creato uno script CREATE TABLE per tale tabella. Per i Sottoscrittori non SQL Server, lo script viene creato nel dialetto Transact-SQL e quindi convertito in un dialetto SQL più generico dall'agente di distribuzione prima di essere applicato al Sottoscrittore. Per specificare uno script di creazione personalizzato, modificare lo script di 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 l'agente di distribuzione applichi lo script nel Sottoscrittore senza traduzione.

    Gli script possono essere modificati per diversi motivi, ma il motivo più comune è modificare i mapping dei tipi di dati. Per altre informazioni, vedere la sezione "Considerazioni sul mapping dei tipi di dati" in questo argomento. Se si modifica lo script di 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 uno script di articolo e fornirlo come script di creazione personalizzato

    1. Dopo aver generato lo snapshot per la pubblicazione, passare alla cartella snapshot per la pubblicazione.

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

    3. Apri questo file usando 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 uno script di articolo e specificarlo come script di creazione personalizzato

    1. Creare uno script di articolo usando il dialetto SQL db2. Assicurarsi che la prima riga del file sia bypass_translation, senza nient'altro nella riga.

    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 illustrate nell'argomento Sottoscrittori non SQL Server, considerare i problemi seguenti durante la replica nei Sottoscrittori DB2:

  • I dati e gli indici per ogni tabella replicata vengono assegnati a uno spazio di tabella DB2. Le dimensioni della pagina di uno spazio di tabella DB2 controllano il numero massimo di colonne e le dimensioni massime delle righe delle tabelle appartenenti allo spazio tabelle. Assicurarsi che lo spazio di tabella associato alle tabelle replicate sia appropriato in base al numero di colonne replicate e alle dimensioni massime delle righe delle tabelle.

  • Non pubblicare tabelle nei Sottoscrittori DB2 usando la replica transazionale se una o più colonne chiave primaria nella tabella sono di tipo di dati DECIMAL(32-38, 0-38) o NUMERIC(32-38, 0-38). La replica transazionale identifica le righe usando la chiave primaria; Questo può causare errori perché questi tipi di dati vengono mappati a VARCHAR(41) nel Sottoscrittore. Le tabelle con chiavi primarie che usano questi tipi di dati possono essere pubblicate tramite la replica snapshot.

  • Se si desidera creare le tabelle nel Sottoscrittore prima che la replica le crei, usare l'opzione di supporto esclusivo per la replica. Per altre informazioni, vedere Inizializzare una sottoscrizione transazionale senza un'istantanea.

  • 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 nel 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 assicurarsi che le tabelle pubblicate non includano nomi di colonna più lunghi di quelli supportati nella versione DB2 nel Sottoscrittore.

Mapping dei tipi di dati da SQL Server a IBM DB2

Nella tabella seguente vengono illustrati i mapping dei tipi di dati usati quando i dati vengono replicati in un Sottoscrittore che esegue IBM DB2.

Tipo di dati di SQL Server Tipo di dati IBM DB2
bigint DECIMAL(19,0)
binary(1-254) CHAR(1-254) PER I DATI BIT
binary(255-8000) VARCHAR(255-8000) PER I DATI BIT
bit SMALLINT
char(1-254) CHAR(1-254)
char(255-8000) VARCHAR(255-8000)
date DATTERO
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) DOPPIO
float Galleggiare
geography IMMAGINE
geometry IMMAGINE
hierarchyid IMMAGINE
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 REALE
smalldatetime TIMESTAMP
smallint SMALLINT
smallmoney DECIMAL(10,4)
sql_variant Non disponibile
sysname VARCHAR(128)
text VARCHAR(0)1
time(0-7) VARCHAR(16)
timestamp CHAR(8) PER DATI BINARI
tinyint SMALLINT
uniqueidentifier CHAR(38)
varbinary(1-8000) VARCHAR(1-8000) PER I DATI DI BIT
varchar(1-8000) VARCHAR(1-8000)
varbinary(max) VARCHAR(0) FOR BIT DATA1
varchar(max) VARCHAR(0)1
xml VARCHAR(0)1

1 Consultare la sezione successiva per ulteriori informazioni sulle mappature a VARCHAR(0).

Considerazioni sul mapping dei tipi di dati

Considerate i seguenti problemi di mapping dei tipi di dati quando replicate ai sottoscrittori di DB2:

  • Quando si esegue il mapping di SQL Server char, varchar, binary e varbinary 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 può essere creata correttamente nel Sottoscrittore, purché il vincolo di dimensioni della pagina DB2 sia sufficientemente grande per contenere le dimensioni massime della riga. Assicurarsi che l'account di accesso usato per accedere al database DB2 disponga delle autorizzazioni necessarie per accedere agli spazi delle tabelle di dimensioni sufficienti per le tabelle replicate in DB2.

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

    In base alla conoscenza della tabella di origine che si sta replicando, determinare se è appropriato eseguire il mapping di un oggetto DI 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 specifica di uno script di creazione personalizzato, vedere il passaggio 5 nella sezione "Configurazione di un Sottoscrittore IBM DB2" in questo argomento.

    Annotazioni

    La lunghezza specificata per il tipo DB2, se combinata con altre lunghezze di colonna, non può superare la dimensione massima della riga in base allo spazio della tabella DB2 a cui sono assegnati i dati della tabella.

    Se non è disponibile alcun mapping appropriato per una colonna di oggetti di grandi dimensioni, è consigliabile usare il filtro delle colonne nell'articolo in modo che 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. Tuttavia, la lunghezza del tipo di dati potrebbe essere troppo piccola per la tabella DB2 generata.

    In alcuni ambienti DB2, un elemento di dati di SQL Server char non è limitato a caratteri a byte singolo. La lunghezza di un elemento CHAR o VARCHAR deve tenere presente questo elemento. È necessario prendere in considerazione anche i caratteri di spostamento in e spostamento fuori se necessario. Se si replicano 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 specifica di uno script di creazione personalizzato, vedere il passaggio 5 nella sezione "Configurazione di un Sottoscrittore IBM DB2" in questo argomento.

Vedere anche

Sottoscrittori non SQL Server
Sottoscrivere pubblicazioni

  • Last updated on