antonch

χρυσόστομε πεστα

Προσωπικά νομίζω ότι είναι πολυ φασαρία για το τίποτα. Κάθε σοβαρός asp.net developer δεν αφήνει κλειστά τα custom errors ειδικά άμα έχει παρακολουθήσει σεμινάρια asp.net από την έκδοση 1.0 μιλάνε για αυτό. Επίσης όλοι οι IIS Admins αυτό το κλείνουν όπως και να έχει. To συγκεκριμένο tag παίρνει 3 τιμές στο mode property Mode=”On” Αυτό σημαίνει ότι αν χτυπήσει κάποιο unhandled exception θα εμφανιστεί η σελίδα που έχει ορισθεί στο defaultRedirect. Mode=”Off” Εδώ είσαι τελείως ξεβράκωτος και αυτό σημαίνει ότι ότι λάθος χτυπήσει θα εμφανιστεί μια σελίδα με όλες τις λεπτομέρειες για αυτό (εμφανίσει όλο το stacktrace property του exception). Αυτή η τιμή είναι μόνο για όσο κάνουμε development και είναι για εξυπηρέτηση μας όχι για την παραγωγή. Στη παραγωγή ΠΟΤΕ δεν την βάζουμε. Αλλιώς είναι σαν παρακαλάς τον Hacker του στέλνεις έτσι το μήνυμα: «Ανοίξαμε και σας περιμένουμε». Mode=”RemoteOnly” (default) Με αυτό αν σκάσει κάποιο exception τότε στον hacker θα βγει ένα μήνυμα Server exception που δεν θα λέει τίποτα περισσότερο από να αλλάξει αν θέλει να δει το exception να αλλάξει το Mode σε On πράγμα που φυσικά δεν έχει πρόσβαση να το κάνει. Αν όμως είσαι ο admin του IIS και έχει φυσική πρόσβαση σε αυτόν και πας τοπικά και χτυπήσει το site σου και σου σκάσει θα δεις κανονικά το exception σαν να το είχες off. Αλλά αυτό δεν είναι πρόβλημα μιας και είσαι ο admin του IIS. Αν μετά από όλα αυτά αυτό είναι security issue τι να πω. Ο Σκωτ καλά κάνει και το αναφέρει μιας και πρέπει να χτυπήσει το καμπανάκι σε μερικούς μερικούς. Από την άλλη όμως θα προλάβω μερικούς που θα πουν γιατί το άφησαν έτσι και η απάντηση μου είναι γιατί σαν developer θέλω να κάνω ευκολότερα την δουλειά μου. Αλλά ξέρω σαν υπεύθυνος που είμαι για αυτό που φτιάχνω ότι στην παραγωγή το κλείνω.

Eίναι εντυπωσικά γρήγορος και αυτό που προσωπικά μου αρέσει περισσότερο είναι το minimal ui που έχει. Επίσης μου άρεσει πολύ που σου δείχνει το πόσο κάθε add-in καθυστερεί την φόρτωση του. Δεν θα μιλήσω για το τι δυνατότητες έχει για μένα σαν developer αυτό είναι για άλλο forum

Φέτος για πρώτη φορά η PDC θα προβάλλεται ολόκληρη ζωντανά από το Redmond.

Δες περισσότερα εδω http://research.microsoft.com/en-us/projects/scholarlynk/ Αλλά το ωραίο είναι στο τέλος της σελίδα που δείχνει την Ελληνική συμμετοχή

Ένα απίστευτο video έχει αναρτηθεί εδώ, το οποίο με έκανε να γελάσω αρκετά σήμερα το βράδυ. Ελπίζω να κάνει και εσάς

Regardless of how much content is available to today's researchers, it loses value if it cannot be properly managed and shared. At this week's 14th European Conference on Research and Advanced Technology for Digital Libraries (ECDL) at Glasgow University in Scotland, Microsoft Research will present the prototype of ScholarLynk, a desktop solution designed to help researchers more effectively manage, organize, and share ideas and information. One of the main goals of ScholarLynk is to make scholarly data as easy to access and manage as one's personal music collection. Unlike other offerings, ScholarLynk doesn't lock the user into a particular tool or service. Instead, it bridges data silos by enabling the user to manage information across repositories and applications. http://blogs.msdn.com/b/msr_er/archive/2010/09/03/introducing-scholarlynk.aspx

στο it pro dev connections δεν θα πούμε για .net αλλά για SQL Server, αυτό θα το κάνουμε σε κάποιο acx event που θα έχουμε περισσότερη ώρα στην διάθεση μας

Πρέπει κάποια στιγμή να σας μαζέψω και να σας κάνω ένα σεμινάριο .net framework για admins

Επειδή από το 2000 ασχολούμαι με το .net και έχω γράψει αρκετές εφαρμογές θα σου πω ότι δεν νομίζω να φταίει το framework. Αυτή την στιγμή στο pc μου έχω όλα τα .net framework εγκατεστημένα από την έκδοση 1.0. Εξάλλου το 3.5 είναι extention του 2.0

O Σ. Τζόνσον έλεγε: « Η γνώση είναι δύο ειδών: είτε ξέρουμε το αντικείμενο είτε ξέρουμε πού να βρούμε πληροφορίες γι' αυτό.» ότι και να διαλέξετε το σίγουρο είναι ότι στο IT PRO | Dev Connection θα βρείτε και τα δύο.

The field of computer networking research has traditionally been challenged by the tension between relying on actual network traces for evaluation, and the privacy and security issues associated with releasing actual traces to researchers. While the traces are critical for conducing and assessing research on computer networks, the also contain a substantial amount of information about the participants in the trace. This information can be explicit (the contents of packets), or implicit (two known computers communicated with each other). The challenge of conducting research while preventing access to such sensitive information is important for the future of this, and other, research fields. Our observation, though we are hardly the first, is that much of the information required by analysts is ''aggregate"; it concerns large-scale statistics about the trace as a whole, rather than specific properties of individual packets. While this intuition is appealing, formal articulations of the distinction have only recently begun to emerge, one appealing example of which is Differential Privacy. Differential privacy formally requires that a computation depend only slightly on any one individual input record, while permitting substantial variation as a result of changes in large numbers of input records. While differential privacy is appealing, confirming that a computation provides differential privacy is challenging, most commonly done by hand, by experts, for small programs. Most networking trace analyses are not so simple. As part of our SIGCOMM 2010 paper titled "Differentially-Private Network Trace Analysis", we produced a toolkit and collection of analyses useful for network trace analysis. The tools were built on top of the Privacy Integrated Queries platform for differentially-private data analysis, and were selected to reflect several important types of network trace analyses. Note: the toolkit contains an updated version of PINQ which is not officially released. The official release of PINQ should be refreshed soon, but until then the version in the toolkit should be used. Αρχική δημοσίευση από το http://research.microsoft.com/en-us/projects/pinq/networking.aspx

http://research.microsoft.com/en-us/projects/cloudfaster/default.aspx

Πληροφορίες εδώ

Πριν από λίγο καιρό στο SQL Server Magazine διάβασα το παρακάτω το οποίο είναι αρκετά ενδιαφέρον μιας και την απάντηση την έχει δώσει ένας άνθρωπος που τον έχει φτίαξει ο Paul Randal, απολαύστε το Q: I’ve been wondering about the algorithm for generating log sequence numbers for transaction log records and I’m concerned that with a high enough workload it may be possible to run out of log sequence numbers. What happens in that case? A: There’s no need to worry as for all practical purposes it is not possible to run out of log sequence numbers. As a bit of background, a log sequence number is a three-part number used to uniquely identify a transaction log record – constructed from the sequence number of the virtual log file (VLF) containing the log record; the log block number within the virtual log file; the log record number within the log block. This isn’t really important, but what is important is that the VLF sequence number is a 64-bit number. Whenever a VLF is reused in the transaction log, the VLF sequence is increased by 1. So let’s do a little math… Imagine a transaction log with 65536 VLFs, each one a quarter megabyte in size (not a nonsensical situation, depending on how your transaction log is being managed – for more details on this and on transaction log internals, see Importance of proper transaction log size management). Each time the log is completely used and wraps around to the start, the VLF sequence number will increase by 65536, which is 2 to-the-power 16 (2^16). A 64-bit number can support 2^64 values. To be able to exhaust the 2^64 possible VLF sequence numbers, our example transaction log would have to wrap 2^64 / 2^16 = 2^48 times. That’s a lot of log wrapping. But how much transaction log does that equate to? Our example log is 65536 x 1/4MB in size, which is 16GB. To wrap that log 2^48 times, you’d need to generate 2^48 x 16GB of transaction log. Which equates to 4 billion petabytes (a petabyte = 1024 terabytes) of transaction log – quite an undertaking! Even being able to write that log out to an SSD capable of a sustained 600 MB/s, it would take 4 billion petabytes / 600 megabytes = approximately 240 million years to generate 4 billion petabytes of transaction log. As you can clearly see – no-one’s in any danger of running out of log sequence numbers!

http://research.microsoft.com/apps/pubs/default.aspx?id=132806

Σε συνέχεια από το PART I. Report Server Databases Στα SSRS έχουμε δύο databases τις ReportServer και ReportServerTempDB. ReportServer Database Σε αυτή την βάση αποθηκεύονται τα παρακάτω SSRS configuration Report definitions Report metadata Report history Cache policies Snapshots Resources Security settings Encrypted data Scheduling and Delivery Data Extension information Όπως είναι εύκολα κατανοητό η βάση αυτή είναι και η καρδία των SSRS και φυσικά η απώλεια της σημαίνει πολλά. Για αυτό το λόγο και της συμπεριφερόμαστε όπως σε όλες τις βάσεις παραγωγής, πχ παίρνουμε καθημερινό backup. Επίσης θα πρέπει να τονίσω ότι μπορώ να έχω άμεση πρόσβαση στα δεδομένα των πινάκων και φυσικά να αλλοιώσω αυτά. Αυτό όμως δεν είναι recommended αλλά ούτε και supported από την Microsoft. Επίσης θα πρέπει να τονισθεί ότι υπάρχει πάντα το ενδεχόμενο με κάποιο CU ή SP η δομή της βάσης να αλλάξει. ReportServerTempDB Database Αυτή η βάση είναι υπεύθυνη για την αποθήκευση των ενδιάμεσων διαδικασιών όπως των cached reports , sessions και execution data. Σε αντίθεση με την TempDB του SQL Server τα δεδομένα σε αυτή την βάση παραμένουν όταν γίνεται restart είτε ο SQL Server είτε τα SSRS. Σε τακτά χρονικά διαστήματα γίνεται διαγραφή των expired και orphan data. Αν και μπορούμε να σβήσουμε όλα τα δεδομένα μέσα από αυτή καλό είναι να γίνει αυτό. Αν και το μόνο που μπορεί να μας συμβεί είναι οι χρήστε που είναι σε διαδικασία να δούνε ένα report θα πάρουν μήνυμα ότι δεν μπορούν να διαβάσουν τον session state (rsExecutionNotFound). Σε αυτή την περίπτωση ο χρήστης θα πρέπει να ξαναεκτελέσει το report. Αλλαγή θέσης των Temporary Snapshots Εάν κάποιος θέλει να αλλάξει τον τρόπο που temporary snapshots αποθηκεύονται και αντί για την βάση να αποθηκεύονται σε directory θα πρέπει να ακολουθήσει τα επόμενα βήματα Να αλλάξει στο rsreportserver.config το WebServiceUseFileShareStorage και το WindowsServiceUseFileShareStorage σε True. Να ορίζει το path που θέλει αυτά να αποθηκεύονται στο FileShareStorageLocation. Υπάρχει βέβαια default value και είναι η C:\Program Files\Microsoft SQL Server\MSES10.MSSQLSERVER\Reporting Services\RSTempFiles. Τέλος θα πρέπει να επισημάνω ότι δεν χρειάζεται οι βάσεις αυτές να είναι στην ίδια μηχανή που έχω στήσει τα SSRS αλλά σε έναν άλλο SQL Server.

Οι περισσότεροι σχεδόν χρησιμοποιούν τα 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. Στην παρακάτω εικόνα συνοψίζονται όλα τα παραπάνω

Η Microsoft ανακοίνωσε την έλευση του BPA για τον SQL Server 2008 R2. Στην ανακοίνωση που έβγαλε αναφέρει για αυτό BPA is designed to allow Administrators to validate their SQL Server instances against Microsoft established best practices. It includes best practices validations for SQL Server, SQL Replication, Analysis Services, Integration Services, Reporting Services, and Setup. BPA examines your SQL Server instance with roughly 150 validations of system events, login permissions, SQL Metadata settings, error logs, and reports those items that don’t conform to best practices. For each non-compliant error or warning there are detailed descriptions of the best practice and instructions for becoming compliant. For more information and to download SQL Server 2008 R2 BPA go here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0fd439d7-4bff-4df7-a52f-9a1be8725591 Σύντομα θα ακολουθήσει αναλυτικό post μου που θα σας περιγράφω τα του BPA. Καλή αρχή να έχουμε μέχρι τις επόμενες διακοπές μας.

Γνωρίζοντας ότι μπορεί το παρόν post μου να μην είναι ενδιαφέρον ή να προσφέρει μια γνώση που δεν έχετε, εντούτοις το γράφω διότι πρέπει κάποια πράγματα να λέγονται όπως είναι και να μην υπάρχει μαύρες τρύπες ή διαφορετικές ερμηνείες, που δυστυχώς άκουσα σήμερα. Τι είναι λοιπόν ένα transaction; Είστε σε μια εκκλησία και βλέπετε ένα ζευγάρι να παντρεύεται. Όταν τελειώσει το μυστήριο του γάμου δεν υπάρχει κανένας που να αμφιβάλλει για το status του ζευγαριού αυτού. ΕΙΝΑΙ ΠΑΝΤΡΕΜΕΝΟΙ. Εάν όμως κατά την διάρκεια του μυστήριου συμβεί κάτι πχ η νύφη το σκάσει πάλι δεν υπάρχει καμία αμφιβολία για το status τους. ΔΕΝ ΕΙΝΑΙ ΠΑΝΤΡΕΜΕΝΟΙ. Αυτό στην ουσία είναι και ένα transaction αγαπητές κυρίες και αγαπητοί κύριοι. Τίποτα περισσότερο τίποτα λιγότερο. Οι σύμμαχοι λένε All Or Nothing, που σημαίνει ότι όλα θα γίνουν και θα φτάσω στο επιθυμητό status (ΕΙΝΑΙ ΠΑΝΤΡΕΜΕΝΟΙ-TRANSACTION IS COMMITTED) ή αν γίνει κάτι τότε όλα γυρνάνε στην προηγούμενη κατάσταση (ΔΕΝ ΕΙΝΑΙ ΠΑΝΤΡΕΜΕΝΟΙ – TRANSACTION ROLLBACKED) Ένα transaction υλοποίει – διέπεται από τα ACID properties που είναι τα αρχικό των λέξεων Atomicity – Consistency – Isolation – Durability. Atomicity σημαίνει ότι κάθε transaction πρέπει να είναι μια αυτόνομη εργασία που είτε θα γίνουν όλα όσα αυτή ζητάει να γίνουν είτε δεν θα γίνει τίποτα. Consistency σημαίνει ότι με την ολοκλήρωση του transaction όλα θα είναι σε μια consistent κατάσταση (είναι παντρεμένοι ή δεν είναι παντρεμένοι). Ενδιάμεσες καταστάσεις δεν υπάρχουν. Δεν υπάρχει ολίγο παντρεμένοι ή ολίγο δεν είναι παντρεμένοι. Isolation σημαίνει ότι οι αλλαγές που ζητάει ένα transaction να γίνουν πρέπει να είναι απομονωμένες από τις αλλαγές που κάποια άλλα transaction που εκτελούνται ταυτόχρονα κάνουν. Δηλαδή εάν για παράδειγμα κάποιος από το ζευγάρι που παντρεύεται είναι ήδη παντρεμένο το δικό μας transaction δεν θα προχωρήσει. Ξέρω τι θα ακούσω τώρα για τα ζευγάρια που είναι δίγαμα αλλά αυτό διώκεται ποινικά ξέρετε, έτσι και εδώ υπάρχουν νόμοι και κανόνες που ευτυχώς δεν παραβιάζονται. Επίσης για να προχωρήσει το δικό μας transaction όταν κάποιο ή κάποια άλλα έχουν ξεκινήσει θα πρέπει αυτά να τελειώσουν και να αφήσουν τα δεδομένα που και εμείς θέλουμε να πειράξουμε σε μια ξεκάθαρη κατάσταση. Durability σημαίνει ότι αφού το transaction μας έχει ολοκληρωθεί αυτό παραμένει ακόμα και αν το σύστημα μας έχει failure. Για να επιτευχθούν όλα τα παραπάνω υπάρχουν τα locks τα οποία έρχονται να τηρήσουν τους κανόνες που είπαμε, αλλά για αυτά σε άλλο post. Autocommit Transactions ή Implicit Transactions Στον SQL Server έχω τα Autocommit Transactions ή Implicit Transactions που είναι και η default συμπεριφορά για κάθε sql statement που εκτελείται. Δηλαδή εκτελώ ένα insert statement αυτό θα είναι committed εφόσον δεν υπάρχει κάποιο λάθος, ενώ αν παρουσιαστεί σφάλμα αυτό είναι rollbacked. Για όσους θέλουν να απενεργοποιήσουν την παραπάνω συμπεριφορά του SQL Server γιατί τους φαίνεται ότι δεν είναι σωστή (επειδή έτσι νομίζουν γιατί το έχουν δει αλλού) υπάρχει η δυνατότητα με την εφαρμογή του IMPLICIT_TRANSACTION setting π.χ SET IMPLICIT_TRANSACTIONS ONINSERT / UPDATE / DELETE COMMIT / ROLLBACK Explicit Transactions Εάν θέλεις να έχεις δικά σου ελεγχόμενα transactions τότε θα πρέπει να ξεκινήσεις ένα δικό όπως στο παράδειγμα που ακολουθεί BEGIN TRAN…. COMMIT / ROLLBACK Βέβαια θα πρέπει να είσαι προετοιμασμένος ώστε αν συμβεί κάτι να κάνεις rollback. Δεν θα σας κουράσω δείχνοντας σας πως αυτό γίνονταν πριν τον SQL Server 2005, θα σας δείξω πως γίνεται από τον 2005 και μετά που είναι και αρκετά πιο δομημένος τρόπος γραφής BEGIN TRY BEGIN TRAN …. COMMIT END TRY BEGIN CATCH ROLLBACK SELECT ERROR_NUMBER(), ERROR_MESSAGE() END CATCH Το θέμα φυσικά δεν εξαντλείτε εδώ είναι μεγάλο και θα επανέλθω σύντομα με ένα άλλο post που θα πηγαίνει περισσότερο σε βάθος.

SSMS Tools Pack είναι ένα add-in για τον Microsoft SQL Server Management Studio (SSMS) 2005, 2008, 2008 R2 αλλά και για τις Express versions. Τα έχει φτιάξει ένας SQL Server MVP o Mladen Prajdic και τα μοιράσει δωρεάν αλλά μπορείς να αφήσεις κάτι σε αυτόν για την προσπάθεια του Περιέχουν αρκετά ωραία πραγματάκια που σε μερικούς λοίπουν από το SSMS όπως: SQL Snippets Window Connection Coloring Query Execution History and Current Window History Format SQL Search Table, View or Database Data Copy execution plan bitmaps to clipboard or file Search Results in Grid Mode Generate Insert statements from resultsets, tables or database Regions and Debug sections Running custom scripts from Object Explorer CRUD stored procedure generation New query template General options Για να τα κατεβάζετε επισκευτείτε την παρακάτω σελίδα http://www.ssmstoolspack.com/Download

υποκλίνομαι στο ταλέντο του

Ψάχνοντας μέσα στα αρχεία μου σήμερα για κάτι άλλο ανακάλυψα μια λίστα την οποία είχα κάνει στο παρελθόν και η οποία δείχνει κάτι το οποίο είναι λίγο περίεργο στον SQL Server. Αυτό που είναι περιέργο είναι ότι σε όλα τα άλλα προιόντα της Microsoft όταν βάζει κάποιο service pack ή cummulative update μπορείς εύκολα μετά να καταλάβεις τι έχεις κάνει install πηγαίνοντας στο about ή δίνοντας μια εντολή. Στον SQL Server δεν είναι όμως τόσο απλά τα πράγματα. Μια εύκολη λύση είναι να εκτελέσεις το SELECT @@version το οποίο σου δίνει πληροφορίες όμως δεν λέει τόσο ξεκάθαρα τα πράγματα. Το μόνο που στην ουσία σου δίνει ακριβή πληροφορία είναι το Version number και εσύ πρέπει από αυτό να καταλάβεις τι έχεις εγκαταστήσει. Χωρίς την παρακάτω λίστα είσαι χαμένος από χέρι και ομολογώ ότι είχα καιρό να την ανανεώσω όμως αυτό ήταν το εύκολο μέρος. Θα συνεχίσω να την ενημερώνω στο παρόν post. Η λίστα μου περιέχει την έκδοση και το τι αυτή περιέχει και διορθώνει Version Περιέχει/Διορθώνει SQL Server 2008 R2 10.5.1720.0 SQL Server 2008 R2 CU2 10.5.1702.0 SQL Server 2008 R2 CU1 10.5.1600.1 SQL Server 2008 R2 RTM SQL Server 2008 10.00.2775 SQL Server 2008 SP1 CU8 10.00.2766 SQL Server 2008 SP1 CU7 10.00.2757 SQL Server 2008 SP1 CU6 10.00.2746 SQL Server 2008 SP1 CU5 10.00.2734 SQL Server 2008 SP1 CU4 10.00.2723 SQL Server 2008 SP1 CU3 10.00.2714 SQL Server 2008 SP1 CU2 10.00.2710 SQL Server 2008 SP1 CU1 10.00.2531 SQL Server 2008 SP1 10.00.1835 SQL Server 2008 RTM CU10 10.00.1828 SQL Server 2008 RTM CU9 10.00.1823 SQL Server 2008 RTM CU8 10.00.1818 SQL Server 2008 RTM CU7 10.00.1812 SQL Server 2008 RTM CU6 10.00.1806 SQL Server 2008 RTM CU5 10.00.1798 SQL Server 2008 RTM CU4 10.00.1787 SQL Server 2008 RTM CU3 10.00.1779 SQL Server 2008 RTM CU2 10.00.1763 SQL Server 2008 RTM CU1 10.00.1600 SQL Server 2008 RTM SQL Server 2005 9.00.4305 SQL Server 2005 SP3 CU10 9.00.4294 SQL Server 2005 SP3 CU9 9.00.4285 SQL Server 2005 SP3 CU8 9.00.4273 SQL Server 2005 SP3 CU7 9.00.4266 SQL Server 2005 SP3 CU6 9.00.4230 SQL Server 2005 SP3 CU5 9.00.4226 SQL Server 2005 SP3 CU4 9.00.4220 SQL Server 2005 SP3 CU3 9.00.4211 SQL Server 2005 SP3 CU2 9.00.4207 SQL Server 2005 SP3 CU1 9.00.4053 SQL Server 2005 SP3 GDR 9.00.4035 SQL Server 2005 SP3 9.00.3356 SQL Server 2005 SP2 CU17 9.00.3355 SQL Server 2005 SP2 CU16 9.00.3330 SQL Server 2005 SP2 CU15 9.00.3328 SQL Server 2005 SP2 CU14 9.00.3225 SQL Server 2005 SP2 CU13 9.00.3315 SQL Server 2005 SP2 CU12 9.00.3310 SQL Server 2005 Security Update 9.00.3301 SQL Server 2005 SP2 CU11 9.00.3294 SQL Server 2005 SP2 CU10 9.00.3282 SQL Server 2005 SP2 CU9 9.00.3257 SQL Server 2005 SP2 CU8 9.00.3239 SQL Server 2005 SP2 CU7 9.00.3233 SQL Server 2005 QFE Security Update 9.00.3228 SQL Server 2005 SP2 CU6 9.00.3215 SQL Server 2005 SP2 CU5 9.00.3200 SQL Server 2005 SP2 CU4 9.00.3186 SQL Server 2005 SP2 CU3 9.00.3175 SQL Server 2005 SP2 CU2 9.00.3161 SQL Server 2005 SP2 CU1 9.00.3152 SQL Server 2005 SP2 Hotfix 9.00.3077 SQL Server 2005 Security Update 9.00.3054 KB934458 9.00.3042.01 SQL Server 2005 "SP2a" 9.00.3042 SQL Server 2005 SP2 9.00.2047 SQL Server 2005 SP1 9.00.1399 SQL Server 2005 RTM SQL Server 2000 8.00.2039 SQL Server 2000 SP4 8.00.760 SQL Server 2000 SP3 8.00.534 SQL Server 2000 SP2 8.00.384 SQL Server 2000 SP1 8.00.194 SQL Server 2000 RTM SQL Server 7 7.00.1063 SQL Server 7.0 SP4 7.00.961 SQL Server 7.0 SP3 7.00.842 SQL Server 7.0 SP2 7.00.699 SQL Server 7.0 SP1 7.00.623 SQL Server 7.0 RTM SQL Server 6.5 6.50.416 SQL Server 6.5 SP5a 6.50.415 SQL Server 6.5 SP5 6.50.281 SQL Server 6.5 SP4 6.50.258 SQL Server 6.5 SP3 6.50.240 SQL Server 6.5 SP2 6.50.213 SQL Server 6.5 SP1 6.50.201 SQL Server 6.5 RTM

εαν η καταγραφη συμβαντων που μου εχουν τυχει στα 22 χρονια που ειμαι επαγγελματιας στο χωρο αυτο η εχω την τυχη να ακουω απο αξιολογους συναδελφους ριχνει ρην ποιοτητα του blog μου τοτε μαλλον θα πρεπει να αλλαξω επαγγελμα Ποτε δεν προσωποποιησα τις καταστασεις που αναφερω μιας και θεωρω οτι ειναι ευθυμες νοτες Με την ιδια λογικη θα επρεπε να τον θιγουν και οι ιστοριες του Ζαχαρια στο dnz και ισως και Αριστοφνικες κωμωδιες Οπως και να εχει σκοπος μου ειναι να συνεχισω να γραφω μαργαριταρια μιας και τα θεωρω οπως προειπα ευθυμη νοτα οσο και αν αυτο ριχνει την ποιοτητα οπως λεει ο αγαπητος Blackman

η Ιωαννα ειναι μια αξιολογη συναδελφος αν και δεν θελει να την λεω ετσι εγω την θεωρω συναδελφο με φοβερη επιμονη να μαθαινει το βαθος που υπαρχει πισω απο το καθε τι και που μισει να γραφει απλα εντολες δυστυχως ομως λογο φυσεως της εργασιας ερχεται αντιμετωπη με τετοιες καταστασεις