Riparazione di pagine incoerenti nel database

Abbiamo un database SQL 2000. Il server si è bloccato a causa di un errore dell'array Raid. Ora quando eseguiamo DBCC CHECKDB, riceviamo un errore che ci sono 27 errori di coerenza in 9 pagine.

Quando eseguiamo DBCC PAGE su queste pagine, otteniamo questo:

Msg 8939, Level 16, State 106, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (m_freeCnt == freeCnt) failed. Values are 2 and 19.
Msg 8939, Level 16, State 108, Line 1
Table error: Object ID 1397580017, index ID 2, page (1:8404521). Test (emptySlotCnt == 0) failed. Values are 1 and 0.

Poiché l'indice indicato non è un cluster ed è creato da una costante unica che include 2 colonne, abbiamo provato a eliminare e ricreare l'indice. Ciò ha comportato il seguente errore:

CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is '3280'. 
The statement has been terminated.

Comunque in esecuzione

Select var_id,result_on
from tests
group by var_id,result_on
having count(*)>1

restituisce 0 righe.

Ecco cosa stiamo programmando di fare:

Ripristinare una copia di crash pre-server del DB ed eseguire DBCC CHECKDB
Se restituisce pulito, ripristina nuovamente senza recupero
Applicare tutti i backup TLOG equivalenti
Arresta l'app di produzione, esegui un backup del registro di coda e applica anche quello
Rilasciare il DB prod e rinominare il DB appena ripristinato per renderlo prod
Avvia l'app prod

Qualcuno potrebbe fare dei buchi in questo approccio? Forse, suggerire un approccio diverso? Ciò di cui abbiamo bisogno sono tempi di fermo minimi.

Dimensione database SQL 2000 94 GB La tabella con pagine danneggiate ha 460 milioni + righe di dati

Grazie per l'aiuto.

Raj

sql-server dbcc

Mi piace il tuo approccio. È sensato per me. Forse tieni il database danneggiato a fianco, come assicurazione ...

— user24161

Inoltre, quando le cose si sistemano, pianifica l'aggiornamento del 2008 o del 2008 :-)

— user24161

( ovvero aggiornamento 2005 o 2008)

— user24161

+1 per avere un piano di recupero valido e molto adatto

— Andrew

Risposte:

La soluzione di recupero è il modo per procedere con il libro di testo. Supponendo di disporre di backup adeguati e purché sia possibile eseguire il backup del registro delle transazioni per il database corrotto, la strategia è quella del libro di testo da implementare.

Prima di procedere, tuttavia, hai considerato la possibilità di ricreare solo la tabella interessata?

A volte puoi cavartela creando una copia esatta della tabella interessata facendo un

select *
into NewTableFromOld
from DamagedTable

Quindi rilascia / scambia la tabella danneggiata con la nuova, ricordando di aggiungere vincoli e indici appropriati.

— John Sansom
fonte

Grazie per la risposta. L'approccio sembra buono, ma la preoccupazione è che, considerando che la tabella ha 461 milioni di righe di dati, quale sarebbe l'impatto sulla produzione quando seleziono *? Non sarebbe questo un colpo di grazia e avrebbe colpito le prestazioni?

Non se si utilizza il suggerimento query con (nolock) n. Tuttavia, potresti voler confermare che non è cambiato nulla tra la tabella di origine e quella di destinazione mentre hai preso la copia. Ciò sarebbe probabilmente necessario durante la compilazione della tabella, tuttavia se non si impediva all'app di apportare modifiche. Ci sarà un sovraccarico di prestazioni del disco in tale operazione.

— John Sansom,

Personalmente proverei prima questo approccio, puoi farlo con l'opzione nolock per i test, puoi anche controllare il tempo richiesto. Se funziona come dovrebbe, metterei il db in modalità utente singolo mentre lo faccio di nuovo, per assicurarmi che non si verifichino cambiamenti mentre il processo è in esecuzione. I downtime saranno molto più brevi durante questo approccio, se funziona.

— calvo

Se hai intenzione di farlo, ti consiglio di creare prima la tabella (scrivendo la tabella originale). Quindi utilizzare "INSERT INTO newTable SELECT" rispetto a "SELECT INTO". È possibile riscontrare problemi di prestazioni con un "SELEZIONA IN".

— SQL3D,

Proverei prima a scaricare i dati da archiviare e poi a ricollegarli a una nuova tabella. SELECT INTO non è appropriato (IMO) per quel numero di record ...

— m4rty
fonte