Jump to content

antonch

Administrators
  • Posts

    1030
  • Joined

  • Last visited

  • Days Won

    7

Blog Entries posted by antonch

  1. antonch
    Ένα από τα services του SQL Server είναι τα Reporting Services τα οποία παρέχουν ένα εξαιρετικά ευέλικτο τρόπο να μεταδίδεται η πληροφορία στους τελικούς χρήστες. Η χρήση τους από τις εταιρίες και τους οργανισμούς έχει αυξηθεί σε υπερθετικό βαθμό και κανείς θα βρει μεγάλο αριθμό από reports να εκτελούνται καθημερινά στις υποδομές αυτών των εταιρειών.
    Είναι φυσικό κάποια στιγμή να χρειαζόμαστε
    να παρακολουθήσουμε ποια είναι αυτά που χρησιμοποιούνται,
    πόσο συχνά χρησιμοποιούνται,
    πόσο χρόνο χρειάζονται για να εκτελεστούν
    ποιοι είναι οι χρήστες και ποια reports εκτελούν.

    Οι παραπάνω λόγοι είναι μερικοί και κάνουν επιτακτική την ανάγκη να έχεις αρχικά ενεργοποιημένο το auditing στα SSRS και στην συνέχεια να έχεις μια διαδικασία που να κάνει την ζωή σου ευκολότερη.
    Πέρα όμως από αυτούς το τελευταίο διάστημα είχα αρκετές ανάγκες στον εργασιακό μου χώρο για auditing από επιθεώρηση πάνω στoυς SSRS servers που έχω αλλά και πολλές ερωτήσεις από τους μαθητές μου στα πρόσφατα BI σεμινάρια που έκανα.
     
    http://www.sqlschool.gr/blog/auditing-reports-execution-in-ssrs-1038.aspx
  2. antonch
    Πριν από μερικές μέρες μου ήρθε ένα ερώτημα από ένα φίλο για το τι είναι το C2 Level Auditing στον SQL Server. Δράττω την ευκαιρία αυτή για να το εξηγήσω σε όλους όσους ενδιαφέρονται να παρακολουθήσουν στενότερα το περιβάλλον τους στον SQL Server.
    Εδώ και πολλά χρόνια όπως ξέρουμε τεράστια ποσά έχουν δαπανηθεί στο να έχουμε ασφαλή συστήματα. Αυτό γίνεται με το να οροθετούνται συνεχώς νέα πρότυπα και standards. Οι λόγοι για κάτι τέτοιο είναι βέβαια προφανείς αλλά ποτέ κανείς δεν έπαθε τίποτα από την επανάληψη τους διότι όπως έλεγαν οι αρχαίοι (δυστυχώς μόνο αυτοί) πρόγονοι μας "Η επανάληψη είναι η μητέρα της μάθησης", έτσι θα τους επαναλάβω εν τάχει.
    · Να εντοπισθεί η κακομεταχείριση του συστήματος και να αποτραπεί η συνέχεια αυτής.
    · Να αποδοθούν οι συνέπειες σε αυτούς που είναι υπεύθυνοι για την κακομεταχείριση του συστήματος.
    · Να γίνουν οι ενέργειες που θα φέρουν το σύστημα στην προγενέστερη κατάσταση του, πριν δηλαδή από την υφιστάμενη κακομεταχείριση του.
    Τι είναι όμως το C2;
    Το Υπουργείο Άμυνας των ΗΠΑ έχει ορίσει μια σειρά από επίπεδα για το security level των υπολογιστικών συστημάτων τα οποία βασίζονται στις δυνατότητες τους αλλά και στο πως αυτά προσπελάζονται.
    Με βάση όλα αυτά από την έκδοση του SQL Server 2000 η Microsoft παρέχει την δυνατότητα να έχω C2 Level για το περιβάλλον του SQL Server. Εδώ θα πρέπει να πως ότι ο SQL Server είναι ήδη από τότε C2 Level certified (και μην με ρωτήσετε από πού, αυτό νομίζω ότι είναι προφανές). Για παράδειγμα θα πω ότι ο SQL Server ότι όλα τα δεδομένα τα οποία βγαίνουν από το C2 (files) βγαίνουν μόνο σε NTFS partitions.
    To C2 δημιουργεί auditing records για όλα τα server level events του SQL Server όπως shutdown. restart, successful & failed login attempts. Επίσης παρέχει την δυνατότητα να παρακολουθεί τα permissions σε database objects σε DDL, DCL, DML statements.
    Η πληροφορία που καταγράφεται περιέχει
    timestamp identifier για τον account το οποίο έκανε trigger το event target server name event type success or failure outcome application name server process ID database name Πώς ενεργοποιώ το C2 Auditing Level;
    Αυτό μπορώ να το κάνω με δύο τρόπους, ο πρώτος τρόπος είναι από το Server Properties windows (δεξί κλικ στο όνομα του server μέσα στο SSMS) όπως παρακάτω

    Ο δεύτερος τρόπος είναι με T-SQL commands όπως παρακάτω


    Code Snippet


    USE master GO sp_configure 'show advanced option', 1 GO RECONFIGURE GO sp_configure 'c2 audit mode',1 GO RECONFIGURE GO



    Σε κάθε περίπτωση απαιτείται restart του SQL Server για την ενεργοποίηση του!
    Από το σημείο αυτό και μετά στο data directory που έχουμε ορίσει για τον SQL Server Instance μας π.χ. C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA παράγονται αρχεία της μορφής audittraceΥΥΥΥΜΜDDHHMMSS.trc. Κάθε τέτοιο αρχείο μπορεί να φτάσει τα 200MB. Σε αυτή την περίπτωση δημιουργείται νέο αρχείο το οποίο περιέχει την συνέχεια. Επίσης θα πρέπει να τονίσω ότι στην περίπτωση που γεμίσει ο δίσκος που είναι τα C2 files τότε ο SQL Server σταματάει αυτόματα. Σε αυτή την περίπτωση θα πρέπει να ξεκινήσουμε το SQL Server service με το διακόπτη -f και μετά να ελευθερώσουμε χώρο στο δίσκο.
    Τα αρχεία αυτά μπορούμε να τα διαβάσουμε με δύο τρόπους. Ο ένας τρόπος είναι χρησιμοποιώντας τον SQL Server Profiler. Ο άλλος τρόπος είναι να τα δούμε σε μορφή πίνακα ώστε να τα κάνουμε manipulate με queries όπως παρακάτω


    Code Snippet


    SELECT *  FROM fn_trace_gettable('C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\audittrace20100530214218.trc', default)



     
    Βέβαια έχω την δυνατότητα να δω μόνο αυτά που θέλω πχ θέλω μόνο τα failed logins π.χ


    Code Snippet


    SELECT *  FROM fn_trace_gettable('C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\audittrace20100530214218.trc', default) WHERE TextData like '%Login failed%'



     
    Μερικές χρήσιμες πληροφορίες
    Υπάρχει όπως είναι κατανοητό κάποιο performance penalty, μιας και πρέπει να γράφονται πράγματα στο δίσκο. Σε αυτή την την περίπτωση καλό είναι να γράφονται σε ξεχωριστό φυσικό δίσκο (όχι partition). Στην περίπτωση που δεν μπορεί να γίνει καταγραφή των συμβάντων ο SQL Server δεν ξεκινάει. Στον SQL Server 2008 υπάρχει εναλλακτικός τρόπος για την καταγραφή των συμβάντων τόσο σε επίπεδο server όσο και σε επίπεδο database. (θα ασχοληθώ με αυτό σε άλλο post)
  3. antonch
    Μια πρωινή ερώτηση που ένας συνάδελφος μου έθεσε ήταν η αφορμή για αυτό το tip of the day. Η ερώτηση του ήταν:

    Πως μπορώ να αλλάξω το schema σε ένα object μέσα σε μια database;


    Η απάντηση είναι απλή και φαίνεται στο παρακάτω παράδειγμα
    περισσότερα
  4. antonch
    Είχα σκοπό να τα φτιάξω κάτι σχετικό, αλλά ψάχνοντας για κάτι άλλο, έπεσα επάνω τους. Σας δίνω τα links ώστε να τα δείτε.
    Installation of a Single Node Failover Cluster in SQL Server 2008
    Add a Node to an Existing Failover Cluster in SQL Server 2008
    Remove a Passive Node from an Existing Failover Cluster in SQL Server 2008
    Remove the Active Node from an Existing Failover Cluster in SQL Server 2008
  5. antonch
    Επειδή πάντα θέλω να έχω πρόχειρα τις δυνατότητες ανά έκδοση του SQL Server για να ξέρω τι θα προτείνω στον πελάτη, και επειδή δεν βρήκα κάτι αντίστοιχο όσο και αν έψαξα, έφτιαξα αυτό το poster για να κάνω την δουλειά μου ευκολότερα και το μοιράζομαι μαζί σας.
    Θα το βρήτε εδώ.
    Ελπίζω να σας αρέσει.
  6. antonch
    Για τους αγαπητούς μου developers και όχι μόνο ;-) στο παρακάτω Link υπάρχουν παραδείγματα για το πως να φτιάξουν το connection string με το οποίο θα συνδέσουν την εφαρμογή τους με τον SQL Server 2008.
    http://www.connectionstrings.com/sql-server-2008
  7. antonch
    Εισαγωγή
    Έχοντας σχεδιάσει το DW και αφού έχουμε κάνει data analysis and profiling είμαστε πλέον στο σημείο που πρέπει να δημιουργήσουμε την διαδικασία που θα μεταφέρει τα δεδομένα από την πηγή (data source) στο DW.
    Μια τέτοια διαδικασία είναι γνωστή σαν ETL Process και περιλαμβάνει τα στάδια του
    Extract data from data source Transform data Load data to destination (data warehouse tables) Μια τέτοια διαδικασία θα πρέπει να σχεδιαστεί έτσι ώστε να έχει την μέγιστη απόδοση (performance), κλιμάκωση (scalability) και διαχείριση/συντήρηση (manageability) για όλες τις παραπάνω φάσεις ξεχωριστά για την κάθε μία, αλλά και στο σύνολο της σαν διαδικασία.
    Σε αυτό το post θα ασχοληθούμε με την φάση του extract data form data source.
    Περισσότερα
  8. antonch
    Έχουμε φτάσει στο σημείο που θα πρέπει να γεμίσουμε με δεδομένα τους πίνακες που έχουμε στο DW. Και σε αυτή την φάση υπάρχουν θέματα στα οποία θα πρέπει να πάρω αποφάσεις για αυτά.
    Surrogate Keys
    Η πρώτη βασική απόφαση είναι για το πώς θα δημιουργώ τα surrogate keys στους πίνακες που έχω τέτοια όπως πχ στους dimension tables. Υπάρχουν δύο βασικές «σχολές».
    Η μία λέει ότι αφήνω την βάση να δίνει τιμή σε αυτό με την χρήση identity columns. H συγκεκριμένη «σχολή» έχει σαν πλεονεκτήματα ότι
    δεν δίνει overhead στην διαδικασία ETL καθώς αυτόματα δίνεται τιμή κατά την εισαγωγή νέας έγγραφής από την βάση. μπορείς να ελέγξεις από που θα ξεκινάς και πως θα ανεβαίνεις (seed,increment) μπορώ να έχω concurrency καθώς με την αυτόματη ανάθεση τιμής σε αυτό από την βάση δεν θα έχω duplicate key values περισσότερα
  9. antonch
    Σε αρκετές περιπτώσεις κατά την εκτέλεση ενός ETL process με το οποίο μεταφέρουμε τα δεδομένα μια πηγής στο DW και ειδικότερα κατά την στιγμή που κάνουμε extract data from data sources και πριν την επόμενη φάση του data transformation χρειάζεται σε αρκετές περιπτώσεις να αποθηκεύσουμε αυτά τα δεδομένα σε μια staging area είτε προσωρινά είτε μόνιμα.
    see more
  10. antonch
    Σε συνέχεια των προηγούμενων μου post που σχετίζονται με την διαδικασία ETL με την οποία μεταφέρονται τα δεδομένα από την πηγή στο DW στα οποία είδαμε τι πρέπει να προσέξουμε στην φάση extract και στην χρήση της staging area, έφτασε η στιγμή να μιλήσουμε για την φάση του data transformation.
    Η φάση αυτή είναι ίσως η δυσκολότερη σε σχέση με τις άλλες και μάλιστα απαιτεί και περισσότερο χρόνο ανάπτυξης. Σημαντικό αξίωμα (όπως λέμε στα μαθηματικά) για την υλοποίηση της είναι η κατανόηση με σαφήνεια των απαιτήσεων αλλά και των δεδομένων που...
    περισσότερα
  11. antonch
    Όπως εδώ και καιρό έχει γίνει γνωστό από την ανακοίνωση της Microsoft ο SQL Server 2012 θα είναι η τελευταία έκδοση που θα υποστηρίζει τον SQL Server Native Client OLE DB provider καθώς αυτός θα πρόκειται να σταματήσει να αναπτύσσεται.

    Ο αντικαταστάτης του θα είναι ένας παλιός γνώριμος το ODBC
    read more
  12. antonch
    Επειδή το security στη database είναι αρκετά σημαντικό και πραγματικά δεν ξέρω γιατί οι περισσότεροι δεν δίνουν την πρέπουσα σημασία σε αυτό το σύντομο post θα σας δώσω ένα tip του οποίου η εφαρμογή ξεπερνάει το 99% των περιπτώσεων.
     
    http://www.sqlschool.gr/blog/create-a-db_executor-database-role-1013.aspx
  13. antonch
    Πριν από λίγο ήμουν με ένα φίλο και συνάδελφο και κάναμε διάφορα πραγματάκια σε μία βάση. Κάποια στιγμή θέλαμε να αλλάξουμε την τιμή από ένα πεδίο σε ένα record σε null και βαριόμουν να κάτσω να γράψω ένα update statement. Έτσι άνοιξα τον SSMS και με την γνωστή διαδικασία δεξι κλικ Edit πάνω στο πίνακα που θέλω στην βάση μου πήγα στο πεδίο και πάτησα Ctrl+0 όπου αμέσα γίνεται null η τιμή του και το μόνο που έχεις να κάνει είναι να πας στην επόμενη εγγραφή για να γινει commit η αλλαγή σου. Η κίνηση αυτή ξάφνιασε τον φίλο και συνάδελφο μιας και είναι από τους δυνατούς παίχτες έτσι σκέφτηκα να τα μοιραστώ με περισσότερους που ίσως δεν το γνώριζαν.
  14. antonch
    By
    Abhishek Sinha


    The Microsoft SQL
    Server Sustained Engineering team is proud to announce the release of SQL Server
    2008 R2 Cumulative Update 7.
    Cumulative Update 7 contains a roll-up of hotfixes released since the initial
    release of SQL Server 2008 R2.
    CU#7 KB Article:
    http://support.microsoft.com/kb/2489376 Understanding
    Incremental Servicing
    Model for SQL Server
    SQL Server Support Information:
    http://support.microsoft.com/ph/2855
    Previous
    Cumulative Update KB
    Articles:
    CU#6 KB Article:
    http://support.microsoft.com/kb/2489376 CU#5 KB Article:
    http://support.microsoft.com/kb/2438347 CU#4 KB Article:
    http://support.microsoft.com/kb/2345451 CU#3 KB Article:
    http://support.microsoft.com/kb/2261464 CU#2 KB Article:
    http://support.microsoft.com/kb/2072493 CU#1 KB Article:
    http://support.microsoft.com/kb/981355

    Abhishek
    Sinha
    Program Manager
    SQL Server
    Sustained Engineering
  15. antonch
    Συνεχίζοντας την σειρά των post που αφορούν την υλοποίηση ενός DW για την κάλυψη των αναγκών μιας BI λύσης θα ασχοληθούμε σε αυτό με τον logical design του DW.
    Όπως έχω ήδη αναφέρει σε παλαιότερα post ένα DW είναι ο θεμέλιος λίθος καθώς σε αυτό γίνονται τα ερωτήματα που θα δώσουν τις απαντήσεις σε αυτούς που πρέπει να λάβουν αποφάσεις. Έτσι αυτό θα πρέπει σαν Νούμερο Ένα Απαίτηση να είναι έτσι φτιαγμένο ώστε να υποστηρίζει γρήγορο διάβασμα (optimized for data read operations).
    Ανάμεσα στις δύο κυρίαρχες μεθοδολογίες για την υλοποίηση ενός DW (Inmon Vs Kimball) πιστεύω ότι η μεθοδολογία του Kimball η οποία ορίζει το dimensional modeling είναι αυτή που, κατά την γνώμη μου πάντα, ταιριάζει.
    Περισσότερα
  16. antonch
    Αφού έχουμε σχεδιάσει λογικά και σύμφωνα με τις επιχειρησιακές
    απαιτήσεις το DW μας, φτάνει η στιγμή που πρέπει να το κάνουμε πραγματικότητα
    υλοποιώντας το φυσικά.



    Όπως έχω αναφέρει σε όλα τα προηγούμενα post αυτής της σειράς
    θα πρέπει φυσικά να υλοποιήσω το DW λαμβάνοντας σοβαρά υπόψη μου τους εξής
    παράγοντες που δεν είναι άλλοι από τους performance, scalability, manageability.



    Με αυτούς σαν πυξίδα θα πρέπει να





    Περισσότερα
  17. antonch
    Διαβάζοντας το τελευταίο άρθρο του Jonathan Kehayias διαπίστωσα ότι έχω πολύ καιρό να γράψω κάτι για τα internals του SQL Server.
    Μέσα στο άρθρο αυτό του Jonathan υπάρχουν αναφορές σε κάποια ειδικά pages που υπάρχουν σε κάθε database στον SQL Server. Με αφορμή αυτό αποφάσισα να γράψω το post αυτό και να αναφερθώ σε όλα αυτά το special pages.
    Page structure and page offset
    Πριν ξεκινήσω όμως την αναφορά μου σε αυτά θα πρέπει να είμαι σίγουρος ότι όλοι γνωρίζουμε ότι κάθε data file σε μια SQL Server database δομείτε εσωτερικά σε pages των 8ΚΒ. Σε αυτά αποθηκεύονται τα δεδομένα του SQL Server. Ένα page έχει τον page header που είναι 96 bytes και το offset array το οποίο βρίσκεται στο τέλος του page, είναι 36 bytes και παρέχει τους δείκτες (pointers) στο byte location της αρχής της κάθε γραμμής (record) που είναι στην συγκεκριμένη σελίδα.

    Αυτό είναι αποθηκευμένο αντίστροφα πάνω στην σελίδα δηλαδή το offset του πρώτου record είναι στο τέλος του συγκεκριμένου array το δεύτερο είναι προτελευταίο κ.ο.κ.

    Το υπόλοιπο τμήμα (8060 bytes) είναι ο χώρος στον οποίο αποθηκεύονται τα records. Αυτός είναι και ο λόγος που λέμε ότι το max record length δεν μπορεί να είναι πάνω από 8060 bytes καθώς ένα record δεν μπορεί να είναι σπασμένο σε δύο pages.
    Extents
    Κάθε 8 τέτοιες σελίδες φτιάχνουν ένα extent. Υπάρχουν δύο είδη extent
    read more
  18. antonch
    Χρόνια Πολλά σε όλους!
    Εύχομαι ο νέος χρόνος να φέρει υγεία, αγάπη και ευτυχία σε εσάς και τις οικογένειες σας.
    Αυτές τι μέρες βρήκα την ευκαιρία να διαβάσω αρκετά νέα βιβλία τα οποία είχα προμηθευτεί επί τούτου. Μέσα σε όλα αυτά ξεχώρισα τ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.

  19. antonch
    Το PAGEIOLATCH wait type δείχνει το χρόνο που χρειάστηκε για να διαβαστεί μια σελίδα από το δίσκο και να μπει στην μνήμη (buffer cache)
  20. antonch
    Αρκετές φορές έχω αναφέρει κατά την διάρκεια των μαθημάτων και των παρουσιάσεων που κάνω για την αρχιτεκτονική μιας βάσης, ότι τα data files χωρίζονται σε σελίδες των 8K, κάθε 8 τέτοιες σελίδες αποτελούν ένα extent και ότι υπάρχουν δύο είδη extent τα uniform και τα mixed.
    Uniform είναι αυτά που οι 8 σελίδες τους ανήκουν σε ένα object πχ στον πίνακα των πελατών, ενώ mixed είναι αυτά που οι 8 σελίδες τους ανήκουν σε διαφορετικά.

    Επανειλημμένα έχω αναφέρει ότι σε κάθε πίνακα οι πρώτες 8 σελίδες του ανήκουν σε mixed extend και από την 9 και μετά πάνε σε uniform extent.
    Είναι αρκετά χρήσιμο να γνωρίζω το πως έχει γίνει αυτή κατανομή των σελίδων σε extents καθώς θα με βοηθήσει να καταλάβω το πως θα διαβαστούν τα δεδομένα μου αλλά και να μπορώ να καταλάβω το πιθανό fragmentation που θα εμφανιστεί.
    Τι κάνει η DBCC EXTENTINFO;
    Για όλους αυτούς του λόγους είναι χρήσιμο να γνωρίζω την ύπαρξη της DBCC EXTENTINFO. Η συγκεκριμένη ανήκει στην κατηγορία των undocumented dbcc commands, αλλά είναι γνωστή σε όσους ασχολούνται συστηματικά με τον SQL Server.
    Η εκτέλεση της επιστρέφει ένα dataset του οποίου η κάθε γραμμή αντιπροσωπεύει ένα extent στην βάση μου εάν αυτό είναι uniform και πολλές (μέχρι 8) αν είναι mixed.
    περισσότερα


  21. antonch
    Αν και η συγκεκριμένη εντολή είναι ευρέως γνωστή και σίγουρα θα την έχετε βρει σε διάφορα sites εντούτοις θα γράψω και εγώ για αυτή καθώς θεωρώ ότι είναι μια σημαντική εντολή αν και είναι undocumented. Φυσικά μπορούμε με ασφάλεια να την χρησιμοποιήσουμε σε παραγωγικά συστήματα χωρίς φόβο και πάθος.
    Με αυτή μπορούμε να δούμε αναλυτικές πληροφορίες για τους indexes σε ένα συγκεκριμένο object ανά σελίδα.
    Η σύνταξη της εντολής είναι η παρακάτω
    DBCC IND
    (
    {‘dbname’|dbid}
    , {‘objectname’|objectid}
    , {nonclustered index id | 0 | 1 | -1 | -2 }
    [, partition number]
    )

    Υποχρεωτικές είναι οι πρώτες τρεις παράμετροι, αναλυτικά




    {‘dbname’|dbid}




    Σε αυτή δίνουμε είτε το όνομα της βάσης είτε το dbid αυτής το οποίο μπορούμε να πάρουμε είτε κάνοντας ερώτημα στο sys.databases είτε χρησιμοποιώντας την db_id metadata function του SQL Server.






    {‘objectname’|objectid}




    Σε αυτή δίνουμε τον πίνακα ή το indexed view για το οποίο θέλουμε να δούμε τον/τους indexes του. Αυτό γίνεται είτε δίνοντας το όνομα του είτε χρησιμοποιώντας τη object_id metadata function.






    {nonclustered index id | 1 | 0 | -1 | -2 }




    Σε αυτή δίνουμε το index id ενός nonclustered index (το εύρος των τιμών είναι από 2-250 και 256-1005) και παίρνουμε πληροφορίες για όλες τις IAM, data pages, indexes pages ενός index ή μία από τις παρακάτω τιμές




    0




    Δίνοντας αυτή την τιμή παίρνουμε πληροφορίες για τα in-row data pages και IAM pages in-row και σε αυτές, φυσικά για το object το οποίο έχουμε ορίσει παραπάνω.






    1




    Δίνοντας αυτή την τιμή παίρνουμε πληροφορίες που αφορούν όλα τα pages (IAM, data pages, LOB pages/row overflow pages), αν στο object που έχουμε δώσει υπάρχει clustered index συμπεριλαμβάνεται.






    -1




    Δίνοντας αυτή την τιμή παίρνουμε πληροφορίες για ΟΛΟΥΣ τους indexes που υπάρχουν στο object που διερευνούμε.






    -2




    Δίνοντας αυτή την τιμή παίρνουμε πληροφορίες για όλες τις ΙΑΜ που υπάρχουν στο συγκεκριμένο object.










    Το αποτέλεσμα το οποίο επιστρέφεται από την εκτέλεση της εντολής περιέχει τα παρακάτω στοιχεία




    PageFID




    Το File ID στο οποίο ανήκει η σελίδα






    PagePID




    Ο αριθμός της σελίδας στο αρχείο (FileID)






    IAMFID




    Το file id στο οποίο η ΙΑΜ υπάρχει






    IAMPID




    Ο αριθμός της σελίδας στο αρχείο






    ObjectID




    Το object ID






    IndexID




    O αριθμός του index (0-250 & 256-1005)






    PartitionNumber




    To partition number






    PartitionID




    To partition ID






    IAM_Chain_Type




    Ο τύπος του allocation στην σελίδα (in-row, row-overflow, LOB)






    PageType




    1=data page, 2=index page, 3= text mixed page, 4 = text tree page, 10 = IAM






    IndexLevel




    0= leaf level , 1,2,3… = τα παραπάνω levels






    NextPageFID




    Το File ID που περιέχει την επόμενη σελίδα του συγκεκριμένου level






    NextPagePID




    Το αρχείο που περιέχει την επόμενη σελίδα του συγκεκριμένου level






    PrevPageFID




    Το File ID που περιέχει την προηγούμενη σελίδα του συγκεκριμένου level






    PrevPagePID




    Το αρχείο που περιέχει την προηγούμενη σελίδα του συγκεκριμένου level



  22. antonch
    Για ακόμα μια φορά θα πρέπει να ασχοληθούμε με το transaction log. Καθημερινά αντιμετωπίζω περιστατικά τα οποία μου δείχνουν ότι υπάρχει θέμα κατανόησης με την αξία, την λειτουργία αλλά και την χρήση του transaction log. Η βασική ερώτηση που μου έχει τεθεί αρκετές φορές και έχω γράφει αρκετά άρθρα για αυτή είναι γνωστή πλέον και αφορά το μέγεθος του transaction log file. Αν έχετε έρθει για πρώτη φορά στο blog αυτό μια απλή αναζήτηση εδώ θα σας φέρει αρκετά άρθρα για το θέμα αυτό. Αλλά αν ψάξετε και στον internet θα βρείτε ακόμα περισσότερα.
    Αρκετές φορές έχω περιγράψει την φυσική δομή μιας βάσης τόσο μέσα από τα μαθήματα που κάνω όσο και από εδώ ή τα SQL Server Saturday Nights. Σε όλες αυτές τις περιπτώσεις έχω τονίσει ότι το transaction log εσωτερικά δομείται σε virtual log files (VLFs). Επίσης αρκετές φορές έχω αναφέρει ότι το transaction log γίνεται truncate μόνο όταν παίρνουμε transaction log backup (εφόσον είμαστε σε full ή bulk recovery model). Και ακόμα αρκετές φορές έχω αναφέρει ότι σε αυτή την περίπτωση γίνεται truncate το μη ενεργό κομμάτι αυτού το ή τα οποίο(α) δεν είναι άλλο(α) από τα VLFs που δεν έχουν ενεργό(α) transaction(s).
    Για όσους λοιπόν αναρωτιούνται τι γίνεται με το transaction log τους και πώς θα συμπεριφερθεί στο επόμενο transaction log backup ή ακόμα καλύτερα θέλουν να βάλουν το δάκτυλο επί τον τύπο τον ήλο, υπάρχει ένα undocumented αλλά ευρέως γνωστό και φυσικά χρησιμοποιούμενο dbcc command και δεν είναι άλλο από το DBCC LOGINFO.
    Το command αυτό μας δίνει πληροφορίες για τα VLFs που υπάρχουν μέσα στο transaction log της βάσης μας
    Η εκτέλεση του είναι αρκετά απλή καθώς η μόνη παράμετρος που παίρνει το όνομα της βάσης.
    dbcc loginfo (AdventureWorks2008R2)
    Το αποτέλεσμα που βγάζει έχει την παρακάτω μορφή

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 458752 8192 46 2 64 0
    2 458752 466944 43 0 128 0
    2 458752 925696 44 0 128 0
    2 712704 1384448 45 0 128 0
    Ας δούμε όμως λίγο τι είναι το κάθε πεδίο που μας εμφανίζεται από την εκτέλεση της dbcc loginfo.



    FileID : To ID του αρχείου στην συγκεκριμένη βάση

    FileSize : Το μέγεθος του VLF σε bytes

    StartOffset : Το σημείο αρχής του VLF

    FSeqNo : Το sequence number του VLF

    Status: Η κατάσταση του VLF 0=Inactive, 2=Active

    Parity : Parity info για το VLF

    CreateLSN : To Log Sequence Number με το οποίο ξεκινάει το VLF
    Ας δούμε λίγο τα πράγματα με ένα απλό παράδειγμα

    Δημιουργώ μια βάση

    use master
    go

    create database DemoDB
    on primary

    ( name='demodb_data',
    filename='c:\temp\demodb_data.mdf',
    size=10MB
    )
    log on
    ( name='demodb_log',
    filename='c:\temp\demodb_log.ldf',
    size=5MB
    )
    go


    Με αυτό έχω φτιάξει μια βάση με μέγεθος data file 10MB και log file 5ΜΒ

    Εκτελώ την dbcc loginfo (demodb) και έχω το εξής

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 28 2 64 0
    2 1245184 1253376 0 0 0 0
    2 1245184 2498560 0 0 0 0
    2 1499136 3743744 0 0 0 0

    Από το αποτέλεσμα καταλαβαίνω ότι έχω ένα transaction log το οποίο έχει τέσσερα VLFs, από τα οποία χρησιμοποιείται το πρώτο καθώς το Status=2. Το μέγεθος των VLFs είναι περίπου 1,2 ΜΒ.

    Δημιουργώ έναν πίνακα

    create table T
    ( id int identity(1,1) primary key,
    data char(8000) default 'abcdefghijklmnopqrstuvwxyz'
    )
    go


    Και τον γεμίζω με 1000 εγγραφές

    insert into T default values
    go 1000

    Εκτελώντας την DBCC LOGINFO έχω το εξής αποτέλεσμα

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 32 0 128 0
    2 1245184 1253376 33 0 128 0
    2 1245184 2498560 34 2 128 0
    2 1499136 3743744 35 2 128 0

    Παρατηρόντας το βλέπουμε ότι έχουν γεμίζει σειριακά το VLFs (FSeqNo) και ότι τα ενεργά είναι τα δύο τελευταία (Status=2).

    Αν κάνω checkpoint και μετά δω ξανά το log με την dbcc θα έχω το εξής αποτέλεσμα

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 32 0 128 0
    2 1245184 1253376 33 0 128 0
    2 1245184 2498560 34 0 128 0
    2 1499136 3743744 35 2 128 0

    Παρατηρώ ότι μόνο το τελευταίο VLF είναι πλεόν ενεργό

    Βάζω ακόμα 1000 εγγραφές στον πίνακα μου και έχω το εξής αποτελεσμα μετά από την εκτέλεση της dbcc

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 40 0 128 0
    2 1245184 1253376 41 2 128 0
    2 1245184 2498560 42 2 128 0
    2 1499136 3743744 39 0 64 0

    Παρατηρώ ότι τα δύο μεσαία είναι ενεργά. Παίρνω το πρώτο full backup και το πρώτο log backup



    backup database demodb to disk='c:\temp\demodb.bak'
    go

    backup log demodb to disk='c:\temp\demodb.bak'
    go


    Eκτελώ την dbcc το αποτέλεσμα είναι το παρακάτω



    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 40 0 128 0
    2 1245184 1253376 41 0 128 0
    2 1245184 2498560 42 2 128 0
    2 1499136 3743744 39 0 64 0

    Βάζω μια εγγραφή που δεν την κάνω commit στο transaction

    BEGIN TRAN
    insert into T default values



    και παράλληλα από ένα άλλο session βάζω ακόμα 1000 εγγραφές, εκτελώ την dbcc από την οποία έχω το εξής απότελεσμα

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 44 2 64 0
    2 1245184 1253376 45 2 64 0
    2 1245184 2498560 42 2 128 0
    2 1499136 3743744 43 2 128 0
    2 253952 5242880 46 2 64 45000000203100009
    2 270336 5496832 47 2 64 45000000203100009
    2 253952 5767168 48 2 64 47000000014000009
    2 335872 6021120 49 2 64 47000000014000009
    2 253952 6356992 50 2 64 49000000026900009
    2 401408 6610944 51 2 64 49000000026900009
    2 253952 7012352 52 2 64 51000000038300009
    2 466944 7266304 53 2 64 51000000038300009
    2 253952 7733248 54 2 64 53000000052200013
    2 253952 7987200 55 2 64 53000000052200013
    2 278528 8241152 56 2 64 53000000052200013
    2 253952 8519680 57 2 64 56000000014100015
    2 253952 8773632 58 2 64 56000000014100015
    2 344064 9027584 59 2 64 56000000014100015
    2 253952 9371648 60 2 64 59000000028700003
    2 253952 9625600 61 2 64 59000000028700003
    2 475136 9879552 62 2 64 59000000028700003
    2 253952 10354688 63 2 64 62000000054000009
    2 253952 10608640 0 0 0 62000000054000009
    2 253952 10862592 0 0 0 62000000054000009
    2 286720 11116544 0 0 0 62000000054000009

    Χωρίς άλλη σκέψη παίρνω transaction log backup και εκτελώ την dbcc

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 44 2 64 0
    2 1245184 1253376 45 2 64 0
    2 1245184 2498560 42 2 128 0
    2 1499136 3743744 43 2 128 0
    2 253952 5242880 46 2 64 45000000203100009
    2 270336 5496832 47 2 64 45000000203100009
    2 253952 5767168 48 2 64 47000000014000009
    2 335872 6021120 49 2 64 47000000014000009
    2 253952 6356992 50 2 64 49000000026900009
    2 401408 6610944 51 2 64 49000000026900009
    2 253952 7012352 52 2 64 51000000038300009
    2 466944 7266304 53 2 64 51000000038300009
    2 253952 7733248 54 2 64 53000000052200013
    2 253952 7987200 55 2 64 53000000052200013
    2 278528 8241152 56 2 64 53000000052200013
    2 253952 8519680 57 2 64 56000000014100015
    2 253952 8773632 58 2 64 56000000014100015
    2 344064 9027584 59 2 64 56000000014100015
    2 253952 9371648 60 2 64 59000000028700003
    2 253952 9625600 61 2 64 59000000028700003
    2 475136 9879552 62 2 64 59000000028700003
    2 253952 10354688 63 2 64 62000000054000009
    2 253952 10608640 0 0 0 62000000054000009
    2 253952 10862592 0 0 0 62000000054000009
    2 286720 11116544 0 0 0 62000000054000009

    Κανω commit το transaction που είχα αφήσει πριν και ξαναπαίρνω log backup και εκτελώ την dbcc

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 44 0 64 0
    2 1245184 1253376 45 0 64 0
    2 1245184 2498560 42 0 128 0
    2 1499136 3743744 43 0 128 0
    2 253952 5242880 46 0 64 45000000203100009
    2 270336 5496832 47 0 64 45000000203100009
    2 253952 5767168 48 0 64 47000000014000009
    2 335872 6021120 49 0 64 47000000014000009
    2 253952 6356992 50 0 64 49000000026900009
    2 401408 6610944 51 0 64 49000000026900009
    2 253952 7012352 52 0 64 51000000038300009
    2 466944 7266304 53 0 64 51000000038300009
    2 253952 7733248 54 0 64 53000000052200013
    2 253952 7987200 55 0 64 53000000052200013
    2 278528 8241152 56 0 64 53000000052200013
    2 253952 8519680 57 0 64 56000000014100015
    2 253952 8773632 58 0 64 56000000014100015
    2 344064 9027584 59 0 64 56000000014100015
    2 253952 9371648 60 0 64 59000000028700003
    2 253952 9625600 61 0 64 59000000028700003
    2 475136 9879552 62 0 64 59000000028700003
    2 253952 10354688 63 2 64 62000000054000009
    2 253952 10608640 0 0 0 62000000054000009
    2 253952 10862592 0 0 0 62000000054000009
    2 286720 11116544 0 0 0 62000000054000009

    Βάζω ακόμα 1000 εγγραφές και εκτελώ την dbcc

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 69 2 128 0
    2 1245184 1253376 70 2 128 0
    2 1245184 2498560 67 2 64 0
    2 1499136 3743744 68 2 64 0
    2 253952 5242880 71 2 128 45000000203100009
    2 270336 5496832 72 2 128 45000000203100009
    2 253952 5767168 73 2 128 47000000014000009
    2 335872 6021120 74 2 128 47000000014000009
    2 253952 6356992 75 2 128 49000000026900009
    2 401408 6610944 76 2 128 49000000026900009
    2 253952 7012352 77 2 128 51000000038300009
    2 466944 7266304 78 2 128 51000000038300009
    2 253952 7733248 79 2 128 53000000052200013
    2 253952 7987200 80 2 128 53000000052200013
    2 278528 8241152 81 2 128 53000000052200013
    2 253952 8519680 82 2 128 56000000014100015
    2 253952 8773632 58 0 64 56000000014100015
    2 344064 9027584 59 0 64 56000000014100015
    2 253952 9371648 60 0 64 59000000028700003
    2 253952 9625600 61 0 64 59000000028700003
    2 475136 9879552 62 0 64 59000000028700003
    2 253952 10354688 63 2 64 62000000054000009
    2 253952 10608640 64 2 64 62000000054000009
    2 253952 10862592 65 2 64 62000000054000009
    2 286720 11116544 66 2 64 62000000054000009

    Από όλα τα παραπάνω βλέπω παρατηρώντας τα FSeqNo και Status ποια VLF είναι ενεργά και ποια όχι έτσι βλέπω πως γίνεται η ανακύκλωση του transaction log εσωτερικά και ποια είναι αυτά το VLFs τα οποία έχουν γίνει truncate.

    Αυτό μου είναι χρήσιμο ακόμα όταν θέλω να κάνω shrink το log file καθώς όπως έχουμε πει αρκετές φορές για να γίνει shrink θα πρέπει τα μην ενεργά VLFs να είναι στο τέλος όχι όπως στο παραπάνω δείγμα όπου αν είμαι σε αυτή την περίπτωση θα πρέπει να παίρνω ανεπάληλα transaction log backups ώστε να φτάσω σε μια μορφή όπως αυτή

    FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    2 1245184 8192 44 2 64 0
    2 1245184 1253376 45 2 64 0
    2 1245184 2498560 42 2 128 0
    2 1499136 3743744 43 2 128 0
    2 253952 5242880 46 2 64 45000000203100009
    2 270336 5496832 47 2 64 45000000203100009
    2 253952 5767168 48 2 64 47000000014000009
    2 335872 6021120 49 2 64 47000000014000009
    2 253952 6356992 50 2 64 49000000026900009
    2 401408 6610944 51 2 64 49000000026900009
    2 253952 7012352 52 2 64 51000000038300009
    2 466944 7266304 53 2 64 51000000038300009
    2 253952 7733248 54 2 64 53000000052200013
    2 253952 7987200 55 2 64 53000000052200013
    2 278528 8241152 56 2 64 53000000052200013
    2 253952 8519680 57 2 64 56000000014100015
    2 253952 8773632 58 2 64 56000000014100015
    2 344064 9027584 59 2 64 56000000014100015
    2 253952 9371648 60 2 64 59000000028700003
    2 253952 9625600 61 2 64 59000000028700003
    2 475136 9879552 62 2 64 59000000028700003
    2 253952 10354688 63 2 64 62000000054000009
    2 253952 10608640 0 0 0 62000000054000009
    2 253952 10862592 0 0 0 62000000054000009
    2 286720 11116544 0 0 0 62000000054000009

    SQL Server ‘Denali’

    Επειδή αρκετοί από εσάς φαντάζομαι ότι ήδη έχετε αρχίσει και βλέπετε την επόμενη έκδοση του SQL Server με την κωδική ονομασία Denali, πιθανότατα να έχετε εκτελέσει ή να εκτελέσετε την dbcc αυτή. Σε κάθε περίπτωση θα βρεθείτε σε μια έκπληξη καθώς σε αυτή υπάρχει νέα κολώνα και δεν είναι άλλη από την πρώτη με την ονομασία RecoveryUnitID όπου σε όλες τις γραμμές που θα εμφανιστούν έχει την τιμή μηδέν (0). Για την ενημέρωση σας χωρίς να έχω την εξουσιοδότηση να μπω σε περισσότερες λεπτομέρειες λόγω NDA, η κολώνα αυτή θα έχει πρακτική αξία στην μετά Denali έκδοση του SQL Server.

    RecoveryUnitId FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
    -------------- ----------- -------------------- -------------------- ----------- ----------- ------ ---------------------------------------
    0 2 253952 8192 49 2 128 0
    0 2 253952 262144 44 0 64 0
    0 2 270336 516096 45 0 64 43000000003000331
    0 2 262144 786432 46 0 64 44000000013600398
    0 2 262144 1048576 47 0 64 44000000038000359
    0 2 262144 1310720 48 0 64 45000000025400069
  23. antonch
    Εισαγωγή

    Για άλλη μια φορά σήμερα ευλογώ τον Θεό που μου έχει δώσει την δυνατότητα να κάνω αυτή την δουλειά καθώς μου δίνει την δυνατότητα σε τακτά χρονικά διαστήματα να μαθαίνω κάτι νέο.
    Αυτό που έμαθα σήμερα κατά την καθημερινή μου ενασχόληση με τον SQL Server θα ήθελα να το μοιραστώ μαζί σας και είμαι  αρκετά χαρούμενος για αυτό καθώς το αγαπημένο μου προϊόν ο SQL Server μου χαρίζει αυτές τις συγκινήσεις.
     

    Η ανάγκη

    Ας έρθουμε όμως στο ζουμί. Σαν DBA ή DB Dev καθημερινά γράφεις queries. Αρκετές φορές μέχρι κάποια πάνε σφαίρα κάποια πάνε αργά και γενικά είσαι μέσα σε μια ατέρμονη διαδικασία τα αργά να τα κάνεις να πάνε γρήγορα και τα γρήγορα γρηγορότερα.

    περισσότερα
  24. antonch
    Οι περισσότεροι είστε σε κάποιον παραθαλάσσιο μέρος και καλά κάνετε. Παρόλα αυτά όμως τα SQL Saturday Nights ακόμα δεν έχουν τελειώσει, απλά αντί να σας βάζω σε διαδικασίες να τα παρακολουθήσετε live αποφάσισα να φτιάξω ένα απόψε καθώς θέλω να αναδείξω ένα θέμα το οποίο οι περισσότεροι δεν γνωρίζετε ή το γνωρίζετε λίγο ή ακόμα και για αυτούς που το γνωρίζουν δεν είναι κακό να το ξαναδούν.
    Αφορά τον αριθμό των VLFs (Virtual Log Files) που έχει ένα transaction log σε μία database στον SQL Server και πως όταν αυτός ο αριθμός είναι αρκετά μεγάλος επηρεάζει την απόδοση μιας datatase.
    περισσότερα
  25. antonch
    Επιτέλους η στιγμή την οποία περίμενα εδώ και 1 χρόνο έφτασε.
    Μπορώ να σπάσω την σιωπή μου και να ανακοινώσω ότι πλέον είναι διαθέσιμη σε όλους η νέα έκδοση του SQL Server την οποία μπορείτε να βρείτε στο παρακάτω link
    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6a04f16f-f6be-4f92-9c92-f7e5677d91f9
    Πολλά έχουν αλλάξει, ακόμα περισσότερα έχουν προσθεθεί. Για όλα αυτά όμως θα μου δωθεί η ευκαιρία να σας μιλήσω σε posts που θα ακολουθήσουν.
×
×
  • Create New...