Condividi tramite

Aggiornare il Log Shipping a SQL Server 2014 (Transact-SQL)

È possibile mantenere le configurazioni di log shipping durante l'aggiornamento da SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 o SQL Server 2012 a SQL Server 2014. In questo argomento vengono descritti scenari alternativi e procedure consigliate per l'aggiornamento di una configurazione per il log shipping.

Annotazioni

La compressione dei backup è stata introdotta in SQL Server 2008 Enterprise. Una configurazione di log shipping aggiornata usa l'opzione di configurazione di backup compression default a livello di server per controllare se la compressione dei backup viene usata per i file di backup del log delle transazioni. È possibile specificare il comportamento di compressione del backup dei log per ogni configurazione di log shipping. Per ulteriori informazioni, vedere Configurare il trasferimento dei log (SQL Server).

Proteggere i dati prima dell'aggiornamento

Come procedura consigliata, è consigliabile proteggere i dati prima di un aggiornamento del log shipping.

Per proteggere i dati

  1. Eseguire un backup completo del database di ogni database primario.

    Per altre informazioni, vedere Creazione di un backup completo del database (SQL Server).

  2. Eseguire il comando DBCC CHECKDB in ogni database primario.

Aggiornamento dell'istanza del server di monitoraggio

L'istanza del server di monitoraggio, se presente, può essere aggiornata in qualsiasi momento.

Durante l'aggiornamento del server di monitoraggio, la configurazione del log shipping continua a funzionare, ma il relativo stato non viene registrato nelle tabelle del monitoraggio. Gli avvisi configurati non verranno attivati durante l'aggiornamento del server di monitoraggio. Dopo l'aggiornamento, è possibile aggiornare le informazioni nelle tabelle di monitoraggio eseguendo la procedura memorizzata di sistema sp_refresh_log_shipping_monitor.

Aggiornamento delle configurazioni di log shipping con un singolo server secondario

Il processo di aggiornamento descritto in questa sezione presuppone una configurazione costituita dal server primario e da un solo server secondario. Questa configurazione è rappresentata nella figura seguente, che mostra un'istanza del server primario, A e una singola istanza del server secondario, B.

Un server secondario e nessun server di monitoraggio Un

Per informazioni sull'aggiornamento di più server secondari, vedere Aggiornamento di più istanze del server secondario più avanti in questo argomento.

Aggiornamento dell'istanza del server secondario

Il processo di aggiornamento prevede l'aggiornamento delle istanze del server secondario di una configurazione di log shipping di SQL Server 2005 o successiva a SQL Server 2014 prima di aggiornare l'istanza del server primario. Aggiorna sempre l'istanza del server secondario per prima. Se il server primario è stato aggiornato prima di un server secondario, il log shipping avrà esito negativo perché un backup creato in una versione più recente di SQL Server non può essere ripristinato in una versione precedente di SQL Server.

Il log shipping continua durante il processo di aggiornamento perché i server secondari aggiornati continuano a ripristinare i backup del log dal server primario di SQL Server 2005 o versione successiva. Il processo di aggiornamento delle istanze del server secondario dipende in parte dal fatto che la configurazione del log shipping abbia più server secondari. Per altre informazioni, vedere Aggiornamento di più istanze del server secondario più avanti in questo argomento.

Durante l'aggiornamento dell'istanza del server secondario, i processi di copia e ripristino del log shipping non vengono eseguiti, quindi i backup dei log delle transazioni non ripristinati si accumulano. La quantità di accumulo dipende dalla frequenza del backup pianificato nel server primario. Inoltre, se è stato configurato un server di monitoraggio separato, potrebbero essere generati avvisi che indicano che i ripristini non sono stati eseguiti per più tempo rispetto all'intervallo configurato.

Dopo l'aggiornamento del server secondario, i processi degli agenti di log shipping riprendono e continuano a copiare e ripristinare i backup del log dall'istanza del server primario, server A. La quantità di tempo necessaria per il server secondario per aggiornare il database secondario varia a seconda del tempo impiegato per aggiornare il server secondario e la frequenza dei backup nel server primario.

Annotazioni

Durante l'aggiornamento del server, il database secondario non viene aggiornato a un database di SQL Server 2014. Verrà aggiornato solo se è collegato online.

Importante

L'opzione RESTORE WITH STANDBY non è supportata per un database che richiede l'aggiornamento. Se un database secondario aggiornato è stato configurato tramite RESTORE WITH STANDBY, i log delle transazioni non possono più essere ripristinati dopo l'aggiornamento. Per riprendere il log shipping nel database secondario, sarà necessario riconfigurarlo sul server di standby. Per altre informazioni sull'opzione STANDBY, vedere Argomenti RESTORE (Transact-SQL).

Aggiornamento dell'istanza del server primario

Quando si pianifica un aggiornamento, una considerazione significativa è la quantità di tempo in cui il database non sarà disponibile. Lo scenario di aggiornamento più semplice prevede che il database non sia disponibile durante l'aggiornamento del server primario (scenario 1, di seguito).

A costo di un processo di aggiornamento più complesso, è possibile ottimizzare la disponibilità del database eseguendo il failover del server primario di SQL Server 2005 o superiore a un server secondario di SQL Server 2014 prima di aggiornare il server primario originale (scenario 2, di seguito). Esistono due varianti dello scenario di failover. È possibile tornare al server primario originale e mantenere la configurazione del log shipping originale. In alternativa, è possibile rimuovere la configurazione originale per il log shipping prima di aggiornare il server primario originale e successivamente creare una nuova configurazione usando il nuovo server primario. Questa sezione descrive entrambi questi scenari.

Importante

Assicurarsi di aggiornare l'istanza del server secondario prima di aggiornare l'istanza del server primario. Per altre informazioni, vedere Aggiornamento dell'istanza del server secondario, più indietro in questo argomento.

Scenario 1: Aggiornare l'istanza del server primario senza failover

Questo è lo scenario più semplice, ma causa un tempo di inattività maggiore rispetto all'uso del failover. L'istanza del server primario viene semplicemente aggiornata e il database non è disponibile durante questo aggiornamento.

Una volta aggiornato il server, il database viene automaticamente riportato online, che ne determina l'aggiornamento. Dopo l'aggiornamento del database, i processi di log shipping riprendono.

Scenario 2: Aggiornamento dell'istanza del server primario con procedura di failover

Questo scenario ottimizza la disponibilità e riduce al minimo i tempi di inattività. Utilizza un failover controllato nell'istanza del server secondario, che mantiene il database disponibile durante l'aggiornamento dell'istanza del server primario originale. Il tempo di inattività è limitato al tempo relativamente breve necessario per il failover, anziché al tempo necessario per aggiornare l'istanza del server primario.

L'aggiornamento dell'istanza del server primario con failover prevede tre procedure generali: esecuzione di un failover controllato nel server secondario, aggiornamento dell'istanza del server primario originale a SQL Server 2014 e configurazione del log shipping in un'istanza del server primario di SQL Server 2014. Queste procedure sono descritte in questa sezione.

Importante

Se si prevede di disporre dell'istanza del server secondario come nuova istanza del server primario, è necessario rimuovere la configurazione del log shipping. Il log shipping dovrà essere riconfigurato dal nuovo database primario al nuovo database secondario, dopo l'aggiornamento dell'istanza del server primario originale. Per altre informazioni, vedere Rimuovere il log shipping (SQL Server).

Procedura 1: Eseguire un failover controllato nel server secondario

Failover controllato nel server secondario:

  1. Eseguire manualmente un backup della parte finale del log delle transazioni nel database primario specificando WITH NORECOVERY. Questo backup del log acquisisce tutti i record di log di cui non è ancora stato eseguito il backup e porta offline il database. Si noti che mentre il database è offline, il processo di backup del log shipping avrà esito negativo.

    Nell'esempio seguente viene creato un backup della parte finale del log del database AdventureWorks nel server primario. Il file di backup è denominato Failover_AW_20080315.trn:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
   WITH NORECOVERY;
GO

    È consigliabile usare una convenzione di denominazione dei file distinta per distinguere il file di backup creato manualmente dai file di backup creati dal processo di backup del log shipping.

  2. Nel server secondario:

    1. Assicurarsi che tutti i backup eseguiti automaticamente dai processi di backup per il log shipping siano stati applicati. Per verificare quali processi di backup sono stati applicati, usare la stored procedure di sistema sp_help_log_shipping_monitor sul server di monitoraggio o sui server primario e secondario. Lo stesso file deve essere elencato nelle colonne last_backup_file, last_copied_file e last_restored_file . Se uno dei file di backup non è stato copiato e ripristinato, richiamare manualmente i processi di copia e ripristino dell'agente per la configurazione del log shipping.

      Per informazioni sull'avvio di un'attività, vedere Avviare un'attività.

    2. Copiare il file di backup del log finale creato nel passaggio 1 dalla condivisione dei file al percorso locale usato dal log shipping nel server secondario.

    3. Ripristinare il backup del log finale specificando WITH RECOVERY per portare online il database. Come parte di essere portato online, il database verrà aggiornato a SQL Server 2014.

      Nell'esempio seguente viene ripristinato il backup della parte finale del log del AdventureWorks database nel database secondario. Nell'esempio viene usata l'opzione WITH RECOVERY, che porta online il database:

      RESTORE LOG AdventureWorks 
  FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
   WITH RECOVERY;
GO

      Annotazioni

      Per una configurazione che contiene più server secondari, è necessario tenere presenti considerazioni aggiuntive. Per altre informazioni, vedere Aggiornamento di più istanze del server secondario più avanti in questo argomento.

    4. Eseguire il failover del database reindirizzando i client dal server primario originale (server A) al server secondario online (server B).

    5. Prestare attenzione che il log delle transazioni del database secondario non si riempie mentre il database è online. Per impedire il riempimento del log delle transazioni, potrebbe essere necessario eseguirne il backup. In questo caso, è consigliabile eseguirne il backup in un percorso condiviso, una condivisione di backup, per rendere disponibili i backup per il ripristino nell'altra istanza del server.

Procedura 2: Aggiornare l'istanza del server primario originale a SQL Server 2014

Dopo aver aggiornato l'istanza del server primario originale a SQL Server 2014, il database sarà comunque offline e nel formato .

Procedura 3: Configurare il trasferimento dei log in SQL Server 2014

Il resto del processo di aggiornamento dipende dal fatto che il log shipping sia ancora configurato, come indicato di seguito:

Per ritornare all'istanza originale del server primario

  1. Nel server primario provvisorio (server B) eseguire il backup della parte finale del log usando WITH NORECOVERY per creare un backup della parte finale del log e portare offline il database. Il backup della parte finale del log è denominato Switchback_AW_20080315.trn. Per esempio:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
   WITH NORECOVERY;
GO

  2. Se nel database primario provvisorio sono stati eseguiti backup del log delle transazioni diversi dal backup finale creato nel passaggio 1, ripristinare tali backup del log usando WITH NORECOVERY nel database offline nel server primario originale (server A). Il database viene aggiornato al formato SQL Server 2014 quando viene ripristinato il primo backup del log.

  3. Ripristinare il backup del log finale, Switchback_AW_20080315.trn, nel database primario originale (sul server A) utilizzando WITH RECOVERY, per rendere il database disponibile online.

  4. Eseguire il failover nel database primario originale (nel server A) reindirizzando i client al server secondario online dal server primario originale.

Dopo che il database viene online, la configurazione originale per il log shipping riprenderà.

Per mantenere l'istanza del server secondario precedente come nuova istanza del server primario

Stabilire una nuova configurazione per il log shipping usando l'istanza precedente del server secondario, B, come server primario e l'istanza precedente del server primario, A, come nuovo server secondario, come indicato di seguito:

Importante

La configurazione del log shipping precedente dovrebbe essere stata rimossa dal server primario originale all'inizio del processo prima di eseguire il backup manuale del log delle transazioni che ha portato offline il database.

  1. Per evitare di eseguire un backup completo e il ripristino del database nel nuovo server secondario (server A), applicare i backup del log dal nuovo database primario al nuovo database secondario. Nella configurazione di esempio, ciò comporta il ripristino dei backup del log eseguiti nel server B nel database nel server A.

  2. Eseguire il backup del log dal nuovo database primario (nel server B).

  3. Ripristinare i backup del log nella nuova istanza del server secondario (server A) usando WITH NORECOVERY. La prima operazione di ripristino aggiorna il database a SQL Server 2014.

  4. Configurare il log shipping con il server che era precedentemente secondario (server B) come istanza del server primario.

    Importante

    Se si usa SQL Server Management Studio, specificare che il database secondario è già inizializzato.

    Per ulteriori informazioni, vedere Configurare il trasferimento dei log (SQL Server).

  5. Eseguire il failover del database reindirizzando i client dal server primario originale (server A) al server secondario online (server B).

    Importante

    Quando si esegue il failover in un nuovo database primario, è necessario assicurarsi che i relativi metadati siano coerenti con i metadati del database primario originale. Per altre informazioni, vedere Gestire i metadati quando si rende disponibile un database in un'altra istanza del server (SQL Server).

Aggiornamento di più istanze del server secondario

Questa configurazione è rappresentata nella figura seguente, che mostra un'istanza del server primario, A e due istanze del server secondario, B e C.

Due server secondari e nessun server di monitoraggio

Questa sezione illustra come eseguire l'aggiornamento usando un failover e quindi tornare al server primario originale. Quando si aggiorna l'istanza primaria con failover, il processo è più complesso quando sono presenti più istanze del server secondario. Nella procedura seguente, dopo che tutti i server secondari sono stati aggiornati, il server primario viene trasferito a uno dei database secondari aggiornati. Il server primario originale viene aggiornato e il failover del log shipping viene ripristinato su di esso.

Importante

Aggiornare sempre tutte le istanze del server secondario prima di aggiornare il server primario.

Per eseguire l'aggiornamento usando un failover e quindi tornare al server primario originale

  1. Aggiornare tutte le istanze del server secondario (server B e server C).

  2. Ottenere la parte finale del log delle transazioni del database primario (nel server A) e portare il database offline eseguendo il backup del log delle transazioni usando WITH NORECOVERY.

  3. Nel server secondario in cui si prevede di eseguire il failover (server B), portare online il database secondario ripristinando il backup del log tramite WITH RECOVERY.

  4. In ogni altro server secondario (server C) lasciare offline il database secondario ripristinando il backup del log usando WITH NORECOVERY.

    Annotazioni

    I processi di copia e ripristino del log shipping verranno eseguiti nei server secondari, ma i processi non eseguiranno alcuna operazione perché i nuovi file di backup del log non verranno inseriti nella condivisione di backup.

  5. Eseguire il failover del database reindirizzando i client dal server primario originale (server A) al server secondario online (server B). Il database online diventa un server primario provvisorio, mantenendo il database disponibile mentre il server primario originale è offline (server A).

  6. Aggiornare il server primario originale (server A).

  7. Nel database primario provvisorio su cui è stato eseguito il failover (nel server B), eseguire manualmente il backup del log delle transazioni usando WITH NORECOVERY. In questo modo il database viene offline.

  8. Ripristinare tutti i backup del log delle transazioni creati nel database primario provvisorio (sul server B) in ogni altro database secondario (nel server C) usando WITH NORECOVERY. In questo modo, il log shipping può continuare dal database primario originale dopo l'aggiornamento, senza richiedere un ripristino completo del database in ogni database secondario.

  9. Ripristinare il log delle transazioni dal server primario provvisorio (server B) al database primario originale (nel server A) usando WITH RECOVERY.

Ridistribuzione di Log Shipping

Se non si vuole eseguire la migrazione della configurazione per il log shipping usando una delle procedure illustrate in precedenza, è possibile ridistribuire il log shipping da zero reinizializzando il database secondario con un backup completo e il ripristino del database primario. Questa opzione può essere utile se si dispone di un database di piccole dimensioni o se la disponibilità elevata non è fondamentale durante la procedura di aggiornamento.

Per informazioni sull'abilitazione del log shipping, vedere Configurare il log shipping (SQL Server).

Vedere anche

Backup del log delle transazioni (SQL Server)Applicare i backup del log delle transazioni (SQL Server)Tabelle e stored procedure per il trasferimento dei log

  • Last updated on