Impossibile ripristinare (errore 3456)

Ho una situazione che non è facile da capire e ho pensato di chiedere a questo forum se altri potessero avere dei suggerimenti.

Sto eseguendo SQL Server 2008 R2 Standard SP3 su Windows Server 2008R2 Enterprise.

Un database aveva bisogno di un po 'di manutenzione e dopo il fatto avevo bisogno di ripristinare su un altro server. Ho eseguito un backup completo del db con COPY_ONLY e un set di 4 backup di tlog.

prima di iniziare, crea tlogbackup1
passare da FULLal BULK_LOGGEDmodello di recupero
aggiungi nuovo filegroup
aggiungi il file a newfilegroup
imposta newfilegroup come predefinito
seleziona in tabella (su newfilegroup)
rilasciare la tabella originale
elimina il file originale
elimina il filegroup originale
cambia il nome della nuova tabella in modo che corrisponda alla tabella originale
cambia il nome del file di newfilegroup in modo che corrisponda al filegroup originale
cambia il nome del file nel catalogo in modo che corrisponda al nome del file originale
cambia il nome del file a livello di sistema operativo in modo che corrisponda al nome del file originale
imposta il filegroup predefinito come originale
portare online db
passare da BULK_LOGGEDal FULLmodello di recupero
Dopo aver completato tutti i passaggi, creare tlogbackup2

Il ripristino di tutti i backup deve utilizzare WITH MOVE, a causa delle modifiche delle lettere di unità sul server di ripristino.

Passaggi di recupero:

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

Il ripristino finale di tlog arriva al 100% e quindi non riesce con errore 3456:

368 pagine elaborate per il database "SomeDB", file "SystemData" sul file 1.

Elaborate 7656520 pagine per il database "SomeDB", file "SystemDataPDS" sul file 1.

172430 pagine elaborate per il database "SomeDB", file "SystemData_log" sul file 1.

Messaggio 3456, livello 16, stato 1, riga 1
Impossibile ripetere il registro (210388: 123648: 232), per ID transazione (0: 1016710921), a pagina (4: 8088), database 'SomeDB' (ID database 6) . Pagina: LSN = (0: 0: 1), tipo = 11. Log: OpCode = 4, contesto 11, PrevPageLSN: (210388: 122007: 1). Ripristinare da un backup del database o ripristinare il database. Messaggio 3013, livello 16, stato 1, riga 1 RIPRISTINA LOG si sta chiudendo in modo anomalo.

Solo per verificare che il backup completo del db fosse corretto, l'ho ripristinato CHECKDBe non si sono verificati errori.

Tutti i feedback sono stati ben accolti.

Grazie in anticipo,

Lontra di Ned

— NedOtter
fonte

Potresti approfondire il motivo per cui pensi di avere una catena di tronchi ininterrotta? Nel momento in cui hai attivato il database in modalità BULK_LOGGED e hai iniziato a fare confusione con lo schema, tutte le scommesse sull'interruzione della catena di log sono disattivate.

— Thomas Kejser,

Grazie per la tua risposta, Thomas. Vedo ora che il titolo del mio post non era corretto. Non ho bisogno di un ripristino temporizzato, ma di un ripristino completo fino alla fine del quarto backup del tlog. Quindi l'impostazione di BULK_LOGGED non avrebbe dovuto causare alcun problema. Non vedo come ciò che ho fatto avrebbe causato il fallimento del secondo backup di tlog: tutti i comandi erano supportati da SQL Server e ho eseguito gli stessi identici passaggi (anche se non sugli stessi dati) su un database più piccolo, ed è stato in grado per ripristinare il secondo backup di tlog senza problemi.

— NedOtter,

L'errore sembra corruzione. È un errore interno. Puoi verificare l'integrità di tutti i file di backup? Sono con checksum?

— usr

Ho verificato che il backup completo del db avesse 0 errori eseguendo CHECKDB. Dovrò verificare se è stato utilizzato CHECKSUM.

— NedOtter,

Se i backup hanno checksum abilitato, è necessario utilizzare anche checksum per il ripristino. Il tipo di pagina 11 è una pagina PFS, il che significa che non è possibile correggerlo, è possibile eseguire solo un ripristino completo. Inoltre, non dici quando è stata eseguita la copia solo del backup. Dov'era quel backup nella linea del tempo?

— Robert L Davis,

Per capire perché verrebbe generato l'errore 3456, è necessario fare un piccolo passo indietro e capire come SQL Server gestisce questo angolo di recupero.

Quando SQL Server sta eseguendo una ripetizione di un'operazione e tale ripetizione è una modifica della pagina, esegue un controllo rapido. Nell'intestazione della pagina alla fine ci sarà un PageLSN, che è un'indicazione dell'ultimo LSN che ha modificato quella pagina, registrata dalla pagina. Pensaci in questo modo, la pagina tiene traccia dell'ultimo LSN che ha apportato modifiche ad esso. Questo è il PageLSN.

Ogni volta che viene eseguita un'operazione di modifica della pagina registrata, quel record di registro include alcuni LSN. Vale a dire, l'LSN del record di registro (pensa ... LSN attuale ), e quindi ha quello che viene chiamato LSN della pagina precedente ( PrevPageLSNandando avanti). Pertanto, quando modifichiamo una pagina, uno dei dati inseriti nel record del registro è ciò che la pagina indica come l' ultimo LSN prima che tu abbia modificato la pagina .

Pensaci in questo modo ... La tua auto deve avere del lavoro fatto su di essa. Il meccanico John lavora sulla tua auto e nel vano motore ha un piccolo tag e il meccanico John scrive "John ha lavorato su questa macchina per ultimo". Quindi la prossima volta che porti la tua macchina in un altro negozio, il meccanico Mark guarda nel vano motore e vede che il meccanico John ha lavorato per ultimo su questa macchina. Sulla sua scheda tecnica scrive queste informazioni. Stessa idea con SQL Server.

Questo può essere un po 'di confusione, in modo da dare un'occhiata a questa immagine in basso a modifiche di pagina sequenziali, e come l' PageLSNe PrevPageLSNrelazionarsi:

inserisci qui la descrizione dell'immagine

Torniamo indietro, poiché tutto ciò entra in gioco quando è necessario ripetere un'operazione su una pagina (ripristini, ripristino, HA, ecc.). Quando SQL Server deve ripetere un'operazione sulla pagina, esegue un controllo di integrità per vedere se PageLSNnella pagina corrisponde a PrevPageLSNquello incluso nel record del registro. Se ciò non è uguale, verrà visualizzato l'errore 3456.

Non PageLSN uguale PrevPageLSN ? No??? Arresta e solleva l'errore 3456 ...

Analizziamo il tuo messaggio di errore, che include come:

Impossibile ripetere il record del registro (210388: 123648: 232), per ID transazione (0: 1016710921), a pagina (4: 8088), database 'SomeDB' (ID database 6). Pagina: LSN = (0: 0: 1) , tipo = 11. Log: OpCode = 4, contesto 11, PrevPageLSN: (210388: 122007: 1) . Ripristinare da un backup del database o ripristinare il database. Messaggio 3013, livello 16, stato 1, riga 1 RIPRISTINA LOG si sta chiudendo in modo anomalo.

Ho messo in grassetto i due pezzi di dati che hanno una disuguaglianza che causa l'errore. Puoi vedere che il nostro PageLSNè 0: 0: 1 (questo è stato trovato nell'intestazione della pagina) e il nostro PrevPageLSNè 210388: 122007: 1 (questo è stato trovato nei dati sul record del registro che stava tentando di essere rifatto). Questi ovviamente non sono uguali, quindi err3456.

Quindi, al fine di scoprire il perché di questo evento, sarebbe scoprire perché c'è una disparità qui. Dobbiamo davvero tracciare il ciclo di vita di pagina 4: 8088 e vedere dove si trova la disconnessione. Sfortunatamente senza ulteriori informazioni o risoluzione dei problemi pratici non c'è molto altro che posso fare oltre a fornirti lo sfondo di questa operazione di recupero e ciò che causa l'errore.

— Thomas Stringer
fonte

So che è passato un po 'ma comunque ... cose buone, grazie per la spiegazione approfondita!

— RThomas,