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. Συνεχίζεται…

Ας συνεχίζουμε στο δεύτερο και τελευταίο μέρος τους 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.

Λοιπόν μιας και απέκτησα και εδω ένα 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

Ακόμα δεν υποστηρίζονται όλα τα undocumented commands τα οποία κάποιοι είχατε χρησιμοποιήσει στο παρελθόν

Πρόσφατα αντιμετώπισα ένα πρόβλημα στα SQL Server 2005 Reporting Services. Ενώ όλα ήταν μια χαρά και όλοι μέσα στην εταιρεία δούλευαν μια χάρα, ένα πρωί όπως συμβάνει πάντα σε αυτές τις περιπτώσεις είχαν σπάσει τα τηλέφωνα, είχα 40 mail, και 20 msn χρήστες να θέλουν να μιλήσουν μαζί μου. Τι έγινε ρε παιδιά... 1. πήραμε φωτία; 2. δεν θα βγει ο Ομπάμα; 3. θα μας πέσει ο ουρανός στο κεφάλι; Τιποτα από όλα αυτά, απλά, όταν πήγαιναν να τυπώσουν είχαν ένα ώραίο μύνημα που τους έλεγε "Unable to load client print control". Μετά από ψάξιμο βρήκα ότι η αιτία είναι ότι ένα security patch μπλοκάρει τη εκτέλεση του συγκεκριμένου dll και η λύση είναι 1. Κατεβάσουμε το Microsoft Report Viewer Redistributable 2005 Service Pack 1 2. Πάμε και κάνουμε unistall τα security patches KB956803 & KB956391 και από τον server αλλα και από τους clients 3. Στήνουμε το Microsoft Report Viewer Redistributable 2005 Service Pack 1 4. Κάνουμε restart τον server