Ανάκτηση βάσεων δεδομένων Microsoft SQL Server. Ανάκτηση βάσης δεδομένων

Μία από τις κύριες απαιτήσεις για ένα DBMS είναι η αξιοπιστία της αποθήκευσης δεδομένων στην εξωτερική μνήμη. Η αξιοπιστία αποθήκευσης σημαίνει ότι το DBMS πρέπει να μπορεί να επαναφέρει την τελευταία συνεπή κατάσταση του DB μετά από οποιαδήποτε αποτυχία υλικού ή λογισμικού. Συνήθως εξετάζονται δύο πιθανοί τύποι αστοχιών υλικού: οι αποκαλούμενες λογικές αστοχίες, οι οποίες μπορούν να ερμηνευθούν ως ξαφνική διακοπή του υπολογιστή (για παράδειγμα, απενεργοποίηση έκτακτης ανάγκης) και αστοχίες σκληρού υλικού, που χαρακτηρίζονται από απώλεια πληροφοριών σχετικά με το μεσο ΜΑΖΙΚΗΣ ΕΝΗΜΕΡΩΣΗΣ. εξωτερική μνήμη... Παραδείγματα αστοχιών λογισμικού μπορεί να είναι: μη φυσιολογικός τερματισμός του DBMS (λόγω σφάλματος στο πρόγραμμα ή ως αποτέλεσμα κάποιας αστοχίας υλικού) ή μη φυσιολογικός τερματισμός ενός προγράμματος χρήστη, ως αποτέλεσμα του οποίου κάποια συναλλαγή παραμένει ημιτελής. Η πρώτη κατάσταση μπορεί να θεωρηθεί ως ένα ειδικό είδος αστοχίας λογισμικού. όταν συμβαίνει το τελευταίο, απαιτείται η εξάλειψη των συνεπειών μιας μόνο συναλλαγής.

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

Το περιοδικό είναι ένα ειδικό μέρος της βάσης δεδομένων που δεν είναι προσβάσιμο στους χρήστες DBMS και διατηρείται με ιδιαίτερη προσοχή (μερικές φορές υποστηρίζονται δύο αντίγραφα του περιοδικού, που βρίσκονται σε διαφορετικά φυσικούς δίσκους), το οποίο λαμβάνει εγγραφές όλων των αλλαγών στο κύριο μέρος της βάσης δεδομένων. Κατά την καταγραφή, τηρείται η στρατηγική της "προώθησης" εγγραφής, πράγμα που σημαίνει ότι μια εγγραφή σχετικά με μια αλλαγή οποιουδήποτε αντικειμένου βάσης δεδομένων πρέπει να μπει στην εξωτερική μνήμη του αρχείου καταγραφής πριν το αλλαγμένο αντικείμενο εισέλθει στην εξωτερική μνήμη του κύριου μέρους του βάση δεδομένων. Είναι γνωστό ότι εάν το DBMS τηρεί σωστά αυτήν την κατάσταση, τότε χρησιμοποιώντας το αρχείο καταγραφής είναι δυνατό να λυθούν όλα τα προβλήματα επαναφοράς της βάσης δεδομένων μετά από οποιαδήποτε αποτυχία.

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

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

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

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

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

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

Επαναφορά μιας βάσης δεδομένων από ένα πλήρες αντίγραφο.

Ανεξάρτητα από το μοντέλο ανάκτησης, το πρώτο βήμα είναι πάντα να επαναφέρετε το πιο πρόσφατο πλήρες αντίγραφο ασφαλείας. Για να επαναφέρετε τη βάση δεδομένων στο Enterprise Manager, επιλέξτε τη βάση δεδομένων, κάντε διπλό κλικ σε αυτήν κάντε δεξί κλικποντίκι και επιλέξτε μέσα κατάλογος συμφραζόμενων«Όλες οι εργασίες> Επαναφορά βάσης δεδομένων», θα ανοίξει το παράθυρο διαλόγου που φαίνεται στην Εικόνα Α.

Εικόνα Α.

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

• Αφαιρέστε τις κασέτες μετά την επαναφορά κάθε αντιγράφου ασφαλείας
• Ερώτηση πριν από την επαναφορά κάθε αντιγράφου ασφαλείας (δώστε μια πρόσθετη προειδοποίηση πριν επαναφέρετε κάθε αντίγραφο ασφαλείας)
• Αναγκαστική επαναφορά μέσω υπάρχουσας βάσης δεδομένων, αυτή η επιλογή ισοδυναμεί με το Move in T-SQL.

Εικόνα Β.

Στο κάτω μέρος του παραθύρου υπάρχουν τρεις διακόπτες που σας επιτρέπουν να προσδιορίσετε την κατάσταση της βάσης δεδομένων μετά την επαναφορά ενός αντιγράφου:

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

Το μόνο που έχετε να κάνετε είναι να κάνετε κλικ στο OK για να επαναφέρετε τη βάση δεδομένων και τα αρχεία καταγραφής συναλλαγών.

Ανάκτηση βάσης δεδομένων με χρήση T-SQL.

Η ανάκτηση βάσης δεδομένων μπορεί επίσης να γίνει χρησιμοποιώντας την T-SQL, η οποία προσφέρει περισσότερες επιλογές από το Enterprise Manager. Σύνταξη χρήσης Εντολές T-SQLΕπόμενο:

ΕΠΑΝΑΦΟΡΑ ΒΑΣΗΣ ΔΕΔΟΜΕΝΩΝ ( όνομα βάσης δεδομένων | @ database_name_var }
[ΑΠΟ< backup_device > [ , ...n ] ]
[ΜΕ
[RESTRICTED_USER]
[ [ , ] ΑΡΧΕΙΟ = { αριθμός φακέλου | @ αριθμός φακέλου } ]
[ [ , ] ΚΩΔΙΚΟΣ ΠΡΟΣΒΑΣΗΣ = { Κωδικός πρόσβασης | @ κωδικός_μεταβλητής } ]
[ [ , ] MEDIANAME = { όνομα_μέσου | @ όνομα_μέσο_μεταβλητή } ]
[ [ , ] ΚΩΔΙΚΟΣ ΜΕΣΩΝ = { κωδικό πρόσβασης μέσων | @ mediapassword_variable } ]
[ [ , ] ΚΙΝΗΣΗ " λογικό_όνομα_αρχείου" ΠΡΟΣ ΤΟ " Όνομα_αρχείου_λειτουργικού_συστήματος" ]
[ , ...n ]
[ [ , ] KEEP_REPLICATION]
[ [ , ] (NORECOVERY | RECOVERY | STANDBY = undo_file_name } ]
[ [ , ] (NOREWIND | REWIND)]
[ [ , ] (NOUNLOAD | UNLOAD)]
[ [ , ] ΑΝΤΙΚΑΤΑΣΤΑΣΗ]
[ [ , ] ΕΠΑΝΕΚΚΙΝΗΣΗ]
[ [ , ] ΣΤΑΤΙΣΤΙΚΑ [ = ποσοστό ] ]

Για μια λεπτομερή συζήτηση για κάθε επιλογή, διαβάστε τις περιγραφές στο SQL Server 2000 Books Online.

Το σχήμα Γ δείχνει την επαναφορά ενός πλήρους αντιγράφου της βάσης δεδομένων Pubs από μια συσκευή δημιουργίας αντιγράφων ασφαλείας.

Εικόνα Γ.

Επαναφορά βάσης δεδομένων από διαφορικό αντίγραφο.

Εάν χρησιμοποιείτε το μοντέλο πλήρους ή μαζικής ανάκτησης, πρέπει πρώτα να επαναφέρετε το πλήρες αντίγραφο ασφαλείας και μετά το τελευταίο διαφορικό αντίγραφο ασφαλείας και όλα τα αρχεία καταγραφής συναλλαγών. Για να επαναφέρετε μια βάση δεδομένων χρησιμοποιώντας ένα διαφορικό αντίγραφο, στο Enterprise Manager, επιλέξτε τη βάση δεδομένων, κάντε διπλό κλικ σε αυτήν και επιλέξτε "Όλες οι εργασίες> Επαναφορά βάσης δεδομένων" από το μενού περιβάλλοντος, επιλέξτε επαναφορά πλήρους και διαφορικών αντιγράφων της βάσης δεδομένων και, στη συνέχεια, κάντε κλικ στο OK . (Εικόνα Δ)

Εικόνα Δ.

Η σύνταξη εντολής Restore για την εκτέλεση διαφορικής επαναφοράς αντιγράφων ασφαλείας φαίνεται στο Σχήμα Ε.

Εικόνα Ε.

Επαναφορά του αρχείου καταγραφής συναλλαγών.

Πριν ξεκινήσετε την επαναφορά του αρχείου καταγραφής συναλλαγών, πρέπει να επαναφέρετε το πλήρες και το πιο πρόσφατο διαφορικό αντίγραφο της βάσης δεδομένων. Στη συνέχεια, μπορείτε να επαναφέρετε τα αρχεία καταγραφής συναλλαγών με την κατάλληλη σειρά. Εάν χρησιμοποιείτε το Enterprise Manager, πρέπει να επιλέξετε τη βάση δεδομένων, να κάνετε διπλό κλικ σε αυτήν με το δεξί κουμπί του ποντικιού και να επιλέξετε "Όλες οι εργασίες> Επαναφορά βάσης δεδομένων" από το μενού περιβάλλοντος, να επιλέξετε όλα τα απαραίτητα αντίγραφα και, εάν είναι απαραίτητο, το Σημείο στην επιλογή Time Restore. point in time) (Εικόνα F).

Εικόνα ΣΤ.

Η σύνταξη της εντολής Restore για την επαναφορά του αρχείου καταγραφής συναλλαγών φαίνεται στο Σχήμα Ζ.

Εικόνα G.

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

Το σημερινό μάθημα: MySQL.(Η MySQL είναι ένα δωρεάν σύστημα διαχείρισης βάσεων δεδομένων). Η ανάκτηση μιας βάσης δεδομένων είναι απλή, αλλά πρέπει να έχετε ένα αντίγραφο ασφαλείας της βάσης δεδομένων σας. Όταν είχα προβλήματα με τη βάση δεδομένων, δεν μπορούσα να μπω στον ιστότοπο και όλα τα άρθρα μου εξαφανίστηκαν. Έπρεπε να αποφασίσω επειγόντως πώς να επαναφέρω τη βάση δεδομένων Wordprerss.

Αυτή η κατάσταση μου συνέβη πριν από μερικές μέρες, όταν έγραφα το μάθημα 59. Κυριολεκτικά λίγα λεπτά αργότερα, έλαβα ένα SMS από το Yandex-Metrica ότι ο ιστότοπός μου δεν ήταν διαθέσιμος. Εάν έχετε αντιμετωπίσει τέτοιο πρόβλημα στο παρελθόν, τότε ξέρετε πώς να επαναφέρετε τα πάντα σε κατάσταση λειτουργίας και, αν όχι, διαβάστε παρακάτω.

Πώς να ανακτήσετε τη βάση δεδομένων του WordPress (Μέθοδος 1)

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

Εάν το ιστολόγιό σας δεν έχει εγκαταστήσει ακόμα κάποιο πρόσθετο ή παρόμοιο, τότε διατρέχετε τον κίνδυνο να μείνετε χωρίς ιστολόγιο. Φανταστείτε ότι έχετε blog για πολύ καιρό, και μετά μια φορά, και αυτό είναι! Άμπα! Αυτό το πρόσθετο δεν θα επιτρέψει να συμβεί αυτό. Διατηρεί μόνιμα τη βάση δεδομένων του ιστολογίου σας αυτόματη λειτουργίακαι χωρίς τη συμμετοχή σας.

Υπάρχουν πολλές πληροφορίες για την αποκατάσταση της βάσης δεδομένων στο Διαδίκτυο, αλλά μερικές φορές γράφουν τέτοιες ανοησίες, για τις οποίες επίσης ευχαριστούν οι άνθρωποι. Ο συγγραφέας του άρθρου δίνει συμβουλές για το πώς να κάνει σωστά αυτό και εκείνο, αλλά ο ίδιος δεν καταλαβαίνει καν τι γράφει. Όλα, ήρθε η ώρα να ασχοληθείτε 🙂

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

Κάντε κλικ στο όνομα της βάσης δεδομένων που θέλετε να επαναφέρετε.

Στη συνέχεια, πρέπει να κάνετε κλικ στο "SQL"και επικολλήστε στο παράθυρο αυτό που αντιγράψατε από το αρχείο της βάσης δεδομένων κάνοντας κλικ" CTRL " + "V". Κάντε κλικ στη συνέχεια" Εντάξει ".

Περιμένετε μέχρι να ολοκληρωθεί η ανάκτηση της βάσης δεδομένων. Θα πρέπει να εμφανιστεί το μήνυμα επιτυχίας.

Το ιστολόγιό σας έχει πλέον αποκατασταθεί πλήρως.

Πώς να επαναφέρετε γρήγορα μια βάση δεδομένων WordPress (μέθοδος 2)

Έτσι, χωρίς περιττές εισαγωγές. Μεταβείτε στον πίνακα ελέγχου της φιλοξενίας σας (cPanel). Βρείτε το σύνδεσμο " MySQL" ή " PhpMyAdmin ».

Τώρα πρέπει να συνδεθείτε στον πίνακα διαχείρισης της βάσης δεδομένων, δηλαδή στο PhpMyAdmin. Κάντε κλικ " Να ερθει μεσα»

Θα μεταφερθείτε στο PhpMyAdmin. Στα αριστερά, κάντε κλικ στη βάση δεδομένων που πρόκειται να επαναφέρετε. Στην περίπτωσή μου, αυτή είναι η βάση δεδομένων dvpress.

Αφού επιλέξετε μια βάση δεδομένων, θα εμφανιστούν όλοι οι πίνακες για αυτήν τη βάση δεδομένων. Για να αποφευχθούν τυχόν σφάλματα κατά την ανάκτηση, αυτή η βάση δεδομένων πρέπει να διαγραφεί πλήρως. Κατεβαίνουμε στον πάτο και βρίσκουμε " Έλεγχος όλων / Αποεπιλογή όλων ". Κάντε κλικ στο " Επιλογή όλων "Έτσι ώστε όλοι οι πίνακες στη βάση δεδομένων να είναι επιλεγμένοι στο πλαίσιο ελέγχου. Επιλέγουμε στο παράθυρο στα δεξιά " Διαγράφω"Και μετά επιβεβαιώστε" Ναί". Η βάση δεδομένων πρέπει να καθαριστεί πλήρως από όλους τους πίνακες.

Τώρα το καθήκον σας είναι να επαναφέρετε αυτήν τη βάση δεδομένων από ένα αντίγραφο ασφαλείας. Κάντε κλικ στην κορυφή " Εισαγωγή", Στη συνέχεια κάντε κλικ στο κουμπί" επιλέξτε ένα αρχείο ". Βρείτε ένα αντίγραφο ασφαλείας της βάσης δεδομένων στον υπολογιστή σας και κάντε κλικ στο " Ανοιξε". Τώρα στο PhpMyAdmin στο κάτω μέρος κάντε κλικ στο " Εντάξει". Η λειτουργία πρέπει να είναι επιτυχής και η επιγραφή " Ερώτημα SQLολοκληρώθηκε με επιτυχία ».

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

Επαναφορά βάσεων δεδομένων στον SQL Server

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

Ο SQL Server παρέχει πολλές επιλογές για ανάκτηση βάσης δεδομένων. Πρώτον, αυτό επαναφέρει ολόκληρη τη βάση δεδομένων - μπορεί να διαρκέσει πολύ χρόνο (ανάλογα με το μέγεθος της βάσης δεδομένων και την ταχύτητα σκληροι ΔΙΣΚΟΙ). Δεύτερον, ανάκτηση μεμονωμένων ομάδων αρχείων ή αρχείων, εάν η βάση δεδομένων σας αποτελείται από πολλές ομάδες αρχείων (ή, κατά συνέπεια, αρχεία). Σε αυτήν την περίπτωση, είναι δυνατή η επαναφορά μόνο των κατεστραμμένων τμημάτων της βάσης δεδομένων χωρίς να επηρεαστούν τα υπόλοιπα. Αυτοί οι δύο τύποι ανάκτησης βάσεων δεδομένων χρησιμοποιούνται αρκετά συχνά και δεν θα τεθούν στο μέλλον.
Τρίτον, στον SQL Server 2005, κατέστη δυνατή η επαναφορά μεμονωμένων σελίδων βάσης δεδομένων - σε αυτήν την περίπτωση, μόνο οι καθορισμένες σελίδες θα αποκατασταθούν από το αντίγραφο ασφαλείας. Μια τέτοια ανάκτηση θα είναι ιδιαίτερα σημαντική εάν το DBCC CHECKDB βρει αρκετές κατεστραμμένες σελίδες σε κάποιο τεράστιο τραπέζι που "κείνται" σε ένα βαρύ αρχείο. Λόγω του γεγονότος ότι δεν θα γίνει επαναφορά ολόκληρου του αρχείου, ούτε καν ολόκληρος ο πίνακας, αλλά μόνο μερικές σελίδες, ο χρόνος διακοπής λειτουργίας μπορεί να μειωθεί σημαντικά.

Απαιτήσεις και Περιορισμοί

Μοντέλο ανάκτησης και διαθεσιμότητα αντιγράφων καταγραφής συναλλαγών

Το πιο σημαντικό πράγμα που πρέπει να θυμάστε είναι ότι για την ανάκτηση μεμονωμένων σελίδων, η βάση δεδομένων πρέπει να χρησιμοποιεί το μοντέλο πλήρους ανάκτησης ή το μοντέλο ανάκτησης μαζικής καταγραφής. Εάν οι βάσεις δεδομένων σας βρίσκονται σε ένα απλό (απλό) μοντέλο ανάκτησης, τότε ενδέχεται να μην διαβάσετε περαιτέρω.
Η δεύτερη απαίτηση είναι ότι τα πλήρη αντίγραφα ασφαλείας και τα αντίγραφα καταγραφής συναλλαγών πρέπει να αποτελούν μια άθραυστη αλυσίδα καταγραφής. Εάν δεν εκτελέσετε ποτέ το BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) και μεταβείτε σε απλό μοντέλοανάκτηση προκειμένου να συρρικνωθεί το αρχείο καταγραφής συναλλαγών και έχετε ΟΛΑ τα αντίγραφα ασφαλείας του αρχείου καταγραφής συναλλαγών από την τελευταία πλήρη δημιουργία αντιγράφων ασφαλείας χωρίς σελίδα (συμπεριλαμβανομένου αυτού του πιο ολοκληρωμένου αντιγράφου ασφαλείας) - δεν χρειάζεται να ανησυχείτε για την αλυσίδα καταγραφής.
Σε ένα μοντέλο ανάκτησης με μαζική καταγραφή, θεωρητικά, η ανάκτηση μεμονωμένων σελίδων θα πρέπει να λειτουργεί καλά, εφόσον πληρούνται οι προϋποθέσεις που περιγράφονται παραπάνω και οι σελίδες που αποκαθίστανται δεν έχουν τροποποιηθεί από λειτουργίες που εκτελούνται με ελάχιστη καταγραφή.

Εκδόσεις SQL Server

Η ανάκτηση σελίδας είναι δυνατή σε οποιαδήποτε έκδοση του SQL Server, αλλά για τις εκδόσεις Enterprise και Developer είναι δυνατή η ανάκτηση κατεστραμμένων σελίδων on-line, π.χ. μπορείτε να αποκτήσετε πρόσβαση στη βάση δεδομένων κατά την ανάκτηση (και επιπλέον, μπορείτε ακόμη και να ανατρέξετε στον πίνακα στον οποίο ανήκουν οι σελίδες που αποκαθίστανται αυτήν τη στιγμή, εάν αυτές οι ίδιες οι σελίδες δεν «επηρεαστούν» - διαφορετικά, το αίτημα θα αποτύχει). Για τις εκδόσεις «κάτω» Enterprise Edition, η ανάκτηση σελίδων πραγματοποιείται εκτός σύνδεσης και η βάση δεδομένων καθίσταται μη διαθέσιμη κατά την ανάκτηση.

Κατεστραμμένος τύπος σελίδας

Σε περίπτωση που οι σελίδες ευρετηρίου ή οι σελίδες δεδομένων καταστραφούν, η ανάκτησή τους είναι δυνατή ηλεκτρονικά στην έκδοση Enterprise.
Οι σελίδες που περιέχουν κρίσιμους πίνακες συστήματος μπορούν να αποκατασταθούν, αλλά η βάση δεδομένων, όταν αποκατασταθεί, δεν θα είναι διαθέσιμη σε καμία έκδοση του SQL Server.
Οι "κάρτες τοποθέτησης" δεν μπορούν να αποκατασταθούν "ξεχωριστά". Εάν οι σελίδες GAM, SGAM, PFS, ML, DIFF είναι κατεστραμμένες, πρέπει να επαναφέρετε ολόκληρη τη βάση δεδομένων. Η μόνη εξαίρεση είναι οι σελίδες IAM. Αν και αναφέρονται ως "χάρτες τοποθέτησης", περιγράφουν μόνο έναν πίνακα, όχι ολόκληρη τη βάση δεδομένων και μπορούν να επαναφερθούν.
Η σελίδα εκκίνησης της βάσης δεδομένων (σελίδα 9 στο 1ο αρχείο βάσης δεδομένων) και η σελίδα κεφαλίδας του αρχείου (σελίδα 0 σε κάθε αρχείο) δεν μπορούν να αποκατασταθούν "ξεχωριστά", εάν είναι κατεστραμμένα, θα πρέπει να επαναφέρετε ολόκληρη τη βάση δεδομένων.

Στην πραγματικότητα, ανάκαμψη

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

Χαλάμε τη βάση δεδομένων

Για πειραματισμό, θα χρησιμοποιήσω τη βάση δεδομένων AdventureWorks που αποστέλλεται με τον SQL Server. Εάν δεν το έχετε εγκαταστήσει, μπορείτε να το κατεβάσετε εάν θέλετε. Το μεταφράζω στο μοντέλο πλήρους ανάκτησης:
ALTER DATABASE AdventureWorks SET RECOVERY FULL Φροντίζω να μην υπάρχουν ακόμη σφάλματα σε αυτό:
DBCC CHECKDB ("AdventureWorks") ΜΕ NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY και δημιουργήστε ένα πλήρες αντίγραφο ασφαλείας:
BACKUP DATABASE AdventureWorks TO DISK = "D: \ tmp \ aw_backups \ aw_full_ok1.bak"

Σε αυτήν τη βάση δεδομένων, δημιουργώ έναν πίνακα σφαλμάτων.
CREATE TABLE crash (txt varchar (1000)) Θα χαλάσουμε το πεδίο varchar για να ελέγξουμε τι θα συμβεί αν ο SQL Server βρει ξαφνικά σε αυτόν τα δεδομένα που έγραψε ο ίδιος εκεί.
Πριν χαλάσεις κάτι, πρέπει να το γεμίσεις με κάτι. Φορτώνω τα αριστερά δεδομένα στον πίνακα που δημιουργήθηκε.
ΡΥΘΜΙΣΕ ΜΗ ΛΟΓΑΡΙΑΣΜΟ ΣΤΗ ΔΗΛΩΣΗ @i INT SET @i = 1 ΕΝΩ @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE("a", 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:
BACKUP LOG AdventureWorks TO DISK = "D: \ tmp \ aw_backups \ aw_log_ok1.trn"

Τώρα ας αλλάξουμε λίγο τα δεδομένα:

Όλα λοιπόν είναι έτοιμα. Αποσυνδέστε τη βάση δεδομένων και ανοίξτε το αρχείο mdf FAR (ή οτιδήποτε σας βολεύει περισσότερο), αναζητήστε τη συμβολοσειρά "zzzzzzzz" σε αυτό και αντικαταστήστε αρκετούς "z" με αυθαίρετους χαρακτήρες:


Τώρα που η βάση δεδομένων είναι κατεστραμμένη, τη συνδέουμε. Και, ναι, θυμάμαι ότι στο προηγούμενο άρθρο αναφέρθηκε ξεκάθαρα ότι η αποσύνδεση / επισύναψη της βάσης δεδομένων δεν αξίζει τον κόπο. Αλλά στην περίπτωσή μας είναι απολύτως "ασφαλές" - η βάση δεδομένων στο "ύποπτο" δεν θα πέσει.

Ψάχνετε για σφάλματα

Έτσι, η κατεστραμμένη βάση δεδομένων επέστρεψε με επιτυχία στην υπηρεσία. Ας εκτελέσουμε ξανά τον έλεγχο ακεραιότητας:
DBCC CHECKDB ("AdventureWorks") WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Ως αποτέλεσμα, αυτό που περιμέναμε ( φροντίστε να θυμάστε τους αριθμούς των κατεστραμμένων σελίδων!):

Μήνυμα 8928, Επίπεδο 16, Πολιτεία 1, Γραμμή 1
Αναγνωριστικό αντικειμένου 1883153754, αναγνωριστικό ευρετηρίου 0, αναγνωριστικό διαμερίσματος 72057594054246400, αναγνωριστικό μονάδας κατανομής 72057594061651968 (τύπος δεδομένων στη σειρά): Δεν ήταν δυνατή η επεξεργασία της σελίδας (1: 20455). Δείτε άλλα σφάλματα για λεπτομέρειες.
Μήνυμα 8939, Επίπεδο 16, Πολιτεία 98, Γραμμή 1
Σφάλμα πίνακα: Αναγνωριστικό αντικειμένου 1883153754, αναγνωριστικό ευρετηρίου 0, αναγνωριστικό διαμερίσματος 72057594054246400, αναγνωριστικό μονάδας κατανομής 72057594061651968 (τύπος δεδομένων στη σειρά), σελίδα (1: 20455). Η δοκιμή (IS_OFF (BUF_IOERR, pBUF-> bstat)) απέτυχε. Οι τιμές είναι 29493257 και -4.
Το CHECKDB βρήκε 0 σφάλματα κατανομής και 2 σφάλματα συνέπειας στο "crash" του πίνακα (Αναγνωριστικό αντικειμένου 1883153754).
Το CHECKDB βρήκε 0 σφάλματα κατανομής και 2 σφάλματα συνέπειας στη βάση δεδομένων "AdventureWorks".
Το repair_allow_data_loss είναι το ελάχιστο επίπεδο επιδιόρθωσης για τα σφάλματα που εντοπίστηκαν από το DBCC CHECKDB (AdventureWorks).
V σε αυτήν την περίπτωσητα δεδομένα στον ίδιο τον σωρό είναι κατεστραμμένα (αναγνωριστικό ευρετηρίου = 0), επομένως ο SQL Server δεν θα μπορεί να ανακτήσει αυτά τα δεδομένα.
Τώρα έχουμε τρεις επιλογές:

1. Αποδεχτείτε την απώλεια δεδομένων και εκτελέστε το DBCC CHECKDB ("AdventureWorks", REPAIR_ALLOW_DATA_LOSS)
2. Δημιουργήστε αντίγραφο ασφαλείας του ενεργού τμήματος του αρχείου καταγραφής συναλλαγών και επαναφέρετε ολόκληρη τη βάση δεδομένων - δεν θα υπάρξει απώλεια δεδομένων ως αποτέλεσμα, αλλά θα χρειαστεί πολύς χρόνος
3. Δημιουργήστε αντίγραφο ασφαλείας του ενεργού τμήματος του αρχείου καταγραφής συναλλαγών και επαναφέρετε μόνο μία (!) Κατεστραμμένη σελίδα

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

Ανάκτηση κατεστραμμένης σελίδας

Πρώτα απ 'όλα, πρέπει να δημιουργήσουμε ένα αντίγραφο ασφαλείας του τελικού τμήματος του αρχείου καταγραφής συναλλαγών (tail backup). Ταυτόχρονα, εάν έχετε Enterprise Edition, δεν μπορείτε να προσθέσετε την παράμετρο NORECOVERY, η οποία θα μεταφέρει τη βάση δεδομένων σε κατάσταση "επαναφοράς", καθώς αυτή η έκδοση υποστηρίζει την ανάκτηση σελίδων σε απευθείας σύνδεση. Επιπλέον, εάν τα αντίγραφα ασφαλείας του αρχείου καταγραφής συναλλαγών σας εκτελούνται σε τακτική βάση, ώστε να μην σπάσει η αλυσίδα καταγραφής, στην Enterprise Edition, μπορείτε να δημιουργήσετε αντίγραφο ασφαλείας COPY_ONLY.
Ακολουθώ τη διαδρομή ανάκτησης εκτός σύνδεσης και εκτελώ:
BACKUP LOG AdventureWorks TO DISK = "D: \ tmp \ aw_backups \ aw_log_fail3.trn" ΜΕ ΚΑΜΙΑ ΑΝΑΚΤΗΣΗ


Τώρα, μπορείτε να ανακτήσετε την κατεστραμμένη σελίδα. Πρώτα απ 'όλα, χρησιμοποιούμε ένα πλήρες αντίγραφο ασφαλείας (aw_full_ok1.bak):

ΕΠΑΝΑΦΟΡΑ ΒΑΣΗΣ ΔΕΔΟΜΕΝΩΝ AdventureWorks PAGE = "1: 20455" ΑΠΟ ΔΙΣΚΟ = "D: \ tmp \ aw_backups \ aw_full_ok1.bak" ΜΕ ΚΑΜΙΑ ΑΝΑΚΤΗΣΗ
Ως αποτέλεσμα, έχουμε:

Σημειώστε ότι πρέπει να χρησιμοποιήσετε την επιλογή NORECOVERY καθώς δεν έχουμε ακόμη δημιουργήσει αντίγραφα ασφαλείας του αρχείου καταγραφής συναλλαγών σε αυτήν.
RESTORE LOG AdventureWorks FROM DISK = "D: \ tmp \ aw_backups \ aw_log_ok1.trn" ΜΕ NORECOVERY και
ΕΠΑΝΑΦΟΡΑ LOG AdventureWorks FROM DISK = "D: \ tmp \ aw_backups \ aw_log_fail3.trn" ΜΕ ΑΝΑΚΤΗΣΗ


Όλα φαίνονται να είναι επιτυχημένα, εκτελέστε το DBCC CHECKDB και ...


Η ανάκτηση ήταν επιτυχής.
Λάβετε υπόψη ότι ο χρόνος διακοπής λειτουργίας μειώνεται λόγω του γεγονότος ότι δεν επαναφέρουμε ολόκληρη τη βάση δεδομένων από ένα πλήρες αντίγραφο ασφαλείας, αλλά μόνο από κατεστραμμένες σελίδες (αν αποκαθιστούσα ολόκληρο το αντίγραφο ασφαλείας, το αντίγραφο ασφαλείας θα επαναφερόταν σε 8,5 δευτερόλεπτα, αλλά από μεγαλύτερο μέγεθος DB - τόσο μεγαλύτερη είναι η διαφορά ώρας). Οι τυχεροί με το SQL Server Enterprise Edition που χρησιμοποιούν ανάκτηση σε απευθείας σύνδεση θα εξοικονομήσουν χρόνο για την ανάκτηση από τα αντίγραφα ασφαλείας των αρχείων καταγραφής και με την ανάκτηση εκτός σύνδεσης, δυστυχώς, θα υποβληθούν σε επεξεργασία ολόκληρα τα αρχεία καταγραφής.
Θα πρέπει επίσης να προστεθεί ότι στον SQL Server 2005, 2008, 2008 R2, η επαναφορά μιας μεμονωμένης σελίδας είναι δυνατή μόνο με χρήση T-SQL, στο Denali κατέστη δυνατό να γίνει αυτό μέσω του GUI.

Τι κι αν, τελικά, DBCC CHECKDB;

Για κάθε ενδεχόμενο, αποφάσισα να ελέγξω τι θα κάνει ο SQL Server εάν εκτελώ το DBCC CHECKDB με την παράμετρο REPAIR_ALLOW_DATA_LOSS. Ίδιο σφάλμα:


Αρχικά, μεταφέρουμε τη βάση δεδομένων στη λειτουργία SINGLE_USER:
ALTER DATABASE AdventureWorks SET SINGLE_USER Και, στη συνέχεια, ξεκινήστε την ανάκτηση:
DBCC CHECKDB ("AdventureWorks", REPAIR_ALLOW_DATA_LOSS) ΜΕ NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Ως αποτέλεσμα:
Επιδιόρθωση: Η σελίδα (1: 20455) έχει εκχωρηθεί από το αναγνωριστικό αντικειμένου 1883153754, αναγνωριστικό ευρετηρίου 0, αναγνωριστικό διαμερίσματος 72057594054246400, αναγνωριστικό μονάδας κατανομής 72057594061651968 (τύπος δεδομένων στη σειρά).
Ναι, ο SQL Server διέγραψε τη "μολυσμένη" σελίδα. Μεταφέρουμε τη βάση δεδομένων στη λειτουργία MULTI_USER ώστε να είναι διαθέσιμη σε όλους και να ελέγξουμε τι λείπει:

Λαμβάνοντας υπόψη ότι το μέγεθος σελίδας στον SQL Server είναι 8KB και είναι λίγο λιγότερο διαθέσιμο για δεδομένα χρήστη, τότε όλα είναι φυσικά, ο πίνακας "έχασε βάρος" κατά 7 εγγραφές (στην αρχή υπήρχαν 99999). Δεδομένου ότι αυτός ο πίνακας δεν είχε ομαδοποιημένο ευρετήριο, τα δεδομένα μπορούσαν να αποθηκευτούν με αυθαίρετη σειρά, π.χ. δεν μπορούσαμε καν να μάθουμε ποια δεδομένα θα χαθούν.

Γιατί, τελικά, όχι μετάφραση;

Λοιπόν, γιατί δεν είναι ακόμα μετάφραση, αλλά ανάρτηση «βασισμένη σε». Γεγονός είναι ότι, στον δημόσιο τομέα, δεν υπάρχει άρθρο "Επαναφορά σελίδας" από την Gail Shaw. Υπάρχει μια τέτοια ενότητα στο βιβλίο SQL Server MVP Deep Dives vol.2, το οποίο πωλείται για αρκετά σημαντικό χρηματικό ποσό (αλλά, φυσικά, βρίσκεται εύκολα στο Διαδίκτυο) και δεν είμαι σίγουρος ότι η δημοσίευση μιας μετάφρασης είναι , χμ... σωστά ή κάτι τέτοιο.
Γενικά, διάβασα το άρθρο, σημείωσα τα κύρια σημεία και μετά έγραψα το κείμενο μόνος μου και, στην πορεία, έκανα ένα πείραμα για την αποκατάσταση. Ελπίζω ότι κάποιος βρήκε αυτή την εμπειρία χρήσιμη.
Και κύριοι, ελπίζω ειλικρινά ότι εάν αποφασίσετε να επαναλάβετε αυτό το πείραμα, θα είστε εξαιρετικά προσεκτικοί (για παράδειγμα, δεν θα πειραματιστείτε με την κύρια βάση δεδομένων στον διακομιστή παραγωγής). Να θυμάστε ότι δεν είμαι υπεύθυνος για τις πράξεις σας.

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

Επαναφορά βάσεων δεδομένων στον SQL Server

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

Ο SQL Server παρέχει πολλές επιλογές για ανάκτηση βάσης δεδομένων. Πρώτον, πρόκειται για επαναφορά ολόκληρης της βάσης δεδομένων - μπορεί να διαρκέσει πολύ χρόνο (ανάλογα με το μέγεθος της βάσης δεδομένων και την ταχύτητα των σκληρών δίσκων). Δεύτερον, ανάκτηση μεμονωμένων ομάδων αρχείων ή αρχείων, εάν η βάση δεδομένων σας αποτελείται από πολλές ομάδες αρχείων (ή, κατά συνέπεια, αρχεία). Σε αυτήν την περίπτωση, είναι δυνατή η επαναφορά μόνο των κατεστραμμένων τμημάτων της βάσης δεδομένων χωρίς να επηρεαστούν τα υπόλοιπα. Αυτοί οι δύο τύποι ανάκτησης βάσεων δεδομένων χρησιμοποιούνται αρκετά συχνά και δεν θα τεθούν στο μέλλον.
Τρίτον, στον SQL Server 2005, κατέστη δυνατή η επαναφορά μεμονωμένων σελίδων βάσης δεδομένων - σε αυτήν την περίπτωση, μόνο οι καθορισμένες σελίδες θα αποκατασταθούν από το αντίγραφο ασφαλείας. Μια τέτοια ανάκτηση θα είναι ιδιαίτερα σημαντική εάν το DBCC CHECKDB βρει αρκετές κατεστραμμένες σελίδες σε κάποιο τεράστιο τραπέζι που "κείνται" σε ένα βαρύ αρχείο. Λόγω του γεγονότος ότι δεν θα γίνει επαναφορά ολόκληρου του αρχείου, ούτε καν ολόκληρος ο πίνακας, αλλά μόνο μερικές σελίδες, ο χρόνος διακοπής λειτουργίας μπορεί να μειωθεί σημαντικά.

Απαιτήσεις και Περιορισμοί

Μοντέλο ανάκτησης και διαθεσιμότητα αντιγράφων καταγραφής συναλλαγών

Το πιο σημαντικό πράγμα που πρέπει να θυμάστε είναι ότι για την ανάκτηση μεμονωμένων σελίδων, η βάση δεδομένων πρέπει να χρησιμοποιεί το μοντέλο πλήρους ανάκτησης ή το μοντέλο ανάκτησης μαζικής καταγραφής. Εάν οι βάσεις δεδομένων σας βρίσκονται σε ένα απλό (απλό) μοντέλο ανάκτησης, τότε ενδέχεται να μην διαβάσετε περαιτέρω.
Η δεύτερη απαίτηση είναι ότι τα πλήρη αντίγραφα ασφαλείας και τα αντίγραφα καταγραφής συναλλαγών πρέπει να αποτελούν μια άθραυστη αλυσίδα καταγραφής. Εάν δεν εκτελέσετε ποτέ την εντολή BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) και δεν μεταβείτε στο απλό μοντέλο ανάκτησης για να συρρικνώσετε το αρχείο καταγραφής συναλλαγών και έχετε ΟΛΑ τα αντίγραφα ασφαλείας του αρχείου καταγραφής συναλλαγών από την τελευταία δωρεάν δημιουργία αντιγράφων ασφαλείας πλήρους σελίδας (συμπεριλαμβανομένου αυτού του πιο ολοκληρωμένου backup) - δεν χρειάζεται να ανησυχείτε για την αλυσίδα των κορμών.
Σε ένα μοντέλο ανάκτησης με μαζική καταγραφή, θεωρητικά, η ανάκτηση μεμονωμένων σελίδων θα πρέπει να λειτουργεί καλά, εφόσον πληρούνται οι προϋποθέσεις που περιγράφονται παραπάνω και οι σελίδες που αποκαθίστανται δεν έχουν τροποποιηθεί από λειτουργίες που εκτελούνται με ελάχιστη καταγραφή.

Εκδόσεις SQL Server

Η ανάκτηση σελίδας είναι δυνατή σε οποιαδήποτε έκδοση του SQL Server, αλλά για τις εκδόσεις Enterprise και Developer είναι δυνατή η ανάκτηση κατεστραμμένων σελίδων on-line, π.χ. μπορείτε να αποκτήσετε πρόσβαση στη βάση δεδομένων κατά την ανάκτηση (και επιπλέον, μπορείτε ακόμη και να ανατρέξετε στον πίνακα στον οποίο ανήκουν οι σελίδες που αποκαθίστανται αυτήν τη στιγμή, εάν αυτές οι ίδιες οι σελίδες δεν «επηρεαστούν» - διαφορετικά, το αίτημα θα αποτύχει). Για τις εκδόσεις «κάτω» Enterprise Edition, η ανάκτηση σελίδων πραγματοποιείται εκτός σύνδεσης και η βάση δεδομένων καθίσταται μη διαθέσιμη κατά την ανάκτηση.

Κατεστραμμένος τύπος σελίδας

Σε περίπτωση που οι σελίδες ευρετηρίου ή οι σελίδες δεδομένων καταστραφούν, η ανάκτησή τους είναι δυνατή ηλεκτρονικά στην έκδοση Enterprise.
Οι σελίδες που περιέχουν κρίσιμους πίνακες συστήματος μπορούν να αποκατασταθούν, αλλά η βάση δεδομένων, όταν αποκατασταθεί, δεν θα είναι διαθέσιμη σε καμία έκδοση του SQL Server.
Οι "κάρτες τοποθέτησης" δεν μπορούν να αποκατασταθούν "ξεχωριστά". Εάν οι σελίδες GAM, SGAM, PFS, ML, DIFF είναι κατεστραμμένες, πρέπει να επαναφέρετε ολόκληρη τη βάση δεδομένων. Η μόνη εξαίρεση είναι οι σελίδες IAM. Αν και αναφέρονται ως "χάρτες τοποθέτησης", περιγράφουν μόνο έναν πίνακα, όχι ολόκληρη τη βάση δεδομένων και μπορούν να επαναφερθούν.
Η σελίδα εκκίνησης της βάσης δεδομένων (σελίδα 9 στο 1ο αρχείο βάσης δεδομένων) και η σελίδα κεφαλίδας του αρχείου (σελίδα 0 σε κάθε αρχείο) δεν μπορούν να αποκατασταθούν "ξεχωριστά", εάν είναι κατεστραμμένα, θα πρέπει να επαναφέρετε ολόκληρη τη βάση δεδομένων.

Στην πραγματικότητα, ανάκαμψη

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

Χαλάμε τη βάση δεδομένων

Για πειραματισμό, θα χρησιμοποιήσω τη βάση δεδομένων AdventureWorks που αποστέλλεται με τον SQL Server. Εάν δεν το έχετε εγκαταστήσει, μπορείτε να το κατεβάσετε εάν θέλετε. Το μεταφράζω στο μοντέλο πλήρους ανάκτησης:
ALTER DATABASE AdventureWorks SET RECOVERY FULL Φροντίζω να μην υπάρχουν ακόμη σφάλματα σε αυτό:
DBCC CHECKDB ("AdventureWorks") ΜΕ NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY και δημιουργήστε ένα πλήρες αντίγραφο ασφαλείας:
BACKUP DATABASE AdventureWorks TO DISK = "D: \ tmp \ aw_backups \ aw_full_ok1.bak"

Σε αυτήν τη βάση δεδομένων, δημιουργώ έναν πίνακα σφαλμάτων.
CREATE TABLE crash (txt varchar (1000)) Θα χαλάσουμε το πεδίο varchar για να ελέγξουμε τι θα συμβεί αν ο SQL Server βρει ξαφνικά σε αυτόν τα δεδομένα που έγραψε ο ίδιος εκεί.
Πριν χαλάσεις κάτι, πρέπει να το γεμίσεις με κάτι. Φορτώνω τα αριστερά δεδομένα στον πίνακα που δημιουργήθηκε.
ΡΥΘΜΙΣΕ ΜΗ ΛΟΓΑΡΙΑΣΜΟ ΣΤΗ ΔΗΛΩΣΗ @i INT SET @i = 1 ΕΝΩ @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE("a", 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:
BACKUP LOG AdventureWorks TO DISK = "D: \ tmp \ aw_backups \ aw_log_ok1.trn"

Τώρα ας αλλάξουμε λίγο τα δεδομένα:

Όλα λοιπόν είναι έτοιμα. Αποσυνδέστε τη βάση δεδομένων και ανοίξτε το αρχείο mdf FAR (ή οτιδήποτε σας βολεύει περισσότερο), αναζητήστε τη συμβολοσειρά "zzzzzzzz" σε αυτό και αντικαταστήστε αρκετούς "z" με αυθαίρετους χαρακτήρες:


Τώρα που η βάση δεδομένων είναι κατεστραμμένη, τη συνδέουμε. Και, ναι, θυμάμαι ότι στο προηγούμενο άρθρο αναφέρθηκε ξεκάθαρα ότι η αποσύνδεση / επισύναψη της βάσης δεδομένων δεν αξίζει τον κόπο. Αλλά στην περίπτωσή μας είναι απολύτως "ασφαλές" - η βάση δεδομένων στο "ύποπτο" δεν θα πέσει.

Ψάχνετε για σφάλματα

Έτσι, η κατεστραμμένη βάση δεδομένων επέστρεψε με επιτυχία στην υπηρεσία. Ας εκτελέσουμε ξανά τον έλεγχο ακεραιότητας:
DBCC CHECKDB ("AdventureWorks") WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Ως αποτέλεσμα, αυτό που περιμέναμε ( φροντίστε να θυμάστε τους αριθμούς των κατεστραμμένων σελίδων!):

Μήνυμα 8928, Επίπεδο 16, Πολιτεία 1, Γραμμή 1
Αναγνωριστικό αντικειμένου 1883153754, αναγνωριστικό ευρετηρίου 0, αναγνωριστικό διαμερίσματος 72057594054246400, αναγνωριστικό μονάδας κατανομής 72057594061651968 (τύπος δεδομένων στη σειρά): Δεν ήταν δυνατή η επεξεργασία της σελίδας (1: 20455). Δείτε άλλα σφάλματα για λεπτομέρειες.
Μήνυμα 8939, Επίπεδο 16, Πολιτεία 98, Γραμμή 1
Σφάλμα πίνακα: Αναγνωριστικό αντικειμένου 1883153754, αναγνωριστικό ευρετηρίου 0, αναγνωριστικό διαμερίσματος 72057594054246400, αναγνωριστικό μονάδας κατανομής 72057594061651968 (τύπος δεδομένων στη σειρά), σελίδα (1: 20455). Η δοκιμή (IS_OFF (BUF_IOERR, pBUF-> bstat)) απέτυχε. Οι τιμές είναι 29493257 και -4.
Το CHECKDB βρήκε 0 σφάλματα κατανομής και 2 σφάλματα συνέπειας στο "crash" του πίνακα (Αναγνωριστικό αντικειμένου 1883153754).
Το CHECKDB βρήκε 0 σφάλματα κατανομής και 2 σφάλματα συνέπειας στη βάση δεδομένων "AdventureWorks".
Το repair_allow_data_loss είναι το ελάχιστο επίπεδο επιδιόρθωσης για τα σφάλματα που εντοπίστηκαν από το DBCC CHECKDB (AdventureWorks).
Σε αυτήν την περίπτωση, τα ίδια τα δεδομένα είναι κατεστραμμένα στο σωρό (αναγνωριστικό ευρετηρίου = 0), επομένως ο SQL Server δεν θα μπορεί να ανακτήσει αυτά τα δεδομένα.
Τώρα έχουμε τρεις επιλογές:

1. Αποδεχτείτε την απώλεια δεδομένων και εκτελέστε το DBCC CHECKDB ("AdventureWorks", REPAIR_ALLOW_DATA_LOSS)
2. Δημιουργήστε αντίγραφο ασφαλείας του ενεργού τμήματος του αρχείου καταγραφής συναλλαγών και επαναφέρετε ολόκληρη τη βάση δεδομένων - δεν θα υπάρξει απώλεια δεδομένων ως αποτέλεσμα, αλλά θα χρειαστεί πολύς χρόνος
3. Δημιουργήστε αντίγραφο ασφαλείας του ενεργού τμήματος του αρχείου καταγραφής συναλλαγών και επαναφέρετε μόνο μία (!) Κατεστραμμένη σελίδα

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

Ανάκτηση κατεστραμμένης σελίδας

Πρώτα απ 'όλα, πρέπει να δημιουργήσουμε ένα αντίγραφο ασφαλείας του τελικού τμήματος του αρχείου καταγραφής συναλλαγών (tail backup). Ταυτόχρονα, εάν έχετε Enterprise Edition, δεν μπορείτε να προσθέσετε την παράμετρο NORECOVERY, η οποία θα μεταφέρει τη βάση δεδομένων σε κατάσταση "επαναφοράς", καθώς αυτή η έκδοση υποστηρίζει την ανάκτηση σελίδων σε απευθείας σύνδεση. Επιπλέον, εάν τα αντίγραφα ασφαλείας του αρχείου καταγραφής συναλλαγών σας εκτελούνται σε τακτική βάση, ώστε να μην σπάσει η αλυσίδα καταγραφής, στην Enterprise Edition, μπορείτε να δημιουργήσετε αντίγραφο ασφαλείας COPY_ONLY.
Ακολουθώ τη διαδρομή ανάκτησης εκτός σύνδεσης και εκτελώ:
BACKUP LOG AdventureWorks TO DISK = "D: \ tmp \ aw_backups \ aw_log_fail3.trn" ΜΕ ΚΑΜΙΑ ΑΝΑΚΤΗΣΗ


Τώρα, μπορείτε να ανακτήσετε την κατεστραμμένη σελίδα. Πρώτα απ 'όλα, χρησιμοποιούμε ένα πλήρες αντίγραφο ασφαλείας (aw_full_ok1.bak):

ΕΠΑΝΑΦΟΡΑ ΒΑΣΗΣ ΔΕΔΟΜΕΝΩΝ AdventureWorks PAGE = "1: 20455" ΑΠΟ ΔΙΣΚΟ = "D: \ tmp \ aw_backups \ aw_full_ok1.bak" ΜΕ ΚΑΜΙΑ ΑΝΑΚΤΗΣΗ
Ως αποτέλεσμα, έχουμε:

Σημειώστε ότι πρέπει να χρησιμοποιήσετε την επιλογή NORECOVERY καθώς δεν έχουμε ακόμη δημιουργήσει αντίγραφα ασφαλείας του αρχείου καταγραφής συναλλαγών σε αυτήν.
RESTORE LOG AdventureWorks FROM DISK = "D: \ tmp \ aw_backups \ aw_log_ok1.trn" ΜΕ NORECOVERY και
ΕΠΑΝΑΦΟΡΑ LOG AdventureWorks FROM DISK = "D: \ tmp \ aw_backups \ aw_log_fail3.trn" ΜΕ ΑΝΑΚΤΗΣΗ


Όλα φαίνονται να είναι επιτυχημένα, εκτελέστε το DBCC CHECKDB και ...


Η ανάκτηση ήταν επιτυχής.
Λάβετε υπόψη ότι ο χρόνος διακοπής λειτουργίας μειώνεται λόγω του γεγονότος ότι δεν επαναφέρουμε ολόκληρη τη βάση δεδομένων από ένα πλήρες αντίγραφο ασφαλείας, αλλά μόνο από κατεστραμμένες σελίδες (αν επαναφέρω ολόκληρο το αντίγραφο ασφαλείας, το αντίγραφο ασφαλείας θα επαναφερόταν σε 8,5 δευτερόλεπτα, αλλά όσο μεγαλύτερο είναι το μέγεθος της βάσης δεδομένων , τόσο θα υπάρχει μεγαλύτερη διαφορά ώρας). Οι τυχεροί με το SQL Server Enterprise Edition που χρησιμοποιούν ανάκτηση σε απευθείας σύνδεση θα εξοικονομήσουν χρόνο για την ανάκτηση από τα αντίγραφα ασφαλείας των αρχείων καταγραφής και με την ανάκτηση εκτός σύνδεσης, δυστυχώς, θα υποβληθούν σε επεξεργασία ολόκληρα τα αρχεία καταγραφής.
Θα πρέπει επίσης να προστεθεί ότι στον SQL Server 2005, 2008, 2008 R2, η επαναφορά μιας μεμονωμένης σελίδας είναι δυνατή μόνο με χρήση T-SQL, στο Denali κατέστη δυνατό να γίνει αυτό μέσω του GUI.

Τι κι αν, τελικά, DBCC CHECKDB;

Για κάθε ενδεχόμενο, αποφάσισα να ελέγξω τι θα κάνει ο SQL Server εάν εκτελώ το DBCC CHECKDB με την παράμετρο REPAIR_ALLOW_DATA_LOSS. Ίδιο σφάλμα:


Αρχικά, μεταφέρουμε τη βάση δεδομένων στη λειτουργία SINGLE_USER:
ALTER DATABASE AdventureWorks SET SINGLE_USER Και, στη συνέχεια, ξεκινήστε την ανάκτηση:
DBCC CHECKDB ("AdventureWorks", REPAIR_ALLOW_DATA_LOSS) ΜΕ NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY Ως αποτέλεσμα:
Επιδιόρθωση: Η σελίδα (1: 20455) έχει εκχωρηθεί από το αναγνωριστικό αντικειμένου 1883153754, αναγνωριστικό ευρετηρίου 0, αναγνωριστικό διαμερίσματος 72057594054246400, αναγνωριστικό μονάδας κατανομής 72057594061651968 (τύπος δεδομένων στη σειρά).
Ναι, ο SQL Server διέγραψε τη "μολυσμένη" σελίδα. Μεταφέρουμε τη βάση δεδομένων στη λειτουργία MULTI_USER ώστε να είναι διαθέσιμη σε όλους και να ελέγξουμε τι λείπει:

Λαμβάνοντας υπόψη ότι το μέγεθος σελίδας στον SQL Server είναι 8KB και είναι λίγο λιγότερο διαθέσιμο για δεδομένα χρήστη, τότε όλα είναι φυσικά, ο πίνακας "έχασε βάρος" κατά 7 εγγραφές (στην αρχή υπήρχαν 99999). Δεδομένου ότι αυτός ο πίνακας δεν είχε ομαδοποιημένο ευρετήριο, τα δεδομένα μπορούσαν να αποθηκευτούν με αυθαίρετη σειρά, π.χ. δεν μπορούσαμε καν να μάθουμε ποια δεδομένα θα χαθούν.

Γιατί, τελικά, όχι μετάφραση;

Λοιπόν, γιατί δεν είναι ακόμα μετάφραση, αλλά ανάρτηση «βασισμένη σε». Γεγονός είναι ότι, στον δημόσιο τομέα, δεν υπάρχει άρθρο "Επαναφορά σελίδας" από την Gail Shaw. Υπάρχει μια τέτοια ενότητα στο βιβλίο SQL Server MVP Deep Dives vol.2, το οποίο πωλείται για αρκετά σημαντικό χρηματικό ποσό (αλλά, φυσικά, βρίσκεται εύκολα στο Διαδίκτυο) και δεν είμαι σίγουρος ότι η δημοσίευση μιας μετάφρασης είναι , χμ... σωστά ή κάτι τέτοιο.
Γενικά, διάβασα το άρθρο, σημείωσα τα κύρια σημεία και μετά έγραψα το κείμενο μόνος μου και, στην πορεία, έκανα ένα πείραμα για την αποκατάσταση. Ελπίζω ότι κάποιος βρήκε αυτή την εμπειρία χρήσιμη.
Και κύριοι, ελπίζω ειλικρινά ότι εάν αποφασίσετε να επαναλάβετε αυτό το πείραμα, θα είστε εξαιρετικά προσεκτικοί (για παράδειγμα, δεν θα πειραματιστείτε με την κύρια βάση δεδομένων στον διακομιστή παραγωγής). Να θυμάστε ότι δεν είμαι υπεύθυνος για τις πράξεις σας.