Jump to content

antonch

Administrators
  • Posts

    1030
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by antonch

  1. Χρόνια Πολλά σε όλους! Εύχομαι ο νέος χρόνος να φέρει υγεία, αγάπη και ευτυχία σε εσάς και τις οικογένειες σας. Αυτές τι μέρες βρήκα την ευκαιρία να διαβάσω αρκετά νέα βιβλία τα οποία είχα προμηθευτεί επί τούτου. Μέσα σε όλα αυτά ξεχώρισα τo παρακάτω εισαγωγικό σημειώμα που apriory με εκφράζει απόλυτα. Με το που το διάβασα πετάχθηκα από το καναπέ μου και αναφώνησα ΠΕΣΤΑ ΧΡΥΣΟΣΤΟΜΕ. Χαίρομαι ιδιαίτερα όταν αυτά που και εγώ πιστεύω και διδάσκω είναι σύμφωνα με τα λεγόμενα ανθρώπων που είναι έγκυροι και καταξιωμένοι στην επιστημονική κοινότητα. Ο εν λόγω κύριος είναι ο Paul Nielsen, SQL Server MVP με πάνω από 30 χρόνια φούρναρης εεε Database Specialist και συγγραφέας του SQL Server Bible http://www.sqlserverbible.com/. Ειδικά το υπογραμμισμένο κείμενο είναι κορυφαίο παράδειγμα για αυτούς που επιμένουν να θεωρούν την βάση σαν ένα κουβά. Απολαύστε το Any database can be evaluated on six basic criteria: usability, data integrity, scalability, extensibility, availability, and security. Of these database objectives, the first four are primarily driven by the design and development of the database. One of the best practices that serves as a root cause for each of the four design driven goals is the elegance of the database design itself. The trouble is that elegance of design can be an elusive creature—difficult to define, difficult to achieve, and difficult to teach. But we do know that at the core of every well-designed database are the principles of normalization. In the application development world, technologies are annual trends, but not so in the database world. Even after nearly 40 years, normalization—one grouping of things is one entity, one thing is one tuple, one fact is one attribute, and every attribute must describe the tuple—is still the foundation of database technology. In the quest for elegance of design, the concepts of generalization and data driven design augment, but don’t negate, normalization. The war cry of the data architect is still, “The key, the whole key, and nothing but the key!” I am concerned, however, that database development skills—database design, normalization, and T-SQL—seem to be a dying art. In many shops, the lone data architect is outnumbered 50 to 1 by developers who don’t respect the importance of data integrity. Managers listen to the crowd, and systems are designed for today rather than for next year, much less the next decade. The design methods and development tools used to encapsulate data should be at least as stable and live as long as the data. And data lasts a long, long time. Ask around, and see how many DBAs manage data that’s 10, 20, or 50 years old. Most do. The average lifecycle of a popular application development language is 3 to 5 years; a stored procedure written 20 years ago still runs (with maybe a slight tweak to the JOIN syntax). I picture the database as a granite rock that will last for an eon. Occasionally a UI developer comes along and paints a pretty chalk picture on the rock; it washes off and a few more UI developers add their pictures. They all wash off with time, but the rock remains. OK, it’s a stretch, and I do like a great UI, but the point is that any IT architecture should be founded on data integrity.
  2. BRAVO SOTIRIS!!! και έλεγα τι να διαβάσω τώρα που θα παω στο χωριό δίπλα στο τζάκι με τα λουκάνικα από αγριογούρουνο και τα τσίπουρα
  3. πες τα Ανδρέα!!! Το χρησιμοποιώ από την πρώτη έκδοση του και έχω φτιάξει ένα γιγάντιο book. To feature που μου αρέσει περισσότερο είναι ότι μπορώ να πάρω σελίδες από τον web που έχουν πράγματα που με ενδιαφέρουν και με το πάτημα ενός κουμπιού να μπαίνούν μέσα σε αυτό. (Send to OneNote). Ένα πράγμα μόνο με χαλάει και αυτό είναι ότι σε x64 δεν παίζει ο εκτυπωτής του OneNote, αλλά νομίζω ότι αυτό έχει διορθωθεί στην έκδοση 2010.
  4. εμ τωρα θα φταίω έγω να φωνάζω για τα αδέρφια μου τους developers, πόσες φορές θα τα λέμε για το πως θα πρέπει να γράφουμε κώδικα για να μην έχουμε SQL Injection, ευκαιρία να γράψω ακόμα ένα post
  5. Επειδή στο προηγούμενο μου post σχετικά με το Database Mirroring στον SQL Server ξέχασα να βάλω κάποια Best Practices που έχω διαβάσει σε διάφορα paper, blogs και βιβλία βάζω τα παρακάτω που προτείνει και ο Brad McGehee μιας και με βρήσκουν 100% σύμφωνο. The principal database and the mirror database should be on separate physical hardware, and ideally, in different physical locations. The witness server should be on separate physical hardware, and be on a separate network (best if at a third location). Initial database mirroring setup should be done during less busy times, as the setup process can negatively affect performance of the production database being mirrored. Use high availability mode whenever possible, and high performance mode only when required. The hardware, along with the OS and SQL Server configuration, should be identical (at least very similar) between the two servers. While a fast connection is not required between mirrored servers, the faster the connection, and the better quality the connection, the better. You will want to optimize the performance of the mirrored database as much as possible to reduce the overhead caused by the mirroring process itself. Thoroughly test database mirroring before putting it into production. Monitor database mirroring daily to ensure that it is working properly, and is meeting performance goals. Develop a formal operational and recovery procedure (and document) to support mirroring. Periodically test the failover process to ensure that it works.
  6. καλησπέρα σας. Θέλω να ρωτήσω αν κάποιος γνωρίζει πως μπορώ σε ένα post στο blog μου να κάνω embed ένα video. Έχω δοκιμάσει τα πάντα και ενω στο preview απο το live writer όλα είναι καλα στο Blog μέσα σεν εμφανίζεται τίποτα. Δοκίμασα πολλέ εναλλακτικές αλλά τζίφος. Κάπου βέβαια είδα ότι ίσως χρειάζεται να γίνει config ο community server αλλά δεν μπορώ να κάνω κάτι με αυτό.
  7. Ένα από τα πράγματα τα οποία προσωπικά θεωρώ από τα διαμάντια του SQL Server που έχουμε διαθέσιμα από την έκδοση του SQL Server 2005 (Standard & Enterprise) SP1 είναι το Database Mirroring. Μέχρι την εμφάνιση του για να έχω αυτό που όλοι θέλουμε και δεν είναι άλλο από το database availability έπρεπε να καταφύγουμε σε κάποιες λύσεις όπως: 1. Clustering Ιδανική λύση αλλά στοιχίζει αρκετά σε χρήμα τόσο για την υλοποίηση της όσο και στη διαχείριση του. 2. Replication Αξιόπιστη λύση, με κάποια θεματάκια στην υλοποίηση της, αλλά και με κάποιες παραδοχές που πρέπει να λάβουμε ανάλογα με το τι είδος replication θα υλοποιήσουμε και αφορούν στην παλαιότητα της πληροφορίας που θα έχουμε στην replica. 3. Log Shipping Μια ιδανική λύση για αυτούς που δεν έχουν χρήματα για να υλοποιήσουν τις παραπάνω λύσεις, αλλά έχουν την δυνατότητα να υποστούν απώλεια δεδομένων πχ τα transactions των τελευταίων 15 λεπτών. Αλλά έχουν και την πολυτέλεια να έχουν ένα αρκετά υψηλό downtime μέχρι το αντίγραφο να έρθει σε κατάσταση λειτουργίας και να ενημερωθούν όλες οι εφαρμογές να χρησιμοποιούν αυτό πλέον. Προσωπικά και χαριτολογώντας πάντα αυτό το ονομάζω το cluster του φτωχού. Έχοντας υλοποιήσει στο παρελθόν και τις τρεις λύσεις, έχω μόνο καλά λόγια να πω και για τις τρεις. Απλά θέλω να υποσημειώσω ότι κάθε μία έχει υλοποιηθεί με οδηγό τις ανάγκες του κάθε πελάτη. Για παράδειγμα αν αυτός δεν μπορεί να έχει data loss και θέλει zero downtime δεν θα του βάλεις την 2 και την 3 λυση. Σημείωση Αν και με την λύση 2 έχοντας ένα transactional replication σε ένα πολύ γρήγορο δίκτυο μπορείς να έχεις παλαιότητα πληροφορίας κάτω από 1 sec Τι είναι όμως το Database Mirroring; Είναι δυνατότητα που μας δίνει ο SQL Server ώστε να έχω ένα hot standby αντίγραφο της βάσης μου σε ένα άλλο server που είναι σε διαφορετική γεωγραφική περιοχή. Η μόνη απώλεια δεδομένων που θα έχω θα είναι μόνο τα transactions τα οποία ήταν σε εξέλιξη (δεν είχαν προλάβει να γίνουν commit) κατά την στιγμή της καταστροφής της βάσης ή του server, όπως ακριβώς συμβαίνει και με την λύση του cluster. Σημείωση Το Database Mirroring είναι σε επίπεδο database και όχι σε επίπεδο server όπως το clustering. Αυτό σημαίνει ότι αν στο server της παραγωγής έχω 10 databases θα πρέπει να κάνω Mirror κάθε μια ξεχωριστά. ΔΕΝ ΜΠΟΡΩ ΝΑ ΚΑΝΩ MIRROR ΣΤΙΣ SYSTEM DATABASES (MASTER, MSDB, MODEL, TEMPDB) Ποια είναι η Αρχιτεκτονική του Database Mirroring; Η αρχιτεκτονική του database mirroring είναι σχετικά απλή όπως φαίνεται στο παρακάτω σχεδιάγραμμα. Αυτή είναι η απλή λύση όπου έχω τους δύο servers μου. Τον Server της παραγωγής με την βάση μου το ονομάζουν Principal Server ενώ το mirror server τον ονομάζουν Mirror Server. Σε αυτή την περίπτωση όμως αν "σκάσει" ο Principal θα πρέπει με το "χέρι" να φέρω στην ζωή τον Mirror ο οποίος θα γίνει μετά από αυτή την διαδικασία Principal. Μα καλά θα πει κάποιος τι σόι διαθεσιμότητα είναι αυτή αν πρέπει να το κάνω με το "χερι"; Είπαμε αυτή είναι η απλή λύση. Υπάρχει η κανονική λύση η οποία είναι η παρακάτω: Σε αυτή την περίπτωση εμπλέκεται ακόμα ένας server o Witness Server του οποίου η δουλειά είναι να παρακολουθεί το database mirroring έτσι ώστε αν "πέσει" o principal αυτόματα να κάνει principal τον mirror server. Σημείωση Συνηθίζουμε να ονομάζουμε τους τρεις αυτούς servers (Principal, Mirror, Witness) σαν Mirror Partners ή Partners. Προϋποθέσεις και μικρά αλλά σημαντικά μυστικά για την Υλοποίηση 1. Όλοι οι servers πρέπει να είναι στην ίδια version του SQL Server π.χ 2008. Δεν μπορεί κάποιος από αυτούς να είναι σε 2005 2. Ο Principal και ο Mirror πρέπει να είναι στην ίδια edition πχ. Standard ή Enterprise 3. O Witness πρέπει να είναι σε ένα reliable computer system και μπορεί να είναι Standard, Enterprise, Workgroup ή Express edition. 4. O Mirror server πρέπει να έχει τον χώρο που χρειάζεται η βάση που έχουμε στον Principal. 5. Στην περίπτωση που θα υλοποιήσουμε το σενάριο high safety with automatic failover σε όλους τους partners το cpu load να είναι μικρότερο από το 50% (ειδικά για τον principal και τον mirror). Και αυτό διότι αν έχουμε cpu overload o failover partner μπορεί να μην μπορέσει να κάνει ping τα άλλα server instances με αποτέλεσμα να έχω unnecessary failover!!!. Εάν αυτό δεν μπορεί να γίνει τότε διαλέξετε κάποιο άλλο από τα διαθέσιμα σενάρια (high safety without automatic failover ή high performance). 6. Όλοι οι SQL Servers που συμμετέχουν στο database mirroring πρέπει στην master database να έχουν το ίδιο code page και collation, αλλιώς θα έχουμε προβλήματα κατά την διάρκεια του database mirroring setup!. 7. Για καλύτερο performance είναι καλύτερα να χρησιμοποιηθεί dedicated network adapter για το mirroring. 8. Εάν έχουμε 32bit system, τότε το database mirroring μπορεί να υποστηρίξει μέχρι 10 databases ανά SQL Server instance εξαιτίας του αριθμού των worker threads τα οποία καταναλώνονται για κάθε database mirroring session. 9. Το database mirroring υποστηρίζει οποιοδήποτε database compatibility level. 10. To RESTORE του BACKUP από την principal server στον mirror server πρέπει να γίνει με WITH NORECOVERY. 11. Μόνο το FULL RECOVERY model υποστηρίζεται στο database mirroring. Αυτό σημαίνει ότι η database που θα κάνω Mirror θα πρέπει να έχει αυτό το recovery model, κανένα 12. Databases που έχουν Filestream enable δεν μπορούν να γίνουν mirror. Ποια είναι τα πλεονεκτήματα του Database Mirroring; 1. Αυξάνει την ασφάλεια των δεδομένων 2. Αυξάνει την διαθεσιμότητα της database. 3. Αυξάνει την διαθεσιμότητα του παραγωγικού περιβάλλοντος στην περίπτωση που θελήσουμε σε αυτό να κάνουμε upgrades. Πώς δουλεύει το Database Mirroring; Ο principal και ο mirror server έχοντας ένα database mirror session μεταξύ τους και στην ουσία του πράγματος ότι γίνεται στον principal server γινεται redo στον mirror server. Αυτό γίνεται όσο το δυνατό γρηγορότερα και στην πραγματικότητα ο principal server στέλνει κάθε ενεργό transaction log record στον mirror server, ο οποίος με την σειρά του το κάνει στην mirror database. Σημείωση Δεν είναι όπως στο transactional replication το οποίο είναι σε logical level, εδώ είναι σε physical log record level. Το database mirroring session τρέχει είτε σύγχρονα είτε ασύγχρονα. Το αν θα χρησιμοποιήσω κάποιο από αυτά εξαρτάται από τον τρόπο με τον οποίο θέλω να γίνεται το database mirroring, επιλέγοντας ένα από τους παρακάτω: 1. High Safety (synchronous operation) Κάθε φορά που ένα transaction γίνεται στην database του principal, αυτός στέλνει τα active log στον mirror server. O mirror με την σειρά του γράφει το active log που πήρε το δυνατόν γρηγορότερα και αφού το κάνει αυτό τότε o principal server παίρνει ένα μήνυμα ότι mirror server έχει κάνει την δουλειά του και κάνει commit (ο principal). Σημείωση Ο Mirror δεν κάνει commit απλά γράφει το log στο δίσκο μιας και όπως θα δούμε παρακάτω η database στον mirror server είναι σε φάση restore. Μετά από αυτό το status τον database είναι synchronized και όσο διατηρείται το database mirroring session αυτό θα είναι πάντα το ίδιο. Στον συγκεκριμένο τρόπο έχω δύο ακόμα επιλογές και αυτές είναι αν θα έχω automatic failover ή όχι. Απλά στην πρώτη περίπτωση πρέπει να έχω και witness server, ο οποίος κοιτάζει αν ο principal είναι στην ζωή και αν δεν τότε σηκώνει τον mirror μόνος του. Στην άλλη περίπτωση θα πρέπει να τον σηκώσω εγώ κάνοντας αλλαγή ρόλου είτε με Τ-SQL είτε μέσα από τα UI Σημείωση για τους Developers Εάν θέλετε οι εφαρμογές που έχετε φτιάξει αυτόματα να βλέπουν τον mirror όταν πέσει ο principal τότε καλό είναι να χρησιμοποιήσετε το SQL Native Client Access σαν provider στο connection string βάζοντας ακόμα μέσα σε αυτό την επιλογή failover parter στην οποία θα βάζεται το όνομα του Mirror Server ενώ στο Server/Data Source θα έχετε κανονικά τον principal π.χ Provider=SQLNCLI10.1; Data Source=ac-demosrv; Failover Partner=ac-demosrv\inst01;… Στην περίπτωση που έχετε legacy εφαρμογές υπάρχουν δύο λύσεις που σας προτείνω: a) Να έχετε 2 connection strings το ένα να δείχνει στον principal και το άλλο στον mirror. Πάντα χρησιμοποιούμε το πρώτο και αν αυτό είναι κάτω πιάνουμε το timeout error και μετά χρησιμοποιούμε το άλλο Με κάποιον τρόπο έχουμε εκτός εφαρμογής το connection string και το αλλάζουμε με το χέρι πχ udl file , registry entry με ότι βέβαια συνεπάγεται αυτό από κόστος σε χρόνο για να γίνει. Σημείωση Εάν θέλω να αλλάξω τους ρόλους με t-sql θα πρέπει να εκτελέσω το εξής command ALTER DATABASE SET PARTNER FAILOVER; To ίδιο μπορώ να το κάνω από εάν κάνω δεξί κλικ Properties πάνω στην βάση μου και πάω στην επιλογή Mirroring και πατήσω το κουμπί Failover Εδώ πρέπει να τονίσω ότι υπάρχουν και μερικές παραλλαγές αλλά για αυτές δείτε τα BOL. Ο τρόπος αυτός προσφέρει ασφάλεια και εγγυάται ότι δεν θα έχω απώλεια δεδεμένων στον mirror server όμως έχω κάποιο performance penalty στον principal όσον αφορά το transaction 2. High Performance (asynchronous operation) Εδώ αν και έχω καλύτερο performance μιας και ή όλη διαδικασία γίνεται ασύγχρονα υπάρχει η πιθανότητα να έχω απώλεια δεδομένων στον Mirror Server. Και αυτό διότι όταν γίνεται το transaction στον Principal Server αυτός στέλνει στον Mirror Server το log αλλά δεν περιμένει να πάρει απάντηση για αν το έκανε ή όχι apply αλλά κάνει commit και φυσικά στέλνει στον client ότι όλα είναι ΟΚ. Αυτό σημαίνει ότι ο Mirror Server μπορεί να είναι πίσω όσον αφορά τα δεδομένα που έχει πάρει και σε περίπτωση που πέσει ο Principal και έρθει στην ζωή θα έχει λιγότερα δεδομένα. Στην περίπτωση αυτή ο Mirror Server είναι DISCONNECTED. Αυτός ο τρόπος είναι ιδανικός στην περίπτωση που έχω Principal που είναι oveloaded ή στην περίπτωση που έχω τον Mirror σε WAN το οποίο δεν έχει κάλο δίκτυο. Υπάρχει ακόμα ένα θέμα στο τρόπο αυτό που έχει να κάνει με τη χρήση του Witness Server. Αν και μπορεί να υπάρχει σε αυτό υπάρχουν περιπτώσεις όπου μπορεί να δημιουργήσει πρόβλημα όπως Εάν χαθεί ο Mirror Server ο Principal πρέπει να κάνει connect στον Witness αν δεν τα καταφέρει τότε ο Principal κάνει την database offline ακόμα και αν μετά συνδεθεί είτε ο Mirror είτε ο Witness. Στην περίπτωση που χαθεί ο Principal ο Mirror με την σειρά του πρέπει να κάνει connect στον Witness και αν αυτός είναι μη διαθέσιμος τότε η database δεν θα γίνει διαθέσιμη. Bήματα Yλοποίησης του Database Mirrorning με T-SQL (εύκολος τρόπος ;-) ) Aς δούμε την υλοποίηση με κώδικα t-sql στο demo που ακολουθεί Demo Video Τον κώδικα της παρουσίασης μπορείτε να τον κάνετε download από εδώ Bήματα Yλοποίησης του Database Mirrorning με την χρήση του SSMS (δύσκολος τρόπος ;-) ) Aφού είδαμε το εύκολο τρόπο ας δούμε τον δυσκολο τρόπο υλοποίησης Demo Video Σας ευχαριστώ για την προσοχή σας Αντώνης
  8. Πρόσφατα έκανα μια παρουσίαση με το παραπάνω θέμα για το dotNetZone. Επειδή το θεωρω σημαντικό και επειδή τα παιδιά εκεί την έχουν μαγνητοσκοπήσει σας την δίνω και σε εσάς. https://www323.livemeeting.com/cc/usergroups/view?id=dnz34 και η παρουσίαση μου είναι στο http://cid-4745d5449dec653a.skydrive.live.com/self.aspx/dnzPresentations/Why%20%5E0%20How%20to%20optimize%20SQL%20Server%20for%20performance%20from%20design%20to%20query.pdf
  9. ΖΗΛΕΥΩ :-( Πιείτε μία και για μένα κατά προτίμηση μιά Weizbeer
  10. At the PASS Summit 2009 last week, Ted Kummert announced the soon-to-be-delivered November SQL Server 2008 R2 Community Technology Preview. We’re happy to announce that it is available today for MSDN and TechNet subscribers and it will be available to the general public on November 11th. Go to http://www.microsoft.com/sqlserver/2008/en/us/R2.aspx to get more information and to download!
  11. This survey will be valid until November 13, 2009 and can be found at https://www.surveymonkey.com/s.aspx?sm=DJv_2brczgTusUJkolYrczAQ_3d_3d.
  12. After a very popular first article on tools for the DBA, David Bird is back with a list of some utilities you might find very handy for working with SQL Server. Free “How to Become an Exceptional DBA (2nd ed.)” eBook Download your copy and a free trial of Red Gate SQL Backup for robust SQL Server database backups.
  13. επίσης διακρίνω ότι και εσυ συντάσεσε μαζί μου έτσι δεν είναι; αν όχι κατέθεσε την άποψη σου να κάνουμε μια ωραία συζήτηση ώστε να βγει κάτι που θα οφελήσει όλους μας.
  14. επίσης δες αυτό www.gender-it.eu είναι όλο με EF και SPs όσο αφορά το Data Accessing και είναι σε ένα pc με 256 RAM! ο Web Server και ο SQL Server σε ένα Virtual Machine με 512 μνήμη. Και όπως θα δεις πάει αρκετά καλά. Να γιατί είμαι τόσο επίμονος σε αυτό.
  15. Συνονόματε είμαι από αυτούς που αγαπούν το EF (πως θα μπορούσε άλλωστε αλλιώς να γίνει), αλλά νομίζω ότι οι sp σε συνδιασμό με αυτό είναι ότι καλύτερο. Δεν μπορώ να δεχτώ ότι η βάση είναι ένας κουβάς στον οποίο πετάς δεδομένα. Για μένα η βάση δεν είναι κουβάς είναι το A & Ω σε μία data aware εφαρμογή. Είναι ένα μωρό που θέλει ντάντεμα και το οποίο όταν το νταντεύεις σωστά γλυτώνεις πολλές δεκάδες για να μην πω εκατοντάδες γραμμές κώδικα στο application. Οι SPs αν γραφτούν σωστά τότε είναι χάρμα οφθαλμών το performance αλλά και το validation όπως και το logic sharing σε πολλές εφαρμογές. Μέσα σε αυτά τα 21 χρόνια που είμαι στο χώρο και είδικά από το 1996 που άρχισα να ασχολούμαι με το SQL Server (έκδοση 6.0 ήταν τότε) έχουν δει πολλά τα ματάκια μου και αρκετές τρίχες του κεφαλίου μου πήγαν διακοπές στις Μπαχάμες. Δεν διεκδικώ το αλάθητο ίσα ίσα είμαι ίσως ο πιο χαζός άνθρωπος στο κόσμο, απλά αυτή είναι η γνώμη μου. Εξάλλου το βλέπω το όλο θέμα και από μια σκοπία ίσως λίγο διαφορετική και αυτή είναι οι distributed εφαρμογές με χρήση του WCF σήμερα WS* και παλαιότερα COM+ και ακόμα παλαιότερα MTS. Όπως και να έχει όμως σε ευχαριστώ για το σχόλιο σου και θα ήθελα να σχολιάσεις και άλλα άρθρα μου και θα ήθελα να σε ευχαριστήσω για τα links που πρόσθεσες σε αυτό. Είναι καλό να ακουγονται όλες οι απόψεις επι του θέματος γιατί έτσι θα γίνουμε όλοι μας καλύτερη. Με εκτίμηση Αντώνης
  16. Η μόνη διαδικασία είναι μέχρι να το κάνεις bootable. Μετά copy & paste και πάει τρενο. Με αυτό τον τρόπο έστησα στο netbook το windows 7.
  17. Πρόσφατα αγόρασα ένα netbook για να έχω κάποια πράγματα τα οποία ήθελα μαζί μου και να μην κουβαλάω μεγάλο βάρος. Θέλησα να βάλω Windows 7 αλλά όπως είναι γνωστό dvd αυτά δεν έχουν. Έτσι ψαχνοντας από εδώ και απο εκεί βρήκα την λύση που σας την δίνω εδω http://www.intowindows.com/how-to-install-windows-7vista-from-usb-drive-detailed-100-working-guide/ . Είμαι σίγουρος ότι οι περισσότεροι την ξέρετε αλλα ίσως υπάρχουν κάποιοι που δεν την γνωρίζουν οπότε καλό είναι να την ξέρουν. Βέβαια μπορεί να χρησιμοποιηθεί και για άλλους σκοπούς, ένα bootable USB είναι πάντα χρήσιμο δεν νομίζετε;
  18. Free “SQL Server Tacklebox” eBook Download the eBook for expert advice on tackling SQL Server issues and try out SQL Response to be alerted to problems on your SQL Servers.
  19. Χαίρετε, καιρό είχατε να με ακούσετε ε; Δυστυχώς αυτά συμβαίνουν όταν αλλάζεις δουλειά. Όμως σιγά σιγά βρίσκω τα νέα βήματα μου οπότε επανέρχομαι δριμύτερος. Σήμερα θέλω να σας κουράσω με κάτι που δεν είναι στο administration του SQL Server αλλά στο programming του. Αυτό ακούει στο όνομα Stored Procedures. Είμαι σίγουρος ότι αν όχι όλοι οι περισσότεροι τις ξέρετε. Είμαι σίγουρος ότι υπάρχουν φανατικοί υποστηρικτές τους, όπως επίσης και άλλοι που όταν ακούνε το όνομα τους βγάζουν σπυράκια. Εάν έχετε ποτέ εμπλακεί σε μια τέτοια κουβέντα, σίγουρα θα έχετε πάρει το μέρος κάποιας πλευράς. Όπως συμβαίνει όμως πάντα σε αυτή τη ζωή η αλήθεια είναι πάντα στην μέση. Ίσως σε αυτή την περίπτωση να γέρνει λίγο περισσότερο στην μία μεριά αλλά καλύτερα αυτό να το αποφασίσετε εσείς μετά από όλα όσα σας πω σε αυτό το post μου. Μια σειρά από αλήθειες και μύθους έχουν φτιάξει την διαμάχη αυτή. Νομίζω όμως ότι είναι καιρός να βάλουμε τα πράγματα στην θέση τους όπως ακριβώς έχουν. Οφείλω να ομολογήσω ότι και εγώ προσωπικά έχω εμπλακεί σε αυτή την διαμάχη, όπως οφείλω να ομολογήσω ότι είμαι θερμός υποστηρικτής της μίας εκ των δύο. Ας πάρουμε τα πράγματα από την αρχή. Μία Stored Procedure είναι ένα σύνολο από T-SQL statements τα οποία είναι compiled μέσα σε ένα single execution plan. Επειδή ενδεχομένως κάποιος συνάδελφος να ρωτήσει τι είναι το execution plan παραθέτω το παρακάτω link για περισσότερη μελέτη. http://msdn.microsoft.com/en-us/library/ms181055.aspx Με την χρήση των SPs μπορώ να μεταφέρω την λογική που θα έγραφα μέσα σε κάποια εφαρμογή η οποία έχει να κάνει με τα δεδομένα πάνω στον SQL Server, στο σημείο δηλαδή που τα δεδομένα υπάρχουν. Απλά από την εφαρμογή μου καλώ την SP. Το παραπάνω αποτελεί ένα από τα βασικά σημεία τριβής των εμπλεκομένων στην διαμάχη αυτή. Οι καταγγέλλοντες τις SP λένε: "Με αυτό τον τρόπο έχω σπάσει το business logic σε πολλά διαφορετικά σημεία (data tier, middle tier) και έτσι μου γίνεται δύσκολη η ζωή στην περίπτωση που θέλω να το αλλάξω γιατί απλά δεν θα ξέρω που θα το βρω. Επίσης δεν μπορώ να έχω κάποιο έτοιμο documentation όπως αν θα το έκανα μέσα από το Visual Studio με τα διάφορα εργαλεία που αυτό έχει. Άσε που με T-SQL δεν μπορώ να κάνω όλα όσα μπορώ να κάνω με C# π.χ. Και εντάξει να κάνω χρήση των SPs αλλά τι θα γίνει στην περίπτωση που ο SQL Server είναι εξαντλημένος από resources; Η/Οι SP(s) δεν θα ανταποκρίνονται για αυτό κάνω το query/ τα queries μου και φέρνω τα δεδομένα στο middle ¨η στον client και κάνω μια χαρά την δουλειά μου." Οι υποστηρικτές λένε: "Μα τι λες τώρα. Ίσα ίσα αυτό είναι καλό διότι η λογική μπορεί εύκολα να μοιρασθεί σε περισσότερες εφαρμογές μια και δεν θα χρειασθεί να γραφτεί ξανά μέσα σε αυτές με τον κίνδυνο του λάθους να καραδοκεί. Επίσης επειδή η SP εκτελείται στον SQL Server στο σημείο που είναι τα δεδομένα έχω καλύτερο performance και φυσικά αποσυμφορίζω το δίκτυο από traffic να μεταφέρω τα δεδομένα από τον database server στον application server και σε κάποιες περιπτώσεις και στον client με σκοπό να γίνει η επεξεργασίας τους και μετά να τα επιστρέφω στον database server, αλλά και τον client από φόρτο εργασίας." Και τώρα μάλιστα, τα πιάσαμε τα λεφτά μας. Ποιος από τους δύο έχει δίκιο; Εδώ λοιπόν θα βρούμε μερικούς μύθους και μερικές αλήθειες. ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 1. Όντως η T-SQL δεν είναι τόσο δυνατή γλώσσα όπως η C#, αλλά ο σκοπός της δεν είναι να κάνει ότι κάνει η C#. Ο σκοπός της είναι να ασχοληθεί με τα δεδομένα και σε αυτό είναι η τέλεια γλώσσα. ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 2. Όντως η δυνατότητα για documentation που δίνει ο SQL Server είναι αρκετά φτωχή σε σχέση με τα XML Remarks που έχω στην C#. Όμως έχω το Microsoft Visio, το Microsoft Visual Studio Database Developer Team Suite, και φυσικά μια πληθώρα από άλλα εργαλεία πχ το SQL Toolbelt της Red-Gate ή τα εργαλεία της Apex. ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 3. "Με αυτό τον τρόπο έχω σπάσει το business logic σε πολλά διαφορετικά σημεία (data tier, middle tier) και έτσι μου γίνεται δύσκολη η ζωή στην περίπτωση που θέλω να το αλλάξω γιατί απλά δεν θα ξέρω που θα το βρω." Όντως αυτό είναι ένα πιθανό σενάριο που όμως θα συμβεί από κακό documentation ή κακό σχεδιασμό. Δηλαδή όταν έχει στο middle tier X τον αριθμό από classes, web services κ.λ.π. δεν έχει σπάσει την λογική σε Ν σημεία; Εκτός και αν μιλάμε για Client-Server αρχιτεκτονική όπου όλα τα έχει στον client (Fat client), όπου αφού κάνει την αλλαγή θα πρέπει να την κάνει deploy σε n clients με ότι αυτό συνεπάγεται από χρόνο και κόστος. ΜΥΘΟΣ/ΑΛΗΘΕΙΑ 4. "Επίσης επειδή η SP εκτελείται στον SQL Server στο σημείο που είναι τα δεδομένα έχω καλύτερο performance και φυσικά αποσυμφορίζω το δίκτυο από traffic να μεταφέρω τα δεδομένα από τον database server στον application server και σε κάποιες περιπτώσεις και στον client με σκοπό να γίνει η επεξεργασίας τους και μετά να τα επιστρέφω στον database server, αλλά και τον client από φόρτο εργασίας." "Και εντάξει να κάνω χρήση των SPs αλλά τι θα γίνει στην περίπτωση που ο SQL Server είναι εξαντλημένος από resources; Η/Οι SP(s) δεν θα ανταποκρίνονται για αυτό κάνω το query/ τα queries μου και φέρνω τα δεδομένα στο middle ¨η στον client και κάνω μια χαρά την δουλειά μου." Οι υποστηρικτές σε αυτό το σημείο έχουν δίκιο όσο και οι καταγγέλλοντες που μιλάνε για την περίπτωση που ο SQL Server εξαντληθεί από resouces. Αυτό όντως θα γίνει αν ακολουθήσουμε την γενικότερη λογική των δεύτερων δλδ όχι SPs μόνο queries. Βέβαια υπάρχει και η περίπτωση που έχουμε κάνει λάθος εκτίμηση αναγκών, δηλαδή εκτιμήσαμε λιγότερο φόρτο εργασίας από αυτόν που έχουμε, ή αυτός που έγραψε την SP δεν είχε ιδέα από SQL άρα έγραφε όπως ήθελε με αποτέλεσμα να ζητάει το σύμπαν από resources. Αν τίποτα από όλα αυτά δεν συμβεί τότε NAI κερδίζω σε performance όπως επίσης και σε network traffic. Ας δούμε όμως τι κερδίζω από την χρήση των SPs σε σχέση με την χρήση των προγραμμάτων που εκτελούν μέσα τους T-SQL. Το αντιγράφω όπως είναι από τα BOL του SQL Server, δεν θέλω να το αλλάξω για να μην υπάρξει έστω και η παραμικρή αλλοίωση του νοήματος. 1. They are registered at the server. 2. They can have security attributes (such as permissions) and ownership chaining, and certificates can be attached to them. 3. Users can be granted permission to execute a stored procedure without having to have direct permissions on the objects referenced in the procedure. 4. They can enhance the security of your application. 5. Parameterized stored procedures can help protect your application from SQL Injection attacks. 6. They allow modular programming. 7. You can create the procedure once, and call it any number of times in your program. This can improve the maintainability of your application and allow applications to access the database in a uniform manner. 8. They are named code allowing for delayed binding. 9. This provides a level of indirection for easy code evolution. 10. They can reduce network traffic. An operation requiring hundreds of lines of Transact-SQL code can be performed through a single statement that executes the code in a procedure, rather than by sending hundreds of lines of code over the network. Προσωπικά δεν μπορώ να φανταστώ μια εφαρμογή που δεν χρησιμοποιεί SPs. Βέβαια ξέρω τι θα μου πει η άλλη πλευρά. "Ναι αλλά θέλω να έχω την δυνατότητα να μιλάω από την εφαρμογή μου με τα διάφορα ORM tools (Object Relational Models) όπως LINQ, Entity Framework και οι SPs δεν μου δίνουν όλα μου δίνουν οι πίνακες". Η απάντηση μου είναι ότι δεν είναι ακριβώς έτσι τα πράγματα, σίγουρα υπάρχουν κάποια πράγματα τα οποία χάνεις όμως η εφαρμογή αγαπητοί μου συνάδελφοι δεν είναι μόνο User Interface και δεν μπορώ να θυσιάζω τα πάντα για αυτό. Εξάλλου εάν έχω distributed εφαρμογές όλα αυτά τα εργαλεία που πραγματικά είναι ΦΟΒΕΡΑ δεν έχουν νόημα χρήσης στο UI μιας και μεσολαβεί το middle το οποίο είναι αυτό το οποίο κάνει την επικοινωνία με την βάση. Άρα η χρήση τους περιορίζεται σε αυτό και με άλλους τρόπους (δικά μας object, object lists) μεταφέρουμε τα δεδομένα στο UI. Ελπίζω να σας έπεισα και να κάνετε χρήση των SP.
  20. Συντοπίτη προχωρα δυνατά!!!
  21. Αγαπητέ μου συνάδελφε η απάντηση μου είναι ότι δεν θα έχεις κάνενα απολύτως πρόβλημα όσο αφορά την λειτουργία της βάσης σου. Απλά κάποια features που έχει ο 2008 πχ database encryption κ.α δεν θα τα έχεις διαθέσιμά. Προχώρα αφόβα όπως είσαι. Φιλικά
  22. Ίσως όσα θα αναφερθούν παρακάτω να είναι γνωστά, και το post αυτό να μην είναι ενδιαφέρον. Όμως έχω την υποχρέωση να τα αναφέρω ξανά γιατί θεωρώ ότι είναι πράγματα στα οποία δεν δίνουμε ιδιαίτερη σημασία και τα οποία όταν διογκώνονται είναι δύσκολα στην επίλυση τους. Θα μιλήσουμε εδώ γιa την αρχιτεκτονική μιας database στον SQL Server, από τι αποτελείτε μια database, πιο είναι το ιδανικό αρχικό μέγεθος δημιουργίας της, τι πολιτική να ορίσω για το growth της. Μια database στον SQL Server αποτελείτε από τουλάχιστον 2 αρχεία. Το ένα από αυτά είναι το data αρχείο και το άλλο είναι το log αρχείο. Εάν δεν ορίσω κάτι συγκεκριμένο κατά την δημιουργία της database, αυτή είναι ένα πιστό αντίγραφο της model database που έχει ο SQL Server. Δηλαδή έχει όλα τα περιεχόμενα και το μέγεθος της model database. Γενικότερα να γνωρίζεται ότι κάθε φορά που φτιάχνεται μια database αυτή είναι ένα αντίγραφο της model database τουλάχιστον ως προς τα περιεχόμενα της, μιας και κατά την δημιουργία έχουμε την δυνατότητα να αλλάξουμε το μέγεθος, το location που θα είναι τα αρχεία της database και ένα σωρό άλλα options και παραμέτρους. Αν αναρωτιέστε ποια είναι τα περιεχόμενα της model database, αυτά είναι τα database system catalogs και τυχόν δικά μας objects όπως tables, views, stored procedures κλπ που έχουμε φτιάξει στην model με σκοπό να τα έχουμε διαθέσιμα στις νέες δικιές μας databases. (Παρατήρηση: Εάν έχω ήδη δικίες μου databases και φτιάξω στην model ένα νέο δικό μου object (πχ table) τότε αυτό δεν θα πάει και στις ήδη υπάρχουσες αλλά μόνο στις νέες). Όπως είπα και πιο πάνω μια database έχει τουλάχιστον 2 αρχεία το data file και το log file. Μια database μπορεί να έχει μέχρι 32.767 αρχεία. Το μέγεθος της μπορεί να φτάσει στα 524.258 ΤΒ για τις εκδόσεις 2005 και 2008 και στα 1.048.512 ΤΒ για τις εκδόσεις 2000 και 7.0. Κάθε data file δεν μπορεί να είναι μεγαλύτερο από 16 ΤΒ για τις εκδόσεις 2005 και 2008 και 32 ΤΒ για 2000 και 7.0, ενώ το κάθε log file δεν μπορεί να είναι μεγαλύτερο των 2 ΤΒ για τις εκδόσεις 2005 και 2008, 32 ΤΒ στην έκδοση 2000 και 4 ΤΒ στην έκδοση 7.0. Όταν δημιουργούμε μια database συνήθως ορίζουμε το αρχικό μέγεθος δημιουργίας της, τόσο για το data όσο και για το log file. O χώρος αυτός καταλαμβάνεται άμεσα από το δίσκο μας. Δηλαδή αν φτιάξω μια βάση με 10 ΜΒ data file και 3 ΜΒ log file τότε έχω μείον 13 ΜΒ από τα διαθέσιμα του δίσκου μου. Κάθε data file χωρίζεται εσωτερικά σε σελίδες (pages) των 8ΚΒ (8.192 Β), στις οποίες αποθηκεύονται τα δεδομένα που έχω στην βάση (data, metadata, indexes). Κάθε 8 συνεχόμενες σελίδες μου κάνουν ένα extent (64 ΚΒ ήτοι 16 extents / 1 ΜΒ). Υπάρχουν δύο είδη extent τα uniform (και οι 8 σελίδες ανήκουν στον ίδιο object πχ. Table) και τα mixed (οι 8 σελίδες δεν ανήκουν στο ίδιο object αλλά σε περισσότερα από ένα) . Σε κάθε data file οι πρώτες 8 σελίδες είναι εξ ορισμού δεσμευμένες από κάποιες ειδικού χειρισμού σελίδες που στην ουσία κάνουν trace τον ελεύθερο και δεσμευμένο χώρο σε αυτό. Αυτές είναι οι File Header (FH), Page Free Space (PFS), Global Allocation Map (GAM), Shared Global Allocation Map (SGAM) (περισσότερα) Κάθε σελίδα όπως είπα και πιο πάνω είναι 8 ΚΒ. Από αυτά τα 96 ΚΒ είναι ο page header στον οποίο είναι αποθηκευμένες οι εξής πληροφορίες page number, page type, το ποσό του free space στην σελίδα, και το allocation unit ID του object στο οποίο ανήκει η σελίδα. Με το που βάζω το πρώτο record αυτό μπαίνει αμέσως μετά από τον header και στο τέλος της σελίδα υπάρχει το record offset το οποίο μπαίνει με την αντίστροφη σειρά της εισαγωγής. Άρα ο πραγματικός ωφέλιμος χώρος που έχω πάνω σε κάθε σελίδα είναι 8060 bytes. Αυτό είναι και το μέγιστο record length που μπορώ να έχω πάνω σε ένα πίνακα. Δηλαδή εάν έχω ένα πίνακα που το record length του είναι 100 bytes αυτό σημαίνει ότι σε κάθε σελίδα χωράνε 80 records, και αν ο πίνακας έχει 200 εγγραφές τότε θέλω 3 σελίδες για να αποθηκευτούν τα δεδομένα του. (περισσότερα). Επίσης θα πρέπει να το τονίσω σε αυτό το σημείο ότι ένα record ανήκει πάντα σε μια σελίδα, δεν υπάρχει ποτέ περίπτωση να είναι το μισό σε μια και το άλλο σε άλλη. Θα προλάβω μερικούς συναδέλφους που θα πουν για τα datatypes varchar(max), nvarchar(max), text, ntext, images, varbinary(max) ότι είναι σε άλλες σελίδες αλλά είναι εκεί λόγω μεγέθους. Αυτό που σας έχω αναφέρει μέχρι τώρα είναι αρκετά σημαντικό για τον σχεδιασμό των tables, indexes σε μια database στον SQL Server. Διότι κυρίες και κύριοι συνάδελφοι εάν κάποιος αρχίζει και βάζει πεδία μέσα στον πίνακα (μέχρι 1024 πεδία μπορεί να έχει ένας πίνακας) και φτιάξει ένα record length 5000 bytes αυτό σημαίνει ότι μέσα σε μια σελίδα μπαίνει ένα και μόνο ένα record και μένουν ανεκμετάλλευτα 3000 bytes. Εάν λοιπόν ο πίνακας μου έχει 10.000 records σημαίνει ότι θέλω και 10.000 σελίδες που στην κάθε μία χάνω 3.000 bytes, άρα 3.000 bytes x 10.000 σελίδες = 30.000.000 bytes / 1024 bytes = 29296 KB / 1024 KB=28 MB χαμένου χώρου στον δίσκο, μιας και αν θεωρήσουμε ότι υπάρχει μόνο αυτός ο πίνακας στην βάση μας (κάτι φυσικά που δε συμβαίνει στην πραγματικότητα) το data file μας έχει δεσμεύσει χώρο στο δίσκο ίσο με 78 ΜΒ. Όπως γίνεται άμεσα κατανοητό ο κακός σχεδιασμός επηρεάζει άμεσα και το performance πώς? η απάντηση σε λίγο. Επίσης όταν δημιουργούμε μια database σκόπιμο θα είναι να έχουμε κάνει μια εκτίμηση για το μέγεθος για τους πρώτους 3 μήνες της ζωής της ώστε να δεσμεύσουμε τον χώρο αυτό κατά την στιγμή της δημιουργίας της. Ο σκοπός του να γίνει κάτι τέτοιο είναι σημαντικός διότι αν δώσουμε κάτι το οποίο είναι μικρό και σε συνδυασμό με το τι έχουμε ορίσει σαν file growth policy, που συνήθως το αφήνουμε μικρό, και έχουμε μεγάλο αριθμό από transactions αυτό θα μας οδηγήσει μαθηματικά στο να έχουμε συνεχόμενο ΙΟ στον δίσκο μας επειδή ο SQL Server θα αιτείτε συνέχεια επιπλέον χώρο σε αυτόν μέσω του λειτουργικού συστήματος καθώς η database θα γεμίζει συχνότερα. Αυτό είναι καταστροφικό σε συστήματα που έχουν πολλά transactions. Πριν προχωρήσω στην διαδικασία θα επισημάνω την λέξη εκτίμηση. Αυτό σημαίνει ότι μετά από πάροδο μερικών ημερών κάνω έναν έλεγχο για να δω αν η εκτίμηση μου είναι σωστή και αναλόγως πράττω, μεγαλώνω ή μικραίνω την database. Τώρα πως κάνουμε την εκτίμηση αυτή. Πρώτα από όλα επιλέγουμε μια χρονική περίοδο για την εκτίμηση μας πχ 1 μήνα , 2 μήνες κλπ ανάλογα με το είδος της εφαρμογής που χρησιμοποιεί την database, πχ σε ένα ERP θα μπορούσαμε διαλέξουμε 3 μήνες. Έπειτα βρίσκω το record length του κάθε πίνακα αυτό το πολλαπλασιάζω με τον αριθμό των records που εκτιμώ ότι θα μπουν στην χρονική περίοδο που έχω διαλέξει. Το αποτέλεσμα τα κάνω σελίδες και τις σελίδες τις κάνω MB. Το ίδιο αλλά κάπως διαφοροποιημένο το κάνω και για τους indexes. Το άθροισμα όλων αυτών μου δίνει το αρχικό μέγεθος δημιουργίας της database μου. Δεν θα το αναλύσω περισσότερο εδώ απλά θα σας παραπέμψω στα books online όπου έχει αναλυτικά όλη την διαδικασία. Απλά κάντε αναζήτηση για Estimating the Size of a Database. Μέχρι τώρα δεν έχω αναφέρει τίποτα για το άλλο αρχείο που έχει μια database, το log αρχείο. Προσωπικά πιστεύω ότι είναι το σημαντικότερο αρχείο σε μία database. Σε αυτό καταγράφονται όλα εκτός από τα select statements και τα blob πεδία αν και αυτά έχω την επιλογή να πω να καταγράφονται. Συνήθως το αρχικό μέγεθος δημιουργίας του είναι το 30% του αρχικού μεγέθους του ή των data αρχείου (αρχείων). Δηλαδή αν έχω 100 ΜΒ data φτιάχνω log ίσο με 30ΜΒ. Βέβαια αυτό αν και είναι κανόνας, πάντα υπάρχει περιθώριο καταστρατήγησης του, όπως για παράδειγμα αν έχω heavily transactional databases, όπου σε αυτές τις περιπτώσεις είναι ανάλογα μεγαλύτερο. Έδω όμως θα τονίσω ότι χρειάζεται ιδιαίτερη προσοχή στην πολιτική για το πως αυτό θα μεγαλώνει όταν γεμίσει. Αυτό που έχω δει είναι ότι συνήθως βάζετε κάτι μικρό ή αφήνετε το default που είναι 10%. Αυτό είναι και το λάθος σας. Καλό είναι να βάζετε σαν πολιτική το αρχικό μέγεθος του. Δηλαδή αν έχω 30ΜΒ Log λέω στo file growth του 30ΜΒ ούτε 100% ούτε τίποτα σε ποσοστό. Και αυτό γιατί πολλοί θεωρούν το Log σαν έναν κουβά όμως τα πράγματα δεν είναι έτσι. Εσωτερικά το log χωρίζεται σε virtual logs. Ο σκοπός μου είναι να έχω πάντα ισομεγέθη virtual log ώστε να μην μου εμφανισθεί το φαινόμενο το Log file να είναι μεγαλύτερο από το ή τα data file(s). Σε κάποιο άλλο post μου θα σας πω περισσότερα για αυτό. Τώρα βέβαια θα πρέπει να πω ότι αν παίρνω backup την βάση μου το log γίνεται truncate. Προσοχή δεν μειώνεται σαν μέγεθος στον δίσκο αλλά εσωτερικά γίνεται truncate. Αυτό σημαίνει ότι ο εσωτερικός χώρος που ελευθερώνεται επαναχρησιμοποιείται. Λογικά αν έχω εκτιμήσει σωστά το αρχικό μέγεθος δημιουργίας του log file και κάνω καθημερινό backup δεν θα το δω ποτέ να μεγαλώνει πέρα από το αρχικό του μέγεθος. Για να δούμε πως χρησιμοποιείται το log. Τρεις είναι οι βασικοί παράγοντες που επηρεάζουν το performance, CPU, MEMORY, DISK IO. Δυστυχώς όμως το χειρότερο από όλα σε performance σε σχέση με τα άλλα είναι ο δίσκος. Σκοπός του SQL Server είναι να έχει το μικρότερο δυνατό disk io. Για να το κάνει αυτό χρησιμοποιεί μνήμη και φυσικά το log file. O SQL Server δεσμεύει ένα ποσό από την διαθέσιμη μνήμη του συστήματος. Ένα ποσό από αυτή την μνήμη ανήκει στη buffer cache. Για να δούμε όλη την διαδικασία με ένα παράδειγμα. Είπαμε πιο πάνω ότι τα δεδομένα μου είναι αποθηκευμένα σε σελίδες των 8KB. Έτσι όταν κάποιος χρήστης κάνει ένα select, insert, update, delete αυτό που κάνει ο SQL Server είναι να δει αν υπάρχουν στην buffer cache οι σελίδες που θα επηρεαστούν από την ενέργεια αυτή. Εάν δεν είναι τότε τις διαβάζει από τον δίσκο και τις βάζει στην buffer cache. Το επόμενο βήμα του είναι να εκτελέσει την ενέργεια πάνω στις σελίδες που είναι στην buffer cache. Για το μεν select επιστρέφει τα δεδομένα στον χρήστη, για τις άλλες ενέργειες όμως κάνει ακόμα ένα βήμα γράφει την ενέργεια στο log file. Γιατί το κάνει αυτό; Η απάντηση είναι απλή κάνει minimize το ΙΟ. Στην ουσία οι ενέργειες θα γραφτούν στο data file όταν γίνει η διαδικασία που φέρει το όνομα checkpoint process. Τι κάνει αυτή; Σε τακτά χρονικά διαστήματα έρχεται ο SQL Server και διαβάζει το log είτε από την αρχή εάν είναι η πρώτη φορά είτε από το σημείο που είχε σταματήσει την προηγούμενη φορά η διαδικασία αυτή. Και όσα transactions είναι commited βλέπει ποιες είναι οι σελίδες που έχουν επηρεασθεί από αυτά και τις γράφει στον data file δηλαδή στον δίσκο. Τώρα κάποιος θα αναρωτηθεί και αν πέσει το ρεύμα πριν γίνει η διαδικασία αυτή; ΔΕΝ ΥΠΑΡΧΕΙ ΚΑΝΕΝΑ ΠΡΟΒΛΗΜΑ. Διότι κάθε φορά που ο SQL Server ξεκινάει κοιτάζει το Log file και ότι transaction είναι ολοκληρωμένο και δεν υπάρχει στα data file αναπαράγετε, ότι ήταν σε εξέλιξη γίνεται rollback. Η διαδικασία αυτή λέγεται recovery process. Άρα θα έχω όλα μου τα δεδομένα εκτός βέβαια από αυτά που δεν είχαν προλάβει να ολοκληρωθούν. Σας χρωστάω μια απάντηση από πιο πάνω. Θυμηθείτε το παράδειγμα με τις 10.000 σελίδες όπου στην κάθε μία έχω ένα record. Βάλτε με το μυαλό σας τι θα γίνει αν απλά θελήσω να διαβάσω όλα τα δεδομένα του πίνακα. Απλά θα έχω "τσακίσει" τους τρεις βασικούς παράγοντες που επηρεάζουν την απόδοση του SQL Server, και αυτό γιατί για να κινηθούν οι κεφάλες στον δίσκο θα πρέπει να δώσει η εντολή η CPU αυτές θα διαβάσουν τα δεδομένα , άρα μεγάλο ΙΟ και αυτά θα πρέπει αν μεταφερθούν στην μνήμη. Έτσι απλά! τα φόρτωσα όλα, και αυτό γιατί όταν σχεδίαζα την βάση μου δεν έλαβα υπόψη μου την αρχιτεκτονική του SQL Server.
×
×
  • Create New...