Στο project που αναπτύσσω υπάρχει η εξής παράμετρος. Ενώ τα κυρίως δεδομένα του συστήματος είναι σχετικά λίγα (το πολύ 100MB), τα δεδομένα που έχουν να κάνουν με την καταγραφή της δραστηριότητας μπορεί να είναι πάρα πολλά (σε μια εξαιρετική περίπτωση ένας πελάτης, στην πρηγούμενη έκδοση, θέλει να κρατάει log 4-5 ετών, οπότε μιλάμε για περισσότερα από 30GB!). Το πρόβλημα που δημιουργείται είναι κυρίως στο backup. Δεδομένου ότι τα βασικά δεδομένα είναι πολύ λίγα και θα μπορούσαν να αντιγράφονται και δυο φορές τη μέρα, λόγω του log γίνεται backup μια φορά την εβδομάδα και αυτό είναι ολόκληρη ιστορία.
Σκέφτηκα λοιπόν να έχω ξεχωριστή βάση δεδομένων για το logging. Δεδομένου ότι υπάρχει και application server θα είναι κάτι σχετικά απλό και διαφανές προς τον χρήστη.
Είναι καλή λύση ή υπάρχει και άλλος τρόπος, μέσω ρυθμίσεων στον sql server;
Σημείωση: Η βάση μου θα είναι συμβατή με sql server 2000 και 2005

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Αν το μόνο που σε απασχολεί είναι το μέγεθος του backup, δεν χρειάζεται να αλλάξεις κάτι. Επιλέγοντας ένα συνδυασμό full και differential μπορείς να πετύχεις αυτό που θέλεις. Π.χ. να παίρνεις ένα full backup μία φορά την εβδομάδα και differential κάθε μέρα. Με τον τρόπο αυτό για να κάνεις restore θα χρειάζεσαι το τελευταίο full και differential. Αν θέλεις τα backup να πιάνουν λιγότερο χώρο, μπορείς να κάνεις πιο αραιά το full, π.χ. μία φορά το μήνα, κάθε εβδομάδα differential και κάθε μέρα transaction log backup. Σε αυτή την περίπτωση χρειάζεσαι το full, το differential και όλα τα transaction log backups από το τελευταίο differential. Πιάνει μεν λιγότερο χώρο, αλλά καθυστερεί περισσότερο στο restore.

Το άλλο που μπορείς να κάνεις είναι να αποθηκεύεις τους πίνακες του logging σε άλλο filegroup και να έχεις διαφορετικές διαδικασίες backup για τα δεδομένα και το logging. Έτσι θα μπορείς, π.χ. να έχεις full+differential για τα δεδομένα, full+differential+log για το logging. Με τον τρόπο αυτό το restore των δεδομένων θα είναι γρήγορο, το restore του logging θα πάρει περισσότερο χρόνο.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Οπότε δεν βλέπεις κανένα λόγο να έχω δεύτερη βάση.

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

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

To ερώτημα είναι τι ρόλο παίζουν αυτά τα data. Αν για παράδειγμα τα έχεις για reporting σκοπό, τότε σαφώς θα μπορούσαν να μπουν σε μία άλλη βάση ώστε να βελτιστοποιηθούν τα read operations και ίσως αργότερα να μπούν σε έναν άλλον server, πράγμα που θα είναι ευκολότερο αν εξ αρχής έχεις σχεδιάσει την εφαρμογή σου να βλέπει δύο διαφορετικές βάσεις. Αν αυτά τα data λαμβάνουν μέρος στα OLTP operations τότε περιπλέκεται η αρχιτεκτονική (πλέον θα έχεις distributed transactions) και ιδιαίτερεα τα database administration tasks.

---

Vir prudens non contra ventum mingit

Οπότε λέτε... άλλο filegroup.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.