Aggiornamento del log shipping a SQL Server 2016 (Transact-SQL)

  • Articolo

Si applica a:SQL Server

Per mantenere la soluzione di ripristino di emergenza per il log shipping, aggiornare o applicare gli aggiornamenti di manutenzione nell'ordine appropriato. Gli aggiornamenti di manutenzione includono Service Pack o aggiornamenti cumulativi.

Nota

La compressione dei backup è stata introdotta in SQL Server 2008 (10.0.x) Enterprise. In una configurazione per il log shipping aggiornata viene usata l'opzione di configurazione a livello di server backup compression default per controllare se la compressione dei backup viene usata 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 altre informazioni, vedere Configurare il log shipping (SQL Server).

Contenuto dell'argomento:

Prerequisiti

Prima di iniziare, esaminare le informazioni seguenti:

  • Supported Version and Edition Upgrades: verificare che sia possibile eseguire l'aggiornamento a SQL Server 2016 dalla versione del sistema operativo Windows e di SQL Server. Ad esempio, non è possibile eseguire l'aggiornamento diretto da un'istanza di SQL Server 2005 a SQL Server 2019 (15.x).

  • Scegliere un Database Engine Upgrade Method: selezionare il metodo di aggiornamento appropriato e i passaggi in base alla verifica degli aggiornamenti di versione ed edizione supportati e anche in base agli altri componenti installati nell'ambiente interessato per aggiornare i componenti di ordine corretto.

  • Pianificare e testare il piano di aggiornamento del motore di database: esaminare le note sulla versione, i problemi di aggiornamento noti e l'elenco di controllo pre-aggiornamento e sviluppare e testare il piano di aggiornamento.

  • Requisiti hardware e software per l'installazione di SQL Server 2016: esaminare i requisiti software per l'installazione di SQL Server. Se è necessario software aggiuntivo, installarlo in ogni nodo prima di iniziare il processo di aggiornamento per ridurre al minimo eventuali tempi di inattività.

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.

Importante

Assicurarsi di disporre di spazio sufficiente nel server primario per contenere le copie di backup del log per tutto il tempo previsto per l'aggiornamento dei server secondari. Se è previsto il failover su un server secondario, la stessa considerazione è valida per il server secondario, ovvero il nuovo primario.

Aggiornamento dell'istanza del server di monitoraggio (facoltativo)

L'istanza del server di monitoraggio, se presente, può essere aggiornata in qualsiasi momento. Non è tuttavia è necessario aggiornare il server di monitoraggio facoltativo quando si aggiornano i server primario e secondari.

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. Per altre informazioni su un server di monitoraggio, vedere Informazioni sul log shipping (SQL Server).

Aggiornamento delle istanze del server secondario

Il processo di aggiornamento prevede prima di tutto l'aggiornamento delle istanze del server secondario di SQL Server prima di aggiornare l'istanza del server primario. È sempre necessario aggiornare prima le istanze secondarie di SQL Server. Il log shipping non viene interrotto durante tutto il processo di aggiornamento perché le istanze del server secondario aggiornate continuano a ripristinare i backup del log dall'istanza del server primario. Se l'istanza del server primario viene aggiornata prima dell'istanza del server secondario, il log shipping non funzionerà perché un backup creato in una versione più recente di SQL Server non può essere ripristinato in una versione precedente di SQL Server. È possibile aggiornare le istanze secondarie contemporaneamente o in sequenza, ma tutte le istanze secondarie devono essere aggiornate prima dell'istanza primaria, per evitare un errore di log shipping.

Durante l'aggiornamento di un'istanza del server secondario, i processi di copia e ripristino del log shipping non vengono eseguiti. Questo significa che i backup del log delle transazioni non ripristinati si accumulano nel server primario ed è necessario avere a disposizione spazio sufficiente per conservare questi backup non ripristinati. La quantità di accumulo dipende dalla frequenza di esecuzione dei backup pianificati nell'istanza del server primario e dalla sequenza di aggiornamento delle istanze secondarie. 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.

Al termine dell'aggiornamento delle istanze del server secondario, i processi dell'agente di log shipping riprendono e continuano con la copia e il ripristino dei backup del log dall'istanza del server primario alle istanze del server secondario. La quantità di tempo necessaria affinché le istanze de server secondario aggiornino il database secondario varia a seconda del tempo impiegato per aggiornare le istanze del server secondario e della frequenza dei backup nel server primario.

Nota

Durante l'aggiornamento del server, il database secondario non viene aggiornato alla nuova versione. Verrà aggiornato solo se viene portato online avviando un failover del database di distribuzione dei log. In teoria, questa condizione potrebbe persistere all'infinito. La quantità di tempo per aggiornare i metadati del database quando viene avviato un failover è limitata.

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 altre informazioni sull'opzione STANDBY, vedere Ripristinare un backup del log delle transazioni (SQL Server).

Aggiornamento dell'istanza del server primario

Dato che il log shipping è principalmente una soluzione di ripristino di emergenza, lo scenario più semplice e più comune consiste nell'aggiornare l'istanza primaria sul posto e il database è semplicemente 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.

Nota

Il log shipping supporta anche l'opzione per Eseguire il failover in un database secondario per il log shipping (SQL Server) e facoltativamente per la modifica dei ruoli tra i server primario e secondario per il log shipping (SQL Server). Dato però che il log shipping viene ormai configurato molto raramente come soluzione a disponibilità elevata dato che le opzioni più recenti sono molto più efficaci, il failover non consente in genere di ridurre al massimo i tempi di inattività, in quanto gli oggetti di database di sistema non verranno sincronizzati e fare in modo che i client possano individuare facilmente un server secondario alzato di livello e connettersi a tale server può essere veramente complicato.

Vedi anche

Eseguire l'aggiornamento a SQL Server 2016 usando l'Installazione guidata (programma di installazione)
Installare SQL Server 2016 dal prompt dei comandi
Configurare il log shipping (SQL Server)
Monitorare il log shipping (Transact-SQL)
Tabelle e stored procedure relative al log shipping