antonch

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

O SQL Server έχει αρκετά εργαλεία για να κάνεις export & import data. Από τα απλά T-SQL BULK INSET ή το κλασσικό BCP μέχρι τα DTS (Data Transformation Services) και σήμερα τα SSIS ( SQL Server Integration Services). Όμως υπάρχουν αρκετές περιπτώσεις που δεν θα ήθελες να εμπλακείς με αυτά. Ένα σενάριο το οποίο κάποια στιγμή σε ένα project μου έτυχε ήταν η απαίτηση να πατάει ο χρήστης ένα κουμπί και να γίνονται τα δεδομένα export σε Excel αρχείο. Για να δούμε λοιπόν την υλοποίηση του χωρίς να χρησιμοποιήσω κάτι από τα παραπάνω αλλά κάνοντας χρήση αγνού T-SQL και της δυνατότητας που έχει ο SQL Server με τους Linked Servers. Βασική προϋπόθεση για να μπορέσει η λύση να δουλέψει είναι να δημιουργήσεις ένα άδειο αρχείο excel στο server με συγκεκριμένο όνομα και σε συγκεκριμένο directory. Ας το πούμε empty.xls και ας το βάλουμε στο c:\temp. Αυτό θα λειτουργεί σαν template για τα αρχεία που δα δημιουργήσουμε παρακάτω. Όμως δεν φτάνει μόνο αυτό. Θα πρέπει να ανοίξω το excel αρχείο και να δώσω ένα όνομα στο φύλλο (πχ MyData). Ακόμα θα πρέπει να γνωρίζω πόσα πεδία θα βάλω στο excel φύλλο πχ αν ξέρω ότι θα βάλω 2 πεδία θα πρέπει στα πρώτα 2 κελιά της πρώτης γραμμής να δώσω κάποιο όνομα πχ A,B. Φτιάχνω την stored procedure που θα κάνει όλη την δουλειά create proc usp_write2Excel (@fileName varchar(100),@NumOfColumns tinyint,@query varchar(200)) as begin declare @dosStmt varchar(200) declare @tsqlStmt varchar(500) declare @colList varchar(200) declare @charInd tinyint set nocount on -- -- COLUMNS LIST CREATION -- set @charInd=0 set @colList = 'A' while @charInd begin set @charInd = @charInd + 1 set @colList = @colList + ',' + char(65+ @charInd) end -- CREATE MY EXCEL FILE BY COPING EXCEL TEMPLATE set @dosStmt = ' copy c:\temp\empty.xls ' + @fileName exec master..xp_cmdshell @dosStmt -- Create a "temporary" linked server to that file in order to "Export" Data EXEC sp_addlinkedserver 'ExcelSource','Jet 4.0','Microsoft.Jet.OLEDB.4.0',@fileName,NULL,'Excel 5.0' -- construct a T-SQL statement that will actually export the query results-- to the Table in the target linked server set @tsqlStmt = 'Insert ExcelSource...[MyData$] ' + ' ( ' + @colList + ' ) '+ @query -- execute dynamically the TSQL statement exec (@tsqlStmt) -- drop the linked server EXEC sp_dropserver 'ExcelSource' set nocount off end GO Execute sp exec usp_write2Excel 'c:\temp\Customers.xls',2,'select customerid,companyname from northwind.dbo.customers' Αυτό ήταν έχεις τα δεδομένα σου σε Excel!!!

Επειδή είμαι μεγάλος τεμπέλης αλλά και επειδή θέλω να τελειώνω γρήγορα με τις τυχόν αλλαγές που θα προκείψουν πάντα έφτιαχνα stored procedures με "δυναμικές" παραμέτρους Τώρα με το SQL Server 2005 τα πράγματα είναι αρκετά καλύτερα εξαιτίας 2 χαρακτηριστικών 1. το νέο xml data type 2. τον "integrated" XML Parser Ψάχνοντας από εδώ και από εκεί βρήκα αυτό, το οποίο είναι αρκετά ενδιαφέρον για να το δείτε και πιστεύω ότι αξίζει τον κόπo (PDF)

Όπως όλοι γνωρίζουμε μια από τις system databases του SQL Server είναι η tempdb. Λίγοι είναι όμως γνωρίζουν το ρόλο αλλά και την σημασία της database αυτής. Και για να γίνω εξ’ αρχής αντιληπτός ο ρόλος της είναι σημαντικός, ζωτικός θα έλεγα για το performance του SQL Server. Ειδικά στον SQL Server 2005 γίνεται «τρελή χρήση» της βάσης αυτής. Πολλά παλιά αλλά και νέα χαρακτηριστικά που μας έχει δώσει ο SQL Server 2005 χρησιμοποιούν την tempdb όπως: Query Triggers Snapshot isolation and read committed snapshot (RCSI) MARS Online index creation Temporary tables, table variables, and table-valued functions DBCC CHECK LOB parameters Cursors Service Broker and event notification XML and LOB variable Query notifications Database mail Index creation User-defined functions Στον SQL Server 2005 έχουν γίνει αρκετές βελτιώσεις στην tempdb για να έχει το μέγιστο δυνατό performace. Επίσης κάτι το οποίο θα πρέπει να επισημανθεί είναι κάθε φορά που ξεκινάει το service του SQL Server η tempdb γίνεται recreate. Ένα κοινό tip που όλοι γνωρίζουμε είναι το να μεταφέρουμε την tempdb σε άλλο φυσικό δίσκο και να μεγαλώνουμε το μέγεθος της από το 8ΜΒ σε κάτι που να εκπληρώνει τις ανάγκες μας. Ενδεικτικά σας παραθέτω ένα πίνακα με βάση το μέγεθος της εταιρίας Μέγεθος εταιρίας Size of Data in MB Size of Log in MB Μικρή 1024 256 Μεσαία 5120 1024 Μεγάλη 10024 2048 Ακόμα δεν θα πρέπει να έχω το option auto shrink on, καθώς επίσης να μην είναι auto expand. Για να δείτε πως μπορείτε να μεταφέρεται την tempdb σε άλλο δίσκο δείτε στα books online του SQL Server το ALTER DATABASE – EXAMPLE G. Ακόμα μερικά tips για την tempdb. Βάλτε σε ξεχωριστούς φυσικούς δίσκους τα data files και τα logs. Και γράφω τα data files και όχι το data file γιατί στην περίπτωση που είμαι σε ένα σύστημα με περισσότερους από έναν επεξεργαστές μπορώ να έχω περισσότερα από ένα data files στην tempdb, θα έλεγα μάλιστα ότι πρέπει να το κάνω διότι ο κάθε επεξεργαστής θα χρησιμοποιήσει διαφορετικό data file. Αυτό σημαίνει ότι εάν έχω 2 επεξεργαστές τότες 2 data files και αν αυτά τα έχω σε ξεχωριστούς φυσικούς δίσκους και με διαφορετικό bus, ε τότε μιλάμε για πάρτυ.

Η Διεθνής Ημέρα του Διαχειριστή Συστημάτων γιορτάζεται από το 2000, με πρωτοβουλία του ελληνοαμερικανού διαχειριστή συστημάτων (System Administrator) Τεντ Κετάτος, την τελευταία Παρασκευή κάθε Ιουλίου. Χρόνο με το χρόνο η γιορτή... διεθνοποιείται όλο και περισσότερο. Ο συμπατριώτης μας από το Σικάγο θέλησε με αυτό τον τρόπο να φέρει στην επιφάνεια και να τιμήσει τους διαχειριστές συστημάτων, αλλά και τους συναφείς επαγγελματίες της πληροφορικής, οι οποίοι νύχτα-μέρα, με ήλιο και βροχή, φροντίζουν να κρατούν σε λειτουργία τα ζωτικής σημασίας για το σύγχρονο κόσμο πληροφοριακά συστήματα και να επιλύουν και το απλούστερο πρόβλημα, που φαντάζει "βουνό" για τον μέσο χρήστη. Η εθιμοτυπία της ημέρας απαιτεί ο χρήστης να προσφέρει ένα δωράκι στον διαχειριστή του υπολογιστικού του συστήματος σε ένδειξη ευγνωμοσύνης. Από σοκολάτες και κρασιά ως ηλεκτρονικά γκάτζετ και βιντεοπαιχνίδια. Πηγή:http://troktiko.blogspot.com/2009/08/blog-post_1248.html

Επειδή αρκετές φορές με ρωτούν αν ο SQL Server έχει κάποια όρια σας παραθέτω τα όρια του Database Engine Object x32 x64 Batch size1 65,536 * Network Packet Size 65,536 * Network Packet Size Bytes per short string column 8,000 8,000 Bytes per GROUP BY, ORDER BY 8,060 8,060 Bytes per index key2 900 900 Bytes per foreign key 900 900 Bytes per primary key 900 900 Bytes per row8 8,060 8,060 Bytes in source text of a stored procedure Lesser of batch size or 250 MB Lesser of batch size or 250 MB Bytes per varchar(max), varbinary(max), xml, text, or image column 2^31-1 2^31-1 Characters per ntext or nvarchar(max) column 2^30-1 2^30-1 Clustered indexes per table 1 1 Columns in GROUP BY, ORDER BY Limited only by number of bytes Limited only by number of bytes Columns or expressions in a GROUP BY WITH CUBE or WITH ROLLUP statement 10 10 Columns per index key7 16 16 Columns per foreign key 16 16 Columns per primary key 16 16 Columns per base table 1,024 1,024 Columns per SELECT statement 4,096 4,096 Columns per INSERT statement 1,024 1,024 Connections per client Maximum value of configured connections Maximum value of configured connections Database size 1,048,516 terabytes 1,048,516 terabytes Databases per instance of SQL Server 32,767 32,767 Filegroups per database 32,767 32,767 Files per database 32,767 32,767 File size (data) 16 terabytes 16 terabytes File size (log) 2 terabytes 2 terabytes Foreign key table references per table4 253 253 Identifier length (in characters) 128 128 Instances per computer 16 16 Length of a string containing SQL statements (batch size)1 65,536 * Network packet size 65,536 * Network packet size Locks per connection Maximum locks per server Maximum locks per server Locks per instance of SQL Server5 Up to 2,147,483,647 Limited only by memory Nested stored procedure levels6 32 32 Nested subqueries 32 32 Nested trigger levels 32 32 Nonclustered indexes per table 249 249 Parameters per stored procedure 2,100 2,100 Parameters per user-defined function 2,100 2,100 REFERENCES per table 253 253 Rows per table Limited by available storage Limited by available storage Tables per database3 Limited by number of objects in a database Limited by number of objects in a database Partitions per partitioned table or index 1,000 1,000 Statistics on non-indexed columns 2,000 2,000 Tables per SELECT statement 256 256 Triggers per table3 Limited by number of objects in a database Limited by number of objects in a database UNIQUE indexes or constraints per table 249 nonclustered and 1 clustered 249 nonclustered and 1 clustered User connections 32,767 32,767 XML indexes 249 249 1 Network Packet Size is the size of the tabular data stream (TDS) packets used to communicate between applications and the relational Database Engine. The default packet size is 4 kilobytes (KB), and is controlled by the network packet size configuration option. 2 The maximum number of bytes in any index key cannot exceed 900 in SQL Server 2005. You can define a key using variable-length columns whose maximum sizes add up to more than 900, provided no row is ever inserted with more than 900 bytes of data in those columns. In SQL Server 2005, you can include nonkey columns in a nonclustered index to avoid the maximum index key size of 900 bytes. For more information, see Index with Included Columns. 3 Database objects include objects such as tables, views, stored procedures, user-defined functions, triggers, rules, defaults, and constraints. The sum of the number of all objects in a database cannot exceed 2,147,483,647. 4 Although a table can contain an unlimited number of FOREIGN KEY constraints, the recommended maximum is 253. Depending on the hardware configuration hosting SQL Server, specifying additional foreign key constraints may be expensive for the query optimizer to process. 5 This value is for static lock allocation. Dynamic locks are limited only by memory. 6 If a stored procedure accesses more than 8 databases, or more than 2 databases in interleaving, you will receive an error. 7 If the table contains one or more XML indexes, the clustering key of the user table is limited to 15 columns because the XML column is added to the clustering key of the primary XML index. In SQL Server 2005, you can include nonkey columns in a nonclustered index to avoid the limitation of a maximum of 16 key columns. For more information, see Index with Included Columns. 8 SQL Server 2005 supports row-overflow storage which enables variable length columns to be pushed off-row. Only a 24-byte root is stored in the main record for variable length columns pushed out of row; because of this, the effective row limit is higher than in previous releases of SQL Server. For more information, see the "Row-Overflow Data Exceeding 8 KB" topic in SQL Server 2005 Books Online.

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

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

Μ Π Ρ Α Β Ο !!!!

ναι παίζει σε 10 λεπτα θα σου έχω άλλο post για αυτό

Επειδή ο φίλος Αθανάσιος το ζήτησε για να μην του χαλάσουμε το χατήρι. Αποθηκεύουμε το παρακάτω script σε ένα άρχειο στο δίσκο μας πχ. backup.sql declare @weekday char(3) declare @command varchar(2048) select @weekday=upper(left(datename(dw,getdate()),3)) set @command = 'backup database $(dbname) to disk =''$(backupPath)\$(backupFileName)_'+@weekday+'.bak' + ''' with init' exec (@command) και μετά με το sqlcmd εργαλείο του SQL Server από command line γράφουμε το εξής C:>sqlcmd –E –i backup.sql –v dbname=”” backupPath=”” backupFileName=””

Πριν από λίγο ένας συνεργάτης μου, που έχει πολλούς πελάτες με ERP που είναι σε SQL Server μου ζήτησε να παίρνει backup σε ημερήσια εβδομαδιαία βάση αυτοματοποιημένα. Δηλαδή ένα backup για κάθε database (full βεβαια) κάθε μέρα της εβδομάδας, και την επόμενη εβδομάδα να γράφει πάνω στο προηγούμενο της αντίστοιχης ημέρας. Η λύση είναι απλή Πάμε και φτιάχνουμε ένα job στον SQL Server Agent, και σε αυτό, στο ένα και μοναδικό step βάζουμε το παρακάτω script: declare @weekday char(3) declare @dbname varchar(50) declare @backupPath varchar(1024) declare @backupFileName varchar(128) declare @command varchar(2048) set @dbname ='' set @backupPath ='' set @backupFileName='' select @weekday=upper(left(datename(dw,getdate()),3)) set @command = 'backup database ' + @dbname + ' to disk=''' + @backupPath +'\' +upper(@backupFileName)+'_'+@weekday+'.bak' + ''' with init' exec (@command) Αλλάζουμε τις τιμές στις μεταβλητές @dbname, @backuPath, @backupFileName, με αυτές που θέλουμε και προγραμματίζουμε το job αυτό να τρέχει κάθε μέρα στην ώρα που θέλουμε. Με αυτή την υλοποίηση έχουμε καθημερινό backup για την κάθε ημέρα της εβδομάδας σε ξεχωριστά αν ήμερα devices. Καλά database backup!

Εδώ και καιρό ήθελα να ασχοληθώ και να γράψω ένα άρθρο με αυτό το θέμα. Ένα θέμα το οποίο προσωπικά θεωρώ ότι είναι από τα καλύτερα και δυνατότερα κομμάτια του SQL Server. Με το που το είδα στον SQL Server 2005 (εδώ εμφανίστηκε για πρώτη φορά) έκανα σαν μωρό παιδί που του πήρανε καινούργιο παιχνίδι. Και αυτό γιατί όπως οι περισσότεροι γνωρίζεται είμαι στην μεριά των developers. Από το παρελθόν (21 χρόνια είμαι επαγγελματικά στο χώρο της πληροφορικής) έχω ασχοληθεί με distributed applications, queuing system, asynchronous systems programming. Οι εμπειρίες μου σε μερικές περιπτώσεις είναι τραυματικές με τέτοια συστήματα όπως επίσης και οι χιλιάδες γραμμές κώδικα που έχω γράψει για να υλοποίησω τέτοιες λύσεις. Κυρίως θα ήθελα να τονίσω ότι για να υλοποιηθούν τέτοιες λύσεις θα πρέπει να κάνεις να δουλέψουν σωστά πολλά διαφορετικά εργαλεία και τεχνολογίες. Όταν πρωτοείδα τον Service Broker είπα μέσα μου εδώ έχει "ψωμί". Αυτό το "ψωμί" θα προσπαθήσω να το μοιραστώ μαζί σας σε περισσότερα από δύο posts (γιατί το θέμα είναι μεγάλο και δύσκολο). Ο Service Broker είναι μια message-queuing τεχνολογία που είναι ενσωματωμένη στον SQL Server, η οποία επιτρέπει στους developers να κάνουν πλήρως intergate τον SQL Server σε distributed applications, μιας και τους παρέχει ένα asynchronous σύστημα για database to database communication. Τι σημαίνει αυτό; ‘Οτι με την χρήση του μπορείς από μια database να στείλεις μηνύματα σε μια άλλη database χωρίς να χρειάζεται να περιμένεις για reponse, πράγμα που σημαίνει ότι οι εφαρμογές θα συνεχίσουν να δουλεύουν ακόμα και όταν η δεύτερη δεν είναι διαθέσιμη. Ο Service Broker σαν ένα καθαρόαιμο message-queuing σύστημα δουλεύει με το να στέλνει μηνυματα (messages) τα οποία περιέχουν δεδομένα σε ένα QUEUE. Τα messages παραμένουν αποθηκευμένα στο Queue μέχρι το σύστημα να έχει τα διαθέσιμα resources ώστε να τα επεξεργαστεί κάνοντας τις ενέργειες που το καθένα απαιτεί. Έτσι με το Service Broker μπορώ να έχω καλύτερο scalability και resource management καθώς επίσης έχω και τις εγγυήσεις ότι κανένα message που έχει σταλθεί δεν θα χαθεί όπως επίσης και ότι αυτά επεξεργασθούν ακριβώς με την σειρά που μπήκαν στο queue. O Service Broker εγγυάται 100% αξιοπιστία κάτι που δύσκολα, για να μην πω καθόλου, θα το συνατήσεται σε άλλα παρόμοια συστήματα. Στον SQL Server 2008 έγιναν μερικές σημαντικές αλλαγές κυρίως στην διαχείρiση μέσα απο Management Studio, τις οποίες θα δούμε αργότερα Μέχρι εδώ καταλάβατε τι είναι ο Service Broker; Πιθανές απαντήσεις Α. ΝΑΙ, προχωράμε λοιπόν παρακάτω Β. ΟΧΙ, ξαναδιαβάζουμε το άρθρο από την αρχή Είμαι σίγουρος ότι πολλοί αναρωτιέστε που μπορείτε να χρησιμοποιήσετε το Service Broker. Ας δώσω μερικά παραδείγματα. Παράδειγμα Α Ας υποθέσουμε ότι έχουμε μια εταιρία που έχει δύο sites ( Α και Β ) όπου στο κάθε ένα έχει από μια βάση σε SQL Server. Έστω ότι έχω ένα transaction (distributed) το οποίο ξεκινάει από μια διαδικασια στην database του Α site και το οποίο ενημερώνει την τοπική database αλλα και την database στο Β site. Στην περίπτωση που το Β site δεν είναι διαθέσιμο τι θα γίνει με το transaction αυτό; Σωστά σκεφτήκατε θα γίνει rollback. Όμως αν αντί να ενημερώνω το B (με την λογική του distibuted transaction) έστελνα ένα μήνυμα με την πληροφορία που θέλω να πάει στον Β Service Broker (κατά την διάρκεια του transaction στο A site ) τότε ακόμα και όταν το Β site δεν είναι διαθέσιμο το transaction το οποίο έχω ξεκινήσει στο A site θα είναι committed. Απλά το Β site θα μάθει τι θα κάνει όταν είναι ξανα στον αέρα και αφού διαβάσει τα μηνύματα που του έχουν έρθει. Εδώ θα πρέπει να επισημάνω ότι αν για οποιοδήποτε άλλο λόγο το transaction στο A site γίνει rollback και το μήνυμα το οποίο στάλθηκε στο B site θα γίνει και αυτό rollback. Μήπως θυμάται κανείς σας τι έπρεπε να κάνετε στο κοντινό παρελθόν με COM+ και Messege Queue Service; Παράδειγμα Β Ας υποθέσουμε ότι θέλουμε να εκτελέσουμε ένα περίπλοκο batch ή query μέσα από την εφαρμογή μας το οποίο είναι και χρονοβώρο. Θα ξεκινούσαμε την εκτέλεση και θα περιμέναμε μέχρι να τελειώσει. Φανταστήτε να γινόνταν η εκτέλεση αυτή μέσα από μια εφαρμογή. Ο χρήστης που την εκτελούσε δεν θα μπορούσε να κάνει τίποτα άλλο μέσα από την εφαρμογή μέχρι αυτή να τελειώσει. Και για να προλάβω κάποιους που θα μου πουν ότι θα το έβαζαν να τρέξει σε ξεχωριστό thread και όλα καλά, απλά να τους θυμίσω τις γραμμές κώδικα που έχουν γράψει για να το πετύχουν αυτό. Σε αυτή την περίπτωση θα μπορούσα να στείλω ένα μήνυμα στον Service Broker και αυτός να αναλάβει την εκτέλεση του κάποια στιγμή που δεν θα υπάρχει φόρτος εργασίας. Εννοείται βέβαια ότι δεν υπάρχει περίπτωση να χρησιμοποιήσουμε τον Service Broker όταν θέλουμε real time transactions ή θέλουμε να έχουμε άμεσες απαντήσεις. Επίσης εννοείται ότι δεν εκτελούμε SELECT σε μια remote database. Γενικά τον Service Broker τον χρησιμοποιούμε σε σενάρια όπως Asynchronous triggers, Bulk processing, Distributed order processing. Με την παραπάνω παράγραφο στο μυαλό μας ελπίζω να σας έδωσα την πραγματική και πρακτική αξία του Service Broker. Αν πραγματικά το βρήσκετε ενδιαφέρον και προκείτε να το αξιοποιήσετε προχωρήστε παρακάτω, αλλιώς ζητώ συγνώμη για τον μέχρι τώρα χρόνο σας. ( ει, δεν θα φύγει κανείς, έχει και συνέχεια!!!) Ποία όμως είναι η Αρχιτεκτονική του Service Broker;. Βασικά είναι μια ξεκάθαρη client/server αρχιτεκτονική. Ένα Service Broker application αποτελείται από ένα client service το οποίο ξεκινάει ένα διάλογο και ένα receiving service το οποίο δέχεται και επεξεργάζεται τα μηνύματα. Κάθε service αντιστοιχίζεται σε ένα queue. O συνδετικός κρίκος ανάμεσα στο service και στο queue είναι το contract το οποίο ορίζει το τύπο του μηνυματος (message) το οποίο στέλνεται από το service στο queue. H ανταλλαγή μηνυμάτων μεταξύ δύο services λέγεται conversation dialog. Τί είναι το Service; Το service είναι ένα endpoint για το διάλογο του Service Broker. Αυτό είτε μπορεί να είναι ένα service το οποίο ξεκινάει τον διάλογο αυτό (initiating-sending service) με την αποστολή του μηνύματος, είτε είναι ο αποδέκτης (target-receiving service), αυτό δηλαδή που λαμβάνει το μήνυμα από το queue. Κάθε service αντιστοιχίζεται σε ένα queue και σε ένα contract το οποίο ορίζει το τύπο του μηνύματος το οποίο στέλενται στο queue, διασφαλίζοντας το conversation contract. Τί είναι το Queue; Είναι με απλά λόγια ο κουβάς με τα μηνύματα (εντάξει δεν είναι χύμα στο κύμα αλλά επιτρέψετε μου για χάρη ευκολίας και αστείου να το λέω έτσι). Κάθε queue μπορεί να έχει αντιστιχοιθεί με πολλά services (διαφορετικά, μην ξεχνιώμαστε). Ακόμα κάθε queue μπορεί να συνδεθεί με μια stored procedure η οποία θα εκτελείται κάθε φορά που ένα νέο μήνυμα μπαίνει στον κουβά, δίνοντας μου την δυνατότητα να επεξεργάζομαι το μήνυμα άμεσα (θεικό ε;). Όμως μπορώ να έχω και διαφορετικούς τρόπους επεξεργασίας των μηνυμάτων όπως π.χ. χρησιμοποιόντας τον SQL Server Agent και τα jobs του. Επίσης κάθε queue μπορώ να το έχω active ή όχι χωρίς να πειράζω την όλη υλοποίηση μου (σαν να ήταν ένα service του λειτουργικού). Στο σημείο αυτό θα ήθελα να δώσω μερικές χρήσιμες, πιστεύω, παρατηρήσεις για το queue. · Εάν το sending και το receiving service είναι στο ίδιο SQL Server instance τότε μπορούν να μοιράζονται το ίδιο queue, αλλιώς διαφορετικά queues. · Εάν το receiving queue είναι σε άλλο SQL Server instance ή δεν είναι για κάποιο λόγο ενεργό (active), το μήνυμα θα πρέπει να μπαίνει στο transmission queue για της βάσης όπου το sending service ανήκει. Αυτό ισχύει και αντίστροφα. Χρησιμοποιόντας την view sys.transmission_queue μπορούμε να δούμε τα εκκρεμή μηνύματα. Τί είναι το Message; Κάθε μήνυμα είναι στην ουσία μια γραμμή στο queue. To format του ορίζεται από το τύπο του μηνύματος (message type) από το contract που υπάρχει ανάμεσα σε δύο services. Μπορεί να είναι empty, well-formed XML, XML το οποίο είναι valid ως προς κάποιο σχήμα ή να περιέχει binary data. Τί είναι το Dialog Conversation; Αντιπροσωπεύει την ανταλλαγή των μηνυμάτων μεταξύ δύο services. Τα μηνύματα μέσα σε ένα τέτοιο διάλογο μπαίνουν στο queue με την σειρά με την οποία στάλθηκαν. Ο διάλογος σταματάει όταν κάποια από τις εφαρμογές που συμμετέχουν σε αυτόν σταματήσει την συμμετοχής της είτε εκτελώντας την END CONVERSATION εντολή είτε υπάρχει error. Εάν δεν χρησιμοποιήσουμε την παραπάνω εντολή ο διάλογος παραμένει ανοικτός στην database που ανήκει. Με την sys.conversation_endpoints μπορώ να δω τους ενεργούς διαλόγους. Κάθε διάλογος διασφαλίζει τα παρακάτω: 1. Guaranteed delivery Ο Service Broker είναι ένα reliable messaging system. Αυτό σημαίνει ότι ο αποστολέας του μηνύματος είναι σίγουρος ότι ο παραλήπτης θα πάρει το μήνυμα αυτό ακόμα και αν κατά την διάρκεια της αποστολής δεν είναι διαθέσιμος. 2. Long-lived Τα dialogs συνήθως ζουν για μερικά δευτερόλεπτα, αλλα μπορούν να ζήσουν και χρόνια ολοκλήρα εφόσον έχω long-running business processes. 3. Exactly once (αυτό μου αρέσει πολύ) Η αποστολή του μηνύματος μέσα από τον διάλογο στον Service Broker μου εγγυάται την μοναδικότητα του μηνύματος. Δηλαδή, ακόμα και αν το initiator service πρέπει να ξαναστείλει το ίδιο μήνυμα επειδή κάτι πήγε στραβά, τότε και τα δυο θα πάνε στον παραλήπτη αλλά μόνο το ένα από τα δυο θα γίνει processes. To άλλο αυτόματα θα διαγραφεί. ( ρε παιδία δεν καιρός να δούμε τον exchange server σε SQL Server database;) 4. In-order delivery Διασφαλίζει ότι τα μηνύματα θα παραληφθούν με την ίδια σειρά που εστάλησαν. 5. Persistence Ένας Service Broker dialog επιβιώνει μετά από restart του database server, επειδή τα messages και οι dialogs είναι persisted απευθείας στην database. Αυτό σημαίνει ότι ακόμα όλα τα l open dialogs αλλά και τα unprocessed messages είναι persisted αυτόματα και γίνονται ξανά διάθεσιμα όταν ξεκινήσει ξανά το database engine service!!!. Τί είναι τα Conversation Groups; Κάθε conversation group εμπεριέχει έναν ή περισσότερους διαλόγους και επιτρέπει στον Service Broker εύκολα να βρήσκει τα conversations που εμπλέκονται σε μια συγκεκριμένη εργασία. Η σημασία τους είναι τεράστια και αυτό διότι εαν πχ μια εφαρμογή στέλνει ή παίρνει ένα μηνυμα ο SQL Server κλειδώνει το group στο οποίο το μήνυμα ανήκει με σκοπό να παραγματώσει αυτό που είπαμε παραπάνω το EOIO delivery (exactly once in order). Τί είναι το Contract; To contract ορίζει τον τύπο του μηνύματος που το service χρησιμοποίει για να πραγματώσει την διαδικασία. Είναι η συμφωνία μεταξύ δύο services για το τι το κάθε ένα παίρνει και στέλνει στην επικοινωνία μετάξυ τους . Επίσης διασφαλίζει ότι μόνο οι τύποι των μηνυμάτων που έχουν ορισθεί στο contract θα γίνουν processes. Τί είναι το Service Broker Endpoint; Εάν δύο services σε ένα conversation είναι σε διαφορετικά instances του SQL Server χρειάζεται να δημιουργήσουμε ένα Service Broker endpoint το οποίο θα δέχεται τα incoming and outgoing TCP/IP connections σε συγκεκριμένη πόρτα. 'Ενα SQL Server instance μπορεί να έχει ένα και μόνο ένα Service Broker endpoint το οποίο γίνεται shared σε όλα τα services στο instance αυτό. Τί είναι τα Remote Service Bindings; Τα Remote Service Bindings χρησιμοποιούνται για να ορίσουμε το security context με το οποίο το initiating service συνδέεται στο remote service το οποίο είναι σε διαφορετικό instance του SQL Server. Τα Remote Service Binding χρησιμοποιούν certificate το οποίο δένεται με συγκεκριμένο database user account για να συνδεθούμε στο remote instance. Τί είναι τα Routes; Ο Service Broker χρησιμοποιεί τα routes για να εντοπίσει το service με το οποίο θα στείλει το μήνυμα. Εάν δεν υπάρχει κάποιο route το οποίο να είναι συνδεδεμένο με το το service τοτε by default ο Service Broker θα κάνει παράδοση του μηνύματος στο τρέχων instance. Ένα route περιέχει το όνομα του service με το οποίο γίνεται η σύνδεση, το ID του Service Broker instance το οποίο κάνει host το service, και το network address του remote Service Broker endpoint. Εδώ λέω να σταματήσω το πρώτο μέρος. Ελπίζω το θέμα αυτό να σας αρέσει. Περιμένω τα σχόλια σας για αυτό.

Σου είπα στην άδεια θα γίνει αυτό!. Μέχρι τότε οι "ταρζανίες" θα είναι σε ημερήσια βάση.

Επειδή δουλεύω συνεχεια με virtual μηχανές και επειδή πολλές φορές θέλω ένα αρχείο απο αυτές όταν είναι κλειστές . Εψαξα και βρήκα αυτό http://blogs.msdn.com/virtual_pc_guy/archive/2006/09/01/734435.aspx Αλλά και αυτό το οποίο έχει περισσότερες λεπτομέρειες http://www.petri.co.il/mounting-vhd-files-with-vhdmount.htm Αλλα και αυτό το οποίο έχει μια άλλη προσέγγιση http://blogs.technet.com/daven/archive/2006/12/15/vhdmount-without-virtual-server.aspx

Πρόσφατα με έναν συνεργάτη μου που είναι dealer μια ελληνικής εταιρίας που έχει ERP αντιμετωπίσαμε το παρακάτω πρόβλημα όταν πήγαμε να εγκαταστήσουμε τον SQL Server 2005 Standard Edition σε pc που είχε εγκατεστημένο Window XP Pro Ελληνικό. Σε συνεργασία μαζί του (ευχαριστώ Δημήτρη) σας παρουσιάζουμε την λύση. Κατά την στιγμή της εγκατάστασης του SQL Server 2005 ή 2008 παίρνουμε το παρακάτω μήνυμα λάθους στο σημείο που πάει να ενημερώσει τον MSXML Parser. The Windows Installer service cannot update the system file C:\WINDOWS\system32\msxml6r.dll because the file is protected by Windows. You may need to update your operating system for this program to work correctly Αυτό γίνεται διότι η εγκατάσταση του SQL Server 2005 και του 2008 πάει να γράψει στα παραπάνω αρχεία αλλά επειδή είναι File protected δεν σε αφήνει. Αυτό έχει συμβεί με την εγκατάσταση του SP3 των Windows XP Pro ελληνικά διότι η Microsoft τα έχει ενσωματώσει στον κώδικά της. Η λύση κατόπιν επικοινωνίας με την Microsοft είναι η ακόλουθη : Απεγκατάσταση του MSXML 6 Parser με το utility που θα βρείτε στο παρακάτω link :http://download.microsoft.com/download/e/9/d/e9d80355-7ab4-45b8-80e8-983a48d5e1bd/msicuu2.exe Κατόπιν πάμε στην Registry και στο σημείο HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon όπου βρίσκουμε την μεταβλητή SFCDisable (REG_DWORD) και από 0 την κάνουμε 1 Κάνουμε την εγκατάσταση του SQL Server (θα μας ξαναβγάλει το μήνυμα λάθους αλλά πατάμε ok) και όλα πάνε καλά. Κάνουμε restart και ελέγχουμε ξανά την registry να έχει πάλι η μεταβλητή την τιμή 1 (εάν έχει γίνει 0 την αλλάζουμε). Εγκαθιστούμε το SP2 ή το SP3 του SQL2005 και ξανακάνουμε restart. Στο τέλος ελέγχουμε την μεταβλητή στην registry να είναι 0. Το link της Microsoft για τα παραπάνω είναι το ακόλουθο : http://support.microsoft.com/kb/222473 Εάν τα Windows XP Pro με SP3 είναι αγγλικά δηλαδή ίδια γλώσσα με τον SQL Server δεν ισχύουν τα παραπάνω.

όντως θα έπρεπε να πάει εκει, σε ευχαριστώ για την επισήμανση θα το λάβω υπόψην μου την επόμενη φορά

Όλοι ξέρουμε το pagefile του λειτουργικού και την χρηστικότητα του. Όμως ποιό είναι το ιδανικό μέγεθος του σε ένα server που έχει εγκατεστημένο SQL Server; Πρέπει το Pagefile να είναι 1,5 φορές μεγαλύτερο από την φυσική μνήμη του server. Εάν έχω ή πρόκειτε να χρησιμοποιήσω full-text search τότε πρέπει να είναι τουλάχιστον τρεις φορές μεγαλύτερο από την φυσική μνήμη του server. Για ακόμα καλύτερα αποτελέσματα καλό θα είναι το pagefile να είναι σε ξεχωριστό φυσικό από αυτό του λειτουργικού.

Στον SQL Server 2005, και φυσικά υπάρχει και στο SQL Server 2008, πρωτοεμφανίστηκε μια νέα system database η Resource Database. Η database αυτή περιέχει όλα τα read-only critical system tables, metadata, και stored procedures τα οποία ο SQL Server χρειάζεται για τρέξει. Δεν περιέχει πληροφορίες για το SQL Server instance ή για τις databases σας, και αυτό γιατί δημιουργήται κατά την διαδικασία εγκατάστασης του SQL Server ή όταν εγκαταστήσουμε κάποιο service pack. Περιέχει δε όλα τα objects (table, stored procedures) τα οποία χρησιμοποιούμε σε όλες τις δικίες μας databases. H Resource Database βρήσκεται στο directory DATA που έχουμε στήσει τον SQL Server και το όνομα των αρχείων της είναι mssqlsystemresource τόσο για το .mdf όσο και για το .ldf. Εάν έχω πολλά SQL Server instances για κάθε ένα από αυτά έχω και διαφορετική Resource Database. Την Resource Database δεν μπορούμε να την δούμε μέσα από τον Management Studio και δεν μπορούμε να την αλλάξουμε. Σε πολύ ειδικές περιπτώσεις και μόνο με συμβουλή του Microsoft Support επιτρέπεται να γίνει κάτι τέτοιο. Την συγκεκριμένη database δεν την βάζουμε σε encrypted ή compressed drive, διότι αυτό μπορεί να οδήγήσει σε upgrade ή performance issues. Όμως ποιά είναι πρακτική αξία αυτής της system database; Στον SQL Server 2000 όταν κάναμε upgrade αυτόν με κάποιο patch ή service pack, παρατηρούσαμε ότι έπρεπε να τρέξουν κάποια μεγάλα scripts τα οποία στην ουσία έκαναν drop και recreate system objects. Εκτός του ότι η συγκεκριμένη διαδικασία ήταν μεγάλη σε χρόνο δεν μας έδινε την δυνατότητα να κάνουμε rollback στην προηγούμενη έκδοση που είχαμε. Στους SQL Servers 2005 & 2008 κάτι τέτοιο δεν γίνεται και αυτό γιατί είτε ρίχνουμε patch είτε service pack αυτό στην ουσία κάνει override την υπάρχουσα Resource Database. Την οποία αν την έχουμε πάρει αντίγραφο πριν την εγκατάσταση του patch ή του service pack διασφαλίζουμε την εύκολη επιστρoφή μας στην προηγούμενη έκδοση.

Πριν ξεκινήσω να περιγράφω το συγκεκριμένο εργαλείο, οφείλω να καταθέσω την άποψη μου γι’ αυτό. ΕΙΝΑΙ ΚΑΤΑΠΛΗΚΤΙΚΟ!!!. Όσοι έχετε ασχοληθεί από παλία με τον SQL Server, προσωπικά ασχολούμαι από την έκδοση 6.0 (1996), θα έχετε παρακολουθήσει την εξέλιξη του συγκεκριμένου εργαλείου. Σε κάθε έκδοση είχαμε κάποιες βελτιώσεις. Όμως στην έκδοση του SQL Server 2008 πιστεύω ότι έχουμε τις περισσότερες αλλά και τις σημαντικότερες βελτιώσεις. Eίναι μια διαφορετική υλοποίηση του εργαλείου που δίνει μια πληρέστερη εικόνα τόσο στον Database Admin όσο και στον Database Developer. Ας ξεκινήσω λοιπόν την περιήγηση στο εργαλείο αυτό. Πρώτη αλλαγή είναι το πως τον ξεκινάς. Δεν είναι πλεόν στο Management του SSMS (SQL Server Management Studio). Αλλά πρέπει να κάνεις δεξί κλικ στον server στον Object Explorer και να επιλέξεις την επιλογή Activity Monitor από το menu επιλογών. Μετά από αυτο θα δούμε το νέο Activity Monitor Όπως θα δείτε υπάρχουν τέσσερα γραφήματα τα οποία δείχνουν % Processor Time Το ποσοστό του χρόνου που έχει διανυθεί και τον οποίο ο επεξεργαστής έχει δαπανήσει για να εκτελέσει non-idle threads για τον SQL Server σε όλες τις CPUs. Waiting Tasks Ο αριθμός των tasks τα οποία περιμένουν πόρους είτε του επεξεργαστή, είτε για Ι/Ο, είτε για μνήμη. Database I/Ο Το transfer rate σε MB/Sec για την μεταφορά των δεδομένων είτε από την μνήμη στον δίσκο, είτε από το δίσκο στη μνήμη, είτε από δίσκο σε δίσκο. Batch Requests/sec Ο αριθμός των batches που έχουν σταλθεί στον SQL Server. Ακριβώς κάτω από τα γραφήματα υπάρχουν τέσσερεις λίστες Processes Εδώ βλέπουμε κάθε connection που έχει γίνει στον SQL Server και τι ακριβώς κάνει. Η λίστα περιέχει τις εξής πληροφορίες Session ID Ο μοναδικός αριθμός που παίρνει κάθε connection το γνωστό SPID. Αν δείτε δίπλα του μια κλεψύδρα εύκολα θα καταλάβετε ότι κάτι περιμένει ή είναι μπλοκαρισμένο από κάποιο άλλο connection. User Process Flag Δείχνει τα αν το συγκεκριμένο process είναι internal (τιμή 0) ή user (τιμή 1). By default δείχνει μόνο τα user αλλά μπορείτε να το αλλαξετε πατώντας το drop down που υπάρχει στο header της κολώνας. Υπάρχει και η τιμή All που τα δείχνει όλα. Login Το login name με το οποίο το συγκεκριμένο process έχει γίνει. Database Η τρέχουσα database στην οποία το connection είναι συνδεδεμένο. Task State Δείχνει εάν το process είναι ενεργό ή όχι. Εδώ μπορώ να έχω τις εξής τιμές Done: Ολοκλήρωση Pending: Το process περιμένει ένα worker thread Runnable: Κάτι έχει κάνει λίγο πριν αλλά αυτή την στιγμή δεν κάνει τίποτα αλλά είναι ακόμα συνδεδεμένο. Running: Κάτι κάνει αυτή την στιγμή Suspended: Το process αν και έχει δουλειά να κάνει, έχει σταματήσει γιατί κάτι το εμποδίζει να συνεχίσει. Δες το γιατί από την κολώνα Wait Type. Σχόλιο: Διευκρίνηση για το αφεντικό, αυτό δεν δείχνει αν χρήστης το φυσικό πρόσωπο δηλαδή κοιμάτε ή όχι πάνω στο πληκτρολόγιο του. Το λέω γιατί κάποιος πελάτης, μου είπε κάτι τέτοιο στο παρελθόν!!!. Command Δείχνει το command type (πχ SELECT, DBCC, INSERT, AWAITING COMMAND,…) το οποίο εκτελείτε. Προσοχή δεν δείχνει το πραγματικό command. Εαν θέλετε να δείτε το πραγματικό κάντε δεξί κλικ και επιλέξτε Details. Application Δείχνει την εφαρμογή με την οποία έχει γίνει το connection. Αυτό μπορεί να ορισθεί από τον developer πάνω στο connection string με το keyword Application Name. Wait Time (ms) Εαν το process είναι bloked δείχνει τον χρόνο που είναι σε αναμονή σε milliseconds αλλιώς δείχνει 0. Wait Type Δείχνει το event το οποίο περιμένει το process για να συνεχίσει. Wait Resource Δείχνει το resource το οποίο περιμένει το process να ελευθερώθεί για να συνεχίσει. Blocked By Δείχνει το SPID (Session ID) το οποίο έχει μπλοκάρει το process αυτό. Head Blocker Εαν η τιμή είναι 1 αυτό σημαίνει ότι το Session ID που φαίνεται στην Blocked By κολώνα είναι ο επικεφαλής στην αλυσίδα των μπλοκαρισμάτων. Memory Use (KB) Δείχνει το ποσό της μνήμης η οποία χρησιμοποιείται από το process αυτό. Host Δείχνει το computer name από όπου έχει γίνει το connection αυτό. Workload Group Δείχνει το όνομα του Resource Governor workload group για το query αυτό. Resource Waits Η λίστα αυτή δείχνει πληροφορίες για την αναμονή στα resources και περιλαμβάνει τις εξής πληροφορίες: Wait Category Είναι οι κατηγορίες που συγκεντρώνονται για τα wait type statistics. Κάτι αντίστοιχο μπορώ να πάρω με την dmv sys.dm_os_wait_stats. Wait Time (ms/sec) Ο χρόνος wait time σε ms/sec για όλα τα task τα οποία περιμένουν κάποιο ή κάποια resources στην συγκεκριμένη κατηγορία από το τελευταίο update interval. Recent Wait Time (ms/sec) O σταθμικός μέσος του wait time ms/sec για όλα τα task τα οποία περιμένουν ένα ή περισσότερα resources στην κατηγορία από το τελευταίο update interval. Average Waiter Count Ο αριθμός των tasks που περιμένουν για κάποιο ή κάποια resources στην συγκεριμένη κατηγορία σε μια δεδομένη στιγμή. Cumulative Wait Time (sec) Ο συνολικός χρόνος που τα tasks πρέπει να περιμένουν για ένα ή περισσότερα resources στην κατηγορία από τοτε που ξεκίνησε ο SQL Server ή από τότε που εκτελέσθηκε τελευταία φορά ή DBCC SQLPERF. Data File I/O Η λίστα αυτή δείχνει πληροφορίες για τα database files των databases που υπάρχουν στον SQL Server, και περιέχει τις εξής πληροφορίες: Database Το όνομα της βάσης. File Name Το όνομα (φυσικό) του αρχειου της βάσης. MB/sec Read Το τελευταίο read activity, σε megabytes ανά second, για το database file. MB/sec Written Το τελευταίο write activity, σε megabytes ανά second, για το database file. Response Time (ms) Ο Μ.Ο του response time, σε milliseconds, για το τελευταίο read-and-write activity στο database file. Recent Expensive Queries Η λίστα αυτή δείχνει πληροφορίες για τα πιό ακριβά σε resources queries τα οποία έχουν τρέξει στον SQL Server τα τελευταία 30 sec. H πληροφορία βγαίνει από την ένωση των dmv sys.dm_exec_requests και sys.dm_exec_query_stats και περιλαμβάνει queries τα οποία είναι σε εξέλιξη αλλά και αυτά τα όποία έχουν τελειώσει μέσα στην χρονική περίοδο των 30 sec, και περιλαμβάνει τις εξης πληροφορίες: Query Το query statement το οποίο γίνεται monitor. Executions/min Τα executions ανα λεπτό για το query. CPU (ms/sec) Η χρήση της CPU από το query Physical Reads/sec Η χρήση ανα second των physical reads από το query. Logical Writes/sec Η χρήση ανά second των logical writes από το query. Logical Reads/sec Η χρήση ανά second των logical reads από το query. Average Duration (ms) Η μέση διάρκεια εκτέλεσης του query σε milliseconds. Plan Count O αριθμός των cached query plans για αυτό το query. Ένας μεγάλος αριθμός δείχνει ότι χρειάζεται να στρέψουμε την προσοχή μας στο query αυτό.

Σήμερα το πρωί σε μια συνάντηση που είχαμε όλοι οι Έλληνες MCTs ένας συνάδελφος μου έκανε μια ερώτηση. “Θέλω να καταγράφω τα events που γίνονται σε μια βάση στο Windows Event Log γιατί θέλω να τα βλέπω από το MOM;” Η απάντηση σε αυτό είναι η παρακάτω, όμως θα πρέπει να επισημάνω ότι είναι για SQL Server 2005 μιας και στον SQL Server 2008 δεν υπάρχει η ανάγκη να κάνουμε κάτι τέτοιο μιας και υπάρχει build-in δυνατότητα την οποία υπόσχομαι να παρουσιάσω σε ένα άλλο μου post. Η προσέγγιση θα μπορούσε να γίνει και αλλιώς πχ με Event Notifications αλλά επέλεξα την παρακάτω λύση λόγο της απλότητας της. Για την υλοποίηση της λύσης, η οποία είναι draft και μπορεί με την βοήθεια σας να γίνει καλύτερη, θα αξιοποιήσω δύο πράγματα. Το πρώτο είναι οι DDL Triggers και το δεύτερο η extented stored procedure xp_logevent. Έτσι σε κάθε database που θέλω τα event της να καταγράφονται στο windows event log δημιουργούμε τον παρακάτω ddl trigger. Θα πρέπει να τονίσω ότι καταγράφονται μόνο τα DDL statements και όχι τα DML statements. CREATE TRIGGER WriteToEventLog ON DATABASE FOR DDL_DATABASE_LEVEL_EVENTS AS DECLARE @ed XML DECLARE @logmsg char(255) SELECT @ed = EVENTDATA() -- ΕΠΕΛΕΞΑ ΝΑ ΦΕΡΝΩ ΜΟΝΟ ΤΟ T-SQL COMMAND -- ΑΛΛΑ ΜΠΟΡΕΙΤΕ ΝΑ ΔΕΙΞΕΤΕ ΚΑΙ ΑΛΛΑ ΣΤΟΙΧΕΙΑ -- ΠΟΥ ΥΠΑΡΧΟΥΝ ΣΤΟ XML ΠΟΥ ΕΠΙΣΤΡΕΦΕΙ Ο TRIGGER -- ΜΕΣΩ ΤΗΣ EVENTDATA FUNCTION SET @logmsg = @ed.VALUE('(/EVENT_INSTANCE/TSQLCommand/CommandText[1]','char(255)') EXEC xp_logevent 50001,@logmsg,'WARNING' go Περιμένω τα σχόλια σας.

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

Αντε να δουμε...

Είστε σίγουροι ότι έχετε πάρει έστω και μια φορά όλες τις databases σας backup; Ειδικά εσείς αγαπητοί συνάδελφοι που έχετε πολλές databases είστε σίγουροι; Η απάντηση στο ερώτημα αυτό είναι η παρακάτω stored procedure η οποία θα σας επιστρέψει αμέσως όλες τις database που έχετε ξεχάσει να πάρετε backup. create proc dbo.spUnbackupedDbs @backup_type char(1)='D', @time_span_days int=5 as -- Created by Antonios Chatzipavlis -- -- This stored procedure returns all databases in a server -- ( except model and tempdb ) at which I have not take any backup -- for a specific days from the current day -- -- Parameters -- -- @backup_type : defines the backup type -- VALID VALUES -- 'D' : Full Backup (DEFAULT VALUE) -- 'I' : Diffential -- 'L' : Transaction Log -- 'F' : File or Filegroup -- 'G' : File Diffential -- 'P' : Partial -- 'Q' : Partial Differential -- -- @time_span_days : defines the amount of days ( DEFAULT VALUE is 5 DAYS ) select a.[name] as database_name from master.dbo.sysdatabases a left join msdb.dbo.backupset b on a.[name] = b.database_name and datediff(day,b.backup_finish_date,getdate()) and b.type=@backup_type where a.[name] not in ('model','tempdb') and b.database_name is null go Δημιουργήστε πρώτα την stored procedure τρέχοντας το παραπάνω script και εφόσον όλα πάνε καλά εκτελέστε την όπως παρακάτω exec spUnbackupedDbs

Καλησπέρα ίσως αυτό σε βοηθήσει να καταλάβεις το γιατί http://autoexec.gr/blogs/antonch/archive/2009/06/30/the-sql-server-operating-system-sqlos-1.aspx Φιλικα