• Articolo

Considerazioni sull'aggiornamento di database replicati

SQL Server 2008 supporta l'aggiornamento di database replicati da versioni precedenti di SQL Server senza che sia necessario, durante l'aggiornamento di un nodo, interrompere le attività negli altri nodi. Verificare che vengano osservate le regole relative alle versioni supportate in una topologia:

  • Per partecipare a una topologia di replica con SQL Server 2008, è necessario disporre almeno di SQL Server 2000 Service Pack 3 (SP3). Se si utilizza SQL Server 2005, non vi è alcun requisito di versione minima.

  • La versione del server di distribuzione è indifferente, purché superiore o uguale alla versione del server di pubblicazione (in molti casi l'istanza del server di distribuzione è la stessa del server di pubblicazione).

  • La versione del server di pubblicazione è indifferente, purché inferiore o uguale alla versione del server di distribuzione.

  • La versione del Sottoscrittore dipende dal tipo di pubblicazione:

    • La versione di un Sottoscrittore per una pubblicazione transazionale può essere una versione qualsiasi all'interno di 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, mentre un server di pubblicazione SQL Server 2008 può disporre di Sottoscrittori SQL Server 2000.

    • Un Sottoscrittore a una pubblicazione di tipo merge può essere qualsiasi versione inferiore o uguale alla versione del server di pubblicazione.

[!NOTA]

Questo argomento è disponibile nella Guida del programma di installazione e nella documentazione in linea di SQL Server. I collegamenti visualizzati in grassetto nella Guida del programma di installazione si riferiscono ad argomenti disponibili solo nella documentazione in linea.

Esecuzione dell'agente di lettura log per la replica transazionale prima dell'aggiornamento

Prima di eseguire l'aggiornamento a SQL Server 2008, è necessario assicurarsi che tutte le transazioni completate dalle tabelle pubblicate siano state elaborate dall'agente di lettura log. Per assicurarsi che tutte le transazioni siano state elaborate, eseguire i passaggi seguenti per ogni database che contiene pubblicazioni transazionali:

  1. Verificare che l'agente di lettura log sia in esecuzione per il database. Per impostazione predefinita, l'agente viene eseguito in modo continuativo.

  2. Arrestare l'attività dell'utente nelle tabelle pubblicate.

  3. Concedere tempo all'agente di lettura log per copiare transazioni nel database di distribuzione, quindi arrestare l'agente.

  4. Eseguire sp_replcmds per verificare che siano state elaborate tutte le transazioni. Il set di risultati restituito da questa procedura deve essere vuoto.

  5. Eseguire sp_replflush per chiudere la connessione da sp_replcmds.

  6. Eseguire l'aggiornamento del server a SQL Server 2008.

  7. Riavviare SQL Server Agent e l'agente di lettura log se non vengono avviati automaticamente dopo l'aggiornamento.

Esecuzione degli agenti per una replica di tipo merge dopo l'aggiornamento

Al termine dell'aggiornamento, eseguire l'agente snapshot per ogni pubblicazione di tipo merge e l'agente di merge per ogni sottoscrizione in modo da aggiornare i metadati della replica. Non occorre applicare il nuovo snapshot in quanto non è necessario reinizializzare le sottoscrizioni. I metadati delle sottoscrizioni vengono aggiornati alla prima esecuzione dell'agente di merge successiva all'aggiornamento. Ciò significa che il database di sottoscrizione può rimanere in linea e attivo durante l'aggiornamento del server di pubblicazione.

La replica di tipo merge archivia i metadati delle pubblicazioni e delle sottoscrizioni in alcune tabelle di sistema nei database di pubblicazione e sottoscrizione. L'esecuzione dell'agente snapshot aggiorna i metadati delle pubblicazioni e l'esecuzione dell'agente di merge aggiorna i metadati delle sottoscrizioni. È semplicemente richiesta la generazione di uno snapshot di pubblicazione. Se una pubblicazione di tipo merge utilizza filtri con parametri, ogni partizione includerà uno snapshot. Non è necessario aggiornare gli snapshot partizionati. (In SQL Server 2000 i filtri con parametri vengono denominati filtri dinamici e gli snapshot partizionati vengono denominati snapshot dinamici).

Eseguire gli agenti da SQL Server Management Studio, Monitoraggio replica o dalla riga di comando. Per ulteriori informazioni sull'esecuzione dell'agente snapshot, vedere gli argomenti seguenti:

Per ulteriori informazioni sull'esecuzione dell'agente di merge, vedere gli argomenti seguenti:

Al termine dell'aggiornamento di SQL Server in una topologia che utilizza una replica di tipo merge, modificare il livello di compatibilità di tutte le pubblicazioni se si desidera utilizzare le nuove funzionalità. Per ulteriori informazioni, vedere Utilizzo di più versioni di SQL Server in una topologia di replica.

Aggiornamento alle versioni Standard, Workgroup o Express

Prima di eseguire l'aggiornamento da un'edizione all'altra di SQL Server 2008, verificare che le funzionalità utilizzate siano supportate nell'edizione a cui si esegue l'aggiornamento. Per ulteriori informazioni, vedere la sezione relativa alle funzionalità di replica di SQL Server 2008 nell'argomento Funzionalità supportate dalle edizioni di SQL Server 2008.

Nuovo modello di protezione dell'agente di replica

Per impostazione predefinita, nelle versioni di SQL Server precedenti a SQL Server 2005 gli agenti vengono eseguiti nel contesto dell'account del servizio SQL Server Agent. In SQL Server 2005 è stato introdotto un controllo accurato di ogni account utilizzato per eseguire gli agenti di replica che a loro volta stabiliscono connessioni integrate di Windows a database e altre risorse. Per ciascun agente è possibile specificare un account diverso. Per ulteriori informazioni, vedere Sicurezza e protezione (replica) e Modello di protezione dell'agente di replica.

Per l'aggiornamento e l'esecuzione di SQL Server 2000 in una topologia, il nuovo modello di protezione presenta le implicazioni seguenti:

  • Per utilizzare in modo ottimale i miglioramenti a livello di protezione, è necessario che gli script di replica creati in SQL Server 2000 siano aggiornati per SQL Server 2008. Per ulteriori informazioni, vedere Procedura: Aggiornamento di script di replica (programmazione Transact-SQL della replica).

  • Un server di distribuzione o un Sottoscrittore aggiornato da SQL Server 2000 a SQL Server 2008 continuerà a essere eseguito con l'account di SQL Server Agent ed è possibile che disponga di un numero maggiore di privilegi rispetto a quelli necessari. Al termine dell'aggiornamento, è consigliabile specificare account separati per gli agenti con i privilegi minimi appropriati. Per specificare gli account separati:

    1. Inserire la pubblicazione e le sottoscrizioni nello script.

    2. Modificare gli script. Per ulteriori informazioni, vedere Procedura: Aggiornamento di script di replica (programmazione Transact-SQL della replica).

    3. Eliminare la pubblicazione e le sottoscrizioni. Per ulteriori informazioni, vedere Pubblicazione di dati e oggetti di database e Sottoscrizione delle pubblicazioni.

    4. Ricreare la pubblicazione e le sottoscrizioni mediante gli script modificati.

    Per informazioni sui privilegi richiesti dagli agenti, vedere Modello di protezione dell'agente di replica. Per informazioni sulla gestione di account di accesso e password, vedere Gestione degli account di accesso e delle password nella replica. Le nuove configurazioni di replica create al termine di un aggiornamento prevedono la definizione di un account specifico per ogni agente di replica.

    [!NOTA]

    Tutti gli agenti configurati per l'utilizzo dell'autenticazione di SQL Server per connessioni di database locali vengono modificati in modo da utilizzare l'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.

  • I partecipanti a una topologia di replica che eseguono versioni precedenti di SQL Server mantengono invariato il modello di protezione della replica precedente. Ad esempio:

    • Una sottoscrizione pull a un Sottoscrittore che esegue SQL Server 2000 non utilizza il nuovo modello di protezione, in quanto l'agente di merge o il server di distribuzione viene creato nel Sottoscrittore.

    • Una sottoscrizione push da un server di distribuzione che esegue SQL Server 2008 a un Sottoscrittore che esegue SQL Server 2000 utilizza il nuovo modello di protezione, in quanto l'agente di merge o il server di distribuzione viene creato nel server di distribuzione.

    • Un server di pubblicazione che esegue SQL Server 2000 con un server di distribuzione che esegue SQL Server 2008 non utilizza il nuovo modello di protezione (per l'agente snapshot, l'agente di lettura log o l'agente di lettura coda) in quanto gli agenti vengono creati nel contesto del database di pubblicazione.

  • SQL Server 2005 e SQL Server 2008 utilizzano lo stesso modello di protezione.

Sincronizzazione tramite il Web per la replica di tipo merge

L'opzione di sincronizzazione Web per la replica di tipo merge richiede che il listener per la replica di SQL Server (replisapi.dll) venga copiato nella directory virtuale nel server Internet Information Services (IIS) utilizzato per la sincronizzazione. Quando si configura la sincronizzazione tramite il Web, il file viene copiato nella directory virtuale dalla procedura di configurazione guidata della sincronizzazione tramite il Web. Se si aggiornano i componenti di SQL Server installati nel server IIS, è necessario copiare manualmente replisapi.dll dalla directory COM alla directory virtuale nel server IIS. Per ulteriori informazioni sulla configurazione della sincronizzazione tramite il Web, vedere Configurazione della sincronizzazione tramite il Web.

Ripristino di un database replicato da una versione precedente

Per verificare che in seguito al ripristino del backup di un database replicato vengano mantenute le impostazioni di replica di una versione precedente, eseguire il ripristino in un server e un database con gli stessi nomi del server e del database utilizzati per la creazione della copia di backup.