DBCC CHECKDB Not Run Recently

Quando SQL Server scrive dati sulle unità, presume che tutto sia a posto fino a quando non ha bisogno di leggere nuovamente i dati.

Purtroppo, in caso di corruzione dello storage, lo storage non è così gentile da avvisare SQL Server. E a volte, SQL Server è stato persino conosciuto per corrompere se stesso.

Abbiamo bisogno di controllare periodicamente per assicurarci che i dati sul disco abbiano ancora senso, ed è qui che entra in gioco DBCC CHECKDB. Controlla sia gli errori di allocazione che quelli di coerenza. Inoltre, se ci sono problemi, i messaggi di errore ritornano con informazioni su dove si trovano gli errori, la gravità dell’errore e l’opzione di riparazione suggerita.

È essenziale eseguire CHECKDB su base regolare per trovare gli errori, se esistono, perché se c’è corruzione, dobbiamo correggerla prima che i nostri ultimi buoni backup spariscano.

Per trovare il problema, controlliamo ogni database per assicurarci che DBCC CHECKDB abbia completato con successo un controllo nelle ultime due settimane.

Non ci credi?

“Ma io eseguo CHECKDB tutto il tempo”, potresti dire – beh, scopriamolo:

Transact-SQL

1
DBCC DBINFO(‘StackOverflow’) WITH TABLERESULTS

Ecco. Ma l’output è un incubo. Sono circa 80 righe di roba che probabilmente non vi interesserà mai. Intorno alla linea 50 c’è quello che state cercando.

Ciao, sono una sciocchezza.

E questo è probabilmente quello che vedrete! Una data di 1900-01-01 ecc. Questo significa mai. Se esegui DBCC CHECKDB sul database, forse così:

Transact-SQL

1
DBCC CHECKDB(‘StackOverflow’) WITH NO_INFOMSGS, ALL_ERRORMSGS

E poi eseguire nuovamente il comando DBCC DBINFO, la nostra data è ora aggiornata alla corrente:

Guarda quanto ci stiamo divertendo

Se la data non si aggiorna, ciò significa una delle due cose: SQL Server non può scrivere sul database (come se fosse di sola lettura), o sta trovando degli errori (hoowee, non va bene.)

Per risolvere il problema

Decidere se si desidera utilizzare i piani di manutenzione integrati, o uno strumento gratuito come gli script CHECKDB gratuiti di Ola Hallengren. Un paio di considerazioni:

  • I piani di manutenzione hanno un’interfaccia grafica, nel caso in cui non si conosca il T-SQL.
  • Gli script gratuiti di Ola Hallengren si occupano di opzioni di regolazione fine, come l’esecuzione automatica dei controlli di purezza dei dati (che è una buona cosa).

Come impostare la manutenzione regolare per controllare la corruzione

Opzione 1: usare un piano di manutenzione per eseguire DBCC CHECKDB

Se stai usando piani di manutenzione, puoi modificare i piani di manutenzione in SQL Server Management Studio sotto Gestione, Piani di manutenzione. Il tuo server potrebbe avere più piani di manutenzione che eseguono CHECKDB per diversi tipi di database, come uno per i database di sistema e uno per i database utente.

Espandi il nodo Gestione in SSMS, fai clic destro su Piani di manutenzione e seleziona Nuovo piano.

Dalla finestra Toolbox, che a volte viene nascosta sulla sinistra, trascinate il Check Database Integrity Task sulla scheda Maintenance Plan.

Quando fate doppio clic sulla casella Check Database Integrity Task nella scheda Maintenance Plan, sarete in grado di scegliere quali database volete far controllare durante il processo.

Da lì, tutto ciò che rimane è la pianificazione, che è proprio come la pianificazione di un lavoro Agent.

Dopo aver salvato e chiuso il piano di manutenzione, assicuratevi di trovare il relativo lavoro nel SQL Server Agent e impostare le proprietà di notifica per far sapere a un operatore se fallisce.

Opzione 2: Impostare i lavori dell’agente SQL per eseguire DBCC CHECKDB usando gli script gratuiti di Ola Hallengren

E se state implementando i controlli di integrità per la prima volta, considerate di usare gli script di manutenzione gratuiti di Ola Hallengren. Non sono facili come i piani di manutenzione, ma sono molto più flessibili. Includono anche la possibilità di suddividere le operazioni DBCC in pezzi più piccoli per i grandi database. Su database molto grandi CHECKDB può richiedere una quantità significativa di tempo e risorse – l’opzione WITH PHYSICAL_ONLY è più veloce, ma omette i controlli logici.

Una volta che i lavori dell’agente sono a posto, è possibile pianificarli per eseguirli semplicemente come i piani di manutenzione, o è possibile metterli a punto con le opzioni aggiuntive documentate qui.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.