Συμπτώματα
Ας υποθέσουμε ότι έχετε εγκαταστήσει τον Microsoft SQL Server 2014, 2016 ή 2017. Ενδέχεται να αντιμετωπίσετε ένα ή περισσότερα από τα ακόλουθα ζητήματα:
-
Η παρουσία του SQL Server εμφανίζεται αδιάφορη και παρουσιάζεται ένα σφάλμα "μη δώσουν Scheduler". Ίσως χρειαστεί να επανεκκινήσετε τον διακομιστή για να τον ανακτήσετε.
-
Η επαναφορά μιας συναλλαγής μπορεί να χρειαστεί πολύ χρόνο για να ολοκληρωθεί. Στις περισσότερες περιπτώσεις, η επανεκκίνηση της παρουσίας θα επιτρέψει στη βάση δεδομένων να ανακτήσει πολύ πιο γρήγορα από την επαναφορά. Σημειώστε ότι υπάρχουν πολλοί λόγοι για τους οποίους μπορεί να χρειαστεί πολύς χρόνος για να ολοκληρωθεί μια επαναφορά, ανατρέξτε στην ενότητα "περισσότερες πληροφορίες" παρακάτω για λεπτομέρειες σχετικά με την παρακολούθηση των αναστροφής πριν από την απόπειρα επανεκκίνησης.
-
Ενδέχεται να δείτε τις υψηλές αναμονή στο spinlocks, όπως SOS_OBJECT_STORE.
Επίλυση
Αυτό το πρόβλημα διορθώνεται με τις ακόλουθες αθροιστικές ενημερώσεις για τον SQL Server:
Κάθε νέα αθροιστική ενημέρωση για τον SQL Server περιέχει όλες τις επείγουσες επιδιορθώσεις και όλες τις επιδιορθώσεις ασφαλείας που συμπεριλήφθηκαν στην προηγούμενη αθροιστική ενημέρωση. Ανάληψη ελέγχου των πιο πρόσφατων αθροιστικών ενημερώσεων για τον SQL Server:
Η πιο πρόσφατη αθροιστική ενημέρωση για τον SQL Server 2017
Πληροφορίες για το Service Pack για τον SQL Server
Αυτή η ενημέρωση επιδιορθώνεται στο ακόλουθο Service Pack για τον SQL Server:
Τα Service Pack είναι αθροιστικά. Κάθε νέο Service Pack περιέχει όλες τις επιδιορθώσεις που υπάρχουν σε προηγούμενα Service Pack, μαζί με τυχόν νέες επιδιορθώσεις. Η σύστασή μας είναι να εφαρμόσουμε το πιο πρόσφατο Service Pack και την πιο πρόσφατη αθροιστική ενημέρωση για το συγκεκριμένο Service Pack. Δεν χρειάζεται να εγκαταστήσετε ένα προηγούμενο Service Pack πριν από την εγκατάσταση του πιο πρόσφατου Service Pack. Χρησιμοποιήστε τον πίνακα 1 στο ακόλουθο άρθρο για να βρείτε περισσότερες πληροφορίες σχετικά με το πιο πρόσφατο Service Pack και την πιο πρόσφατη αθροιστική ενημερωμένη έκδοση.
Περισσότερες πληροφορίες
Υπάρχουν πολλοί λόγοι για τους οποίους μια επαναφορά μπορεί να διαρκέσει πολύ χρόνο, όπως μια συναλλαγή μεγάλης διάρκειας, ένας μεγάλος αριθμός VLFs στο αρχείο καταγραφής συναλλαγών, η αργή I/O κ. λπ. Για να επαληθεύσετε ότι το ζήτημα που περιγράφεται σε αυτό το άρθρο είναι η βασική αιτία μιας αργής επαναφοράς, προτείνουμε να χρησιμοποιηθούν οι παρακάτω τεχνικές για την παρακολούθηση της προόδου της λειτουργίας επαναφοράς:
-
Από το sys.dm_exec_requests, προσδιορίστε την session_id της οποίας η εντολή έχει καθοριστεί σε "ΣΚΟΤΩΜΈΝΟ/επαναφορά" και βεβαιωθείτε ότι η περίοδος λειτουργίας συσσωρεύεται και ο χρόνος εισόδου/εξόδου και CPU που υποδηλώνει πρόοδο. Εάν η IO δεν αλλάζει, μπορεί να είναι μια ένδειξη ότι αντιμετωπίζετε το πρόβλημα που περιγράφεται σε αυτό το άρθρο.
-
Sys.dm_tran_database_transactions ερωτήματος για να προσδιορίσετε την τρέχουσα κατάσταση της επαναφοράς χρησιμοποιώντας ένα ερώτημα όπως το εξής:
Επιλέξτε GETDATE () ως CurrentTime, database_transaction_next_undo_lsn, database_transaction_begin_lsn, t.transaction_id, database_transaction_begin_time, database_transaction_log_record_count, db_name (t.database_id)
ΑΠΌ το sys.dm_tran_database_transactions t
ΣΥΜΜΕΤΟΧΉ sys.dm_exec_requests s ΣΕ t.transaction_id = s.transaction_id
ΌΠΟΥ t.database_id = db_id (' <όνομα βάσης δεδομένων') και s.session_id =<Session_id εκτέλεση της λειτουργίας επαναφοράς>
Σημείωση:
Στο παραπάνω ερώτημα,
database_transaction_next_undo_lsn είναι το LSN της επόμενης εγγραφής που θα αναιρέσετε. database_transaction_begin_lsn είναι το LSN της εγγραφής begin για τη συναλλαγή στο αρχείο καταγραφής συναλλαγών.
το database_transaction_next_undo_lsn θα πρέπει να μειώνεται με κάθε στιγμιότυπο αυτού του ερωτήματος. Η επαναφορά θα ολοκληρωθεί με επιτυχία όταν το database_transaction_next_undo_lsn φθάσει database_transaction_begin_lsn.
Ο στόχος εδώ είναι να τραβήξετε μερικά στιγμιότυπα του προηγούμενου ερωτήματος μέσα σε ένα προκαθορισμένο χρονικό διάστημα και, στη συνέχεια, να χρησιμοποιήσετε το Δέλτα του LSNs που έχει υποστεί επεξεργασία σε database_transaction_next_undo_lsn εντός αυτού του χρονικού διαστήματος και να υπολογίσετε το χρόνο που απαιτείται για να υπολογίσετε το χρόνο που θα χρειαστεί για να φτάσει το database_transaction_next_undo_lsn στο database_transaction_begin_lsn.
Εάν η επαναφορά εξελίσσεται με αξιοπρεπή ρυθμό μεταξύ κάθε στιγμιότυπου, προτείνουμε ότι η επαναφορά θα επιτρέπεται να ολοκληρωθεί από μόνη της χωρίς να γίνει επανεκκίνηση της παρουσίας του SQL Server.
Ανατρέξτε στα παρακάτω άρθρα για περισσότερες πληροφορίες σχετικά με την ανάκτηση με μεγάλη διάρκεια:
-
SQL Server (2000, 2005, 2008): ανάκτηση/επαναφορά με μεγαλύτερη διάρκεια από την αναμενόμενη
-
Πώς μια δομή αρχείου καταγραφής μπορεί να επηρεάσει το χρόνο αποκατάστασης της βάσης δεδομένων
-
Παρακολούθηση της προόδου ανάκτησης βάσης δεδομένων με χρήση πληροφοριών από το DMV
Κατάσταση
Η Microsoft έχει επιβεβαιώσει ότι πρόκειται για ένα πρόβλημα στα προϊόντα της Microsoft που παρατίθενται στην ενότητα "ισχύει για".
Αναφορές
Μάθετε περισσότερα σχετικά με την ορολογίαπου χρησιμοποιεί η Microsoft για την περιγραφή ενημερώσεων λογισμικού.
