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

Απ: Περί συντήρησης

KelMan — Sat, 08 Jul 2006 04:37:50 GMT

Κοίτα, δεν υπάρχει κάποιος τυφλοσούρτης. Όλα εξαρτώνται από τη βάση και το γενικότερο περιβάλλον λειτουργίας. Ας πούμε το αν έχεις μια βάση 25GB δεν λέει τίποτα αν έχεις ένα σύστημα με 16 CPU και 40G RAM. Από την άλλη αν έχεις μια βάση 100MB, 80 χρήστες με μια κακογραμμένη εφαρμογή που δημιουργεί πολλά locks σε ένα σύστημα με 1GB RAM τότε αλλάζουν δραματικά τα πράγματα. Άλλα considerations έχουν οι Very Large DBs και άλλα οι μικρές. Άλλα οι 24x7 που υποστηρίζουν ένα web site (διαρκής κίνηση) και άλλα οι 24x7 που έχουν peak 9 με 5.

Γι αυτό και σου προτείνω να ξεκινήσεις από το maintenance plan. Μπορείς να το δημιουργήσεις αλλά δεν είναι απαραίτητο να το προγραμματίσεις να τρέχει σε συγκεκριμένες χρονικές στιγμές. Μπορείς να το ξεκινάς όποτε θέλεις. Ούτε είναι υποχρεωτικό να δουλεύει με τη βάση οff-line. Έπειτα, δες τι κάνει και δες πως μπορείς να κάνεις τα ίδια με TSQL/DBCC/κλπ εντολές. Με αυτόν τον τρόπο θα μπορέσεις να γράψεις τα δικά σου maintenance scripts.

Επίσης, μπορείς να διαβάσεις και αυτό το κατατοπιστικότατο white paper: SQL Server 2000 Operations Guide ωστόσο για μένα το πιο σημαντικό είναι η μελέτη των BOL ώστε να καταλάβεις τα inner workings του συστήματος.

Απ: Περί συντήρησης

axaros — Fri, 07 Jul 2006 18:35:41 GMT

Μάνο, το πρόβλημα μου είναι ότι δεν μπορώ να ρίξω τον Server.
Έχω 24 Χ 7 λειτουργία ...
Έχω ένα maintenance plan με scheduled backups αλλά όλα
τα υπόλοιπα θα πρέπει να γίνουν σε καθορισμένους χρόνους
που θα "ρίξουμε" το σύστημα...

Γι' αυτό ρωτάω : manually τι πρέπει να γίνει και με ποια σειρά ;

Απ: Περί συντήρησης

KelMan — Fri, 07 Jul 2006 06:20:11 GMT

Αν η βάση δεν έχει κάποιες "περίεργες" απαιτήσεις, τότε μπορείς να παίξεις με τον Maintenance Plan Wizard από τον Enterprise Manager / SQL Server Management Studio. Θα σε καλύψει σίγουρα...

Απ: Περί συντήρησης

axaros — Thu, 06 Jul 2006 19:05:27 GMT

Ok ...
Πηγαίνοντας παρακάτω :
Τι άλλα integirty cheks θεωρείτε ότι πρέπει να κάνει κανείς
πριν μιλήσουμε για backup και truncation των logs κλπ.;

Ή μάλλον :
άρχισα σωστά με το θέμα του reindexing ή κάτι άλλο θα πρέπει
να προηγηθεί...

Εν ολίγοις, γενικότερα, τι πρέπει να κάνω και με ποια σειρά ;

Απ: Περί συντήρησης

KelMan — Thu, 06 Jul 2006 16:07:47 GMT

Όποιος ψάχνει βρίσκει... Δεν κοίταζα στο σωστό σημείο. Στον SQL Server 2005 για πολλά DBCC statements έχουν βγει αντίστοιχα TSQL statements με στόχο να περιοριστεί η χρήση του DBCC καθώς (υποτίθεται) ότι μπορεί σε μελλοντικές εκδόσεις να μην υποστηρίζεται.

Μπορείς λοιπόν να χρησιμοποιήσεις το νέο ALTER INDEX statement για το reindex το οποίο διαθέτι ένα switch ONLINE = { ON | OFF } (ισχύει όμως μόνο στην Enterprise έκδοση του SQL Server) και κάνει επίσης update των statistics (σε όλες τις εκδόσεις).

Απ: Περί συντήρησης

KelMan — Thu, 06 Jul 2006 15:48:50 GMT

Στο what's new δεν έχω δει κάτι και στα BOL λέει τα ίδια, οπότε νομίζω δεν υπάρχει καμιά αλλαγή σε αυτόν τον τομέα...

Απ: Περί συντήρησης

axaros — Wed, 05 Jul 2006 21:24:08 GMT

Ευχαριστώ για άλλη μια φορά,
rector ...
Το είχα το άρθρο αλλά, δεν είχα προσέξει το περί statistics ...
Τώρα τί αλλάζει στον 2005 όσον αφορά στο reindexing ;

Απ: Περί συντήρησης

KelMan — Wed, 05 Jul 2006 21:10:36 GMT

To INDEXDEFRAG δεν κάνει update τα statistics σε αντίθεση με το DBREINDEX.

Ρίξε μια ματιά εδώ: http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx είναι ένα πολύ αναλυτικό άρθρο.

Απ: Περί συντήρησης

axaros — Wed, 05 Jul 2006 20:40:13 GMT

Ναι τα έχω δει ...
Κάτι ακόμη : θα πρέπει μετά το reindexing να κάνω update τα statistics;

Απ: Περί συντήρησης

KelMan — Wed, 05 Jul 2006 20:34:58 GMT

Ναι, το DBREINDEX είναι off-line operation ενώ το INDEXDEFRAG είναι on-line. Ρίξε μια ματιά για τις διαφορές τους στα BOL. Μέσω DMO δεν έχω κάνει κάτι τέτοιο, υποθέτω όμως ότι δεν αλλάζει κάτι...

Απ: Περί συντήρησης

axaros — Wed, 05 Jul 2006 20:27:10 GMT

Ακριβώς αυτό ήθελα να σε ρωτήσω :
Ισχύει ότι το DBREINDEX βάζει ένα table lock μέχρι να τελειώσει το operation;
Να υποθέσω ότι και αν πάω μέσω (SQL DMO) ισχύει το ίδιο ;

Απ: Περί συντήρησης

KelMan — Wed, 05 Jul 2006 20:16:33 GMT

Ακριβώς! Όταν έχεις πολλά insert, update, delete θα πρέπει να ορίσεις το κατάλληλο fill factor. Κάνοντας monitor πως μεταβάλλονται τα περιεχόμενα των σελίδων θα μπορέσεις να βρεις ποιό είναι το βέλτιστο fill factor. Μιας και το fill factor δεν είναι κάτι που συντηρεί αυτόματα o SQL Server, θα πρέπει να κάνεις ένα περιοδικό maintenance plan και ο στόχος σου είναι να μην ανεβαίνει το fragmentation μεταξύ των δύο εκτελέσεων του maintenance plan. Προφανώς, όταν θα έχει τελειώσει το πρώτο maintenance plan θα πρέπει το DBCC να σου δείχνει αρκετό ελεύθερο χώρο στις σελίδες, ενώ πριν αν ξεκινήσει το δεύτερο maintenance plan θα πρέπει ο ελεύθερος χώρος να πλησιάζει το 0. Από εκεί και πέρα, ανάλογα με το αν υπάρχει χρονικό παράθυρο που να μπορείς να θέσεις τη βάση off line ή όχι, επιλέγεις αν θα κάνεις DBREINDEX ή INDEXDEFRAG.

Απ: Περί συντήρησης

axaros — Wed, 05 Jul 2006 20:01:00 GMT

KelMan wrote:

Τέλος, το Avg. Bytes Free per Page και το Avg. Page Density δείχνουν τον ελεύθερο χώρο κατά μέσο όρο και την πυκνότητα των σελίδων αλλά εδώ θέλει προσοχή. Ο SQL Server κάνει τα I/O operations ανά σελίδα. Δηλαδή αν θέλω να διαβάσω έστω και μία εγγραφή θα διαβάσω (υποχρεωτικά) και τις υπόλοιπες της ίδιας σελίδας. Έτσι, όσο πιο γεμάτη είναι μια σελίδα, τόσες περισσότερες εγγραφές διαβάζω με ένα read, τουτέστιν αν θέλω να διαβάσω όλον τον πίνακα θα χρειαστώ λιγότερα I/O's,. Προσοχή όμως! Αυτό δεν είναι απαραίτητα καλό, γιατί αν κάνω πολλά write operations, τότε οι γεμάτες σελίδες θα έχουν ως αποτέλεσμα πολλαπλά page splits (όταν έχω clustered index σε μια σελίδα και προσπαθώ να εισάγω μια εγγραφή, αυτή θα πρέπει να πάει σε συγκεκριμένη θέση, οπότε αν δεν χωράει θα σπάσει τη σελίδα σε δύο μοιράζοντας τις εγγραφές) που έχουν κόστος.

Άρα, καλά τα νουμεράκια που λέει το DBCC SHOWCONTIG αλλά προσοχή στην ερμηνεία τους γιατί το αν είναι καλό ή κακό ένα αποτέλεσμα εξαρτάται πολύ από την χρήση του πίνακα.

Άρα στους Heavy-duty πίνακες θα πρέπει να έχω σχετικά μικρό fill factor στους indexes ;
Το καταλαβαίνω καλά Μάνο ;

Απ: Περί συντήρησης

KelMan — Wed, 05 Jul 2006 19:45:41 GMT

Λοιπόν, ας πούμε για το πρώτο DBCC. Έχουμε και λέμε:

Αποτελείται από 1431 σελίδες. Κάθε σελίδα, ιδανικά, χωράει 8ΚΒ αλλά πολλές φορές δεν μπορούμε να εκμεταλλευτούμε όλον τον χώρο καθώς θα πρέπει να περιέχει ακέραιο αριθμό εγγραφών, οπότε αν δεν χωράει μια εγγραφή στον περισευούμενο χώρο πηγαίνει στην επόμενη σελίδα.

Οι σελίδες οργανώνονται σε "extents". Κάθε extent περιέχει 8 σελίδες, όμως όχι απαραίτητα από τον ίδιο πίνακα. Απλουστευμένα, αυτό που κάνει το DBCC SHOWCONTIG είναι να διαβάζει όλες τις εγγραφές στη σειρά και να μετράει πόσες φορές αναγκάστηκε να κάνει jump (switch) γιατί δεν βρήκε την εγγραφή που περίμενε αλλά κάποια άλλη. Αυτό το switch μπορεί να γίνει από page σε page μέσα στο ίδιο extent ή από page σε page σε διαφορετικό extent. To πλήθος των switches είναι και ο δείκτης του fragmentation σε έναν πίνακα.

Γυρίζοντας στο παράδειγμα, έχουμε 182 extents και 181 switches, δηλαδή ιδανική κατάσταση.

Επίσης, τα extents είναι σχεδόν πλήρη (7.9 Avg. Pages per Extent), πράγμα πολύ καλό.

Οι 1431 σελίδες είναι (ιδανικά) 179 extents άρα αυτό που έχουμε σε σχέση με τα 179, δηλαδή το Scan Density είναι πολύ καλό στο 98.35%.

Τώρα, ως προς το Logical Scan Fragmentation και το Extent Scan Fragmentation.

Αυτά τα νούμερα έχουν νόημα όταν έχουμε τουλάχιστον ένα clustered index πάνω στον πίνακα. Είναι λίγο δύσκολο να εξηγήσω πως βγαίνει αυτή η τιμή καθώς θα πρέπει να γράψω αρκετά περί IAM pages, page pointers, κλπ. Γενικά, αυτά τα νούμερα δείχνουν πόσο καλά είναι οργανωμένo το clustered index του πίνακα και όσο πιο κοντά στο μηδέν είναι η τιμή, τόσο το καλύτερο.

Τέλος, το Avg. Bytes Free per Page και το Avg. Page Density δείχνουν τον ελεύθερο χώρο κατά μέσο όρο και την πυκνότητα των σελίδων αλλά εδώ θέλει προσοχή. Ο SQL Server κάνει τα I/O operations ανά σελίδα. Δηλαδή αν θέλω να διαβάσω έστω και μία εγγραφή θα διαβάσω (υποχρεωτικά) και τις υπόλοιπες της ίδιας σελίδας. Έτσι, όσο πιο γεμάτη είναι μια σελίδα, τόσες περισσότερες εγγραφές διαβάζω με ένα read, τουτέστιν αν θέλω να διαβάσω όλον τον πίνακα θα χρειαστώ λιγότερα I/O's,. Προσοχή όμως! Αυτό δεν είναι απαραίτητα καλό, γιατί αν κάνω πολλά write operations, τότε οι γεμάτες σελίδες θα έχουν ως αποτέλεσμα πολλαπλά page splits (όταν έχω clustered index σε μια σελίδα και προσπαθώ να εισάγω μια εγγραφή, αυτή θα πρέπει να πάει σε συγκεκριμένη θέση, οπότε αν δεν χωράει θα σπάσει τη σελίδα σε δύο μοιράζοντας τις εγγραφές) που έχουν κόστος.

Άρα, καλά τα νουμεράκια που λέει το DBCC SHOWCONTIG αλλά προσοχή στην ερμηνεία τους γιατί το αν είναι καλό ή κακό ένα αποτέλεσμα εξαρτάται πολύ από την χρήση του πίνακα.

Απ: Περί συντήρησης

axaros — Wed, 05 Jul 2006 18:56:35 GMT

Έφτασε :

DBCC SHOWCONTIG scanning '***MyTable***' table...
Table: '***MyTable***' (370100359); index ID: 1, database ID: 13
TABLE level scan performed.
- Pages Scanned................................: 1431
- Extents Scanned..............................: 182
- Extent Switches..............................: 181
- Avg. Pages per Extent........................: 7.9
- Scan Density [Best Count:Actual Count].......: 98.35% [179:182]
- Logical Scan Fragmentation ..................: 0.42%
- Extent Scan Fragmentation ...................: 13.19%
- Avg. Bytes Free per Page.....................: 781.9
- Avg. Page Density (full).....................: 90.34%

DBCC SHOWCONTIG scanning '***MyTable***' table...
Table: '***MyTable***' (370100359); index ID: 15, database ID: 13
LEAF level scan performed.
- Pages Scanned................................: 219
- Extents Scanned..............................: 28
- Extent Switches..............................: 27
- Avg. Pages per Extent........................: 7.8
- Scan Density [Best Count:Actual Count].......: 100.00% [28:28]
- Logical Scan Fragmentation ..................: 12.33%
- Extent Scan Fragmentation ...................: 7.14%
- Avg. Bytes Free per Page.....................: 803.9
- Avg. Page Density (full).....................: 90.07%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.