Modifiche di rilievo alla replica di SQL Server

In questo argomento vengono descritte le modifiche di rilievo introdotte nella replica di SQL Server. Tali modifiche potrebbero interrompere il funzionamento di applicazioni, funzionalità o script basati su versioni precedenti di SQL Server. È possibile che questi problemi si verifichino quando viene eseguito un aggiornamento. Per ulteriori informazioni, vedere Utilizzo di Preparazione aggiornamento per preparare gli aggiornamenti.

Modifiche di rilievo apportate in SQL Server 2005 e SQL Server 2008

In questa sezione vengono illustrate le modifiche di rilievo alle funzionalità di replica effettuate in SQL Server 2005 o SQL Server 2008.

Modifiche di rilievo che interessano tutti i tipi di replica

Le modifiche riportate di seguito si applicano a tutti i tipi di replica.

Funzionalità	Descrizione
Modifiche necessarie per gli script di replica	Rispetto a SQL Server 2000 il modello di protezione dell'agente di replica è stato modificato. Per informazioni dettagliate sul modello di protezione, vedere Modello di protezione dell'agente di replica. Se si appartiene al ruolo predefinito del server sysadmin in SQL Server 2005 e si eseguono gli script di replica creati con SQL Server 2000 o SQL Server 7.0, gli script verranno eseguiti correttamente. Se si appartiene al ruolo predefinito del database dbo o a un altro ruolo, gli script avranno esito negativo e dovranno essere aggiornati. Per informazioni sull'aggiornamento degli script, vedere Procedura: Aggiornamento di script di replica (programmazione Transact-SQL della replica). Sebbene non sia obbligatorio aggiornare gli script eseguiti da membri del ruolo sysadmin, tale operazione è consigliabile per sfruttare i potenziamenti della protezione.
Connessioni locali per agenti di replica	Durante l'aggiornamento a SQL Server 2005, tutte le connessioni locali che utilizzano l'autenticazione di SQL Server vengono modificate per l'utilizzo dell'autenticazione di Windows. Le connessioni locali sono connessioni effettuate da un agente a un'istanza di SQL Server in esecuzione nello stesso computer dell'agente. Ad esempio, se l'agente di merge di una sottoscrizione pull viene eseguito nel Sottoscrittore, le connessioni eseguite dall'agente al Sottoscrittore sono connessioni locali. Nelle versioni precedenti di SQL Server per impostazione predefinita gli agenti vengono eseguiti nel contesto dell'account del servizio SQL Server Agent. Dopo l'aggiornamento, le connessioni locali vengono eseguite nel contesto di questo account. SQL Server 2005 consente un controllo dettagliato di ogni account nel quale vengono eseguiti gli agenti di replica che a loro volta effettuano connessioni integrate di Windows a database e altre risorse. È inoltre possibile specificare un account diverso per ogni agente. Dopo l'aggiornamento è consigliabile specificare account diversi per ogni agente. Per ulteriori informazioni, vedere Considerazioni sull'aggiornamento di database replicati e Modello di protezione dell'agente di replica.
Controlli ActiveX	Tutti i controlli ActiveX sono contrassegnati come non sicuri per la generazione di script e l'inizializzazione. Il controllo ActiveX dell'agente snapshot non è disponibile in SQL Server 2005. In alternativa, utilizzare il nuovo agente snapshot gestito. Per ulteriori informazioni, vedere SnapshotGenerationAgent e Procedura: Creazione dello snapshot iniziale (programmazione RMO).
Password per l'account distributor_admin	Le connessioni trusted tra un server di pubblicazione e un server di distribuzione remoto non sono più supportate perché non richiedono una password (le connessioni trusted vengono utilizzate per impostazione predefinita nelle versioni precedenti a SQL Server 2000 Service Pack 3). Se si utilizza un server di distribuzione remoto, convertire le connessioni trusted in connessioni non trusted prima dell'aggiornamento a SQL Server 2005. Questo problema non riguarda i server di pubblicazione che utilizzano un server di distribuzione locale. Per ulteriori informazioni sull'account distributor_admin, vedere Protezione del server di distribuzione. Per stabilire il tipo di connessione in uso Nel server di distribuzione eseguire sp_helpdistpublisher. Se il valore della colonna trusted è 1, è necessario modificare la connessione in non trusted. Per modificare la connessione trusted in non trusted Eseguire sp_changedistpublisher nel server di distribuzione specificando il valore 'trusted' per il parametro @property e il valore 'False' per il parametro @value. Nota Alcune versioni della documentazione in linea di SQL Server 2000 non riportano 'trusted' come valore valido per il parametro @property. Tale valore è tuttavia valido per tutte le versioni di SQL Server 2000. Eseguire sp_changedistributor_password sia nel server di pubblicazione che nel server di distribuzione, specificando una password complessa per il parametro @password.
In SQL Server Express non è incluso SQL Server Agent	Se si esegue l'aggiornamento a SQL Server Express, è necessario riconfigurare la sincronizzazione della replica poiché SQL Server Express non include SQL Server Agent. Se si desidera utilizzare sottoscrizioni pull, è necessario sincronizzarle tramite oggetti RMO (Replication Management Objects) o Gestione sincronizzazione Microsoft Windows oppure eseguendo l'agente di replica nella riga di comando. Per ulteriori informazioni, vedere Replica di dati in SQL Server Express. Se si desidera continuare a utilizzare SQL Server Agent per eseguire processi dell'agente di replica, è necessario utilizzare le sottoscrizioni push o eseguire l'aggiornamento a un'altra versione di SQL Server (tutte le versioni tranne SQL Server Express e SQL Server Compact 3.5 SP1 includono SQL Server Agent). Con le sottoscrizioni push, l'agente di distribuzione o di merge viene eseguito nel server di distribuzione, di conseguenza SQL Server Agent è disponibile (SQL Server Express non può essere un server di distribuzione).
Sottoscrittori Microsoft Access (Jet 4.0)	Jet è il database sottostante utilizzato da Access. In SQL Server 2000 la replica supporta le sottoscrizioni di database Jet. Queste sottoscrizioni non sono più supportate. In alternativa, è consigliabile utilizzare SQL Server Express. Access è in grado di utilizzare un database di SQL Server come back-end e i database di SQL Server non sono interessati da questo problema. Per ulteriori informazioni, vedere Replica di dati in SQL Server Express.

Modifiche di rilievo alla replica transazionale

Le modifiche seguenti si applicano alla replica transazionale.

Funzionalità	Descrizione
Inizializzazione di una sottoscrizione transazionale da una copia di backup1	Per inizializzare una sottoscrizione da una copia di backup in SQL Server 2008, l'utente deve appartenere al ruolo del server dbcreator. In SQL Server 2005 è sufficiente l'appartenenza al ruolo del database db_owner. Per ulteriori informazioni sull'inizializzazione di una sottoscrizione da una copia di backup, vedere Inizializzazione di una sottoscrizione transazionale senza uno snapshot.
Opzione MSMQ per sottoscrizione ad aggiornamento in coda	Con le sottoscrizioni ad aggiornamento in coda, le modifiche provenienti dai Sottoscrittori vengono scritte in una coda, quindi vengono lette dalla coda stessa e recapitate al server di pubblicazione dall'agente di lettura coda. In SQL Server 2000 le sottoscrizioni potrebbero utilizzare una coda SQL Server o MSMQ per accodare le modifiche. Il tipo di coda viene specificato con il parametro @queue_type di sp_addpublication, che consente l'utilizzo dei valori sql e msmq (Message Queuing). In SQL Server 2005 è invece consentito il solo valore sql. Le pubblicazioni esistenti che utilizzano MSMQ vengono modificate durante l'aggiornamento in modo da utilizzare una coda di SQL Server. Se si dispone di applicazioni che dipendono da un aggiornamento in coda tramite MSMQ, sarà necessario riscrivere tali applicazioni per includere una coda di SQL Server. Per ulteriori informazioni sulle sottoscrizioni ad aggiornamento in coda, vedere Sottoscrizioni aggiornabili per la replica transazionale. Con l'aggiornamento, le code di sottoscrizione MSMQ vengono rimosse se il servizio di Accodamento messaggi è in esecuzione durante l'aggiornamento di SQL Server. Importante In Windows 2000 e Windows XP deve inoltre essere in esecuzione il servizio Microsoft Distributed Transaction Coordinator (MS DTC). Con tali piattaforme, infatti, per MSMQ è necessario MSDTC. Se il servizio di Accodamento messaggi non è in esecuzione, rimuovere manualmente le code al termine dell'aggiornamento. Per ulteriori informazioni sulla rimozione di code, vedere la documentazione di Windows.
Modifica del formato di chiamata per l'aggiornamento di sottoscrizioni	Per impostazione predefinita, nella replica transazionale viene utilizzato un set di stored procedure per l'applicazione delle modifiche al Sottoscrittore. Ogni stored procedure dispone di un formato di chiamata. Questo formato determina il modo in cui i parametri vengono passati alla stored procedure e la quantità di dati inviati al Sottoscrittore. In SQL Server 2000 il formato predefinito è CALL, mentre in SQL Server 2005 e SQL Server 2008 il formato predefinito è VCALL. Questa modifica riguarda solo le topologie in cui sono state personalizzate le stored procedure. Dopo l'aggiornamento, è necessario modificare la firma della stored procedure personalizzata in modo da includere i parametri aggiuntivi. In caso contrario, l'agente di distribuzione avrà esito negativo.

1 Questo problema influisce solo su SQL Server 2008 e sulle versioni più recenti.

Modifiche di rilievo alla replica di merge

Le modifiche seguenti si applicano alla replica di tipo merge.

Funzionalità	Descrizione
Pubblicazione da SQL Server Express	SQL Server MSDE è in grado di fungere da server di pubblicazione per le pubblicazioni di tipo merge. SQL Server Express, ovvero la funzionalità utilizzata per sostituire MSDE, non è in grado di fungere da server di pubblicazione, tuttavia consente la sottoscrizione di pubblicazioni di tipo merge, transazionali e snapshot. La replica di tipo merge e la replica transazionale con sottoscrizioni aggiornabili consentono entrambe la propagazione delle modifiche dai Sottoscrittori al server di pubblicazione. Per ulteriori informazioni sulla replica in SQL Server Express, vedere Replica di dati in SQL Server Express.
Esecuzione in batch delle modifiche	Nelle versioni precedenti di SQL Server le modifiche apportate dall'agente di merge vengono eseguite riga per riga. In SQL Server 2005 le modifiche vengono apportate in batch per migliorare le prestazioni. Di conseguenza, all'interno di una singola istruzione è possibile inserire, aggiornare o eliminare più righe. Se i database di pubblicazione o di sottoscrizione contengono tabelle pubblicate che presentano trigger, verificare che i trigger siano in grado di gestire gli inserimenti, gli aggiornamenti e le eliminazioni di più righe. Per ulteriori informazioni, vedere Considerazioni sulle istruzioni che interessano più righe.
Ricreazione di tabelle con conflitti	In seguito all'aggiornamento a SQL Server 2005, le tabelle con conflitti vengono ricreate con DBO come proprietario. Se in SQL Server 2000 una tabella è di proprietà di un altro utente, è necessario modificare l'applicazione. La replica di merge crea una tabella con conflitti per ogni articolo di una pubblicazione, con un nome in formato conflict_PublicationName_ArticleName. Tutte le tabelle di metadati vengono ricreate in seguito all'aggiornamento e tutte le tabelle con conflitti vengono create nello schema DBO.
Assegnazione di nuovi intervalli di valori Identity	Per le tabelle che utilizzano la gestione automatica degli intervalli di valori Identity, è possibile che in seguito all'aggiornamento la replica assegni nuovi intervalli. Se a una tabella è stato assegnato un intervallo di valori Identity più ampio per il Sottoscrittore rispetto al server di pubblicazione, durante la replica verrà assegnato per il server di pubblicazione un intervallo uguale a quello del Sottoscrittore. Per determinare gli intervalli da utilizzare per ogni articolo, eseguire sp_helpmergearticle nel database di pubblicazione e controllare le colonne pub_identity_range e identity_range.

Vedere anche

Concetti

Compatibilità con le versioni precedenti della replica