Aggiornamento del log shipping di SQL Server 2005 a SQL Server 2008

Il processo di aggiornamento prevede innanzitutto l'aggiornamento delle istanze del server secondario di una configurazione per il log shipping di SQL Server 2005 a SQL Server 2008 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. 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 "Considerazioni per l'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.

Importante

L'opzione RESTORE WITH STANDBY non è supportata per i database in cui vengono richiesti 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).

Quando si pianifica un aggiornamento, un aspetto significativo da considerare è la quantità di tempo in cui il database non sarà 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 su un server secondario di SQL Server 2008 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 questo argomento 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.

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

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 2008 e l'impostazione del log shipping in un'istanza del server primario di SQL Server 2008. 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 Rimozione del log shipping.

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à non in linea per il database. Si noti che mentre il database non è in linea, 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 (Transact-SQL) 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 recupero relativi alla configurazione per il log shipping. Per ulteriori informazioni, vedere Procedura: Avvio di un processo (SQL Server Management Studio) o sp_start_job (Transact-SQL).

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

      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à in linea 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 "Considerazioni per l'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 in linea (server B).

   5. Verificare che lo spazio disponibile sul log delle transazioni del database secondario non si esaurisca mentre il database è in linea. 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 2008

Dopo avere aggiornato l'istanza del server primario originale a SQL Server 2008, per il database sarà ancora attivata la modalità non in linea e il formato del database sarà SQL Server 2005.

Procedura 3. Impostazione del log shipping in SQL Server 2008

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, 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à non in linea 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 non in linea 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 2008 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à in linea per il database.

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

Dopo che il database è in linea, 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à non in linea 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 2008.

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 configurare il log shipping

   • Procedura: Attivazione della funzione di log shipping (SQL Server Management Studio)

   • Procedura: Abilitazione del log shipping (Transact-SQL)

5. Eseguire il failover del database reindirizzando i client dal server primario originale (server A) al server secondario in linea (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.

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.

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à non in linea 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à in linea per il database secondario ripristinando il backup del log tramite WITH RECOVERY.

4. Nell'altro server secondario (server C) lasciare attivata la modalità non in linea 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 in linea (server B). Il database in linea diventa un server primario provvisorio, mantenendo disponibile il database mentre per il server primario originale è attivata la modalità non in linea (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à non in linea 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.