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

  2. antonch
    Χρόνια Πολλά σε όλους!
    Εύχομαι ο νέος χρόνος να φέρει υγεία, αγάπη και ευτυχία σε εσάς και τις οικογένειες σας.
    Αυτές τι μέρες βρήκα την ευκαιρία να διαβάσω αρκετά νέα βιβλία τα οποία είχα προμηθευτεί επί τούτου. Μέσα σε όλα αυτά ξεχώρισα τo παρακάτω εισαγωγικό σημειώμα που apriory με εκφράζει απόλυτα.
    Με το που το διάβασα πετάχθηκα από το καναπέ μου και αναφώνησα ΠΕΣΤΑ ΧΡΥΣΟΣΤΟΜΕ. Χαίρομαι ιδιαίτερα όταν αυτά που και εγώ πιστεύω και διδάσκω είναι σύμφωνα με τα λεγόμενα ανθρώπων που είναι έγκυροι και καταξιωμένοι στην επιστημονική κοινότητα.
    Ο εν λόγω κύριος είναι ο Paul Nielsen, SQL Server MVP με πάνω από 30 χρόνια φούρναρης εεε Database Specialist και συγγραφέας του SQL Server Bible http://www.sqlserverbible.com/. Ειδικά το υπογραμμισμένο κείμενο είναι κορυφαίο παράδειγμα για αυτούς που επιμένουν να θεωρούν την βάση σαν ένα κουβά.
    Απολαύστε το

    Any database can be evaluated on six basic criteria: usability, data integrity, scalability, extensibility, availability, and security. Of these database objectives, the first four are primarily driven by the design and development of the database.
    One of the best practices that serves as a root cause for each of the four design driven goals is the elegance of the database design itself.
    The trouble is that elegance of design can be an elusive creature—difficult to define, difficult to achieve, and difficult to teach. But we do know that at the core of every well-designed database are the principles of normalization. In the application development world, technologies are annual trends, but not so in the database world. Even after nearly 40 years, normalization—one grouping of things is one entity, one thing is one tuple, one fact is one attribute, and every attribute must describe the tuple—is still the foundation of database technology.
    In the quest for elegance of design, the concepts of generalization and data driven design augment, but don’t negate, normalization. The war cry of the data architect is still, “The key, the whole key, and nothing but the key!” I am concerned, however, that database development skills—database design, normalization, and T-SQL—seem to be a dying art. In many shops, the lone data architect is outnumbered 50 to 1 by developers who don’t respect the
    importance of data integrity. Managers listen to the crowd, and systems are designed for today rather than for next year, much less the next decade. The design methods and development tools used to encapsulate data should be at least as stable and live as long as the data. And data lasts a long, long time. Ask around, and
    see how many DBAs manage data that’s 10, 20, or 50 years old. Most do.
    The average lifecycle of a popular application development language is 3 to 5 years; a stored procedure written 20 years ago still runs (with maybe a slight tweak to the JOIN syntax). I picture the database as a granite rock that will last for an eon. Occasionally a UI developer comes along and paints a pretty chalk picture on the rock; it washes off and a few more UI developers add their pictures. They all wash off with time, but the rock remains. OK, it’s a stretch, and I do like a great UI, but the point is that any IT architecture should be founded on data integrity.

  3. antonch
    Η Microsoft ανακοίνωσε και έβγαλε στην διάθεση του κοινού την πρώτη CTP έκδοση του Microsoft SQL Server Migration Assistant (SSMA) 2005 & 2008 (δύο ξεχωριστά). Όπως χαρακτηριστικά η εταιρεία λέει “. is a toolkit that dramatically cuts the effort, cost, and risk of migrating from MySQL to SQL Server. SSMA for MySQL v1.0 CTP1 provides an assessment of migration efforts as well as automates schema and data migration”.
    Download links
    Microsoft SQL Server Migration Assistant 2005 for MySQL v1.0 CTP1 Microsoft SQL Server Migration Assistant 2008 for MySQL v1.0 CTP1
  4. antonch
    Σήμερα έλαβα ένα mail από το MVP Program το οποίο με ενημέρωνε ότι έγινα MVP στον SQL Server.
    Ήταν το πρώτο και μοναδικό mail που πήρα για το 2010 και με γέμισε χαρά, ικανοποίηση αλλά και υποχρεώσεις για το μέλλον.
    Θα ήθελα να ευχαριστήσω όλους σας για αυτό και ιδιαίτερα τον Νάσο Κλαδάκη και την Μάρθα Πετροπούλου για την βοήθεια τους και την προτροπή τους στο να προσπαθήσω για τον τίτλο αυτό.
    ΚΑΛΗ ΧΡΟΝΙΑ ΣΕ ΟΛΟΥΣ
  5. antonch
    Πρόσφατα αγόρασα ένα netbook για να έχω κάποια πράγματα τα οποία ήθελα μαζί μου και να μην κουβαλάω μεγάλο βάρος. Θέλησα να βάλω Windows 7 αλλά όπως είναι γνωστό dvd αυτά δεν έχουν. Έτσι ψαχνοντας από εδώ και απο εκεί βρήκα την λύση που σας την δίνω εδω http://www.intowindows.com/how-to-install-windows-7vista-from-usb-drive-detailed-100-working-guide/ . Είμαι σίγουρος ότι οι περισσότεροι την ξέρετε αλλα ίσως υπάρχουν κάποιοι που δεν την γνωρίζουν οπότε καλό είναι να την ξέρουν. Βέβαια μπορεί να χρησιμοποιηθεί και για άλλους σκοπούς, ένα bootable USB είναι πάντα χρήσιμο δεν νομίζετε;
  6. antonch
    Αφορμή για αυτό το post είναι ο Blackman. Σε μια ωραία συζήτηση που είχαμε μου εξέφρασε την επιθυμία για αυτό επειδή μια εφαρμογή που έχει του αφήνει ανοικτά sessions.
    Σε αυτό το σημείο θα πρέπει να αναφέρω ότι κάτι τέτοιο μπορεί να συμβεί είτε διότι η εφαρμογή δεν έχει γραφτεί σωστά, είτε έπειδή ο σταθμός εργασίας που έχει ανοίξει το session σταμάτησε να λειτουργεί είτε η εφαρμογή σταμάτησε απότομα.
    Ο SQL Server βέβαια έχει τους μηχανισμούς για να τα “σκοτώνει” αυτόματα αλλά απαιτείται να πειράξεις registry (http://msdn.microsoft.com/en-us/library/aa275788(SQL.80).aspx) αν θέλεις να γίνεται σε πιο σύντομο διάστημα. Όμως όπως θα δείτε και στο link που σας έδωσα στην ουσία πειράζει το πρωτόκολο επικοινωνίας, και αυτό ίσως να μην το θέλεις αν έχεις και άλλα services.
    Εαν πάντως δεν θέλεις να κάνεις την παραπάνω αλλαγή σας παρέχω 2 τρόπους για να κάνετε kill τα idle sessions.
    ΤΡΟΠΟΣ Α.
    Αυτό ο τρόπος “σκοτώνει” όλα τα idle session σε όλες τις databases εκτός από τις system databases και το session με το οποίο κάνουμε την εκτέλεση της εργασίας.
    Για να το κάνετε αυτό πρέπει πρώτα να πάρετε τον παρακάτω κώδικα να να τον τρέξετε μέσα από ένα query στον SQL Server με επιλεγμένη βάση την master. Αυτός θα σας φτίαξει μια stored procedure σε αυτή την οποία μπορείτε να την εκτελέσετε ως εξής
    EXEC dbo.spKillAllIdleSession
    : είναι ο χρόνος σε λεπτά που το session δεν κάνει τίποτα δηλαδή αν πούμε 20 σημαίνει “σκότωσε όλα τα session που πάνω από 20 λεπτά δεν κάνουν τίποτα.
    π.χ EXEC dbo.spKillAllIdleSession 20




    CREATE PROC dbo.spKillAllIdleSessions
                @IdleTime int    -- Parameter to set your desirable idle time for session in minutes
    /*
        This stored procedure kills all idle processes in sql server 2005, 2008
        except the current process and all processes on system databases
        
        Created by Antonios Chatzipavlis Sep 27, 2009
    */
    as

        DECLARE @killCommand varchar(50)
        DECLARE IdleSessions CURSOR FOR
            SELECT 'KILL ' + Convert(VARCHAR(5), p.spid)
                FROM master.sys.sysprocesses AS p
                    WHERE  p.spid > 50
                    AND p.spid @@SPID
                    AND DateDiff(minute, p.last_batch, GetDate()) > @IdleTime
                    AND p.dbid not in (DB_ID('master'),DB_ID('model'),DB_ID('msdb'),DB_ID('tempdb'),
                                        DB_ID('ReportServer'),DB_ID('ReportServerTempDB'),DB_ID('distribution'))
                    
        OPEN IdleSessions
        FETCH IdleSessions INTO @killCommand

        WHILE 0 = @@fetch_status
        BEGIN
            EXECUTE (@killCommand) -- Actually execute the command
            FETCH IdleSessions INTO @killCommand
        END

        CLOSE IdleSessions
        DEALLOCATE IdleSessions
    GO




    ΤΡΟΠΟΣ Β.
    Αυτό ο τρόπος “σκοτώνει” όλα τα idle session σε συγκεκριμένη database εκτός από το session με το οποίο κάνουμε την εκτέλεση της εργασίας.
    Για να το κάνετε αυτό πρέπει πρώτα να πάρετε τον παρακάτω κώδικα να να τον τρέξετε μέσα από ένα query στον SQL Server με επιλεγμένη βάση την master. Αυτός θα σας φτίαξει μια stored procedure σε αυτή την οποία μπορείτε να την εκτελέσετε ως εξής
    EXEC dbo.spKillAllIdleSessionInDatabase ,
    : είναι ο χρόνος σε λεπτά που το session δεν κάνει τίποτα δηλαδή αν πούμε 20 σημαίνει “σκότωσε όλα τα session που πάνω από 20 λεπτά δεν κάνουν τίποτα.
    : είναι το όνομα της database.
    π.χ EXEC dbo.spKillAllIdleSessionInDatabase 20, ‘MyDB’



    CREATE PROC dbo.spKillAllIdleSessionsInDatabase
                @IdleTime int    -- Parameter to set your desirable idle time for session in minutes
    ,            @DBName varchar(50) -- Parameter to set database name            
    /*
        This stored procedure kills all idle processes in a specific database
        Created by Antonios Chatzipavlis Sep 27, 2009
    */
    as

        DECLARE @killCommand varchar(50)
        DECLARE IdleSessions CURSOR FOR
            SELECT 'KILL ' + Convert(VARCHAR(5), p.spid)
                FROM master.sys.sysprocesses AS p
                    WHERE  p.spid > 50
                    AND p.spid @@SPID
                    AND DateDiff(minute, p.last_batch, GetDate()) > @IdleTime
                    AND p.dbid =DB_ID(@DBName)
                    
        OPEN IdleSessions
        FETCH IdleSessions INTO @killCommand

        WHILE 0 = @@fetch_status
        BEGIN
            EXECUTE (@killCommand) -- Actually execute the command
            FETCH IdleSessions INTO @killCommand
        END

        CLOSE IdleSessions
        DEALLOCATE IdleSessions
    GO




    ΠΑΡΑΤΗΡΗΣΕΙΣ
    Τόσο κατά την δημιουργία, όσο και κατά την εκτέλεση ο χρήστης με τον οποίο έχετε κάνει login στον SQL Server θα πρέπει να είναι στον system role sysadmins. Εαν θέλετε να το φτιάξετε για SQL Server 2000 απλά αλλάξε το σημείο FROM master.sys.sysprocesses AS p σε FROM master.dbo.sysprocesses AS p  
  7. antonch
    Χαίρετε, καιρό είχατε να με ακούσετε ε;
    Δυστυχώς αυτά συμβαίνουν όταν αλλάζεις δουλειά.
    Όμως σιγά σιγά βρίσκω τα νέα βήματα μου οπότε επανέρχομαι δριμύτερος.
    Σήμερα θέλω να σας κουράσω με κάτι που δεν είναι στο administration του SQL Server αλλά στο programming του. Αυτό ακούει στο όνομα Stored Procedures.
    Είμαι σίγουρος ότι αν όχι όλοι οι περισσότεροι τις ξέρετε. Είμαι σίγουρος ότι υπάρχουν φανατικοί υποστηρικτές τους, όπως επίσης και άλλοι που όταν ακούνε το όνομα τους βγάζουν σπυράκια.
    Εάν έχετε ποτέ εμπλακεί σε μια τέτοια κουβέντα, σίγουρα θα έχετε πάρει το μέρος κάποιας πλευράς. Όπως συμβαίνει όμως πάντα σε αυτή τη ζωή η αλήθεια είναι πάντα στην μέση. Ίσως σε αυτή την περίπτωση να γέρνει λίγο περισσότερο στην μία μεριά αλλά καλύτερα αυτό να το αποφασίσετε εσείς μετά από όλα όσα σας πω σε αυτό το post μου.
    Μια σειρά από αλήθειες και μύθους έχουν φτιάξει την διαμάχη αυτή. Νομίζω όμως ότι είναι καιρός να βάλουμε τα πράγματα στην θέση τους όπως ακριβώς έχουν.
    Οφείλω να ομολογήσω ότι και εγώ προσωπικά έχω εμπλακεί σε αυτή την διαμάχη, όπως οφείλω να ομολογήσω ότι είμαι θερμός υποστηρικτής της μίας εκ των δύο.
    Ας πάρουμε τα πράγματα από την αρχή.
    Μία Stored Procedure είναι ένα σύνολο από T-SQL statements τα οποία είναι compiled μέσα σε ένα single execution plan.
    Επειδή ενδεχομένως κάποιος συνάδελφος να ρωτήσει τι είναι το execution plan παραθέτω το παρακάτω link για περισσότερη μελέτη.
    http://msdn.microsoft.com/en-us/library/ms181055.aspx
    Με την χρήση των SPs μπορώ να μεταφέρω την λογική που θα έγραφα μέσα σε κάποια εφαρμογή η οποία έχει να κάνει με τα δεδομένα πάνω στον SQL Server, στο σημείο δηλαδή που τα δεδομένα υπάρχουν. Απλά από την εφαρμογή μου καλώ την SP.
    Το παραπάνω αποτελεί ένα από τα βασικά σημεία τριβής των εμπλεκομένων στην διαμάχη αυτή.
    Οι καταγγέλλοντες τις SP λένε: "Με αυτό τον τρόπο έχω σπάσει το business logic σε πολλά διαφορετικά σημεία (data tier, middle tier) και έτσι μου γίνεται δύσκολη η ζωή στην περίπτωση που θέλω να το αλλάξω γιατί απλά δεν θα ξέρω που θα το βρω. Επίσης δεν μπορώ να έχω κάποιο έτοιμο documentation όπως αν θα το έκανα μέσα από το Visual Studio με τα διάφορα εργαλεία που αυτό έχει. Άσε που με T-SQL δεν μπορώ να κάνω όλα όσα μπορώ να κάνω με C# π.χ. Και εντάξει να κάνω χρήση των SPs αλλά τι θα γίνει στην περίπτωση που ο SQL Server είναι εξαντλημένος από resources; Η/Οι SP(s) δεν θα ανταποκρίνονται για αυτό κάνω το query/ τα queries μου και φέρνω τα δεδομένα στο middle ¨η στον client και κάνω μια χαρά την δουλειά μου."

    Οι υποστηρικτές λένε: "Μα τι λες τώρα. Ίσα ίσα αυτό είναι καλό διότι η λογική μπορεί εύκολα να μοιρασθεί σε περισσότερες εφαρμογές μια και δεν θα χρειασθεί να γραφτεί ξανά μέσα σε αυτές με τον κίνδυνο του λάθους να καραδοκεί. Επίσης επειδή η SP εκτελείται στον SQL Server στο σημείο που είναι τα δεδομένα έχω καλύτερο performance και φυσικά αποσυμφορίζω το δίκτυο από traffic να μεταφέρω τα δεδομένα από τον database server στον application server και σε κάποιες περιπτώσεις και στον client με σκοπό να γίνει η επεξεργασίας τους και μετά να τα επιστρέφω στον database server, αλλά και τον client από φόρτο εργασίας."
    Και τώρα μάλιστα, τα πιάσαμε τα λεφτά μας. Ποιος από τους δύο έχει δίκιο;
    Εδώ λοιπόν θα βρούμε μερικούς μύθους και μερικές αλήθειες.
    ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 1.
    Όντως η T-SQL δεν είναι τόσο δυνατή γλώσσα όπως η C#, αλλά ο σκοπός της δεν είναι να κάνει ότι κάνει η C#. Ο σκοπός της είναι να ασχοληθεί με τα δεδομένα και σε αυτό είναι η τέλεια γλώσσα.
    ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 2.
    Όντως η δυνατότητα για documentation που δίνει ο SQL Server είναι αρκετά φτωχή σε σχέση με τα XML Remarks που έχω στην C#. Όμως έχω το Microsoft Visio, το Microsoft Visual Studio Database Developer Team Suite, και φυσικά μια πληθώρα από άλλα εργαλεία πχ το SQL Toolbelt της Red-Gate ή τα εργαλεία της Apex.
    ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 3.
    "Με αυτό τον τρόπο έχω σπάσει το business logic σε πολλά διαφορετικά σημεία (data tier, middle tier) και έτσι μου γίνεται δύσκολη η ζωή στην περίπτωση που θέλω να το αλλάξω γιατί απλά δεν θα ξέρω που θα το βρω."
    Όντως αυτό είναι ένα πιθανό σενάριο που όμως θα συμβεί από κακό documentation ή κακό σχεδιασμό. Δηλαδή όταν έχει στο middle tier X τον αριθμό από classes, web services κ.λ.π. δεν έχει σπάσει την λογική σε Ν σημεία; Εκτός και αν μιλάμε για Client-Server αρχιτεκτονική όπου όλα τα έχει στον client (Fat client), όπου αφού κάνει την αλλαγή θα πρέπει να την κάνει deploy σε n clients με ότι αυτό συνεπάγεται από χρόνο και κόστος.
    ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 4.
    "Επίσης επειδή η SP εκτελείται στον SQL Server στο σημείο που είναι τα δεδομένα έχω καλύτερο performance και φυσικά αποσυμφορίζω το δίκτυο από traffic να μεταφέρω τα δεδομένα από τον database server στον application server και σε κάποιες περιπτώσεις και στον client με σκοπό να γίνει η επεξεργασίας τους και μετά να τα επιστρέφω στον database server, αλλά και τον client από φόρτο εργασίας."

    "Και εντάξει να κάνω χρήση των SPs αλλά τι θα γίνει στην περίπτωση που ο SQL Server είναι εξαντλημένος από resources; Η/Οι SP(s) δεν θα ανταποκρίνονται για αυτό κάνω το query/ τα queries μου και φέρνω τα δεδομένα στο middle ¨η στον client και κάνω μια χαρά την δουλειά μου."

    Οι υποστηρικτές σε αυτό το σημείο έχουν δίκιο όσο και οι καταγγέλλοντες που μιλάνε για την περίπτωση που ο SQL Server εξαντληθεί από resouces. Αυτό όντως θα γίνει αν ακολουθήσουμε την γενικότερη λογική των δεύτερων δλδ όχι SPs μόνο queries. Βέβαια υπάρχει και η περίπτωση που έχουμε κάνει λάθος εκτίμηση αναγκών, δηλαδή εκτιμήσαμε λιγότερο φόρτο εργασίας από αυτόν που έχουμε, ή αυτός που έγραψε την SP δεν είχε ιδέα από SQL άρα έγραφε όπως ήθελε με αποτέλεσμα να ζητάει το σύμπαν από resources. Αν τίποτα από όλα αυτά δεν συμβεί τότε NAI κερδίζω σε performance όπως επίσης και σε network traffic.
    Ας δούμε όμως τι κερδίζω από την χρήση των SPs σε σχέση με την χρήση των προγραμμάτων που εκτελούν μέσα τους T-SQL.
    Το αντιγράφω όπως είναι από τα BOL του SQL Server, δεν θέλω να το αλλάξω για να μην υπάρξει έστω και η παραμικρή αλλοίωση του νοήματος.
    1. They are registered at the server.
    2. They can have security attributes (such as permissions) and ownership chaining, and certificates can be attached to them.
    3. Users can be granted permission to execute a stored procedure without having to have direct permissions on the objects referenced in the procedure.
    4. They can enhance the security of your application.
    5. Parameterized stored procedures can help protect your application from SQL Injection attacks.
    6. They allow modular programming.
    7. You can create the procedure once, and call it any number of times in your program. This can improve the maintainability of your application and allow applications to access the database in a uniform manner.
    8. They are named code allowing for delayed binding.
    9. This provides a level of indirection for easy code evolution.
    10. They can reduce network traffic. An operation requiring hundreds of lines of Transact-SQL code can be performed through a single statement that executes the code in a procedure, rather than by sending hundreds of lines of code over the network.
    Προσωπικά δεν μπορώ να φανταστώ μια εφαρμογή που δεν χρησιμοποιεί SPs.
    Βέβαια ξέρω τι θα μου πει η άλλη πλευρά.
    "Ναι αλλά θέλω να έχω την δυνατότητα να μιλάω από την εφαρμογή μου με τα διάφορα ORM tools (Object Relational Models) όπως LINQ, Entity Framework και οι SPs δεν μου δίνουν όλα μου δίνουν οι πίνακες". Η απάντηση μου είναι ότι δεν είναι ακριβώς έτσι τα πράγματα, σίγουρα υπάρχουν κάποια πράγματα τα οποία χάνεις όμως η εφαρμογή αγαπητοί μου συνάδελφοι δεν είναι μόνο User Interface και δεν μπορώ να θυσιάζω τα πάντα για αυτό.
    Εξάλλου εάν έχω distributed εφαρμογές όλα αυτά τα εργαλεία που πραγματικά είναι ΦΟΒΕΡΑ δεν έχουν νόημα χρήσης στο UI μιας και μεσολαβεί το middle το οποίο είναι αυτό το οποίο κάνει την επικοινωνία με την βάση. Άρα η χρήση τους περιορίζεται σε αυτό και με άλλους τρόπους (δικά μας object, object lists) μεταφέρουμε τα δεδομένα στο UI.
    Ελπίζω να σας έπεισα και να κάνετε χρήση των SP.
  8. antonch
    Ε1. Παίζει ο SQL Server σε virtualization;
    Ε2. Τι κερδίσω και τι χάνω από αυτό;
    Ε3. Να βάζω πάντα τον SQL Server σε virtual environment ή όχι;
    Ε4. Τι θα με οδηγήσει στο να πάρω την σωστή απόφαση για τον αν θα πάω virtual ή όχι;
    Ερωτήματα που κατά καιρούς μου έχουν τεθεί είτε από μαθητές μου είτε από συνεργάτες μου.
    Θα επιχειρήσω να απαντήσω σε όλα αυτά. Ναι ο SQL Server παίζει σε virtual environment. Αυτό με κάνει να κερδίζω σε total cost of ownership (TCO) μιας και είναι χαμηλό αλλά και return of investment (ROI) μιας και αξιοποιώ 100% το hardware μου. Αλλα δεν είναι μόνο αυτά, εξοικονομώ χρήματα διότι καταναλώνω λιγότερη ενέργεια, χρειάζομαι μικρότερους χώρους, αλλά και έχω μια πιο μαζεμένη διαχείριση των server μου.
    Ακόμα εξοικονομώ χρήματα από τις άδειες χρήσης του SQL Server (Enterprise Editon) μιας και μπορώ να έχω όσες virtual μηχανές θέλω, με SQL Server μέσα σε αυτές, σε μια φυσική μηχανή, αρκεί να έχω αγοράσει άδειες, του SQL Server, για όλους τους φυσικούς επεξεργαστές που υπάρχουν σε αυτή (φυσική μηχανή).
    Υπάρχουν και άλλα πλεονεκτήματα αλλά και μειονεκτήματα, δεν θα τα αναφέρω όλα. Μπορείτε όμως να τα βρείτε από το http://www.microsoft.com/sqlserver/2008/en/us/virtualization.aspx link.
    Εκεί που θέλω να δώσω την μεγαλύτερη βαρύτητα είναι στο με πια κριτήρια επιλέγω να πάω τον SQL Server μου σε virtual environment. Ο βασικότερος για μένα είναι το performance. Όλοι ξέρουμε ότι υπάρχει ένα θέμα με αυτό στα virtual enviroments. Αν και στα Windows Server 2008 R2 με Hyper-V τα πράγματα έχουν γίνει αισθητά καλύτερα, εντούτοις παραμένει ένα θέμα, ειδικά για VLDBs (Very Large Databases) και για heavily transactional OLTP databases, και φυσικά καλό είναι να αποφεύγουμε το virtualization σε τέτοιες περιπτώσεις.
    Ποιες είναι όμως οι περιπτώσεις που θα μπορούσα να έχω το SQL Server σε virtual environment χωρίς να αντιμετωπίσω προβλήματα είτε performance είτε οτιδήποτε άλλο;
    Μερικές τέτοιες είναι οι παρακάτω:
    Consolidating underutilized servers BI components όπως Analysis Services και Reporting Services Managing high availability με Hyper-V Live Migration για hardware maintenance Remote site consolidation με Database Mirroring Development and Test environments. Το θέμα είναι μεγάλο. Οι συζητήσεις και οι ερωτήσεις γύρω από αυτό πολλές. Δεν υπάρχει άσπρο ή μαύρο. Όλα είναι θέμα σωστής εκτίμησης η οποία θα βγει μόνο αν είσαι ενημερωμένος σωστά στο θέμα. Εικασίες, φήμες, και μου το είπε ο Μήτσος δεν χωράνε εδώ.
    Εγώ απλά θέλω να σας τριβελίσω το μυαλό αλλά και να σας δώσω μια σειρά από Links μέσα από τα οποία θα βρείτε πληροφορίες σημαντικές για το θέμα αυτό. Παράλληλα όμως θέλω να σας τονίσω ότι καλό είναι να κρατήσετε σαν μπουσούλα τις παραπάνω περιπτώσεις ένα δεν θέλετε να μπείτε περισσότερο σε βάθος.
    Τα links είναι
    http://www.microsoft.com/sqlserver/2008/en/us/virtualization.aspx http://www.microsoft.com/virtualization/solutions/business-critical-applications/default.mspx http://msdn.microsoft.com/en-us/architecture/dd393309.aspx
  9. antonch
    Το Madison είναι ένας highly scalable data warehouse προσαρμογέας ο οποίος προσφέρει high performance σε χαμηλό κόστος μέσω μιας Massively Parallel Processing (MPP) αρχιτεκτονικής για τον SQL Server.
    Σε σχέση με τον ανταγωνισμό το Madison προσφέρει “hardware flexibility with configurations from the major hardware vendors and low cost through industry standard hardware”, όπως χαρακτηριστικά λεει η ανακοίνωση.
    Με αυτό το project η Microsoft μεγαλώνει το μέγεθος των data warehouses από τα περίπου 50GB που είναι σήμερα πάνω από το 1 Petabyte μέσω scaling out, αυτή την στιγμή έχουν φτάσει στα 20 nodes.
    Μέχρι σήμερα στην δοκιμή αυτή συμμετέχουν 10 πελάτες της Microsoft από 7 διαφορετικές επιχειρηματικές δραστηριότητες. Τα πρώτα αποτελέσματα είναι εντυπωσιακά όπως
    Data loading rate 1 TB / hour Processing query executions > 1,5 ΤΒ / min Για να συμμετέχει κάποιος σε αυτό το CTP θα πρέπει να έχει κάποιες προϋποθέσεις που έχουν ορισθεί, και ο αριθμός των συμμετεχόντων θα είναι περιορισμένος. Για όσους επιθυμούν να συμμετέχουν σε αυτό θα πρέπει να στείλουν mail στο [email protected]
    Για περισσότερες πληροφορίες για το Madison Project θα βρείτε εδώ
    · Madison Website: http://www.microsoft.com/sqlserver/2008/en/us/madison.aspx
    · SQL Server 2008 Website: http://www.microsoft.com/sqlserver/2008/en/us/default.aspx
  10. antonch
    Μέσα σε έναν οργανισμό θα συναντήσουμε πολλές batabase οι οποίες περιέχουν business-critical data. Πάνω από αυτές θα βρούμε applications τα οποία διαχειρίζονται τα δεδομένα αυτά. Καθώς ο όγκος των δεδομένων γεωμετρικά αυξάνετε, αλλά και ο αριθμός των χρηστών που ζητούν πρόσβαση σε αυτά μεγαλώνει, είναι κατανοητό σε όλους ότι η διαθεσιμότητα των δεδομένων πρέπει να είναι αδιάλειπτη, όπως επίσης και η ταχύτητα απόκρισης στα ερώτημα και στα transactions των χρηστών πρέπει να είναι μεγάλη και σταθερή. Ο SQL Server 2008 παρουσίασε μια σειρά από εργαλεία τα οποία σκοπό έχουν να βοηθήσουν τον DBA στο να παρέχει τα παραπάνω. Ένα από αυτά τα εργαλεία είναι και ο RESOURCE GOVERNOR με τον οποίο θα ασχοληθώ σε αυτό το post μου.
    Το πρόβλημα
    Στις προηγούμενες εκδόσεις του SQL Server όταν ήμασταν σε ώρες αιχμής κάποιες βασικές εφαρμογές βλέπαμε να υποφέρουν κυριολεκτικά σε performance και αυτό διότι υπήρχαν άλλες λιγότερο βασικές εφαρμογές που έτρεχαν παράλληλα εκτελούσαν "βαριές εργασίες". Όμως ακόμα και στην περίπτωση που έχουμε μια βασική εφαρμογή αλλά μεγάλο αριθμό χρηστών, που ο καθένας όμως κάνει εργασία με διαφορετικό βάρος στην παραγωγική διαδικασία της ημέρας, πόσες φορές έχουμε έρθει αντιμέτωποι με προβλήματα όπως η τιμολόγηση ή το λογιστήριο ή ακόμα χειρότερα το αφεντικό να "σέρνονται"; Η αιτία για όλα αυτά είναι ότι όλες οι εφαρμογές και όλοι οι χρήστες έπαιρναν στο μέτρο του δυνατού ισόποσα ποσοστά χρήσης τόσο της μνήμης όσο και της CPU.
    Την λύση στα παραπάνω ήρθε να δώσει ο Resource Governor.
    Τί είναι ο Resource Governor?
    Ταξινομεί τα εισερχόμενα connections και τα βάζει το καθένα σε προκαθαρισμένο workload group. Ομαδοποιεί τα resources σε resource pools, που το κάθε ένα ορίζει όρια όσον αφορά την χρήση της CPU και της μνήμης. Συνδέει τα workload groups σε resource pools. Παρακολουθεί τα resources χρησιμοποιώντας το workload group. Ορίζει την προτεραιότητα μεταξύ των workload groups. Τι είναι τα Resource Pools?
    Ένα recourse pool συσχετίζεται με τους φυσικούς πόρους που ο server μας έχει. Με την ολοκλήρωση της εγκατάστασης του SQL Server 2008 έχω εκ προοιμίου δύο resource pools, τα default (χρησιμοποιείται για όλα τα groups που δεν τους έχω ορίσει pool) και internal (είναι για τις εσωτερικές εργασίες του SQL Server). Μπορώ να φτιάξω και τα δικά μου και κάθε resource pool μπορώ να ορίσω (δεν μπορώ να το κάνω στα default και Internal) τα εξής:
    Minimum CPU percentage (0->100) Maximum CPU percentage (100->0) Minimum memory percentage (0->100) Maximum memory percentage (100->0) Τι είναι τα Workload Groups?
    Είναι ο container για τα session requests τα οποία τα ίδια κριτήρια ταξινόμησης. Με την ολοκλήρωση της εγκατάστασης του SQL Server 2008 έχω εκ προοιμίου δύο workload groups τα default και internal, τα οποία εξ' ορισμού ανήκουν στα default & internal resource pools. Εδώ θα πρέπει να επισημάνω ότι και αυτά που θα φτιάξω εγώ μπορούν να ανήκουν σε ένα και μόνο ένα resource pool. Σε κάθε workload group μπορώ να ορίσω τα εξής:
    Assign a Priority Ορίζω το priority (Low, Medium, High).
    Limit Maximum Requests Ορίζω τον αριθμό των ταυτόχρονων requests τα οποία επιτρέπονται να εκτελεστούν στο συγκεκριμένο workload group.
    Limit CPU Time (Sec) Ορίζω το maximum χρόνο της CPU που ένα request μπορεί να χρησιμοποιήσει.
    Limit Memory Grant % Ορίζω το maximum ποσοστό μνήμης που ένα request μπορεί να πάρει από το pool.
    Limit Grant Timeout (Sec) Ορίζω το maximum του χρόνου που ένα query θα περιμένει ένα resource να γίνει διαθέσιμο πριν αποτύχει.
    Limit Degree of Parallelism Ορίζω τον maximum αριθμό επεξεργαστών που το request μπορεί να χρησιμοποιήσει.
    Τι είναι τo Classifier Function?
    Είναι το function αυτό με το οποίο γίνεται η ανάθεση του νέου session/εφαρμογή σε workload group. Αυτό είναι ένα και μόνο ένα κάθε φορά δηλαδή δεν μπορώ να έχω ταυτόχρονα δύο classifier functions. Μετά από κάθε αλλαγή σε αυτό θα πρέπει να κάνω reconfigure τον R.G.
    Μέσα σε αυτό το function μπορώ να χρησιμοποιήσω system functions για να κατατάξω το session/εφαρμογή στο workload group όπως τα
    HOST_NAME APP_NAME Προσοχή σε αυτό διότι είναι κάτι το οποίο ορίζεται μέσα στο connection string της εφαρμογής και μπορεί να αλλαχθεί ανά πάσα στιγμή από κάποιον με σκοπό να πάρει καλύτερο workload group.
    SUSER_NAME SUSER_SNAME IS_SRVROLEMEMBER IS_MEMBER ORIGINAL_DB_ΝΑΜΕ και άλλα Δέστε στα BOL τι κάνει το καθένα.
    Υπάρχουν περιορισμοί?
    Βέβαια υπάρχουν και περιορισμοί και αυτοί είναι:
    Δουλεύει μόνο με το Database Engine. Δηλαδή όχι Analysis, Integration, Reporting Services. Ορίζεται ξεχωριστά για κάθε instance. Δηλαδή δεν έχω κεντρική διαχείριση για όλα τα instances του SQL Server. Δεν έχω την δυνατότητα να ελέγξω IO allocations μόνο MEMORY & CPU (μάλλον στην επόμενη έκδοση) Σε καμία περίπτωση δεν μπορώ να πως σε ένα συγκεκριμένο query να πάει γρηγορότερα. Ο Resource Governor είναι διαθέσιμος μόνο στην Enterprise Edition του SQL Server 2008. Παρατηρήσεις
    Ο R.G εφαρμόζεται μόνο όταν υπάρχει ανάγκη να εφαρμοστεί. Πχ. έχω μια εφαρμογή η οποία ανήκει σε ένα workload group στο οποίο έχω ορίσει max CPU 40%. Εφόσον την δεδομένη χρονική στιγμή που εκτελείται η εφαρμογή δεν υπάρχει κάποια άλλη που να είναι σε κάποιο άλλο group με μεγαλύτερο ποσοστό, δύναται να χρησιμοποιήσει όλη την CPU. To άθροισμα των μικρότερων (minimum) τιμών δεν μπορεί να περνάει το 100% Ότι πόρους αφήνουν ελεύθερους τα pools αυτά μοιράζονται. DEMO
    Την υλοποίηση του demo την έκανα με T-SQL. Βέβαια υπάρχει και γραφικό περιβάλλον για να υλοποιήσεις τον Resource Governor όπως θα δείτε και στα παρακάτω screen shoots.


    To demo θα το βρείτε εδώ
     
    Τα σχόλια σας είναι πάντα ευπρόσδεκτα!
  11. antonch
    Αρκετοί με ρωτούν όταν μέσα στα μαθήματα που κάνω όταν λέω SQL Server τον προφέρω "sequel server", ενώ όταν αναφέρομαι στην γλώσσα Transact SQL λέω "transact ess kyoo ell".
    Θα σας δώσω λοιπόν την εξήγηση, την οποία εχω υιοθετήσει. Την έχω διαβάσει σε αρκετά sites και βιβλία, αλλά έχω ρωτήσει και αρκετά άτομα από το SQL Server Development Team της Microsoft στο τελευταίο μου ταξίδι στο Microsoft Campus στο Redmond πέρσι.
    Υπάρχουν δύο βασικοί λόγοι. Ο ένας είναι ιστορικός και ο άλλος γλωσσολογικός.
    Ο ιστορικός λόγος είναι γιατί το 1970 η IBM ανέπτυξε μια γλώσσα την οποία ονόμασε SEQUEL σαν απόρροια ακρωνυμίου από το Structured English QUEry Language. Η γλώσσα αυτή φτιάχτηκε για να κάνει maniplulate data τα οποία ήταν αποθηκευμένα στην database System R η οποία βάση, ήταν βασισμένη πάνω στο RDBMS μοντέλο του Dr. Edgar F. Codd (εαν βρείτε το βιβλίου του διαβάστε το αξίζει ).
    Το 1986 το ANSI υιοθέτησε σαν standard την γλώσσα αυτή και το 1987 την έκανε ISO κόβοντας ταυτόχρονα το όνομα σε SQL και δηλώνοντας και τον τρόπο προφοράς της σε "ess kyoo ell".
    Ο γλωσσολογικός λόγος είναι η απλότητα που δίνεται στην προφορά για όλους τους αγγλόφωνους.
    Τώρα γιατί έχει "καθιερωθεί" ο Microsoft SQL Server να προφέρετε Microsoft Sequel Server; Για να δείξουν ότι είναι RDBMS και όχι γλώσσα δεδομένων υιοθέτησαν την αρχική ονομασία.
    Και για να προλάβω μερικούς...
    Την ονομασία αυτή δεν την έδωσε η Microsoft αλλά οι εταιρίες που αρχικά έφτιαξαν τον SQL Server, για την ιστορία ήταν οι Sybase, Ashton Tale (dBase) και Microsoft, και αυτό έγινε το 1987 που ξέρουμε ποιός από τους τρεις ήταν ο ισχυρός.
  12. antonch
    Με αυτό το post μου σε καμία περίπτωση δεν θέλω να εγείρω ατέρμονες συζητήσεις και διαμάχες απλά να καταγράψω και να σχολιάσω θέλω μια είδηση που βρήκα τυχαία εδώ και αναφέρει ότι η ORACLE έκανε αύξηση στη τιμή της 11g κατά 40%! μέσα σε αυτή την δύσκολη οικονομική συγκύρια.
    Από την άλλη η "επάρατη" Microsoft συνεχίζει να πουλάει με την ίδια τιμή τον SQL Server 2008 και μην μου πείτε ότι είναι καλύτερη η ORACLE 11g από τον SQL Server 2008 γιατί ξέρουμε όλοι ότι κάτι τέτοιο δεν ισχύει.
    Για όσους πάντως θέλουν να δουν τι θα πληρώσουν αν αγοράσουν SQL Server 2008 εδώ θα βρείτε ένα calculator που υπάρχει στον site του SQL Server.
    Εγώ δεν έχω να προσθέσω τίποτα άλλο, τα σχόλια και οι επιλογές είναι δικά σας πλέον.
  13. antonch
    Τις τελευταίες μέρες κάνω διάφορα πειράματα και δοκιμές στον SQL Server 2008 πάνω σε Windows Server 2008 R2.
    Έτσι έφτιαξα μια μηχανή στην οποία ήθελα να έχω περισσότερα από ένα instances του SQL Server 2008.
    Έστησα το πρώτο έκανα και τα απαραίτητα updates & restarts και πήγα να στήσω το δεύτερο. Με το που ξεκίνησε μου βγάζει το μήνυμα

    “Invoke or BeginInvoke cannot be called on a control until the window handle has been created.”

    ‘Επειτα από μια έρευνα που έκανα βρήκα ότι αυτό γίνεται εξαιτίας της αλλαγής συμπεριφοράς που έχει το .NET Framework τόσο στον Windows Server 2008 R2, όσο και στα Windows 7, που αφορά το πως γίνεται handle τα UI dialogs με αποτέλεσμα σε κάποιες περιπτώσεις να βγάζει το μήνημα αυτό. Μάλλον είναι bug αλλά για να είμαι σίγουρος θα περιμένω την επιβεβαιώση. Από ότι φαίνεται αυτό θα το συναντήσουμε και στην R2 έκδοση του SQL Server 2008.
    Το καλό βέβαια είναι ότι δεν δημιουργεί ιδιαίτερο πρόβλημα μιας και αν αμέσως ξαναξεκινήσεις το setup αυτό θα προχωρήσει κανονικά.
    Φιλικά
    Αντώνης
  14. antonch
    Σήμερα αντιμετώπισα ένα μήνυμα λάθους που δεν το είχα ξαναδεί μέχρι τώρα

    Ο φίλος Νίκος Κοασίδης από την Θεσσαλονίκη προσπαθούσε να στήσει την Express έκδοση του SQL Server 2005 σε windows xp ελληνικά με sp3. Βέβαια αυτό μπορεί να συμβεί και στις άλλες εκδόσεις.

    Με το που ξεκινούσε την εγκατάσταση εμφάνιζε το μήνυμα λάθους


    “SQL Server Setup unexpectedly failed. For more information, review the Setup summary log file..."


    Μετά από μια σύντομη αναζήτηση βρήκα το εξής που λύνει το πρόβλημα αυτό.

    Πάμε στην registry και κοιτάμε δύο hives τα

    HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

    και

    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

    Μέσα σε αυτές πρέπει να υπάρχει το entry “ΑppData”  με value “%USERPROFILE%\Application Data”.

    Έαν δεν υπάρχει το δημιουργούμε (String). Στον Νίκο έλειπε από το HKEY_CURRENT_USER\… .

    Τρέχουμε ξανά το setup και βγάζει ένα μήνυμα για το MSXML αλλα λέμε ΟΚ και όλα πάνε καλά
  15. antonch
    Η ώρα είναι 3:40 πμ (άγρια χαράματα δηλαδή) αλλά ύπνος δεν μου κολλάει. Ίσως φταίει ότι το μεσημέρι έφαγα μια κατσαρόλα λαγό στιφάδο (να είσαι καλά μάνα με την προσφορά σου αυτή) και κατανάλωσα και δύο μπύρες. Όπως είναι φυσικό μετά από τέτοιο τσιμπούσι ο ύπνος είναι απαραίτητος. Έτσι σαν καλό παιδί κοιμήθηκα και ξύπνησα στις 21:00 για να δω ποδόσφαιρο. Αφού τελείωσε λέω “δεν βάζω τον SQL Server 2008 στα Windows 2008 EE που έχω στήσει”. Ξεκίνησα την εγκατάσταση και όλα καλά. Βέβαια θα πρέπει να τονίσω ότι μου έβγαλε το warining για το Windows Firewall αλλά λέω ok θα το λύσω μετά γνωστό είναι…
    Στο ενδιάμεσω μίλαγα με φίλους στον messenger και όταν τελείωσε η εγκατάσταση λέω “αντε να βάλω και το SP1 μιας και χωρίς αυτό δεν θα παίζει τίποτα”.
    Όπως είναι φυσικό υπό την επήρεια του λαγού ξέχασα το windows firewall και η εγκατάσταση κολλούσε. Βρε καλέ μου, βρε γλυκό μου τίποτα. Αφού έκανα και την αντίστοιχη δέηση στην προστάτιδα των απανταχού κομπιουτεράδων την Αγία Θέκλα θυμήθηκα το Windows Firewall.
    Έτσι το έκλεισα προσωρινά και μετά έστησα το SP1 και όπως ήταν φυσικό είδα με χαρά το παρακάτω μήνυμα

    Καλημέρα σε όλους σας
  16. 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

  17. 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=””
  18. 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!
  19. 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.
    Εδώ λέω να σταματήσω το πρώτο μέρος. Ελπίζω το θέμα αυτό να σας αρέσει. Περιμένω τα σχόλια σας για αυτό.
  20. 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
  21. antonch
    Όλοι ξέρουμε το pagefile του λειτουργικού και την χρηστικότητα του.
    Όμως ποιό είναι το ιδανικό μέγεθος του σε ένα server που έχει εγκατεστημένο SQL Server;
    Πρέπει το Pagefile να είναι 1,5 φορές μεγαλύτερο από την φυσική μνήμη του server.
    Εάν έχω ή πρόκειτε να χρησιμοποιήσω full-text search τότε πρέπει να είναι τουλάχιστον τρεις φορές μεγαλύτερο από την φυσική μνήμη του server.
    Για ακόμα καλύτερα αποτελέσματα καλό θα είναι το pagefile να είναι σε ξεχωριστό φυσικό από αυτό του λειτουργικού.
  22. 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





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









  23. 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
  24. 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.
  25. 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
×
×
  • Create New...