SQL Server (και άλλες databases)

Απ: shrink database

spaceman — Fri, 03 Jun 2011 02:22:07 GMT

Κάποια πράγματα που ίσως θα έπρεπε να ψάξεις περισσότερο:
data size = 155327624 KB
index size = 135162832 KB
Η μισή βάση είναι δεδομένα και η άλλη μισή είναι indexes. Χωρίς αυτό να είναι "κακό" ίσως θα έπρεπε να κοιτάξεις
πως χρησιμοποιούνται οι υπάρχοντες indexes και αν όντως χρειάζονται όλοι.

Το log file, (if i am not mistaken), έχει μέγεθος γύρω στα 18 GB.
Ίσως αξίζει να κοιτάξεις τo disaster-recovery πλάνο για την συγκεκριμένη βάση, καθώς και υπάρχοντα maintenance plans-jobs (:κυρίως index rebuilds)

Ο αριθμός των filegroups&files είναι λίγο "περίεργος". Ίσως θα πρέπει να ελέγξεις την κατανομή των files per filegroup και το μέγεθος του κάθε file:
Αν πχ. σε ενα filegroup (με 5 datafiles) υπαρχουν 3 files με μεγεθος 1GB και 2 files με μεγεθος 3GB.
Αν στο primary filegroup δεν αποθηκευονται δεδομένα και το primary filegroup έχει περισσότερα από ένα data files κτλ.

Επίσης, αν η βάση έχει πίνακες χωρίς clustered index (heaps) ίσως υπάρχουν allocated pages οι οποίες δεν περιέχουν "ενεργά" δεδομένα.
--pay attention to heaps με μικρό αριθμό rows και ιδιαίτερα μεγάλο αριθμό xx_pages (σε σχέση με το μέσο μέγεθος data/index record)

SELECT  OBJECT_NAME(i.object_id) AS tbl_name, ISNULL(i.name, 'heap_table_data') AS indexname, p.partition_id, p.rows, dp.*, lobp.*
FROM sys.indexes AS i
 JOIN sys.partitions AS p on i.object_id = p.object_id AND i.index_id = p.index_id
 OUTER APPLY (SELECT SUM(total_pages) AS total_pages, SUM(used_pages) AS used_pages, SUM(data_pages) AS data_pages
    FROM sys.allocation_units AS al
    WHERE al.container_id = p.hobt_id
    AND al.type IN (1,3)) AS dp
 --lob pages are deallocated when heap records are deleted, display them for a complete overview
 OUTER APPLY (SELECT SUM(total_pages) AS lob_total_pages, SUM(used_pages) AS lob_used_pages, SUM(data_pages) AS lob_data_pages
    FROM sys.allocation_units AS al
    WHERE al.container_id = p.partition_id
    AND al.type = 2) AS lobp    
WHERE OBJECTPROPERTYEX(i.object_id, N'TableHasClustIndex') = 0 --table is a heap
AND OBJECTPROPERTYEX(i.object_id, N'IsUserTable ') = 1

Απ: shrink database

Antonios Chatzipavlis — Fri, 03 Jun 2011 01:24:02 GMT

vmakrin:
μετά από όσα είπαμε δεν μου φαίνεται καλή ιδέα να κάνω shrink στην βάση, απλά με ανησυχεί ο χώρος στους δίσκους και όλα αυτά τα datafiles.

Θα σου τι υποψιάζομαι για αυτά το βράδυ μόλις πάω σπίτι

Απ: shrink database

vmakrin — Thu, 02 Jun 2011 23:15:16 GMT

μετά από όσα είπαμε δεν μου φαίνεται καλή ιδέα να κάνω shrink στην βάση, απλά με ανησυχεί ο χώρος στους δίσκους και όλα αυτά τα datafiles.

Απ: shrink database

ckotsidimos — Thu, 02 Jun 2011 23:04:09 GMT

Έχεις κάποιο πρόβληαμ και το σκέφτεσαι το shrink? Αν όχι, θα συμφωνήσω με τον Αντώνη

Απ: shrink database

vmakrin — Thu, 02 Jun 2011 19:02:53 GMT

η αλήθεια είναι πώς έτσι την κληρονόμησα εδώ και 5 περίπου μήνες και αρχίζω να "ψάχνομαι" σε διάφορα επίπεδα.

Απ: shrink database

Antonios Chatzipavlis — Thu, 02 Jun 2011 05:20:51 GMT

Βλέποντας τα παραπάνω αγαπητέ μου φίλε μπορώ ασφαλώς να συμπεράνω ότι κάτι σοβαρό είναι πάνω σε αυτή σωστά;

(Δεν μπορώ διαφορετικά να εξηγήσω τον αριθμό των αρχείων)

Με βάση αυτή την εκτίμηση αλλά και το μέγεθος του ελεύθερου χώρου που μας δίνεις δεν βλέπω το λόγο να κάνεις κάτι γιά αυτή.

Αν κάτσεις να υπολογίσεις τον χρόνο που θα χρειαστείς να κάνεις shrink σε σχέση με το κόστος των GB που θέλεις να πάρεις πίσω στους δίσκους σου νομίζω ότι δεν αξίζει την φασάρια.

Πρίν κάνεις οτιδήποτε υπολόγισε πόσο σου κοστίζει το GB στο storage σου (θεωρώ ότι με αυτά που δίνεις σαν στοιχεία έχεις storage) και πόσο κοστίζει η ώρα που δεν είναι διαθέσιμη η βάση σου στην εταιρία σου.

Απ: shrink database

vmakrin — Wed, 01 Jun 2011 16:47:52 GMT

η εικόνα της βάσης είναι η παρακάτω,

filegroups: 8

datafiles :88

database_name: dbname

database_size: 359921.94 MB

unallocated space: 54036.81 MB

reserved: 294038720 KB

data: 155327624 KB

index_size: 135162832 KB

unused: 3548264 KB

Απ: shrink database

cap — Wed, 01 Jun 2011 08:43:53 GMT

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

Τα πάντα είναι σχετικά όταν μιλάμε για μεγέθη. Μια βάση ενός πορταλ σε ένα server περιορισμένων δυνατοτητων (ορισμένες φορές συμβαίνει) έχει ανάγκη τα indexes όταν έχει ακόμα και μερικές εκατοντάδες εγγραφές σε κάποιους πίνακες. Διαφωνείς;

Στο σενάριο που περιγράφω, ναι, το shrink εξασφαλίζει μικρότερο χώρο στο δίσκο, ο οποίος σε ορισμένες περιπτώσεις είναι πολύτιμος. Το να το πληρώνεις με επιδόσεις οχι, δεν είναι σωστό, αλλλά αν ένα indexdefrag σου κάνει τη δουλειά, είναι αποδεκτό.

Απ: shrink database

George J. Capnias — Wed, 01 Jun 2011 07:29:00 GMT

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

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

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

George J.

Απ: shrink database

cap — Wed, 01 Jun 2011 04:49:34 GMT

Antonios Chatzipavlis:
cap:
Μια απορία πάνω στα πολύ ενδιαφέροντα που συζητάτε:
Εξαιρώντας το performance hit, δεν διορθώνεται η κατάσταση μετά από ένα shrink με ένα dbcc indexdefrag; Η δημιουργούνται πρόσθετα θέματα;

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

Αντώνη, αν μου ξαναμεγαλώσει σε σχέση με τα indexes, δεν το θεωρώ θέμα. Οπως γράφω και σε προηγούμενο post, για να φτάσω (εγώ, εσύ, ο άλλος) να κάνουμε shrink σημαίνει πως κάτι είχε "φουσκωμένο" μέσα και το "ξεφουσκώσαμε". Ε, δεν πιστεύω να μεγαλώσει ξανά το ίδιο.

Απ: shrink database

cap — Wed, 01 Jun 2011 04:47:02 GMT

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

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

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

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

Απ: shrink database

George J. Capnias — Wed, 01 Jun 2011 04:03:26 GMT

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

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

George J.

Απ: shrink database

Antonios Chatzipavlis — Wed, 01 Jun 2011 03:15:18 GMT

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

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

Απ: shrink database

spaceman — Wed, 01 Jun 2011 03:12:32 GMT

Αν το ζητούμενο είναι η μείωση/συρρίκνωση του μεγέθους της βάσης (για λόγους διαχείρισης-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.

Απ: shrink database

nikolaosk — Wed, 01 Jun 2011 01:33:34 GMT

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

DBCC INDEXDEFRAG

ή

ALTER INDEX REORGANIZE

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

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