Condividi tramite

  • Articolo

Utilizzo di più versioni di SQL Server in una topologia di replica

La replica consente di replicare i dati tra versioni diverse di SQL Server. In questo argomento vengono fornite informazioni sui seguenti aspetti:

  • Versioni di SQL Server supportate

  • Mapping dei tipi di dati di SQL Server 2008 per le versioni precedenti

  • Ripristino di un database replicato da una versione precedente

  • Livello di compatibilità per le pubblicazioni di tipo merge

Per informazioni sulle modalità di replica dei dati in SQL Server Express e SQL Server Compact 3.5 SP1, vedere Replica di dati in SQL Server Express e Replica di dati in SQL Server Compact. Per informazioni sulle funzionalità supportate da ogni versione di SQL Server, vedere Funzionalità supportate dalle edizioni di SQL Server 2008.

Versioni di SQL Server supportate

Sia SQL Server 2000 che SQL Server 2005 possono partecipare alle topologie di replica con SQL Server 2008. Per SQL Server 2000 la versione minima è Service Pack 3 (SP3), mentre per SQL Server 2005 la versione minima è Service Pack 2 (SP2).

Quando si esegue la replica tra versioni diverse di SQL Server, le funzionalità disponibili sono in genere limitate a quelle supportate dalla versione meno recente utilizzata. Se, ad esempio, si aggiorna un server di distribuzione a un'istanza di SQL Server 2008, ma sono presenti un server di pubblicazione che esegue un'istanza di SQL Server 2005 e un Sottoscrittore che esegue un'istanza di SQL Server 2000, si disporrà delle funzionalità generali e di replica di SQL Server 2000.

[!NOTA]

Poiché in SQL Server il formato di archiviazione su disco è lo stesso negli ambienti a 64 bit e a 32 bit, in una topologia di replica possono essere presenti istanze del server eseguite in un ambiente a 32 bit e istanze del server eseguite in un ambiente a 64 bit.

Per tutti i tipi di replica, la versione del server di distribuzione non deve essere precedente a quella del server di pubblicazione. In molti casi l'istanza del server di distribuzione è la stessa di quella del server di pubblicazione.

In caso di replica transazionale, la versione di un Sottoscrittore di una pubblicazione transazionale è limitata a un intervallo di due versioni in base alla versione del server di pubblicazione. Un server di pubblicazione SQL Server 2000, ad esempio, può disporre di Sottoscrittori SQL Server 2008 e un server di pubblicazione SQL Server 2008 può disporre di Sottoscrittori SQL Server 2000.

In caso di replica di tipe merge, è possibile utilizzare qualsiasi versione del Sottoscrittore di una pubblicazione di tipo merge purché non sia successiva a quella del server di pubblicazione. Per ulteriori informazioni sulla compatibilità per le versioni precedenti, vedere la sezione "Livello di compatibilità per le pubblicazioni di tipo merge" di seguito in questo argomento. Per ulteriori informazioni sulle funzionalità di replica supportate nelle diverse versioni di SQL Server, vedere Funzionalità supportate dalle edizioni di SQL Server 2008.

Utilizzo di un server di distribuzione SQL Server 2005 o SQL Server 2008 con un server di pubblicazione che esegue SQL Server 2000

Sia SQL Server 2005 che SQL Server 2008 possono essere utilizzati come server di distribuzione remoto per server di pubblicazione che eseguono SQL Server 2000. In questo scenario, per modificare le proprietà degli agenti, eseguire nel server di distribuzione le stored procedure seguenti, le quali consentono di modificare proprietà introdotte in SQL Server 2005:

Se si dispone di un server di pubblicazione e di un server di distribuzione che eseguono SQL Server 2000, è possibile modificare le credenziali utilizzate dagli agenti per eseguire le connessioni utilizzando sp_changedistpublisher e sp_changesubscriber. Tuttavia, se si aggiorna il server di distribuzione a SQL Server 2008, non sarà possibile utilizzare queste procedure per modificare le credenziali utilizzate nei processi esistenti degli agenti. Le procedure influiscono sui processi degli agenti creati dopo che la procedura è stata chiamata. Per modificare le credenziali dei processi esistenti degli agenti, chiamare una delle quattro procedure elencate in precedenza.

Mapping dei nuovi tipi di dati per le versioni precedenti

In SQL Server 2008 e SQL Server 2005 sono supportati numerosi nuovi tipi di dati. Come illustrato nella tabella seguente, questi nuovi tipi di dati vengono mappati a tipi di dati compatibili nel Sottoscrittore se vengono utilizzate sottoscrizioni push da un server di distribuzione SQL Server 2005 o SQL Server 2008. Se i nuovi tipi di dati vengono replicati in Sottoscrittori che eseguono versioni precedenti di SQL Server, è necessario verificare che il mapping dei tipi di dati venga eseguito in modo corretto:

Tipo di dati di SQL Server 2008

Tipo di dati di SQL Server 2005

Tipo di dati di SQL Server 2000

Tipo CLR (Common Language Runtime) definito dall'utente (UDT): uguale o inferiore a 8000 byte

UDT

image

UDT: maggiore di 8000 byte1

varbinary(max)

image

date2, 3

nvarchar(10)

nvarchar(10)

datetime22, 3

nvarchar(27)

nvarchar(27)

datetimeoffset2, 3

nvarchar(34)

nvarchar(34)

Attributo FILESTREAM1, 4

varbinary(max)

Non supportato

geography e geometry1, 3

varbinary(max)

image

hierarchyid1, 5

varbinary(max)

image

nvarchar(max)

nvarchar(max)

ntext

time2, 3

nvarchar(16)

nvarchar(16)

varchar(max)

varchar(max)

text

varbinary(max)

varbinary(max)

image

xml

xml

ntext

1 I mapping per i tipi UDT, FILESTREAM, geography, geometry e hierarchyid non sono supportati per le pubblicazioni transazionali con le sottoscrizioni aggiornabili. Includere questi tipi solo se tutti i Sottoscrittori dell'aggiornamento eseguono SQL Server 2008 o una versione successiva.

2 La replica non controlla il formato dei dati inseriti nel Sottoscrittore. Di conseguenza l'applicazione deve verificare che i dati inseriti siano del formato corretto per le colonne di tipo date, datetime2, datetimeoffset e time. Questa operazione viene eseguita in genere mediante un vincolo. Se i dati non sono del formato corretto, non sarà possibile eseguire un inserimento nel server di pubblicazione.

3 I Sottoscrittori di SQL Server Compact 3.5 convertono questi tipi dopo che vengono replicati al Sottoscrittore. Per ulteriori informazioni sui mapping dei tipi di dati per SQL Server Compact 3.5, vedere la documentazione di SQL Server Compact 3.5.

Se si esegue il mapping di colonne di tipo geography o geometry a varbinary(max) o image, non è possibile replicare vincoli predefiniti per queste colonne. Le conseguenze sono le seguenti:

4 FILESTREAM è un attributo in una colonna varbinary(max). Per informazioni sull'utilizzo di colonne FILESTREAM in tabelle replicate, vedere la sezione "Replica" in Utilizzo di FILESTREAM con altre funzionalità di SQL Server. Le colonne per cui è presente un attributo FILESTREAM non devono essere incluse in pubblicazioni che utilizzano uno snapshot in modalità carattere.

5 Il supporto per colonne di tipo hierarchyid dipende dal tipo di replica e dalle versioni di SQL Server utilizzate. Per ulteriori informazioni, vedere la sezione "Utilizzo di colonne hierarchyid nelle tabelle replicate" in hierarchyid (Transact-SQL). Per la replica di tipo merge, il tipo hierarchyid viene mappato a image quando il livello di compatibilità della pubblicazione è 100RTM e viene utilizzato uno snapshot in modalità carattere.

Replica di tipi di dati XML

Quando si replicano tipi di dati XML in SQL Server Compact 3.5 SP1, la replica di tipo merge ne esegue il mapping in Ntext. I dati XML in SQL Server 2008 includono byte di prefisso per la codifica UTF-16. Questi byte vengono mantenuti quando si esegue la replica di tipo merge da SQL Server a SQL Server Compact 3.5 SP1. I byte di prefisso non vengono riconosciuti da SQL Server Management Studio quando si visualizza la colonna Ntext del database SQL Server Compact 3.5 SP1. Pertanto, vengono visualizzati come caratteri corrotti.

La raccolta di schemi XML di SQL Server 2008 è stata aggiornata. Ciò ha effetto quando si esegue la replica delle colonne XML associate a schemi XML da SQL Server 2008 a SQL Server 2005.

I fusi orari non sono obbligatori per i valori date, time e datetime degli schemi XML in SQL Server 2008. Pertanto, se nella colonna XML del server di pubblicazione di SQL Server 2008 non è specificato alcun fuso orario, la modifica non verrà applicata ai Sottoscrittori di SQL Server 2005, perché SQL Server 2005 richiede la specifica di un fuso orario.

Le informazioni del fuso orario relative ai valori di tipo date, time e datetime degli schemi XML del server di pubblicazione di SQL Server 2008 verranno convertite nel fuso orario UTC-0 in SQL Server 2005, rappresentato dall'indicatore Z.

I tipi date, time e datetime dello schema XML di SQL Server 2008 supportano una maggiore precisione. Pertanto, vengono arrotondati quando si esegue la replica in SQL Server 2005.

Quando si esegue la replica dei valori date o datetime degli schemi XML da SQL Server 2005 a SQL Server 2008, i valori con un anno negativo non verranno applicati in SQL Server 2008 perché non sono supportati in SQL Server 2008.

In queste situazioni, sp_table_validation e i metodi Validate negli agenti di replica possono avere esito negativo. Per ulteriori informazioni, vedere la sezione "Aggiornamento di dati XML tipizzati da SQL Server 2005 a SQL Server 2008" in Dati XML tipizzati confrontati con dati XML non tipizzati.

Pubblicazione di dati compressi

SQL Server 2008 supporta la compressione di riga e di pagina per tabelle e indici. Per informazioni sul supporto della replica per dati compressi, vedere la sezione "Impatto della compressione sulla replica" in Creazione di tabelle e di indici compressi.

Ripristino di un database replicato da una versione precedente

Quando si ripristina un backup di un database replicato da una versione precedente, è possibile mantenere le impostazioni di replica. Se si esegue il ripristino in un server e in un database i cui nomi corrispondono a quelli del server e del database in cui è stato eseguito il backup o se si specifica l'opzione KEEP_REPLICATION, le impostazioni di replica vengono mantenute. Per ulteriori informazioni, vedere RESTORE (Transact-SQL). Dopo il ripristino del database, eseguire sp_vupgrade_replication per aggiornare i dati dello schema e di sistema per il supporto della replica a livello del prodotto corrente.

Sebbene sia possibile mantenere le impostazioni di replica dopo il ripristino da un backup eseguito da una versione precedente, questa operazione viene utilizzata raramente come opzione di aggiornamento. È più comune aggiornare il database replicato nell'ambito di un aggiornamento del prodotto oppure ricreare il database e la configurazione di replica da un set di script.

Livello di compatibilità per le pubblicazioni di tipo merge

Nella replica di tipo merge il livello di compatibilità consente di determinare quali funzionalità possono essere utilizzate dalle pubblicazioni in un determinato database. I valori sono contenuti in un intervallo compreso tra 80RTM (SQL Server 2000 senza Service Pack installati) e 100RTM per SQL Server 2008. Il livello di compatibilità viene specificato in base a uno dei metodi seguenti:

Per le funzionalità seguenti è necessario un livello di compatibilità di 90RTM o superiore:

Sebbene le funzionalità seguenti non dipendano dal livello di compatibilità, per utilizzarle è tuttavia necessario l'agente di merge disponibile in SQL Server 2005 e versioni successive. I Sottoscrittori che eseguono versioni precedenti di SQL Server possono essere utilizzati come se la funzionalità non fosse abilitata.

Funzionamento del livello di compatibilità delle pubblicazioni in SQL Server 2008

Di seguito vengono riportati alcuni importanti aspetti relativi al comportamento del livello di compatibilità delle pubblicazioni di cui è consigliabile tenere conto:

  • Il livello di compatibilità delle pubblicazioni non è collegato al livello di compatibilità dei database.

  • Se si crea una pubblicazione utilizzando sp_addmergepublication o mediante oggetti RMO (Replication Management Objects), per impostazione predefinita il livello di compatibilità della pubblicazione è impostato su 80RTM. Se si crea una pubblicazione con Creazione guidata nuova pubblicazione, il livello di compatibilità della pubblicazione viene determinato in base alle opzioni selezionate nella pagina Tipi di Sottoscrittore della procedura guidata.

  • Nelle versioni di SQL Server precedenti a SQL Server 2005 il livello di compatibilità della pubblicazione viene aumentato automaticamente se si abilita una funzionalità per cui è necessario un livello superiore. A partire da SQL Server 2005, è necessario impostare manualmente il livello di compatibilità della pubblicazione su 90RTM o su un valore superiore prima di abilitare funzionalità per cui è necessario tale livello di compatibilità.

  • È possibile diminuire il livello di compatibilità delle pubblicazioni solo se l'agente snapshot non è stato avviato e se non esistono sottoscrizioni della pubblicazione.

  • Tutte le pubblicazioni di un database devono avere lo stesso livello di compatibilità. Questo requisito comporta le conseguenze indicate di seguito:

    • Se un database contiene una pubblicazione con un livello di compatibilità inferiore (ad esempio 80RTM) e si desidera aggiungere allo stesso database un'altra pubblicazione di livello 90RTM o superiore, è necessario aumentare manualmente il livello della prima pubblicazione prima di aggiungere la nuova pubblicazione.

    • Se un database contiene due o più pubblicazioni con livelli di compatibilità inferiori e si desidera aggiungere allo stesso database un'altra pubblicazione di livello 90RTM o superiore, è necessario eliminare tutte le pubblicazioni esistenti ad eccezione di una, aumentare il livello della pubblicazione rimanente fino a 90RTM o valore superiore, ricreare le pubblicazioni eliminate con il livello 90RTM o superiore e creare la nuova pubblicazione con il livello 90RTM o superiore.

Componenti e livelli di compatibilità necessari per la sincronizzazione Web

In SQL Server 2008 è supportata la sincronizzazione Web per Sottoscrittori che eseguono SQL Server 2005, SQL Server 2008 e SQL Server Compact 3.5 versioni 3.0, 3.1 e 3.5. Nella tabella seguente vengono elencati i livelli di compatibilità della pubblicazione e i componenti server necessari per ogni tipo di Sottoscrittore.

Versione del server di pubblicazione

Versione del Sottoscrittore

Livello di compatibilità della pubblicazione necessario

Componenti necessari sul server IIS

SQL Server 2008

SQL Server 2008

100RTM

Componenti IIS per SQL Server 2008

SQL Server 2008

SQL Server Compact 3.5 3.0, 3.1 e 3.5

90RTM

Componenti di IIS per SQL Server Compact 3.5 SP1 e per SQL Server 2008

SQL Server 2008

SQL Server 2005

90RTM

Componenti di IIS per SQL Server 2008

SQL Server 2005

SQL Server 2005

90RTM

Componenti di IIS per SQL Server 2005

SQL Server 2005

SQL Server Compact 3.5 3.0, 3.1 e 3.5

90RTM

Componenti IIS per SQL Server Compact 3.5 SP1 e per SQL Server 2005

SQL Server 2005

SQL Server 2008

Non applicabile1

Non applicabile1

1 Questa configurazione non è supportata poiché la versione del server di pubblicazione deve essere uguale o superiore rispetto alla versione del Sottoscrittore.