Jump to content

antonch

Administrators
 View Profile  See their activity

  • Posts

    1030

  • Joined

  • Last visited

  • Days Won

    7

 Content Type 

Blog Entries posted by antonch

  1. antonch
    Αρκετές φορές μέσα από τα μαθήματα που κάνω για τον SQL Server όταν αναφέρω ότι το datetime έχει σαν βάση την 1/1/1753 οι μαθητές μου με ρωτάνε το λόγο.
    Ο λόγος είναι ο εξής όπως τον εξηγεί όμορφα ο Tibor Karaszi

    There are historical reasons for this limitation. In what we sometimes refer to as the "Western world," there have been two calendars in modern times: the Julian and Gregorian calendars. These calendars were a number of days apart (depending on which century you looked at), so when a culture that used the Julian calendar moved to the Gregorian calendar, it removed from 10 to 13 days. Great Britain made this shift in 1752. (So, in that year, September 2, 1752 was followed by September 14, 1752.)
    An educated guess as to why Sybase SQL Server—the predecessor of Microsoft SQL Server—selected 1753 as the earliest date is that if you were to store a date earlier than 1753, you would also have to know which country was using which calendar and also handle this 10- to 13-day jump. So Sybase decided to not allow dates earlier than 1753. Note, too, that other countries made the shift later than 1752. Turkey, for instance, did it in 1927.
    Being Swedish, I find it amusing that Sweden had the weirdest implementation. Sweden originally planned to skip every February 29, leap day, over a period of 40 years (from 1700 to 1740) so that Sweden would be in sync with the Gregorian calendar after 1740 (but meanwhile not in sync with anyone else). However, in 1704 and 1708 the leap day wasn't skipped for some reason, so in 1712 (which was a leap year), Sweden inserted yet one more extra day (imagine being born in Feb 30!) and then made the shift over a day, in 1753, in a similar manner to everyone else.
    By Tibor Karaszi, SQL Server MVP

  2. antonch
    Επειδή πάντα θέλω να έχω πρόχειρα τις δυνατότητες ανά έκδοση του SQL Server για να ξέρω τι θα προτείνω στον πελάτη, και επειδή δεν βρήκα κάτι αντίστοιχο όσο και αν έψαξα, έφτιαξα αυτό το poster για να κάνω την δουλειά μου ευκολότερα και το μοιράζομαι μαζί σας.
    Θα το βρήτε εδώ.
    Ελπίζω να σας αρέσει.
  3. antonch
    Επειδή ο φίλος Αθανάσιος το ζήτησε για να μην του χαλάσουμε το χατήρι.

    Αποθηκεύουμε το παρακάτω script σε ένα άρχειο στο δίσκο μας πχ. backup.sql





    declare @weekday char(3)
    declare @command varchar(2048)
    select @weekday=upper(left(datename(dw,getdate()),3))
    set @command = 'backup database $(dbname) to disk =''$(backupPath)\$(backupFileName)_'+@weekday+'.bak' + ''' with init'
    exec (@command)
    και μετά με το sqlcmd εργαλείο του SQL Server από command line γράφουμε το εξής

    C:>sqlcmd –E –i backup.sql –v dbname=”” backupPath=”” backupFileName=””
  4. antonch
    Πριν από λίγο ένας συνεργάτης μου, που έχει πολλούς πελάτες με ERP που είναι σε SQL Server μου ζήτησε να παίρνει backup σε ημερήσια εβδομαδιαία βάση αυτοματοποιημένα. Δηλαδή ένα backup για κάθε database (full βεβαια) κάθε μέρα της εβδομάδας, και την επόμενη εβδομάδα να γράφει πάνω στο προηγούμενο της αντίστοιχης ημέρας.
    Η λύση είναι απλή
    Πάμε και φτιάχνουμε ένα job στον SQL Server Agent, και σε αυτό, στο ένα και μοναδικό step βάζουμε το παρακάτω script:
     




    declare @weekday char(3) declare @dbname varchar(50) declare @backupPath varchar(1024) declare @backupFileName varchar(128) declare @command varchar(2048) set @dbname ='' set @backupPath ='' set @backupFileName='' select @weekday=upper(left(datename(dw,getdate()),3)) set @command = 'backup database ' + @dbname + ' to disk=''' + @backupPath +'\' +upper(@backupFileName)+'_'+@weekday+'.bak' + ''' with init' exec (@command)



    Αλλάζουμε τις τιμές στις μεταβλητές @dbname, @backuPath, @backupFileName, με αυτές που θέλουμε και προγραμματίζουμε το job αυτό να τρέχει κάθε μέρα στην ώρα που θέλουμε.
    Με αυτή την υλοποίηση έχουμε καθημερινό backup για την κάθε ημέρα της εβδομάδας σε ξεχωριστά αν ήμερα devices.
    Καλά database backup!
  5. antonch
    Εδώ και καιρό ήθελα να ασχοληθώ και να γράψω ένα άρθρο με αυτό το θέμα.
    Ένα θέμα το οποίο προσωπικά θεωρώ ότι είναι από τα καλύτερα και δυνατότερα κομμάτια του SQL Server. Με το που το είδα στον SQL Server 2005 (εδώ εμφανίστηκε για πρώτη φορά) έκανα σαν μωρό παιδί που του πήρανε καινούργιο παιχνίδι. Και αυτό γιατί όπως οι περισσότεροι γνωρίζεται είμαι στην μεριά των developers. Από το παρελθόν (21 χρόνια είμαι επαγγελματικά στο χώρο της πληροφορικής) έχω ασχοληθεί με distributed applications, queuing system, asynchronous systems programming. Οι εμπειρίες μου σε μερικές περιπτώσεις είναι τραυματικές με τέτοια συστήματα όπως επίσης και οι χιλιάδες γραμμές κώδικα που έχω γράψει για να υλοποίησω τέτοιες λύσεις. Κυρίως θα ήθελα να τονίσω ότι για να υλοποιηθούν τέτοιες λύσεις θα πρέπει να κάνεις να δουλέψουν σωστά πολλά διαφορετικά εργαλεία και τεχνολογίες.
    Όταν πρωτοείδα τον Service Broker είπα μέσα μου εδώ έχει "ψωμί". Αυτό το "ψωμί" θα προσπαθήσω να το μοιραστώ μαζί σας σε περισσότερα από δύο posts (γιατί το θέμα είναι μεγάλο και δύσκολο).
    Ο Service Broker είναι μια message-queuing τεχνολογία που είναι ενσωματωμένη στον SQL Server, η οποία επιτρέπει στους developers να κάνουν πλήρως intergate τον SQL Server σε distributed applications, μιας και τους παρέχει ένα asynchronous σύστημα για database to database communication. Τι σημαίνει αυτό; ‘Οτι με την χρήση του μπορείς από μια database να στείλεις μηνύματα σε μια άλλη database χωρίς να χρειάζεται να περιμένεις για reponse, πράγμα που σημαίνει ότι οι εφαρμογές θα συνεχίσουν να δουλεύουν ακόμα και όταν η δεύτερη δεν είναι διαθέσιμη.
    Ο Service Broker σαν ένα καθαρόαιμο message-queuing σύστημα δουλεύει με το να στέλνει μηνυματα (messages) τα οποία περιέχουν δεδομένα σε ένα QUEUE. Τα messages παραμένουν αποθηκευμένα στο Queue μέχρι το σύστημα να έχει τα διαθέσιμα resources ώστε να τα επεξεργαστεί κάνοντας τις ενέργειες που το καθένα απαιτεί.
    Έτσι με το Service Broker μπορώ να έχω καλύτερο scalability και resource management καθώς επίσης έχω και τις εγγυήσεις ότι κανένα message που έχει σταλθεί δεν θα χαθεί όπως επίσης και ότι αυτά επεξεργασθούν ακριβώς με την σειρά που μπήκαν στο queue. O Service Broker εγγυάται 100% αξιοπιστία κάτι που δύσκολα, για να μην πω καθόλου, θα το συνατήσεται σε άλλα παρόμοια συστήματα.
    Στον SQL Server 2008 έγιναν μερικές σημαντικές αλλαγές κυρίως στην διαχείρiση μέσα απο Management Studio, τις οποίες θα δούμε αργότερα
    Μέχρι εδώ καταλάβατε τι είναι ο Service Broker;
    Πιθανές απαντήσεις
    Α. ΝΑΙ, προχωράμε λοιπόν παρακάτω
    Β. ΟΧΙ, ξαναδιαβάζουμε το άρθρο από την αρχή
    Είμαι σίγουρος ότι πολλοί αναρωτιέστε που μπορείτε να χρησιμοποιήσετε το Service Broker. Ας δώσω μερικά παραδείγματα.
    Παράδειγμα Α
    Ας υποθέσουμε ότι έχουμε μια εταιρία που έχει δύο sites ( Α και Β ) όπου στο κάθε ένα έχει από μια βάση σε SQL Server. Έστω ότι έχω ένα transaction (distributed) το οποίο ξεκινάει από μια διαδικασια στην database του Α site και το οποίο ενημερώνει την τοπική database αλλα και την database στο Β site.
    Στην περίπτωση που το Β site δεν είναι διαθέσιμο τι θα γίνει με το transaction αυτό;
    Σωστά σκεφτήκατε θα γίνει rollback.
    Όμως αν αντί να ενημερώνω το B (με την λογική του distibuted transaction) έστελνα ένα μήνυμα με την πληροφορία που θέλω να πάει στον Β Service Broker (κατά την διάρκεια του transaction στο A site ) τότε ακόμα και όταν το Β site δεν είναι διαθέσιμο το transaction το οποίο έχω ξεκινήσει στο A site θα είναι committed. Απλά το Β site θα μάθει τι θα κάνει όταν είναι ξανα στον αέρα και αφού διαβάσει τα μηνύματα που του έχουν έρθει. Εδώ θα πρέπει να επισημάνω ότι αν για οποιοδήποτε άλλο λόγο το transaction στο A site γίνει rollback και το μήνυμα το οποίο στάλθηκε στο B site θα γίνει και αυτό rollback. Μήπως θυμάται κανείς σας τι έπρεπε να κάνετε στο κοντινό παρελθόν με COM+ και Messege Queue Service;
    Παράδειγμα Β
    Ας υποθέσουμε ότι θέλουμε να εκτελέσουμε ένα περίπλοκο batch ή query μέσα από την εφαρμογή μας το οποίο είναι και χρονοβώρο. Θα ξεκινούσαμε την εκτέλεση και θα περιμέναμε μέχρι να τελειώσει. Φανταστήτε να γινόνταν η εκτέλεση αυτή μέσα από μια εφαρμογή. Ο χρήστης που την εκτελούσε δεν θα μπορούσε να κάνει τίποτα άλλο μέσα από την εφαρμογή μέχρι αυτή να τελειώσει. Και για να προλάβω κάποιους που θα μου πουν ότι θα το έβαζαν να τρέξει σε ξεχωριστό thread και όλα καλά, απλά να τους θυμίσω τις γραμμές κώδικα που έχουν γράψει για να το πετύχουν αυτό.
    Σε αυτή την περίπτωση θα μπορούσα να στείλω ένα μήνυμα στον Service Broker και αυτός να αναλάβει την εκτέλεση του κάποια στιγμή που δεν θα υπάρχει φόρτος εργασίας.
    Εννοείται βέβαια ότι δεν υπάρχει περίπτωση να χρησιμοποιήσουμε τον Service Broker όταν θέλουμε real time transactions ή θέλουμε να έχουμε άμεσες απαντήσεις. Επίσης εννοείται ότι δεν εκτελούμε SELECT σε μια remote database. Γενικά τον Service Broker τον χρησιμοποιούμε σε σενάρια όπως Asynchronous triggers, Bulk processing, Distributed order processing.
    Με την παραπάνω παράγραφο στο μυαλό μας ελπίζω να σας έδωσα την πραγματική και πρακτική αξία του Service Broker. Αν πραγματικά το βρήσκετε ενδιαφέρον και προκείτε να το αξιοποιήσετε προχωρήστε παρακάτω, αλλιώς ζητώ συγνώμη για τον μέχρι τώρα χρόνο σας. ( ει, δεν θα φύγει κανείς, έχει και συνέχεια!!!)
    Ποία όμως είναι η Αρχιτεκτονική του Service Broker;.
    Βασικά είναι μια ξεκάθαρη client/server αρχιτεκτονική.
    Ένα Service Broker application αποτελείται από ένα client service το οποίο ξεκινάει ένα διάλογο και ένα receiving service το οποίο δέχεται και επεξεργάζεται τα μηνύματα. Κάθε service αντιστοιχίζεται σε ένα queue. O συνδετικός κρίκος ανάμεσα στο service και στο queue είναι το contract το οποίο ορίζει το τύπο του μηνυματος (message) το οποίο στέλνεται από το service στο queue. H ανταλλαγή μηνυμάτων μεταξύ δύο services λέγεται conversation dialog.

    Τί είναι το Service;
    Το service είναι ένα endpoint για το διάλογο του Service Broker. Αυτό είτε μπορεί να είναι ένα service το οποίο ξεκινάει τον διάλογο αυτό (initiating-sending service) με την αποστολή του μηνύματος, είτε είναι ο αποδέκτης (target-receiving service), αυτό δηλαδή που λαμβάνει το μήνυμα από το queue. Κάθε service αντιστοιχίζεται σε ένα queue και σε ένα contract το οποίο ορίζει το τύπο του μηνύματος το οποίο στέλενται στο queue, διασφαλίζοντας το conversation contract.

    Τί είναι το Queue;
    Είναι με απλά λόγια ο κουβάς με τα μηνύματα (εντάξει δεν είναι χύμα στο κύμα αλλά επιτρέψετε μου για χάρη ευκολίας και αστείου να το λέω έτσι). Κάθε queue μπορεί να έχει αντιστιχοιθεί με πολλά services (διαφορετικά, μην ξεχνιώμαστε). Ακόμα κάθε queue μπορεί να συνδεθεί με μια stored procedure η οποία θα εκτελείται κάθε φορά που ένα νέο μήνυμα μπαίνει στον κουβά, δίνοντας μου την δυνατότητα να επεξεργάζομαι το μήνυμα άμεσα (θεικό ε;). Όμως μπορώ να έχω και διαφορετικούς τρόπους επεξεργασίας των μηνυμάτων όπως π.χ. χρησιμοποιόντας τον SQL Server Agent και τα jobs του. Επίσης κάθε queue μπορώ να το έχω active ή όχι χωρίς να πειράζω την όλη υλοποίηση μου (σαν να ήταν ένα service του λειτουργικού).
    Στο σημείο αυτό θα ήθελα να δώσω μερικές χρήσιμες, πιστεύω, παρατηρήσεις για το queue.
    · Εάν το sending και το receiving service είναι στο ίδιο SQL Server instance τότε μπορούν να μοιράζονται το ίδιο queue, αλλιώς διαφορετικά queues.
    · Εάν το receiving queue είναι σε άλλο SQL Server instance ή δεν είναι για κάποιο λόγο ενεργό (active), το μήνυμα θα πρέπει να μπαίνει στο transmission queue για της βάσης όπου το sending service ανήκει. Αυτό ισχύει και αντίστροφα. Χρησιμοποιόντας την view sys.transmission_queue μπορούμε να δούμε τα εκκρεμή μηνύματα.
    Τί είναι το Message;
    Κάθε μήνυμα είναι στην ουσία μια γραμμή στο queue. To format του ορίζεται από το τύπο του μηνύματος (message type) από το contract που υπάρχει ανάμεσα σε δύο services. Μπορεί να είναι empty, well-formed XML, XML το οποίο είναι valid ως προς κάποιο σχήμα ή να περιέχει binary data.

    Τί είναι το Dialog Conversation;
    Αντιπροσωπεύει την ανταλλαγή των μηνυμάτων μεταξύ δύο services. Τα μηνύματα μέσα σε ένα τέτοιο διάλογο μπαίνουν στο queue με την σειρά με την οποία στάλθηκαν. Ο διάλογος σταματάει όταν κάποια από τις εφαρμογές που συμμετέχουν σε αυτόν σταματήσει την συμμετοχής της είτε εκτελώντας την END CONVERSATION εντολή είτε υπάρχει error. Εάν δεν χρησιμοποιήσουμε την παραπάνω εντολή ο διάλογος παραμένει ανοικτός στην database που ανήκει. Με την sys.conversation_endpoints μπορώ να δω τους ενεργούς διαλόγους.
    Κάθε διάλογος διασφαλίζει τα παρακάτω:
    1. Guaranteed delivery
    Ο Service Broker είναι ένα reliable messaging system. Αυτό σημαίνει ότι ο αποστολέας του μηνύματος είναι σίγουρος ότι ο παραλήπτης θα πάρει το μήνυμα αυτό ακόμα και αν κατά την διάρκεια της αποστολής δεν είναι διαθέσιμος.
    2. Long-lived
    Τα dialogs συνήθως ζουν για μερικά δευτερόλεπτα, αλλα μπορούν να ζήσουν και χρόνια ολοκλήρα εφόσον έχω long-running business processes.
    3. Exactly once (αυτό μου αρέσει πολύ)
    Η αποστολή του μηνύματος μέσα από τον διάλογο στον Service Broker μου εγγυάται την μοναδικότητα του μηνύματος. Δηλαδή, ακόμα και αν το initiator service πρέπει να ξαναστείλει το ίδιο μήνυμα επειδή κάτι πήγε στραβά, τότε και τα δυο θα πάνε στον παραλήπτη αλλά μόνο το ένα από τα δυο θα γίνει processes. To άλλο αυτόματα θα διαγραφεί. ( ρε παιδία δεν καιρός να δούμε τον exchange server σε SQL Server database;)
    4. In-order delivery
    Διασφαλίζει ότι τα μηνύματα θα παραληφθούν με την ίδια σειρά που εστάλησαν.
    5. Persistence
    Ένας Service Broker dialog επιβιώνει μετά από restart του database server, επειδή τα messages και οι dialogs είναι persisted απευθείας στην database. Αυτό σημαίνει ότι ακόμα όλα τα l open dialogs αλλά και τα unprocessed messages είναι persisted αυτόματα και γίνονται ξανά διάθεσιμα όταν ξεκινήσει ξανά το database engine service!!!.

    Τί είναι τα Conversation Groups;
    Κάθε conversation group εμπεριέχει έναν ή περισσότερους διαλόγους και επιτρέπει στον Service Broker εύκολα να βρήσκει τα conversations που εμπλέκονται σε μια συγκεκριμένη εργασία. Η σημασία τους είναι τεράστια και αυτό διότι εαν πχ μια εφαρμογή στέλνει ή παίρνει ένα μηνυμα ο SQL Server κλειδώνει το group στο οποίο το μήνυμα ανήκει με σκοπό να παραγματώσει αυτό που είπαμε παραπάνω το EOIO delivery (exactly once in order).

    Τί είναι το Contract;
    To contract ορίζει τον τύπο του μηνύματος που το service χρησιμοποίει για να πραγματώσει την διαδικασία. Είναι η συμφωνία μεταξύ δύο services για το τι το κάθε ένα παίρνει και στέλνει στην επικοινωνία μετάξυ τους . Επίσης διασφαλίζει ότι μόνο οι τύποι των μηνυμάτων που έχουν ορισθεί στο contract θα γίνουν processes.

     
    Τί είναι το Service Broker Endpoint;
    Εάν δύο services σε ένα conversation είναι σε διαφορετικά instances του SQL Server χρειάζεται να δημιουργήσουμε ένα Service Broker endpoint το οποίο θα δέχεται τα incoming and outgoing TCP/IP connections σε συγκεκριμένη πόρτα. 'Ενα SQL Server instance μπορεί να έχει ένα και μόνο ένα Service Broker endpoint το οποίο γίνεται shared σε όλα τα services στο instance αυτό.
    Τί είναι τα Remote Service Bindings;
    Τα Remote Service Bindings χρησιμοποιούνται για να ορίσουμε το security context με το οποίο το initiating service συνδέεται στο remote service το οποίο είναι σε διαφορετικό instance του SQL Server. Τα Remote Service Binding χρησιμοποιούν certificate το οποίο δένεται με συγκεκριμένο database user account για να συνδεθούμε στο remote instance.
    Τί είναι τα Routes;
    Ο Service Broker χρησιμοποιεί τα routes για να εντοπίσει το service με το οποίο θα στείλει το μήνυμα. Εάν δεν υπάρχει κάποιο route το οποίο να είναι συνδεδεμένο με το το service τοτε by default ο Service Broker θα κάνει παράδοση του μηνύματος στο τρέχων instance. Ένα route περιέχει το όνομα του service με το οποίο γίνεται η σύνδεση, το ID του Service Broker instance το οποίο κάνει host το service, και το network address του remote Service Broker endpoint.
    Εδώ λέω να σταματήσω το πρώτο μέρος. Ελπίζω το θέμα αυτό να σας αρέσει. Περιμένω τα σχόλια σας για αυτό.
  6. antonch
    Επειδή δουλεύω συνεχεια με virtual μηχανές και επειδή πολλές φορές θέλω ένα αρχείο απο αυτές όταν είναι κλειστές .
    Εψαξα και βρήκα αυτό http://blogs.msdn.com/virtual_pc_guy/archive/2006/09/01/734435.aspx
    Αλλά και αυτό το οποίο έχει περισσότερες λεπτομέρειες
    http://www.petri.co.il/mounting-vhd-files-with-vhdmount.htm
    Αλλα και αυτό το οποίο έχει μια άλλη προσέγγιση
    http://blogs.technet.com/daven/archive/2006/12/15/vhdmount-without-virtual-server.aspx
  7. antonch
    Πρόσφατα με έναν συνεργάτη μου που είναι dealer μια ελληνικής εταιρίας που έχει ERP αντιμετωπίσαμε το παρακάτω πρόβλημα όταν πήγαμε να εγκαταστήσουμε τον SQL Server 2005 Standard Edition σε pc που είχε εγκατεστημένο Window XP Pro Ελληνικό.
    Σε συνεργασία μαζί του (ευχαριστώ Δημήτρη) σας παρουσιάζουμε την λύση.
    Κατά την στιγμή της εγκατάστασης του SQL Server 2005 ή 2008 παίρνουμε το παρακάτω μήνυμα λάθους στο σημείο που πάει να ενημερώσει τον MSXML Parser.

    The Windows Installer service cannot update the system file C:\WINDOWS\system32\msxml6r.dll because the file is protected by Windows. You may need to update your operating system for this program to work correctly

     
    Αυτό γίνεται διότι η εγκατάσταση του SQL Server 2005 και του 2008 πάει να γράψει στα παραπάνω αρχεία αλλά επειδή είναι File protected δεν σε αφήνει. Αυτό έχει συμβεί με την εγκατάσταση του SP3 των Windows XP Pro ελληνικά διότι η Microsoft τα έχει ενσωματώσει στον κώδικά της.
     
     
    Η λύση κατόπιν επικοινωνίας με την Microsοft είναι η ακόλουθη :
     
    Απεγκατάσταση του MSXML 6 Parser με το utility που θα βρείτε στο παρακάτω link :http://download.microsoft.com/download/e/9/d/e9d80355-7ab4-45b8-80e8-983a48d5e1bd/msicuu2.exe Κατόπιν πάμε στην Registry και στο σημείο HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon όπου βρίσκουμε την μεταβλητή SFCDisable (REG_DWORD) και από 0 την κάνουμε 1 Κάνουμε την εγκατάσταση του SQL Server (θα μας ξαναβγάλει το μήνυμα λάθους αλλά πατάμε ok) και όλα πάνε καλά. Κάνουμε restart και ελέγχουμε ξανά την registry να έχει πάλι η μεταβλητή την τιμή 1 (εάν έχει γίνει 0 την αλλάζουμε). Εγκαθιστούμε το SP2 ή το SP3 του SQL2005 και ξανακάνουμε restart. Στο τέλος ελέγχουμε την μεταβλητή στην registry να είναι 0. Το link της Microsoft για τα παραπάνω είναι το ακόλουθο : http://support.microsoft.com/kb/222473
     
    Εάν τα Windows XP Pro με SP3 είναι αγγλικά δηλαδή ίδια γλώσσα με τον SQL Server δεν ισχύουν τα παραπάνω.
  8. antonch
    Όλοι ξέρουμε το pagefile του λειτουργικού και την χρηστικότητα του.
    Όμως ποιό είναι το ιδανικό μέγεθος του σε ένα server που έχει εγκατεστημένο SQL Server;
    Πρέπει το Pagefile να είναι 1,5 φορές μεγαλύτερο από την φυσική μνήμη του server.
    Εάν έχω ή πρόκειτε να χρησιμοποιήσω full-text search τότε πρέπει να είναι τουλάχιστον τρεις φορές μεγαλύτερο από την φυσική μνήμη του server.
    Για ακόμα καλύτερα αποτελέσματα καλό θα είναι το pagefile να είναι σε ξεχωριστό φυσικό από αυτό του λειτουργικού.
  9. antonch
    Στον SQL Server 2005, και φυσικά υπάρχει και στο SQL Server 2008, πρωτοεμφανίστηκε μια νέα system database η Resource Database.
    Η database αυτή περιέχει όλα τα read-only critical system tables, metadata, και stored procedures τα οποία ο SQL Server χρειάζεται για τρέξει.
    Δεν περιέχει πληροφορίες για το SQL Server instance ή για τις databases σας, και αυτό γιατί δημιουργήται κατά την διαδικασία εγκατάστασης του SQL Server ή όταν εγκαταστήσουμε κάποιο service pack. Περιέχει δε όλα τα objects (table, stored procedures) τα οποία χρησιμοποιούμε σε όλες τις δικίες μας databases.
    H Resource Database βρήσκεται στο directory DATA που έχουμε στήσει τον SQL Server και το όνομα των αρχείων της είναι mssqlsystemresource τόσο για το .mdf όσο και για το .ldf. Εάν έχω πολλά SQL Server instances για κάθε ένα από αυτά έχω και διαφορετική Resource Database.
    Την Resource Database δεν μπορούμε να την δούμε μέσα από τον Management Studio και δεν μπορούμε να την αλλάξουμε. Σε πολύ ειδικές περιπτώσεις και μόνο με συμβουλή του Microsoft Support επιτρέπεται να γίνει κάτι τέτοιο.
    Την συγκεκριμένη database δεν την βάζουμε σε encrypted ή compressed drive, διότι αυτό μπορεί να οδήγήσει σε upgrade ή performance issues.
    Όμως ποιά είναι πρακτική αξία αυτής της system database;
    Στον SQL Server 2000 όταν κάναμε upgrade αυτόν με κάποιο patch ή service pack, παρατηρούσαμε ότι έπρεπε να τρέξουν κάποια μεγάλα scripts τα οποία στην ουσία έκαναν drop και recreate system objects. Εκτός του ότι η συγκεκριμένη διαδικασία ήταν μεγάλη σε χρόνο δεν μας έδινε την δυνατότητα να κάνουμε rollback στην προηγούμενη έκδοση που είχαμε. Στους SQL Servers 2005 & 2008 κάτι τέτοιο δεν γίνεται και αυτό γιατί είτε ρίχνουμε patch είτε service pack αυτό στην ουσία κάνει override την υπάρχουσα Resource Database. Την οποία αν την έχουμε πάρει αντίγραφο πριν την εγκατάσταση του patch ή του service pack διασφαλίζουμε την εύκολη επιστρoφή μας στην προηγούμενη έκδοση.
  10. antonch
    Πριν ξεκινήσω να περιγράφω το συγκεκριμένο εργαλείο, οφείλω να καταθέσω την άποψη μου γι’ αυτό. ΕΙΝΑΙ ΚΑΤΑΠΛΗΚΤΙΚΟ!!!.
    Όσοι έχετε ασχοληθεί από παλία με τον SQL Server, προσωπικά ασχολούμαι από την έκδοση 6.0 (1996), θα έχετε παρακολουθήσει την εξέλιξη του συγκεκριμένου εργαλείου. Σε κάθε έκδοση είχαμε κάποιες βελτιώσεις. Όμως στην έκδοση του SQL Server 2008 πιστεύω ότι έχουμε τις περισσότερες αλλά και τις σημαντικότερες βελτιώσεις. Eίναι μια διαφορετική υλοποίηση του εργαλείου που δίνει μια πληρέστερη εικόνα τόσο στον Database Admin όσο και στον Database Developer.
    Ας ξεκινήσω λοιπόν την περιήγηση στο εργαλείο αυτό.
    Πρώτη αλλαγή είναι το πως τον ξεκινάς. Δεν είναι πλεόν στο Management του SSMS (SQL Server Management Studio). Αλλά πρέπει να κάνεις δεξί κλικ στον server στον Object Explorer και να επιλέξεις την επιλογή Activity Monitor από το menu επιλογών.

    Μετά από αυτο θα δούμε το νέο Activity Monitor

    Όπως θα δείτε υπάρχουν τέσσερα γραφήματα τα οποία δείχνουν
    % Processor Time
    Το ποσοστό του χρόνου που έχει διανυθεί και τον οποίο ο επεξεργαστής έχει δαπανήσει για να εκτελέσει non-idle threads για τον SQL Server σε όλες τις CPUs.
    Waiting Tasks
    Ο αριθμός των tasks τα οποία περιμένουν πόρους είτε του επεξεργαστή, είτε για Ι/Ο, είτε για μνήμη.
    Database I/Ο
    Το transfer rate σε MB/Sec για την μεταφορά των δεδομένων είτε από την μνήμη στον δίσκο, είτε από το δίσκο στη μνήμη, είτε από δίσκο σε δίσκο.
    Batch Requests/sec
    Ο αριθμός των batches που έχουν σταλθεί στον SQL Server.
    Ακριβώς κάτω από τα γραφήματα υπάρχουν τέσσερεις λίστες
    Processes


    Εδώ βλέπουμε κάθε connection που έχει γίνει στον SQL Server και τι ακριβώς κάνει. Η λίστα περιέχει τις εξής πληροφορίες


    Session ID

    Ο μοναδικός αριθμός που παίρνει κάθε connection το γνωστό SPID. Αν δείτε δίπλα του μια κλεψύδρα εύκολα θα καταλάβετε ότι κάτι περιμένει ή είναι μπλοκαρισμένο από κάποιο άλλο connection.

    User Process Flag



    Δείχνει τα αν το συγκεκριμένο process είναι internal (τιμή 0) ή user (τιμή 1). By default δείχνει μόνο τα user αλλά μπορείτε να το αλλαξετε πατώντας το drop down που υπάρχει στο header της κολώνας. Υπάρχει και η τιμή All που τα δείχνει όλα.

    Login



    Το login name με το οποίο το συγκεκριμένο process έχει γίνει.

    Database



    Η τρέχουσα database στην οποία το connection είναι συνδεδεμένο.

    Task State



    Δείχνει εάν το process είναι ενεργό ή όχι. Εδώ μπορώ να έχω τις εξής τιμές
    Done: Ολοκλήρωση Pending: Το process περιμένει ένα worker thread Runnable: Κάτι έχει κάνει λίγο πριν αλλά αυτή την στιγμή δεν κάνει τίποτα αλλά είναι ακόμα συνδεδεμένο. Running: Κάτι κάνει αυτή την στιγμή Suspended: Το process αν και έχει δουλειά να κάνει, έχει σταματήσει γιατί κάτι το εμποδίζει να συνεχίσει. Δες το γιατί από την κολώνα Wait Type.
    Σχόλιο: Διευκρίνηση για το αφεντικό, αυτό δεν δείχνει αν χρήστης το φυσικό πρόσωπο δηλαδή κοιμάτε ή όχι πάνω στο πληκτρολόγιο του. Το λέω γιατί κάποιος πελάτης, μου είπε κάτι τέτοιο στο παρελθόν!!!.


    Command



    Δείχνει το command type (πχ SELECT, DBCC, INSERT, AWAITING COMMAND,…) το οποίο εκτελείτε. Προσοχή δεν δείχνει το πραγματικό command. Εαν θέλετε να δείτε το πραγματικό κάντε δεξί κλικ και επιλέξτε Details.

    Application



    Δείχνει την εφαρμογή με την οποία έχει γίνει το connection. Αυτό μπορεί να ορισθεί από τον developer πάνω στο connection string με το keyword Application Name.

    Wait Time (ms)



    Εαν το process είναι bloked δείχνει τον χρόνο που είναι σε αναμονή σε milliseconds αλλιώς δείχνει 0.

    Wait Type



    Δείχνει το event το οποίο περιμένει το process για να συνεχίσει.

    Wait Resource



    Δείχνει το resource το οποίο περιμένει το process να ελευθερώθεί για να συνεχίσει.

    Blocked By



    Δείχνει το SPID (Session ID) το οποίο έχει μπλοκάρει το process αυτό.

    Head Blocker



    Εαν η τιμή είναι 1 αυτό σημαίνει ότι το Session ID που φαίνεται στην Blocked By κολώνα είναι ο επικεφαλής στην αλυσίδα των μπλοκαρισμάτων.

    Memory Use (KB)



    Δείχνει το ποσό της μνήμης η οποία χρησιμοποιείται από το process αυτό.

    Host



    Δείχνει το computer name από όπου έχει γίνει το connection αυτό.

    Workload Group



    Δείχνει το όνομα του Resource Governor workload group για το query αυτό.
    Resource Waits


    Η λίστα αυτή δείχνει πληροφορίες για την αναμονή στα resources και περιλαμβάνει τις εξής πληροφορίες:
    Wait Category

    Είναι οι κατηγορίες που συγκεντρώνονται για τα wait type statistics. Κάτι αντίστοιχο μπορώ να πάρω με την dmv sys.dm_os_wait_stats.
    Wait Time (ms/sec)
    Ο χρόνος wait time σε ms/sec για όλα τα task τα οποία περιμένουν κάποιο ή κάποια resources στην συγκεκριμένη κατηγορία από το τελευταίο update interval.
    Recent Wait Time (ms/sec)
    O σταθμικός μέσος του wait time ms/sec για όλα τα task τα οποία περιμένουν ένα ή περισσότερα resources στην κατηγορία από το τελευταίο update interval.
    Average Waiter Count
    Ο αριθμός των tasks που περιμένουν για κάποιο ή κάποια resources στην συγκεριμένη κατηγορία σε μια δεδομένη στιγμή.
    Cumulative Wait Time (sec)
    Ο συνολικός χρόνος που τα tasks πρέπει να περιμένουν για ένα ή περισσότερα resources στην κατηγορία από τοτε που ξεκίνησε ο SQL Server ή από τότε που εκτελέσθηκε τελευταία φορά ή DBCC SQLPERF.

    Data File I/O


    Η λίστα αυτή δείχνει πληροφορίες για τα database files των databases που υπάρχουν στον SQL Server, και περιέχει τις εξής πληροφορίες:
    Database

    Το όνομα της βάσης. File Name

    Το όνομα (φυσικό) του αρχειου της βάσης. MB/sec Read

    Το τελευταίο read activity, σε megabytes ανά second, για το database file. MB/sec Written

    Το τελευταίο write activity, σε megabytes ανά second, για το database file. Response Time (ms)

    Ο Μ.Ο του response time, σε milliseconds, για το τελευταίο read-and-write activity στο database file.
    Recent Expensive Queries


    Η λίστα αυτή δείχνει πληροφορίες για τα πιό ακριβά σε resources queries τα οποία έχουν τρέξει στον SQL Server τα τελευταία 30 sec.
    H πληροφορία βγαίνει από την ένωση των dmv sys.dm_exec_requests και sys.dm_exec_query_stats και περιλαμβάνει queries τα οποία είναι σε εξέλιξη αλλά και αυτά τα όποία έχουν τελειώσει μέσα στην χρονική περίοδο των 30 sec, και περιλαμβάνει τις εξης πληροφορίες:
    Query

    Το query statement το οποίο γίνεται monitor.
    Executions/min

    Τα executions ανα λεπτό για το query.
    CPU (ms/sec)

    Η χρήση της CPU από το query
    Physical Reads/sec

    Η χρήση ανα second των physical reads από το query.
    Logical Writes/sec

    Η χρήση ανά second των logical writes από το query.
    Logical Reads/sec

    Η χρήση ανά second των logical reads από το query.
    Average Duration (ms)

    Η μέση διάρκεια εκτέλεσης του query σε milliseconds.
    Plan Count

    O αριθμός των cached query plans για αυτό το query. Ένας μεγάλος αριθμός δείχνει ότι χρειάζεται να στρέψουμε την προσοχή μας στο query αυτό.
  11. antonch
    Σήμερα το πρωί σε μια συνάντηση που είχαμε όλοι οι Έλληνες MCTs ένας συνάδελφος μου έκανε μια ερώτηση.
    “Θέλω να καταγράφω τα events που γίνονται σε μια βάση στο Windows Event Log γιατί θέλω να τα βλέπω από το MOM;”
    Η απάντηση σε αυτό είναι η παρακάτω, όμως θα πρέπει να επισημάνω ότι είναι για SQL Server 2005 μιας και στον SQL Server 2008 δεν υπάρχει η ανάγκη να κάνουμε κάτι τέτοιο μιας και υπάρχει build-in δυνατότητα την οποία υπόσχομαι να παρουσιάσω σε ένα άλλο μου post.
    Η προσέγγιση θα μπορούσε να γίνει και αλλιώς πχ με Event Notifications αλλά επέλεξα την παρακάτω λύση λόγο της απλότητας της.
    Για την υλοποίηση της λύσης, η οποία είναι draft και μπορεί με την βοήθεια σας να γίνει καλύτερη, θα αξιοποιήσω δύο πράγματα.
    Το πρώτο είναι οι DDL Triggers και το δεύτερο η extented stored procedure xp_logevent.
    Έτσι σε κάθε database που θέλω τα event της να καταγράφονται στο windows event log δημιουργούμε τον παρακάτω ddl trigger.
    Θα πρέπει να τονίσω ότι καταγράφονται μόνο τα DDL statements και όχι τα DML statements.
    CREATE TRIGGER WriteToEventLog
    ON DATABASE
    FOR DDL_DATABASE_LEVEL_EVENTS
    AS
    DECLARE @ed XML
    DECLARE @logmsg char(255)

    SELECT @ed = EVENTDATA()

    -- ΕΠΕΛΕΞΑ ΝΑ ΦΕΡΝΩ ΜΟΝΟ ΤΟ T-SQL COMMAND
    -- ΑΛΛΑ ΜΠΟΡΕΙΤΕ ΝΑ ΔΕΙΞΕΤΕ ΚΑΙ ΑΛΛΑ ΣΤΟΙΧΕΙΑ
    -- ΠΟΥ ΥΠΑΡΧΟΥΝ ΣΤΟ XML ΠΟΥ ΕΠΙΣΤΡΕΦΕΙ Ο TRIGGER
    -- ΜΕΣΩ ΤΗΣ EVENTDATA FUNCTION

    SET @logmsg =
    @ed.VALUE('(/EVENT_INSTANCE/TSQLCommand/CommandText[1]','char(255)')

    EXEC xp_logevent 50001,@logmsg,'WARNING'
    go





    Περιμένω τα σχόλια σας.









  12. antonch
    By Sylvia Moestl Vasilik, 2009/06/22
    Μου άρεσε πάρα πολυ και τα αναδημοσιεύω όπως έχει.
    So ... Bob's left the company to move back east, and you're the new lead database developer on the database. Or, the third-party company to which the maintenance has been outsourced is no longer working on it, so it's yours now. One way or another, you need to take over a database system that you had no part in developing. It's not in good shape, and there's not many resources for you to tap.
    What do you do?
    I've been faced with this situation a few times now, and have developed a list of some of the things that have helped me the most, both in getting productive, and in bringing the database system up to par.
    Backups
    Make sure that backups are happening. I'm assuming here that you're the database developer, and not the database administrator. However, just as minimum check, make sure that backups are occurring regularly. Ideally you should successfully restore the backup somewhere else.
    Research
    Look at the database. Go through and get an idea of the table structure, what the largest tables are by size, what the most commonly used stored procedures are, if there are jobs, and what documentation there is. Read through some the stored procedures. You may find it useful to create a quick and dirty database diagram if there isn't one, using the built in diagramming tool in SQL Server. This can also be a good visual aid when you talk to other people.
    Talk to the former developers
    This may not be an option, but try hard to have a least a few friendly interviews with the former developers. This is not the time to make comments like, "I can't believe you guys did [insert bad development practice here]". You don't know the history- maybe it was that way when they got the system. You'll want to get as much information as they can give you on current issues, items on this list, etc. Keep things friendly - and maybe try to get their cell number in case of questions. A good relationship with former developers can go a long way.
    A bug database
    Is there a bug database - somewhere that bugs (and sometimes enhancement ideas) are tracked for this system? This is certainly one of the things that you want to set up, if it's not there currently. I've always been lucky enough to work at companies where bug tracking was taken seriously, and there were systems already in place that I could just plug into. If there's no bug database, time to do some research. I wouldn't suggest reinventing the wheel here, since there's a lot of good systems out there -- just use what's available.
    Source code control
    Is the code in some kind of source code control system, such as VSS or Perforce? If it is -- is everything up to date? I'm going to hazard a guess that it's either not in source code control, or it hasn't been kept up to date. That's been a big task for me when starting work on inherited systems. There's a number of tools with which to tackle this. In the past I've used a custom written Perl tool that used SQL DMO, but I won't go into detail -- that's the topic of another article. If nothing else, you could use the built in tools that SQL Server provides to script out your database objects, and check them in. Once you have everything checked in, try running a database build from the checked in code, and compare it to production. Also -- make sure you have a good system to keep all the code updated!
    Talk to the users and/or business owners
    Sit down and have some conversations with the users. This is a good opportunity to get to know their problems and concerns, the improvements they would most like to see, and where things are heading in the future. You want to make sure that this database is sticking around, that it's not going to be replaced with a third party product or anything like that. If you're going to put a lot of work into improving the system, you need to know that your efforts are going to pay off for the business. Also-you'll probably be spending lots of time on issues that are important to a well-run database system (a bug database, source code control, etc), but that won't give them any new features. Make sure they understand this.
    Establish credibility with the users by fixing a few things or making some enhancements
    Even though you'll probably be needing to spend a lot of time on tasks like setting up source code control, bug tracking, etc, you don't want to do this exclusively. From talks with users, hopefully you've identified enhancements or bug fixes that you could get out quickly. Do what you can here. This is a great way to establish credibility with them. Let them know, too, that once you have the systems in place, bug fixes and enhancements will be much easier to roll out.
    Create a development environment
    If you don't have a development environment, but code still needs to be written, where are the developers going to write and test their code? I hate to tell you, but if they have access, they'll write and test in the production environment. So you may have stored procedures called CampaignEmailExport_TEST hanging around (and never getting deleted). Or -- oops -- you may accidentally overwrite the production version with your new version, and then it runs and causes hundreds of thousands of emails to be sent where they weren't supposed to. Not that I've ever heard of this happening. This kind of problem can go a long way towards convincing users that time and money needs to be spent on working on setting up a good foundation.
    For the development environment-you may be able to just get a backup from production, and set it up on another server. If it's too large, you might need to be creative. Whatever you do, don't develop or test in the production environment.
    Drop obsolete objects
    In a system that hasn't been maintained very well, it's likely that there are a lot of database objects out there that aren't being used. They may have suffixes like 'temp' or 'bak' on them. It can be hard to identify all of these, and you may be tempted to just leave them. However, they can cause a number of problems:
    They make it difficult to figure out what the actual working code base is. If you have a lot of duplicate, backup, "working" or "temp" objects, you don't know what your code base is like, and how complex it is. Supposed you'd like to drop a tables because it's huge, and looks like it hasn't been updated in a long time, but it turns out that they're being used by stored procedure X. If it turns out that stored procedure X is never used, but you're keeping it around in the database anyway, then you've just lost this opportunity to enhance your code because of an obsolete stored procedure. This kind of issue, multiplied by all the obsolete objects that are in the database, can cause development to be very slow, or even grind to a halt. Finally...
    There's potentially months and months of work if you start from scratch on all of the above. It'll require good judgment on what to prioritize, where to start, and how much time to spend on all the tasks that need doing. And perhaps you're not in a position to set all the priorities. But it can be worthwhile and fun to streamline and tune-up a database that just needs a little work to become a well-oiled machine, requiring much less development time.
    Thanks for reading! I welcome feedback in the form of comments, and may post an update to this article with the best suggestions and comments.
  13. antonch
    Είστε σίγουροι ότι έχετε πάρει έστω και μια φορά όλες τις databases σας backup;
    Ειδικά εσείς αγαπητοί συνάδελφοι που έχετε πολλές databases είστε σίγουροι;
    Η απάντηση στο ερώτημα αυτό είναι η παρακάτω stored procedure η οποία θα σας επιστρέψει αμέσως όλες τις database που έχετε ξεχάσει να πάρετε backup.
     
    create proc dbo.spUnbackupedDbs
    @backup_type char(1)='D',
    @time_span_days int=5
    as
    -- Created by Antonios Chatzipavlis
    --
    -- This stored procedure returns all databases in a server
    -- ( except model and tempdb ) at which I have not take any backup
    -- for a specific days from the current day
    --
    -- Parameters
    --
    -- @backup_type : defines the backup type
    -- VALID VALUES
    -- 'D' : Full Backup (DEFAULT VALUE)
    -- 'I' : Diffential
    -- 'L' : Transaction Log
    -- 'F' : File or Filegroup
    -- 'G' : File Diffential
    -- 'P' : Partial
    -- 'Q' : Partial Differential
    --
    -- @time_span_days : defines the amount of days ( DEFAULT VALUE is 5 DAYS )

    select
    a.[name] as database_name
    from master.dbo.sysdatabases a
    left join msdb.dbo.backupset b on a.[name] = b.database_name
    and
    datediff(day,b.backup_finish_date,getdate()) and
    b.type=@backup_type
    where a.[name] not in ('model','tempdb')
    and b.database_name is null
    go

    Δημιουργήστε πρώτα την stored procedure τρέχοντας το παραπάνω script και εφόσον όλα πάνε καλά εκτελέστε την όπως παρακάτω


     


    exec spUnbackupedDbs
  14. antonch
    Πριν προχωρήσω στο αντικείμενο που θέλω να παρουσιάσω θα ήθελα να περιγράψω κάποιες γνωστές έννοιες που θεωρώ ότι είναι καλό να επαναληθούν, μιας και η επανάληψη είναι η μητέρα της μάθησης όπως έλεγαν οι πρόγονοι μας.
    Κάθε application ( και με αυτό τον όρο συμπεριλαμβάνω και τα services ) μπορεί να εκτελεσθεί πολλές φορές. Κάθε εκτέλεση του application είναι ένα instance.
    Κάθε instance που τρέχει είναι ένα process, το οποίο στην ουσία είναι ένας container από ένα ή πολλα threads και τα οποία είναι προγραμματισμένα να κάνουν χρήση του επεξεργαστή για ένα συγκεκριμένο χρονικό διάστημα (time slice) το οποίο είναι οριζόμενο από το λειτουργικό σύστημα.
    Τα threads επιτρέπουν στην εφαρμογή να χρησιμοποιεί με το καλύτερο δυνατό τρόπο τον επεξεργαστή, είτε αυτός είναι ένας, είτε περισσότεροι.
    Τα Windows είναι ένα preemptive (με προτίμηση λόγω κατοχής) multitasking (πολυεπεξεργαστικό) λειτουργικό σύστημα.
    Αυτό σημαίνει ότι σε κάθε περίπτωση που τρέχουμε ένα application το λειτουργικό σύστημα δίνει ένα χρονικό διάστημα στο thread για να τρέξει. Όταν αυτό το χρονικό διάστημα περάσει ή κάποιο άλλο thread με προτεραιότητα μεγαλύτερη (high-priority) από αυτό που τρέχει την δεδομένη χρονική στιγμή, θέλει να τρέξει, τότε το λειτουργικό σύστημα αποθηκεύει την contextual information (συναφή πληροφορία) του τρέχοντος thread, το αντικαθιστά ή το σταματά και φορτώνει την contextual information από κάποιο άλλο thread ώστε αυτό να τρέξει με την σειρά του για το χρονικό διάστημα που του αναλογεί. Αυτό είναι το γνωστό σαν context switching και όλη η διαδικασία σαν Windows preemptive scheduling.
    User Mode Scheduler (UMS)
    Από την έκδοση 6.5 ο SQL Server χρησιμοποιεί ιδανικά το Windows scheduling. Όμως αυτό είναι γενικού σκοπού και για όλα τα application και όπως είναι φυσικό περιορίζει τo scalability (κλιμάκωση) που ο SQL Server προσπαθεί να επιτύχει. Η προσέγγιση του Windows preemptive sheduling έχει σαν αποτέλεσμα το context switching το οποίο είναι ακριβό σαν διαδικασία μιας και εναλλάσετε μεταξύ του user και του kernel mode του επεξεργαστή.
    Έτσι ένα process όπως του SQL Server το οποίο δημιουργεί και χρησιμοποιεί πολλά threads η εκτεταμένη χρήση του context switching έχει αρνητική επίδραση στο γενικότερο performance αλλά και το scalability του. Αυτός είναι και ο λόγος για τον οποίο η ομάδα ανάπτυξης του SQL Server αποφάσισε ότι ο ίδιος o SQL Server πρεπει να κάνει δικό του scheduling. Έτσι ο SQL Server γνωρίζει και ορίζει καλύτερα τις δικιές του ανάγκες για scheduling από ότι το λειτουργικό. Ακόμα θα πρέπει να τονίσω ότι ο SQL Server κάνει καλύτερη υλοποίηση όσον αφορά το thread scheduling και αποφεύγει σχεδόν πάντα το context switching.
    Από την έκδοση 7.0 του SQL Server παρουσιάστηκε η έννοια του User Mode Scheduler (UMS) o οποίος είναι ένα thin layer πάνω από το λειτουργικό σύστημα με πρωταρχικό σκόπο να βελτιστοποιήσει το thread management του SQL Server, ελαχιστοποιόντας το context switching και προσπαθώντας να κρατήσει όσο το δυνατόν τα SQL Server schedules στο user mode.
    Έτσι στο binn folder της εγκατάστασης του SQL Server 7.0 θα βρείτε ένα αρχείο to ums.dll, το οποίο είναι η υλοποίηση του UMS.
    Εδώ θα πρέπει να τονίσω ότι δεν θα γινόταν και τίποτα σπουδαίο αν το UMS εκτός από το scheduling δεν αφαιρούσε από το λειτουργικό χαρακτηριστικά που είναι system dependent όπως τα fibers και asynchronous Ι/Ο.
    Αλλά για να δούμε πως το UMS καταφέρνει να επιβληθεί πάνω στο Windows scheduling;
    UMS έχει την "εμπιστοσύνη" των Windows ότι όλα τα threads εκτός από αυτό που το ίδιο θέλει δεν είναι εφαρμόσιμο ("not viable"). Εαν ένα thread βρήσκεται σε ένα infinite wait state, αυτό σημαίνει ότι εάν ένα thread καλέσει την WaitForSingleObject και περάσει INFINITE σαν timeout value, τα Windows εκλαμβάνουν το thread αυτό σαν "not viable" για scheduling και το αγνοούν. Ο μόνος τρόπος για να ξυπνήσει ένα τέτοιο thread είναι στείλω ένα σήμα στο thread's event object.
    Στο λειτουργικό σύστημα φαίνεται μόνο ένα SQL Server thread ανα επεξεργαστή να είναι ενεργό κάθε φορά. Έτσι ακόμα και εάν έχουμε εκατοντάδες worker threads σε μια δεδομένη χρονική στιγμή, μόνο ένα από αυτά για κάθε επεξεργαστή εμφανίζετε στα Windows να κάνει κάτι.
    Ο Windows scheduler είναι όπως είπαμε preemptive. Από την άλλη μεριά ο UMS προσπαθεί και επιτυχώς ακολουθεί ένα cooperative model και είναι ένας non-preemptive scheduler.
    Ο UMS βασίζεται σε αυτό που λεμε "on threads to yield voluntarily" το οποίο σε ελεύθερη μετάφραση θα το πω "στην εθελούσια παραίτηση του thread".
    O UMS χρησιμοποιεί την προσέγγιση αυτή ώστε να χρησιμοποιήσει τον Windows kernel μόνο όταν είναι πραγματικά απαραίτητος.
    Το UMS cooperative scheduling απαίτησε να γραφτεί τέτοιος κώδικας από το SQL Server development team που θα μου επιτραπεί να τον χαρακτηρίσω λίρα εκατό. Αλλά αυτό άξιζε τον κόπο μιας καταφέρνει να είναι πιο αποτελεσματικο από του λειτουργικού αφού είναι κομένο και ραμένο στα μέτρα του SQL Server.
    Έτσι όταν ένα thread υποχωρεί είτε επειδή τελειώσε το task του είτε επειδή εκτέλεσε κώδικα που αφορούσε κλήση σε μια απο τις yield functions του UMS, αυτός ελέγχει την λίστα με τα threads τα οποία είναι έτοιμα να τρέξουν και λέει στο πρώτο διαθέσιμο οτι μπορεί να τρέξει. Έτσι με αυτό τον τρόπο όλα γίνονται στο user mode και αποφεύγεται το switching στο kernel mode.
    Όταν ο SQL Server ξεκινά, για κάθε επεξεργαστή δημιουργήτε ένας UMS. Κάθε UMS συντηρεί τα ακόλουθα 5 πράγματα:
    Worker List Η λίστα αυτή είναι τα διαθέσιμα threads ή fibers. Ο αριθμός των διαθέσιμων threads ορίζεται από αυτόν που έχουμε ορίσει στο max worker threads option κάνοντας χρήση της sp_configure. Εαν για παράδειγμα έχουμε ορίσει το max worker threads σε 255 σε ένα σύστημα με 8 επεξεργαστές , κάθε επεξεργαστής και κατα συνέπεια κάθε UMS μπορεί να έχει 32 workers (UMS workers). Κάθε ένας UMS worker μπορεί να υποστηρίξει πολλαπλούς χρήστες ή SPIDs.
    Runnable List Η λίστα αυτή δείχνει τους UMS workers που είναι έτοιμοι να εκτελέσουν κάποιο υπαρκτό request. Έτσι όταν ένας UMS worker υποχωρήσει σαν αποτέλεσμα της διαδικασίας υποχώρησης που περιέγραψα πιο πάνω ελεγχετε η λίστα και δίνει σήμα στο επόμενο UMS worker να προχωρήσει με αυτό που έχει να κάνει.
    Resource Waiter List Όταν ένας UMS worker ζητήσει κάποιο resource το οποίο είναι δεσμευμένο από κάποιον άλλον UMS worker μπαίνει στην συγκεκριμένη λίστα οικιοθελώς και μπαίνει σε infinite wait state. Όταν ο UMS worker που έχει το δεσμευμένο resource είναι έτοιμος να το αποδεσμεύσει, κοιτάζει την συγκεκριμένη λίστα και βρήσκει τον πρώτο διαθέσιμο UMS worker που ενδιαφέρεται για το συγκεκριμένο resource τον μεταφέρει στην Runnable List και «ξυπνάει» τον πρώτο διαθέσιμο UMS worker της Runnable List.
    I/O List Είναι η λίστα με τα outstanding asynchronous I/O requests.
    Timer List Είναι η λίστα με τα UMS timer request η οποία στην ουσία λέει πόσο χρόνο θα περιμένω ένα resource μέχρι να γίνει time out.
    Στον SQL Server 7.0 & 2000, μπορείς να χρησιμοποιήσεις τo DBCC SQLPERF(umsstats) undocumented statement για να κάνεις monitor κάθε visible UMS στο σύστημα σου.
    Στον SQL Server 2005 & 2008, μπορείς να χρησιμοποιήσεις την sys.dm_os_schedulers dynamic management view (DMV) για να δεις statistics για τους visible αλλά και για τους hidden schedulers στο σύστημα σου. Για περισσότερες λεπτομέρειες σχετικά με την DMV δείτε στο books online του SQL Server
    Τί είναι το SQLOS;
    Όπως είδαμε το UMS thread management έδωσε την δυνατότητα στον SQL Server να είναι self-managed και εύκολα μπορεί να γίνει scale εάν ένας νέος επεξεργαστής προστεθεί στο σύστημα μας. Από την έκδοση 7.0 του SQL Server όπου για πρώτη φορά παρουσιάσθηκε ο UMS πολλά εσωτερικά engines όπως , ο memory manager, το storage engine, και το relational engine έγιναν upgrade με built-in adaptive algorithms και self-tuning capabilities. Αυτό έδωσε την δυνατότητα στον SQL Server 7.0 όταν βγήκε στην αγορά το 1998 να είναι το πρώτο enterprise database engine το οποίο ήταν δυνατόν να κάνει automatic configuration και dynamic self-tuning.
    Στον SQL Server 2005 η Microsoft πήγε το self-managing και το self-tuning σε ακόμα υψηλότερο επίπεδο. Αυτό είχε σαν αποτέλεσμα ένα νέο component το SQLOS να γεννηθεί..
    Το SQLOS είναι ένα layer το οποίο κάθεται πάνω από το λειτουργικό και είναι υπεύθυνο για την διαχείριση των πόρων του λειτουργικού συστήματος που είναι όμως για τον SQL Server.
    To SQLOS δίνει στον SQL Server την δυνατότητα να εξυπηρετεί τις εσωτερικές του ανάγκες για πόρους καλύτερα και σε μεγαλύτερο εύρος.
    Κάθε component μέσα στο SQLOS είναι έτσι φτιαχμένο ώστε να κάνει κάποιο συγκεκριμένη εργασία καθώς επίσης να συνεργάζεται ομαλά με όλα τα άλλα componets του SQLOS, ώστε να δίνεται ένα large-scale performance προσαρμοζόμενο φυσικά σε διαφορετικά hardware configurations, όπως 32-bit, 64-bit, x64, dual core chips, και large memory addressability.
    Με άλλα λόγια δεν χρειάζεται να γίνουν αλλαγές στο SQL Server configuration ώστε να γίνει το SQLOS adapt to hardware resources ενώ από την άλλη παρέχει ένα άνευ προηγουμένου scalability.
    Εδώ θα πρέπει να επισημάνω ότι στον SQL Server 2005 δεν υπάρχει το ums.dll μιας και αυτό είναι ένα από τα components του SQLOS και αναφέρεται πλέον σαν "Non Preemptive Scheduler"

    Όπως βλέπουμε στην παραπάνω είκόνα υπάρχουν δύο μεγάλα components του SQLOS το non-preemptive scheduling (το γνωστό UMS) και το memory management. Υπάρχουν όμως και άλλα components όπως το resource monitor, ο exception handler, και τα hosting subsystems. Το SQLOS παντρεύει όλα αυτά τα system components και δίνει την δυνατότητα ένος συνεκτικού API που δίνει την δυνατότητα στο SQL Server development team εύκολα να εκμεταλλευθεί τα χαρακτηριστικά του hardware και του λειτουργικού συστήματος.
    Non-Preemptive Scheduling
    Το non-preemptive scheduling component του SQLOS χρησιμοποιήτε για να κάνει scheduling και synchronizing τα concurrent tasks χωρίς να χρειασθεί να κάνει κλήση στο Windows kernel. Είναι υπεύθυνο για το ιδανικό scheduling των Windows threads ή των fibers.
    Ο scheduler είναι υπέθυνος για την διαχείριση των scheduling process και διασφαλίζει οτι μόνο ένα thread processor είναι ενεργό σε κάθε δεδομένη χρονική στιγμή.
    Η sys.dm_os_schedulers DMV είναι αυτή που δείχνει την λίστα των schedulers.
    Ένα collection από schedulers το οποίο παρέχει ένα abstraction layer πάνω από ένα group επεξεργαστών ονομάζεται scheduling node. Με τον όρο αυτός αναφερόμαστε σε ένα unit of work το οποίο είναι scheduled από τον SQL Server.
    Ένα Transact-SQL (T-SQL) statement batch μπορεί να δείχνει σε ένα ή περισσότερα tasks.
    Για παράδειγμα ένα parallel query εκτελείται με πολλαπλά tasks, τα οποία εκτελούνται μέσω worker threads.
    Ένα worker thread αντιπροσωπεύει ένα logical thread στον SQL Server το οποίο εσωτερικά αντιστοιχίζεται (1:1) είτε σε ένα Windows thread είτα σε fiber (εαν έχω ενεργοποιήσει το lightweight pooling στον SQL Server).
    H αντιστοιχία του worker thread σε Windows thread υπάρχει μέχρι το worker thread να γινει deallocated ή επειδή υπάρχει έλειψη μνήμης ή είναι idle για μεγάλο χρονικό διάστημα. Τα Worker threads εκτελούνται και διαχειρίζονται από τα system threads.
    The max worker threads Option
    Κάθε instance του SQL Server συντηρεί ένα pool από Windows threads ή fibers με σκοπό να κάνει processing τα user queries. Αυτό το thread pool βοηθάει στο να γίνει optimize το performance όταν ένας μεγάλος αριθμός από clients είναι συνδεδεμένοι στον server. Το maximum size του pool αυτού ορίζεται από το max worker threads στα server configuration option.
    Η minimum και τα default values για το max worker threads option (το οποίο για να μην ξεχάσω είναι στα advanced options) έχει αλλάξει στον SQL Server 2005.
    Στον Server 2000 η minimum τιμή που μπορούσες να ορίσεις είναι 32, στον SQL Server 2005 είναι 128.
    Στον SQL Server 2000 η default τιμή είναι 255, στον SQL Server 2005 είναι 0. Αυτό σημαίνει ότι μόνος του ο SQL Server θα κάνει αυτόματα configure τον αριθμό των worker threads κατα το startup του service. Εάν είναι 0 τότε ο SQL Server 2005 χρησιμοποιεί την παρακάτω formula ανάλογα με το είμαι σε x32 ή x64 πλατφόρμα.
    Η formula είναι
    # of CPUs
    x32
    x64

    256
    512
    >4
    256 + ( (#CPUs - 4) * 8 )
    512 + ( (#CPUs – 4) * 8 )
    Ενδεικτικά αναφέρω

    Number of CPUs
    32-bit computer
    64-bit computer

    256
    512
    8 processors
    288
    576
    16 processors
    352
    704
    32 processors
    480
    960
    Εδώ είναι θεωρώ σημαντικό να αναφέρω ότι ο SQL Server στην πραγματικότητα δεν δημιουργεί όλα τα threads αλλα δεσμεύει την μνήμη που χρειάζεται για την δημιουργία του αριθμού των threads που έχουν ορισθεί με την max worker threads.
    Εαν τώρα ο αριθμός των χρηστών που είναι συνδεδεμένος την δεδομένη χρονική στιγμή είναι μικρότερος από τον αριθμός που έχει ορισθεί στην max worker threads τότε ένα thread κάνει handle ένα user connection (1:1). Εάν είναι μεγαλύτερος τότε ο SQL Server κάνει pooling ώστε το επόμενο διαθέσιμο worker thread να ικανοποιήσει το request.
    Routing Tasks to a Scheduler
    O SQL Server 2000 χρησιμοποιούσε για τον scheduler τον αλγόριθμο round-robin κατά την στιγμή του connection. Έτσι όλα τα batches στο ίδιο connection τρέχαν στον ίδιο scheduler, αυτό όπως γίνεται κατανοητό μπορούσε να οδηγήσει σε αστάθεια ιδιαίτερα με τα long-lived connections.
    Στον SQL Server 2005, η απόφαση για την επιλογή του scheduler βασίζεται στο πόσο απασχολημένος είναι αυτός.
    Με άλλα λόγια ένα task στον SQL Server 2000 πήγαινε πάντα σε έναν συγκεκριμένο scheduler, στον SQL Server 2005, η επιλογή για το σε ποιον θα πάει το task γίνεται με το ποσο φορτωμένος είναι.
    Κατά τη στιγμή του connection o SQL Server 2005 διαλέγει τον λιγότερο φορτωμένο scheduler. Στο επόμενο batch στο ίδιο connection χρησιμοποιεί τον ίδιο αλογόριθμο έτσι εαν ο τρεχων scheduler είναι ο ποιο φορτωμένος διαλέγει το λιγότερο φορτωμένο.
    Τα πεδία όπως το load_factor και runnable_tasks_count της sys.dm_os_schedulers μπορουν να χρησιμοποιηθούν για την εύρεση του πόσο απασχολημένος είναι ένας scheduler.
    Συνεχίζεται…
  15. antonch
    Ας συνεχίζουμε στο δεύτερο και τελευταίο μέρος τους SQLOS. To 1ο μέρος θα το βρείτε εδω.
    Memory Management
    Τα Windows στην x86 έκδοση τους δίνουν σε όλα τα processes 4GB Virtual Address Space (VAS), η οποία χωρίζεται σε δύο μέρη των 2GB το καθένα, το ένα είναι το user mode partition και το άλλο είναι το kerner mode partition όπως συνηθίζουμε να τα λέμε.
    Εάν ένα application χρειάζεται περισσότερο από τα 2GB του user mode partition στο VAS μπορώ να προσθέσω τον διακόπτη /3GB στο boot.ini αρχείο του λειτουργικού συστήματος. Αυτό σημαίνει ότι θα περιοριστεί το μέγεθος του kerner mode partition του VAS σε 1GB, και το user mode partition θα γίνει 3GB τα οποία θα είναι διαθέσιμα στο application.
    Στα Windows XP και στα Windows 2003 υπάρχει άκομα ένας διακόπτης ο /USERVA ο οποίος μπαίνει και αυτός στο boot.ini και ο οποίος δίνει καλύτερο έλεγχο μιας και μας επιστρέπει να ορίσουμε ακριβώς το μέγεθος που θα έχει user mode partition του VAS ή αν το πούμε αλλιώς το μέγεθος που θα χάσει το kerner mode partition του VAS
    Ακόμα και όταν τα 3GB μνήμης στο user mode partition δεν είναι αρκετά μπορώ, εάν φυσικά χρησιμοποίω επεξεργαστή που είναι Pentium Pro και πάνω, να προσθέσω τον διακόπτη /PAE στο boot.ini, και να εκμεταλευτώ το the Address Windowing Extensions (AWE) που παρέχουν τα Windows ώστε να φτάσω τα 64GB φυσικής μνήμης.
    Εδώ θα πρέπει αν επισημάνω ότι μειώνοντας το μέγεθος του kernel mode partition του VAS στο 1GB στην ουσία μειώνω το χώρο για τις εσωτερικές λειτουργίες και δομές του λειτουργικού.
    Ο SQL Server χωρίζει την δικιά του VAS σε δυο περιοχές

    Βuffer Pool
    H περιοχή αυτή είναι γνωστή και σαν BPoll, και είναι η βασική περιοχή αποθήκευσης στην μνήμη του SQL Server. Χρησιμοποιήτε για τα data & index pages και για όλες τις ανάγκες αποθήκευσης στην μνήμη που είναι μικρότερες των 8KB. Το μέγεθος της ορίζεται από τις τιμές που δίνω στα server configuration options max server memory και min server memory. Η BPoll ποτέ δεν ξεπερνάει τα όρια τα οποία έχουμε ορίζει με τα options τα οποία ανέφερα παραπάνω. Μέσα στην BPoll υπάρχουν γνωστά objects όπως buffer cache, procedure cach, system-level structures, locks, log caches, connection contexts.

    Reserved Address Space (RAS)
    Την περιοχή αυτή αρκετοί την λένε MemToLeave, άλλοι όπως και εγω την λέμε Reserved Address Space. Εμείς οι άλλοι πιστεύουμε ότι η ονομασία MemToLeave είναι παντελώς λάθος αλλά δεν θα ασχοληθώ εδώ με αυτό. Η περιοχή αυτή χρησιμοποιείτε για internal SQL Server allocations τα οποία περνούν τα 8ΚΒ συνεχούς χώρου, αλλά και για allocations που γίνονται από external consumers όπως extended stored procedures, OLE DB providers, in-process COM objects, SQLCLR assemblies κ.λ.π. Το μέγεθος της ορίζεται από την forumla
    RAS = 256 ΜΒ + ( max worker threads * 512 KB )
    Αν ανατρέξουμε στην εικόνα που έχω δώσει στο πρώτο μέρος του θέματος αυτού θα δούμε ότι στον SQL Server 2005 η αρχιτεκτονική του memory management αποτελείτε από αρκετά components όπως memory nodes, memory clerks, caches, pools, και memory objects.

    The memory node component
    Αυτό είναι υπεύθυνο για το μέρος που θα δεσμευθεί (locality of allocations). Αποτελείτε από τις εξής σελίδες:
    single-page allocator, multi-page allocator, large page allocator, reserved page allocator, virtual allocator, shared memory allocator. Memory clerks
    Αυτοί είναι το κλειδί στο granular memory management στον SQL Server 2005. Επιτρέπουν στον SQLOS να παρακολουθεί και να ελέγχει το μέγεθος της μνήμης που δεσμεύεται από το κάθε component.
    Η sys.dm_os_memory_clerks είναι αυτή η DMV την οποία μπορείτε να χρησιμοποιήσετε για να δείτε το memory distribution, όπως και την λίστα των ενεργών memory clerks καθώς επίσης και το μέγεθος των διαφορετικών ειδών μνήμης που έχουν δεσμευθεί από κάθε clerk.
    Για παράδειγμα το παρακάτω query δείχνει πως με την χρήση της sys.dm_os_memory_clerks DMV μπορείτε να δείτε τον κάθε τύπο του memory clerk μαζί με το σύνολο των reserved virtual memory, committed virtual memory, single και multi-pages που έχει δεσμεύσει ο καθένας
    SELECT [type],
    SUM(virtual_memory_reserved_kb) AS TotalVirtualMemoryReservedΚΒ,
    SUM(virtual_memory_committed_kb) AS TotalVirtualMemoryCommittedKB,
    SUM(multi_pages_kb) AS TotalMultiPagesKB,
    SUM(single_pages_kb) AS TotalSinglePagesKB
    FROM sys.dm_os_memory_clerks
    GROUP BY [type]
    ORDER BY TotalVirtualMemoryCommittedKB DESC,
    TotalVirtualMemoryReservedΚΒ DESC,
    TotalMultiPagesKB DESC,
    TotalSinglePagesKB DESC
    Επίσης μπορείτε να κάνετε χρήση της sys.dm_os_virtual_address_dump DMV για να δείτε λεπτομερείς πληροφορίες για την VAS.
  16. antonch
    Λοιπόν μιας και απέκτησα και εδω ένα blog είπα να κάνω σεφτέ με κάτι που λίγο ή πολύ όσοι ασχολούμαστε με SQL Server αντιμετωπίζουμε.
    Πως θα βρω τα queries που κάνουν υψηλή χρήση της CPU;
    H απάντηση στο ερώτημα αυτό είναι η παρακάτω custom stored procedure η οποία δουλεύει σε SQL Server 2005 & 2008
     
    create procedure spFindQueriesThatUseHighCPU
    as
    Set NOCOUNT ON
    SELECT TOP 100
    (a.total_worker_time/a.execution_count) as [Avg_CPU_Time], -- the time is in ms
    Convert(Varchar,Last_Execution_Time) as 'Last_execution_Time',
    Total_Physical_Reads,
    SUBSTRING(b.text,a.statement_start_offset/2,
    (case
    when a.statement_end_offset = -1 then len(convert(nvarchar(max), b.text)) * 2
    else
    a.statement_end_offset end - a.statement_start_offset)/2) as Query_Text,
    dbname=Upper(db_name(b.dbid)),
    b.objectid as 'Object_ID'
    FROM sys.dm_exec_query_stats a
    cross apply sys.dm_exec_sql_text(a.sql_handle) as b
    ORDER BY [Avg_CPU_Time] DESC
    go
  17. antonch
    Πρόσφατα αντιμετώπισα ένα πρόβλημα στα SQL Server 2005 Reporting Services.
    Ενώ όλα ήταν μια χαρά και όλοι μέσα στην εταιρεία δούλευαν μια χάρα, ένα πρωί όπως συμβάνει πάντα σε αυτές τις περιπτώσεις είχαν σπάσει τα τηλέφωνα, είχα 40 mail, και 20 msn χρήστες να θέλουν να μιλήσουν μαζί μου.
    Τι έγινε ρε παιδιά...
    1. πήραμε φωτία;
    2. δεν θα βγει ο Ομπάμα;
    3. θα μας πέσει ο ουρανός στο κεφάλι;
    Τιποτα από όλα αυτά, απλά, όταν πήγαιναν να τυπώσουν είχαν ένα ώραίο μύνημα που τους έλεγε "Unable to load client print control".
    Μετά από ψάξιμο βρήκα ότι η αιτία είναι ότι ένα security patch μπλοκάρει τη εκτέλεση του συγκεκριμένου dll και η λύση είναι
    1. Κατεβάσουμε το Microsoft Report Viewer Redistributable 2005 Service Pack 1
    2. Πάμε και κάνουμε unistall τα security patches KB956803 & KB956391 και από τον server αλλα και από τους clients
    3. Στήνουμε το Microsoft Report Viewer Redistributable 2005 Service Pack 1
    4. Κάνουμε restart τον server
×
×
  • Create New...