antonch

Μπορώ να έχω την δομή του πίνακα σε παρακαλώ

Δεν θα λύσεις το πρόβλημα σου με αυτό που σκέφτεσαι να κάνεις απλά θα το μεταθέσεις σε άλλη βάση, συν το γεγονός ότι θα έχεις δύο φορές το ίδιο πρόβλημα (καθυστέρησης) όταν θα κάνεις merge replication. Υποψιάζομαι ότι στο πίνακα σου έχεις σαν primary key uniqueidentifier. Αν όντως αυτό ισχύει δες το blog post μου για να καταλάβεις το πρόβλημα σου και άλλαξε το default σε αυτό που προτείνω. Αν πάλι δεν μπορείς να αλλάξεις την δομή της βάσης τότε φρόντισε να μεγαλώσεις το fillfactor στον index του primary key πχ 50%. Αυτό βέβαια θα μεγαλώσει το μέγεθος της βάσης σου αλλά θα σου λύσει το πρόβλημα performance που αντιμετωπίζεις.

Καλησπέρα julax

Είναι η γνωστή βάση που κοιτάζαμε την προηγούμενη φορά?

Δεν γνωρίζω να σου απαντήσω αν υπάρχει νομοθετημένο κάτι τέτοιο στην Ελλάδα. Θα πρέπει να ρωτήσεις στο υπουργείο εμπορίου (τώρα το λένε αλλιώς αλλά πάντα το ξεχνάω πως) 

Ορθολογικά σκεπτόμενος, αλλά χωρίς να γνωρίζω, νομίζω ότι ακόμα και αν δεν υπάρχει μπορείς να κάνεις την δουλειά σου με ένα NDA και κάποιο δικηγόρο/συμβολαιογράφο μιας και πρόκειτε για συμφωνία δύο μερών θα είσαι καλυμένος.

Χρήστο θέλω τίτλο και περιεχόμενο παρουσίασης για τον Sharepoint και αλλαγή μήνα διότι όλοι θέλετε τον Σεπτέμβριο!!!!!

Καλά δεν υπάρχει κάνεις που να θέλει να κάνει μια παρουσίαση μέσα στον Φλεβάρη??????!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Γιώργη γίνε λίγο ποιο συγκεκριμένος παλικάρι μου.

Κάποιος φίλος είπε κάτι για Forefront & Exchange υπάρχει κανείς συνάδελφος για αυτό.

Αντε γιατί θα τα κάνω όλα εγω και θα βαρεθήτε να ακούτε SQL Server. []

Ενδιαφέρον γαι Sharepoint υπάρχει???

Φυσικά και υπάρχει διάλεξε ημερομηνία και θέμα και προχώρα

ελπίζω να σας άρεσε...

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

Σε ευχαριστώ για την διόρθωση, πάμε τώρα στο προκείμενο.

Στο 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 ή όχι πραγματικά δεν ξερω πως να το χαρακτηρίσω σε κάθε περίπτωση είναι θέμα...

Φιλικά 

ΟΚ  Απόστολε ...

Τώρα κάνε το εξής (επαναλαμβάνω όλα τα βήματα για καθαρό λόγους ευκολίας στην ανάγνωση):

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), θα δεις ότι υπάρχει μια διαφορά αλλά μεγάλη πολύ μεγάλη αυτή την φορά σωστά;

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

Στο βήμα 4 τον πίνακα τον γέμισα με το script
DECLARE @count int
SELECT @count =2560
WHILE @count > 0
BEGIN
SELECT @count=@count-1
INSERT INTO T1(f2) VALUES('APOSTOLOS APOSTOLOS APOSTOLOS')
END

Εαν γυρίσεις σε 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 δύο γραμμές

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

ωραία αρχίζει να φαίνεται φως

για τρεξε στην κανονική αυτό

select * from sys.objects where object_id=

και στην άλλη το ίδιο με τιμη

εξαιρετικά

τρεξε και στις 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

και δώσε μας τα αποτελέσματα

Φιλικά 

Τώρα με στεναχώρησες. Μπορεί να έχω χάσει τα Sql Saturday nights αλλά τα posts σου τα έχω διαβάσει. Απλά δυστυχώς δε κατάφερα να συνδυάσω ότι λύση σου που αφορά τα transaction log έχει εφαρμογή και στα data. Να κάτι νέο να δοκιμάσω αύριο.

Όχι παλικάρι μου δεν θέλω να σε στεναχωρώ.

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

ΠΕΡΙΜΕΝΕΕΕΕΕΕΕΕΕΕΕΕ

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