antonch

ελπίζω να σας άρεσε... και για άλλη μια φορά θα πω χαίρομαι που ασχολούμαι μαζί του (για SQL Server μιλάω) 14 χρόνια τώρα γεμίζει εύκολα τα βράδια μου με τέτοια θέματα...

@Thanasis Kladakis ...ότι και να έχουμε παλιά νέα blob ή μη το ίδιο θέμα υπάρχει...

Σε ευχαριστώ για την διόρθωση, πάμε τώρα στο προκείμενο. Στο 1ο πείραμα που σε έβαλα να κάνεις υπήρχε ένα τρικ. Πρώτα φτιάχθηκε ο Τ1 και μετά ο Τ2 ο οποίος όπως κατάλαβες παίζει το ρόλο του να μεγαλώσει την βάση και μετα σβήνοντας τον να δημιουργεί ο κένος χώρος ώστε να έχει νόημα το shrink. Όμως επειδή έγινε μετά τον δεύτερο θεωρητικά οι σελίδες του είναι προς το τέλος του αρχείου. Άρα διαγράφωντας τον στην ουσία στο τέλος είχαμε το κενό. Όπως είπα και πριν η DBCC SHRINKDATABASE, DBCC SHRINKFILE αλλά και το AUTO_SHRINK στην βάση είναι per file operation και χρησιμοποιούν την GAM page ώστε να βρούν την τελευταία γεμάτη σελίδα (το λέω αρκετά χοντροκομμένα ώστε να είναι εύκολο στην κατανόηση διότι είχα παράνονα όπως το περιέγραψα πριν). Αυτό σημαίνει ότι ήταν αρκετά εύκολη υπόθεση το όλο θέμα και δεν χρειάστηκε να κάνει πολλές επαναλαμβανόμενες αναζητήσεις μέσα στη GAM και να αλλάζει θέσεις σελίδων (εφόσον χρειαζεται να γίνει). Θα το έλεγα ιδανικό σενάριο. Στο 2ο πείραμα όπως τα πράγματα ήταν διαφορετικά. Σε έβαλα πρώτα να φτιάξει και να γεμίσεις τον Τ2 μετά να φτιάξεις και να γεμίσεις τον Τ1 που είχε και τον index. Αυτό σημαίνει ότι εσκεμένα πλέον όταν σβήσαμε τον Τ2 το κενό ήταν στην αρχή του αρχείου. Με τον τρόπο που δουλεύει το shrink με τη λογική της GAM είδε και τα index pages τα οποία έπρεπε να "μαγειρευτούν" (ας μου επιτραπεί η λέξη για λόγους απλότητας και πάλι) με αποτέλεσμα ο index να την ακούσει στερεοφωνικά. Δηλάδη να γίνει fragmented που σημαίνει και περισσότερες σελίδες μιας και δεν είχαμε αλλάγη στα δεδομένα μας. Για το παράδειγμα μας μειώθηκε κατά ελάχιστο η βάση αλλα σαν αποτέλεσμα είχαμε ένα παντελώς άχρηστο index. Κάτι ανάλογο έπαθε και φίλος μας για αυτό και είχε μεγαλύτερο μέγεθος βάσης από την κανονική του όπου πρέπει να επισημάνω ότι είχε την βάση του σε AUTO_SHRINK που είναι ακόμα χειρότερο μιας και δε σου δίνεται ποτέ η δυνατότητα να κάνει ταυτόχρονα και reorganize τον index. Εσύ σωστά το υποπτεύθηκες όπως και εγώ για αυτό και του ζήτησα να περιμένει και να μην κάνει τίποτα. Απλά τον έβαλα να κάνει αυτά που του ζήτησα διότι ήθελα μέσα από τις πληροφορίες αυτές να έχω την πλήρη εικόνα, αλλά και για να τεκμιριώσω τα λεγόμενα μου. Η λύση που του πρότεινα να φτιάξει ένα άλλο filegroup και να μεταφέρει εκεί τον πίνακα και τους index αυτού είναι όπως μάλλον έχεις ήδη καταλάβει για να κάνω εξομιώση το 1ο πείραμα. Φυσικά αυτό απαιτεί σχεδιασμό ή να το πω καλύτερα επαναπροσδιορισμό της δομής της βάσης. Το resume της όλης ιστοριάς είναι, για να μην μακρηγορώ, ότι καλό θα είναι να μη χρησιμοποιούμε ποτέ μα ποτέ (όποιο και να είναι το κόστος) τις DBCC SHRINKDATABASE, SHRINKFILE και το AUTO_SHRINK option σε μια βάση (ειδικά αυτό μακριά και αγαπημένοι), διότι όπως είδες μας κάνουν τους indexes σχεδόν 100% fragmented. Τώρα αν αυτό είναι bug ή όχι πραγματικά δεν ξερω πως να το χαρακτηρίσω σε κάθε περίπτωση είναι θέμα... Φιλικά

Χθες ξεκίνησε ένα thread στο autoexec.gr στο οποίο ενεπλάκηκα και επειδή είναι αρκετά ενδιαφέρον και κατατοπιστικό θα σας έλεγα να το διαβάσετε από την αρχή μέχρι το τέλος.

ΟΚ Απόστολε ... Τώρα κάνε το εξής (επαναλαμβάνω όλα τα βήματα για καθαρό λόγους ευκολίας στην ανάγνωση): 1. Φτιάξε μια νέα βάση - CREATE DATABASE test2 2. CREATE ΤΑΒLE T2 ( f1 INT IDENTITY, f2 CHAR(8000) ) 3. INSERT INTO T2(f2) VALUES('APOSTOLOS APOSTOLOS APOSTOLOS') GO 2560 4. CREATE ΤABLE T1 ( f1 INT IDENTITY, f2 CHAR(8000) ) 5. CREATE CLUSTERED INDEX CI_T1_F1 ON T1 (f1) 6. INSERT INTO T1(f2) VALUES('APOSTOLOS APOSTOLOS APOSTOLOS') GO 2560 7. Εκτέλεσε την sp_helpdb test2 και θα δεις ότι έχεις μια βάση που θα είναι μαζί με το log περίπου 43ΜΒ. 8. Εκτέλεσε την sp_spaceused πάνω σε αυτή την βάση και δες το πόσοστο του unallocated space, σημείωσε το. 9. Σβήσε τον πίνακα Τ2 - DROP TABLE T2 10. Εκτέλεσε ξανά την sp_spaceused πάνω σε αυτή την βάση και δες το πόσοστο του unallocated space, θα δεις ότι έχεις πλέον ελεύθερα τα 20ΜΒ που ήταν δεσμευμένα από τον Τ2. 11. Εκτέλεσε την εντολή SELECT avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID('test2'),OBJECT_ID('T1'),1,NULL,NULL) η οποία θα σου δείξει το ποσοστό που ο clustered index είναι fragmented και θα πρέπει να δεις ότι είναι κάτω από 1% 12. Τώρα κάνε shink database DBCC SHRINKDATABASE(test2) 13. Και ξαναεκτέλεσε την SELECT avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID('test2'),OBJECT_ID('T1'),1,NULL,NULL), θα δεις ότι υπάρχει μια διαφορά αλλά μεγάλη πολύ μεγάλη αυτή την φορά σωστά; Επιβεβαίωσε μας ότι έτσι όπως τα λέω σε παρακαλώ και ρωτάω εγώ τώρα γιατί έγινε αυτό και τι σημαίνει αυτό;

Εαν γυρίσεις σε SQLCMD mode το query δεν χρειάζεται να κάνεις loop

Απόστολε με ποιά σειρά έφτιαξε τους πίνακες? Με αυτή που έχω πεις ή πρώτα έφτιαξες τον Τ2 και μετά τον Τ1?

ops sorry τυπογραφικό λάθος [] Τα κάνατε τα βήματα? Έχουμε αποτελέσματα?

Δεν έχει να κάνει με το reindexing αγαπητέ Απόστολε ... Έχει να κάνει με το shrink database και μάλιστα ισχύει ακόμα και αν δεν έχει blob fields. Για να το δεις κάνε το εξής: 1. Φτιάξε μια νέα βάση - CREATE DATABASE test 2. Σε αυτή φτιάξε ένα πίνακα που απλά να μπαίνει ένα record / page - CREATE TABLE T1 ( f1 INT IDENTITY, f2 CHAR(8000) ) 3. Βάλε και ένα clustered index στο f1 - CREATE CLUSTERED INDEX CI_T1_F1 ON T1 (f1) 4. Γέμισε τον με δεδομένα ώστε να γίνει 20ΜΒ - INSERT INTO T1(f2) VALUES('APOSTOLOS APOSTOLOS APOSTOLOS') GO 2560 5. Φτιάξε ακριβώς ένα ίδιο πίνακα Τ2 χωρίς όμως να φτιάξεις σε αυτόν το clustered index και γέμισε τον όπως και τον προηγούμενο 6. Εκτέλεσε την sp_helpdb test και θα δεις ότι έχεις μια βάση που θα είναι μαζί με το log περίπου 43ΜΒ. 7. Εκτέλεσε την sp_spaceused πάνω σε αυτή την βάση και δες το πόσοστο του unallocated space, σημείωσε το. 8. Σβήσε τον πίνακα Τ2 - DROP TABLE T2 9. Εκτέλεσε ξανά την sp_spaceused πάνω σε αυτή την βάση και δες το πόσοστο του unallocated space, θα δεις ότι έχεις πλέον ελεύθερα τα 20ΜΒ που ήταν δεσμευμένα από τον Τ2. 10. Εκτέλεσε την εντολή SELECT avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID('test'),OBJECT_ID('T1'),1,NULL,NULL) η οποία θα σου δείξει το ποσοστό που ο clustered index είναι fragmented και θα πρέπει να δεις ότι είναι κάτω από 1% 11. Τώρα κάνε shink database DBCC SHRINKDATABASE(test) 12. Και ξαναεκτέλεσε την SELECT avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID('test'),OBJECT_ID('T1'),1,NULL,NULL), θα δεις ότι υπάρχει μια διαφορά αλλά είναι μικρή και βέβαια είναι πάλι κάτω από 1% σωστά; Επιβεβαίωσε μας ότι έτσι όπως τα λέω σε παρακαλώ για να συνεχίσω παρακάτω Σε ευχαριστώ

Με το που θα κάνεις reorganize τον index, αυτός σίγουρα θα γίνει μικρότερος, όμως με το που θα πας να κάνεις ξανά shrink την βάση θα γίνει όπως και τώρα, άρα όπως σου είπα και παραπάνω θα πρέπει να ζήσεις με αυτό. Εαν τώρα ντε και καλα θέλεις να κάνεις shrink τότε θα μπεις στο κόπο να κάνεις τα εξής: Να φτιάξεις ένα νέο filegroup Nα μεταφέρεις όσους πίνακες (και τους indexes αυτών) αντιμετωπίζουν το ίδιο θέμα με τον ΙnMessages (μάλλον και τον OutMessages) στο νέο filegroup χρησιμοποιόντας την CREATE INDEX ... WITH (DROP_EXISTING) ON και αφού γίνει αυτό τότε Να κάνεις shrink το PRIMARY FILEGROUP. Φιλικά

έχεις πέσει στην περίπτωση 1o. Στον πίνακα σου έχεις πεδίο με nvarchar(max) 2ο. Είναι πολύ κακή πρακτική να έχεις auto shrink την βάση σου και γενικά να κάνεις shrink την βάση σου όταν έχει blob fields όπως text, image, varchar(max), nvarchar(max), xml, varbinary(max). Τα LOB fields αποθηκεύουν τις τιμές τους είτε in-row είτε off-row. Τα text, ntext, image που είναι τα παλαιά data types εξ ορισμού αποθηκεύονται off-row. Τα varchar(max),nvarchar(max), xml, varbinary(max) αποθηκεύονται in-row εφόσον η τιμής τους χωράει στη σελίδα που είναι το record αλλιώς off-row. Στην off-row αποθήκευση υπάρχει ένας περίπλοκος pointer o οποίος αποθηκεύεται είτε στο data row είτε στο index row και ονομαζεται blob root και περιέχει ένα Pointer στην root page περιέχει τα δεδομένα αυτά (σημειωση αυτά τα data types μπορούν να αποθηκεύσουν πληροφορία μέχρι 2GB άρα έχω ένα δεντρο απο σελίδες των 8Κ που όλες μαζί συνθέτουν την πληροφορία) και ένα timestamp. Τώρα εσύ έχεις ένα Clustered Index στο πεδίο MsgID και όπως ξέρουμε το leaf level στον clustered index είναι στην ουσία τα data pages (περισσότερα το Σάββατο στο SQL Saturday Night). Από τα στοιχεία που μου έστειλες (συγνώμη που σε παίδεψα, αλλά γενικά όταν κατάλαβα περίπου τι παίζει ήθελα να έχω όλες τι πληροφορίες που χρειαζόμουν διαθέσιμες) και σε ευχαριστώ για αυτό στην προβληματική βάση (που δεν είναι μπορείς να το παθεις και στην κανονική) στα σταστικά με τους Indexes στο πίνακα InMessages υπάρχουν για τον clustered index δύο γραμμές database_id object_id index_id partition_number index_type_desc alloc_unit_type_desc index_depth index_level avg_fragmentation_in_percent fragment_count avg_fragment_size_in_pages page_count 7 1381579960 1 1 CLUSTERED INDEX IN_ROW_DATA 4 0 99,19692565 20295 1,000098546 20297 7 1381579960 1 1 CLUSTERED INDEX LOB_DATA 1 0 0 NULL NULL 4999474 όπως βλέπεις στην κίτρινη γράμμη αυτά αποθηκεύονται ξεχωριστα και δυο γραμμές αυτές κάνουν το index. Κοίτα στο τέλος το πόσες σελίδες είναι. όπως επίσης δες το πόσο fragmented είναι ο index αν και cluster 99,19692565!!!!! Γιατί τώρα έγινε αυτό Εσύ έβαλες τα όμορφα δεδομένα σου και αποφάσισες να σβήσεις κάποια από αυτά. Εαν δεν είχες auto shrink την βάση σου δεν θα έτρεχε κάστανο τώρα όμως τρέχεις και αυτό γιατί η διαδικασία του shrink είναι single file δλδ ένα αρχείο την φορά και όχι μόνο αυτό αλλά χρησιμοποιεί και GAM bitmaps για να βρει τη μεγαλύτερη δεσμευμένη σελίδα στο αρχείο. Αυτό έχει σαν αποτέλεσμα να πηγαίνει συνέχεια μπρος και πίσω και το αποτέλεσμα της είναι να κάνει fragmented τον index από εκεί που ήταν μια χαρα defragmented. Δυστυχώς για σένα δεν υπάρχει μια εύκολη λύση για λύσεις το πρόβλημα σου ή θα πορευτείς με αυτό ή θα βγάλεις το auto shrink. Τώρα για έρθει ο index στα καλά του θα πρέπει να τον κάνεις reorganize. (γάτος ο Απόστολος που είπε για ανατιναγμένους indexes εκει πήγε το μυαλό όλων μας αλλά πρέπει να το τεκμιριώσουμε σωστά Αυτά το ολίγα από μένα

δεν μου λες στο συγκεκριμένο πίνακα έβαλες εγγραφές (προφανώς αρκετές) και μετά έσβησες (και πάλι προφανώς αρκετές)?

Για δείξε μου την δομή του πίνακα InMessages (για να το κάνεις αυτό κάνε δεξι κλικ στον πινακα script table as > create to)

οχι δεν είναι λογικό θα πρέπει να σου φέρει για τρεξε το παραπανω query και στις 2 βασεις με τιμη στο where 1381579960

ωραία αρχίζει να φαίνεται φως για τρεξε στην κανονική αυτό select * from sys.objects where object_id= 1413580074 και στην άλλη το ίδιο με τιμη 1381579960

εξαιρετικά τρεξε και στις 2 αυτό αφού πρωτα στη θεση ΧΧΧ βάλεις το όνομα της βάσης SELECT * FROM sys.dm_db_index_physical_stats(db_id('ΧΧΧ'),null,null,null,null) GO και λύσε μου μια απορία ακόμα έχεις 2 servers και οι δύο έχουν 2008 SQL Server?

μια φορα το καθένα απλά βάλε στην αρχή USE master αλλά δώσε μου και αυτο στην κάθε βάση όμως αυτό create table #rowcount (tablename varchar(128), rowcnt int) exec sp_MSforeachtable 'insert into #rowcount select ''?'', count(*) from ?' select * from #rowcount order by rowcnt desc drop table #rowcount

ωραία πάμε παρακάτω θέλω τα αποτελεσματα των παρακατω sp_helpdb και SELECT DB_NAME(database_id) AS DatabaseName, CAST([Name] AS varchar(20)) AS NameofFile, CAST(physical_name AS varchar(100)) AS PhysicalFile, type_desc AS FileType, ((size * 8)/1024) AS FileSize, MaxFileSize = CASE WHEN max_size = -1 OR max_size = 268435456 THEN 'UNLIMITED' WHEN max_size = 0 THEN 'NO_GROWTH' WHEN max_size -1 OR max_size 0 THEN CAST(((max_size * 8) / 1024) AS varchar(15)) ELSE 'Unknown' END, SpaceRemainingMB = CASE WHEN max_size = -1 OR max_size = 268435456 THEN 'UNLIMITED' WHEN max_size -1 OR max_size = 268435456 THEN CAST((((max_size - size) * 8) / 1024) AS varchar(10)) ELSE 'Unknown' END, Growth = CASE WHEN growth = 0 THEN 'FIXED_SIZE' WHEN growth > 0 THEN convert(nvarchar(30),((growth * 8)/1024)) ELSE 'Unknown' END, GrowthType = CASE WHEN is_percent_growth = 1 THEN 'PERCENTAGE' WHEN is_percent_growth = 0 THEN 'MBs' ELSE 'Unknown' END FROM master.sys.master_files WHERE state = 0 AND type_desc IN ('LOG', 'ROWS') ORDER BY database_id, file_id

Καταρχήν συγνώμη για το προηγούμενο post με τα κεφαλαία. Επειδή το UI δεν λέει πάντα την αλήθεια και επειδή ο καλός DBA πρέπει να γράφει commands για να βγάλουμε άκρη και να μην γίνει καμιά ζημιά θέλω να εκτελέσεις τα παρακάτω και να μας βάλεις τα αποτελέσματα τους. Τρέξε το παρακάτω 2 φορές αλλάζοντας κάθε φορά το ΧΧΧ στο όνομα της βάσης σου. Θέλω να το τρέξεις και για τις 2 βάσεις που έχεις select name, recovery_model, recovery_model_desc, log_reuse_wait, log_reuse_wait_desc, collation_name, compatibility_level from sys.databases where name='ΧΧΧ' και μετά άλλαξε και παρακάτω το ΧΧΧΧ με τα ονόματα των βάσεων use ΧΧΧΧ go select * from sys.database_files select * from sys.data_spaces select * from sys.dm_db_file_space_usage select * from INFORMATION_SCHEMA.TABLES where TABLE_TYPE='BASE TABLE' select TABLE_SCHEMA,TABLE_NAME,COLUMN_NAME,DATA_TYPE from INFORMATION_SCHEMA.COLUMNS where CHARACTER_MAXIMUM_LENGTH=-1 και δώσε μας τα αποτελέσματα Φιλικά

Όχι παλικάρι μου δεν θέλω να σε στεναχωρώ. Δωστε μου λίγο χρόνο γιατί πρέπει να δουμε λίγο κάπως αλλιώς τα πράγματα ετοιμάζω απάντηση

ΠΕΡΙΜΕΝΕΕΕΕΕΕΕΕΕΕΕΕ Μην κάνεις τίποτα (σύντομα αναλυτική απάντηση)

χα χα δεν πρόλαβα πάλι μέχρι να απαντήσω ήρθαν τα δεδομένα που ήθελα Λοιπόν από τις φωτο βγαίνει ότι η βάση έχει πραγματικά δεδομένα δες το 0,77% available free space άρα δεν θα γίνει μικρό. Από το όνομα της βάσης καταλαβαίνω ότι πρόκειτε για κάποιο cms συστημα. Τι αποθηκευονται σε αυτή ξέρεις? Μήπως αποθηκεύονται φωτογραφίες?

Ops! Τώρα διάβασα προσεκτικά όλο το thread. Απο ότι λες το log είναι μικρό άρα ή έχεις πολλά δεδομένα ή για κάποιο λόγο η βάση έχει γίνει extented σε αυτό το μέγεθος που λες. Πως είσαι σίγουρος ότι δεν είναι πραγματικό μέγεθος απο δεδομένα Για πες μας πρώτα με ποιο τρόπο μεγάλωνει το mdf file

Αδερφέ Απόστολε δεν με διαβάζεις συνέχεια.... [:'(] Φίλε μου εδώ είναι η λύση στο προβλημα σου http://autoexec.gr/blogs/antonch/archive/2010/11/03/zzz.aspx

Αγαπητές Φίλες και Αγαπητοί Φίλοι Άλλος ένα χρόνος μας μπήκε, ελπίζουμε με το καλό για όλους. Να μας βγει και καλά είναι ίσως η καλύτερη ευχή για φέτος. Τουλάχιστον σαν κοινότητα φέτος έχουμε σκοπό να κάνουμε περισσότερα και ομορφότερα πράγματα έτσι με μεγάλη χαρά ανακοινώνουμε το 27ο Autoexec.gr Community Event, την Τετάρτη, 19 Ιανουαρίου 2011 στις 18:30, στις εγκαταστάσεις της Microsoft Hellas (Κηφισίας 221, Μαρούσι). Στο event αυτό θα γίνουν: 1. Απολογισμός 2010 και το τι σχεδιάζουμε για το 2011 από τους Moderators. 2. Θα ακολουθήσει κοπή πίτας. Και όπως πάντα θα δοθούν πλούσια δώρα σε όλους και ακόμα πλουσιότερα σε όποιον κερδίσει το φλουρί.. FAQ · Χρειάζεται προεγγραφή; Όχι · Πόσο κοστίζει; Είναι δωρεάν · Χρειάζεται να είμαι μέλος του autoexec.gr; Όχι, αλλά προτείνεται · Πόση ώρα διαρκεί; Περίπου 2 ώρες Μαθαίνετε τα events μας και από την παρουσία μας στο FaceBook