καλημέρα σε όλους και καλή εβδομάδα,

αυτό εδώ που γράφεις,

DBCC SHRINKDATABASE (dbname, 10);

μειώνει το μέγεθος του (των) data & log files στην βάση έτσι ώστε να υπάρχει 10% ελεύθερος χώρος στην βάση.

αυτό το statement

DBCC SHRINKDATABASE (dbname, TRUNCATEONLY);

1) δεν έχει νόημα να βάλεις κάποιο ποσοστό (π.χ 10) όπως είχες στο πρώτο statement.
2) δεν επηρεάζει το μέγεθος του log file μόνο του data file
3) επειδή ακριβώς τα αρχεία γίνονται shrink από το τέλος, ότι απελευθερώνεται από το τέλος του data file "πηγαίνει" στο λειτουργικό σύστημα.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

ευχαριστώ πολύ για την απάντηση,

Σε καμία περίπτωση δεν πρέπει να γίνεται shrink οποίο και να είναι το κόστος γιατί γίνονται fragmented οι indexes . H Μονή εξαίρεση είναι για το log. Άρα σε κάθε περίπτωση ξεχνάς την dbcc shrink database και μαθαίνεις την dbcc shrink file για το log

---

Antonios Chatzipavlis

Το τι είναι σωστό ειδικά στον SQL Server, είναι μεγάλη κουβέντα και γενικά πολλές φορές η απάντηση είναι "εξαρτάται".Ένα από τα θέματα που σχεδόν όλοι συμφωνούνε είναι το θέμα του shrinking των databases.

Εγώ απλά σου εξήγησα το τι κάνουν αυτά τα statements. Ο αντώνης το πήγε δύο βήματα παρακάτω και πολύ καλά έκανε.


Γενικά το Shrinking των data files, όπως σωστά σου έγραψε ο αντώνης, είναι κάτι που πρέπει να το αποφεύγουμε. Όσο για το shrinking του log, πρέπει να το κάνεις κάποια στιγμή αλλά και αυτό δομημένα μέσα σε κάποιο maintenance window.

To Index fragmentation είναι πολύ κακό διότι έχει πολύ μεγάλη αρνητική επίδραση στο performance. Δες στο παρακάτω Link την απόδειξη αυτών που λέει ο αντώνης για το πόσο fragmented γίνονται οι Indexes στo shrinking των database data files.

http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx

Γενικά κατά την διάρκεια του shrink έχουμε πολύ μεγάλη μετακίνηση data pages, έχουμε πολύ μεγάλο I/O και πολύ μεγάλο CPU Utilisation.

Όσο αφορά το transaction log και την διαχείριση του μεγέθους του , το οποίο είναι πολύ σημαντικό θέμα, σου προτείνω να δεις πολύ καλά το backup/restore strategy για την βάση.

Πολλοί συνάδελφοι βλέπουν το transaction log να μεγαλώνει πολύ και δεν ξέρουν γιατί. Φυσικά για να μειώσουν το μέγεθος του χρησιμοποιούν shrinking. Απλά κάνουν λάθος νομίζοντας ότι παίρνοντας full ή differential backup "αδειάζει" και το log.

Μόνο με transaction log backups "αδειάζει" το transaction log.Δεν γίνεται μικρότερο σε μέγεθος αλλά "αδειάζει" έτσι ώστε να μπορούν να γίνουν νέες εγγραφές, οπότε μεγαλώνει με πολύ πολύ πιο αργό ρυθμό.

Δες (μιας και πιάσαμε το κομμάτι του shrinking σε αρκετό βάθος) το πολύ ωραίο video του αντώνη εδώ

 

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Να συμφωνήσω και εγώ με τα παιδιά για το shrink και να προσθέσω ότι αν δε βρεις το λόγο που μεγάλωσε το LOG πάλι θα έχεις το ίδιο πρόβλημα σύν το γεγονός ότι θα έχει και performance penalty κάθε φορά που θα κάνει grow το physical αρχείο.

---

Ckotsidimos

BSc, MSc, MCTS (SQL SERVER 2008)

My Blog: SQL & Sharepoint tips and how to's

Μια απορία πάνω στα πολύ ενδιαφέροντα που συζητάτε:

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Mπορείς να χρησιμοποιήσεις τα

DBCC INDEXDEFRAG

ή

ALTER INDEX REORGANIZE

για να κάνεις defrag τους Indexes. αυτό είναι σωστό. Το θέμα είναι ότι επειδή αρκετός κόσμος δεν ξέρει την σχέση που έχει το shrinking της βάσης με το index fragmentation,

δεν κάνει τίποτα για να το διορθώσει μετά....

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Αν το ζητούμενο είναι η μείωση/συρρίκνωση του μεγέθους της βάσης (για λόγους διαχείρισης-administration),
τότε η DBCC SHRINKDATABASE (dbname, xx);
παρέχει περισσότερο έλεγχο και "εγγυηση" σχετικά με το τελικό αποτέλεσμα.
Εφ'όσον τηρούνται οι προυποθέσεις, η εκτέλεση της DBCC SHRINKDATABASE (dbname, xx); θα "συρρικνώσει" το μεγεθος της βάσης
ώστε στο τέλος xx% του μεγέθους της βάσης να είναι ελεύθερος χώρος.

Η DBCC SHRINKDATABASE (dbname, TRUNCATEONLY); "αποδεσμεύει" χώρο απο το τέλος του κάθε data file μέχρι το σημείο-extent που περιέχει "ενεργα" δεδομένα {space/data pages allocated to deleted data is/are reclaimed}.
Έτσι, η DBCC SHRINKDATABASE (dbname, TRUNCATEONLY); δεν προσφέρει έλεγχο σχετικά με το τελικό αποτέλεσμα. Μετά την εκτέλεση της
DBCC SHRINKDATABASE (dbname, TRUNCATEONLY); ο ελευθερος χώρος στα data files μπορεί να είναι ~0%,..., 10%,..., 30% ... ή και 99%.
Επειδη η DBCC SHRINKDATABASE (dbname, TRUNCATEONLY); αποδεσμεύει καθαρά ελευθερο χωρο απο το τελος των data files, ΔΕΝ έχει καμία επιπτωση στα δεδομενα, indexes κτλ.
Οι indexes δεν γίνονται περισσότερο fragmented.

cap:

Μια απορία πάνω στα πολύ ενδιαφέροντα που συζητάτε:

Εξαιρώντας το performance hit, δεν διορθώνεται η κατάσταση μετά από ένα shrink με ένα dbcc indexdefrag; Η δημιουργούνται πρόσθετα θέματα;

Ναι θα σου ξαναμεγαλώσει η βάση.

---

Antonios Chatzipavlis

Νομίζω ότι η συζήτηση έχει πάρει "φιλολογικό" χαρακτήρα, μιας και φτάσαμε να αντιγράφουμε τι λέει το documentation:

• Αν η βάση είναι μεγάλη, το σίγουρο είναι ότι χρειάστηκε αυτό τον χώρο και για αυτό έχουν μεγαλώσει τα αρχεία δεδομένων της - το αποτέλεσμα αυτό προέρχεται από το γεγονός ότι ή οι ρυθμίσεις για τις απαιτήσεις για τον ελεύθερο χώρο στα data pages το έχουν προκαλέσει, ή όντως η βάση έχει πολλά δεδομένα.
  
• Μην ξεχνάμε να αναφερθούμε στο backup plan που έχει η βάση - αν είναι full backup, έχει σημασία κάθε πότε γίνεται το full backup και η αποφόρτωση του transaction log, που ουσιαστικά είναι και ο συνηθέστερος λόγος που μεγαλώνει "ξαφνικά" και "πολύ" το μέγεθος των αρχείων μιας βάσης δεδομένων - και όχι η αύξηση των δεδομένων της.
  
• Shrink database, θα συζητούσα στην περίπτωση που είχα μια βάση και έβγαζα δεδομένα μέσα από αυτή, πολλά δεδομένα - δηλαδή αναφέρομαι σε μια απίθανη διαδικασία!
  
• To να κάνεις shrink την βάση για να μικρήνουν τα αρχεία δεδομένων και στην συνέχεια να ξανακάνεις re-index και να ξαναμεγαλώσει, είναι μια μη απαραίτητη διαδικασία - δεν αναφέρομαι στην φυσική συντήρηση της βάσης που πρέπει να γίνεται περιοδικά, και θεωρώ απαραίτητο ότι η βάση δεδομένων έχει administrator που ξέρει την τάξη μεγέθους που μεγαλώνει η βάση φυσιολογικά και έχει πάρει τα μέτρα του και έχει προσαρμόσει αντίστοιχα τα ποσοστά του ελεύθερου χώρου στα data pages.
  
• Όλα τα παραπάνω τα συζητάω για μια βάση που βρίσκεται σε παραγωγή - αν η βάση είναι σε development μηχάνημα θα προτιμούσα να την σβήσω τελείως και να την επαναφέρω για να την μικρίνω μιας και θα μου είναι πιο εύκολο/γρήγορο μέσα από το γραφικό περιβάλλον.

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

George J. Capnias:

Shrink database, θα συζητούσα στην περίπτωση που είχα μια βάση και έβγαζα δεδομένα μέσα από αυτή, πολλά δεδομένα - δηλαδή αναφέρομαι σε μια απίθανη διαδικασία!

Δεν είναι και τόσο απίθανη διαδικασία. Σκέψου την περίπτωση οπου η βάση κρατάει ένα εσωτερικό event log για errors ή events το οποίο "φουσκώνει" και πρέπει περιοδικά να καθαρίζεται. Να σου αναφέρω δύο παραδείγματα που μου έρχονται μάνι-μάνι στο μυαλό: YAF και DNN. 

Στο DNN ειδικά, επειδή δουλεύω το OWS, αυτό έχει εσωτερικό action log το οποίο ΑΝ το ξεχάσεις ανοιχτό (για debug) και τυχόν βγάλεις το μαραφέτι σε production και έχει κίνηση, γεμίζει από χιλιάδες records στο πι και φι. Τι κάνεις μετά; Το καθαρίζεις και έχεις π.χ. μια βάση η οποία υπό κανονικές συνθήκες δεν θα πιάσει ποτέ τα 300ΜΒ να πιάνει π.χ. 1GB; Ε, θα την κάνεις shrink ή τέλος πάντων θα πρέπει με κάποιο τρόπο να την μικρύνεις.

Βεβαια, θα μου πεις, δεν είναι τόσο critical scenarios αυτα σε σχέση π.χ. με ένα τραπεζικό σύστημα, και θα συμφωνήσω. Αλλά οτι συμβαίνει, συμβαίνει!

Antonios Chatzipavlis:

cap:

Μια απορία πάνω στα πολύ ενδιαφέροντα που συζητάτε:

Εξαιρώντας το performance hit, δεν διορθώνεται η κατάσταση μετά από ένα shrink με ένα dbcc indexdefrag; Η δημιουργούνται πρόσθετα θέματα;

Ναι θα σου ξαναμεγαλώσει η βάση.

---

Σωτήρης Φιλιππίδης

DotSee Web Services

cap:

Δεν είναι και τόσο απίθανη διαδικασία. Σκέψου την περίπτωση οπου η βάση κρατάει ένα εσωτερικό event log για errors ή events το οποίο "φουσκώνει" και πρέπει περιοδικά να καθαρίζεται. Να σου αναφέρω δύο παραδείγματα που μου έρχονται μάνι-μάνι στο μυαλό: YAF και DNN. 

Πριν απαντήσει άλλος, να πω εγώ:

• Δέχομαι το παράδειγμα σου, αλλά υποστηρίζεις ότι σε μια βάση που έχει ένα τέτοιο πίνακα, έχει νόημα να μιλάμε για indexes στον πίνακα, και re-arrange indexes; Μήπως και full text search;
• Μήπως ακριβώς στην συγκεκριμένη περίπτωση δεν σε συμφέρει το shrink γιατί εκτός του ότι η βάση έχει "ανοίξει", και δεν θα έχεις το penalty του expansion στο δίσκο, ξανά; Ενώ η βεβαιότητα ότι η βάση θα ξαναεπιστρέψει στο αυτό μέγεθος στο μέλλον, ουσιαστικά τι πιστεύεις ότι θα κερδίζεις για την εφαρμογή σου; Χώρο στο δίσκο; Και το πληρώνεις με perfomance; Το βλέπεις σωστό;

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

George J. Capnias:

• Δέχομαι το παράδειγμα σου, αλλά ότι σε μια βάση που έχει ένα τέτοιο πίνακα, έχει νόημα να μιλάμε για indexes στον πίνακα, και re-arrange indexes; Μήπως και full text search;
• Μήπως ακριβώς στην συγκεκριμένη περίπτωση δεν σε συμφέρει το shrink γιατί εκτός του ότι η βάση έχει "ανοίξει", και δεν θα έχεις το penalty του expansion στο δίσκο, ξανά; Ενώ η βεβαιότητα ότι η βάση θα ξαναεπιστρέψει στο αυτό μέγεθος στο μέλλον, ουσιαστικά τι πιστεύεις ότι θα κερδίζεις για την εφαρμογή σου; Χώρο στο δίσκο; Και το πληρώνεις με perfomance; Το βλέπεις σωστό;

---

Σωτήρης Φιλιππίδης

DotSee Web Services