Panoramica del log shipping
Il log shipping consente di inviare automaticamente i backup del log delle transazioni da un database primario in un'istanza del server primario a uno o più database secondari in istanze separate del server secondario. I backup del log delle transazioni vengono applicati singolarmente a ogni database secondario. Un terzo server facoltativo, noto come server di monitoraggio, registra la cronologia e lo stato delle operazioni di backup e di ripristino e genera avvisi nel caso in cui tali operazioni non vengano eseguite come previsto.
Operazioni per il log shipping
Il log shipping prevede tre operazioni:
Backup del log delle transazioni nell'istanza del server primario.
Copia del file di log delle transazioni nell'istanza del server secondario.
Ripristino del backup del log nell'istanza del server secondario.
È possibile distribuire il log a più istanze del server secondario e in questo caso sarà necessario ripetere le operazioni 2 e 3 per ognuna delle istanze.
Il failover di una configurazione per il log shipping dal server primario al server secondario non viene eseguito automaticamente. Se il database primario non è più disponibile, è possibile portare online manualmente uno qualsiasi dei database secondari.
È possibile utilizzare un database secondario per la generazione di report. Per ulteriori informazioni, vedere Utilizzo di server secondari per l'elaborazione delle query.
È inoltre possibile configurare avvisi per la configurazione per il log shipping.
Server e database primari
In una configurazione per il log shipping il server primario è l'istanza del Motore di database di SQL Server che rappresenta il server di produzione. Il database primario è il database nel server primario per il quale si desidera eseguire il backup su un altro server. Tutte le procedure di amministrazione della configurazione per il log shipping tramite SQL Server Management Studio vengono eseguite dal database primario.
Il database primario deve utilizzare il modello di recupero con registrazione completa o registrazione minima delle operazioni bulk. Il passaggio al modello di recupero con registrazione minima comporterà l'arresto del log shipping.
Server e database secondari
Il server secondario in una configurazione per il log shipping è il server in cui si desidera mantenere una copia del database primario in modalità standby a caldo (warm standby). Un server secondario può contenere copie di backup di database di numerosi server primari diversi. Si supponga, ad esempio, che in un reparto siano presenti cinque server, ognuno dei quali esegue un sistema di database critico per le strategie aziendali. È possibile utilizzare un unico server secondario, anziché cinque server secondari distinti. I backup dei cinque sistemi primari possono essere caricati nell'unico sistema di backup, con conseguente riduzione del numero di risorse e dell'investimento corrispondente. È improbabile che si verifichino contemporaneamente errori su più sistemi primari. Per ovviare anche a tale eventualità, è possibile prevedere un server secondario con specifiche superiori a quelle dei server primari.
Per inizializzare il database secondario è necessario ripristinare un backup completo del database primario, utilizzando l'opzione NORECOVERY o STANDBY per completare la procedura. È possibile eseguire questa operazione manualmente o tramite SQL Server Management Studio.
Server di monitoraggio
Il server di monitoraggio facoltativo tiene traccia di tutti i dettagli relativi al log shipping, ad esempio:
Quando è stato eseguito l'ultimo backup del log delle transazioni nel database primario.
Quando i server secondari hanno eseguito per l'ultima volta la copia e il ripristino dei file di backup.
Informazioni sugli avvisi di backup non riusciti.
Per evitare la perdita di dati critici o l'interruzione del monitoraggio nel caso in cui il server primario o secondario non sia più disponibile, è consigliabile utilizzare come server di monitoraggio un server distinto da quelli primario e secondario. Un singolo server di monitoraggio è in grado di monitorare più configurazioni per il log shipping. In questo scenario, tutte le configurazioni che utilizzano il server di monitoraggio condividono un singolo processo di gestione degli avvisi.
.gif "Nota importante") Importante |
|---|
Una volta configurato il server di monitoraggio, non sarà possibile modificarlo senza prima rimuovere il log shipping. |
Per ulteriori informazioni, vedere Monitoraggio del log shipping.
Processi per il log shipping
Il log shipping comprende quattro processi gestiti da processi di SQL Server Agent dedicati, ovvero il processo di backup, il processo di copia, il processo di ripristino e il processo per la gestione degli avvisi.
L'utente controlla la frequenza di esecuzione dei backup del log, la frequenza con cui vengono copiati in ogni server secondario e la frequenza con cui vengono applicati al database secondario. Per ridurre la quantità di operazioni necessarie per portare online un server secondario, ad esempio in caso di errore nel sistema di produzione, è possibile copiare e ripristinare i backup del log delle transazioni non appena vengono creati. In alternativa, ad esempio in un ulteriore server secondario, è possibile ritardare l'applicazione dei backup del log delle transazioni nel database secondario. In questo modo sarà disponibile un intervallo durante il quale è possibile individuare un eventuale errore nel sistema primario, ad esempio l'eliminazione accidentale di dati critici, e intraprendere le misure correttive opportune.
Processo di backup
Nell'istanza del server primario viene creato un processo di backup per ogni database primario. Il processo esegue il backup, registra la cronologia nel server locale e nel server di monitoraggio ed elimina i file di backup e le informazioni sulla cronologia precedenti. Per impostazione predefinita, questo processo viene eseguito ogni 15 minuti, ma l'intervallo è personalizzabile.
Se il log shipping è abilitato, nell'istanza del server primario viene creata la categoria di processi di SQL Server Agent relativa al backup per il log shipping.
SQL Server 2008 Enterprise Edition e le versioni successive supportano la compressione dei backup. Quando si crea una configurazione per il log shipping, è possibile determinare il comportamento della compressione dei backup per i backup del log. Per ulteriori informazioni, vedere Compressione backup (SQL Server).
Processo di copia
In una configurazione per il log shipping viene creato un processo di copia in ogni istanza del server secondario. Il processo copia i file di backup del server primario in una destinazione configurabile del server secondario e registra la cronologia nel server secondario e nel server di monitoraggio. La pianificazione del processo di copia, che è personalizzabile, deve seguire da vicino la pianificazione del backup.
Se il log shipping è attivato, nell'istanza del server secondario viene creata la categoria di processi di SQL Server Agent relativa alla copia per il log shipping.
Processo di ripristino
Per ogni configurazione per il log shipping, viene creato un processo di ripristino nell'istanza del server secondario. Il processo ripristina i file di backup copiati nei database secondari, registra la cronologia nel server locale e nel server di monitoraggio ed elimina i file e le informazioni sulla cronologia precedenti. Se il log shipping è attivato, nell'istanza del server secondario viene creata la categoria di processi di SQL Server Agent relativa al ripristino per il log shipping.
In un'istanza specifica del server secondario è possibile pianificare il processo di ripristino e quello di copia con la stessa frequenza, oppure ritardare il processo di ripristino. Pianificando una frequenza uguale per i due processi, il database secondario resterà quanto più possibile allineato al database primario, consentendo di creare un database in modalità standby a caldo (warm standby).
Ritardare i processi di ripristino di qualche ora può invece essere utile in caso di un errore grave dell'utente, come l'eliminazione impropria di una tabella o di una riga di una tabella. Se l'orario dell'errore è noto, è possibile eseguire il rollforward del database secondario a un momento immediatamente precedente all'errore, esportare i dati perduti e importarli nuovamente nel database primario.
Processo gestione avvisi
Se si utilizza un server di monitoraggio, nell'istanza di tale server viene creato un processo per la gestione degli avvisi. Il processo è condiviso dai database primari e secondari di tutte le configurazioni per il log shipping che utilizzano l'istanza del server di monitoraggio. Qualsiasi modifica al processo per la gestione degli avvisi (ad esempio la ripianificazione, la disabilitazione o l'attivazione del processo) influisce su tutti i database che utilizzano il server di monitoraggio. Il processo genera avvisi, per ognuno dei quali è necessario specificare un numero, relativi ai database primari e secondari nel caso in cui le operazioni di backup e ripristino non vengano completate entro le soglie stabilite. È necessario configurare gli avvisi in modo che un operatore riceva la notifica di un errore del log shipping. Se il log shipping è attivato, nell'istanza del server di monitoraggio viene creata la categoria di processi di SQL Server Agent relativa alla gestione degli avvisi per il log shipping.
Se non si utilizza un server di monitoraggio, i processi per la gestione degli avvisi vengono creati localmente nell'istanza del server primario e in ogni istanza di server secondario. Il processo per la gestione degli avvisi nell'istanza del server primario genera errori nel caso in cui le operazioni di backup non vengano completate entro una soglia stabilita. Quello nell'istanza del server secondario genera errori nel caso in cui le operazioni di copia e ripristino locali non vengano completate entro una soglia stabilita.
Configurazione tipica per il log shipping
Nella figura seguente viene illustrata una configurazione per il log shipping con l'istanza del server primario, tre istanze del server secondario e un'istanza del server di monitoraggio. Nella figura vengono illustrati i passaggi eseguiti dai processi di backup, copia e ripristino, nel modo che segue:
L'istanza del server primario esegue il processo di backup per eseguire il backup del log delle transazioni nel database primario. Il backup del log viene quindi inserito in un file di backup del log primario, che viene inviato alla cartella di backup. In questa figura, la cartella di backup risiede in una directory condivisa, la condivisione di backup.
Ognuna delle tre istanze del server secondario esegue un processo di copia per copiare il file di backup del log primario nella propria cartella di destinazione locale.
Ognuna delle istanze del server secondario esegue un processo di ripristino per ripristinare il backup del log dalla cartella di destinazione locale al database secondario locale.
Le istanze dei server primario e secondario inviano la propria cronologia e il proprio stato all'istanza del server di monitoraggio.
.gif "Configurazione che include processi di backup, copia e ripristino")
Per abilitare il log shipping
Vedere anche