Jump to content
  • entries
    292
  • comments
    368
  • views
    59730

Why TRUNCATE_LOG discontinued (Answer to Mr. Kladakis)


antonch

1690 views

 Share

Στο 18ο event μας που είχα την ομιλία μου η συζήτηση μας έφερε να μιλήσουμε για το ότι ευτυχώς πλέον δεν υποστηρίζεται η χρήση της BACKUP LOG dbname> WITH TRUNCATE_ONLY.

Ο φίλος μου, συναγωνιστής μου, Αθανάσιος Κλαδάκης είχε την εύλογη απορία γιατί έγινε αυτό. Είπαμε κάποια πράγματα αλλά επειδή ο χρόνος ήταν περιορισμένος διότι περίμεναν οι μπύρες και η πίτα-πίτσα δεν έμεινα ικανοποιημένος με την απάντηση που έδωσα. Έτσι επανέρχομαι στο θέμα.

Ο Νάσος είπε ότι σε όσους πελάτες του βλέπει σε κάποια βάση ότι το Transaction Log (TL) έχει γίνει μεγάλο εκτελεί την εντολή αυτή και φέρνει τα πράγματα στα ίσια τους. Μέχρι εδώ σωστά. Όμως αυτό εγκυμονεί κινδύνους. Ο σημαντικότερος από αυτούς είναι ο παρακάτω.

Έστω ότι έχω εγκαθιδρύσει μια διαδικασία backup στην βάση με την οποία παίρνω και TL Backup. πχ

Στις 05:00 κάνω Full Backup (FB) και από τις 06:00 παίρνω TL backup.

Κάποια στιγμή το μεσημέρι βλέπω το TL να είναι μεγάλο και σαν καλό παιδί αποφασίζω να το μικρύνω με την χρήση της παραπάνω εντολής. Όλα πάνε καλά και είμαι ευτυχισμένος. Αυτό ας υποθέσουμε ότι έγινε γύρω στις 12:30.

Στις 17:30 για κάποιο λόγο σκάει η βάση και πρέπει να κάνω RESTORE. Σύμφωνα με αυτά που ξέρω θα πρέπει να κάνω RESTORE το FB των 05:00 WITH NORECOVERY και στη συνέχεια να κάνω RESTORE όλα τα TL backups με την σειρά που τα πήρα όλα WITH NORECOVERY εκτός του τελευταίου το οποίο είναι στις 17:00 (εκτός και αν έχω πάρει και tail log backup αμέσως μετά από την εμφάνιση του προβλήματος) το οποίο θα πρέπει να γίνει με RECOVERY.

Όμως σιγά που θα γίνει αυτό που θέλω. Επειδή στις 12:30 έκανα το truncate στο log δεν μπορώ να συνεχίσω στο restore των logs από εκεί και πέρα διότι πολύ απλά δεν έχω τέτοια μιας και με την χρήση της εντολής που συζητάμε έχω καταφέρει να κάνω break το Log Sequence Number (LSN) πάνω στο οποίο βασίζεται η διαδικασία του TL backup.

Αποτέλεσμα, πάω για κρύες μπύρες, διότι έχω χάσει τα περιεχόμενα του TL από το τελευταίο FB. (Ένα ρίγος περνάει αυτή τη στιγμή την πλάτη μου μόνο και που το σκέφτομαι)

Αυτό που μέχρι την διακοπή της χρήσης της εντολής η Microsoft συνιστούσε ήταν αμέσως μετά την ολοκλήρωση της εντολής να παίρνουμε FULL BACKUP ώστε τα TL backups να μην σκάνε.

Σήμερα (SQL Server 2005, 2008, 2008 R2) με την κατάργηση της εντολής αν θέλουμε να κάνουμε αυτό που θέλει να κάνει ο Νάσος σύμφωνα πάντα με την Microsoft θα πρέπει να γυρίσουμε την βάση σε SIMPLE RECOVERY MODEL ώστε να γίνει truncate το log και όταν τελειώσει αυτό να την επαναφέρουμε σε FULL RECOVERY MODEL.

Ελπίζω να έδωσα τώρα μια πιο κατατοπιστική απάντηση γιατί δεν έχει θέση στον SQL Server η TRUNCATE_LOG.

Να σημειώσω ότι μπορεί να την δείτε και σαν NO_LOG είναι το ίδιο αλλά με άλλο όνομα, και αυτή πήγε στον Καιάδα.

Υ.Γ. Δεν ξέρω αν η κοινότητα είναι εξοικειωμένη με τις διάφορες μορφές backup που μπορώ να έχω στον SQL Server. Επειδή μέχρι σήμερα δεν έχω αναφερθεί σε αυτό, θεωρώντας το γνωστό, θα ήθελα να ξέρω αν υπάρχει ενδιαφέρον ώστε να γράψω για αυτό.

 Share

13 Comments


Recommended Comments

Καλά τα λές αγαπητέ Αντώνη, αλλά αν στις 12:30 δεν έκανα truncate τότε στις 12:40 δεν θα είχες σημασία αν στις 17:30 θα μπορούσα να κάνω restore, διότι απλά ο πελάτης θα είχε πηδήξει απο το μπαλκόνι. Συνήθως ο λόγος που κάναμε truncate είναι γιατί ο δίσκος ήταν τίγκα, χώρο για backup δεν είχαμε, 2000 χρήστες ούρλιαζαν που δεν δούλευαν, όλο το διοικητικό συμβούλιο απειλούσε και ικέτευε, κάθε λεπτό χάνονταν λεφτά, οπότε, απλά...πολύ απλά ...γύριζες τα πράγματα στο κανονικό, παίρνωντας το ρίσκο να έχεις πρόβλημα σε ...μελλόντικο σκάσιμο (???), που δεν μου έχει συμβεί ούτε μία φορά. Οι μεγάλοι άντρες ζούν επικίνδυνα !!!

Link to comment

Θα συμφωνήσω μαζί σου για το σενάριο που αναφέρεις αλλά θα επισημάνω ότι για να φτάσεις στην κατάσταση αυτή έχουν γίνει σωρεία από λάθη πχ. capacity estimation. Άσε δε που φοβάμαι ότι ποτε δεν θα έχει παρθεί backup στην βάση αυτή. Το να μένει ένας server χωρίς χώρο στον δίσκο είναι κάπως δεν είναι; Τι έκανε ο διαχειριστής τυφλός ήταν; Τέλος πάντων όπως και να έχει η εντολή είχε πολλά ρίσκα και καλά έκαναν και την έφαγαν.

Link to comment

To σενάριο που περιγράφει ο Θανάσης είναι αρκετά σύνηθες. Πρόσφατα μου έτυχε περίπτωση όπου επιχειρήθηκε index rebuild μέσα από το SSMS και ο άτυχος που το έκανε έπεσε στο bug του ανάποδου ποσοστού (το UI ερμηνεύει διαφορετικά το 10% free space και περνάει αυτήν την τιμή αντί του σωστού 90% στο rebuild index command). To αποτέλεσμα ήταν να φτάσει το TL στα 110GB, για μια βάση 4GB και τελικά να σκάσει η διαδικασία λόγω disk space. Τώρα θα μου πεις, εντάξει, αλλά πόσοι πέφτουν σε κάτι τέτοιο; Σε κάτι τέτοιο ίσως όχι πολλοί γιατί για το συγκεκριμένο θα πρέπει να έχεις αφήσει τον SQL Server χωρίς SP. Όμως κατά τη γνώμη μου, είναι ενδεικτικό ενός προβλήματος που συνοψίζεται στο εξής: Μικρά/μεσαία μαγαζιά (χωρίς άνθρωπο να ξέρει τον SQL Server ώστε να βάλει alerts κλπ) που έχουν απλά μια βασική εγκατάσταση "next-next-next" είναι καταδικασμένα κάποια στιγμή να εντιμετωπίσουν τέτοια προβήματα. Ο SQL Server δίνει όλους τους μηχανισμούς για να προλάβεις να ΜΗΝ φτάσεις στο πρόβλημα, ωστόσο το θέμα είναι ότι δεν χρησιμοποιούνται. Προσωπικά δεν θεωρώ ότι είναι καλό να μην υποστηρίζεται πλέον το WITH TRUNCATE_LOG. Αλίμονο μην φτάσουμε στο σημείο να αφαιρούνται features για να προστατεύοναι οι άσχετοι! "Αφαιρέσαμε τη δυνατότητα να κάνεις shift-delete γιατί οι χρήστες παραπονιόντουσαν ότι έσβηναν οριστικά πολλά αρχεία κατά λάθος". Αυτό θα το έβλεπα πιο θετικά. Τα Windows είναι end-user προϊόν, ο SQL Server όχι, οφείλεις να δίνεις ό,τι εργαλείο χρειάζεται. Θεωρώ ότι είναι καλύτερα το bullet-proofing να γίνεται στην αιτία με καλύτερο management UI, out-of-box policies και ρυθμίσεις, κλπ παρά εκ των υστέρων να προσπαθείς να λύσεις το πρόβλημα με ασπιρίνες.

Link to comment

Αν δεν παίρνεις backup σωστό, τα Logs φουσκώνουν και κάποια μέρα σκάει το σύμπαν.

Μια χαρά τα λέει ο Αντώνης.

Link to comment

Ο SQL Server μπορεί να μην είναι end-user προϊόν αλλά η πράξη έχει δείξει ότι έχει γίνει. Και αυτό γιατί έχει μπει όπως σωστά λες μέσα στα μικρά/μεσαία μαγαζιά, που δεν έχουν dba. Σχεδόν όλες οι μεγάλες εταιρείες πληροφορικής στην Ελλάδα που έχουν ERP είναι σε SQL Server. Και μάλιστα έχουν τις απλές εκδόσεις και όχι την enterprise. Από ότι έχω δει οι περισσότεροι, και καλά κάνουν, σε τέτοιες εγκαταστάσεις έχουν Simple Recovery model στην βάση τους. Οπότε δεν πρόκειται να δούμε μεγάλο TL. Βέβαια και σε αυτό υπάρχουν εξαιρέσεις ειδικά όταν λόγο "τσιγκουνιάς" δημιουργούμε την βάση με μικρό μέγεθος στο TL και βάζουμε autogrowth 10%. Εξαιτίας όλων αυτών πιστεύω ακράδαντα ότι καλά έκαναν και την έβγαλαν διότι περισσότερα προβλήματα αναφύονταν παρά καλά, διότι ο μη σχετικός με τον SQL Server όταν είχε να αντιμετωπίσει το συγκεκριμένο πρόβλημα έκανε μια σχετική αναζήτηση στο web και την έβρισκε σε κάποιο forum χωρίς όμως δυστυχώς να αναφέρονται τα ρίσκα. Έτσι μπορεί μεν να έλυνε το πρόβλημα του προσωρινά αλλά αν μετά από λίγο είχε πρόβλημα τότε έχανε και την βάση (ναι εντάξει δεν είναι σύνηθες να χάνουμε βάση στον SQL Server τα τελευταία 10 χρόνια, αλλά καλύτερα να είμαστε σίγουροι). Το θέμα για την Microsoft, κατά την προσωπική μου γνώμη, ήταν να αφήσει το feature ανοικτό και να γίνεται ότι γίνονταν με αποτέλεσμα να δημιουργείται μια άσχημη εικόνα για το προϊόν ή να το κλείσει. Εξάλλου όπως έχω αναφέρει και στο post μου υπάρχει λύση τώρα που δεν την έχουμε. Και να μην ξεχνάμε ότι ακόμα και όταν εκτελούσαμε την TRUNCATE_LOG το πρόβλημα λύνονταν προσωρινά μετά από λίγο καιρό εμφανίζονταν ξανά. Μερικές φορές είναι καλύτερα να χρησιμοποιήσεις μια ασπιρίνη παρά να κάνεις εγχείριση.

Link to comment

Gsimo, ο sql δεν είναι exchange ώστε τα logs να σβήνονται με το backup πάντα (που ούτε εκεί σβήνονται δλδ πάντα). Υπάρχουν περιπτώσεις που απο λάθος sync δεν σβήνει πότε. Ασε που όπως λέει και ο kelman, το log γεμίζει σε 5 λεπτά τον δίσκο από ένα βλακώδες tsql statement.

Με καλύπτει αυτό που λεεί ο Αντώνης πάντως ότι αρκεί να αλλάξω το μοντέλο recovery.

Link to comment

Σε κάθε περίπτωση πάντως υπάρχει και το BULK-LOGGED recovery model. Το οποίο έχει σαν πλεονέκτημα να έχω μικρότερο μέγεθος στο TL μια και καταγράφει τα πάντα σε επίπεδο extent. Τα μειονεκτήματα του είναι ότι χρειάζεται μεγαλύτερο χρόνος για να έρθει η βάση σε κατάσταση λειτουργίας και δεν μπορώ να σταματήσω σε συγκεκριμένη χρονική στιγμή στο restore (STOPAT).

Link to comment

Αυτό που θέλω να πω είναι ότι θα μπορούσε το SSMS να είναι πολύ πιο user friendly και η όλη εγκατάσταση του SQL Server πιο real-world oriented. Για παράδειγμα, να έρχεται με προεγκατεστημένα alerts, jobs και operators, από αυτά που όλοι εμείς προσθέτουμε στη συνέχεια. Επίσης, να έχει ένα best-practices analyzer που να σε προειδοποιεί για το συνεπάγονται οι επιλογές σου στο τρόπο στησίματος. Τέτοια πράγματα...

 

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

 

Link to comment

Μα ρε φίλε ο SSMS είναι user friendly. Και πολλά από αυτά που λες (όχι έτσι ακριβώς που τα λες) έχουν γίνει πραγματικότητα στο R2. Τώρα όσον αφορά αυτό που λέχθηκε ότι αφαιρέθηκε για λόγους marketing αυτό όπως τόνισα είναι προσωπική μου θέση. Αλλά και αυτό να έγινε αφού έχω λύση για το συγκεκριμένο πρόβλημα η οποία δεν δημιουργεί το ρίσκο γιατί να υπάρχει κάτι το οποίο αν πέσει στα χέρια κάποιου μη σχετικού με κίνδυνο να δημιουργεί το χάος. Συμφωνώ για την πρόκα και το σφυρί, αλλά όταν πας να καρφώσει παίρνεις και τις ανάλογες προφυλάξεις. Εξάλλου και οι δύο είμαστε developers και έχουμε μάθει για τον αμυντικό προγραμματισμό. Δεν χάθηκε η δυνατότητα να κάνεις truncate το log, απλά άλλαξε η διαδικασία, και χάθηκε μια εντολή. Απλά αλλάζει ο τρόπος που είναι εδώ που τα λέμε και ασφαλέστερος.

Link to comment

Όπως είπε πρόσφατα και ο Παναγιώτης ο Καναβός, ...συνδιαφωνούμε. Συμφωνούμε ως προς την μαρκετινίστικη ανάγκη, δική σου άποψη που συνυπογράφω, αλλά διαφωνούμε ως προς το big-deal που είναι το όλο θέμα. Εγώ, δεν το βλέπω τόσο big-deal ως προς το τεχνικό κομμάτι (αφού το είπαμε, γίνεται κι αλλιώς η δουλειά) αλλά το βλέπω ως big-deal γιατί είναι γενικώς κακή τακτική να αντιμετωπίζουν κατά τέτοιο τρόπο τα προβλήματα.

Link to comment

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

Link to comment

Αν θέλουμε ο SQL Server να είναι έτοιμος για μικρομεσίους χωρίς γνώσεις DBA, τότε ίσως θα έπρεπε το default recovey mode στην δημιουργία των βάσεων να ήταν το simple. Αυτοί που δεν ξερουν τί κάνει ο SQL Server και νομίζουν ότι είναι μια μεγάλη Access δεν πρόκειται να παίρνουν log και tail backups. Ένα full θα παίρνουν, αν το παίρνουν και αυτό. Δεν υπάρχει λόγος να καταναλόνουν χώρο για το log file.

 

Τωρα με την αφαίρεση της backup with trancate_only συμφωνώ γιατί αν κάποιος δεν ξέρει πραγματικά καλά τον SQL Server μπορεί να πιστέψει ότι έχει πάρει KAI backup, και αργότερα να βρεθεί προ εκπλήξεων. Και δεν στέκει και συντακτικά. Δεν πήρα backup, γιατί ξεκινάω λέγοντας "BACKUP...";

 

Τωρα μια εντολή του στυλ "Trancate log, I need space NOW, PLEASEΕΕΕΕ" μπορεί να ήταν χρήσιμη, αλλά αφού η δουλειά γίνεται και με την αλλαγή του recovery mode μου αρκεί.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...