sqlschool.gr logo

articles

Articles of SQLschool.gr Team

Always On Availability Groups and Transaction Log Shrink operation

Antonios Chatzipavlis
Monday 22 January 2018

Αφορμή για το άρθρο αυτό είναι το ερώτημα ενός μέλους του SQLschool.gr το οποίο αφορούσε το transaction log maintenance και ιδιαίτερα του shrink αυτού μιας database που είναι σε Availability Group.

AlwaysOn Availability Group

Σε ένα AlwaysOn Availability Group (AG) έχω περισσότερα από δύο SQL Server instances όπου το ένα είναι το Primary node και το άλλο ή τα άλλα το secondary(ries) node(s).

Επίσης σε ένα AG μπαίνει μια η περισσότερες databases και αυτή είναι σε Full Recovery model καθώς αυτό μόνο υποστηρίζεται σε AG.

Τέλος κάθε database μπορεί να είναι είτε σε full sync mode που σημαίνει ότι ενέργεια γίνεται στο primary θα πρέπει να ενημερώσει το secondary για να θεωρηθεί ολοκληρωμένη είτε σε async mode που σημαίνει ότι όποια ενέργεια γίνεται στο primary θεωρείται ολοκληρωμένη και ασύγχρονα ενημερώνετε το secondary.

Για την υλοποίηση αυτών ο SQL Server χρησιμοποιεί το transaction log και στην ουσία μεταφέρει από το primary στο secondary Log Blocks. Όπως έχω αναφέρει σε προηγούμενο άρθρο μου ένα Log Block είναι μια συλλογή (container) από Log Records που έχουν γίνει από μια συγκεκριμένη ενέργεια.

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

Κάθε φορά που γίνεται μια transactional ενέργεια στον primary ο secondary ζητάει τα log blocks που περιέχουν τα log records της ενέργειας αυτής. Τότε ενεργοποιείται στο primary ένας log scanner worker οποίος με βάση τα LSNs που λείπουν από τον secondary δίνει σε αυτό τα αντίστοιχα Log Blocks.

Αυτό σημαίνει ότι όταν η ενέργεια που έχει γίνει έχει μεγάλο όγκο από Log Blocks αυτά θα πρέπει μεταφερθούν και γραφτούν στο secondary και εδώ παίζει μεγάλη σημασία το network.

Shrink Transaction Log on AG

Για να μπορεί να γίνει shrink το transaction log θα πρέπει να είναι ελεύθερα τα VLFs που είναι στο τέλος αυτού. Κάτι τέτοιο μπορεί κανείς να το δει με τη DBCC LOGINFO η οποία επιστρέφει τον αριθμό των VLFs που υπάρχουν στην εκάστοτε database και καταλαβαίνουμε αν αυτά είναι δεσμευμένα ή όχι αν στη στήλη Status είναι την τιμή 2 (δεσμευμένο) ή 0 (ελεύθερο).

Για να ελευθερωθεί κάποιο VLF θα πρέπει να κάνουμε transaction log backup και εφόσον αυτό δεν περιέχει active transactions καθαρίζεται και μπορεί να επαναχρησιμοποιηθεί. Αυτό πραγματικά γίνεται πάντα εκτός από την περίπτωση που έχω την database σε AG/

Lazy Log Truncation

Στην περίπτωση αυτή έχω αυτό που ονομάζεται Lazy Log Truncation που "μαρκάρει" το VLF σαν υποψήφιο για truncation αλλά δεν το κάνει μέχρι αυτό πραγματικά να μην χρειάζεται.

Αυτό το κάνει για να έχει την δυνατότητα στην περίπτωση που θα προστεθεί ένα νέο secondary να χρειαστούν το δυνατό λιγότερα transaction log backups/restores.

Το πότε αυτά θα φύγουν είναι κάτι το οποίο θα πάρει κάποιο χρόνο (μπορεί λεπτά μπορεί και ώρες). Αυτός είναι και ο λόγος που δεν είναι πάντα άμεσα εφικτό να κάνουμε shrink το transaction log σε μια database που είναι σε AG.

Transaction Log Maintenance in AG

Αρχικά για ΑΚΟΜΑ ΜΙΑ ΦΟΡΑ να ΤΟΝΙΣΩ ΟΣΟ ΠΕΡΙΣΣΟΤΕΡΟ ΜΠΟΡΩ OΤΙ ΠΡΕΠΕΙ ΝΑ ΣΤΑΜΑΤΗΣΕΤΕ ΤΟ ΟΠΟΙΑΔΗΠΟΤΕ SHRINK OPERATION ΚΑΝΕΤΕ ΣΤΗΝ DATABASE. Περισσότερο κακό κάνετε παρά καλό και το έχω γράψει εδώ στο SQLschool.gr αρκετές φορές.

Πέρα όμως από αυτό θα πρέπει να είστε προετοιμασμένοι όταν βάζετε μια database σε AG ότι θα χρειάζεστε περισσότερο χώρο για το transaction log για αυτή.

Για να κρατήσετε τον χώρο αυτό σε χαμηλά μεγέθη θα πρέπει να κάνετε συχνότερα transaction log backups που ενδεχομένως να είναι και ανά 5-10 λεπτά ανάλογα με το φορτίο που έχει η κάθε database.

Τέλος θα πρέπει να γίνει πλήρως κατανοητό ότι εργασίες όπως rebuild/reorg indexes θα αυξήσουν τον χώρο του transaction log και θα πρέπει να τις λάβετε υπόψη όταν κάνει size estimation για αυτό.


Ελπίζω όλα τα παραπάνω να βοηθήσουν την καθημερινότητα σας με το transaction log μιας database που είναι σε AG.


//antonch


Antonios Chatzipavlis

Antonios Chatzipavlis

Antonios Chatzipavlis is a highly experienced Data Solutions Consultant and Trainer. He has been working in the IT industry since 1988, holding various roles such as senior developer, IT Manager, Data & AI Solutions Architect and Consultant.

Since 1995, Antonios has focused on modern technologies and software development tools, primarily by Microsoft. He has specialized in Data & AI since 2000, with expertise in Microsoft Data Platform (SQL Server, Azure SQL Databases, Azure Synapse Analytics, Microsoft Fabric, Power BI, AI) and Databricks.

Antonios is also a Microsoft Certified Trainer (MCT) for over 25 years, has been recognized as a Microsoft Most Valuable Professional (MVP) in Data Platform since 2010 and he is in the Data Expert 40 Powerlist 2024 by Boussias. He is the co-founder and visionary behind XLYTiCA, a company dedicated to Data & AI solutions.

Episode

Task Flows in Microsoft Fabric

image

More Episodes...

Tip

What's New in SQL Server 2022 - Episodes

More Tips...

Become a member

If you want to receive updates from us become a member to our community.

Connect

Explore

Learn


sqlschool.gr © 2010-2025 All rights reserved

This site uses cookies for operational and analytics purposes only. By continuing to browse this site, you agree to their use.