Ripristino della pagina online con un limite di 1000

Mi è stato assegnato il compito di provare a ripristinare un database che ha subito un danneggiamento (a causa di un errore I / O, che è stato corretto da allora). Non ho familiarità con il database o cosa contiene.

Mi è stato dato un vecchio backup completo (~ 3 settimane) e una serie di registri delle transazioni ... tuttavia mancano i registri delle transazioni, quindi posso recuperare solo fino a una certa data. Mancano circa 2,5 settimane di dati mancanti (e molti dati vengono aggiunti costantemente a questo database).

Mi è stata anche data una copia del database corrotto (che è accessibile, ma con molte pagine corrotte / mancanti).

Ho provato i DBCC CHECKDBcomandi tipici (ancora no repair_allow_data_loss, sarà la mia ultima risorsa se non funzionasse nient'altro).

Dopo che molti vanno e vengono nel database (il db è un piccolo mostro da 1,5 terabyte e tutto ciò che faccio è lento e richiede un po 'di tempo), ho provato a fare un ripristino della pagina online dall'ultimo buon backup noto per le pagine corrotte.

Per fare ciò, ho realizzato uno script che crea molti RESTORE DATABASE <foo> PAGE='pages' FROM DISK='<bar.bak>'comandi DBCC CHECKDBdall'output (básically una regex e un distinto) ... finora tutto bene, ha funzionato fino al punto in cui diceva che avevo raggiunto un limite di 1000 pagine per file (ci sono 8 file su questo db) per comando di ripristino.

Quindi mi chiede di "completare il ripristino online", ma non riesco a farlo ... Non ho un registro di coda o qualcosa di più completo del backup completo con cui sto iniziando, quindi Fondamentalmente non so come completare il ripristino per continuare a provare con il resto delle pagine.

Ho provato un RESTORE DATABASE <foo> WITH RECOVERYma che non ha funzionato neanche, mi chiede un registro che non ho.

Qualcuno ha qualche consiglio su come potrei provare a recuperare qualcosa da qui? O come "completare" il ripristino online in modo da poter continuare a provare a recuperare più pagine? Avrei lo stesso problema se provassi un ripristino offline (fondamentalmente aggiungendo WITH NORECOVERYtutto e poi provando a riportarlo alla fine?)

Elaborare il database a mano è praticamente annullabile ... ci sono centinaia di tabelle con milioni di righe e non c'è un chiaro significato di ciò che è. Il DB corrotto non funzionerà nelle SELECTquery dopo alcuni milioni di righe, ma non sono sicuro di riuscire a capire dove. Ho provato a ricostruire tutti gli indici non cluster, ma ci sono pagine corrotte con dati di riga, quindi non ha funzionato neanche.

Una certa perdita di dati sarebbe accettabile, ma la coerenza sul DB dovrebbe almeno tentare di essere raggiunta.

Il database corrotto è -still- online e i client ci stanno lavorando (quindi continua a ricevere nuovi dati), quindi qualsiasi processo che faccio sul banco di laboratorio dovrebbe essere riproducibile sul database di produzione in seguito (i tempi di inattività saranno difficili).

Questa è SQL Server 2014 Enterprise

PS: non sono un DBA ... sono un programmatore, ma il cliente ha provato alcuni servizi di "disaster recovery" sql "esperti" e hanno rinunciato, quindi mi è stato chiesto di guardarlo e vedere se potevo Fai qualcosa.

Aggiornamento : dopo molti test, il ripristino pagina per pagina non ha funzionato, quindi abbiamo abbandonato l'idea. Stiamo andando per un ripristino manuale (selezionando manualmente i record mancanti dalle tabelle corrotte e inserendoli nell'ultimo backup valido noto), facendo alcuni strumenti automatici per esso (di nuovo, ci sono centinaia e centinaia di tabelle).

La procedura standard sarebbe:

1. Ottieni gli ID pagina che devono essere ripristinati.
2. Avviare un ripristino della pagina con un database completo.
3. Applica il backup differenziale più recente.
4. Applica backup di log successivi.
5. Crea nuovo backup del registro.
6. Ripristina il nuovo backup del lob.

Dopo aver applicato il nuovo backup del registro, il ripristino della pagina è completato e le pagine sono quindi utilizzabili.

Esempio di ripristino

RESTORE DATABASE <database> PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM <file_backup_of_file_B>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;  
RESTORE LOG <database> FROM <log_backup>   
   WITH NORECOVERY;   
BACKUP LOG <database> TO <new_log_backup>;   
RESTORE LOG <database> FROM <new_log_backup> WITH RECOVERY;  
GO  

Riferimento: Restore Pages (SQL Server) (Microsoft Docs) Riferimento: RESTORE Dichiarazioni (Transact-SQL) (Microsoft Docs)

Tuttavia, sono presenti buchi nei backup TLOG e il ripristino con la procedura sopra descritta potrebbe riportare il database in uno stato nel tempo che non si desidera.

Sei in una situazione complicata.

1. Il tuo database ha pagine corrotte e la tua azienda aggiunge costantemente nuovi dati a un database con problemi. Ciò potrebbe comportare un tempo di inattività totale del database. Pensi che si vuole rischiare che?

2. Qualcuno sarà ritenuto responsabile e più si tenta di risolverlo, più gestione potrebbe essere incline a decidere che alla fine potresti essere quella persona. Pensi che si vuole rischiare che?

3. Ti stai mettendo in una situazione difficile assumendo un ruolo per il quale non sei stato assunto. Stai cercando di ottenere qualcosa che né i DBA della tua azienda né il tuo consulente esterno erano in grado di fare. Mentre può sembrare un gesto nobile, ti stai mettendo a rischio. Potresti aver "implicitamente promesso" qualcosa che non sarai mai in grado di soddisfare. Pensi che si vuole rischiare che?

4. Quando qualcuno che lavora con il database richiede dati danneggiati, probabilmente riceveranno un messaggio di errore. Il lavoro quotidiano è già influenzato. Più a lungo aspetti con l'inevitabile, maggiore sarà la produttività. Pensi che si vuole rischiare che? (Questa domanda potrebbe anche essere sollevata con la direzione)

5. La procedura di backup della tua azienda sembra essere difettosa (altrimenti come potrebbero mancare i backup TLOG?) E stai ancora eseguendo il tuo database di produzione come se non ci fossero problemi. Pensi che si vuole rischiare che?

La migliore raccomandazione che posso darti è di interrompere la produzione e chiamare Microsoft! O almeno chiama Microsoft e forse ferma la produzione.

Mentre la mia scrittura può sembrare eccessivamente cauta e leggermente drammatizzata dal tuo punto di vista, posso personalmente relazionarmi con un'esperienza come DBA in cui i dati sono stati persi in una situazione simile. Abbiamo perso solo mezza giornata di dati, ma abbiamo dovuto risincronizzare molti dati con i sistemi circostanti .

Più a lungo aspetti, potrebbe diventare più costoso il recupero.

Per quanto riguarda la limitazione sui ripristini di pagina, qui una citazione dalla documentazione ufficiale:

Il numero massimo di pagine che è possibile ripristinare in un singolo file in una sequenza di ripristino è 1000 . Tuttavia, se in un file sono presenti più di un numero limitato di pagine danneggiate, è consigliabile ripristinare l'intero file anziché le pagine.

^{( enfatizzare il mio)}

Riferimento: istruzioni RESTORE - Argomenti (Transact-SQL) (Microsoft Docs)

Quando tutto torna alla normalità, i DBA e / o i consulenti esterni potrebbero voler prendere in considerazione l'implementazione di una diversa politica / procedura di backup / ripristino per il database. Dato che deve essere 7x24 non puoi rischiare di avere una procedura di backup che non fornisca adeguate capacità di ripristino per ogni situazione.

Vedo che hai provato diversi metodi tra cui lavorare con "esperti" di recupero dati per riparare questo database corrotto, specialmente con dimensioni superiori a 1 TB. Questo rende il processo molto più difficile e una corsa contro il tempo. In qualità di DBA esperto, mi sono imbattuto in situazioni simili in cui la maggior parte delle volte sono disponibili buoni backup da ripristinare. In caso di eredità di backup errati e database corrotto, mi sono fortemente affidato a uno strumento di terze parti chiamato Stellar Phoenix SQL Database Repair tool . Questo strumento è rinomato per la riparazione di database corrotti (.mdf e .ndf). Di seguito sono riportate alcune funzionalità dello strumento:

• Ripara i file corrotti del database SQL (.mdf & .ndf)
• Recupera tabelle, trigger, indici, chiavi, regole e procedure memorizzate

• Esegue il ripristino dei record eliminati dal database SQL

• Salva i risultati della scansione del database per eseguire il ripristino in una fase successiva

• Consente il salvataggio dei file riparati nei formati MSSQL, HTML, XLS e CSV
• Supporta MS SQL Server 2016, 2014, 2012.2008 e versioni precedenti

Lo strumento richiede che i file .mdf e .ndf siano offline, quindi funziona alla grande se si dispone di una copia del database PROD danneggiato e non è necessario arrestare i servizi di SQL Server.

La parte migliore è che la versione di prova offre la piena funzionalità dello strumento, tranne per il fatto che il database riparato non può essere esportato / salvato. Saresti comunque in grado di visualizzare tutti gli oggetti del database recuperati e l'ampio file di registro delle riparazioni che fornisce dettagli sulle diverse fasi del processo di riparazione.

Sentiti libero di scaricare e vedi se aiuta. Scarica qui

Ho anche scritto un blog su come funziona lo strumento in questo sito: blog samosql

Grazie e HTH per renderti l'EROE della giornata!

PS. Al termine di questa tempesta, ricordarsi di dire alla direzione che è necessario eseguire una revisione sostanziale delle procedure di backup, specialmente per tale database. Una ripetizione di questo scenario è totalmente inaccettabile! :)