Γιατί καθυστερεί η επανεκκίνηση του SQL Server instance;
Πιστοποιήσεις:
- Πώς αυτοματοποιούμε τη διαδικασία ελέγχου ακεραιότητας των βάσεων δεδομένων σε SQL Server χωρίς την χρήση maintenance plan - 10 Μάιος 2024
- Πώς μπορούμε να συνδέσουμε Oracle Database με SQL Server με χρήση Oracle Gateway σε Windows - 5 Απρίλιος 2024
- Πώς μπορούμε να λαμβάνουμε email κάθε φορά που ξεπερνάει ένα όριο η μνήμη PGA σε βάση δεδομένων της Oracle - 1 Μάρτιος 2024
Σε αυτό το άρθρο θα δούμε αναλυτικά μερικούς από τους πιο συχνούς λόγους που μπορεί να αργεί η επανεκκίνηση ενός SQL Server instance και τι μπορούμε να κάνουμε ώστε να βελτιώσουμε τον χρόνο αυτό άνα περίπτωση.
Χρήση πολύ μεγάλου Transaction Log με μεγάλο κατακερματισμό σε VLFs
Όλες οι συναλλαγές που γίνονται σε μία βάση δεδομένων στον SQL Server καταγράφονται σε ένα αρχείο που ονομάζεται Transaction Log, ο σκοπός του είναι να καταγράφει τις συναλλαγές ώστε να έχουμε την δυνατότητα να κάνουμε rollback συναλλαγές αλλά και recovery των βάσεων δεδομένων μετά από κάποια πτώση του SQL Server instance. Το μέγεθος του transaction log δεν είναι σταθερό, όσο εκτελούμε περισσότερες και πιο βαριές συναλλαγές αυξάνεται. Ο τρόπος που αυξάνεται είναι με την δημιουργία μικρών αρχείων που ονομάζονται VLF (Virtual Log Files) κάθε φορά που μεγαλώνει το transaction log με manual ή auto-growth δημιουργούνται καινούργια VLFs.
Όταν έχουμε πολλά VLFs στο transaction log της βάσης δεδομένων μας δημιουργείται κατακερματισμός και πέφτει η απόδοση ειδικά στον τομέα του recovery όπως κατά την εκκίνηση του SQL Server instance.
Η λύση σε αυτό το πρόβλημα είναι να κάνουμε SHRINK το transaction log file στο μικρότερο δυνατό μέγεθος που θα μας επιτρέπει και να το αυξήσουμε manual στο μέγεθος που θεωρούμε σωστό ότι πρέπει να έχει, χωρίς να αφήσουμε να κάνει πάλι πολλά μικρά auto-growth του αρχείου που θα μας οδηγήσει πάλι στο αρχικό πρόβλημα.
Χρήση Full Recovery Model χωρίς συχνό Transaction Log Backup
Ένα πολύ συχνό φαινόμενο είναι να βλέπουμε βάσεις δεδομένων που έχουν επιλεγμένο ως recovery model το FULL, να μην παίρνονται transaction log backup ή να μην είναι αρκετά συχνό. Όταν μία βάση δεδομένων είναι σε FULL recovery model το transaction log που καταγράφει όλες τις συναλλαγές, δεν αδειάζει μέχρις ότου το έχουμε πάρει transaction log backup. Αυτό έρχεται σε αντίθεση με το SIMPLE recovery model που αδειάζει με το που ολοκληρωθεί (γίνει commit) μία συναλλαγή και γίνει CHECKPOINT με τα δεδομένα του στα datafiles.
Αυτό συμβαίνει διότι με το FULL recovery model που έχουμε επιλέξει ζητάμε από τον SQL Server να έχει την δυνατότητα χρησιμοποιόντας τα backups που έχουμε πάρει να κάνει Point in Time Recovery, δηλαδή να έχει την δυνατότητα να γυρίσει πίσω σε οποιαδήποτε χρονική στιγμή.
Σαν αποτέλεσμα για όσο δεν έχουμε πάρει transaction log backup το μέγεθος του transaction log να μεγαλώνει ατέρμονα στον δίσκο δημιουργώντας όλο και περισσότερα VLFs (Virtual Log Files).
Η λύση σε αυτή τη περίπτωση για να μην αυξάνονται τα VLFs και το transaction log αντίστοιχα είναι να έχουμε πραγματίσει συχνά transaction log backups (άνα 5 έως 60 λεπτά).
Επανεκκίνηση SQL Server Instance κάτα την διάρκεια Kill και Rollback operation
Συνήθως ο SQL Server γνωρίζει καλύτερα από εμάς και δεν υπάρχουν shortcuts. Αν πάμε και κάνουμε KILL ένα session που εκτελεί ένα πολύ μεγάλο query (π.χ. μαζικά deletes) χωρίς να έχουμε κάνει πρώτα COMMIT, θα πραγματοποιήσει ROLLBACK ολόκληρης της συναλλαγής μέσα από το transaction log και αυτή η διαδικασία θα διαρκέσει όσο και η εκτέλεση της. Αν τώρα πάμε και κάνουμε force επανεκκίνηση όλοκληρου του instance γιατί πιστεύουμε οτι θα μας γλυτώσει χρόνο, το instance δεν θα ξεκινήσει μέχρι να ολοκληρωθεί το ROLLBACK της συναλλαγής. Οπότε αντί να λύσουμε το πρόβλημα θα το μεγαλώσουμε.
Σε αυτή τη περίπτωση απλά περιμένουμε να ολοκληρωθεί το ROLLBACK και φροντίζουμε σε μεγάλα transactions να έχουμε loops με COMMIT άνα κάποιες εγγραφές ώστε να μην χρειάζεται χρονοβόρο recovery σε περίπτωση που τερματίσουμε το session αυτό.
Χρήση Query Store
Τα δεδομένα που προκύπτουν από την χρήση του Query Store καταγράφονται πρώτα στην μνήμη και άνα τακτά χρονικά διαστήματα μεταφέρονται στον δίσκο, το πόσο συχνά συμβάινει αυτό ορίζεται απο την παράμετρο DATA_FLUSH_INTERVAL_SECONDS. Η default τιμή για την διαδικασία αυτή είναι τα 15 λεπτά. Έτσι κατά την επανεκκίνηση του instance ή ενός failover σε ένα Always On Availability Group, θα περιμένει πρώτα να γραφτεί η πληροφορία αυτή από την μνήμη στον δίσκο ώστε να προχωρήση η διαδικασία.
Η λύση σε αυτό το πρόβλημα για εκδόσεις SQL Server πριν τον SQL Server 2019, είναι η ενεργοποίηση του trace flag 7745, με το οποίο δεν θα περιμένει να γραφτούν τα δεδομένα από την μνήμη στον δίσκο αλλά θα προχωρήσει άμεσα στον τερματισμό του instance. Αυτό σαν αποτέλεσμα έχει να χαθούν τα δεδομένα των τελευταίων λεπτών του Query Store αλλά θα επιταχύνει την διαδικασία.
Χρήση In-Memory πινάκων (Hekaton)
Όταν κάνουμε χρήση πίνακα που έχει όλα του τα δεδομένα φορτώμένα στην μνήμη (In-Memory) με την παράμετρο DURABILITY=SCHEMA_AND_DATA (που είναι η default τιμή), ορίζουμε ότι θέλουμε να κρατάμε τα δεδομένα και στον δίσκο ώστε έπειτα από επανεκκίνηση του instance να μην χάνοντε τα δεδομένα αυτά αλλά να επανέρχονται στην μνήμη. Σαν αποτέλεσμα κάτα την επανεκκίνηση του instance θα πρέπει να περιμένουμε να φορτωθούν τα δεδομένα αυτά από τον δίσκο στην μνήμη.
Για να βελτιωθεί η αναμονή βοηθάει η χρήση της εντολής CHECKPOINT πριν την επανεκκίνηση, ώστε όλα τα δεδομένα να έχουν γραφτεί στα datafiles και να μην χρειάζεται να γίνει πρώτα recovery από το transaction log πρωτού φορτωθούν και πάλι στην μνήμη.
