Percorsi di recupero
La comprensione del concetto di percorso di recupero è importante se si utilizzano backup differenziali o backup dei log e si esegue il recupero di un database fino a un punto nel tempo precedente tramite uno dei metodi seguenti:
- Esecuzione di un ripristino temporizzato
- Esecuzione di un recupero senza prima ripristinare tutti i backup dei log o il backup differenziale più recente.
Se si recupera un database da un punto di recupero precedente e si inizia a utilizzare il database da tale punto, verrà creato un nuovo percorso di recupero. Il percorso di recupero è la sequenza di dati e di backup dei log che hanno portato un database a un particolare punto nel tempo, tramite il normale utilizzo del database o tramite un ripristino specifico dei dati e del log. Un percorso di recupero è costituito da un set unico di trasformazioni specifiche che hanno determinato la modifica del database nel corso del tempo, mantenendone tuttavia la consistenza. Nella figura seguente viene illustrata la relazione tra un punto di recupero e i percorsi di recupero risultanti.
In genere, un punto di recupero comporta l'inizio di un nuovo percorso di recupero, poiché è necessario eseguire il rollback delle transazioni e il database si trova in uno stato univoco. È possibile che i numeri di sequenza del file di log (LSN) dei backup preesistenti siano ora maggiori dell'LSN del punto di recupero. Gli LSN in questi backup si trovano su un ramo di recupero diverso dal nuovo ramo creato dall'operazione di recupero corrente.
[!NOTA] Il ripristino di un backup completo del database e il recupero del database senza utilizzare altri tipi di backup determinano la creazione di un nuovo percorso di recupero.
Procedura consigliata Per evitare la creazione di un percorso di recupero con più fork di recupero, eseguire un set completo di backup dei dati non appena possibile dopo il recupero del database. Questo approccio garantisce che tutti i backup siano eseguiti su un ramo di recupero singolo. Per verificarlo, è possibile esaminare la colonna last_recovery_fork_guid nella tabella backupset o nel set di risultati RESTORE HEADERONLY.
Nelle situazioni seguenti viene creato un nuovo percorso di recupero in quanto il database non viene ripristinato fino alla fine. Esistono quindi backup che possono determinare la creazione di due o più percorsi di recupero, ognuno dei quali utilizzerà lo stesso intervallo di LSN.
- Ripristino di un backup completo e di un backup differenziale del database e recupero del database senza applicare i backup esistenti del log delle transazioni.
- Recupero del database fino alla fine di un backup differenziale diverso dal più recente.
- Recupero del database fino alla fine di un backup del log delle transazioni diverso dal più recente.
- Recupero del database fino a un punto specifico nel tempo o fino a una transazione contrassegnata all'interno di un backup del log delle transazioni.
Esempio di percorso di recupero
Nella figura seguente viene illustrata la creazione di un nuovo percorso di recupero quando il database viene recuperato. In questa figura vengono creati un backup completo del database e una sequenza di quattro backup del log. Il database viene quindi ripristinato in corrispondenza della fine del secondo backup del log ripristinando il backup completo del database, il primo backup del log e il secondo backup del log. Il database viene recuperato in corrispondenza di questo punto, creando un nuovo fork di recupero. Il database viene quindi utilizzato per un certo periodo di tempo e vengono creati altri due backup del log delle transazioni, ovvero i backup 5 e 6.
Il backup del database e i primi quattro backup dei log si trovano tutti sul ramo 1. Il quinto e il sesto backup del log si trovano sul ramo 2. Il fork di recupero contiene l'ultimo LSN del secondo backup del log (Log_Backup_2.LastLSN) e il primo LSN del quinto backup del log (Log_Backup_5.FirstLSN).
All'interno del quinto backup del log, first_recovery_fork_guid identifica il ramo 1 e last_recovery_fork_guid identifica il ramo 2. Il percorso di recupero è ramo 1, ramo 2.
[!NOTA] Il ripristino fino alla fine di un backup del log non è obbligatorio per la creazione di un nuovo percorso.
Per eseguire un ripristino e un rollforward su un vecchio percorso
È consigliabile evitare di utilizzare un percorso di recupero precedente, in quanto tale utilizzo determina l'inclusione nel database di transazioni di cui è stato eseguito il commit in due intervalli di tempo diversi. Tuttavia, se necessario, è possibile eseguire il rollforward mediante un percorso di recupero precedente seguendo la sequenza di backup eseguiti prima della creazione del percorso di recupero corrente. Ad esempio, è possibile utilizzare i backup eseguiti prima di un recupero temporizzato, in modo da raggiungere i punti desiderati del vecchio percorso.
[!NOTA] Per creare due database da un predecessore comune, per ogni database considerare il percorso di recupero che è necessario utilizzare per raggiungere la fine del database.
Ad esempio, in base ai backup creati nella figura precedente, dopo la creazione del quinto e del sesto backup del log, è sempre possibile eseguire il ripristino fino alla fine del terzo backup del log, che rappresenta il percorso di recupero precedente.
Per ripristinare ed eseguire il rollforward di un percorso completo precedente su un nuovo percorso
Motore di database di SQL Server impedisce l'utilizzo, da parte di una singola sequenza di ripristino, dei backup non compatibili tra loro, ovvero che tentano di eseguire il rollforward su percorsi di recupero diversi. Tale limitazione consente di mantenere la coerenza di un database dopo un recupero.
Per eseguire un ripristino e un rollforward su un nuovo percorso di recupero, creare sequenze di ripristino distinte per i backup precedenti al punto di recupero e per i backup successivi al punto di recupero:
- Ripristinare i backup eseguiti prima del recupero che ha preceduto il nuovo percorso di recupero. Escludere il backup che include il punto di recupero.
- Eseguire il rollforward sul nuovo percorso di recupero ripristinando i backup eseguiti dal momento della creazione del percorso di recupero.
Ad esempio, in base ai backup creati nella figura precedente, si supponga che il terzo backup del log sia relativo all'intervallo di tempo tra le 10.00 e le 11.00. È stato eseguito un ripristino temporizzato che specifica STOPAT**=10:**30. Questo ha creato il percorso di recupero e avviato un nuovo ramo di recupero, il ramo 2. Il primo backup del log sul nuovo ramo, il quinto backup del log, include lo stesso LSN del terzo backup del log, in sostituzione del terzo backup del log, ora inattivo. Per ripristinare i backup sul nuovo percorso di recupero (a partire dal ramo 1 fino al ramo 2), la sequenza di recupero è: backup completo del database, primo backup del log, secondo backup del log, quinto backup del log e sesto backup del log.
Gestione dei fork di recupero
Un ramo di recupero è un intervallo di numeri di sequenza del file di log (LSN) che condividono lo stesso GUID. Un percorso di recupero descrive un intervallo di numeri di sequenza del file di log da un punto di inizio (LSN,GUID) a un punto di fine (LSN,GUID). È possibile che l'intervallo di numeri di sequenza del file di log attraversi uno o più rami di recupero dall'inizio alla fine. Un nuovo ramo di recupero viene generato quando si crea un database e quando RESTORE WITH RECOVERY genera un fork di recupero.
Un fork di recupero è il punto (LSN,GUID) in cui inizia un nuovo ramo di recupero, ogni volta che si esegue RESTORE WITH RECOVERY. Ogni fork di recupero determina una relazione padre-figlio tra i rami di recupero.
Il recupero del database imposta l'intero stato del database, incluso l'LSN successivo, sul punto di recupero. Gli LSN vengono quindi riutilizzati, a partire da fork_point_lsn. Quando si crea una sequenza di ripristino, pertanto, è necessario che i backup siano collegati tramite fork di recupero e tramite LSN, in quanto è possibile che lo stesso LSN esista su più fork. Nella figura seguente viene illustrato il riutilizzo degli LSN. Essa mostra in che modo gli LSN vengono riutilizzati nei diversi fork di recupero.
Se è necessario che una sequenza di ripristino incorpori i backup che attraversano un fork di recupero, la sequenza di ripristino dovrà essere creata in modo che i backup utilizzati seguano il percorso di recupero corretto fino al punto di recupero. A tale scopo, i backup includono backupset.first_recovery_fork_guid e backupset.last_recovery_fork_guid, che consentono di collegare i backup, in modo da assicurare che la sequenza segua il fork corretto.
I valori nella tabella di cronologia backupset consentono di determinare quale set di backup utilizzare:
- Per ogni backup del log nella sequenza da ripristinare, first_recovery_fork_guid deve essere uguale a last_recovery_fork_guid del backup precedente nella sequenza.
- È inoltre necessario collegare i backup di dati e differenziali.
Se il backup del log include sia l'ultimo LSN di un backup completo del database o un backup differenziale del database sia un punto di fork, il test di collegamento dipende dal percorso dell'ultimo LSN rispetto al punto di fork.
I test di collegamento sono i seguenti, utilizzando i valori di backupset:- Se last_lsn è minore o uguale a fork_point_lsn, last_recovery_fork_guid del backup di dati o differenziale deve essere uguale a first_recovery_fork_guid del backup del log. Nella figura seguente viene illustrato un caso in cui last_lsn è minore di fork_point_lsn.
- Se last_lsn è maggiore di fork_point_lsn, last_recovery_fork_guid del backup di dati o differenziale deve essere uguale a last_recovery_fork_guid del backup del log. Nella figura seguente viene illustrato un caso in cui last_lsn è maggiore di fork_point_lsn.
- Se last_lsn è minore o uguale a fork_point_lsn, last_recovery_fork_guid del backup di dati o differenziale deve essere uguale a first_recovery_fork_guid del backup del log. Nella figura seguente viene illustrato un caso in cui last_lsn è minore di fork_point_lsn.
- Per un backup differenziale, è possibile individuarne la base utilizzando backupset.differential_base_guid.
Se il backup differenziale include più basi, backupset.differential_base_guid è NULL ed è necessario determinare le basi del backup differenziale per ogni file utilizzando backupfile.differential_base_guid.
Vedere anche
Concetti
Copia di database tramite backup e ripristino
Pianificazione ed esecuzione di sequenze di ripristino (Modello di recupero con registrazione completa)
Introduzione ai numeri di sequenza del file di log
Numeri di sequenza del file di log e pianificazione del ripristino
Base di un backup differenziale
Altre risorse
Implementazione degli scenari di ripristino per database di SQL Server