Il primo passaggio consiste nell'analizzare le colonne della vista del catalogo contenenti i numeri di sequenza del file di log di rollforward redo_start_lsn, redo_start_fork_guid, redo_target_lsn e redo_target_fork_guid. Nella tabella seguente vengono descritti gli LSN di rollforward e viene spiegato come interpretarli.

Colonne	Descrizione
redo_start_lsn e redo_start_fork_guid	Insieme, queste colonne descrivono una coppia (lsn,guid) che rappresenta il punto nel tempo del file. Dopo il rollforward del file, i valori di queste colonne variano. Il rollforward continua da tale punto. Importante: Se redo_start_lsn = NULL, lo stato su disco del file è sconosciuto ed è necessario ripristinare il file da un backup completo.
redo_target_lsn e redo_target_fork_guid	Insieme, queste colonne descrivono una coppia (lsn,guid) che definisce il punto di recupero in base al quale è necessario ripristinare il file per garantirne la consistenza con il database in linea, ovvero il punto di recupero di destinazione.

Le viste del catalogo sys.database_files e sys.master_files contengono entrambe le colonne relative al numero di sequenza del file di log di rollforward, ma non sempre sono consistenti. In genere, se il database è in linea, i valori di sys.database_files e sys.master_files sono consistenti. I valori sono tuttavia inconsistenti nelle situazioni seguenti:

• Se il database è di sola lettura, la vista del catalogo sys.database_files non viene aggiornata con eventuali modifiche provocate dal backup e le informazioni aggiornate sono presenti solo nella vista del catalogo sys.master_files.
  

  Nota:
  Per sapere se un file è di sola lettura, analizzare le colonne is_read_only e read_only_lsn. is_read_only indica che il file è di sola lettura. In questo caso, la colonna read_only_lsn indica il punto in cui il file ha assunto tale stato.

• Se il database è in modalità non in linea, ad esempio durante il suo ripristino, non è possibile accedere al catalogo del database. Nel caso di un database non in linea, per ottenere informazioni è necessario utilizzare la vista del catalogo sys.master_files.
  
• Se vi è un'operazione di ripristino che influisce sul file, è in corso l'aggiornamento degli LSN di rollforward del file, che pertanto sono inconsistenti. È quindi consigliabile analizzare le colonne relative all'LSN di rollforward solo tra due operazioni di ripristino.
  

Nota:
Questa sezione presuppone una conoscenza dei concetti di percorso di recupero e fork di recupero. Per ulteriori informazioni, vedere Percorsi di recupero.

Questa sezione è rilevante solo se è stato eseguito un ripristino temporizzato e sono ancora presenti backup da percorsi di recupero inattivi. I fork di recupero sono rilevanti quando si ripristina un file in stato di ripristino, in attesa di recupero o non in linea. Analizzando i fork di recupero, è possibile identificare i percorsi di recupero potenziali. In genere, vi è un percorso di recupero che è chiaramente il più appropriato per il recupero del database.

Per identificare tale percorso, è necessario verificare se il file si trova nel fork di recupero di destinazione o in un fork di recupero diverso:

• Il file si trova in un fork di recupero diverso.
  Se redo_start_fork_guid != redo_target_fork_guid e non è un predecessore di redo_target_fork_guid, il file si trova in un fork di recupero diverso da quello di destinazione.
  

  Nota:
  Per individuare un fork predecessore, risalire a ritroso la catena di log. Per ulteriori informazioni, vedere Percorsi di recupero.

  In questo caso, è necessario ripristinare il file da un backup completo. Mediante tale ripristino, il file verrà posizionato in un punto che rappresenta un predecessore valido del punto di recupero corrente del database.
  

  Nota:

  Per ripristinare qualsiasi file, è necessario che il relativo backup sia un predecessore del punto di recupero del database. Cercare sempre il backup completo più recente del file. È necessario eseguire il rollforward dei dati fino al punto di destinazione. L'unica eccezione è costituita dal backup di un file di sola lettura, in quanto se il file era di sola lettura anche prima di eseguire il backup, non è necessario eseguire il rollforward. Se necessario, dopo aver ripristinato il backup del file ripristinare un backup differenziale del file, se presente, e i backup del log, per portare il file al punto di recupero di destinazione.

• Il file si trova nel fork di recupero di destinazione corrente o è un predecessore di tale fork.
  

  Nota:
  Se il backup del file è stato eseguito dopo il recupero del database, il file si trova nel fork di recupero di destinazione.

  In questi casi, il ripristino del file può essere necessario o meno a seconda della relazione tra redo_start_lsn e redo_target_lsn, come illustrato nella tabella seguente.
  

  Relazione	Necessità di ripristino
  redo_start_lsn = redo_target_lsn	Non è necessario ripristinare il file. Il file è consistente con il database ed è possibile portarlo in linea senza utilizzare RESTORE DATABASE database_name WITH RECOVERY.
  redo_start_lsn < redo_target_lsn	Prima di poter portare in linea il file, il rollforward deve raggiungere redo_target_lsn.
  redo_start_lsn > redo_target_lsn	Il database è precedente al file. È necessario ripristinare il file da un backup completo oppure è possibile ripristinare nuovamente il database fino a un punto nel tempo successivo con un'altra sequenza di ripristino parziale. Nota: Questa situazione può verificarsi solo per un ripristino non in linea in quanto, subito dopo il recupero del filegroup primario, viene generato un nuovo fork di recupero. I filegroup secondari non recuperati non si trovano più nello stesso percorso di recupero del filegroup primario.

Nota:
Dopo aver ripristinato i backup per uno o più di questi percorsi di recupero, i percorsi di recupero alternativi non sono più validi. I backup specifici di un percorso di recupero non valido diventano inattivi. È consigliabile eliminare i backup inattivi oppure spostarli e contrassegnarli chiaramente come inattivi.

Concetti

Altre risorse

Guida e informazioni