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 aggiornare una configurazione per il log shipping.

Protezione dei dati prima dell'aggiornamento

Prima di eseguire un aggiornamento del log shipping, è consigliabile proteggere i dati.

Per proteggere i dati

1. Eseguire un backup completo di ciascun database primario.

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

2. Eseguire il comando DBCC CHECKDB in ciascun 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 per il log shipping continua a funzionare, ma lo stato relativo non viene registrato nelle tabelle sul monitor e non verrà attivato alcun avviso configurato. Dopo l'aggiornamento, è possibile eseguire la stored procedure di sistema sp_refresh_log_shipping_monitor per aggiornare le informazioni contenute nelle tabelle di monitoraggio.

Aggiornamento delle configurazioni per il log shipping con un unico server secondario

Il processo di aggiornamento descritto in questa sezione prevede l'utilizzo di una configurazione costituita dal server primario e da un unico server secondario. Tale configurazione è rappresentata nella figura seguente, in cui vengono illustrate un'istanza del server primario, A, e un'unica istanza del server secondario, B.

di

Per informazioni sull'aggiornamento di più server secondari, vedere Aggiornamento di più istanze del server secondariopiù 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 SQL Server 2005 o successiva a SQL Server 2014 prima di aggiornare l'istanza del server primario. È sempre necessario aggiornare prima l'istanza del server secondario 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 SQL Server 2005 o versione successiva. Il processo di aggiornamento delle istanze del server secondario dipende in parte dalla presenza di più server secondari nella configurazione per il log shipping. Per ulteriori informazioni, vedere Aggiornamento di più istanze del server secondariopiù avanti in questo argomento.

Durante l'aggiornamento dell'istanza del server secondario, i processi di copia del log shipping e di ripristino non sono in esecuzione e di conseguenza i backup del log delle transazioni non ripristinati si accumuleranno. La quantità di accumulo dipende dalla frequenza di esecuzione dei backup pianificati nel server primario. Se è stato configurato un server di monitoraggio separato, inoltre, è possibile che vengano generati avvisi che indicano che i ripristini non sono stati eseguiti per un tempo maggiore rispetto all'intervallo configurato.

Dopo che il server secondario è stato aggiornato, i processi dell'agente di log shipping riprendono e continuano a copiare e ripristinare i backup del log dall'istanza del server primario, ovvero il server A. La quantità di tempo necessaria affinché il server secondario aggiorni il database secondario varia a seconda del tempo impiegato per aggiornare il server secondario e della frequenza dei backup nel server primario.

Aggiornamento dell'istanza del server primario

Quando si pianifica un aggiornamento, un aspetto significativo da considerare è la quantità di tempo in cui il database non risulterà disponibile. Nello scenario di aggiornamento più semplice il database non è disponibile durante l'aggiornamento del server primario (scenario 1 riportato di seguito).

A costo di un processo di aggiornamento più complesso, è possibile ottimizzare la disponibilità del database eseguendo il failover del server primario SQL Server 2005 o superiore a un server secondario SQL Server 2014 prima di aggiornare il server primario originale (scenario 2, di seguito). Sono disponibili due scenari di failover diversi. È possibile tornare al server primario originale e mantenere la configurazione per il log shipping originale oppure è possibile rimuovere la configurazione per il log shipping originale prima di aggiornare il server primario originale e creare in un secondo momento una nuova configurazione utilizzando il nuovo server primario. In questa sezione vengono descritti entrambi gli scenari.

Scenario 1. Aggiornamento dell'istanza del server primario senza failover

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

Dopo che il server è stato aggiornato, viene attivata automaticamente la modalità online per il database determinandone pertanto l'aggiornamento. Dopo che il database è stato aggiornato, viene ripresa l'esecuzione dei processi per il log shipping.

Scenario 2. Aggiornamento dell'istanza del server primario con failover

In questo scenario viene aumentata al massimo la disponibilità e ridotto al minimo il tempo di inattività. Nello scenario viene utilizzato un failover controllato sull'istanza del server secondario che consente di mantenere il database disponibile durante l'aggiornamento dell'istanza del server primario originale. Il tempo di inattività è limitato al tempo relativamente breve necessario per eseguire il failover anziché essere costituito dal 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 al server secondario, aggiornamento dell'istanza del server primario originale a SQL Server 2014 e configurazione del log shipping in un'istanza del server primario SQL Server 2014. Tali procedure vengono descritte in questa sezione.

Procedura 1: Esecuzione di un failover controllato sul server secondario

Failover controllato sul server secondario:

1. Eseguire manualmente un backup della parte finale del log delle transazioni nel database primario specificando WITH NORECOVERY. Tale backup acquisisce qualsiasi record di log di cui non è stato eseguito il backup e attiva la modalità offline per il database. Si noti che mentre il database è offline, il processo di backup del log shipping non riuscirà.

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

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

   È consigliabile utilizzare una convenzione di denominazione del file distinta per differenziare il file di backup creato manualmente da quelli creati dal processo di backup del log shipping.

2. Nel server secondario effettuare le seguenti operazioni:

   1. Verificare che tutti i backup eseguiti automaticamente dai processi di backup del 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 nel server di monitoraggio o nei server primari e secondari. Lo stesso file deve essere elencato nelle colonne last_backup_file, last_copied_file e last_restored_file . Se un file di backup non è stato copiato né ripristinato, richiamare manualmente i processi di copia dell'agente e di ripristino relativi alla configurazione per il log shipping.

      Per informazioni sull'avvio di un processo, vedere Start a Job.

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

   3. Ripristinare il backup del log finale specificando WITH RECOVERY per attivare la modalità online per il database. Nell'ambito del trasferimento online, il database verrà aggiornato a SQL Server 2014.

      Nell'esempio seguente viene ripristinato il backup della parte finale del log del database AdventureWorks nel database secondario. Nell'esempio viene utilizzata l'opzione WITH RECOVERY che consente di attivare la modalità online per il database:

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

      Nota

      Per una configurazione in cui è presente più di un server secondario, è necessario tenere presente considerazioni aggiuntive. Per ulteriori informazioni, vedere Aggiornamento di più istanze del server secondariopiù 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. Verificare che lo spazio disponibile sul log delle transazioni del database secondario non si esaurisca mentre il database è online. Per evitare che si verifichi questa situazione, potrebbe essere necessario eseguire un backup del log. In questo caso è consigliabile eseguire il backup in un percorso condiviso, ovvero una condivisione di backup, in modo che i backup siano disponibili per eseguire 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à ancora offline e nel formato .

Procedura 3: Configurare il log shipping in SQL Server 2014

La parte rimanente del processo di aggiornamento dipende dalla presenza della configurazione per il log shipping, come indicato di seguito:

• Se è stata mantenuta la configurazione di log shipping superiore del SQL Server 2005or, tornare all'istanza del server primario originale. Per ulteriori informazioni, vedere Per tornare all'istanza del server primario originalepiù avanti in questa sezione.

• Se la configurazione per il log shipping è stata rimossa prima dell'esecuzione del failover, creare una nuova configurazione per il log shipping in cui l'istanza del server secondario originale costituisce la nuova istanza del server primario. Per ulteriori informazioni, vedere Per mantenere l'istanza precedente del server secondario come nuova istanza del server primariopiù avanti in questa sezione.

Per tornare all'istanza del server primario originale

1. Nel server primario provvisorio (server B) eseguire il backup della parte finale del log utilizzando WITH NORECOVERY per crearlo e per attivare la modalità offline per il database. La parte finale del log viene denominata Switchback_AW_20080315.trn, ad 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, ripristinare questi ultimi utilizzando WITH NORECOVERY nel database offline nel server primario originale (server A) anziché ripristinare il backup della parte finale del log creato nel passaggio 1. Il database viene aggiornato a SQL Server formato 2014 quando viene ripristinato il primo backup del log.

3. Ripristinare il backup della parte finale del log, Switchback_AW_20080315.trn, nel database primario originale (nel server A) utilizzando WITH RECOVERY per attivare la modalità online per il database.

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

Dopo che il database è online, verrà ripresa la configurazione per il log shipping originale.

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

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

1. Per evitare di eseguire un backup completo e di ripristinare il database nel nuovo server secondario (server A), applicare i backup del log dal nuovo database primario al nuovo database secondario. Nella configurazione di esempio questa operazione prevede 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) tramite WITH NORECOVERY. La prima operazione di ripristino aggiorna il database a SQL Server 2014.

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

   Importante

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

   Per altre informazioni, vedere Configurare il log shipping (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 sul nuovo database primario, è necessario verificare che tutti i relativi metadati siano coerenti con quelli 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

Tale configurazione è rappresentata nella figura seguente, in cui vengono illustrate un'istanza del server primario, A, e due istanze del server secondario, B e C.

In questa sezione viene descritto come eseguire l'aggiornamento tramite un failover e ritornare quindi al server primario originale. Se sono presenti più istanze del server secondario, l'aggiornamento dell'istanza primaria con failover costituisce un processo più complesso. Nella procedura seguente, dopo l'aggiornamento di tutti i server secondari, viene eseguito il failover del server primario su uno dei database secondari aggiornati. Successivamente il server primario originale viene aggiornato e il failover del log shipping viene eseguito nuovamente su tale server.

Per eseguire l'aggiornamento utilizzando un failover e ritornare quindi al server primario originale

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

2. Eseguire la parte finale del log delle transazioni del database primario (nel server A), quindi attivare la modalità offline per il database eseguendo il backup del log delle transazioni tramite WITH NORECOVERY.

3. Nel server secondario su cui si intende eseguire il failover (server B) attivare la modalità online per il database secondario ripristinando il backup del log tramite WITH RECOVERY.

4. Nell'altro server secondario (server C) lasciare attivata la modalità offline per il database ripristinando il backup del log tramite WITH NORECOVERY.

   Nota

   I processi di copia del log shipping e di ripristino verranno eseguiti nei server secondari, ma non eseguiranno alcuna operazione poiché i nuovi file di backup del log non saranno posizionati 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 disponibile il database mentre per il server primario originale è attivata la modalità offline (server A).

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

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

8. Ripristinare tutti i backup del log delle transazioni creati nel database primario provvisorio (nel server B) a ogni altro database secondario (nel server C) tramite WITH NORECOVERY. In questo modo il log shipping continuerà a funzionare dal database primario originale dopo il relativo aggiornamento, senza che sia necessario eseguire un ripristino completo di ogni database secondario.

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

Ridistribuzione del log shipping

Se non si desidera eseguire la migrazione della configurazione per il log shipping tramite una delle procedure illustrate in precedenza, è possibile ridistribuire il log shipping reinizializzando il database secondario con un backup e ripristino completi del database primario. Questa operazione è consigliabile nel caso di un database di piccole dimensioni oppure se non è essenziale garantire un livello di disponibilità elevato durante il processo di aggiornamento.

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

Vedere anche

Backup del log delle transazioni (SQL Server)Applica backup del log delle transazioni (SQL Server)Tabelle e stored procedure di log shipping