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

Σήμερα ήρθα αντιμέτωπος με μία τέτοια παραλλαγή.

Φίλος και συνεργάτης την ώρα που ήμουν στο δρόμο για το γραφείο ( 7:00 πμ ) με παίρνει στον τηλέφωνο και μου λέει.

«Έχω μια βάση που τα 250ΜΒ είναι το data file και τα 93GB το log. Είναι από το ERP ενός πελάτη μου το οποίο θέλω να πάρω backup και να το δώσω στην εταιρεία ώστε να κάνουν κάποιους ελέγχους σε ένα θέμα που έχει προκύψει με αυτό και δεν μπορώ να το στείλω γιατί βγαίνει ένα μεγάλο μέγεθος στο backup. Έχω δει το άρθρο σου για τον Θαυμαστό κόσμο του Transaction Log και θέλω να μειώσω το log file ώστε να μην είναι τόσο μεγάλο μιας και στην πραγματικότητα δεν το έχω ανάγκη.»

Του απαντώ ΟΚ θα σε βοηθήσω, θα σε πάρω τηλέφωνο μόλις πάω στο γραφείο.

«Όχι τώρα θέλω» 

Και έτσι αρχίζουμε τηλεφωνική διαδικασία μείωσης μεγέθους του log.

Τον ρωτάω εάν έχει πρόσφατο full backup και t-log backup. Η απάντηση του ήταν ότι είχε μόνο full, οπότε ξεκινήσαμε να παίρνουμε t-log backup ώστε να γίνει truncate το log.

Με τη ολοκλήρωση του backup (t-log) τον οδήγησα να πάει μέσω του SSMS να κάνει Shrink File στο transaction log (right click on database Tasks Shrink…), και στην συνέχεια να επιλέξει την 1^η επιλογή (αυτή που λέει ότι θα δει το υπάρχον μέγεθος και τα πραγματικά δεδομένα και θα βρει το optimal).

Πραγματικά μετά από την εκτέλεση υπήρχε μια μείωση του μεγέθους του log αρχείου αλλά η διαφορά ήταν αρκετά μικρή από τα 93 GB πέσαμε στα 90GB.

Αυτό με έβαλε σε σκέψεις και του είπα να μου πει τον τρόπο με τον οποίο μεγαλώνει το transaction log όταν γεμίζει. Η απάντηση ήταν αυτή που υποψιαζόμουν γίνονταν expand κατά 10%. Αυτό όπως έχω πει επανειλημμένος δημιουργεί virtual logs τα οποία επειδή δεν είναι ισόποσα δεν μπορούν να συγχρονιστούν και έτσι φυσικά μεγαλώνει και το log.

Για να επιβεβαιώσω  ότι δεν  χρησιμοποιούνται όλα αυτά τα GBs του λέω να εκτελέσει την εντολή DBCC SQLPERF(LOGSPACE) και να μου πει το ποσοστό το οποίο είναι used. Πραγματικά δεν ήταν μεγάλο (18%).

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

Του είπα και γύρισε μέσα από τoν SSMS την βάση σε simple recovery model, και να πάει να κάνει ξανά shrink file το log. Με μία μικρή διαφορά, αυτή την φορά του είπα να πάει στην επιλογή όπου ορίζουμε το επιθυμητό μέγεθος και του είπα να δώσει 250ΜΒ. O λόγος που του το είπα αυτό είναι για να γλυτώσει IO κατά την διάρκεια των επόμενων expantions του log.

Έτσι έχουμε μια ακόμα ιστορία που αποδεικνύει ότι πρέπει να παίρνουμε KAI transaction log backup όταν έχουμε full recovery model στην database. Επίσης έχουμε και τον τρόπο με τον οποίο μπορούμε να μικρύνουμε το μέγεθος του log file.