Aggiornare il log shipping a SQL Server 2012 (Transact-SQL)

Quando si effettua l'aggiornamento da SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2 a SQL Server 2012, è possibile mantenere le configurazioni per il log shipping. In questo argomento vengono descritti scenari alternativi e procedure consigliate per aggiornare una configurazione per il log shipping.

[!NOTA]

La compressione dei backup è stata introdotta in SQL Server 2008 Enterprise. In una configurazione per il log shipping aggiornata viene utilizzata l'opzione di configurazione a livello di server default backup compression per controllare se la compressione dei backup viene utilizzata per i file di backup del log delle transazioni. Il comportamento della compressione dei backup relativa ai backup del log può essere specificato per ogni configurazione per il log shipping. Per ulteriori informazioni, vedere Configurare il log shipping (SQL Server).

Contenuto dell'argomento

• Protezione dei dati prima dell'aggiornamento

• Aggiornamento dell'istanza del server di monitoraggio

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

• Aggiornamento di più istanze del server secondario

• Ridistribuzione del 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 ulteriori 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.

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

Contenuto della sezione

• Aggiornamento dell'istanza del server secondario

• Aggiornamento dell'istanza del server primario

Aggiornamento dell'istanza del server secondario

Il processo di aggiornamento prevede innanzitutto l'aggiornamento delle istanze del server secondario di una configurazione per il log shipping di SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2 a SQL Server 2012 prima di aggiornare l'istanza del server primario. È sempre necessario aggiornare prima l'istanza del server secondario per evitare che il log shipping funzioni in modo non corretto poiché 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 non si interrompe durante tutto il processo di aggiornamento poiché i server secondari aggiornati continuano a ripristinare i backup del log dal server primario di SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2. 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 secondario più 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.

[!NOTA]

Durante l'aggiornamento del server, il database secondario non viene aggiornato a un database di SQL Server 2012. Per eseguire l'aggiornamento, è necessario attivare la modalità online per il database.

Importante

L'opzione RESTORE WITH STANDBY non è supportata per i database che richiedono aggiornamenti. Se un database secondario aggiornato è stato configurato tramite RESTORE WITH STANDBY, non sarà più possibile ripristinare i log delle transazioni dopo l'aggiornamento. Per riprendere il log shipping sul database secondario, sarà necessario configurarlo nuovamente sul server di standby. Per ulteriori informazioni sull'opzione STANDBY, vedere Argomenti dell'istruzione RESTORE (Transact-SQL).

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 fronte di una maggiore complessità del processo di aggiornamento, è possibile aumentare la disponibilità del database eseguendo il failover del server primario di SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2 su un server secondario di SQL Server 2012 prima di aggiornare il server primario originale (scenario 2 riportato 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.

Importante
Prima di aggiornare l'istanza del server primario, è necessario accertarsi di avere aggiornato l'istanza del server secondario. Per ulteriori informazioni, vedere Aggiornamento dell'istanza del server secondario in precedenza in questo argomento.

Contenuto della sezione

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

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

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 è un processo costituito da tre procedure generali, ovvero l'esecuzione di un failover controllato sul server secondario, l'aggiornamento dell'istanza del server primario originale a SQL Server 2012 e l'impostazione del log shipping in un'istanza del server primario di SQL Server 2012. Tali procedure vengono descritte in questa sezione.

Importante
Se si intende disporre dell'istanza del server secondario come nuova istanza del server primario, è necessario rimuovere la configurazione per il log shipping. Il log shipping dovrà essere riconfigurato dal nuovo server primario nel nuovo server secondario dopo l'aggiornamento dell'istanza del server primario originale. Per ulteriori informazioni, vedere Disattivare il log shipping [SQL Server].

Contenuto della sezione

• Procedura 1: Esecuzione di un failover controllato sul server secondario

• Procedura 2: Aggiornamento dell'istanza del server primario originale a SQL Server 2012

• Procedura 3: Impostare il log shipping in SQL Server 2012

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 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 controllare i processi di backup applicati, utilizzare la stored procedure di sistema sp_help_log_shipping_monitor nel server di monitoraggio o nei server primario e secondario. 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 Avviare un processo.

   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. In seguito a quest'ultima operazione, il database verrà aggiornato a SQL Server 2012.

      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 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. 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: Aggiornamento dell'istanza del server primario originale a SQL Server 2012

Dopo aver aggiornato l'istanza del server primario originale a SQL Server 2012, per il database sarà ancora attivata la modalità offline e il formato.

Procedura 3: Impostazione del log shipping in SQL Server 2012

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 per il log shipping di SQL Server 2005, SQL Server 2008 o SQL Server 2008 R2, tornare all'istanza del server primario originale. Per ulteriori informazioni, vedere Per tornare all'istanza del server primario originale più 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 primario più 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 al formato di SQL Server 2012 nel momento in cui viene eseguito il primo ripristino del 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:

Importante
All'inizio del processo, prima di recuperare il backup del log delle transazioni manuale in base al quale è stata attivata la modalità offline per il database, è necessario che la configurazione per il log shipping sia stata rimossa dal server primario originale.

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 2012.

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

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

   Per ulteriori 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 ulteriori informazioni, vedere Gestione dei 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.

Importante
È necessario aggiornare sempre tutte le istanze del server secondario prima di aggiornare il server primario.

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 su cui è stato eseguito il failover, ovvero il database primario provvisorio (nel server B), eseguire manualmente il backup del log delle transazioni tramite 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 ulteriori informazioni su come abilitare il log shipping, vedere Configurare il log shipping (SQL Server).

Vedere anche

Concetti

Backup di log delle transazioni (SQL Server)

Applicazione dei backup di log delle transazioni (SQL Server)

Tabelle e stored procedure relative al log shipping