Jump to content

Απορίες περί database backup και όχι μόνο...


Memphis
 Share

Recommended Posts

Καλησπέρα σε όλους[:)]

 

 

Άφησα για λίγο στην άκρη το VPN (προς το παρόν παίζει μια χαρά χωρίς προβλήματα, θα επανέλθω για τη θωράκισή του) και

 

ασχολούμαι με δύο σημαντικές βάσεις, μία του ERP και μία της μισθοδοσίας.

 

Να ξεκαθαρίσω ότι είμαι αρχάριος όσον αφορά τις βάσεις. Στο ένα μου χέρι έχω το autoexec, στο άλλο το εξαιρετικό blog του κ.

 

Χατζηπαυλή και πορεύομαι στον άγνωστο για εμένα κόσμο των βάσεων[:)]

 

Αρχικό μου μέλημα είναι να παίρνω από όλες ένα σωστό backup.

 

Το μηχάνημα αποτελείται από Core 2 Duo E6750, 2GB RAM, 320GB HDD SATA (ξέρω, θέλει αλλαγή αλλά προς το παρόν εκεί

 

φιλοξενούνται).

 

 

Ξεκινάω με την πρώτη βάση, του ERP και δίνω λεπτομέρειες:

 

Server: Microsoft SQL Server 2000 SP3 Developer Edition

 

Database: Size 794,56MB, Space Available 64,02MB, Space Allocated 793MB (autogrowth 10%), Simple Recovery Model, Transaction

 

Log allocated 2MB, 10% autogrowth

Αριθμός active χρηστών 7 στο pick, και 2-3 συνήθως connected.

 

 

Και ξεκινώ:

 

1)Space allocated είναι ο χώρος που δεσμεύει στο δίσκο το data file;

 

2)Space available είναι ο ελεύθερος χώρος στο allocated που έχει μείνει από το τελευταίο growth;

 

3)Επιβάλλεται αναβάθμιση σε SP4 ή καλύτερα να την αφήσω όπως είναι;

 

 

Σχετικά με το backup:

Έχει δημιουργηθεί ένα maintenance plan το οποίο παίρνει ένα local full backup τη βάση κάθε μέρα στις 5 το απόγευμα . Επίσης το

 

plan δεν περιλαμβάνει maintenance tasks (rebuild indexes πχ).

 

Σκέφτομαι να κάνω τα εξής:

 

  • Να ορίσω το database file growth fixed στα 400MB
  • Να ορίσω transaction log file size 250MB, autogrowth fixed στα 250MB (αν και δεν θα χρειαστεί ποτέ να μεγαλώσει αν

     

    παίρνονται τα t-log backups)

  • Να γυρίσω τη βάση σε full recovery model

  • Να κάνω schedule το εξής maintenance plan:

    Full BackUp Daily 4:00 AM/Differential Back Up every 8 hours (8:00, 16:00, 11:59)/Transaction Log Back Up every 1 hour

  • Να προσθέσω ένα εξωτερικό δίσκο και να αντιγράφονται εκεί τα backup files

4)Πώς σας φαίνεται το plan;

 

Σκέφτομαι μήπως είναι πολύ σφιχτό για το usage αλλά από την άλλη γιατί να χαθούν δεδομένα έστω και μίας ώρας; Υπάρχουν

 

περιπτώσεις που το ERP ενημερώνεται συνεχώς μέχρι και αργά το απόγευμα, υπάρχουν και άλλες που ενημερώνεται μόνο για μια ώρα

 

την ημέρα.

 

5)Όσον αφορά maintenance tasks πρέπει να ενεργοποιήσω rebuild indexes ή κάποιο άλλο για να βρίσκεται η βάση σε καλή κατάσταση;

6)Είναι safe η ενέργεια ή υπάρχει περίπτωση να επηρεαστεί αρνητικά η βάση;

 

 

Έχω ξεκινήσει και monitoring ενεργοποιώντας τους counters που προτείνει ο κ. Χατζηπαυλής (Memory – Pages/sec, Physical Disk –

 

Disk Transfers/sec, Processor - % Processor Time, SQL Buffer Manager – Cache Hit Ratio) και προς το παρών δεν έχω διαπιστώσει

 

κάποιο bottleneck. Από αυτά που ξέρω μέχρι τώρα τουλάχιστον.

 

7)Υπάρχει κάποιος άλλος counter που θα ήταν χρήσιμο να ενεργοποιήσω;

 

Σημαντικό ρόλο παίζει και το performance μιας και δεν έχουμε το άφθονο γρήγορο hardware.

 

 

Η δεύτερη βάση είναι της μισθοδοσίας και αποτελείται από:

 

Server: Microsoft SQL Server 2005 Standard RTM

 

Database: Size 493MB, Initial Size 273MB,autogrowth by 1MB, unrestricted growth, Simple Recovery Model, Transaction Log Initial

 

Size 133MB, 10% autogrowth restricted to 2GB.

 

 

Σε αυτήν δεν έχει ενεργοποιηθεί καν ο agent (το service είναι σε manual startup) και γίνεται full backup μέσα από την εφαρμογή

 

με παρέμβαση του χρήστη.

 

8)Υπάρχει περίπτωση κάποιο conflict με τον agent του SQL 2000; Μόνο κάτι τέτοιο μπορώ να σκεφθώ για να είναι απενεργοποιημένο

 

το service. Start κάνει κανονικά.

 

 

Για αυτήν σκέφτομαι:

 

  • Να ορίσω το database file growth fixed στα 300MB
  • Να ορίσω transaction log file size 150MB, autogrowth fixed στα 150MB

  • Να γυρίσω τη βάση σε full recovery model και να κάνω schedule τα ίδια jobs με την πρώτη βάση.

Πέρα από αυτές τις 2 κύριες βάσεις σε κάθε server έχω καταλάβει πως είναι σημαντικό να παίρνω και τα system databases backup

 

(master, model, msbd).

 

9)Ένα full backup για αυτές ανά 3 ημέρες είναι αρκετό; Και ακόμα ένα αμέσως μόλις υπάρχουν μεγάλες αλλαγές σε χρήστες ή system

 

configurations.

 

 

 

Επίσης, θέλω να τα περάσω όλα αυτά σε ένα test περιβάλλον για να κάνω εκεί δοκιμές (αναβαθμίσεις SQL και τα σχετικά).

10)Παίρνω ένα image με το disktovhd, το φορτώνω στον hyper-v και είμαι έτοιμος;

 

 

Αυτά για την ώρα.

 

Πάντα μακροσκελή τα post μου, το ξέρω [:)].

 

Πού θα πάει, κάποια στιγμή θα μειωθεί το μέγεθός τους[:)].

 

Ευχαριστώ προκαταβολικά [:)]

 

Link to comment
Share on other sites

Καλημέρα

Σε γενικές γραμμές έχει σκεφτεί σωστά. Δεν έχω πολλές διαφωνίες στην σκέψη σου για τα συγκεκριμένα σενάρια που έχεις περιγράψει.  

Φυσικά και θα πρέπει πάντα να έχεις το τελευταίο SP και ίσως και CU.

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

Φιλικά

 

Link to comment
Share on other sites

Επιτέλους βρήκα το χρόνο

H SQL Server Developer Edition δεν είναι για παραγωγικά περιβάλλοντα και μάλιστα είναι παράνομο να σε τέτοια!

Στις πρώτες τρεις ερωτήσεις σου δεν θα σου πω κάτι ιδιαίτερο μιας και είναι προφανείς οι απαντήσεις.

Για το πλάνο του πρώτου backup πάλι δεν θα σου πω κάτι μιας και είναι από τα best practices.

Καλό είναι μια φορά στο τόσο (αυτό θα κρίνεις με βάση το ρυθμό των transactions που έχεις) να έχεις μια εργασία που θα κάνει index maintenance χωρίς  όμως να το εμπλέξεις με κάποια διαδικασία backup. Αν και καλό είναι να παίρνεις full backup μετά από αυτό.

Μετρητές υπάρχουν να φάνε και οι κότες, αλλά μην μπλέξεις ακόμα μαζί τους εφόσον αυτοί που έχω πει δεν έχουν θέμα.

Performance & Hardware πάνε αγκαλιά. Όπως καταλαβαίνεις με yogo δεν μπορείς να πας πάνω από 120. Εφόσον θέλεις να πας με 200 χρειάζεσαι κάτι άλλο. Άρα το performance ορίζεται με βάση το baseline που θα βγάλεις. Δλδ θα πρέπει να αποθηκεύεις τις μετρήσεις σου ώστε κάθε νέα μέτρηση που θα κάνεις να την συγκρίνεις με τις προηγούμενες ώστε να είσαι σε θέση να αποφανθείς για το αν πας αργά.

Στην βάση της μισθοδοσίας θα πρέπει να αλλάξεις το autogrowth σε κάτι μεγαλύτερο πιστεύω με βάση την εμπειρία μου ότι μια τιμή γύρω στα 30ΜΒ είναι αρκετή για μια μέση μισθοδοσία. Αν και αυτό που γράφω είναι λίγο αυθαίρετο καθώς βλέπω ότι η βάση είναι μικρή σε μέγεθος και με βάση αυτό κάνω την πρόταση μου, αλλά δεν ξέρω αν είναι επειδή ακόμα δεν έχει χρησιμοποιηθεί ή αν χρησιμοποιείται καιρό

Το να μεγαλώσεις μια βάση σε μέγεθος δεν είναι κακό, ίσα ίσα μειώνεις το I/O. Το σωστό βέβαια είναι πριν αυθαίρετα ορίσεις μέγεθος να έχεις κάνει capacity planning ή για ένα χρονικό διάστημα να παρακολουθείς την αύξηση του μεγέθους της ώστε να βρεις το λόγο εκείνο που θα πρέπει να χρησιμοποιήσεις ώστε να τον χρησιμοποιήσεις για να καλύψεις ανάγκες πχ ενός έτους.

Το να γυρίσεις την βάση τις μισθοδοσίας σε full recovery model δεν νομίζω ότι σου χρειάζεται καθώς το πρόγραμμα χρησιμοποιείται σε συγκεκριμένο χρόνο μέσα στο μήνα για την έκδοση της μισθοδοσίας. Επίσης δεν νομίζω ότι σε ημερήσια βάση θα έχεις τόσα transactions τα οποία δεν θα μπορείς εύκολα να αναπαράγεις αν σου σκάσει η βάση και έχεις στα χέρια σου καθημερινό full backup. Με βάση αυτό δεν χρειάζεται να αλλάξεις και το μέγεθος του log.

Τις system databases καλό είναι να τις παίρνεις καθημερινά και αυτές backup δεν θα το καταλαβαίνεις καθόλου είναι πάρα πολύ μικρές, αν και η θεωρία λέει ότι τις παίρνουμε backup όποτε κάνουμε αλλαγές σε αυτές πχ βάζουμε ένα νέο χρήστη ή αλλάζουμε μια ρύθμιση στον SQL Server (master) ή βάζουμε ένα job ή ένα maintenance plan (msdb). Έτσι αντί να μπαίνεις σε αυτή την σκέψη φτιάξε ένα task για καθημερινό backup τους και είσαι μια χαρά.

Για την δημιουργία του test environment το να φτιάξει ένα vm και απλά να κάνεις restore τις βάσεις σε αυτό νομίζω ότι είναι αρκετό.

 

Link to comment
Share on other sites

Επανέρχομαι σήμερα μιας και τις προήγουμενες ημέρες υπήρχε μεγάλος φόρτος [*-)]

 

Κ. Χατζηπαυλή καταρχάς ευχαριστώ πολύ για τις απαντήσεις.

 

Επί του θέματος:

H SQL Server Developer Edition δεν είναι για παραγωγικά περιβάλλοντα και μάλιστα είναι παράνομο να σε τέτοια!

Το μηχάνημα είναι σε διαδικασία αλλαγής hardware. Οπότε είναι μια καλή ευκαιρία να περάσουμε και σε καινούρια έκδοση SQL.

Το να γυρίσεις την βάση τις μισθοδοσίας σε full recovery model δεν νομίζω ότι σου χρειάζεται καθώς το πρόγραμμα χρησιμοποιείται σε συγκεκριμένο χρόνο μέσα στο μήνα για την έκδοση της μισθοδοσίας. Επίσης δεν νομίζω ότι σε ημερήσια βάση θα έχεις τόσα transactions τα οποία δεν θα μπορείς εύκολα να αναπαράγεις αν σου σκάσει η βάση και έχεις στα χέρια σου καθημερινό full backup.

Σχετικά με τη βάση της μισθοδοσίας και την παραμονή σε Simple Recovery Model, τα transactions ανακτώνται με tail log backup από το τελευταίο full ή differential; Μπορώ να πάρω tail-log ενώ η βάση είναι εκτός και σε Simple Recovery Model;

 

Είμαι σε διαδικασία δημιουργίας των plans. Θα συμπεριλάβω και τα system databases και θα τα ποστάρω όταν είναι έτοιμα. [:)]

 

 

Link to comment
Share on other sites

Όταν η database είναι σε simple recovery model δεν μπορείς να παίρνεις transaction log backup οποιασδήποτε μορφής.

Προσωπική μου άποψη είναι ότι δεν χρειάζεται να αλλάξεις την βάση της μισθοδοσίας μιας και όπως έχω ήδη πει δεν είναι ένα προγραμμα που δέχεται καθημερινά μεγάλο αριθμο απο transactions. Ακόμα και αν μέσα στην ημέρα χάσεις την βάση μπορείς να γυρίσεις μέχρι το τελευταίο full ή differential που έχεις. Και μετα να ξανά κανείς ότι σου λείπει. Αν πάλι αυτο που σου λέω δεν σου αρέσει ο SQL server δεν έχει κανένα πρόβλημα. Άλλαξε την βάση σε full και προχωρά με αυτο που έχουμε πει και για την άλλη βάση.
Link to comment
Share on other sites

Όταν η database είναι σε simple recovery model δεν μπορείς να παίρνεις transaction log backup οποιασδήποτε μορφής.

Κατανοητό[:)]

 

Οπότε θα δημιουργήσω ένα plan με full και differential σε συχνά διαστήματα (ανά 6 ή 4 ώρες).

 

Link to comment
Share on other sites

 Share

×
×
  • Create New...