DBCC CHECKDB: Πλήρης οδηγός για την MS SQL Server Εύρυθμη λειτουργία βάσης δεδομένων (2025)

Η καταστροφή της βάσης δεδομένων είναι πανταχού παρούσα SQL Server εφιάλτης του διαχειριστή. Όταν τα κρίσιμα επιχειρηματικά δεδομένα καθίστανται απρόσιτα ή αναξιόπιστα, το cost μπορεί να είναι καταστροφικό. Αυτός ο ολοκληρωμένος οδηγός καλύπτει όλα όσα πρέπει να γνωρίζετε σχετικά με τη χρήση του DBCC CHECKDB για τη διατήρηση της εύρυθμης λειτουργίας της βάσης δεδομένων και την πρόληψη της καταστροφής, καθώς και προηγμένες λύσεις αποκατάστασης για όταν τα τυπικά εργαλεία δεν επαρκούν.

1. Η σημαντικοτητα του SQL Server Εύρυθμη λειτουργία βάσης δεδομένων

1.1 Τι είναι η διαφθορά βάσης δεδομένων CostΕπιχειρήσεις

Σήμερα, μ.ost Οι επιχειρήσεις αποθηκεύουν τα κρίσιμα δεδομένα τους σε βάσεις δεδομένων. Όταν συμβαίνει καταστροφή της βάσης δεδομένων, οι συνέπειες είναι καταστροφικές:

• Οικονομικές απώλειες μέσος όρος 2.3 εκατομμυρίων δολαρίων ετησίως λόγω απώλειας δεδομένων, με τις αστοχίες υλικού και την καταστροφή να αποτελούν τις κύριες αιτίες (EMC Corporation)
• Ποσοστά κλεισίματος επιχειρήσεων δείχνουν ότι το 50% των μικρών επιχειρήσεων που αντιμετωπίζουν απώλεια δεδομένων λόγω βλαβών υλικού κλείνουν εντός δύο ετών, ενώ το 94% των επιχειρήσεων με καταστροφική απώλεια δεδομένων δεν επιβιώνουν καθόλου.
• Συχνότητα αλλοίωσης δεδομένων επηρεάζει το 20% των κρίσιμων εφαρμογών ετησίως, προκαλώντας διαταραχές στη συνέχεια της επιχειρηματικής δραστηριότητας (έρευνα Gartner)
• Διαφθορά που σχετίζεται με το υλικό ευθύνεται για το 67% όλων των περιστατικών απώλειας δεδομένων λόγω σφαλμάτων σκληρού δίσκου και βλαβών συστήματος, με το 40% της απώλειας δεδομένων να αποδίδεται άμεσα σε δυσλειτουργίες υλικού
• Διαφθορά λογισμικού costs κυμαίνονται από χιλιάδες έως εκατομμύρια δολάρια ανάλογα με τη σοβαρότητα και το εύρος, με το 82% των επιχειρήσεων να αντιμετωπίζουν απρογραμμάτιστες διακοπές λειτουργίας όπου η διαφθορά ήταν η κύρια αιτία

1.2 Γιατί οι τακτικοί έλεγχοι υγείας είναι κρίσιμοι

Οι άνθρωποι χρειάζονται τακτικούς ελέγχους υγείας για την έγκαιρη ανίχνευση πιθανών ασθενειών. Ομοίως, οι βάσεις δεδομένων χρειάζονται επίσης τακτικούς ελέγχους υγείας:

1. Εντοπίστε έγκαιρα πιθανές περιπτώσεις διαφθοράς και αντιμετωπίστε τις άμεσα, αποτρέποντας την εξάπλωση των προβλημάτων σε σοβαρό και εκτεταμένο επίπεδο, κάτι που θα μπορούσε να οδηγήσει σε καταστροφικές συνέπειες για την επιχείρηση.
2. Βεβαιωθείτε ότι η βάση δεδομένων λειτουργεί με βέλτιστη απόδοση.
3. Το γost Οι προληπτικοί έλεγχοι εύρυθμης λειτουργίας των βάσεων δεδομένων είναι πολύ χαμηλότεροι από αυτούς της αντιδραστικής ανάκτησης δεδομένων μετά από μια καταστροφή βάσης δεδομένων.

1.3 Εισαγωγή στις εντολές ακεραιότητας βάσης δεδομένων

SQL Server παρέχει αρκετές ενσωματωμένες εντολές για τη διατήρηση της εύρυθμης λειτουργίας της βάσης δεδομένων, με DBCC CHECKDB χρησιμεύοντας ως το μost Διατίθεται ένα ολοκληρωμένο εργαλείο ελέγχου ακεραιότητας. Αυτές οι εντολές συνεργάζονται για να επαληθεύσουν διαφορετικές πτυχές της δομής της βάσης δεδομένων σας, από μεμονωμένους πίνακες έως τη συνοχή ολόκληρης της βάσης δεδομένων, διαμορφώνοντας μια ολοκληρωμένη στρατηγική συντήρησης που διατηρεί τα δεδομένα σας ασφαλή και προσβάσιμα.

2. Τι είναι το DBCC CHECKDB

DBCC CHECKDB is SQL Serverείναι το κύριο εργαλείο για την επαλήθευση της ακεραιότητας της βάσης δεδομένων και τον εντοπισμό προβλημάτων διαφθοράς.

• Είναι μια πρόταση T-SQL, όχι ένα εργαλείο GUI.
• Μπορείτε να το εκτελέσετε μέσω κοινών μεθόδων, όπως π.χ. SQL Server Στούντιο Διαχείρισης (SSMS), SQL Server Πράκτορας, SQLCMD, κ.λπ.

2.1 Τι ελέγχει στην πραγματικότητα το CHECKDB στη βάση δεδομένων σας

Όταν εκτελείτε την εντολή DBCC CHECKDB, η εντολή εκτελεί πολλαπλά επίπεδα επικύρωσης σε όλη τη δομή της βάσης δεδομένων σας:

• Επαλήθευση αθροισμάτων ελέγχου σελίδας για την ανίχνευση φυσικής καταστροφής και προβλημάτων που σχετίζονται με το υλικό
• Επικύρωση συνέπειας ευρετηρίου για να διασφαλιστεί η σωστή ανάκτηση δεδομένων και η απόδοση των ερωτημάτων
• Έλεγχοι δομής κατανομής για να επιβεβαιώσετε την ακριβή χρήση χώρου και την κατανομή σελίδων
• Εξέταση ακεραιότητας αναφοράς μεταξύ σχετικών πινάκων και σχέσεων ξένου κλειδιού
• Επικύρωση συνέπειας πίνακα συστήματος για να εξασφαλιστεί SQL ServerΤα εσωτερικά μεταδεδομένα του παραμένουν αξιόπιστα
• Επαλήθευση σύνδεσης σελίδας δεδομένων για να επιβεβαιώσετε την ορθή ακεραιότητα της αλυσίδας σελίδων
• Συνέπεια σχήματος βάσης δεδομένων για την επικύρωση ορισμών και εξαρτήσεων αντικειμένων

Αυτοί οι ολοκληρωμένοι έλεγχοι καλύπτουν τόσο τα δεδομένα χρήστη όσο και τις δομές του συστήματος, παρέχοντας πλήρη εικόνα της κατάστασης εύρυθμης λειτουργίας της βάσης δεδομένων σας.

3. Εκτέλεση του DBCC CHECKDB: Βήμα προς βήμα

Προϋποθέσεις 3.1

Παρακάτω είναι η λίστα ελέγχου πριν από την εκτέλεση οποιασδήποτε λειτουργίας DBCC CHECKDB:

• Πλήρες αντίγραφο ασφαλείας της βάσης δεδομένων – Δημιουργήστε ένα πλήρες αντίγραφο ασφαλείας πριν εκτελέσετε ελέγχους ακεραιότητας ως δίχτυ ασφαλείας σε περίπτωση που εντοπιστεί καταστροφή ή καταστούν απαραίτητες οι εργασίες επιδιόρθωσης.
• Κατάλληλα δικαιώματα – Χρειάζεστε δικαιώματα sysadmin ή db_owner για να εκτελέσετε εντολές DBCC CHECKDB
• Επαρκείς πόροι συστήματος:
  • Μνήμη: 25% του μεγέθους της βάσης δεδομένων
  • Χώρος Tempdb: 10-15% του μεγέθους της βάσης δεδομένων
  • CPU: Διαθεσιμότητα 50-70% κατά τη συντήρηση
  • Είσοδος/Έξοδος: Αναμένεται εκτεταμένη ανάγνωση
• Προσβασιμότητα βάσης δεδομένων – Επαληθεύστε ότι η βάση δεδομένων σας είναι προσβάσιμη και δεν βρίσκεται σε κατάσταση περιορισμού, καθώς το CHECKDB απαιτεί πρόσβαση ανάγνωσης σε όλες τις σελίδες της βάσης δεδομένων

3.2 Βασική εντολή

Η μost Η βασική εντολή DBCC CHECKDB περιλαμβάνει τρεις συνηθισμένες παραλλαγές:

(1) Ελέγξτε την τρέχουσα βάση δεδομένων (χωρίς παραμέτρους):

DBCC CHECKDB

(2) Ελέγξτε μια βάση δεδομένων με βάση το όνομα:

DBCC CHECKDB ('YourDatabaseName')

(3) Ελέγξτε μια βάση δεδομένων με βάση το αναγνωριστικό:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

Αυτή η βασική εντολή εκτελεί έναν πλήρη έλεγχο ακεραιότητας της καθορισμένης βάσης δεδομένων, εξετάζοντας όλους τους πίνακες, τα ευρετήρια και τις δομές συστήματος. Για βάσεις δεδομένων με τυπικά ονόματα που δεν περιέχουν κενά, μπορείτε να παραλείψετε τα εισαγωγικά. Η εντολή θα εκτελείται μέχρι την ολοκλήρωσή της, εμφανίζοντας μηνύματα προόδου και τελικά αποτελέσματα. Αυτή η βασική σύνταξη λειτουργεί τέλεια για μικρότερες βάσεις δεδομένων ή όταν έχετε άφθονο διαθέσιμο χρόνο συντήρησης.

Παρακάτω είναι ένα στιγμιότυπο οθόνης από την εκτέλεση του DBCC CHECKDB σε SQL Server Management Studio (SSMS):

3.3 Πλήρεις επιλογές

Παρακάτω είναι οι πλήρεις επιλογές για το DBCC CHECKDB:

κατηγορία	Επιλογή	Περιγραφή	Παράδειγμα DBCC CHECKDB
Επιλογές επισκευής	REPAIR_REBUILD	Επισκευές χωρίς απώλεια δεδομένων (π.χ., ανακατασκευές ευρετηρίου)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Δεν απαιτείται επισκευή. Μόνο συμβατότητα με παλαιότερες εκδόσεις.	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Επιδιορθώνει όλα τα σφάλματα (μπορεί να προκαλέσει απώλεια δεδομένων)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Έλεγχος εμβέλειας	NOINDEX	Παραλείπει τους ελέγχους ευρετηρίου που δεν είναι ομαδοποιημένοι	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Ελέγχει μόνο την ακεραιότητα της φυσικής αποθήκευσης (σελίδες/εγγραφές)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Έλεγχοι για λογικά σφάλματα τιμών στήλης (π.χ., μη έγκυρες ημερομηνίες)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Βαθείς λογικοί έλεγχοι (προβολές με ευρετήριο, XML/χωρικά ευρετήρια)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Έλεγχος εξόδου	ALL_ERRORMSGS	Εμφανίζει όλα τα σφάλματα (προεπιλογή: 200 ανά αντικείμενο)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Αποκρύπτει ενημερωτικά μηνύματα	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
💪 Βελτίωση της απόδοσης στην άσκηση	TABLOCK	Χρησιμοποιεί κλειδώματα πίνακα (μειώνει τη χρήση του TempDB αλλά μπλοκάρει τις εγγραφές)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Παρακάμπτει τις ρυθμίσεις παραλληλισμού	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Χρησιμοποίηση	ESTIMATEONLY	Εκτιμήσεις χώρου TempDB που απαιτείται. (χωρίς πραγματικό έλεγχο)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Κατανόηση των αποτελεσμάτων σας

Το DBCC CHECKDB θα παράγει διαφορετικά αποτελέσματα ανάλογα με το αν η εκτέλεσή του ολοκληρώνεται με επιτυχία ή όχι. Ας τα εξηγήσουμε λεπτομερώς.

4.1 Η εκτέλεση του CHECKDB ολοκληρώνεται με επιτυχία

Εάν η εκτέλεση του DBCC CHECKDB ολοκληρωθεί με επιτυχία, θα αναφέρει διαφορετικούς τύπους αποτελεσμάτων ανάλογα με την κατάσταση εύρυθμης λειτουργίας της βάσης δεδομένων σας.

4.1.1 Δεν βρέθηκαν προβλήματα

Εάν το DBCC CHECKDB δεν εντοπίσει κανένα πρόβλημα, θα δείτε ένα αποτέλεσμα παρόμοιο με αυτό:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Αυτό το αποτέλεσμα υποδεικνύει ότι η βάση δεδομένων σας διατηρεί τέλεια ακεραιότητα σε όλες τις ελεγμένες δομές.

4.1.2 Εντοπισμένα σφάλματα διαφθοράς

Κάθε φορά που το DBCC CHECKDB εντοπίζει ένα σφάλμα καταστροφής, θα αναφέρει ένα μήνυμα σφάλματος με την ακόλουθη δομή:
Οδηγός Επιπέδου Σοβαρότητας:

• Επίπεδο 16-19: Σφάλματα που διορθώνονται από τον χρήστη, συχνά μικρές αλλοιώσεις
• Επίπεδο 20-24: Σφάλματα συστήματος, σοβαρή διαφθορά που απαιτεί άμεση αντιμετώπιση
• Επίπεδο 25: Μοιραία σφάλματα, η βάση δεδομένων ενδέχεται να μην είναι προσβάσιμη

Τα κοινά σφάλματα περιλαμβάνουν:

• Αποτυχίες αθροίσματος ελέγχου σελίδας (μήνυμα 824)
• Σφάλματα κατανομής (μήνυμα 8928)
• Προβλήματα συνέπειας ευρετηρίου (μήνυμα 8964)

Η κατανόηση της δομής του μηνύματος βοηθά στην ιεράρχηση των ενεργειών απόκρισης και στον προσδιορισμό των κατάλληλων στρατηγικών ανάκαμψης.

4.1.3 Συνήθη ενημερωτικά και προειδοποιητικά μηνύματα

Δεν υποδεικνύουν όλα τα αποτελέσματα του DBCC CHECKDB σοβαρά προβλήματα. Ενδέχεται επίσης να εμφανίζουν ορισμένα ενημερωτικά και προειδοποιητικά μηνύματα, όπως:

• Δηλώσεις επισκευής – Μηνύματα που προτείνουν εντολές επισκευής για την επίλυση μικρών προβλημάτων
• Προειδοποιήσεις κατανομής – Προειδοποιήσεις σχετικά με την κατανομή χώρου που δεν επηρεάζουν την πρόσβαση στα δεδομένα
• Συστάσεις απόδοσης – Προτάσεις για συντήρηση και βελτιστοποίηση ευρετηρίου
• Ενημερωτικές ανακοινώσεις – Γενικά μηνύματα κατάστασης που δεν απαιτούν άμεση ενέργεια

Αυτά τα μηνύματα παρέχουν πολύτιμες οδηγίες συντήρησης, ενώ παράλληλα διακρίνουν μεταξύ κρίσιμης αλλοίωσης που απαιτεί άμεση δράση και δευτερευόντων προβλημάτων που μπορούν να αντιμετωπιστούν κατά τη διάρκεια των τακτικών περιθωρίων συντήρησης.

Παράδειγμα μηνύματος προειδοποίησης:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 Διακοπές εκτέλεσης CHECKDB

Εάν το CHECKDB ματαιωθεί κατά την εκτέλεση για διάφορους λόγους, θα αναφέρει ένα μήνυμα σφάλματος και θα προσθέσει ένα αρχείο καταγραφής σφαλμάτων με τον παρακάτω κωδικό κατάστασης:

Κατάσταση	Περιγραφή
0	Παρουσιάστηκε ο αριθμός σφάλματος 8930. Αυτό υποδεικνύει μια καταστροφή στα μεταδεδομένα που τερμάτισε την εντολή DBCC.
1	Παρουσιάστηκε ο αριθμός σφάλματος 8967. Παρουσιάστηκε εσωτερικό σφάλμα DBCC.
2	Παρουσιάστηκε σφάλμα κατά την επιδιόρθωση της βάσης δεδομένων σε κατάσταση έκτακτης ανάγκης.
3	Αυτό υποδεικνύει μια καταστροφή στα μεταδεδομένα που τερματίζει την εντολή DBCC.
4	Εντοπίστηκε παραβίαση διεκδίκησης ή πρόσβασης.
5	Παρουσιάστηκε ένα άγνωστο σφάλμα που τερματίζει την εντολή DBCC.

Παράδειγμα μηνύματος σφάλματος:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

or

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

Παράδειγμα αρχείου καταγραφής σφαλμάτων:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

Σε μια τέτοια περίπτωση, μπορείτε να δοκιμάσετε εναλλακτικές προηγμένες επιλογές, όπως π.χ. DataNumen SQL Recovery για να διορθώσετε την καταστροφή στη βάση δεδομένων σας.

5. Διόρθωση σφαλμάτων διαφθοράς

5.1 Δημιουργία αντιγράφων ασφαλείας και επαναφορά: Η ασφαλέστερη λύση

Όταν το DBCC CHECKDB εντοπίζει σφάλματα καταστροφής, η επαναφορά από ένα καθαρό αντίγραφο ασφαλείας αντιπροσωπεύει την ασφαλέστερη και πιο αποτελεσματική μέθοδο.ost αξιόπιστη λύση. Αυτή η προσέγγιση εγγυάται την ακεραιότητα των δεδομένων, εξαλείφοντας παράλληλα τις υποκείμενες αιτίες αλλοίωσης. Πριν από την επαναφορά, επαληθεύστε την ακεραιότητα του αντιγράφου ασφαλείας χρησιμοποιώντας ΕΠΑΝΑΦΟΡΑ ΜΟΝΟ ΕΠΑΛΗΘΕΥΣΗΣ εντολές και λάβετε υπόψη τις επιλογές αποκατάστασης σε συγκεκριμένη χρονική στιγμή για την ελαχιστοποίηση της απώλειας δεδομένων. Καταγράψτε τις λεπτομέρειες της καταστροφής για την ανάλυση της βασικής αιτίας, καθώς τα προβλήματα υλικού ή τα σφάλματα λογισμικού ενδέχεται να απαιτούν πρόσθετη προσοχή για την αποφυγή επανεμφάνισης.

5.2 Λύσεις για τη διαφθορά σε επίπεδο σελίδας

Για μεμονωμένη αλλοίωση σελίδας που επηρεάζει μικρά τμήματα δεδομένων, SQL Server Η έκδοση Enterprise προσφέρει δυνατότητες επαναφοράς σελίδων που επιδιορθώνουν συγκεκριμένες κατεστραμμένες σελίδες χωρίς πλήρη επαναφορά της βάσης δεδομένων. Αυτή η προηγμένη τεχνική απαιτεί πλήρες μοντέλο αποκατάστασης και τρέχοντα αντίγραφα ασφαλείας των αρχείων καταγραφής.

Βήμα προς βήμα διαδικασία επαναφοράς σελίδας:

1. Εντοπίστε την κατεστραμμένη σελίδα από μήνυμα σφάλματος CHECKDB (π.χ., σελίδα 1:256)
2. Δημιουργήστε ένα αντίγραφο ασφαλείας του τρέχοντος αρχείου καταγραφής για την καταγραφή πρόσφατων συναλλαγών:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. Επαναφορά της κατεστραμμένης σελίδας από το μost πρόσφατο πλήρες αντίγραφο ασφαλείας:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. Εφαρμογή διαφορικού αντιγράφου ασφαλείας (εάν είναι διαθέσιμο):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. Εφαρμογή όλων των αντιγράφων ασφαλείας αρχείων καταγραφής σε ακολουθία, συμπεριλαμβανομένου αυτού που μόλις δημιουργήθηκε:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. Δημιουργήστε ένα τελικό αντίγραφο ασφαλείας του αρχείου καταγραφής και επαναφέρετε το για να ενημερώσετε τη σελίδα:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

Εναλλακτική λύση για μη κρίσιμα δεδομένα: Εάν η καταστροφή επηρεάζει μη κρίσιμα δεδομένα, μπορείτε να εξαγάγετε γραμμές που δεν έχουν επηρεαστεί σε νέους πίνακες πριν από την ανακατασκευή των κατεστραμμένων δομών:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 Γρήγορες λύσεις για τη διαφθορά του ευρετηρίου

Η αλλοίωση του ευρετηρίου συχνά ανταποκρίνεται καλά στις λειτουργίες ανακατασκευής που αναδημιουργούν δομές ευρετηρίου χωρίς να επηρεάζουν τα υποκείμενα δεδομένα πίνακα:

ALTER INDEX ALL ON YourTable REBUILD

Αυτή η προσέγγιση λειτουργεί ιδιαίτερα καλά για αλλοίωση ευρετηρίου που δεν είναι σε συστάδες, καθώς η ανακατασκευή αναγεννά τις σελίδες ευρετηρίου από τα δεδομένα του πίνακα προέλευσης, εξαλείφοντας αποτελεσματικά την αλλοίωση διατηρώντας παράλληλα όλες τις αρχικές πληροφορίες.

6. Χρησιμοποιήστε τα REPAIR_REBUILD και REPAIR_ALLOW_DATA_LOSS

Εάν οι προηγούμενες μέθοδοι αποτύχουν όλες ή δεν είναι εφικτές, μπορείτε να χρησιμοποιήσετε τις επιλογές REPAIR_REBUILD και REPAIR_ALLOW_DATA_LOSS για να επιδιορθώσετε τη βάση δεδομένων.

6.1 ΕΠΙΣΚΕΥΗ_ΑΝΑΚΑΤΑΣΚΕΥΗ (Ασφαλέστερη επιλογή):

• Χρήση για: Καταστροφή ευρετηρίου και μικρά σφάλματα κατανομής
• Ασφάλεια δεδομένων: Προσπάθειες διόρθωσης διαφθοράς χωρίς διαγραφή δεδομένων
• Επίπεδο κινδύνου: Χαμηλό – δεν αναμένεται απώλεια δεδομένων
• Τυπικά σενάρια: Καταστροφή ευρετηρίου εκτός ομαδοποίησης, μικρά προβλήματα μεταδεδομένων
• Παράδειγμα εντολής: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 ΕΠΙΣΚΕΥΗ_ΑΠΩΛΕΙΑΣ_ΔΕΔΟΜΕΝΩΝ (Τελευταία Λύση):

• Χρήση για: Σοβαρή καταστροφή όταν δεν υπάρχουν διαθέσιμα αντίγραφα ασφαλείας
• Ασφάλεια δεδομένων: Μπορεί να διαγράψει κατεστραμμένα δεδομένα για να επαναφέρει τη λειτουργικότητα της βάσης δεδομένων
• Επίπεδο κινδύνου: Υψηλή – πιθανή μόνιμη απώλεια δεδομένων
• Τυπικά σενάρια: Καταστροφή σελίδας, ζημιά στον πίνακα συστήματος, σφάλματα στην αλυσίδα κατανομής
• Παράδειγμα εντολής: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Βέλτιστες πρακτικές για αυτές τις επιλογές:

• Πάντα δοκιμή εργασίες επιδιόρθωσης σε αντίγραφα βάσης δεδομένων, όταν είναι δυνατόν
• Να δημιουργείται πάντα αντίγραφο ασφαλείας πριν εκτελέσετε αυτές τις επιλογές
• Καταγράψτε όλες τις αλλαγές για σκοπούς συμμόρφωσης και αντιμετώπισης προβλημάτων
• Ορισμός βάσης δεδομένων σε λειτουργία ενός χρήστη πριν από την εκτέλεση εργασιών επισκευής

Κανονικά, θα έπρεπε να προσπαθήσουμε ΕΠΙΣΚΕΥΗ_ΑΝΑΚΑΤΑΣΚΕΥΗ επιλογή πρώτα. Εάν αποτύχει, δοκιμάστε ΕΠΙΣΚΕΥΗ_ALLOW_DATA_LOSS επιλογή.

6.4 Αποτελέσματα ΕΠΙΣΚΕΥΗΣ_ΑΠΩΛΕΙΑΣ_ΔΕΔΟΜΕΝΩΝ

6.4.1 Η επιδιόρθωση επιτυγχάνεται με απώλεια δεδομένων

Μερικές φορές το ΕΠΙΣΚΕΥΗ_ALLOW_DATA_LOSS η επιλογή θα επιτύχει, αλλά ορισμένα δεδομένα είναι lost μετά την επισκευή.

Παρακάτω παρατίθενται μερικά δείγματα μηνυμάτων:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

Αυτό συμβαίνει επειδή το DBCC CHECKDB διορθώνει τη βάση δεδομένων εγκαταλείποντας ορισμένες κατεστραμμένες εγγραφές, αλλά στην πραγματικότητα, most από αυτά μπορούν ακόμα να ανακτηθούν μέσω DataNumen SQL Recovery.

Δείγματα αρχείων:

SQL Server εκδοχή	Κατεστραμμένο αρχείο MDF	Διορθώθηκε το αρχείο MDF από DataNumen SQL Recovery
SQL Server 2014	Σφάλμα10_1.mdf (Μήνυμα 8909 ακολουθούμενο από Μήνυμα 8939) (600 εγγραφές lost με REPAIR_ALLOW_DATA_LOSS)	Σφάλμα10_1_fixed.mdf (Δεν υπάρχει καταγραφή lost)
SQL Server 2014	Σφάλμα10_2.mdf (Μήνυμα 8909 ακολουθούμενο από Μήνυμα 8939) (6000 εγγραφές (50%) lost με REPAIR_ALLOW_DATA_LOSS)	Σφάλμα10_2_fixed.mdf (Μόνο 100 εγγραφές lost)
SQL Server 2014	Error7.mdf (100 εγγραφές lost με REPAIR_ALLOW_DATA_LOSS)	Σφάλμα7_fixed.mdf (Μόνο μία εγγραφή lost)

6.4.2 Αποτυχία επισκευής – Εξετάστε την επαγγελματική λύση

If ΕΠΙΣΚΕΥΗ_ALLOW_DATA_LOSS Εάν αποτύχει, θα εμφανίσει ένα ή περισσότερα μηνύματα σφάλματος.

Παρακάτω είναι μερικά παραδείγματα:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

Σε αυτές τις περιπτώσεις, θα πρέπει να χρησιμοποιήσετε μια επαγγελματική λύση, όπως π.χ. DataNumen SQL Recovery για να διορθώσετε τη βάση δεδομένων σας.

Δείγματα αρχείων

SQL Server εκδοχή	Κατεστραμμένο αρχείο MDF	Διορθώθηκε το αρχείο MDF από DataNumen SQL Recovery
SQL Server 2014	Σφάλμα1_3.mdf (Μονό μήνυμα 824)	Σφάλμα1_3_fixed.mdf
SQL Server 2014	Σφάλμα1_1.mdf (Συνεχή σφάλματα Msg 824)	Σφάλμα1_1_διορθώθηκε.mdf
SQL Server 2014	Σφάλμα1_2.mdf ((Μήνυμα 824 ακολουθούμενο από μήνυμα 7909)	Σφάλμα1_2_fixed.mdf
SQL Server 2014	Σφάλμα4_1.mdf (Μήνυμα 8992 ακολουθούμενο από μήνυμα 3852)	Σφάλμα4_1_fixed.mdf
SQL Server 2014	Σφάλμα4_2.mdf (Μήνυμα 8992 ακολουθούμενο από μήνυμα 3852)	Σφάλμα4_2_fixed.mdf
SQL Server 2014	Σφάλμα5.mdf (Μήνυμα 8945)	Σφάλμα5_fixed.mdf
SQL Server 2014	Σφάλμα6.mdf (Μήνυμα 2510)	Σφάλμα6_fixed.mdf
SQL Server 2014	Σφάλμα2.mdf (Μήνυμα 2575)	Σφάλμα2_fixed.mdf
SQL Server 2014	Σφάλμα11.mdf (Μήνυμα 8905)	Σφάλμα11_fixed.mdf
SQL Server 2014	Σφάλμα3.mdf (Μήνυμα 5028)	Σφάλμα3_fixed.mdf
SQL Server 2014	Error8.mdf (Μήνυμα 5125)	Error8_διορθώθηκε.mdf
SQL Server 2014	Σφάλμα9.mdf (Μήνυμα 3313)	Σφάλμα9_fixed.mdf

7. Βέλτιστες πρακτικές

7.1 Προγραμματισμός τακτικών λειτουργιών CHECKDB

Εφαρμόστε εβδομαδιαία εκτέλεση DBCC CHECKDB για κρίσιμες βάσεις δεδομένων παραγωγής, με καθημερινούς ελέγχους για συστήματα με υψηλές συναλλαγές. Προγραμματίστε λειτουργίες κατά τη διάρκεια περιόδων χαμηλής χρήσης για να ελαχιστοποιήσετε τον αντίκτυπο στην απόδοση και εξετάστε το ενδεχόμενο εναλλαγής μεταξύ πλήρων ελέγχων και επιλογών PHYSICAL_ONLY με βάση το μέγεθος της βάσης δεδομένων και τα παράθυρα συντήρησης. Αυτοματοποιημένος προγραμματισμός μέσω SQL Server Το Agent διασφαλίζει συνεπή εκτέλεση, παρέχοντας παράλληλα δυνατότητες κεντρικής παρακολούθησης και ειδοποίησης.

7.2 Διαχείριση Επιπτώσεων στην Απόδοση

Οι λειτουργίες DBCC CHECKDB καταναλώνουν σημαντικούς πόρους συστήματος, επηρεάζοντας ενδεχομένως την ταυτόχρονη δραστηριότητα των χρηστών. Παρακολουθήστε την αξιοποίηση της CPU, την κατανάλωση μνήμης και τις εισόδους/εξόδους δίσκου κατά τη διάρκεια των ελέγχων για να κατανοήσετε τα μοτίβα επίδρασης στην απόδοση. Εξετάστε το ενδεχόμενο χρήσης επιλογών NOINDEX για ελέγχους ρουτίνας, διατηρώντας την πλήρη επικύρωση για τα μηνιαία παράθυρα συντήρησης. Εφαρμόστε επεκτάσεις χρονικού ορίου ερωτημάτων και στρατηγικές επικοινωνίας χρηστών για τη διαχείριση των προσδοκιών κατά τη διάρκεια των περιόδων ελέγχου ακεραιότητας.

7.3 Σχεδιασμός Συντήρησης Παραθύρων

Συντονίστε τον προγραμματισμό του DBCC CHECKDB με άλλες δραστηριότητες συντήρησης, όπως λειτουργίες δημιουργίας αντιγράφων ασφαλείας, ανακατασκευή ευρετηρίου και ενημερώσεις στατιστικών στοιχείων. Αποφύγετε την επικάλυψη λειτουργιών που απαιτούν πολλούς πόρους και οι οποίες θα μπορούσαν να προκαλέσουν υποβάθμιση της απόδοσης ή προβλήματα χρονικού ορίου. Σχεδιάστε τα παράθυρα συντήρησης με βάση τις προβλέψεις αύξησης του μεγέθους της βάσης δεδομένων, διασφαλίζοντας επαρκή χρόνο για πλήρη επαλήθευση ακεραιότητας καθώς αυξάνονται οι όγκοι δεδομένων.

7.4 Αυτοματοποιημένη παρακολούθηση και ειδοποίηση

Διαμορφώστε SQL Server Ειδοποιήσεις πρακτόρων για άμεση ειδοποίηση των διαχειριστών όταν το DBCC CHECKDB εντοπίσει διαφθορά. Υλοποίηση λύσεων ανάλυσης αρχείων καταγραφής που εξάγουν και κατηγοριοποιούν τα αποτελέσματα ελέγχου ακεραιότητας, επιτρέποντας την ανάλυση τάσεων και τον προληπτικό εντοπισμό προβλημάτων. Δημιουργία διαδικασιών κλιμάκωσης που καθορίζουν χρονικά πλαίσια απόκρισης και υπεύθυνο προσωπικό για διαφορετικά επίπεδα σοβαρότητας διαφθοράς.

8. DBCC CHECKTABLE: Η ελαφριά εναλλακτική λύση

8.1 Πότε να χρησιμοποιείτε το CHECKTABLE αντί για το CHECKDB

Το DBCC CHECKTABLE παρέχει εστιασμένο έλεγχο ακεραιότητας για μεμονωμένους πίνακες, καθιστώντας το ιδανικό για tarΑποτελεσμένη αντιμετώπιση προβλημάτων και συντήρηση συγκεκριμένων αντικειμένων βάσης δεδομένων. Χρησιμοποιήστε το CHECKTABLE κατά την διερεύνηση προβλημάτων απόδοσης με συγκεκριμένους πίνακες, την επικύρωση κρίσιμων επιχειρηματικών πινάκων μεταξύ πλήρων ελέγχων βάσης δεδομένων ή όταν οι χρονικοί περιορισμοί εμποδίζουν την πλήρη επικύρωση της βάσης δεδομένων. Αυτή η προσέγγιση αποδεικνύεται ιδιαίτερα πολύτιμη σε μεγάλες βάσεις δεδομένων όπου οι πλήρεις λειτουργίες CHECKDB υπερβαίνουν τα διαθέσιμα παράθυρα συντήρησης.

8.2 Σύνταξη και παραδείγματα του DBCC CHECKTABLE

Η βασική εντολή CHECKTABLE tarλαμβάνει συγκεκριμένους πίνακες:

DBCC CHECKTABLE('YourTable')

Όπως και το CHECKDB, το CHECKTABLE υποστηρίζει διάφορες επιλογές, όπως το NOINDEX για βελτιστοποίηση της απόδοσης και παραμέτρους επιδιόρθωσης για την επίλυση προβλημάτων. Μπορείτε επίσης να καθορίσετε ονόματα σχημάτων για ακριβή αναγνώριση πινάκων:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

Αυτός ο διαλογισμός στα tarΗ προσέγγιση Geted επιτρέπει την λεπτομερή επαλήθευση ακεραιότητας, διατηρώντας παράλληλα την απόδοση του συστήματος κατά τις εργάσιμες ώρες.

8.3 Οφέλη απόδοσης για μεγάλες βάσεις δεδομένων

Οι λειτουργίες του CHECKTABLE ολοκληρώνονται σημαντικά πιο γρήγορα από τους πλήρεις ελέγχους βάσης δεδομένων, επιτρέποντας την πιο συχνή επαλήθευση ακεραιότητας των κρίσιμων πινάκων. Αυτή η προσέγγιση επιτρέπει την καθημερινή επικύρωση βασικών επιχειρηματικών πινάκων, ενώ παράλληλα δεσμεύει ολοκληρωμένες λειτουργίες CHECKDB για εβδομαδιαία ή μηνιαία χρονοδιαγράμματα. Η μειωμένη κατανάλωση πόρων καθιστά το CHECKTABLE κατάλληλο για εκτέλεση σε περιβάλλον παραγωγής με ελάχιστη επίδραση στον χρήστη.

9. Όταν το CHECKDB αποτυγχάνει

Το DBCC CHECKDB θα αποτύχει σε διάφορα σενάρια, όπως:

• Εκτέλεση DBCC CHECKDB τερματίζεται ασυνήθιστα
• Η εκτέλεση του DBCC CHECKDB ολοκληρώνεται με επιτυχία, αλλά το επιλογές επισκευής αποτυχία επιδιόρθωσης της βάσης δεδομένων.

Σε αυτά τα σενάρια, χρειαζόμαστε ένα πιο επαγγελματικό εργαλείο για να μας βοηθήσει να διορθώσουμε τις αλλοιώσεις στη βάση δεδομένων.

9.1 Εισαγωγή στο DataNumen SQL Recovery

DataNumen SQL Recovery παρέχει πιο προηγμένες δυνατότητες:

• Καλύτερο ποσοστό ανάκτησης στον κλάδο.
• Ανακτήστε σοβαρά κατεστραμμένα αρχεία βάσης δεδομένων.
• Ανακτήστε όλα τα αντικείμενα της βάσης δεδομένων, συμπεριλαμβανομένων πινάκων, ευρετηρίων, προβολών, εναυσμάτων, κανόνων και προεπιλογών.
• Ανάκτηση αποθηκευμένων διαδικασιών, βαθμωτών συναρτήσεων, ενσωματωμένων συναρτήσεων με τιμές πίνακα και συναρτήσεων με τιμές πίνακα πολλαπλών δηλώσεων.
• Ανακτήστε οριστικά διαγραμμένα αρχεία.
• Αποκρυπτογράφηση κρυπτογραφημένων αντικειμένων σε SQL Server βάσεων δεδομένων.
• Επιδιόρθωση αρχείων MDF σε παρτίδες.
• Ολοκληρωμένες επιλογές επισκευής.
• Προηγμένη καταγραφή και αναφορά.
• Υποστήριξη για όλους SQL Server εκδόσεις.
• Διαθεσιμότητα τεχνικής υποστήριξης
• Τακτικές ενημερώσεις και βελτιώσεις

9.2 Σύγκριση ποσοστού επιτυχίας

Τα ποσοστά επιτυχίας ανάκτησης διαφέρουν σημαντικά:

• DBCC CHECKDB & ΠΙΝΑΚΑΣ ΕΛΕΓΧΟΥ: 1.27% μέσο ποσοστό ανάκτησης
• DataNumen: 92.6% ποσοστό ανάκτησης

Ακολουθεί μια πλήρης ανταγωνιστική σύγκριση:

9.3 Ανάκτηση από σοβαρή διαφθορά

Προηγμένες δυνατότητες για σοβαρές περιπτώσεις:

• Ανάκτηση από σωματικά κατεστραμμένη αποθήκευση
• Ανάκτηση από διαμορφωμένες μονάδες δίσκου ή κατεστραμμένα συστήματα
• Ανάκτηση από εικόνες δίσκου, αρχεία αντιγράφων ασφαλείας, αρχεία δίσκου εικονικής μηχανής, ρυθμόςrary αρχεία, κ.λπ.

9.4 Πότε πρέπει να λάβετε υπόψη τις επαγγελματικές λύσεις

• Δεν υπάρχει διαθέσιμη πρόσφατη δημιουργία αντιγράφων ασφαλείας
• Το DBCC CHECKDB αποτυγχάνει
• Σενάρια σοβαρής διαφθοράς
• Διαχείριση κρίσιμων επιχειρηματικών δεδομένων
• Όταν ο χρόνος είναι κρίσιμος
• Όταν η μέγιστη αποκατάσταση είναι απαραίτητη

10. Συχνές ερωτήσεις

11. Σύναψη

11.1 Περίληψη Βασικών Σημείων

11.1.1 Ανακεφαλαίωση βασικών εντολών DBCC CHECKDB

Κατακτήστε τη βασική σύνταξη DBCC CHECKDB για ολοκληρωμένο έλεγχο βάσεων δεδομένων, χρησιμοποιήστε τις επιλογές NOINDEX και PHYSICAL_ONLY για βελτιστοποίηση απόδοσης και κατανοήστε το CHECKTABLE για tarεπαλήθευση επιλεγμένου πίνακα. Αυτές οι θεμελιώδεις εντολές αποτελούν τη βάση της προληπτικής συντήρησης της βάσης δεδομένων, επιτρέποντας την έγκαιρη ανίχνευση αλλοιώσεων και τη συστηματική παρακολούθηση της ακεραιότητας.

11.1.2 Υπενθύμιση κρίσιμων βέλτιστων πρακτικών

Να διατηρείτε πάντα ενημερωμένα αντίγραφα ασφαλείας πριν από την εκτέλεση ελέγχων ακεραιότητας, να προγραμματίζετε τακτικές λειτουργίες CHECKDB με βάση την κρισιμότητα της βάσης δεδομένων και να εφαρμόζετε αυτοματοποιημένη παρακολούθηση για άμεσες ειδοποιήσεις για διαφθορά. Να θυμάστε ότι η πρόληψη μέσω τακτικής παρακολούθησης υπερβαίνει τις αντιδραστικές προσεγγίσεις και οι επαγγελματικές λύσεις αποκατάστασης παρέχουν πολύτιμες επιλογές δημιουργίας αντιγράφων ασφαλείας όταν τα τυπικά εργαλεία αποδεικνύονται ανεπαρκή.

11.2 Πότε να χρησιμοποιείτε το DBCC CHECKDB έναντι των προηγμένων λύσεων

Χρησιμοποιήστε το DBCC CHECKDB για την τακτική παρακολούθηση της ακεραιότητας και την επίλυση μικρών προβλημάτων διαφθοράς, διατηρώντας παράλληλα επαγγελματικά εργαλεία αποκατάστασης για σοβαρά σενάρια διαφθοράς πέρα ​​από τις ενσωματωμένες δυνατότητες επιδιόρθωσης. Το πλαίσιο λήψης αποφάσεων θα πρέπει να λαμβάνει υπόψη τη διαθεσιμότητα αντιγράφων ασφαλείας, την κρισιμότητα των δεδομένων, τους χρονικούς περιορισμούς και τη σοβαρότητα της διαφθοράς. Οι επιτυχημένοι διαχειριστές βάσεων δεδομένων συνδυάζουν την τακτική παρακολούθηση του CHECKDB με ολοκληρωμένες στρατηγικές δημιουργίας αντιγράφων ασφαλείας και την επίγνωση των προηγμένων επιλογών αποκατάστασης όταν οι τυπικές προσεγγίσεις αποδεικνύονται ανεπαρκείς.

12. αναφορές

1. Microsoft Learn. «DBCC CHECKDB (Transact-SQL).» SQL Server Απόδειξη με έγγραφαMicrosoft Corporation.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. «Αντιμετώπιση σφαλμάτων συνέπειας βάσης δεδομένων που αναφέρθηκαν από το DBCC CHECKDB». SQL Server Απόδειξη με έγγραφαMicrosoft Corporation.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors