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
    Εδώ και αρκετό καιρό έχω γίνει αποδέκτης αρκετών ερωτήσεων σχετικά με τα σεμινάρια της Microsoft για τον SQL Server και συγκεκριμένα για τις εκδόσεις του 2012 & 2014. Οι ερωτήσεις αφορούν θέματα περιεχομένου και πιστοποίησης.
     
    http://www.sqlschool.gr/blog/what-you-must-know-about-official-training-and-certification-in-sql-server-2012-and-2014-1012.aspx
  2. antonch
    Μόλις έλαβα ένα request από τον συνάδελφο Γιώργο Σίμο να φτιάξω κάτι για να παίρνει schedule backup στο sql server express, μιας και αυτή η έκδοση δεν έχει τον sql server agent.
    Λοιπόν όποιος θέλει να υλοποιήσει μια τέτοια λύση θα πρέπει να κάνει τα εξής βήματα:
    BHMA 1o
    Αποθηκεύω το παρακατώ script σε ένα αρχείο πχ c:\My SQL Scripts\DBBackupPerDay.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)\$(dbname)_'+@weekday+'.bak' + ''' with init'
    exec (@command)

    Εδώ έχω πάρει σαν υπόθεση εργασίας ότι κάθε μέρα θα παίρνουμε ημερήσιο full backup την βάση μας σε ξεχωριστό device, το οποίο στην επόμενη φορά που θα ξαναπάρω backup σε αυτό θα σβήνει το προηγούμενο. Δηλαδή έστω ότι είναι Δευτέρα και παίρνω backup την επόμενη Δευτέρα θα σβηστεί το backup αυτής. Εάν υπάρχει ανάγκη για κάτι διαφορετικό ενημερώστε με να σας δώσω την λύση.

    ΒΗΜΑ 2ο
    Ανοίγουμε τον Windows Task Scheduler και φτιάχνουμε ένα νέο Task (Create Task).

    Δίνουμε όνομα και βάζουμε να τρέχει το συγκεκριμένο με ένα windows account που έχει πρόσβαση στον sql server σαν administrator ( η εύκολη λύση ) ή σαν απλός χρήστης αλλά που το έχουμε δώσει να παίρνει backup databases. Επίσης θα πρέπει να έχει write permissions στο directory στο οποίο πρόκειται να τοποθετήσουμε τα backup μας.
    ΒΗΜΑ 3ο
    Πάμε στο Action Tab και φτίαχνουμε ένα νέο action στο οποίο βάζουμε τα εξής

    στο (1) βάζουμε το SQLCMD.exe μαζί με το full path του λογικά θα είναι το
    "C:\Program Files\Microsoft SQL Server\90\Tools\binn\SQLCMD.EXE"
    στο (2) βάζουμε τα εξής
    /S .\sqlexpress /E /i "c:\My SQL Scripts\DBBackupPerDay.sql" -v dbname=MyDB backuppath=”c:\backups"
    στις dbname, backuppath βάζουμε αντίστοιχα το όνομα της βάσης μας και το directory στο οποίο θέλουμε να αποθηκεύονται αυτά.
    ΒΗΜΑ 4ο
    Τέλος φτιάχνουμε έναν Trigger ( Trigger Tab ) για να πούμε κάθε πότε θέλουμε να γίνεται η εκτέλεση τoυ backup.
    Καλά backup!!!
  3. antonch
    Όπως θα έχετε δει τον τελευταίο καιρό και συγκεκριμένα το τελευταίο μήνα ασχολούμαι συστηματικά με την αναμόρφωση του SqlSchool.gr.
    Αυτό ήταν κάτι το οποίο έπρεπε να γίνει εδώ και πολύ καιρό αλλά μια το ένα μια το άλλο δεν μου άφηναν τον χρόνο που χρειαζόμουν για το κάνω αυτό, βέβαια ούτε και τώρα τον είχα αλλά πήρα την απόφαση να το κάνω καθώς ήταν κάτι που δεν έπρεπε να μείνει στην παλαιότερη κατάσταση του.
    Στην αρχή κοίταξα μήπως και χρησιμοποιήσω κάποια έτοιμη πλατφόρμα και να γλυτώσω χρόνο όμως δεν μου άρεσε κάτι ιδιαίτερα και έτσι κάθισα και έφτιαξα μια δικιά μου που πρωτίστως να ικανοποιεί τις ανάγκες μου που ήταν και είναι αρκετές αλλά και δευτερευόντως ήθελα να έχω τον πλήρη έλεγχο σε αυτή σε επίπεδο κώδικα.
    Αυτό τον εγχείρημα ξεκίνησε πριν 40 ημέρες και καθημερινά από τις 9 το βράδυ μέχρι τις 3 τα ξημερώματα έγραφα κώδικα σαν τρελός. Πραγματικά ήταν κάτι το οποίο ευχαριστήθηκα καθώς είχα καιρό να γράψω κάτι τόσο μεγάλο, καθώς πλέον δεν γράφω κώδικα μιας και η καθημερινές μου αρμοδιότητες στο χώρο της εργασία μου είναι άλλες. Παρόλα αυτά όμως διαπίστωσα ότι τελικά είναι σαν το ποδήλατο και αυτό που έκανα τα τελευταία από το 1984 ερασιτεχνικά και από το 1988 επαγγελματικά μέχρι πριν 3-4 χρόνια δεν με έχει εγκαταλείψει.
    Για την υλοποίηση του site χρησιμοποίησα όλες τις πρόσφατες τεχνολογίες όπως .NET 4.0, CSS3, ASP.NET 4.0, WCF, AJAX, JQuery και πολλά ακόμα, όχι EF δεν χρησιμοποίησα. Δυστυχώς δεν μπόρεσα να χρησιμοποιήσω SQL Server 2012 καθώς ο hosting provider ακόμα δεν τον έχει εγκαταστήσει αλλά όμως θα γίνει σύντομα και αυτό! J. Όμως από τις ανάγκες μου στην υλοποίηση δημιούργησα κάποια καλά κομμάτια κώδικα σε T-SQL που θα μοιραστώ μαζί σας σύντομα.
    Ήθελα αυτό που θα φτιαχτεί να έχει μεγάλη διάρκεια ζωής ώστε να ασχοληθώ περισσότερο με το περιεχόμενο. Προσπάθησα να το φτιάξω έτσι ώστε να παίζει σε όλους τους νέους browsers χωρίς προβλήματα και από ότι φαίνεται αυτό έχει επιτευχθεί.
    Επίσης ένα ακόμα σημείο που ήθελα να προσέξω αρκετά και το πρόσεξα ήταν η εύρεση του site από τις μηχανές αναζήτησης. Ομολογώ ότι στο παρελθόν δεν είχα ασχοληθεί αρκετά με το Search Engine Optimization (SEO) αλλά τελικά πότε δεν είναι αργά. Εδώ και μερικές ημέρες βλέπω ότι οι προσπάθειες μου έχουν αποδώσει καρπούς και πλέον στις αναζητήσεις είναι το sqlschool.gr πάντα στην πρώτη σελίδα. Φυσικά χρειάζεται ακόμα δουλειά σε αυτό αλλά οι βάσεις έχουν μπει.
    Από τα πράγματα που ήθελα να κάνω από την αρχή ήταν το sqlschool.gr να αποτελέσει ένα πόλο για τον SQL Server. Για αυτό το λόγο πριν από λίγο έκανα migrate το blog μου από το wordpress στην πλατφόρμα που έφτιαξα για το sqlschool.gr. Πλέον όλα μου τα posts είναι στο sqlschool.gr και όλα τα νέα θα είναι σε αυτό. Για λίγο καιρό ακόμα θα υπάρχει το blog στο wordpress και θα ενημερώνω αυτό με τα νέα μου post απλά με τα links. Για το λόγο αυτό σχόλια παρατηρήσεις και αξιολογήσεις δεν θα φαίνονται στο wordpress αλλά αυτές θα πρέπει να γίνονται από εσάς στο sqlschool.gr. Έτσι θα είναι όλα σε ένα σημείο το οποίο νομίζω ότι καλύτερο για όλους.
    Αν θέλετε να ενημερώσετε τα bookmarks σας με το νέο blog δεν έχετε παρά να βάλετε το www.sqlschool.gr/blogs/antonch
    Φυσικά παρατηρήσεις, επιθυμίες και ότι άλλο θέλετε είναι ευπρόσδεκτες. Γνωρίζω ότι η πλατφόρμα μου έχω φτιάξει χρειάζεται και άλλα πράγματα και έχουν δρομολογηθεί αλλά σιγά σιγά.
    Σας ευχαριστώ για μια ακόμα φορά για την εμπιστοσύνη που μου δείχνετε.
    Φιλικά
    Αντώνης
  5. antonch
    Έχοντας πλέον επιστρέψει από ένα εξαιρετικό MVP Summit αυτό του 2012 θα ήθελα να μοιραστώ μαζί σας την εμπειρία μου αυτή.
    Ξεκινώντας την Καθαρά Δευτέρα για το ταξίδι αυτό και έχοντας τις εμπειρίες μου από το προηγούμενο summit που είχα παρακολουθήσει το 2010 γνώριζα καλά τι με περιμένει. Αλλά αυτό το summit ήταν πραγματικό εξαιρετικό ιδιαίτερα για τους MVPs του SQL Server. Ήταν πολύ παραπάνω από τις προσδοκίες μου και όχι μόνο τις δικιές μου αλλά όλων SQL Server MVPs. Ενδεικτικά θα πω ότι ίσως για πρώτη φορά σηκωθήκαμε όλοι μας όρθιοι και για αρκετά λεπτά χειροκροτήσουμε την ομάδα που είχε έρθει από το product group για να μας ενημερώσει. Δυστυχώς όμως όλα αυτά είναι κάτω από αυστηρό NDA και δεν μπορώ να μοιραστώ ακόμα τίποτα μαζί σας. Μόλις όμως αρθεί αυτό θα έχω να σας πω πολλά.
    Το ημερήσιο πρόγραμμα ήταν αρκετά γεμάτο εγερτήριο στις 6:00 πρωινό μέχρι τις 8:00 και από εκεί και μετά συνέχεια sessions μέχρι τις 19:00 (το δικό μου PG είχε πολλά περισσότερα να μας πει από κάποια άλλα που τελείωναν στις 17:00).
    Οι πρώτες δύο μέρες ήταν ε κ π λ η τ ι κ έ ς. Τα παλικάρια έχουν ζωγραφίσει. Αυτό και μόνο αυτό θα πω γιατί αν θα πω έστω και μια κουβέντα ακόμα κινδυνεύω να παραβιάσω το NDA.
    SQL Server 2012 και ξερό ψωμί και άσε τον Κλαδάκη να λέει ότι θέλει
    Οι επόμενες δύο μέρες είχαν αρκετά sessions όπου το PG ζητούσε την γνώμη μας. Στην ουσία είχαν ερωτηματολόγια που συμπληρώναμε για αυτά που μας ρωτούσαν (είπαμε υπάρχει NDA δεν μπορώ να σας πω) και αφού επιτόπου έβγαζαν το αποτέλεσμα ξεκινούσε μια ζωηρή συζήτηση μεταξύ μας. Το αποτέλεσμα και το feedback που ήταν αμφίδρομο ήταν κάτι παραπάνω από εξαιρετικό.
    Πέρα όμως από αυτά μου δόθηκε η ευκαιρία να μιλήσω με αρκετούς από το PG. Ιδιαίτερη μνεία θα κάνω στην συζήτηση που είχα κατά την διάρκεια του PG Dinner με το Eric Hanson Principal Program Manager Lead, Query Processing and Storage at Microsoft SQL Server. Είχαμε μια ενδιαφέρουσα συζήτηση για τους columnstore indexes, DW και άλλα όμορφα πράγματα.
    Εκτός όμως από τους ανθρώπους του PG είχα αρκετά ενδιαφέρουσες συζητήσεις και με άλλους MVP μια εμπειρία που σε κάνει να νιώθεις ότι κάτι σκαμπάζεις και εσύ καθώς δεν είσαι πλέον στην Ελλάδα που κάποιοι τα ξέρουν όλα και εσύ είσαι ένα απλό σκουπίδι ή ακόμα χειρότερα να λες κάτι και να προσπαθούν να σε υποβαθμίσουν γιατί λέει αυτά δεν ισχύουν στην Ελλάδα. Δυστυχώς ακόμα είμαστε στην εποχή των δεινοσαύρων και πρέπει να το αλλάξουμε γρήγορα αυτό. Εμένα πάντως αυτό μου έκανε αρκετά καλό καθώς είχα τη δυνατότητα να εμπιστευτώ ξανά τις δυνατότητες μου. Ναι το λέω με πίκρα αυτό…
    Με το φαγητό είχα ένα θέμα σε αυτό το summit καθώς είχε τα περισσότερα γεύματα με σολομό. Αν και μου αρέσουν τα ψάρια δεν είμαι ιδιαίτερα φίλος με το ψάρι αυτό. Αλλά και ο τρόπος που το μαγειρεύουν είναι κάπως πέρα από τα γούστα μου. Αλλά στην Αμερική δεν πρόκειται να πεινάσεις. Με το Hyper Vaggelis είχαμε μερικές αρκετές συνεδρίες με rib eye steaks, επισκέψεις στο Cheesecake Factory και άλλους όμοιους οργανισμούς λύτρωσης της πείνας.
    Στο πάρτι που έγινε την προτελευταία μέρα το κέφι ήταν κάτι άλλο. To karaoke που ακολούθησε όλα τα λεφτά. Ο χώρος που διοργανώθηκε ήταν το CenturyLink Field το γήπεδο στο οποίο παίζουν οι Seattle Seahawks. Ένα γήπεδο εξαιρετικής ομορφίας και λειτουργικότητας. Εμείς μόνο το ΟΑΚΑ και το Καραϊσκάκη
    To φαγητό και η μπύρα έρεαν εν αφθονία. Εκεί με τον Hyper Vaggelis και το Cloud boy περάσαμε απίστευτα. Ο Span δυστυχώς δεν μπορούσε να έρθει καθώς έπρεπε με το χάραμα να ταξιδέψει για NY.
    Έχοντας πλέον επιστρέψει πίσω κρατώ όλα αυτά για να αντλήσω δύναμη για την συνέχεια και ελπίζω να είμαι καλά και να μπορώ του χρόνου να ξαναπάω.
    /*antonch*/
  6. antonch
    Η δεύτερη συνέχεια για τα Reporting Services. Σε αυτή θα μιλήσουμε για Security, Execution/Processing, Subscriptions και Administration.
    Δεν υπάρχει κόστος για την παρακολούθηση (live από τον υπολογιστή σας) της παρουσίασης αυτής, αλλά είναι απαραίτητο να κάνετε εγγραφή εδώ. Οι θέσεις είναι περιορισμένες.
  7. antonch
    Πριν μερικές μέρες ανακοινώθηκαν από την Microsoft οι πρώτες αλλαγές που αφορούν τις εκδόσεις και τις άδειες χρήσης του προϊόντος.
    Οφείλω να ομολογήσω ότι ποτέ δεν ήμουν από αυτούς που ασχολούνταν με το θέμα των αδειών, θα μπορούσα να πω ότι ήμουν και είμαι αλλεργικός με το θέμα αυτό. Όμως είδα ότι κάτι πάει να αλλάξει στο θέμα αυτό και μάλιστα προς το καλύτερο.
    Επίσης επειδή είχα την τύχη να παρακολουθήσω ένα live meeting σχετικά με αυτά πήρα την απόφαση να προσθέσω και εγώ το λιθαράκι μου με το post αυτό. Είναι αλήθεια πάντως ότι μου πήρε μερικές μέρες για να καταλάβω πως έχει το θέμα με τις άδειες και είχα αρκετές ερωτήσεις.
    Αυτό πάντως που δεν μου ήταν δύσκολο να καταλάβω με την πρώτη ήταν το ποιες θα είναι οι εκδόσεις του SQL Server 2012.
    [read more]
  8. antonch
    Σαν DBA και DB Developer έχω πολλούς servers/instances του SQL Server τα οποία διαχειρίζομαι. Φαντάζομαι ότι και εσείς θα έχετε αρκετά είναι production είτε development instances.
    Αρκετές φορές πάνω στην βιασύνη ίσως έχετε τρέξει κάποιο script στο production ενώ δεν θα έπρεπε. Συνήθως αυτό γίνεται διότι έχετε ανοίξει ένα query window το οποίο είναι συνδεδεμένο στο instance που δεν θα έπρεπε να είναι.
    Αυτό είναι ένα θέμα. Θέλω να ξέρω κάθε φορά σε ποιο instance είμαι συνδεδεμένος. Εύκολα αυτό είναι εντοπισμό αρκεί να κοιτάξει κανείς στην status bar του query window.
    Όμως εδώ και χρόνια έχω την δυνατότητα εκτός από αυτό να έχω και χρωματική διάκριση ανά instances πώς; Μα με ένα απλό τρόπο.
    Ανοίγω το Register Servers window και κάνω register τους servers/instances που επιθυμώ αλλά πριν πατήσω OK στο window πάω στο tab Connection Properties και διαλέγω το χρώμα που επιθυμώ για το συγκεκριμένο server/instance όπως στην παρακάτω εικόνα και τότε πατώ ΟΚ

    Αυτό θα έχει σαν συνέπεια όταν ανοίγω ένα query window που είναι συνδεδεμένο στο συγκεκριμένο server/instance η status bar θα έχει το χρώμα που έχω επιλέξει και έτσι εύκολα θα μπορώ να καταλάβω που έχω συνδεθεί.

    Έτσι πλέον δεν θα εκτελώ λάθος script σε λάθος server/instance
    /*antonch*/
    /*life runs on SQL Server 2012*/
  9. antonch
    Όπως φαντάζομαι είναι ήδη γνωστό ο SQL Server ‘Denali’ απέκτησε πλέον επίσημο όνομα και αυτό είναι το SQL Server 2012. Θα είναι διαθέσιμος σαν τελικό προϊόν στο πρώτο εξάμηνο του 2012.
    Όπως είναι φυσικό αυτό έχει άμεσες επιπτώσεις στα σεμινάρια αλλά και στις πιστοποιήσεις και στα exams αυτών. Ας δούμε τι σεμινάρια έχουν προγραμματιστεί να βγουν σαν σεμινάρια και εξετάσεις.
    Title Course Exam Administering a Microsoft SQL Server 2012 Database 10775 70-462 Building Data Warehouses with Microsoft SQL Server 2012 10777 70-463 Developing a Microsoft SQL Server 2012 Database 10776 70-464 Designing Database Solutions for SQL Server 2012 10778 70-465 Implementing Data Models and Reports with Microsoft SQL Server 2012 TBD 70-466 Designing Business Intelligence Solutions with Microsoft SQL Server 2012 Platform TBD 70-467 Το ποιο σημαντικό όμως είναι ότι πλέον δεν θα χρειάζεται να παρακολουθήσεις περισσότερα από ένα σεμινάριο ώστε να δώσεις εξετάσεις ακολουθεί πλέον την λογική 1:1, αλλά τα exams πλέον θα είναι ποιο δύσκολα και το σημαντικότερο ίσως όλων είναι ότι για να περάσεις θέλει πραγματική εργασία στο προϊόν
    Πηγή : Microsoft Learning
  10. antonch
    Με μια ανακοίνωση που ακολουθεί η Microsoft παρουσίασε τον Microsoft SQL Server ODBC Driver for Linux. Διαλειτουργικότητα σε όλο της το μεγαλείο.


    Greetings Developer community:
    We heard yesterday and today at the PASS conference about the exciting new areas that we are investing in bringing the power of SQL Server to our customers. Many of our developers who rely on native connectivity to SQL Server primarily use ODBC for their connectivity needs. We have been supporting ODBC as a part of the SQL Native Access Client (SNAC) libraries. In our continued commitment to interoperability, today we also announced that we will be releasing the Microsoft SQL Server ODBC Driver for Linux. We will be releasing first community technology preview (CTP) around mid-November and will be available along with SQL Server 2012 when it is released. Please look for announcement on our SQL Connectivity home page and SQL Server blog page.
    We will be showcasing Microsoft SQL Server ODBC Driver for Linux along with our Java and PHP solutions for SQL Server and Azure at PASS conference session “[AD-211-M] Developing Multi-Platform Applications for Microsoft SQL Server and Azure” on Thursday October 13th at 5:00PM at Washington State Convention Center Room #4C4. Also, if you have any questions or feedback on our multi-platform strategy as well as the entire gamut of support we provide to the application developers, I would encourage you to attend the PASS Panel Discussion with SQL Connectivity Leadership “[AD-101-M] SQL Connectivity Leadership Unplugged” on Friday, October 14, 2011, 2:30 PM - 3:45 PM at Washington State Convention Centre Room# 612 where I will be hosting a panel along with the rest of the leadership team that drives the strategy for our application platform.
    Thanks,
    Raghu Ram
    Principal Group Program Manager
    SQL Server
  11. antonch
    Είναι γνωστή η τρέλλα μου να έχω το μέγιστο δυνατό user experience στα virtual machines μου. Περίμενα με αγωνία το RemoteFX το οποίο είναι άψογο. Αν παρόλα αυτά δεν έχετε το ReportFX να ένας απλός τρόπος να έχετε Aero σε αυτές όταν όμως συνδέεστε με Remote Desktop
    Βάλετε το Desktop Experience feature από τον Server Manager. Ενεργοποιήστε το themes service σε autostart, και ξεκινήστε το. Ενεργοποιήστε το “Allow desktop composition for remote desktop sessions” policy από το Edit Group Policy. Αυτό είναι στο path “ComputerConfiguration\AdministrativeTemplates\WindowsComponents\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment” Ορίστε το “Limit Maximum Color Depth” στο να παίρνει ότι έχει ο client. Αυτό ήταν έχετε Aero Theme
  12. antonch
    Όπως γνωρίζουμε ο SQL Server διαβάζει τις σελίδες από το δίσκο και τις βάζει στην buffer cache. To πόσο χρόνο (σε δευτερόλεπτα) αυτές μπορούν να μείνουν κατά μέσο όρο στην buffer cache χωρίς να ζητηθούν/χρησιμοποιηθούν μπορούμε να το δούμε από τον SQL Server\Buffer Manager\Page Life Expectancy performance counter. O μετρητής αυτός  σύμφωνα με τα recommendations πρέπει να είναι πάνω από 300 sec για να έχουμε ένα καλό PLE. Φυσικά σε σύστήματα που έχουν προβλήματα με την μνήμη αυτός θα είναι μικρότερος καθώς οι σελίδες θα κατεβαίνουν γρηγορότερα στον δίσκο και αυτό δεν μας αρέσει. Αντίθετα σε συστήματα με άπλετη μνήμη θα έχει μεγαλύτερη τιμή και αυτό μας αρέσει.
  13. antonch
    Καιρό ήθελα να γράψω για αυτή και όλο το ξεχνούσα. Πρόσφατα σε μια εκπαίδευση αναφέρεθηκε το όνομα της και αφού το έβαλα σε χίλια δυο σημεία να το κάνω post και να μην το ξεχάσω τελικά τα κατάφερα και δεν την ξέχασα.
    Αρκετές φορές θέλουμε να μεταφέρουμε τα logins που έχουμε σε ένα SQL Server σε κάποιον άλλον. Ιδιαίτερα χρήσιμη όταν έχουμε database mirroring, replication κλπ.
    Υπάρχει ένα άρθρο το οποίο σου δίνει τον κώδικα αυτής και φυσικά αφού την δημιουργήσεις μπορείς να την εκτελέσεις και να πάρεις στο πιάτο τα logins σε μορφή script ώστε να μπορέσεις να τα δημιουργήσεις με κάποιες παραδοχές σε κάποιον άλλον SQL Server.
    Για καθαρά λόγους ευκολίας σε εσάς μεταφέρω το κώδικα εδώ
    USE master
    GO
    IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL
    DROP PROCEDURE sp_hexadecimal
    GO
    CREATE PROCEDURE sp_hexadecimal
    @binvalue varbinary(256),
    @hexvalue varchar (514) OUTPUT
    AS
    DECLARE @charvalue varchar (514)
    DECLARE @i int
    DECLARE @length int
    DECLARE @hexstring char(16)
    SELECT @charvalue = '0x'
    SELECT @i = 1
    SELECT @length = DATALENGTH (@binvalue)
    SELECT @hexstring = '0123456789ABCDEF'
    WHILE (@i BEGIN
    DECLARE @tempint int
    DECLARE @firstint int
    DECLARE @secondint int
    SELECT @tempint = CONVERT(int, SUBSTRING(@binvalue,@i,1))
    SELECT @firstint = FLOOR(@tempint/16)
    SELECT @secondint = @tempint - (@firstint*16)
    SELECT @charvalue = @charvalue +
    SUBSTRING(@hexstring, @firstint+1, 1) +
    SUBSTRING(@hexstring, @secondint+1, 1)
    SELECT @i = @i + 1
    END

    SELECT @hexvalue = @charvalue
    GO

    IF OBJECT_ID ('sp_help_revlogin') IS NOT NULL
    DROP PROCEDURE sp_help_revlogin
    GO
    CREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL AS
    DECLARE @name sysname
    DECLARE @type varchar (1)
    DECLARE @hasaccess int
    DECLARE @denylogin int
    DECLARE @is_disabled int
    DECLARE @PWD_varbinary varbinary (256)
    DECLARE @PWD_string varchar (514)
    DECLARE @SID_varbinary varbinary (85)
    DECLARE @SID_string varchar (514)
    DECLARE @tmpstr varchar (1024)
    DECLARE @is_policy_checked varchar (3)
    DECLARE @is_expiration_checked varchar (3)

    DECLARE @defaultdb sysname

    IF (@login_name IS NULL)
    DECLARE login_curs CURSOR FOR

    SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
    sys.server_principals p LEFT JOIN sys.syslogins l
    ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name 'sa'
    ELSE
    DECLARE login_curs CURSOR FOR


    SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
    sys.server_principals p LEFT JOIN sys.syslogins l
    ON ( l.name = p.name ) WHERE p.type IN ( 'S', 'G', 'U' ) AND p.name = @login_name
    OPEN login_curs

    FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin
    IF (@@fetch_status = -1)
    BEGIN
    PRINT 'No login(s) found.'
    CLOSE login_curs
    DEALLOCATE login_curs
    RETURN -1
    END
    SET @tmpstr = '/* sp_help_revlogin script '
    PRINT @tmpstr
    SET @tmpstr = '** Generated ' + CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'
    PRINT @tmpstr
    PRINT ''
    WHILE (@@fetch_status -1)
    BEGIN
    IF (@@fetch_status -2)
    BEGIN
    PRINT ''
    SET @tmpstr = '-- Login: ' + @name
    PRINT @tmpstr
    IF (@type IN ( 'G', 'U'))
    BEGIN -- NT authenticated account/group

    SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' FROM WINDOWS WITH DEFAULT_DATABASE = [' + @defaultdb + ]'
    END
    ELSE BEGIN -- SQL Server authentication
    -- obtain password and sid
    SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, 'PasswordHash' ) AS varbinary (256) )
    EXEC sp_hexadecimal @PWD_varbinary, @PWD_string OUT
    EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT

    -- obtain password policy state
    SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name
    SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1 THEN 'ON' WHEN 0 THEN 'OFF' ELSE NULL END FROM sys.sql_logins WHERE name = @name

    SET @tmpstr = 'CREATE LOGIN ' + QUOTENAME( @name ) + ' WITH PASSWORD = ' + @PWD_string + ' HASHED, SID = ' + @SID_string + ', DEFAULT_DATABASE = [' + @defaultdb + ]'

    IF ( @is_policy_checked IS NOT NULL )
    BEGIN
    SET @tmpstr = @tmpstr + ', CHECK_POLICY = ' + @is_policy_checked
    END
    IF ( @is_expiration_checked IS NOT NULL )
    BEGIN
    SET @tmpstr = @tmpstr + ', CHECK_EXPIRATION = ' + @is_expiration_checked
    END
    END
    IF (@denylogin = 1)
    BEGIN -- login is denied access
    SET @tmpstr = @tmpstr + '; DENY CONNECT SQL TO ' + QUOTENAME( @name )
    END
    ELSE IF (@hasaccess = 0)
    BEGIN -- login exists but does not have access
    SET @tmpstr = @tmpstr + '; REVOKE CONNECT SQL TO ' + QUOTENAME( @name )
    END
    IF (@is_disabled = 1)
    BEGIN -- login is disabled
    SET @tmpstr = @tmpstr + '; ALTER LOGIN ' + QUOTENAME( @name ) + ' DISABLE'
    END
    PRINT @tmpstr
    END

    FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @type, @is_disabled, @defaultdb, @hasaccess, @denylogin
    END
    CLOSE login_curs
    DEALLOCATE login_curs
    RETURN 0
    GO

    Το αποτέλεσμα της εκτέλεσης του παραπάνω κώδικα θα σας δημιουργήσει δύο stored procedures στην master τις sp_hexadecimal και sp_help_revlogin.


    Εκτελώντας την sp_help_revlogin θα έχετε ένα script με όλα τα logins του server που την τρέξατε.


    Λεπτομέρειες μπορείτε να διαβάσετε στο άρθρο.


    antonch
  14. antonch
    Όπως είναι γνωρίζουμε στον SQL Server υπάρχει μια διαδικασία η οποία σκοπό έχει να μεταφέρει από την Buffer Cache τις αλλαγμένες σελίδες στο δίσκο, γίνεται σε όλες τις βάσεις εκτός από την tempdb (αν και αυτό δεν είναι και τόσο αλήθεια αλλά δεν θα το αναλύσουμε εδώ). Σκοπός του είναι να είναι όσο το δυνατό πιο ενημερωμένα τα data files με τις αλλαγές είναι γραμμένες στο log.
    Αυτό μπορεί να γίνει είτε εκτελώντας την εντολή CHECKPOINT είτε το κάνει o SQL Server αυτόματα. Το αυτόματο μπορεί να ορίστει αν το επιθυμούμε και αυτό γίνεται ορίζοντας το Recovery Interval στο SQL Server. H default τιμή είναι μηδέν που σημαίνει ότι ο SQL Server αποφασίζει για το πότε θα την κάνει αυτή την διαδικασία.
    Πρόσφατα άκουσα ότι αυτή αν δεν ορίσεις τιμή γίνεται κάθε 2 sec. Αυτό με έβαλε σε σκέψεις και αποφάσισα να το ψάξω ενδελεχώς.
    Σύμφωνα με τα BOL http://msdn.microsoft.com/en-us/library/ms189573.aspx στην παράγραφο για τα Automatic Checkpoints αναφέρει

    The SQL Server Database Engine generates automatic checkpoints. The interval between automatic checkpoints is based on the amount of log space used and the time elapsed since the last checkpoint. The time interval between automatic checkpoints can be highly variable and long, if few modifications are made in the database. Automatic checkpoints can also occur frequently if lots of data is modified.

    Αυτό όμως δεν μου έφτασε και άρχισα να κοιτάζω περισσότερα. Έφτασα σε ένα σημείο να ρωτήσω και ανθρώπους που τον έχουν φτιάξει (δεν αναφέρω τα ονόματα τους για μην θεωρηθεί ότι πουλάω μούρη ότι μιλάω μαζί τους). Τελικά οι ερωτήσεις μου και οι αναζητήσεις μου είχαν αποτέλεσμα και ανακάλυψα ότι μπορείς να χρησιμοποιήσεις τα trace flags 3502 και 3605 τα οποία γράφουν μέσα στο error log το κάθε πότε γίνεται checkpoint.
    Επίσης είναι αρκετά εύκολο να το δεις κάνοντας monitor τον Buffer Manager\Checkpoint Pages per Sec perfmon counter.
    Με ποιά όμως λογική γίνεται trigger η αυτόματη διαδικασία? Η απάντηση δια στόματος του Paul Randal είναι η παρακάτω

    A checkpoint is triggered automatically under a variety of conditions. The most common condition is that enough transaction log has been generated that SQL Server estimates that if the server was to crash, it would take about one minute for crash recovery to complete. This is calculated based on the number of log records that have been generated since the last checkpoint and is known as the recovery interval. The next most common condition that triggers a checkpoint is when the log becomes 70% full.

    @antonch
  15. antonch
    Εισαγωγή
    Αρκετό καιρό έχω να γράψω ένα μεγάλο άρθρο, έτσι σήμερα μου ήρθε η όρεξη να το κάνω. Έσπαγα το κεφάλι μου να βρω ένα ωραίο θέμα ώστε να σας κεντρίσει το ενδιαφέρον. Αμέσως στο μυαλό μου ήρθε το θέμα που ο τίτλος περιγράφει.
    Γιατί όμως επέλεξα αυτό; Αφορμή για αυτό είναι κάποια γεγονότα και καταστάσεις που αντιμετώπισα τον τελευταίο διάστημα. Επίσης ένας ακόμα σημαντικός λόγος είναι ότι πλέον η εποχή του virtualization είναι πραγματικότητα και μάλιστα χωρίς να το καταλάβεις βρίσκεσαι με ένα μεγάλο αριθμό από τέτοιες μηχανές.
    Σαν σοβαροί επαγγελματίες που θέλουμε να εξοικονομήσουμε χρόνο συνήθως έχουμε προετοιμάσει κάποια base images των λειτουργικών που θέλουμε με εγκατεστημένα τα προϊόντα που εκ προοιμίου θέλουμε, και με την γνωστή διαδικασία (SysPrep) η δημιουργία μιας νέας virtual machine να είναι υπόθεση μερικών λεπτών.
    Σε αυτή την περίπτωση όμως αν είχαμε εγκαταστήσει SQL Server είχαμε να αντιμετωπίσουμε μερικά προβλήματα. Δεν ήταν άλυτα, δεν ήταν φοβέρα. Απλά σου χάλαγαν λίγο την διάθεση και την ευκολία, αλλά τελικά τι δουλεία σου την έκανες (με λίγο γκρίνια βέβαια).
    Όλα αυτά όμως ανήκουν στο παρελθόν. Στον SQL Server 2008 R2 μας δίνεται η δυνατότητα να εγκαταστήσουμε τον SQL Server στο base image μας χωρίς όμως να τον κάνουμε να λειτουργεί. Στην ουσία στήνονται όλα τα binaries, δεν γίνονται όμως configure θέματα που αφορούν computer, network, account-specific information.
    Αυτό μου δίνει τη δυνατότητα να μπορώ ευκολότερα να φτιάξω μια πλειάδα από μηχανές που περιέχουν ετοιμοπόλεμο SQL Server και μάλιστα με το ίδιο configuration!!!
    Τι μπορώ να έχω
    · Με την συγκεκριμένη διαδικασία μπορώ να έχω έτοιμα μόνο τα Database Engine Service & Reporting Services. Τα SQL Server Browser, SQL Server Writer & SQL Server Native Client γίνονται εγκατάσταση όταν τελικά ενεργοποιώ τον SQL Server
    · Μπορώ μετά την προετοιμασία να προσθέσω ή να αφαιρέσω features του SQL Server.
    · Μπορώ να έχω προετοιμάσει πολλά Instances του SQL Server.
    Τι δεν μπορώ
    · Δεν έχω την δυνατότητα να έχω "ετοιμα" SQL Server Analysis Services.
    · Δεν υποστηρίζεται SQL Server Cluster Installation.
    · Δεν υποστηρίζεται η εγκατάσταση των SQL Server Tools (SSMS κλπ)
    · Δεν υποστηρίζεται ΙΑ-64 εγκατάσταση.
    · Δεν μπορώ να κάνω προετοιμασία ένος SQL Server 2008 R2 Instance σε μηχανή που έχει ήδη προηγούμενες εκδόσεις του SQL Server.
    Η διαδικασία προετοιμασίας (Preparation)
    Ξεκινάμε το setup το SQL Server και επιλέγουμε Advanced > Image preparation of a stand-alone instance of SQL Server

    Ξεκινάει η διαδικασία εγκατάστασης όπως την έχουμε συνηθίσει

    Με την ολοκλήρωση της φάσης Setup Support Rules πατάμε OK

    Ακολουθεί η φάση Setup Support Files στην οποία πατάμε Install.

    Η διαδικασία ξεκινάει

    και με την ολοκλήρωση της

    ακολουθούν ο διάλογος με την License Terms όπου φυσικά και επιλέγουμε τα παρακάτω

    Ο επόμενος διάλογος μας δίνει τη δυνατότητα να επιλέξουμε τα features που θέλουμε να έχουμε διαθέσιμα όταν θα ενεργοποιήσουμε το instance μας. Φυσικά όπως είπα και παραπάνω διαθέσιμα δεν είναι όλα

    Αφού επιλέξουμε ο επόμενος διάλογος μας δίνει την δυνατότητα να ορίσουμε κάποιες βασικές πληροφορίες για το instance μας.

    Η βασικότερη είναι το Instance ID. Αυτό χρησιμοποιείται για να ξεχωρίζει τα installation directories και τα registry key του instance σας. Αυτό βέβαια δεν είναι δεσμευτικό όταν θα γίνει η ενεργοποίηση. Μπορείς πχ να ορίσεις σαν Instance ID κάτι και κατά την επόμενη φάση της ενεργοποίησης να δώσεις κάτι άλλο. Απλά το Instance ID θα παραμείνει το ίδιο ώστε να μην υπάρχει αλλαγή όσα παραπάνω ανάφερω.
    Ακολουθούν μερικοί διάλογοι που μας ενημερώνουν για την εξέλιξη της διαδικασίας μας στους οποίους απαντάμε τα βασικά


    Ώσπου φτάνουμε στο σημείο που είμαστε έτοιμοι για την δημιουργία του image. Στο οποίο βλέπουμε τι έχουμε επιλέξει και πατάμε Prepare

    Η διαδικασία ξεκινάει

    και με την ολοκλήρωση της φτάνουμε στον παρακάτω διάλογο

    πριν φύγετε από εδώ καλό είναι να κάνετε κλικ στο link που σας λέει, όπως επίσης και να πάτε στο directory που δείχνει το link αυτό μιας και σε αυτό θα βρείτε το ConfigurationFile.ini το οποίο και μπορείτε να χρησιμοποιήσετε σαν βάση για εγκατάσταση του SQL Server από configuration file
    Με την ολοκλήρωση της διαδικασίας αυτής έχουμε έτοιμο το instance του SQL Server.
    Μπορούμε να προχωρήσουμε στη διαδικασία του Windows SysPrep και να φτίαξουμε μια νέα μηχανή χρησιμοποιώντας το image αυτό το οποίο περιέχει το λειτουργικό μαζί με τον SQL Server.
    Η διαδικασία ενεργοποίησης (Completion)
    Όταν ανοίξουμε την νέα μηχανή και τελειώσουμε με τα του λειτουργικού πάμε στο Start menu και διαλέγουμε μια από τις παρακάτω επιλογές

    και πάμε

    ακολουθούμε τα βήματα


    ώσπου φτάνουμε στον παρακάτω διάλογο στον οποίο επιλέγουμε το προετοιμασμένο μας instance


    Στον παρακάτω διάλογο μπορείς να επιλέξει αν θα το ενεργοποιήσεις σαν default ή named instance

    Ακολουθούν μερικοί διάλογοι με τους οποίους ορίζεις τα παρακάτω





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


    Ακολουθούμε τις οδηγίες και τελικά φτάνουμε στο επιθυμητό μας αποτέλεσμα
  16. antonch
    Καθώς έχουν ήδη γίνει δέκα SQL Saturday Nights θα ήθελα την γνώμη σας για την ποιότητα αυτών. Θα παρακαλούσα αν θέλετε να μου πείτε όσοι τα έχετε παρακολουθήσει είτε ζωντάνα είτε μαγνητοσκοπημένα την γνώμη σας για αυτά.
    Αυτό μπορείτε να το κάνετε μπαίνοντας στο www.sqlschool.gr και στη δημοσκόπηση που υπάρχει εκεί να επιλέξετε την άποψη σας.
    Σας ευχαριστώ εκ των προτέρων
    antonch
  17. antonch
    Σήμερα θα σας πω μια ιστορία που εξελίσσετε στη μαγική πόλη Σαλαμάνδρα. Στην μικρή αυτή πόλη υπάρχει μια επιχείρηση που έχει δύο servers εκ των οποίων ο ένας είναι και SQL Server. Στον SQL server τρέχουν διάφορα προγράμματα της εταιρείας Πέντε Κιλά Κώδικα (ανταγωνιστής της γνωστής ΤΚΚ) και ο χρήστης μπαίνει συχνά στον server μέσω remote desktop να κάνει διάφορες εργασίες. Επίσης ο τεχνικός του επιχειρηματία, ο Μπάμπης, έχει ανοίξει πρόσβαση μέσω remote desktop και στην ΠΚΚ στην default πόρτα, χωρίς κανέναν έλεγχο και με Administrator password «1» και έχει μόνιμα εγκατεστημένο TeamViewer.
    Όλα είναι καλά, τα πουλάκια κελαηδάνε στα κλαδιά και η ζωή στη μικρή Σαλαμάνδρα κυλάνε ήρεμα. Ώσπου μια μέρα ο χρήστης που μπαινοβγαίνει στον server προσπαθεί να κάνει login και βγάζει μήνυμα για λάθος κωδικό. Πόσο λάθος μπορεί να γράψει κανείς τον αριθμό 1; Παίρνει αμέσως τηλέφωνο την ΠΚΚ να απαιτήσει να μάθει αν έχουν κάνει κάτι μια και νωρίτερα την ίδια μέρα έκαναν κάποιες ρυθμίσει στον SQL. Κάπου στο τέταρτο τηλεφώνημα πείθεται τελικά ότι όχι, το να τρέχεις query στο Management Studio δεν αλλάζει με κάποιο μαγικό τρόπο τους κωδικούς του Administrator και καλό θα ήταν να τηλεφωνήσει άμεσα στον Μπάμπη.
    Δυστυχώς, ο Μπάμπης δεν είναι διαθέσιμος και έτσι έρχεται στη θέση του ο Μήτσος που βάζει ένα Hiren bootcd και κάνει reset το password του Administrator… σε… «1». Μετά από αυτό τηλεφωνεί στην ΠΚΚ και ρωτάει αν μπορούν να μπουν στον server τώρα και να δουν και τον SQL γιατί δεν φαίνεται να παίζει. Εξηγεί ότι ο ίδιος δεν είναι τεχνικός, είναι «sofwarάς» και δεν ξέρει να κάνει κάτι παραπάνω.
    Μπαίνει λοιπόν ένας από την ΠΚΚ στον server και βλέπει τα εξής:
    1. Έχουν σβηστεί όλα τα accounts (άλλο ένα είχε δηλαδή) πλην του Administrator
    2. Τα regional settings είναι στα Ρώσικα
    3. Το Desktop του server δεν έχει κανένα από τα shortcuts που είχε πριν, αλλά έχει κάποια άλλα νέα που παραπέμπουν σε προγράμματα που δεν υπήρχαν μέχρι εκείνο το πρωί. Π.χ. το Denwer, το Samarium κλπ
    4. Ο SQL και ο IIS δεν τρέχουν.
    Αφού ξεπερνάει το αρχικό σοκ του να προσπαθεί να καταλάβει τι ακριβώς βλέπει μπροστά του, προσπαθεί να επαναφέρει λίγο λίγο την κατάσταση. Κάνει reinstall τον IIS, επαναφέρει τα accounts και σηκώνει τον SQL Server και αρχίζει να ξηλώνει ότι πιάνει το μάτι του στα γρήγορα. Τουλάχιστον να μην είναι εντελώς ανοιχτός ο server. Κατεβάζει από το startup προγράμματα που ξεκινούσαν από hidden folders με διάφορα switches και κάνει uninstall ότι δεν έπρεπε να είναι εκεί. Αφού τελειώνει και τουλάχιστον ο server λειτουργεί ζητάει από τον χρήστη, να κάνει shutdown και να περιμένει τον Μπάμπη το πρωί να λύσει το πρόβλημα. Όλα αυτά με την λογική ότι ο τεχνικός της ΠΚΚ έκανε ένα γρήγορο και σχετικό επιφανειακό «καθάρισμα» και να μην είναι ο server προσβάσιμος στον φίλτατο Ρώσο το βράδυ.
    Ανατέλλει ο ήλιος, τα πουλάκια κελαηδάνε πάλι, οι μελισσούλες πάνε στα λουλουδάκια, το πρωί έρχεται και μαζί με το πρωί και ο Μπάμπης που κάνει τις εξής κινήσεις στον server:
    1. Κλείνει το remote desktop
    2. Αλλάζει το password του Administrator
    3. Αδειάζει τον κάδο ανακύκλωσης που ο τεχνικός της ΠΚΚ είχε βάλει όλα τα προγράμματα και αρχεία που έσβησε.
    4. Ενημερώνει την ΠΚΚ ότι πλέον θα μπαίνει μόνο μέσω TeamViewer
    Μόνο αυτά. Δεν έτρεξε antivirus, δεν έψαξε για Trojans, δεν κοίταξε αν υπάρχει κάτι άλλο στον server που μπορεί να ξέφυγε από το γρήγορο «καθάρισμα» που έγινε τη προηγούμενη. Δεν άλλαξε καν το password του TeamViewer που σίγουρα είχε δει ο Ρώσος μια και έτρεχε όταν μπήκε στον server και φαίνεται από το interface.
    Και έπειτα ο ήλιος έδυσε στη μικρή Σαλαμάνδρα και ξεκίνησε ένα χαρούμενο απόγευμα στη μαμά Ρωσία.
  18. antonch
    Μόλις έχω τελειώσει το 9ο SQL Saturday Night και μάλιστα σε χρονικό διάστημα συντομότερο από τον αρχικά προγραμματισμένο. Αίτια για αυτή την συντόμευση ήταν κάποια παλικάρια τα οποία είχαν σαν σκοπό όχι να παρακολουθήσουν την παρουσίαση μου αλλά να κάνουν πλάκα προτείνοντας θέματα σεξουαλικού περιεχομένου και άλλα όμορφα τέτοια πράγματα. Αυτό είχε σαν αποτέλεσμα πρώτον να με απασχολούν και να μου αποσπούν την προσοχή μου από την παρουσίαση μου και δεύτερο η μαγνητοσκόπηση αυτή να πάει στο καλάθι των αχρήστων. Καταρχήν θα πρέπει να ζητήσω συγνώμη σε όσους ήταν μέσα στην παρουσίαση αυτή και φάνηκε ο εκνευρισμός μου, ήταν κάτι το οποίο θεωρούσα ότι δεν πρόκειται να συμβεί ποτέ. Δυστυχώς την παρουσίαση αυτή δεν μπορώ να την ανεβάσω όπως κατεγράφη ή θα πρέπει να υποστεί μεγάλη επεξεργασία ή θα την γράψω μόνος μου από την αρχή, θα αποφασίσω για αυτό το πρωί που θα την δω. Αυτό που όμως είναι σίγουρο ότι θα γίνει είναι ότι πλέον για την αποφυγή της επανάληψης τέτοιων φαινομένων θα αλλάξω τον τρόπο με τον οποίο γίνεται η διάθεση του link της κάθε παρουσίασης και δεν θα είναι τόσο ελεύθερος όσο είναι τώρα. Λυπάμαι πολύ για αυτό αλλά πραγματικά τα SQL Saturday Nights είναι ένα δημιούργημα μου που δε θέλω να καταστραφεί.
  19. antonch
    Οι περισσότεροι σχεδόν χρησιμοποιούν τα SSRS στην καθημερινότητα τους καλύπτοντας τις ανάγκες τους σε reporting. Πρόσφατα είχα μια ενδιαφέρουσα ερώτηση από έναν εκλεκτό φίλο και συνάδελφο σχετικά με αυτά, έτσι μου γεννήθηκε η ιδέα να γράψω το post αυτό.
    SSRS και IIS
    Ένα από τα πρώτα πράγματα που κάνει εντύπωση ειδικότερα σε όσους έχουν προγενέστερη εμπειρία από τον SSRS 2005 είναι το γεγονός ότι από την έκδοση των SSRS 2008 δεν υπάρχει η ανάγκη του IIS. Αν και αυτό μπορεί να είναι κάπως περίεργο, εντούτοις είναι μια σωστή απόφαση ώστε τα SSRS να απαγκιστρωθούν από τον IIS. O IIS είχε μεγάλη επίδραση στα SSRS ιδιαίτερα στην εγκατάσταση τους και αυτό διότι αρκετά IT περιβάλλοντα δεν θέλουν στην ίδια μηχανή να έχουν IIS και SQL Server. Επίσης θα πρέπει να τονισθεί ότι πράγματα όπως το web.config hierarchy μπορεί να έχει, άθελα του, επίδραση στα SSRS επειδή στις περισσότερες περιπτώσεις οι Web Server δεν είναι σωστά configured. Επίσης κατά την γνώμη αρκετών το να έχεις τα SSRS delivery components μέσα στον IIS δεν είναι ότι καλύτερο μιας και δεν σου δίνεται καλύτερο resource governance.
    Στις εκδόσεις μέχρι και τα SSRS 2005 ο IIS χρησιμοποιούταν σαν HTTP server για τα SSRS. Από τα SSRS 2008 και μετά αυτά χρησιμοποιούν απευθείας το HTTP.SYS από το λειτουργικό σύστημα. Έτσι το λειτουργικό πλέον κάνει την δουλειά και όχι ο IIS. Έτσι και αλλιώς θα πρέπει να γίνει κατανοητό ότι τα SSRS δεν είναι ένας γενικού σκοπού web server.
    Εξαιτίας ότι πλέον ο IIS είναι παρελθόν ο Report Server κάνει φυσικά μόνος του url registration και management τόσο για τον Report Manager όσο και για τον Report Server SOAP endpoints κάνοντας χρήση του HTTP.SYS
    Χρησιμοποιώντας το RS Configuration Tool έχουμε την δυνατότητα να settαρουμε αυτά τα URLs μαζί με τις πληροφορίες τους όπως πρωτόκολλο, path, port, virtual directory. Οι πληροφορίες αυτές αποθηκεύονται στο rsreportserver.config στο tag.
    Εδώ μου δίνεται η ευκαιρία να κάνω μια μικρή αλλά σημαντική παρατήρηση . Εξαιτίας ότι δεν υπάρχει εξάρτηση από τον IIS ο Report Manager καθώς και το Report Server web service έχουν ενσωματωθεί στο SQL Server Reporting Services Web Service.
    Συνεχίζοντας μετά την παρατήρηση μου θα πρέπει να αναφερθεί ότι τα ποιο common IIS settings τα οποία υπήρχαν στα SSRS 2005 υποστηρίζονται και στα SSRS 2008 και SSRS 2008 R2. Τέτοια είναι IP address, host headers, multiple ports, SSL certifications, IIS Security modes( NTLM, Kerberos, Negotiate, Basic, Custom). Δεν υποστηρίζονται anonymous, digest και passport authentication ή client certificates.
    Αρκετοί θεωρούν ότι η μεγαλύτερη απώλεια από την ανεξαρτητοποίηση των SSRS από τον IIS είναι τα ISAPI filters. Αν για παράδειγμα είχες single sign-on θα πρέπει να πας με τον ISA πλέον ή αν θέλεις κάποιο άλλο functionality εναλλακτική είναι να πας με ASP.NET HTTP custom modules.
    Φυσικά θα ήταν παράλειψη μου να μη τονίζω ότι μπορείς να έχεις εγκατεστημένο τον IIS και να στήσεις και τα SSRS στον ίδιο server. Αλλά θα πρέπει να γίνει κατανοητό ότι ακόμα και έτσι μιλάμε για δύο διαφορετικά services. Ακόμα και αν φτιάξει ένα virtual directory που έχει το ίδιο όνομα και port στον IIS αυτό δεν πρόκειται ποτέ να δεχθεί τα αιτήματα μιας και το HTTP.SYS πρώτο βλέπει τα αιτήματα αυτά και τα δρομολογεί στα SSRS.
    SSRS Windows Service και Memory Management
    Όλα πλέον στα SSRS είναι ενσωματωμένα σε ένα windows service το οποίο περιέχει τα Report Manager, Report Service Web Service, Scheduling service, Notification service, Event Service.
    Αυτό δεν είναι άλλο από το ReportingServicesService.exe. Το service αυτό κάνει host πολλαπλά application domains. Κάθε ένα από τα παραπάνω ενσωματωμένα services χρησιμοποιεί ξεχωριστό application domain. Αυτό μας δίνει την δυνατότητα να τα ενεργοποιούμε ή απενεργοποιούμε ξεχωριστά αν και υπάρχει εξαρτήσεις μεταξύ τους.
    Παρόλο που έχουμε ξεχωριστά application domains η διαχείριση της μνήμης είναι κοινή για κάθε service μέσα σε αυτό. Tα SSRS χρησιμοποιούν components από το SQL OS για να κάνουν διαχείριση μνήμης. Έτσι ενώ στις προηγούμενες εκδόσεις δεν μπορούσαμε να ελέγξουμε αυτή, εξαιτίας ότι όλα ήταν κάτω από την σκεπή του IIS, τώρα έχουμε την δυνατότητα να ελέγξουμε αυτή ορίζοντας τα πάνω και κάτω όρια αυτής. Επίσης υπάρχουν memory thresholds με αποτέλεσμα όταν ένας από αυτούς εμφανιστεί τα SSRS αλλάζουν συμπεριφορά ώστε να είναι πάντα διαθέσιμα στον τελικό χρήστη.
    Κάθε application domain το οποίο φιλοξενείται μέσα στο SSRS Windows Service όταν ξεκινάει παίρνει το ελάχιστο ποσό μνήμης που χρειάζεται για να ξεκινήσει. Από εκεί και μετά αρχίζει να αναφέρει το τι μνήμη χρησιμοποιεί και φυσικά ακούει τα notification που ο memory manager στέλνει σε αυτό και αφορούν το πόσο μνήμη χρησιμοποιεί και πόση θα πρέπει να απελευθερώσει. Όλα αυτά γίνονται με βάση έναν αλγόριθμο ο οποίος είναι βασισμένος στο χαμηλό κόστος και στο μεγαλύτερο memory consumption.
    Εάν δεν υπάρχει διαθέσιμη μνήμη τότε ο Report Server γυρίζει HTTP 503 error.
    Εάν θέλω να ορίσω το μέγεθος της μνήμης υπάρχουν διαθέσιμα τέσσερεις νέες επιλογές μέσα (ναι δεν είναι γραφικό) στο rsreportserver.config. Αυτές είναι:
    1. WorkingSetMinimum
    Ορίζουμε το ελάχιστο ποσό μνήμη που θέλουμε τα SSRS να χρησιμοποιούν
    2. WorkingSetMaximum
    Ορίζουμε το μέγιστο ποσό μνήμη που θέλουμε τα SSRS να χρησιμοποιούν
    3. MemorySafetyMargin
    Ορίζει το μέγιστο επιτρετό για το low-memory section
    4. MemoryThreshhold
    Ορίζει το μέγιστο επιτρεπτό για το medium-memory pressure section.
    Σε αυτό το σημείο θα πρέπει να σας εξηγήσω λίγο περισσότερο την διαχείριση της μνήμης ώστε να γίνουν κατανοητές οι επιλογές 3 και 4.
    Όταν έρχεται ένα αίτημα για μείωση της μνήμης που χρησιμοποιείται, ο server υπολογίζει το ελάχιστο μέγεθος της μνήμης που θα ελευθερωθεί και λαμβάνει από τα application domains πληροφορίες τέτοιες ώστε να μπορεί να ξέρει πόση μνήμη θα ελευθερώσει και πόσο εύκολα μπορεί να γίνει αυτό γιατί όπως έχω αναφέρει και ποιο πάνω ο αλγόριθμος αυτό κοιτάζει επειδή όταν προσπαθεί να μειώσει την μνήμη ο Report Server κάνει serialize κάποια state information στο δίσκο. Αυτό σημαίνει ότι θα πρέπει να γίνει παύση σε κάποια μεγάλα reports και αυτό το κάνει με το να κάνει serialize και να αφήσει τα μικρά. Έτσι έχουμε τρεις memory pressure καταστάσεις.
    1. Low
    Σε αυτή όλα τα request γίνονται processed και φυσικά νέα γίνονται αποδεκτά. Requests τα οποία απαιτούν background processing συνεχίζουν με χαμηλή προτεραιότητα.
    2. Medium
    Αυτά τα request που είναι σε εξέλιξη συνεχίζουν να εκτελούνται, ενώ τα νέα γίνονται αποδεκτά ανά περίπτωση. Το memory allocation σε όλα τα application domains αρχίζει να μειώνεται με μεγάλη μείωση στα background processing application domains (πχ Scheduling). Tα requests στο web service και στο URL access μπαίνουν στην υψηλή προτεραιότητα ώστε να μην υπάρχει επίπτωση στον τελικό χρήστη.
    3. High
    Δεν γίνονται αποδεκτά νέα request όπως επίσης requests για μνήμη απορρίπτονται. Σε αυτή την περίπτωση αρχίζει και το serialization στο δίσκο όπου φυσικά έχουμε σαν απόρροια να πέφτει η απόδοση των τρεχόντων request.
    Στην παρακάτω εικόνα συνοψίζονται όλα τα παραπάνω

  20. antonch
    Σήμερα λέω να κάνω κάτι που ίσως να σας αλλάξει πολλά στον τρόπο με τον οποίο αντιμετωπίζετε το transaction log.
    Είμαι σίγουρος ότι οι περισσότεροι έχετε το πρόβλημα το transaction log να μεγαλώνει ανεξέλεγκτα και να φωνάζετε βοήθεια.
    Να διαμαρτύρεστε που η Microsoft κατάργησε την TRUNCATE_ONLY.
    Αλλά είπα ήδη πολλά, δείτε το video και θα εξηγηθούν πολλά.

    Αυτά και ελπίζω να σας άρεσε.
    Υ.Γ Αυτό ήταν ένα video το οποίο πραγματικά γούσταρα που το έκανα για αυτό και τρόπος με τον οποίο μίλαγα, δεν έχει να κάνει με τίποτα άλλο.
  21. antonch
    Ίσως όσα θα αναφερθούν παρακάτω να είναι γνωστά, και το post αυτό να μην είναι ενδιαφέρον. Όμως έχω την υποχρέωση να τα αναφέρω ξανά γιατί θεωρώ ότι είναι πράγματα στα οποία δεν δίνουμε ιδιαίτερη σημασία και τα οποία όταν διογκώνονται είναι δύσκολα στην επίλυση τους.
    Θα μιλήσουμε εδώ γιa την αρχιτεκτονική μιας database στον SQL Server, από τι αποτελείτε μια database, πιο είναι το ιδανικό αρχικό μέγεθος δημιουργίας της, τι πολιτική να ορίσω για το growth της.
    Μια database στον SQL Server αποτελείτε από τουλάχιστον 2 αρχεία. Το ένα από αυτά είναι το data αρχείο και το άλλο είναι το log αρχείο. Εάν δεν ορίσω κάτι συγκεκριμένο κατά την δημιουργία της database, αυτή είναι ένα πιστό αντίγραφο της model database που έχει ο SQL Server. Δηλαδή έχει όλα τα περιεχόμενα και το μέγεθος της model database. Γενικότερα να γνωρίζεται ότι κάθε φορά που φτιάχνεται μια database αυτή είναι ένα αντίγραφο της model database τουλάχιστον ως προς τα περιεχόμενα της, μιας και κατά την δημιουργία έχουμε την δυνατότητα να αλλάξουμε το μέγεθος, το location που θα είναι τα αρχεία της database και ένα σωρό άλλα options και παραμέτρους.
    Αν αναρωτιέστε ποια είναι τα περιεχόμενα της model database, αυτά είναι τα database system catalogs και τυχόν δικά μας objects όπως tables, views, stored procedures κλπ που έχουμε φτιάξει στην model με σκοπό να τα έχουμε διαθέσιμα στις νέες δικιές μας databases. (Παρατήρηση: Εάν έχω ήδη δικίες μου databases και φτιάξω στην model ένα νέο δικό μου object (πχ table) τότε αυτό δεν θα πάει και στις ήδη υπάρχουσες αλλά μόνο στις νέες).
    Όπως είπα και πιο πάνω μια database έχει τουλάχιστον 2 αρχεία το data file και το log file. Μια database μπορεί να έχει μέχρι 32.767 αρχεία. Το μέγεθος της μπορεί να φτάσει στα 524.258 ΤΒ για τις εκδόσεις 2005 και 2008 και στα 1.048.512 ΤΒ για τις εκδόσεις 2000 και 7.0. Κάθε data file δεν μπορεί να είναι μεγαλύτερο από 16 ΤΒ για τις εκδόσεις 2005 και 2008 και 32 ΤΒ για 2000 και 7.0, ενώ το κάθε log file δεν μπορεί να είναι μεγαλύτερο των 2 ΤΒ για τις εκδόσεις 2005 και 2008, 32 ΤΒ στην έκδοση 2000 και 4 ΤΒ στην έκδοση 7.0.
    Όταν δημιουργούμε μια database συνήθως ορίζουμε το αρχικό μέγεθος δημιουργίας της, τόσο για το data όσο και για το log file. O χώρος αυτός καταλαμβάνεται άμεσα από το δίσκο μας. Δηλαδή αν φτιάξω μια βάση με 10 ΜΒ data file και 3 ΜΒ log file τότε έχω μείον 13 ΜΒ από τα διαθέσιμα του δίσκου μου.
    Κάθε data file χωρίζεται εσωτερικά σε σελίδες (pages) των 8ΚΒ (8.192 Β), στις οποίες αποθηκεύονται τα δεδομένα που έχω στην βάση (data, metadata, indexes). Κάθε 8 συνεχόμενες σελίδες μου κάνουν ένα extent (64 ΚΒ ήτοι 16 extents / 1 ΜΒ). Υπάρχουν δύο είδη extent τα uniform (και οι 8 σελίδες ανήκουν στον ίδιο object πχ. Table) και τα mixed (οι 8 σελίδες δεν ανήκουν στο ίδιο object αλλά σε περισσότερα από ένα) .
     
    Σε κάθε data file οι πρώτες 8 σελίδες είναι εξ ορισμού δεσμευμένες από κάποιες ειδικού χειρισμού σελίδες που στην ουσία κάνουν trace τον ελεύθερο και δεσμευμένο χώρο σε αυτό. Αυτές είναι οι File Header (FH), Page Free Space (PFS), Global Allocation Map (GAM), Shared Global Allocation Map (SGAM) (περισσότερα)
    Κάθε σελίδα όπως είπα και πιο πάνω είναι 8 ΚΒ. Από αυτά τα 96 ΚΒ είναι ο page header στον οποίο είναι αποθηκευμένες οι εξής πληροφορίες page number, page type, το ποσό του free space στην σελίδα, και το allocation unit ID του object στο οποίο ανήκει η σελίδα. Με το που βάζω το πρώτο record αυτό μπαίνει αμέσως μετά από τον header και στο τέλος της σελίδα υπάρχει το record offset το οποίο μπαίνει με την αντίστροφη σειρά της εισαγωγής. Άρα ο πραγματικός ωφέλιμος χώρος που έχω πάνω σε κάθε σελίδα είναι 8060 bytes. Αυτό είναι και το μέγιστο record length που μπορώ να έχω πάνω σε ένα πίνακα. Δηλαδή εάν έχω ένα πίνακα που το record length του είναι 100 bytes αυτό σημαίνει ότι σε κάθε σελίδα χωράνε 80 records, και αν ο πίνακας έχει 200 εγγραφές τότε θέλω 3 σελίδες για να αποθηκευτούν τα δεδομένα του. (περισσότερα). Επίσης θα πρέπει να το τονίσω σε αυτό το σημείο ότι ένα record ανήκει πάντα σε μια σελίδα, δεν υπάρχει ποτέ περίπτωση να είναι το μισό σε μια και το άλλο σε άλλη. Θα προλάβω μερικούς συναδέλφους που θα πουν για τα datatypes varchar(max), nvarchar(max), text, ntext, images, varbinary(max) ότι είναι σε άλλες σελίδες αλλά είναι εκεί λόγω μεγέθους.
    Αυτό που σας έχω αναφέρει μέχρι τώρα είναι αρκετά σημαντικό για τον σχεδιασμό των tables, indexes σε μια database στον SQL Server. Διότι κυρίες και κύριοι συνάδελφοι εάν κάποιος αρχίζει και βάζει πεδία μέσα στον πίνακα (μέχρι 1024 πεδία μπορεί να έχει ένας πίνακας) και φτιάξει ένα record length 5000 bytes αυτό σημαίνει ότι μέσα σε μια σελίδα μπαίνει ένα και μόνο ένα record και μένουν ανεκμετάλλευτα 3000 bytes. Εάν λοιπόν ο πίνακας μου έχει 10.000 records σημαίνει ότι θέλω και 10.000 σελίδες που στην κάθε μία χάνω 3.000 bytes, άρα 3.000 bytes x 10.000 σελίδες = 30.000.000 bytes / 1024 bytes = 29296 KB / 1024 KB=28 MB χαμένου χώρου στον δίσκο, μιας και αν θεωρήσουμε ότι υπάρχει μόνο αυτός ο πίνακας στην βάση μας (κάτι φυσικά που δε συμβαίνει στην πραγματικότητα) το data file μας έχει δεσμεύσει χώρο στο δίσκο ίσο με 78 ΜΒ. Όπως γίνεται άμεσα κατανοητό ο κακός σχεδιασμός επηρεάζει άμεσα και το performance πώς? η απάντηση σε λίγο.
    Επίσης όταν δημιουργούμε μια database σκόπιμο θα είναι να έχουμε κάνει μια εκτίμηση για το μέγεθος για τους πρώτους 3 μήνες της ζωής της ώστε να δεσμεύσουμε τον χώρο αυτό κατά την στιγμή της δημιουργίας της. Ο σκοπός του να γίνει κάτι τέτοιο είναι σημαντικός διότι αν δώσουμε κάτι το οποίο είναι μικρό και σε συνδυασμό με το τι έχουμε ορίσει σαν file growth policy, που συνήθως το αφήνουμε μικρό, και έχουμε μεγάλο αριθμό από transactions αυτό θα μας οδηγήσει μαθηματικά στο να έχουμε συνεχόμενο ΙΟ στον δίσκο μας επειδή ο SQL Server θα αιτείτε συνέχεια επιπλέον χώρο σε αυτόν μέσω του λειτουργικού συστήματος καθώς η database θα γεμίζει συχνότερα. Αυτό είναι καταστροφικό σε συστήματα που έχουν πολλά transactions.
    Πριν προχωρήσω στην διαδικασία θα επισημάνω την λέξη εκτίμηση. Αυτό σημαίνει ότι μετά από πάροδο μερικών ημερών κάνω έναν έλεγχο για να δω αν η εκτίμηση μου είναι σωστή και αναλόγως πράττω, μεγαλώνω ή μικραίνω την database. Τώρα πως κάνουμε την εκτίμηση αυτή.
    Πρώτα από όλα επιλέγουμε μια χρονική περίοδο για την εκτίμηση μας πχ 1 μήνα , 2 μήνες κλπ ανάλογα με το είδος της εφαρμογής που χρησιμοποιεί την database, πχ σε ένα ERP θα μπορούσαμε διαλέξουμε 3 μήνες.
    Έπειτα βρίσκω το record length του κάθε πίνακα αυτό το πολλαπλασιάζω με τον αριθμό των records που εκτιμώ ότι θα μπουν στην χρονική περίοδο που έχω διαλέξει. Το αποτέλεσμα τα κάνω σελίδες και τις σελίδες τις κάνω MB. Το ίδιο αλλά κάπως διαφοροποιημένο το κάνω και για τους indexes. Το άθροισμα όλων αυτών μου δίνει το αρχικό μέγεθος δημιουργίας της database μου.
    Δεν θα το αναλύσω περισσότερο εδώ απλά θα σας παραπέμψω στα books online όπου έχει αναλυτικά όλη την διαδικασία. Απλά κάντε αναζήτηση για Estimating the Size of a Database.
    Μέχρι τώρα δεν έχω αναφέρει τίποτα για το άλλο αρχείο που έχει μια database, το log αρχείο. Προσωπικά πιστεύω ότι είναι το σημαντικότερο αρχείο σε μία database. Σε αυτό καταγράφονται όλα εκτός από τα select statements και τα blob πεδία αν και αυτά έχω την επιλογή να πω να καταγράφονται. Συνήθως το αρχικό μέγεθος δημιουργίας του είναι το 30% του αρχικού μεγέθους του ή των data αρχείου (αρχείων). Δηλαδή αν έχω 100 ΜΒ data φτιάχνω log ίσο με 30ΜΒ. Βέβαια αυτό αν και είναι κανόνας, πάντα υπάρχει περιθώριο καταστρατήγησης του, όπως για παράδειγμα αν έχω heavily transactional databases, όπου σε αυτές τις περιπτώσεις είναι ανάλογα μεγαλύτερο. Έδω όμως θα τονίσω ότι χρειάζεται ιδιαίτερη προσοχή στην πολιτική για το πως αυτό θα μεγαλώνει όταν γεμίσει. Αυτό που έχω δει είναι ότι συνήθως βάζετε κάτι μικρό ή αφήνετε το default που είναι 10%. Αυτό είναι και το λάθος σας. Καλό είναι να βάζετε σαν πολιτική το αρχικό μέγεθος του. Δηλαδή αν έχω 30ΜΒ Log λέω στo file growth του 30ΜΒ ούτε 100% ούτε τίποτα σε ποσοστό. Και αυτό γιατί πολλοί θεωρούν το Log σαν έναν κουβά όμως τα πράγματα δεν είναι έτσι. Εσωτερικά το log χωρίζεται σε virtual logs. Ο σκοπός μου είναι να έχω πάντα ισομεγέθη virtual log ώστε να μην μου εμφανισθεί το φαινόμενο το Log file να είναι μεγαλύτερο από το ή τα data file(s). Σε κάποιο άλλο post μου θα σας πω περισσότερα για αυτό.
    Τώρα βέβαια θα πρέπει να πω ότι αν παίρνω backup την βάση μου το log γίνεται truncate. Προσοχή δεν μειώνεται σαν μέγεθος στον δίσκο αλλά εσωτερικά γίνεται truncate. Αυτό σημαίνει ότι ο εσωτερικός χώρος που ελευθερώνεται επαναχρησιμοποιείται. Λογικά αν έχω εκτιμήσει σωστά το αρχικό μέγεθος δημιουργίας του log file και κάνω καθημερινό backup δεν θα το δω ποτέ να μεγαλώνει πέρα από το αρχικό του μέγεθος.
    Για να δούμε πως χρησιμοποιείται το log. Τρεις είναι οι βασικοί παράγοντες που επηρεάζουν το performance, CPU, MEMORY, DISK IO. Δυστυχώς όμως το χειρότερο από όλα σε performance σε σχέση με τα άλλα είναι ο δίσκος. Σκοπός του SQL Server είναι να έχει το μικρότερο δυνατό disk io. Για να το κάνει αυτό χρησιμοποιεί μνήμη και φυσικά το log file.
    O SQL Server δεσμεύει ένα ποσό από την διαθέσιμη μνήμη του συστήματος. Ένα ποσό από αυτή την μνήμη ανήκει στη buffer cache. Για να δούμε όλη την διαδικασία με ένα παράδειγμα.
    Είπαμε πιο πάνω ότι τα δεδομένα μου είναι αποθηκευμένα σε σελίδες των 8KB. Έτσι όταν κάποιος χρήστης κάνει ένα select, insert, update, delete αυτό που κάνει ο SQL Server είναι να δει αν υπάρχουν στην buffer cache οι σελίδες που θα επηρεαστούν από την ενέργεια αυτή. Εάν δεν είναι τότε τις διαβάζει από τον δίσκο και τις βάζει στην buffer cache. Το επόμενο βήμα του είναι να εκτελέσει την ενέργεια πάνω στις σελίδες που είναι στην buffer cache. Για το μεν select επιστρέφει τα δεδομένα στον χρήστη, για τις άλλες ενέργειες όμως κάνει ακόμα ένα βήμα γράφει την ενέργεια στο log file. Γιατί το κάνει αυτό; Η απάντηση είναι απλή κάνει minimize το ΙΟ. Στην ουσία οι ενέργειες θα γραφτούν στο data file όταν γίνει η διαδικασία που φέρει το όνομα checkpoint process. Τι κάνει αυτή; Σε τακτά χρονικά διαστήματα έρχεται ο SQL Server και διαβάζει το log είτε από την αρχή εάν είναι η πρώτη φορά είτε από το σημείο που είχε σταματήσει την προηγούμενη φορά η διαδικασία αυτή. Και όσα transactions είναι commited βλέπει ποιες είναι οι σελίδες που έχουν επηρεασθεί από αυτά και τις γράφει στον data file δηλαδή στον δίσκο. Τώρα κάποιος θα αναρωτηθεί και αν πέσει το ρεύμα πριν γίνει η διαδικασία αυτή; ΔΕΝ ΥΠΑΡΧΕΙ ΚΑΝΕΝΑ ΠΡΟΒΛΗΜΑ. Διότι κάθε φορά που ο SQL Server ξεκινάει κοιτάζει το Log file και ότι transaction είναι ολοκληρωμένο και δεν υπάρχει στα data file αναπαράγετε, ότι ήταν σε εξέλιξη γίνεται rollback. Η διαδικασία αυτή λέγεται recovery process. Άρα θα έχω όλα μου τα δεδομένα εκτός βέβαια από αυτά που δεν είχαν προλάβει να ολοκληρωθούν.
    Σας χρωστάω μια απάντηση από πιο πάνω. Θυμηθείτε το παράδειγμα με τις 10.000 σελίδες όπου στην κάθε μία έχω ένα record. Βάλτε με το μυαλό σας τι θα γίνει αν απλά θελήσω να διαβάσω όλα τα δεδομένα του πίνακα. Απλά θα έχω "τσακίσει" τους τρεις βασικούς παράγοντες που επηρεάζουν την απόδοση του SQL Server, και αυτό γιατί για να κινηθούν οι κεφάλες στον δίσκο θα πρέπει να δώσει η εντολή η CPU αυτές θα διαβάσουν τα δεδομένα , άρα μεγάλο ΙΟ και αυτά θα πρέπει αν μεταφερθούν στην μνήμη.
    Έτσι απλά! τα φόρτωσα όλα, και αυτό γιατί όταν σχεδίαζα την βάση μου δεν έλαβα υπόψη μου την αρχιτεκτονική του SQL Server.
  22. antonch
    Τόσα χρόνια στον χώρο της πληροφορικής έχω μάθει να προσπαθώ να καταλάβω τι γίνεται πίσω από την σκηνή με αυτό που ασχολούμαι. Ο SQL Server είναι ένα από αυτά, και στο οποίο έχω αφιερώσει αρκετές τρίχες της κεφαλής μου. Σήμερα θα σας πάρω λίγο από τον πολύτιμο χρόνο σας για να σας μεταφέρω μια γνώση που θα σας φανεί αρκετά χρήσιμη.
    Όλοι λίγο ή πολύ έχετε γράψει ένα sql query. Άλλες φορές αυτό λειτούργησε άψογα άλλες φορές όχι. Το μυστικό για να γράψεις ένα καλό sql query είναι να έχεις κατανοήσει πως αυτό λογικά εκτελείται, ιδιαίτερα στην μηχανή που χρησιμοποιείς, στην δικιά μας περίπτωση ο SQL Server.
    Ένα sql query περιέχει κάποιες εκφράσεις μέσα του, εδώ θα ασχοληθούμε με τι βασικές, Έτσι ένα sql query είναι της μορφής αυτής. Στους αριθμούς μέσα στις παρενθέσεις φαίνεται η σειρά, βήμα, φάση εκτέλεσης.
    Κάθε βήμα δημιουργεί έναν virtual table ο οποίος είναι το input για το επόμενο βήμα. Αυτά το virtual tables δεν είναι διαθέσιμα σε κανένα πλήν του SQL Server, εκτός του τελευταίου που είναι και αυτό που παίρνουμε σαν απάντηση. Εάν στο sql query μας δεν έχουμε κάποια έκφραση απλά αυτή αγνοείτε και πάει στο επόμενο βήμα.
     
    (8) SELECT (9) DISTINCT (11)
    (1) FROM
    (3) JOIN
    (2) ON
    (4) WHERE
    (5) GROUP BY
    (6) WITH {CUBE | ROLLUP}
    (7) HAVING
    (10) ORDER BY
     
    Ας δούμε τα πράγματα λίγο αναλυτικά με ένα παράδειγμα που θα δημιουργήσουμε με το παρακάτω script
    SET NOCOUNT ON;
    USE tempdb;
    GO
    IF OBJECT_ID('dbo.Orders') IS NOT NULL
    DROP TABLE dbo.Orders;
    GO
    IF OBJECT_ID('dbo.Customers') IS NOT NULL
    DROP TABLE dbo.Customers;
    GO
    CREATE TABLE dbo.Customers
    (
    customerid CHAR(5) NOT NULL PRIMARY KEY,
    city VARCHAR(10) NOT NULL
    );

    INSERT INTO dbo.Customers(customerid, city) VALUES('ANTON', 'Athens');
    INSERT INTO dbo.Customers(customerid, city) VALUES('NASOS', 'Athens');
    INSERT INTO dbo.Customers(customerid, city) VALUES('FANIS', 'Athens');
    INSERT INTO dbo.Customers(customerid, city) VALUES('CHRIS', 'Salonica');

    CREATE TABLE dbo.Orders
    (
    orderid INT NOT NULL PRIMARY KEY,
    customerid CHAR(5) NULL REFERENCES Customers(customerid)
    );

    INSERT INTO dbo.Orders(orderid, customerid) VALUES(1, 'NASOS');
    INSERT INTO dbo.Orders(orderid, customerid) VALUES(2, 'NASOS');
    INSERT INTO dbo.Orders(orderid, customerid) VALUES(3, 'FANIS');
    INSERT INTO dbo.Orders(orderid, customerid) VALUES(4, 'FANIS');
    INSERT INTO dbo.Orders(orderid, customerid) VALUES(5, 'FANIS');
    INSERT INTO dbo.Orders(orderid, customerid) VALUES(6, 'CHRIS');
    INSERT INTO dbo.Orders(orderid, customerid) VALUES(7, NULL);
    Μετά από την εκτέλεση του θα έχουμε δύο πίνακες τους Customers, Orders οι οποίοι είναι related μεταξύ τους και τα δεδομένα τους θα είναι τα εξής
    Customers Table Data
    customerid
    city
    ANTON
    Athens
    CHRIS
    Salonica
    FANIS
    Athens
    NASOS
    Athens
     
    Orders Table Data
    Orderid
    customerid
    1
    NASOS
    2
    NASOS
    3
    FANIS
    4
    FANIS
    5
    FANIS
    6
    CHRIS
    7
    NULL
     
    Ας πάρουμε σαν σενάριο ότι θέλουμε να βούμε τους πελάτες της Αθήνας που έχουν κάτω από τρεις παραγγελίες.
    Έτσι το sql query μας θα είναι σαν αυτό.
    SELECT C.customerid, COUNT(O.orderid) AS numorders
    FROM dbo.Customers AS C
    LEFT OUTER JOIN dbo.Orders AS O
    ON C.customerid = O.customerid
    WHERE C.city = 'Athens'
    GROUP BY C.customerid
    HAVING COUNT(O.orderid) 3
    ORDER BY numorders;
    Το αποτέλεσμα της εκτέλεσης του είναι το παρακάτω
    Customerid
    numorders
    ANTON
    0
    NASOS
    2
     
    Ποιά είναι όμως η λογική του εκτέλεση; Ας δούμε λοιπόν τα βήματα της εκτέλεσης.
    Βήμα 1ο - Cross Join
    FROM dbo.Customers AS C ... JOIN dbo.Orders AS O
     
    Εδώ φτιάχνει το καρτεσιανό γινόμενο των δύο πινάκων και το βάζει στο 1ο virtual table (VT1). Το περιεχόμενο του πίνακα αυτού είναι 28 γραμμές ( 4x7).
    Customerid
    City
    Orderid
    customerid
    ANTON
    Athens
    1
    NASOS
    ANTON
    Athens
    2
    NASOS
    ANTON
    Athens
    3
    FANIS
    ANTON
    Athens
    4
    FANIS
    ANTON
    Athens
    5
    FANIS
    ANTON
    Athens
    6
    CHRIS
    ANTON
    Athens
    7
    NULL
    CHRIS
    Salonica
    1
    NASOS
    CHRIS
    Salonica
    2
    NASOS
    CHRIS
    Salonica
    3
    FANIS
    CHRIS
    Salonica
    4
    FANIS
    CHRIS
    Salonica
    5
    FANIS
    CHRIS
    Salonica
    6
    CHRIS
    CHRIS
    Salonica
    7
    NULL
    FANIS
    Athens
    1
    NASOS
    FANIS
    Athens
    2
    NASOS
    FANIS
    Athens
    3
    FANIS
    FANIS
    Athens
    4
    FANIS
    FANIS
    Athens
    5
    FANIS
    FANIS
    Athens
    6
    CHRIS
    FANIS
    Athens
    7
    NULL
    NASOS
    Athens
    1
    NASOS
    NASOS
    Athens
    2
    NASOS
    NASOS
    Athens
    3
    FANIS
    NASOS
    Athens
    4
    FANIS
    NASOS
    Athens
    5
    FANIS
    NASOS
    Athens
    6
    CHRIS
    NASOS
    Athens
    7
    NULL
     
    Βήμα 2ο - Apply Join condition ON Filter
    ON C.customerid = O.customerid
    Στο βήμα αυτό εφαρμόζεται το ON που υπάρχει στο Join και μόνο τα rows εκείνα τα οποία ικανοποιούν το βήμα πηγαίνουν στον VT2 που θα είναι το αποτέλεσμα του βήματος αυτού.
    Έτσι αν πάρω τον VT1 και εφαρμόσω στο παράδειγμα μας το ON θα έχω το εξής αποτέλεσμα
    Customerid
    City
    Orderid
    customerid
    ΟΝ Filter
    ANTON
    Athens
    1
    NASOS
    FALSE
    ANTON
    Athens
    2
    NASOS
    FALSE
    ANTON
    Athens
    3
    FANIS
    FALSE
    ANTON
    Athens
    4
    FANIS
    FALSE
    ANTON
    Athens
    5
    FANIS
    FALSE
    ANTON
    Athens
    6
    CHRIS
    FALSE
    ANTON
    Athens
    7
    NULL
    UNKNOWN
    CHRIS
    Salonica
    1
    NASOS
    FALSE
    CHRIS
    Salonica
    2
    NASOS
    FALSE
    CHRIS
    Salonica
    3
    FANIS
    FALSE
    CHRIS
    Salonica
    4
    FANIS
    FALSE
    CHRIS
    Salonica
    5
    FANIS
    FALSE
    CHRIS
    Salonica
    6
    CHRIS
    TRUE
    CHRIS
    Salonica
    7
    NULL
    UNKNOWN
    FANIS
    Athens
    1
    NASOS
    FALSE
    FANIS
    Athens
    2
    NASOS
    FALSE
    FANIS
    Athens
    3
    FANIS
    TRUE
    FANIS
    Athens
    4
    FANIS
    TRUE
    FANIS
    Athens
    5
    FANIS
    TRUE
    FANIS
    Athens
    6
    CHRIS
    FALSE
    FANIS
    Athens
    7
    NULL
    UNKNOWN
    NASOS
    Athens
    1
    NASOS
    TRUE
    NASOS
    Athens
    2
    NASOS
    TRUE
    NASOS
    Athens
    3
    FANIS
    FALSE
    NASOS
    Athens
    4
    FANIS
    FALSE
    NASOS
    Athens
    5
    FANIS
    FALSE
    NASOS
    Athens
    6
    CHRIS
    FALSE
    NASOS
    Athens
    7
    NULL
    UNKNOWN
     
    Δηλαδή ο VT2 θα είναι τελικά ο παρακάτω
    Customerid
    City
    Orderid
    customerid
    CHRIS
    Salonica
    6
    CHRIS
    FANIS
    Athens
    3
    FANIS
    FANIS
    Athens
    4
    FANIS
    FANIS
    Athens
    5
    FANIS
    NASOS
    Athens
    1
    NASOS
    NASOS
    Athens
    2
    NASOS
     
    Βήμα 3ο - Apply OUTER Join
    FROM dbo.Customers AS C LEFT OUTER JOIN dbo.Orders AS O
    Στην περίπτωση μας μόνο ένας είναι ο πελάτης από την πίνακα τον πελατών που δεν υπάρχει στον VT2 o ΑΝΤΟΝ οπότε μπαίνει και αυτό στον VT3 που είναι το αποτέλεσμα του βήματος αυτού
    Customerid
    City
    Orderid
    customerid
    CHRIS
    Salonica
    6
    CHRIS
    FANIS
    Athens
    3
    FANIS
    FANIS
    Athens
    4
    FANIS
    FANIS
    Athens
    5
    FANIS
    NASOS
    Athens
    1
    NASOS
    NASOS
    Athens
    2
    NASOS
    ΑΝΤΟΝ
    Athens
    NULL
    NULL
     
    Βήμα 4ο - Apply WHERE filter
    WHERE C.city = 'Athens'
    Το αποτέλεσμα είναι ο VT4
    Customerid
    City
    Orderid
    customerid
    FANIS
    Athens
    3
    FANIS
    FANIS
    Athens
    4
    FANIS
    FANIS
    Athens
    5
    FANIS
    NASOS
    Athens
    1
    NASOS
    NASOS
    Athens
    2
    NASOS
    ΑΝΤΟΝ
    Athens
    NULL
    NULL
     
    Βήμα 5ο - Apply Grouping
    GROUP BY C.customerid
    Το αποτέλεσμα είναι ο VT5
    Customerid
    City
    Orderid
    customerid
    FANIS
    Athens
    3
    FANIS
    FANIS
    Athens
    4
    FANIS
    FANIS
    Athens
    5
    FANIS
    NASOS
    Athens
    1
    NASOS
    NASOS
    Athens
    2
    NASOS
    ΑΝΤΟΝ
    Athens
    NULL
    NULL
     
    Βήμα 6ο - Apply Cube or Rollup
    Δεν έχουμε κάτι τέτοιο στο query μας οπότε πάει στο επόμενο βήμα.
    Βήμα 7ο - Apply HAVING Filter
    HAVING COUNT(O.orderid) 3
    Το αποτέλεσμα είναι ο VT7
    Customerid
    City
    Orderid
    customerid
    NASOS
    Athens
    1
    NASOS
    NASOS
    Athens
    2
    NASOS
    ΑΝΤΟΝ
    Athens
    NULL
    NULL
     
    Βήμα 8ο - Apply SELECT List
    SELECT C.customerid, COUNT(O.orderid) AS numorders
    Το αποτέλεσμα είναι ο VT8
    Customerid
    numorders
    NASOS
    2
    ANTON
    0
    Βήμα 9ο - Apply DISTINCT
    Δεν έχουμε κάτι τέτοιο στο query μας οπότε πάει στο επόμενο βήμα.
    Βήμα 10ο - Apply ORDER BY
    SELECT C.customerid, COUNT(O.orderid) AS numorders
    Το αποτέλεσμα είναι ο VT10
    Customerid
    numorders
    ANTON
    0
    NASOS
    2
    Βήμα 11ο - Apply TOP
    Δεν έχουμε κάτι τέτοιο στο query μας οπότε καταλήγουμε στο τελικό μας αποτέλεσμα.
    ΥΓ. Επίτηδες παρέλειψα κάποια βήματα για να μην σας κουράσω. Αν υπάρχει απαίτηση από εσάς μέσω των σχολίων σας θα προχωρήσω βαθύτερα και σε αυτά
  23. antonch
    Πρόσφατα έκανα μια παρουσίαση με το παραπάνω θέμα για το dotNetZone. Επειδή το θεωρω σημαντικό και επειδή τα παιδιά εκεί την έχουν μαγνητοσκοπήσει σας την δίνω και σε εσάς.
    https://www323.livemeeting.com/cc/usergroups/view?id=dnz34
    και η παρουσίαση μου είναι στο
    http://cid-4745d5449dec653a.skydrive.live.com/self.aspx/dnzPresentations/Why%20%5E0%20How%20to%20optimize%20SQL%20Server%20for%20performance%20from%20design%20to%20query.pdf
  24. 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.
    Συνεχίζεται…
×
×
  • Create New...