Jump to content

antonch

Administrators
  • Posts

    1030
  • Joined

  • Last visited

  • Days Won

    7

Blog Entries posted by antonch

  1. antonch
    Αναζητώντας τρόπους για να εκτονώσω την όρεξη μου για εκπαίδευση αποφάσισα να κάνω κάτι μιας και δεν βλέπω να γίνεται κάτι άλλο αυτό τον καιρό.
    Η ιδέα μου ήρθε έτσι ξαφνικά σήμερα το βράδυ ακούγοντας την βροχή να πέφτει.
    Σκέφτηκα ότι τώρα που χειμωνιάζει και οι περισσότεροι θα είμαστε χωμένοι μέσα στην ζεστασιά του σπιτιού μας τα βράδια του Σαββάτου να διοργανώσω εκπαιδευτικά live meetings με θέματα που αφορούν τον SQL Server (και Visual Studio άμα θέλετε).
    Το concept όπως το έχω σκεφτεί έχει ως εξής:
    Κάθε δεύτερο Σάββατο γύρω στις 23:00 το βράδυ που όλοι θα είστε χαλαροί μιας και θα έχετε βάλει τις πυτζάμες σας, τις παντόφλες σας, και τα παιδία για ύπνο να βρισκόμαστε ηλεκτρονικά και να σας κάνω εκπαίδευση πάνω στο θέμα το οποίο είτε θα έχω επιλέξει είτε θα μου έχετε προτείνει εσείς.
    Φυσικά όλα αυτά θα είναι δωρεάν και θα έχει διάρκεια περίπου 2 ώρες.
    Επειδή δεν ξέρω αν αυτό θα έχει ανταπόκριση θα ήθελα τη γνώμη σας ώστε αν δω ότι είναι θετική να προχωρήσω στην διοργάνωση του.
    Για το λόγο αυτό θα ήθελα να ποστάρετε την απάντηση σας στο παρόν ποστ και φυσικά αν έχετε κάποιο θέμα που θα θέλατε να παρουσιαστεί.
    Επίσης καλό θα ήταν αυτό να το διαδώσετε και στους φίλους σας ώστε να μπουν και αυτοί να ψηφίσουν και φυσικά να θέσουν το θέμα τους
    Φιλικά
    Αντώνης
    Υ.Γ Θα παρακαλούσα να έχω τις απαντήσεις εδώ και όχι κάπου άλλου ώστε να τις έχω συγκεντρωμένες σε ένα σημείο
  2. antonch
    Πρόσφατα αγόρασα ένα netbook για να έχω κάποια πράγματα τα οποία ήθελα μαζί μου και να μην κουβαλάω μεγάλο βάρος. Θέλησα να βάλω Windows 7 αλλά όπως είναι γνωστό dvd αυτά δεν έχουν. Έτσι ψαχνοντας από εδώ και απο εκεί βρήκα την λύση που σας την δίνω εδω http://www.intowindows.com/how-to-install-windows-7vista-from-usb-drive-detailed-100-working-guide/ . Είμαι σίγουρος ότι οι περισσότεροι την ξέρετε αλλα ίσως υπάρχουν κάποιοι που δεν την γνωρίζουν οπότε καλό είναι να την ξέρουν. Βέβαια μπορεί να χρησιμοποιηθεί και για άλλους σκοπούς, ένα bootable USB είναι πάντα χρήσιμο δεν νομίζετε;
  3. antonch
    Σήμερα έλαβα ένα mail από το MVP Program το οποίο με ενημέρωνε ότι έγινα MVP στον SQL Server.
    Ήταν το πρώτο και μοναδικό mail που πήρα για το 2010 και με γέμισε χαρά, ικανοποίηση αλλά και υποχρεώσεις για το μέλλον.
    Θα ήθελα να ευχαριστήσω όλους σας για αυτό και ιδιαίτερα τον Νάσο Κλαδάκη και την Μάρθα Πετροπούλου για την βοήθεια τους και την προτροπή τους στο να προσπαθήσω για τον τίτλο αυτό.
    ΚΑΛΗ ΧΡΟΝΙΑ ΣΕ ΟΛΟΥΣ
  4. antonch
    Βλέποντας μέσα από το forum μας διάφορες συζητήσεις σχετικά με το θέμα του μεγέθους του transaction log (T-Log) διαπίστωσα ότι υπάρχει ένα θολό τοπίο γύρω από το θέμα disaster recovery (backup - restore) πάνω στον SQL Server.
    Πήρα την απόφαση να γράψω για αυτό το θέμα ώστε να το ξεκαθαρίσω μια και καλή διότι είναι τόσο απλό και τόσο δυνατό που είναι αμαρτία από το Θεό να παιδεύεται ο κόσμος.
    Πριν ξεκινήσω να παρουσιάζω το θέμα θα πρέπει να ξεκαθαρίσω, και θα ήθελα αυτό να το έχετε σαν αρχή, στον SQL Server παίρνουμε SQL Server Backup και όχι οτιδήποτε άλλο.
    Μέχρι σήμερα δεν σας έχω πει τίποτα για Ευαγγέλια, όσοι έχετε κάνει μάθημα μαζί μου όμως ξέρετε, σήμερα θα σας πω ένα από αυτά.
    Επίσης θεωρώ φρόνιμο να ρίξετε πρώτα μια ματιά σε αυτό το post μου διότι θα σας φανεί χρήσιμο για να κατανοήσετε το παρόν άρθρο.
    Database Recovery Models
    Πρώτα από όλα θα πρέπει να καταλάβουμε τι είναι τα database recovery models, τι κάνουν, ποια είναι και πως επηρεάζουν το disaster recovery strategy που θα ακολουθήσουμε.
    Simple Recovery Model
    Είναι το απλούστερο μοντέλο το οποίο μπορεί κάποιος να επιλέξει σε μια βάση δεδομένων.
    Ενδείκνυται για :
    1. μικρές βάσεις δεδομένων,
    2. για βάσεις που έχουν μικρό αριθμό αλλαγών (transactions),
    3. για τις περιπτώσεις που θέλουμε να έχουμε μικρό μέγεθος στο T-Log file,
    4. για βάσεις που είναι read-only,
    5. για τις βάσεις που είναι σε φάση development ή δουλεύουν developers με αυτές για την κατασκευή εφαρμογών.
    Το συγκεκριμένο μοντέλο δουλεύει με τον εξής τρόπο, κάθε φορά που γίνεται διαδικασία checkpoint ή φτάνει να γεμίσει το φυσικό αρχείο του T-Log file γίνεται αυτόματα truncate με αποτέλεσμα να επαναχρησιμοποιείτε ο εσωτερικά ελεύθερος χώρος.
    Το μειονέκτημα στο μοντέλο αυτό είναι ότι μπορείς να γυρίσεις στον τελευταίο full backup που έχεις πάρει στην περίπτωση που η βάση σκάσει.
    Full Recovery Model
    Είναι το default recovery model. Όλα τα transactions που γίνονται στην βάση καταγράφονται στην λεπτομέρεια τους σε επίπεδο data page και row και αυτό έχει σαν αποτέλεσμα να χρειάζεται περισσότερος χώρος για το T-Log file. Το πλεονεκτήματα του είναι ότι στις περιπτώσεις που έχω πτώση της βάσης μπορώ να γυρίσω ακριβώς στο σημείο της πτώσης της χάνοντας μόνο τα transactions που την στιγμή της πτώσης ήταν σε εξέλιξη δηλαδή δεν είχαν γίνει commit!.
    Bulk-Logged Recovery Model
    Είναι ίσως αυτό που πολλοί DBA δεν το έχουν καταλάβει πως δουλεύει!. Αυτό κάνει ακριβώς ότι κάνει και το Full Recovery Model με μια σημαντική διαφορά. Καταγράφει τα πάντα σε επίπεδο extent (8 συνεχόμενες σελίδες). Αυτό έχει σαν αποτέλεσμα να μπορώ να γυρίσω πάλι στο σημείο της πτώσης της βάσης αλλά χρειάζομαι περισσότερο χρόνο για να έρθει αυτή σε κατάσταση online.
    Για να γίνει κατανοητό αυτό ας πάρουμε σαν παράδειγμα το εξής:
    Έστω ότι έχω μια βάση που είναι σε Full Recovery Model και φτιάχνω ή συντηρώ κάποιον index που έχω σε αυτή. Αφού έχει τελειώσει η εργασία αυτή έστω ότι έχω πτώση της βάσης. Όταν θα κάνω restore η εργασία αυτή θα είναι έτοιμη. Εάν όμως είμαι σε Bulk-Logged Model τα πράγματα είναι λίγο διαφορετικά. Για να το κάνω πιο κατανοητό ας πούμε ότι καταγράφεται η ενέργεια και όχι το αποτέλεσμα της. Έτσι όταν θα κάνω restore θα πρέπει να ξανακάνει πάλι την ενέργεια αυτή, που όπως γίνεται εύκολα αντιληπτό από την φύση της ενέργειας θα πάρει χρόνο για να την ολοκληρώσει.
    Σε αυτό το μοντέλο όλες οι bulk εργασίες γίνονται logged με το ελάχιστο δυνατό τρόπο. Τέτοιες εργασίες είναι:
    · Bulk imports of data (BCP, BULK INSERT, OPENROWSET with BULK clause)
    · BLOB operations ( WRITETEXT, UPDATETEXT)
    · SELECT INTO statements
    · CREATE/ALTER INDEX, ALTER INDEX REBUILD, DBCC REINDEX
    Το μοντέλο αυτό είναι ιδανικό για περιπτώσεις που έχω data warehouses και βάσεις με μεγάλο όγκο από bulk εργασίες. Το μειονέκτημα του είναι δεν μπορώ να γυρίσω σε συγκεκριμένο σημείο (point-in-time) το οποίο όμως θα δούμε παρακάτω τι είναι αυτό.
    SQL Server Backup Types
    Για να δούμε όμως τις δυνατές επιλογές που έχουμε για backup στον SQL Server. Επίσης θα πρέπει να επισημάνω, κάτι το οποίο ισχύει για όλα τους τύπους, ότι μπορώ να πάρω backup ενώ υπάρχει κόσμος και δουλεύει πάνω στην βάση μου (το λέω γιατί μπορείς κάποιος να μην το έχει καταλάβει ότι αυτό γίνεται). Μπορώ να έχω όσα backups θέλω μέσα στην ημέρα αν αυτό δεν μου δημιουργεί προβλήματα απόδοσης στην βάση κατά τη στιγμή που γίνεται αυτή backup. Ναι υπάρχει κάποιο πέναλτι το οποίο επηρεάζεται από πολλούς παράγοντες όπως ταχύτητα μαγνητικών μέσων, μέγεθος βάσης και τύπος του backup.
    Full Backup
    Είναι η βάση για όλες τις άλλες επιλογές που έχω για backup στον SQL Server. Με άλλα λόγια δεν μπορώ να κάνω πχ Differential, Transaction, Tail-Log κλπ εάν δεν έχω πάρει έστω ένα Full Backup. Στην ουσία παίρνει τα πάντα backup με τον έξης τρόπο. Πρώτα κάνει την διαδικασία checkpoint όπου κατεβάζει με αυτή όλα τα data pages της βάσης, που παίρνω backup, από την buffer cache στον δίσκο και μετά ρουφάει σαν σκούπα hoover τα αρχεία από δίσκο και τα βάζει στο backup μου. Ο χρόνος εκτέλεσης μιας τέτοιας εργασίας είναι πάντα σχετικός με το μέγεθος το δεδομένων μου. Το μέγεθος του backup είναι πάντα το πραγματικό μέγεθος των δεδομένων που έχω στην βάση και όχι το φυσικό μέγεθος των αρχείων που υπάρχουν στο δίσκο. Εάν θέλει κάποιος να κάνει εκτίμηση του μεγέθους του Full Backup σε μια βάση του δεν έχει από το να εκτελέσει την sp_spaceused stored procedure και θα πάρει την απάντηση στο ερώτημα του. Επίσης θα πρέπει να γνωρίζουμε ότι Full Backup μπορώ να πάρω με οποιοδήποτε επιλεγμένο Recovery Model έχω στην βάση μου. Εν κατακλείδι ΠΑΝΤΑ FULL BACKUP είναι η ΒΑΣΗ ΟΛΩΝ.
    Στην ουσία το επόμενο full backup που θα πάρω περιέχει μέσα του όλα τα προηγούμενα.
    Differential Backup
    Για να πάρω Differential Backup πρέπει να έχω πάρει Full Backup. Μπορώ να πάρω diffrential backup με όλα τα recovery models. Κάθε τέτοιου τύπου backup περιέχει ΟΛΕΣ τις αλλαγές που έχουν γίνει από το τελευταίο Full Backup που έχω πάρει. Στην ουσία κάθε νέο differential backup "καταργεί" όλα τα προηγούμενα diffential backups.
    Ας πάρουμε ένα παράδειγμα. Έστω ότι έχω πάρει full backup στις 05:00 και στις 10:00 παίρνω differential backup. Αυτό περιέχει ότι έχει γίνει από τις 05:00 μέχρι τις 10:00. Εάν στις 13:00 ξαναπάρω differential αυτό περιέχει ότι έχει γίνει από τις 05:00 μέχρι τις 13:00.
    Ελπίζω αυτό να έγινε κατανοητό διότι αρκετοί συνάδελφοι πιστεύουν ότι το κάθε differential περιέχει τις αλλαγές από το τελευταίο backup.
    Ιδανικό σενάριο για μεγάλες βάσεις που το full backup παίρνει χρόνο. Επίσης το χρησιμοποιούμε και για να μειώσουμε τον αριθμό των αρχείων αλλά και το χρόνο που θα χρειαστούμε σε περίπτωση που θελήσουμε να κάνουμε restore.
    Transaction Log Backup
    Αυτός ο τύπος backup παίζει μόνο εφόσον στην βάση μου έχω FULL ή BULK-LOGGED Recovery Model.
    Φυσικά για να πάρω T-Log backup θα πρέπει να έχω πάρει ένα full backup. Κάθε T-Log backup περιέχει τα transactions που έχουν γίνει στην βάση μου για το χρονικό διάστημα από το τελευταίο full ή differential ή t-log backup. Ο χρόνος που απαιτείται για αυτό συνήθως είναι μικρός και το πέναλτι στην απόδοση σχεδόν ασήμαντο. Επίσης θα πρέπει να τονιστεί ότι EINAI ΤΟ ΜΟΝΑΔΙΚΟ BACKUP ΠΟΥ ΚΑΝΕΙ TRUNCATE TO LOG FILE. (δείτε το άρθρο μου "Ο θαυμαστός κόσμος του Transaction Log")
    Ας πάρουμε ένα παράδειγμα. Έστω ότι έχω πάρει full backup στις 05:00 και στις 07:00 παίρνω t-log backup αυτό περιέχει τα transactions που έχουν γίνει από τις 05:00 έως τις 07:00. Εάν στις 09:00 πάρω ξανά t-log backup αυτό θα περιέχει τα transactions που έχουν γίνει από τις 07:00 έως τις 09:00.
    Προσοχή: Το κάθε t-log backup χρειάζεται την προηγούμενη βάση του για να γίνει restore. Εάν για παράδειγμα χάσω το t-log backup που πήρα στις 07:00 δεν θα μπορέσω να κάνω restore αυτό που πήρα στις 09:00 αυτό στην ορολογία του SQL Server το ονομάζουμε transaction log chain.
    Tail-Log Backup
    Ένα tail-log backup είναι στην ουσία ένα t-log backup το οποίο περιέχει το κομμάτι του log το οποίο δεν έχει παρθεί backup. Μα θα μου πει κάποιος αυτό δεν είναι t-log backup; Όχι ακριβώς. Για να γίνει κατανοητό θα πάρουμε ένα παράδειγμα. Έστω ότι κάθε μέρα στις 05:00 κάνω full backup και κάθε 2 ώρες από εκεί και μετά t-log backup. Έστω ότι στις 11:30 η βάση μου αποδημεί εις τον Κύριο. Σύμφωνα με αυτά που έχουμε πει μέχρι τώρα στα χέρια μου έχω backups που όταν θα τα κάνω restore θα με γυρίσουν στις 11:00 άρα χάνω ότι έχω κάνει από 11:00-11:30. Ξαναλέω ότι η βάση είναι off. Πριν αρχίσω να κάνω restore θέλω να βάλω στην τσέπη μου αυτό το μισάωρο. Εάν τα καταφέρω τότε θα είμαι σε θέση να γυρίσω στις 11:30. Και τώρα κάποιος θα πει, "και γιατί δεν προσπαθώ να πάρω t-log backup;". Αυτό δεν μπορεί να γίνει διότι πρέπει για μια ακόμα φορά να τονίσουμε ότι κάθε φορά που πάω να πάρω t-log backup αυτός κάνει διαδικασία checkpoint αλλά επειδή η βάση είναι off δεν μπορεί να πάρει και backup. Έτσι παίρνω tail-log backup όπου ρουφάει σαν σκουπα hoover το log file χωρίς να κάνει διαδικασία checkpoint. Μάλιστα από την έκδοση του SQL Server 2005 και σας ζητάει σε κάποιες περιπτώσεις να πάρετε πρώτα tail-log backup και μετά να κάνετε restore. Θα σας εξηγήσω παρακάτω τον τρόπο με τον οποίο μπορείτε να κάνετε κάτι τέτοιο.
    File/Filegroup Backup
    Είναι το δυσκολότερο σε υλοποίηση backup στον SQL Server μιας και πρέπει να ξέρεις αρκετά πράγματα για το πώς είναι δομημένη η βάση στην οποία θέλεις να το εφαρμόσεις. Ας πάρουμε ένα παράδειγμα για να το κατανοήσουμε καλύτερα. Έστω ότι έχω μια βάση που έχει 2 data files και 1 log file, αν και το log δεν με ενδιαφέρει στο συγκεκριμένο τύπο backup το λέω για να μην υπάρχει κάποια παρεξήγηση. Έστω αυτός που σχεδίασε την βάση αποφάσισε να βάλει τους πίνακες που δέχονται τα transactions πχ τιμολόγια, κινήσεις λογιστηρίου στο 2ο data file και όλους τους άλλους στο 1ο data file. Επίσης αυτή η βάση είναι τεράστια και ο χρόνος που χρειάζεται να την πάρεις full backup είναι 10 ώρες (υπερβολικό μεν αλλά το έχω δει σε βάση που είναι κάτι ΤΒ). Σε αυτή την περίπτωση μπορεί να παίρνεις full backup κάθε Κυριακή και κάθε μέρα στις 05:00 κάνεις bakup μόνο το 2ο data file το οποίο περιέχει τις κινήσεις.
    Τώρα κάποιος θα μου πει και το filegroup; Δεν ξέρω αν γνωρίζεται τι είναι το filegroup. Μπορείτε να κοιτάξετε στα BOL του SQL Server αν δεν το ξέρετε, απλά εγώ εδώ θα σας πω ότι είναι λογικές οντότητες μέσα στης οποίες ανήκουν τα data files μιας βάσης. Κάθε filegroup ανήκει σε μια συγκέκριμένη βάση και μπορεί να έχει μέσα του περισσότερα από ένα data files. By default κάθε βάση έχει το primary filegroup στο οποίο ανήκει by default το πρώτο data file της βάσης (.mdf). Εάν στο παραπάνω παράδειγμα αντικαταστήσουμε τα files με filegroup θα έχουμε το ίδιο ακριβώς αποτέλεσμα του backup.
    ΠΡΟΣΟΧΗ ΠΡΟΣΟΧΗ ΠΡΟΣΟΧΗ: ΜΕΤΑ ΑΠΟ ΚΑΘΕ FILE/FILEGROUP BACKUP ΠΑΙΡΝΟΥΜΕ Τ-LOG BACKUP. AYTO EINAI ΑΠΑΡΑΒΑΤΟΣ ΚΑΝΟΝΑΣ. Παίζει με Full & Bulk-Logged Recovery Model.
    Partial Backup
    Στην ουσία είναι το backup κάποιου ή κάποιον filegroup(s). Στο παράδειγμα που σας έδωσα στο file/filegroup backup ας έρθουμε να προσθέσουμε ακόμα ένα data file το οποίο θα ανήκει σε ένα ακόμα filegroup. Έτσι η βάση θα έχει τρία (3) data files έστω τα (a1.mdf,a2.ndf,a3.ndf) και έχω και τρία (3) filegroups το primary που έτσι και αλλιώς το έχω και το fg1 και fg2. Στο primary by default ανήκει το πρώτο data file και έχουμε a2.ndf->fg1 & a3.ndf->fg2. Στο 3ο data file βάζουμε τα δεδομένα που είναι από κλεισίματα προηγούμενων χρήσεων και τα οποία δεν θέλουμε αν τα αλλάζουν οι χρήστες. Αυτό είναι εύκολο να γίνει διότι μπορώ να κάνω το fg2 read-only. Ένα τώρα θελήσω να πάρω partial backup στην ουσία παίρνω full backup απλά προσδιορίζω αν θέλω να πάρω τα read only ή τα read-write filegroups. Παίζει με Full & Bulk-Logged Recovery Model.
    Copy Only
    Από τον SQL Server 2005 και μετά έχουμε διαθέσιμο τον συγκεκριμένο τύπο και ομολογώ ότι ήταν κάτι το οποίο έλειπε από το εργαλείο. Θα καταφύγω πάλι σε παράδειγμα για την κατανόηση του τύπου αυτού. Έστω ότι σε ημερήσια βάση έχω μια πολιτική για το backup σε μια βάση μου που είναι η εξής:
    · Full Backup στις 05:00 πμ
    · Transaction Log Backup κάθε μια ώρα
    Στις 15:00 έρχεται το αφεντικό και μου λέει "Θέλω να πάρεις την βάση έτσι όπως είναι τώρα και να την βάλει στο laptop μου γιατί θέλω να πάω ένα ταξίδι και θέλω να έχω τα δεδομένα μαζί μου". Στις προηγούμενες εκδόσεις είχα θέμα με τέτοιου είδους ερωτήματα. Εάν για παράδειγμα έκανα το λάθος και έκανα full backup στην ουσία κατέστρεφα την αλληλουχία των t-logs backups από τις 15:00 και μετά, διότι αυτά θα είχαν σαν βάση το full backup που μόλις έκανα. Έτσι στην περίπτωση που θα ήθελα να κάνω restore στην συγκεκριμένη ημέρα δεν θα ξεκίναγα από το full backup που πήρα στις 05:00 αλλά από αυτό που πήρα στις 15:00. Εάν ήθελα να γυρίσω πριν τις 15:00 θα ξεκίναγα από των 05:00, αλλά θα έπρεπε να τα κάνω όλα με την σειρά που τα πήρα και φυσικά θα χρειαζόμουν περισσότερο χρόνο. Βέβαια όλα θα ήταν καλά αν το backup στις 15:00 το κρατούσα στο μέσο που παίρνω τα backups μου. Για σκεφτείτε όμως τι θα γίνει αν μετά από την μεταφορά στο laptop του αφεντικού το έσβηνα; Πολύ απλά αν ήθελα να γυρίσω στην συγκεκριμένη μέρα αυτό θα ήταν εφικτό να γίνει αλλά μέχρι τις 14:00 όπου ήταν τα τελευταίο valid t-log backup.
    To Copy Only αυτό ακριβώς το πρόβλημα λύνει. Μπορείς να πάρεις full backup οποιαδήποτε στιγμή μέσα στην ημέρα θέλεις χωρίς να επηρεάζεις την συνέχεια στην πολιτική του backup που έχεις.
    How To Backup Database
    Αφού είδαμε, και ελπίζω να έγιναν κατανοητοί οι διάφοροι τύποι του backup, είναι η στιγμή να δούμε και πως παίρνουμε backup αυτούς. Για να το κάνουμε αυτό μπορούμε να χρησιμοποιήσουμε το SQL Server Management Studio ή T-SQL. Δεν θα δώσω ιδιαίτερη βάση στο περιβάλλον του SSMS διότι κυρίως το χρησιμοποιούμε για να πάρουμε ad-hoc backups. Το T-SQL είναι αυτό που μας χρειάζεται διότι αφού το δοκιμάσουμε μετά το κάνουμε schedule. Ναι ξέρω τι θα μου πείτε ότι μπορώ να το κάνω schedule και μέσα από τον SSMS (Maintenance Plans, κλπ), δεν θα διαφωνήσω μαζί σας απλά πιστεύω ότι ο καλύτερος τρόπος εκμάθησης είναι με T-SQL.
    Backup Devices
    Πριν αρχίσω να σας δείχνω τους τρόπους και τις εντολές backup, θέλω να σας πω μερικά πράγματα σχετικά με τα backup devices στα οποία μπαίνουν τα backups που παίρνουμε. Αυτά μπορεί να είναι είτε στον σκληρό δίσκο σας είτε σε ταινία, θα πρέπει όμως να γνωρίζεται ότι η συσκευή της ταινίας πρέπει να είναι φυσικά συνδεδεμένη στη μηχανή στην οποία έχετε βάλει τον SQL Server. Δεν μπορείς π.χ να πάρεις tape backup σε βάση όταν το tape device είναι συνδεμένο στον domain controler server και έχεις σε άλλο server τον SQL Server. Επίσης για τα disk devices αυτά θα πρέπει να είναι δίσκους που βλέπει φυσικά ο server στον οποίο έχουμε εγκαταστήσει τον SQL Server. Εάν θέλουμε να είναι κάποιος share folder μπορεί να γίνει μόνο με UNC Name και όχι με map drive, και φυσικά το account το οποίο ξεκινάει το sql service να έχει τα απαραίτητα read-write permissions σε αυτό.
    Για να σας κάνω την ζωή ευκολότερη θα σας έλεγα να θεωρήσετε ότι το backup device είναι μια συρταριέρα με πολλά συρτάρια, όπου το κάθε ένα συρτάρι είναι ένα backup που παίρνουμε, οποιουδήποτε τύπου (full, diff, t-log) και από οποιαδήποτε βάση. Το μόνο που θα πρέπει να ξέρω είναι τι έχω σε κάθε συρτάρι, το οποίο φυσικά δεν χρειάζεται να το θυμάμαι μιας υπάρχει τρόπος που θα δούμε παρακάτω πως γίνεται να βρω τι έχω μέσα σε αυτό. Θα σας έδινα όμως μια συμβουλή και αυτή είναι backup device να είναι με backups από μια συγκεκριμένη βάση ώστε να μην χάσετε την μπάλα.
    Υπάρχουν δύο είδη backup devices, τα permanent και τα temporary. Η ουσιαστική διαφορά τους είναι ότι τα permanent τα βλέπεις μέσα από SSMS και μπορείς να τα διαχειριστείς με γραφικό περιβάλλον, ενώ τα temporary μόνο με T-SQL μπορείς να τα διαχειριστείς και φυσικά δεν τα βλέπεις από το SSMS. Υπάρχει ακόμα μία διαφορά σε αυτά και είναι ο τρόπος με τον οποίο δημιουργούνται. Τα permanent δημιουργούνται είτε μέσα από το γραφικό περιβάλλον είτε με T-SQL πριν πάρω κάποιο backup, ενώ τα temporary με την εντολή που θα δώσω για να πάρω backup.
    Για να φτιάξω ένα permanent backup device με το SSMS πάω στο Object Explorer Window > Server Objects > Backup Devices > Right Click > New Backup Device. Στο διάλογο που μας δίνεται δίνουμε το όνομα του device και το destination (disk or tape). Ενώ με T-SQL χρησιμοποιώ την sp_addumpdevice πχ
    EXEC master.dbo.sp_addumpdevice 'disk', 'demodevice', 'C:\....\demodevice.bak'
    GO
    Σημείωση : Μέχρι να βάλω το πρώτο backup στο device αυτό δεν υπάρχει σαν αρχείο στο δίσκο αν είναι τύπου disk.
    Όπως είπα και παραπάνω για να φτιάξω temporary device αυτό γίνεται μόνο με T-SQL και μόνο κατά την στιγμή που πάω να πάρω backup π.χ.
    BACKUP DATABASE demoDB TO DISK='C:\...\tempDevName.bak'
    BACKUP LOG demoDB TO DISK='C:\...\tempDevName.bak'
    BACKUP Statement
    Αντιγραφή από τα SQL Server Books Online.

    Backing Up a Whole Database
    BACKUP DATABASE { database_name | @database_name_var }
    TO [ ,...n ]
    [ ] [ next-mirror-to ]
    [ WITH { DIFFERENTIAL | [ ,...n ] } ]
    [;]
    Backing Up Specific Files or Filegroups
    BACKUP DATABASE { database_name | @database_name_var }
    [ ,...n ]
    TO [ ,...n ]
    [ ] [ next-mirror-to ]
    [ WITH { DIFFERENTIAL | [ ,...n ] } ]
    [;]
    Creating a Partial Backup
    BACKUP DATABASE { database_name | @database_name_var }
    READ_WRITE_FILEGROUPS [ , [ ,...n ] ]
    TO [ ,...n ]
    [ ] [ next-mirror-to ]
    [ WITH { DIFFERENTIAL | [ ,...n ] } ]
    [;]

    Backing Up the Transaction Log (full and bulk-logged recovery models)
    BACKUP LOG { database_name | @database_name_var }
    TO [ ,...n ]
    [ ] [ next-mirror-to ]
    [ WITH { | } [ ,...n ] ]
    [;]
    ::=
    {
    { logical_device_name | @logical_device_name_var }
    | { DISK | TAPE } =
    { 'physical_device_name' | @physical_device_name_var }
    }
    ::=
    MIRROR TO [ ,...n ]
    ::=
    {
    FILE = { logical_file_name | @logical_file_name_var }
    | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
    }
    ::=
    FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
    [ ,...n ]::=
    --Backup Set Options
    COPY_ONLY
    | { COMPRESSION | NO_COMPRESSION }
    | DESCRIPTION = { 'text' | @text_variable }
    | NAME = { backup_set_name | @backup_set_name_var }
    | PASSWORD = { password | @password_variable }
    | { EXPIREDATE = { 'date' | @date_var }
    | RETAINDAYS = { days | @days_var } }
    --Media Set Options
    { NOINIT | INIT }
    | { NOSKIP | SKIP }
    | { NOFORMAT | FORMAT }
    | MEDIADESCRIPTION = { 'text' | @text_variable }
    | MEDIANAME = { media_name | @media_name_variable }
    | MEDIAPASSWORD = { mediapassword | @mediapassword_variable }
    | BLOCKSIZE = { blocksize | @blocksize_variable }
    --Data Transfer Options
    BUFFERCOUNT = { buffercount | @buffercount_variable }
    | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }
    --Error Management Options
    { NO_CHECKSUM | CHECKSUM }
    | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
    --Compatibility Options
    RESTART
    --Monitoring Options
    STATS [ = percentage ]
    --Tape Options
    { REWIND | NOREWIND }
    | { UNLOAD | NOUNLOAD }
    --Log-specific Options
    { NORECOVERY | STANDBY = undo_file_name }
    | NO_TRUNCATE
    Θα σταθώ όμως σε μερικά options του BACKUP statement
    Mirror Backup - Enterprise Edition Only
    Με το mirror κάνω αυτό που λέει και η λέξη με μια κίνηση έχω δύο devices που περιέχουν το ίδιο backup. Αυτά όμως πρέπει να είναι του ίδιου τύπου πχ disk και όχι το ένα disk και το άλλο tape. Αρκετά χρήσιμο διότι έτσι εξασφαλίζω ότι θα έχω περισσότερη ασφάλεια.
    Compression Backup - Enterprise Edition Only
    Πολλές φορές μέχρι τώρα για να εξοικονομήσουμε χώρο στο δίσκο αφού τελειώναμε με το backup μας κάναμε compress το device. Πλέον αυτό μπορεί να γίνει αυτόματα από τον SQL Server. Υπάρχει ένα πέναλτι σε χρησιμοποιούμενους πόρους από το σύστημα αλλά είναι πολύ λιγότεροι από αυτούς που χρησιμοποιούσα όταν έκανα μόνος τη διαδικασία με εξωτερικά εργαλεία. Γενικά θα πρέπει να δεις αν το πέναλτι που έχεις αξίζει να το έχεις. Με αυτό θέλω να πω ότι πρέπει να δεις το πόσο compression ratio και αυτό μπορείς να το δεις με αυτό το query
    SELECT backup_size/compressed_backup_size FROM msdb.dbo.backupset
    Striped Backups
    Είναι η δυνατότητα να έχω το backup σε περισσότερα από ένα backup device (μέχρι 64). Χρήσιμο σε περιπτώσεις που βλέπω ότι έχω μια διαδικασία backup να παίρνει μεγάλο χρόνο πχ 4 ώρες, με αυτό μειωνεται ο χρονος στο μισό αν χρησιμοποιήσω 2 backup devices. Ακόμα μια χρήση του είναι όταν έχω πρόβλημα χώρου είτε με το δίσκο που είναι το device είτε με το χώρο τoυ tape (αρκεί βέβαια να έχω δύο tape device).
    How To Restore Database
    Η διαδικασία του restore χωρίζεται σε τρεις φάσεις:
    1. Data Copy Phase
    2. Redo Phase
    3. Undo Phase and Recovery
    Copy Data Phase
    Είναι η πρώτη φάση σε κάθε restore που κάνουμε. Σε αυτή την φάση γίνονται copy όλα (data, log, indexes) από τα backup της βάσης στα database files. Με το τέλος της φάσης αυτής όλα τα περιέχομενα της βάσης έχουν γίνει reset στα περιεχόμενα του backup που κάνουμε restore. Αυτό γίνεται με τα full και differential backups.
    Redo Phase
    Σε αυτή την φάση γίνονται apply όλα τα logged transactions στα δεδομένα που έγιναν copy στην προηγούμενη φάση. Αυτό γίνεται κατά τη στιγμή που γίνονται restore τα transactions log backup. Στην ουσία κοιτάζει ποια transactions που τα logs έχουν δεν υπάρχουν μέσα στα data files και τα κάνει apply.
    Undo Phase and Recovery
    Με το τέλος της προηγούμενης φάσης το επόμενο βήμα είναι βρει τα transactions τα οποία δεν έχουν γίνει commit και κάνει rollback ότι έχουν αυτά κάνει με σκοπό να κρατηθεί η ακεραιότητα και συνοχή των δεδομένων. Αυτό γίνεται διαβάζοντας τα transaction logs. Αφού τελειώσει με την διαδικασία Undo το επόμενο βήμα είναι να προχωρήσει στην επόμενη εσωτερική εργασία της φάσης αυτή που είναι το Recovery Process με την οποία φέρνει στη βάση σε κατάσταση λειτουργίας (online).
    Τι σημαίνουν οι φάσεις αυτές για την διαδικασία Restore;
    Ας απαντήσουμε σε αυτό το κρίσιμο ερώτημα με ένα παράδειγμα. Έστω ότι σε ημερήσια βάση έχουμε το εξής σενάριο για το backup στην βάση μας.
    · FULL BACKUP στις 00:00.
    · DIFFERENTIAL BACKUP στις 06:00, 12:00, 18:00
    · TRANSACTION LOG BACUP κάθε μία ώρα στις εναπομείνασες ώρες
    Στη παρακάτω εικόνα βλέπουμε το σενάριο μας.

    Η ώρα είναι 19:30 και η βάση μας σκάει….
    Τι πρέπει να κάνουμε restore και πως;
    1. Προσπαθούμε να πάρουμε tail-log backup. Εάν το καταφέρουμε γυρνάμε ακριβώς στο σημείο της πτώσης 19:30. Αλλιώς αναγκαστικά γυρνάμε στις 19:00.
    2. Κάνουμε restore to full backup που έχουμε πάρει τα μεσάνυκτα αλλά χωρίς να ενεργοποιήσουμε τις φάσεις 2 & 3. Αυτό γίνεται βάζοντας στην εντολή RESTORE DATABASE το option NORECOVERY. Αυτό το κάνουμε διότι έχουμε να κάνουμε restore και άλλα backups που μας χρειάζονται μέχρι να φτάσουμε στο επιθυμητό σημείου που είναι το σημείο της πτώσης μιας το full backup περιέχει την εικόνα της βάσης όπως ήταν τα μεσάνυκτα.
    3. Επειδή στο σενάριο μας έχουμε differential backups το επόμενο βήμα είναι να κάνουμε restore το ποιο πρόσφατο που έχουμε και δεν είναι άλλο από αυτό των 18:00 όπου και αυτό θα γίνει χωρίς να ενεργοποιήσουμε τις φάσεις 2 & 3. (WITH NORECOVERY).
    4. Μετά κάνουμε restore το t-log backup που έχουμε μετά και αυτό είναι των 19:00. Εδώ τώρα υπάρχουν δύο δρόμοι.
    a. Ο πρώτος δρόμος είναι αυτός που έχει προκύψει από την περίπτωση να μην έχουμε στα χέρια μας tail-log backup. Σε αυτή την περίπτωση με το τέλος του restore θέλουμε να ενεργοποιηθούν οι φάσεις 2 & 3 μιας και δεν έχω κάτι άλλο να κάνω restore έτσι επιλέγω αυτό να το κατεβάζω με την επιλογή WITH RECOVERY, οπότε στο τέλος της θα έχω Online την βάση μου, αλλά θα έχω χάσει αυτή την μίση ώρα.
    b. Ο δεύτερος είναι αυτό που έχει προκύψει από τη περίπτωση να έχω tail-log backup στα χέρια μου. Οπότε επειδή έχω να κάνω restore και αυτό, το t-log backup των 19:00 το κάνω restore χωρίς να ενεργοποιήσω τις φάσεις 2 & 3.
    5. Εφόσον έχω tail-log backup, το κάνω restore και επιλέγω να γίνουν οι φάσεις 2 & 3 (WITH RECOVERY).
    Από το παραπάνω παράδειγμα γίνεται κατανοητό ότι υπάρχει ένας βασικός κανόνας ο οποίος λέει: "ΚΑΝΩ RESTORE ΟΛΑ ΤΑ BACKUPS ΠΟΥ ΕΧΩ ΜΕ ΝΟRECOVERY ΕΚΤΟΣ ΤΟΥ ΤΕΛΕΥΤΑΙΟΥ ΠΟΥ ΤΟ ΚΑΝΩ ΜΕ RECOVERY, ΧΩΡΙΣ ΟΜΩΣ ΝΑ ΞΕΧΝΑΩ ΠΡΙΝ ΚΑΝΩ RESTORE NΑ ΠΡΟΣΠΑΘΗΣΩ ΝΑ ΠΑΡΩ TAIL-LOG BACKUP".
    Restore Statement
    Αντιγραφή από τα SQL Server Books Online.
    --To Restore an Entire Database from a Full database backup (a Complete Restore):
    RESTORE DATABASE { database_name | @database_name_var }
    [ FROM [ ,...n ] ]
    [ WITH
    {
    [ RECOVERY | NORECOVERY | STANDBY =
    {standby_file_name | @standby_file_name_var }
    ]
    | , [ ,...n ]
    | ,
    | ,
    | ,
    | ,
    } [ ,...n ]
    ]
    [;]

    --To perform the first step of the initial restore sequence
    -- of a piecemeal restore:
    RESTORE DATABASE { database_name | @database_name_var }
    [ ,...n ]
    [ FROM [ ,...n ] ]
    WITH
    PARTIAL, NORECOVERY
    [ , [ ,...n ]
    | ,
    ] [ ,...n ]
    [;]

    --To Restore Specific Files or Filegroups:
    RESTORE DATABASE { database_name | @database_name_var }
    [ ,...n ]
    [ FROM [ ,...n ] ]
    WITH
    {
    [ RECOVERY | NORECOVERY ]
    [ , [ ,...n ] ]
    } [ ,...n ]
    [;]

    --To Restore Specific Pages:
    RESTORE DATABASE { database_name | @database_name_var }
    PAGE = 'file:page [ ,...n ]'
    [ , ] [ ,...n ]
    [ FROM [ ,...n ] ]
    WITH
    NORECOVERY
    [ , [ ,...n ] ]
    [;]

    --To Restore a Transaction Log:
    RESTORE LOG { database_name | @database_name_var }
    [ [ ,...n ] ]
    [ FROM [ ,...n ] ]
    [ WITH
    {
    [ RECOVERY | NORECOVERY | STANDBY =
    {standby_file_name | @standby_file_name_var }
    ]
    | , [ ,...n ]
    | ,
    | ,
    } [ ,...n ]
    ]
    [;]

    --To Revert a Database to a Database Snapshot:
    RESTORE DATABASE { database_name | @database_name_var }
    FROM DATABASE_SNAPSHOT = database_snapshot_name

    ::=
    {
    { logical_backup_device_name |
    @logical_backup_device_name_var }
    | { DISK | TAPE } = { 'physical_backup_device_name' |
    @physical_backup_device_name_var }
    }
    ::=
    {
    FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }
    | FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
    | READ_WRITE_FILEGROUPS
    }

    [ ,...n ]::=
    --Restore Operation Options
    MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name'
    [ ,...n ]
    | REPLACE
    | RESTART
    | RESTRICTED_USER
    --Backup Set Options
    | FILE = { backup_set_file_number | @backup_set_file_number }
    | PASSWORD = { password | @password_variable }
    --Media Set Options
    | MEDIANAME = { media_name | @media_name_variable }
    | MEDIAPASSWORD = { mediapassword | @mediapassword_variable }
    | BLOCKSIZE = { blocksize | @blocksize_variable }
    --Data Transfer Options
    | BUFFERCOUNT = { buffercount | @buffercount_variable }
    | MAXTRANSFERSIZE = { maxtransfersize | @maxtransfersize_variable }
    --Error Management Options
    | { CHECKSUM | NO_CHECKSUM }
    | { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
    --Monitoring Options
    | STATS [ = percentage ]
    --Tape Options
    | { REWIND | NOREWIND }
    | { UNLOAD | NOUNLOAD }
    ::=
    | KEEP_REPLICATION
    ::=
    | KEEP_CDC
    ::=
    | ENABLE_BROKER
    | ERROR_BROKER_CONVERSATIONS
    | NEW_BROKER
    ::=
    | {
    STOPAT = { 'datetime' | @datetime_var }
    | STOPATMARK = { 'lsn:lsn_number' }
    [ AFTER 'datetime' ]
    | STOPBEFOREMARK = { 'lsn:lsn_number' }
    [ AFTER 'datetime' ]
    }
    ::=
    | {
    STOPAT = { 'datetime' | @datetime_var }
    | STOPATMARK = { 'mark_name' | 'lsn:lsn_number' }
    [ AFTER 'datetime' ]
    | STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' }
    [ AFTER 'datetime' ]
    }
    Παράδειγμα Backup
    Ας πάρουμε για παράδειγμα το τελευταίο μας
    · FULL BACKUP στις 00:00.
    · DIFFERENTIAL BACKUP στις 06:00, 12:00, 18:00
    · TRANSACTION LOG BACUP κάθε μία ώρα στις εναπομείνασες ώρες

    1. Φτιάχνω ένα permanent device
    EXEC sp_addumpdevice 'disk','pdev1','c:\temp\pdev1.bak'
    GO
    2. Παίρνω το Full backup στις 00:00
    BACKUP DATABASE BackupDemoDB
    TO PDEV1
    WITH INIT, STATS
    GO
    3. Για το Differential backup το statement είναι
    BACKUP DATABASE BackupDemoDB
    TO PDEV1
    WITH DIFFERENTIAL, STATS
    GO
    3. Για το transaction log backup το statement είναι
    BACKUP LOG BackupDemoDB
    TO PDEV1
    WITH DIFFERENTIAL, STATS
    GO
    Και όπως είπαμε παραπάνω η βάση μου σκάει στις 19:30
    Παράδειγμα Restore
    1. Πρώτη κίνηση είναι να πάρω tail-log backup
    BACKUP LOG BackupDemoDB
    TO PDEV1
    WITH NO_TRUNCATE, STATS
    GO
    2. H επόμενη κίνηση είναι κάνω restore το full backup που έχω από τις 00:00. όμως όλα τα backups τα έχω στο ίδιο backup device. Έτσι πρέπει να μάθω τι θα επιλέξω μέσα από αυτό. Για αυτό το λόγο εκτελώ το statement
    RESTORE HEADERONLY FROM PDEV1
    Από το αποτέλεσμα που θα δω με ενδιαφέρουν τα πεδία BackupType , Position, και DatabaseName για την περίπτωση που έχω backup από διαφορετικές βάσεις στο ίδιο backup device. Εδώ δεν έχουμε.
    Το πεδίο BackupType δείχνει τον τύπο του backup (1=FULL, 5=DIFFERENTIAL, 2=TRANSACTION LOG) και το πεδίο Position την θέση του. Αν θυμάστε πιο πάνω το παράδειγμα με την συρταριέρα είναι ας πούμε το συρτάρι. Έτσι αφού έχουμε τις απαραίτητες πληροφορίες προχωράμε
    3. Κάνουμε restore to full backup με ΝΟRECOVERY μιας και πρόκειτε να κάνουμε restore και άλλα backups. Αλλά για να το επιλέξουμε από το backup device χρησιμοποιούμε το FILE=? όπου αντικαθηστούμε το ? με το αριθμό του Position που έχουμε βρει από το βήμα 2 και στο οποίο αντιστοιχεί το Full backup (BackupType=1)
    RESTORE DATABASE BackupDemoDB FROM PDEV1 WITH FILE=1, NORECOVERY
    4. Κάνουμε restore το differential backup των 18:00
    RESTORE DATABASE BackupDemoDB FROM PDEV1 WITH FILE=19, NORECOVERY
    5. Κάνουμε restore το t-log backup των 19:00
    α. για την περίπτωση που έχουμε tail-log backup από το βήμα 1
    RESTORE LOG BackupDemoDB FROM PDEV1 WITH FILE=20, NORECOVERY
    β. εάν δεν έχουμε tail-log
    RESTORE LOG BackupDemoDB FROM PDEV1 WITH FILE=20, RECOVERY
    6. Εφόσον έχουμε tail-log
    RESTORE LOG BackupDemoDB FROM PDEV1 WITH FILE=21, RECOVERY
    Επίλογος
    Σε αυτό το άρθρο σκοπός μου ήταν να κάνω μια καλή εισαγωγή σε αρεκτό βάθος όμως για το τι είναι backup & restore στον SQL Server. Δεν ασχολήθηκα με κάποια σενάρια πχ file/filegroup backup, όμως είναι κάτι που θα το κάνω σύντομα.
  5. antonch
    Τελικά ο Αη Βασίλης ήρθε και για μένα. Για δεύτερη χρονιά μου απονεμήθηκε ο τίτλος του MVP στον SQL Server. Αυτό σημαίνει περισσότερες ευθύνες για μένα, αλλά ευχάριστες.

    Η χρονιά αυτή θα συνεχιστεί με περισσότερη δράση και περισσότερα SQL Saturday Nights.

    Καλή Χρονιά σε όλους και σας ευχαριστώ για την υποστήριξη
  6. antonch
    Στο 18ο event μας που είχα την ομιλία μου η συζήτηση μας έφερε να μιλήσουμε για το ότι ευτυχώς πλέον δεν υποστηρίζεται η χρήση της BACKUP LOG dbname> WITH TRUNCATE_ONLY.
    Ο φίλος μου, συναγωνιστής μου, Αθανάσιος Κλαδάκης είχε την εύλογη απορία γιατί έγινε αυτό. Είπαμε κάποια πράγματα αλλά επειδή ο χρόνος ήταν περιορισμένος διότι περίμεναν οι μπύρες και η πίτα-πίτσα δεν έμεινα ικανοποιημένος με την απάντηση που έδωσα. Έτσι επανέρχομαι στο θέμα.
    Ο Νάσος είπε ότι σε όσους πελάτες του βλέπει σε κάποια βάση ότι το Transaction Log (TL) έχει γίνει μεγάλο εκτελεί την εντολή αυτή και φέρνει τα πράγματα στα ίσια τους. Μέχρι εδώ σωστά. Όμως αυτό εγκυμονεί κινδύνους. Ο σημαντικότερος από αυτούς είναι ο παρακάτω.
    Έστω ότι έχω εγκαθιδρύσει μια διαδικασία backup στην βάση με την οποία παίρνω και TL Backup. πχ
    Στις 05:00 κάνω Full Backup (FB) και από τις 06:00 παίρνω TL backup.
    Κάποια στιγμή το μεσημέρι βλέπω το TL να είναι μεγάλο και σαν καλό παιδί αποφασίζω να το μικρύνω με την χρήση της παραπάνω εντολής. Όλα πάνε καλά και είμαι ευτυχισμένος. Αυτό ας υποθέσουμε ότι έγινε γύρω στις 12:30.
    Στις 17:30 για κάποιο λόγο σκάει η βάση και πρέπει να κάνω RESTORE. Σύμφωνα με αυτά που ξέρω θα πρέπει να κάνω RESTORE το FB των 05:00 WITH NORECOVERY και στη συνέχεια να κάνω RESTORE όλα τα TL backups με την σειρά που τα πήρα όλα WITH NORECOVERY εκτός του τελευταίου το οποίο είναι στις 17:00 (εκτός και αν έχω πάρει και tail log backup αμέσως μετά από την εμφάνιση του προβλήματος) το οποίο θα πρέπει να γίνει με RECOVERY.
    Όμως σιγά που θα γίνει αυτό που θέλω. Επειδή στις 12:30 έκανα το truncate στο log δεν μπορώ να συνεχίσω στο restore των logs από εκεί και πέρα διότι πολύ απλά δεν έχω τέτοια μιας και με την χρήση της εντολής που συζητάμε έχω καταφέρει να κάνω break το Log Sequence Number (LSN) πάνω στο οποίο βασίζεται η διαδικασία του TL backup.
    Αποτέλεσμα, πάω για κρύες μπύρες, διότι έχω χάσει τα περιεχόμενα του TL από το τελευταίο FB. (Ένα ρίγος περνάει αυτή τη στιγμή την πλάτη μου μόνο και που το σκέφτομαι)
    Αυτό που μέχρι την διακοπή της χρήσης της εντολής η Microsoft συνιστούσε ήταν αμέσως μετά την ολοκλήρωση της εντολής να παίρνουμε FULL BACKUP ώστε τα TL backups να μην σκάνε.
    Σήμερα (SQL Server 2005, 2008, 2008 R2) με την κατάργηση της εντολής αν θέλουμε να κάνουμε αυτό που θέλει να κάνει ο Νάσος σύμφωνα πάντα με την Microsoft θα πρέπει να γυρίσουμε την βάση σε SIMPLE RECOVERY MODEL ώστε να γίνει truncate το log και όταν τελειώσει αυτό να την επαναφέρουμε σε FULL RECOVERY MODEL.
    Ελπίζω να έδωσα τώρα μια πιο κατατοπιστική απάντηση γιατί δεν έχει θέση στον SQL Server η TRUNCATE_LOG.
    Να σημειώσω ότι μπορεί να την δείτε και σαν NO_LOG είναι το ίδιο αλλά με άλλο όνομα, και αυτή πήγε στον Καιάδα.
    Υ.Γ. Δεν ξέρω αν η κοινότητα είναι εξοικειωμένη με τις διάφορες μορφές backup που μπορώ να έχω στον SQL Server. Επειδή μέχρι σήμερα δεν έχω αναφερθεί σε αυτό, θεωρώντας το γνωστό, θα ήθελα να ξέρω αν υπάρχει ενδιαφέρον ώστε να γράψω για αυτό.
  7. antonch
    Ολοκληρώθηκε το meeting και το recording αυτού μπορείτε να το βρείτε στα παρακάτω σήμεια
    https://www311.livemeeting.com/cc/mvp/view?id=DSZT9W http://www.techdays.gr --------------------------------------------------------------------------------------------------------
    Συνεχίζουμε στο ρυθμό μας, ελπίζοντας αυτή η προσπάθεια να σας αρέσει, με το 3ο Saturday SQL Night και θεματολογία Backup & Restore (έπειτα με απαίτηση αρκετών από εσάς ).
    Παρακάτω σας δίνω τα στοιχεία του meeting και ελπίζω να δω τους περισσότερους από εσάς.
    Ημερομηνία & Ώρα : 06/11/2010 22:30 μμ
    Attendee URL: https://www.livemeeting.com/cc/mvp/join?id=DSZT9W&role=attend&pw=p7%28pCxwWq
    Meeting ID: DSZT9W
    Attendee Entry Code: p7(pCxwWq
    Duration: 2 hours
    Μέχρι τότε να είσαι όλοι καλά και να προσέχετε τον εαυτό σας.
  8. antonch
    Μόλις έλαβα ένα request από τον συνάδελφο Γιώργο Σίμο να φτιάξω κάτι για να παίρνει schedule backup στο sql server express, μιας και αυτή η έκδοση δεν έχει τον sql server agent.
    Λοιπόν όποιος θέλει να υλοποιήσει μια τέτοια λύση θα πρέπει να κάνει τα εξής βήματα:
    BHMA 1o
    Αποθηκεύω το παρακατώ script σε ένα αρχείο πχ c:\My SQL Scripts\DBBackupPerDay.sql
    declare @weekday char(3)
    declare @command varchar(2048)
    select @weekday=upper(left(datename(dw,getdate()),3))
    set @command = 'backup database $(dbname) to disk =''$(backupPath)\$(dbname)_'+@weekday+'.bak' + ''' with init'
    exec (@command)

    Εδώ έχω πάρει σαν υπόθεση εργασίας ότι κάθε μέρα θα παίρνουμε ημερήσιο full backup την βάση μας σε ξεχωριστό device, το οποίο στην επόμενη φορά που θα ξαναπάρω backup σε αυτό θα σβήνει το προηγούμενο. Δηλαδή έστω ότι είναι Δευτέρα και παίρνω backup την επόμενη Δευτέρα θα σβηστεί το backup αυτής. Εάν υπάρχει ανάγκη για κάτι διαφορετικό ενημερώστε με να σας δώσω την λύση.

    ΒΗΜΑ 2ο
    Ανοίγουμε τον Windows Task Scheduler και φτιάχνουμε ένα νέο Task (Create Task).

    Δίνουμε όνομα και βάζουμε να τρέχει το συγκεκριμένο με ένα windows account που έχει πρόσβαση στον sql server σαν administrator ( η εύκολη λύση ) ή σαν απλός χρήστης αλλά που το έχουμε δώσει να παίρνει backup databases. Επίσης θα πρέπει να έχει write permissions στο directory στο οποίο πρόκειται να τοποθετήσουμε τα backup μας.
    ΒΗΜΑ 3ο
    Πάμε στο Action Tab και φτίαχνουμε ένα νέο action στο οποίο βάζουμε τα εξής

    στο (1) βάζουμε το SQLCMD.exe μαζί με το full path του λογικά θα είναι το
    "C:\Program Files\Microsoft SQL Server\90\Tools\binn\SQLCMD.EXE"
    στο (2) βάζουμε τα εξής
    /S .\sqlexpress /E /i "c:\My SQL Scripts\DBBackupPerDay.sql" -v dbname=MyDB backuppath=”c:\backups"
    στις dbname, backuppath βάζουμε αντίστοιχα το όνομα της βάσης μας και το directory στο οποίο θέλουμε να αποθηκεύονται αυτά.
    ΒΗΜΑ 4ο
    Τέλος φτιάχνουμε έναν Trigger ( Trigger Tab ) για να πούμε κάθε πότε θέλουμε να γίνεται η εκτέλεση τoυ backup.
    Καλά backup!!!
  9. antonch
    Ένα όνειρο αρκετών χρόνων αποκτά σάρκα και οστά. Φιλοδοξία μου είναι όταν σας το παρουσιάσω με περιεχόμενο να αποτελέσει μια σοβαρή πηγή γνώσης για τον SQL Server.
    Αυτό που μένει πλέον είναι να βρω το χρόνο και να στρωθώ στην δουλειά ώστε να γίνει παραγματικότητα το όνειρο μου, γιατί είναι ωραίο να έχεις όνειρα και να τα πραγματοποιείς.
  10. antonch
    Ένας οργανισμός έχει πολλά SQL Server Instances, πολλές databases και σίγουρα πάνω από έναν DBA, DB developer που έχουν πρόσβαση σε αυτά τα instances και αυτές τις databases.
    Ζητούμενο από όλους είναι να γνωρίζουμε τις αλλαγές που έχουν γίνει σε αυτές τις databases σε επίπεδο schema αλλά και πότε μπήκε ένας χρήστης σε ποιο ρόλο και πολλά ακόμα στοιχεία όπως δημιουργία indexes, αλλαγή στο μέγεθος μιας βάσης κλπ.
    Όλα αυτά ακόμα και μέσα από το SSMS να γίνουν είναι Data Definition Language (DDL) statements και χρήσιμο είναι να μπορούν να καταγραφούν ώστε να υπάρχει ένα ιστορικό για τις αλλαγές αυτές.
    Στο SQL Server υπάρχουν μηχανισμοί Auditing που κάνουν εξαιρετική δουλειά. Βέβαια στο παρελθόν κάτι τέτοιο υπήρχε σαν δυνατότητα μόνο στις Enterprise εκδόσεις.
    Σε αυτό το άρθρο όμως δεν θα μιλήσουμε για αυτούς τους μηχανισμούς αλλά για έναν customize μηχανισμό που μπορεί να χρησιμοποιηθεί σε όλες τις εκδόσεις (Std, Ent) και που μπορεί κάποιος να προσθέσει περισσότερη custom πληροφορία.
     
    http://sqlschool.gr/blog/storing-ddl-statements-history-1070.aspx
  11. antonch
    Χειμώνιασε και νομίζω ότι είναι καιρός να αρχίσουμε .
    Βασανίστηκα αρκετά για να επιλέξω θέμα. Είχα να επιλέξω μεταξύ πολλών θεμάτων. Κάποια ήταν υψηλής δυσκολίας και ίσως φίλοι που δεν έχουν την απαιτούμενη εμπειρία στον SQL Server θα είχαν δυσκολίες στην παρακολούθηση. Κάποια άλλα εύκολα και οι έμπειροι φίλοι να τα έβρισκαν ανιαρά. Δύσκολη απόφαση.
    Έτσι πήρα μια απόφαση που πιστεύω ότι είναι η πιο δίκαιη. Θα ξεκινήσουμε από τα βασικά ώστε μέσα στα πρώτα 4-5 μαθήματα να έρθουν οι «μη έμπειροι» σε μια κατάσταση όμοια με τους «έμπειρους» .
    Στο 1ο μάθημα θα ξεκινήσουμε από την εγκατάσταση του SQL Server και θα φτάσουμε μέχρι την δημιουργία και την αρχιτεκτονική μιας database. Απλό θέμα αλλά νομίζω ότι είναι απαραίτητο για αρχή. Εξάλλου θα είναι και πιλότος για το διαδικαστικό μέρος της προσπάθειας αυτής.
    Παρακάτω θα σας δίνω τα στοιχεία του meeting και ελπίζω να δω τους περισσότερους από εσάς.
    Ημερομηνία & Ώρα : 16/10/2010 22:30 μμ
    Attendee URL: https://www.livemeeting.com/cc/mvp/join?id=ZR29ZM&role=attend&pw=5Kpf%5C%7B22w
    Meeting ID: ZR29ZM
    Attendee Entry Code: 5Kpf\{22w
    Duration: 2 hours
    Μέχρι τότε να είσαι όλοι καλά και να προσέχετε τον εαυτό σας.
  12. antonch
    Admin σε εταιρεία αγοράζει server με δίσκο 250 GB. (το αφήνω ασχολίαστο)

    Σπάει τον δίσκο σε C: & D:

    Στο C: δίνει χώρο 29,2 GB και όλα τα υπόλοιπα στο D:

    Στήνει Windows 2008 R2 και SQL Server 2008 όλα στο C: !!!

    Kαι τον D: τι τον κάνει?????????????????????

    Τον αφήνει έτσι όπως είναι για να παίρνει τα backups (ωχ παναγιά μου το είπα)

    Υ.Γ Δεν είχε άλλου είδους backup.

    Σε συνέχεια απο το #2

    Στην εταιρεία αυτή έρχεται ένας εξωτερικός συνεργάτης. Βλέπει τη κατάσταση και κατεβάζει πρόταση ότι για τα backups και μόνο πρέπει να αγορασθεί ξεχωριστό storage!!!!
  13. antonch
    Όπως φαντάζομαι είναι ήδη γνωστό ο SQL Server ‘Denali’ απέκτησε πλέον επίσημο όνομα και αυτό είναι το SQL Server 2012. Θα είναι διαθέσιμος σαν τελικό προϊόν στο πρώτο εξάμηνο του 2012.
    Όπως είναι φυσικό αυτό έχει άμεσες επιπτώσεις στα σεμινάρια αλλά και στις πιστοποιήσεις και στα exams αυτών. Ας δούμε τι σεμινάρια έχουν προγραμματιστεί να βγουν σαν σεμινάρια και εξετάσεις.
    Title Course Exam Administering a Microsoft SQL Server 2012 Database 10775 70-462 Building Data Warehouses with Microsoft SQL Server 2012 10777 70-463 Developing a Microsoft SQL Server 2012 Database 10776 70-464 Designing Database Solutions for SQL Server 2012 10778 70-465 Implementing Data Models and Reports with Microsoft SQL Server 2012 TBD 70-466 Designing Business Intelligence Solutions with Microsoft SQL Server 2012 Platform TBD 70-467 Το ποιο σημαντικό όμως είναι ότι πλέον δεν θα χρειάζεται να παρακολουθήσεις περισσότερα από ένα σεμινάριο ώστε να δώσεις εξετάσεις ακολουθεί πλέον την λογική 1:1, αλλά τα exams πλέον θα είναι ποιο δύσκολα και το σημαντικότερο ίσως όλων είναι ότι για να περάσεις θέλει πραγματική εργασία στο προϊόν
    Πηγή : Microsoft Learning
  14. antonch
    Σήμερα είχα μια ωραία ερώτηση από μια αγαπητή συνάδελφο σχετικά με τον τελεστή LIKE. Η ερώτηση της ήταν:

    «Πως μπορώ να έχω την δυνατότητα με τον τελεστή LIKE να έχω όλα τα records που είναι περασμένα μέσα στην βάση μου σε ένα πίνακα ακόμα και στην περίπτωση που έχουν περαστεί κάποιοι χαρακτήρες με ελληνικά και κάποιοι με αγγλικά;»

    Στην ουσία αυτό που ήθελε ήταν αν έχω ένα πεδίο σε ένα πίνακα μου και έχω περάσει κάποια records που σε αυτό να έχω τις τιμές Antonis, Αντonis, Αntώνης εάν δώσω Antonis ή Αντώνης να μου τα φέρνει όλα.

    Αυτό γίνεται εύκολα αρκεί να χρησιμοποιήσεις για κάθε χαρακτήρα της λέξης που βάζει στο Like το pattern με τις αγκύλες στο οποίο ορίζεις τους χαρακτήρες που θα ψάξεις

    Πχ

    Έστω ότι έχω τον παρακάτω πίνακα
    create table tbLike
    ( id int identity(1,1) primary key,
    memo nvarchar(100))
    Στον οποίο περνάω 2 records
    insert into tbLike values ('λαλα'),('λaλa')
    και θέλω να μου φέρει και τα δύο records to query μου θα πρέπει να είναι το παρακάτω
    select * from tbLike where memo like 'λ[aα]λ[aα]'
    Επειδή αυτό θέλω να κατασκευάζεται αυτόματα τις έφτιαξα μια user define function η οποία παίρνει σαν παράμετρο το input του χρήστη και φτιάχνει το pattern me κάποιες παραδοχές όσον αφορά την αντιστοιχία των ελληνικών και αγγλικών γραμμάτων.

    Αυτή είναι η παρακάτω

    (σημείωση: Έχω προτιμήσει να την γράψω με τον απλούστερο τρόπο ώστε να είναι εύκολα μετατρέψιμη ακόμα και από κάποιον που ξέρει τα βασικά σε Τ-SQL)
    1: create function fnGreekEnglishLikeString(@instring nvarchar(100)) returns nvarchar(100)
    2: as
    3: begin
    4: --abcdefghijklmnopqrstuvwxyz
    5: --αβγδεζηθικλμνξοπρστυφχψω
    6:
    7: declare @rv nvarchar(100)
    8: declare @i int = 1
    9: declare @length int
    10: select @length = len(@instring)
    11: declare @s nvarchar(10)
    12: set @rv=''
    13: while @i
    14: begin
    15: set @s=''
    16: select @s=case
    17: when substring(@instring,@i,1) = 'a' or substring(@instring,@i,1) = 'α' then '[aα]'
    18: when substring(@instring,@i,1) = 'b' or substring(@instring,@i,1) = 'β' then '[bβv]'
    19: --when substring(@instring,@i,1) = 'c' or substring(@instring,@i,1) = '.' then '[bβ]'
    20: when substring(@instring,@i,1) = 'd' or substring(@instring,@i,1) = 'δ' then '[dδ]'
    21: when substring(@instring,@i,1) = 'e' or substring(@instring,@i,1) = 'ε' then '[eε]'
    22: when substring(@instring,@i,1) = 'f' or substring(@instring,@i,1) = 'φ' then '[fφ]'
    23: when substring(@instring,@i,1) = 'g' or substring(@instring,@i,1) = 'γ' then '[gγ]'
    24: when substring(@instring,@i,1) = 'h' or substring(@instring,@i,1) = 'β' then '[hηiι]'
    25: when substring(@instring,@i,1) = 'i' or substring(@instring,@i,1) = 'ι' then '[iιhη]'
    26: --when substring(@instring,@i,1) = 'j' or substring(@instring,@i,1) = 'β' then '[bβ]'
    27: when substring(@instring,@i,1) = 'k' or substring(@instring,@i,1) = 'κ' then '[kκ]'
    28: when substring(@instring,@i,1) = 'l' or substring(@instring,@i,1) = 'λ' then '[lλ]'
    29: when substring(@instring,@i,1) = 'm' or substring(@instring,@i,1) = 'μ' then '[mμ]'
    30: when substring(@instring,@i,1) = 'n' or substring(@instring,@i,1) = 'ν' then '[nν]'
    31: when substring(@instring,@i,1) = 'o' or substring(@instring,@i,1) = 'ο' then '[oοω]'
    32: when substring(@instring,@i,1) = 'p' or substring(@instring,@i,1) = 'π' then '[pπ]'
    33: --when substring(@instring,@i,1) = 'q' or substring(@instring,@i,1) = 'β' then '[bβ]'
    34: when substring(@instring,@i,1) = 'r' or substring(@instring,@i,1) = 'ρ' then '[rρ]'
    35: when substring(@instring,@i,1) = 's' or substring(@instring,@i,1) = 'σ' or substring(@instring,@i,1) = 'ς' then '[sσς]'
    36: when substring(@instring,@i,1) = 't' or substring(@instring,@i,1) = 'τ' then '[tτ]'
    37: when substring(@instring,@i,1) = 'u' or substring(@instring,@i,1) = 'υ' then '[uυy]'
    38: when substring(@instring,@i,1) = 'v' or substring(@instring,@i,1) = 'β' then '[vβb]'
    39: --when substring(@instring,@i,1) = 'w' or substring(@instring,@i,1) = 'β' then '[bβ]'
    40: when substring(@instring,@i,1) = 'x' or substring(@instring,@i,1) = 'χ' then '[xχ]'
    41: when substring(@instring,@i,1) = 'y' or substring(@instring,@i,1) = 'υ' then '[uυy]'
    42: when substring(@instring,@i,1) = 'z' or substring(@instring,@i,1) = 'ζ' then '[zζ]'
    43: else '['+substring(@instring,@i,1)+']'
    44: end
    45: set @rv=@rv+@s
    46: set @i+=1
    47: end
    48: return @rv
    49: end
    50: go
    Εάν κάποιος θέλει να δει το αποτέλεσμα που επιστρέφει η συγκεκριμένη function αρκεί να εκτελέσει το παρακάτω query
    select dbo.fnGreekEnglishLikeString('antonis')
    go
    Εάν τώρα θέλει να το ενσωματώσει στο query του
    select * from tbLike
    where memo like dbo.fnGreekEnglishLikeString('antonis')
    go
    Happy T-SQL Programming
  15. antonch
    Χαίρετε, καιρό είχατε να με ακούσετε ε;
    Δυστυχώς αυτά συμβαίνουν όταν αλλάζεις δουλειά.
    Όμως σιγά σιγά βρίσκω τα νέα βήματα μου οπότε επανέρχομαι δριμύτερος.
    Σήμερα θέλω να σας κουράσω με κάτι που δεν είναι στο 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.
  16. antonch
    Εδώ και αρκετό καιρό έχω γίνει αποδέκτης αρκετών ερωτήσεων σχετικά με τα σεμινάρια της Microsoft για τον SQL Server και συγκεκριμένα για τις εκδόσεις του 2012 & 2014. Οι ερωτήσεις αφορούν θέματα περιεχομένου και πιστοποίησης.
     
    http://www.sqlschool.gr/blog/what-you-must-know-about-official-training-and-certification-in-sql-server-2012-and-2014-1012.aspx
  17. antonch
    Επειδή μάλλον το πρώτο άρεσε είπα να κάνω και το δεύτερο σύντομα.
    Έτσι λοιπόν θα συνεχίσουμε από εκεί που μείναμε δηλαδή την δημιουργία μιας database με πολλά tips για αυτούς που θέλουν να μάθουν να σχεδιάζουν σωστά μια database στον SQL Server.
    Φυσικά αυτό από πίσω κρύβει αρκετή δόση αρχιτεκτονικής.
    Παρακάτω θα σας δίνω τα στοιχεία του meeting και ελπίζω να δω τους περισσότερους από εσάς.
    Ημερομηνία & Ώρα : 23/10/2010 22:30 μμ
    Attendee URL: https://www.livemeeting.com/cc/mvp/join?id=WP7JZ9&role=attend&pw=s%26Dr5%29JWD
    Meeting ID: WP7JZ9
    Attendee Entry Code: s&Dr5)JWD
    Duration: 2 hours
    Μέχρι τότε να είσαι όλοι καλά και να προσέχετε τον εαυτό σας.
    Εδώ θα βρείτε την μαγνητοσκοπημένη παρουσίαση
  18. antonch
    from msdn
    Accessing SQL Server Databases with PHP Auditing in SQL Server 2008 Best Practices for Data Warehousing with SQL Server 2008 Connectivity Options for Microsoft SQL Server 2008 Integration Services Consolidation Guidance for SQL Server Consolidation Using SQL Server 2008 Cryptography in SQL Server Data Access Tracing in SQL Server 2008 Database Encryption in SQL Server 2008 Enterprise Edition Embedding SQL Server 2008 Express in an Application Engine Separation of Duties for the Application Developer FILESTREAM Storage in SQL Server 2008 Geo-Replication Performance Gains with SQL Server 2008 on Windows Server 2008 High Availability with SQL Server 2008 How to Implement Kerberos Constrained Delegation with SQL Server 2008 Hub-And-Spoke: Building an EDW with SQL Server and Strategies of Implementation Improving Performance with SQL Server 2008 Indexed Views Installing SQL Server 2008 Express Guidance Introduction to Fast Track Data Warehouse Architectures Introduction to New Data Warehouse Scalability Features in SQL Server 2008 Introduction to New T-SQL Programmability Features in SQL Server 2008 Introduction to Spatial Coordinate Systems: Flat Maps for a Round Planet Migrating DTS Packages to Integration Services Migrating to SQL Server from Other Database Products Partitioned Table and Index Strategies Using SQL Server 2008 Plan Caching in SQL Server 2008 Remote BLOB Store Provider Library Implementation Specification Reporting Services SharePoint Integration Troubleshooting Resources for Upgrading to SQL Server 2008 Scaling Up Your Data Warehouse with SQL Server 2008 SQL Server Best Practices - Implementation of Database Object Schemas SQL Server RDL Specification SQL Server 2008 Full-Text Search: Internals and Enhancements Statistics Used by the Query Optimizer in Microsoft SQL Server 2008 Troubleshooting Performance Problems in SQL Server 2008 Using the Microsoft Connector for Oracle by Attunity with SQL Server 2008 Integration Services Using Microsoft Connector for Teradata by Attunity Using the Resource Governor Using SQL Server to Build a Hub-and-Spoke Enterprise Data Warehouse Architecture Using SQL Server 2008 Integration Services with SAP BI 7.0 Using SQL Server 2008 Reporting Services with the.NET Framework Data Provider for Teradata Using SQL Server 2008 Reporting Services with SAP NetWeaver Business Intelligence Using Star Join and Few-Outer-Row Optimizations to Improve Data Warehousing Queries We Loaded 1 Terabyte in 30 Minutes with SSIS, and So Can You
  19. antonch
    Πρόσφατα έπεσα μούρη με μούρη σε μια παρουσίαση του Kevin Cox που είχε το παραπάνω θέμα. Επειδή είναι αρκετά ενδιαφέρουσα και ρίχνει αρκετούς μύθους αποφάσισα να την μοιραστώ μαζί σας.
    Ας ξεκινήσουμε με μερικά στατιστικά
    Category Metric Largest single database
    70 ΤΒ Largest table
    20 ΤΒ Biggest total data 1 application
    88 PB Highest database transactions per second 1 db (from Perfmon)
    130.000 Fastest I/O subsystem in production (SQLIO 64k buffer)
    18 GB/sec Fastest “real time” cube
    5 sec latency data load for 1TB
    20 minutes Largest cube
    12 TB Ας προχωρήσουμε στα πιο ειδικά
    OLTP Systems
    MySpace
    500+ SQL Servers, adding new ones every week Total data managed > 1 PB Data Dependent Routing, Distributed Partitioned Views, Replication, SODA Currently moving to Windows 2008 / SQL 2008 Data Dependent Routing, Distributed Partitioned Views, Replication, Caching Tier, Service Broker 500,000 Users: A Simple Architecture Stumbles (two Web servers talking to a single database server – 3 database servers (1 write, 2 read)) 1 Million Users: Vertical Partitioning Solves Scalability Woes (separate databases for parts of the Web site that served different functions) 3 Million Users: Scale-Out Wins Over Scale-Up (cost for scale-up too high), SODA 9 Million Users: Site Migrates to ASP.NET, Adds Caching Tier, Data Dependent Routing 26 Million Users: MySpace Embraces 64-Bit Technology, SQL Server 2008, Service Broker High Availability Windows Clusters 7+1, moving to 10+1 Unattended patching via custom Powershell scripts and management control screen Extensive testing before patching Continually improving operations process 3,000 – 7,000 connections average 2 data centers Doing SAN snapshots between sites In case of loss of one site, can bring up other site to take over within a few hours. Great article on architecture changes as they grew: http://www.baselinemag.com/article2/0,1540,2082921,00.asp Bwin.com
    Online gaming applications - Europe‘s largest betting line-up Sports Poker Casino Skill Games 90 different sports covered in 22 languages > 12,000 different bets offered per day > 3 million individual and combination bets placed every day Bwin.com sponsors top world soccer teams Real Madrid AC Milan FC Bayern Munich Key Technologies Running on SQL Server 2008 & Windows 2008 Enterprise Windows Communication Foundation Synchronous database mirroring between two centers 12 km apart Added 1 ms delay on transaction 99.99x% availability @ 24 x 7 since migrating to SQL from Oracle. 100.00% uptime in 2008 and 2009 (since moving to SQL 2008 and Windows 2008) Zero data loss (financial transactions are involved) Replication and Log shipping for most databases DB Mirroring for betting data base. Full suite of SQL products - IS, AS and RS ASP.NET for applicatio Some numbers Peak financial transactions 6000 per second Peak db transactions 30,000 per second Databases 800+ Instances 100+ Largest table 2 billion rows Total data in SQL Server 100+ TB Backup of 2 TB over network under 1 hr Largest machines 64 core 512 GB IA2 HP 6 x 32 core IA2 400% boost in performance on 128 cores 256GB RAM on IA64 using SQL 2008 R2 More info http://sqlcat.com/whitepapers/archive/2009/08/13/a-technical-case-study-fast-and-reliable-backup-and-restore-of-a-vldb-over-the-network.aspx http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=4000001470 Retail Application
    1,200 stores SQL Standard 10 GB average 15,000 cash registers SQL Express 10 MB database average 1 Corporate Server SQL Enterprise Windows Cluster + DB Mirroring AS, IS, RS 12+ TB database, 1.5 TB cube. Merge replication for products & pricing Service Broker for all transactions One of the largest Service Broker and replication projects in the world 2 Million SKUs (products) 25 Million Accounts 10 million transactions / day SQL Server, AS, IS, RS Windows Cluster, DB Mirroring, Log Shipping

    DATA WAREHOUSEs

    Pan Starrs Project
    Largest Astronomy project in history 4 telescopes capturing 1.5 giga pixel images 100TB on single instance (5 db x 20TB) Total data managed > 1PB 5+TB added per day HA/DR Relying on backups of the input files for now Telecom
    CDR Analytics 70TB Relational 4TB largest cube 100+ concurrent queries Itanium 64 core with storage system rated over 20GB/sec throughput Loading 1TB in Processing 1m rec/sec in AS cubes Hilton Hotels
    Room forecasting system Full suite of SQL products (SQL, AS, IS, RS) Scale out AS and RS Load Balanced Analysis Services reader machines 40 to 50 concurrent users per RS server Complex queries Large data sets returned to many clients IBM xSeries and IBM Blade Center servers Case study: http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=49192 Stein Mart
    First Fast Track case study Saved $50,000 / month after AS/400 migration Faster results – 3 hours of processing instead of 14 hours Less people to maintain Users love the new tools! 4 TB data warehouse http://www.microsoft.com/casestudies/Case_Study_Detail.aspx?casestudyid=4000007013
  20. antonch
    Ίσως όσα θα αναφερθούν παρακάτω να είναι γνωστά, και το 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.
  21. antonch
    Αφορμή για αυτό το post είναι ο Blackman. Σε μια ωραία συζήτηση που είχαμε μου εξέφρασε την επιθυμία για αυτό επειδή μια εφαρμογή που έχει του αφήνει ανοικτά sessions.
    Σε αυτό το σημείο θα πρέπει να αναφέρω ότι κάτι τέτοιο μπορεί να συμβεί είτε διότι η εφαρμογή δεν έχει γραφτεί σωστά, είτε έπειδή ο σταθμός εργασίας που έχει ανοίξει το session σταμάτησε να λειτουργεί είτε η εφαρμογή σταμάτησε απότομα.
    Ο SQL Server βέβαια έχει τους μηχανισμούς για να τα “σκοτώνει” αυτόματα αλλά απαιτείται να πειράξεις registry (http://msdn.microsoft.com/en-us/library/aa275788(SQL.80).aspx) αν θέλεις να γίνεται σε πιο σύντομο διάστημα. Όμως όπως θα δείτε και στο link που σας έδωσα στην ουσία πειράζει το πρωτόκολο επικοινωνίας, και αυτό ίσως να μην το θέλεις αν έχεις και άλλα services.
    Εαν πάντως δεν θέλεις να κάνεις την παραπάνω αλλαγή σας παρέχω 2 τρόπους για να κάνετε kill τα idle sessions.
    ΤΡΟΠΟΣ Α.
    Αυτό ο τρόπος “σκοτώνει” όλα τα idle session σε όλες τις databases εκτός από τις system databases και το session με το οποίο κάνουμε την εκτέλεση της εργασίας.
    Για να το κάνετε αυτό πρέπει πρώτα να πάρετε τον παρακάτω κώδικα να να τον τρέξετε μέσα από ένα query στον SQL Server με επιλεγμένη βάση την master. Αυτός θα σας φτίαξει μια stored procedure σε αυτή την οποία μπορείτε να την εκτελέσετε ως εξής
    EXEC dbo.spKillAllIdleSession
    : είναι ο χρόνος σε λεπτά που το session δεν κάνει τίποτα δηλαδή αν πούμε 20 σημαίνει “σκότωσε όλα τα session που πάνω από 20 λεπτά δεν κάνουν τίποτα.
    π.χ EXEC dbo.spKillAllIdleSession 20




    CREATE PROC dbo.spKillAllIdleSessions
                @IdleTime int    -- Parameter to set your desirable idle time for session in minutes
    /*
        This stored procedure kills all idle processes in sql server 2005, 2008
        except the current process and all processes on system databases
        
        Created by Antonios Chatzipavlis Sep 27, 2009
    */
    as

        DECLARE @killCommand varchar(50)
        DECLARE IdleSessions CURSOR FOR
            SELECT 'KILL ' + Convert(VARCHAR(5), p.spid)
                FROM master.sys.sysprocesses AS p
                    WHERE  p.spid > 50
                    AND p.spid @@SPID
                    AND DateDiff(minute, p.last_batch, GetDate()) > @IdleTime
                    AND p.dbid not in (DB_ID('master'),DB_ID('model'),DB_ID('msdb'),DB_ID('tempdb'),
                                        DB_ID('ReportServer'),DB_ID('ReportServerTempDB'),DB_ID('distribution'))
                    
        OPEN IdleSessions
        FETCH IdleSessions INTO @killCommand

        WHILE 0 = @@fetch_status
        BEGIN
            EXECUTE (@killCommand) -- Actually execute the command
            FETCH IdleSessions INTO @killCommand
        END

        CLOSE IdleSessions
        DEALLOCATE IdleSessions
    GO




    ΤΡΟΠΟΣ Β.
    Αυτό ο τρόπος “σκοτώνει” όλα τα idle session σε συγκεκριμένη database εκτός από το session με το οποίο κάνουμε την εκτέλεση της εργασίας.
    Για να το κάνετε αυτό πρέπει πρώτα να πάρετε τον παρακάτω κώδικα να να τον τρέξετε μέσα από ένα query στον SQL Server με επιλεγμένη βάση την master. Αυτός θα σας φτίαξει μια stored procedure σε αυτή την οποία μπορείτε να την εκτελέσετε ως εξής
    EXEC dbo.spKillAllIdleSessionInDatabase ,
    : είναι ο χρόνος σε λεπτά που το session δεν κάνει τίποτα δηλαδή αν πούμε 20 σημαίνει “σκότωσε όλα τα session που πάνω από 20 λεπτά δεν κάνουν τίποτα.
    : είναι το όνομα της database.
    π.χ EXEC dbo.spKillAllIdleSessionInDatabase 20, ‘MyDB’



    CREATE PROC dbo.spKillAllIdleSessionsInDatabase
                @IdleTime int    -- Parameter to set your desirable idle time for session in minutes
    ,            @DBName varchar(50) -- Parameter to set database name            
    /*
        This stored procedure kills all idle processes in a specific database
        Created by Antonios Chatzipavlis Sep 27, 2009
    */
    as

        DECLARE @killCommand varchar(50)
        DECLARE IdleSessions CURSOR FOR
            SELECT 'KILL ' + Convert(VARCHAR(5), p.spid)
                FROM master.sys.sysprocesses AS p
                    WHERE  p.spid > 50
                    AND p.spid @@SPID
                    AND DateDiff(minute, p.last_batch, GetDate()) > @IdleTime
                    AND p.dbid =DB_ID(@DBName)
                    
        OPEN IdleSessions
        FETCH IdleSessions INTO @killCommand

        WHILE 0 = @@fetch_status
        BEGIN
            EXECUTE (@killCommand) -- Actually execute the command
            FETCH IdleSessions INTO @killCommand
        END

        CLOSE IdleSessions
        DEALLOCATE IdleSessions
    GO




    ΠΑΡΑΤΗΡΗΣΕΙΣ
    Τόσο κατά την δημιουργία, όσο και κατά την εκτέλεση ο χρήστης με τον οποίο έχετε κάνει login στον SQL Server θα πρέπει να είναι στον system role sysadmins. Εαν θέλετε να το φτιάξετε για SQL Server 2000 απλά αλλάξε το σημείο FROM master.sys.sysprocesses AS p σε FROM master.dbo.sysprocesses AS p  
  22. antonch
    Πάντα υπάρχει κάτι που μπορεί να σε κάνει να χαμογελάσεις ευχάριστα ακόμα και αν είναι ένα μήνυμα λάθους!.

    Κάνοντας ένα τυπικό έλεγχο σε ένα παλιό Always On Availability Group διαπίστωσα ότι ένα domain group που είχε πρόσβαση στο ένα node δεν είχε πρόσβαση στο άλλο. Φυσικά αυτό θα έπρεπε να διορθωθεί καθώς σε περίπτωση που γίνονταν failover οι χρήστες του συγκεκριμένου domain group δεν θα είχαν πρόσβαση στο άλλο.

    Τι ποιο απλό από το να κάνει κάνεις αυτή την διαδικασία είτε μέσω SSMS είτε με την εκτέλεση ενός GREATΕ LOGIN command και να βάλεις το domain group αυτό στο node που δεν υπάρχει.

    Παρόλα αυτά όμως κατά την διάρκεια της εκτέλεσης της διαδικασίας έλαβα το error message “The server principal ‘…..’ already exists – Msg 15025”, αλλά δεν υπήρχε λόγος ανησυχίας καθώς αμέσως υποψιάστηκα το τι έχει γίνει απλά έπρεπε να το επιβεβαιώσω.

    Πήγα στο node όπου το domain group υπήρχε και εκτέλεσα το παρακάτω command για να πάρω το SID του login (που επειδή είναι domain group είναι το ίδιο με το domain SID). Η SUSER_SID επιστρέφει το SID του Login που στην ουσία με αυτό δουλεύει ο SQL Server για να υλοποιήσει το security που διαθέτει.

    http://sqlschool.gr/blog/the-server-principal-already-exists-%E2%80%93-error-15025-troubleshooting-1059.aspx
  23. antonch
    Κάθε φορά που στο μυαλό σου έρχεται η σκέψη να κάνεις upgrade ένα υπάρχον SQL Server instance ή κάποιες databases σε επόμενη έκδοση τα αισθήματα σου είναι ανάμικτα. Από την μια λες πρέπει να γίνει καθώς θα πάω σε κάτι νέο με περισσότερα χαρακτηριστικά και δυνατότητες και έτσι θα είμαι σε θέση να παρέχω καλύτερες υπηρεσίες στους χρήστες μου. Από την άλλη αναρωτιέσαι αν αυτό θα σου δημιουργήσει προβλήματα καθώς μπορεί κάποια πράγματα μπορεί να μην δουλέψουν γιατί μπορεί να μην υπάρχει συμβατότητα καθώς κάτι μπορεί να μην υποστηρίζεται στην νέα έκδοση. Κάπως έτσι ξεκινάει ο εφιάλτης. Αλλά για μια στιγμή μήπως τελικά ο εφιάλτης είναι πόνημα φαντασίας;
     
    http://www.sqlschool.gr/blog/how-to-deal-with-migration-or-instance-upgrade-nightmares-1023.aspx
  24. antonch
    Επειδή το security στη database είναι αρκετά σημαντικό και πραγματικά δεν ξέρω γιατί οι περισσότεροι δεν δίνουν την πρέπουσα σημασία σε αυτό το σύντομο post θα σας δώσω ένα tip του οποίου η εφαρμογή ξεπερνάει το 99% των περιπτώσεων.
     
    http://www.sqlschool.gr/blog/create-a-db_executor-database-role-1013.aspx
×
×
  • Create New...