Πρόσφατα χρειάστηκε να διαβάσω για να μάθω τι είναι, πως στήνεται και πως δουλεύει το replication στον SQL SERVER 2000. Έχω παρατηρήσει λοιπόν κάποια ενδιαφέροντα φαινόμενα που θα ήθελα να μοιραστώ μαζί σας για να ακούσω και γνώμες...

Μια μικρή εισαγωγή για να σας βάλω στο πνεύμα της δουλειάς:
Έχω στήσει ένα σενάριο transactional replication και αναγκαστικά στον subscriber έβγαλα το IDENTITY από όσα πεδία το είχαν. Μια και ο σκοπός της subscriber βάσης είναι να λειτουργήσει σαν primary σε περίπτωση απώλειας της publisher, ήθελα να δημιουργήσω τα ανάλογα scriptακια για να μπορεί εύκολα κάποιος να κάνει τη βάση "λειτουργική". Έτσι βρήκα το NFR (NOT FOR REPLICATION). Θεωρητικά, ορίζοντας το IDENTITY με NFR, τα ID που έρχονται από τον publisher μπαίνουν στη βάση όπως είναι, ενώ για τα record που δημιουργούνται από users εκτός του replication agent, παράγονται νέα ID.
Και τώρα στο ζουμί:
Κάνοντας δοκιμές είδα ότι για τα record που έβαζα με το χέρι, παράγονταν ID, αλλά όχι μεγαλύτερα από το μεγαλύτερο που υπήρχε. Παράγονταν έτσι που να κλείνουν τα όποια κενά μπορεί να είχαν προκύψει (και τα οποία θεωρούμε δεδομένα στην περίπτωσή μας). Αλλάζοντας το IDENTITY σε "απλό" (πράγμα που στον subscriber απαγορεύεται), μου έδινε κανονικά το επόμενο ID. Έχει δει κανείς πως δουλεύει αυτό; Είναι η φυσιολογική συμπεριφορά;
Επίσης, πριν δω το παραπάνω "φαινόμενο", τι πιο λογικό απ' το να θελήσω να κάνω τα IDENTITY του publisher να έχουν NFR ώστε σε περίπτωση backup/restore ή snapshot να είναι "έτοιμα" στον subscriber... Έλα όμως που όταν στήνεις το replication (με wizard πάντα) δεν αναγνωρίζει διαφορά και σε σταματάει λέγοντας να τα φτιάξεις manually ώστε να έχουν NFR...


Μπορεί να κάνω λάθος στην ορολογία αλλά ελπίζω να με καταλαβαίνετε, και πάλι εδώ είμαι για διευκρινίσεις.
Ευχαριστώ,
Κώστας

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

Κοντά 2 μήνες μετά καμία απάντηση έστω για μια διευκρίνηση αν το συντακτικό μου είναι κακό και δεν γίνεται κατανοητό αυτό που λέω. Καμία ιδέα κανείς, πρώτος το συνάντησα;;

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

Έτσι όπως το περιγράφεις είναι φυσική συμπεριφορά. Ι βάση του subscriber θα χρισιμοποιτε μόνο για backup ι θέλεις να κάνεις εγγραφές και εκεί?

Πέρα από αισθητικές λεπτομέρειες, δεν υπάρχει ζήτημα συντακτικού. Απλά, την περίοδο που έκανες την ερώτηση, οι συνήθεις ύποπτοι για SQL (ο Kelman κι εγώ) ετοιμαζόμασταν για ταξίδι στην Αμερική. Οπότε η ερώτηση κάπου ξεχάστηκε.

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

---

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

Grigoris:

Έτσι όπως το περιγράφεις είναι φυσική συμπεριφορά. Ι βάση του subscriber θα χρισιμοποιτε μόνο για backup ι θέλεις να κάνεις εγγραφές και εκεί?

O subscriber είναι για περίπτωση disaster recovery. Να εχει δλδ πάντα την τελευταια όσο είναι δυνατόν εικόνα ώστε να μπορεί να δουλέψει σαν primary αν πέσει ο βασικός server. Οπότε δεν γίνονται εγγραφες που θα έκαναν τα πράγματα πιο περίπλοκα.
Μιλάς όμως και για τη συμπεριφορά του ID? Γιατί αυτή είναι που βρήκα περίεργη...

Παναγιώτης Καναβός:

Πέρα από αισθητικές λεπτομέρειες, δεν υπάρχει ζήτημα συντακτικού. Απλά, την περίοδο που έκανες την ερώτηση, οι συνήθεις ύποπτοι για SQL (ο Kelman κι εγώ) ετοιμαζόμασταν για ταξίδι στην Αμερική. Οπότε η ερώτηση κάπου ξεχάστηκε.

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

ΟΚ np. Εχω δει πως απαντάτε γενικά σχετικά άμεσα κλπ και μου έκανε εντύπωση που έπεσε εδώ τέτοια νέκρα .  Γi'αυτό έκανα και το bump για να έρθει στην επικαιρότητα (και να που έγινε ).

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

kcb:

ΟΚ np. Εχω δει πως απαντάτε γενικά σχετικά άμεσα κλπ και μου έκανε εντύπωση που έπεσε εδώ τέτοια νέκρα .  Γi'αυτό έκανα και το bump για να έρθει στην επικαιρότητα (και να που έγινε ).

Προσωπικά, το post σου μου ήταν σχετικά δύσκολο να το απαντήσω γιατί με πέτυχε σε μια χρονική στιγμή που είχα ελάχιστο χρόνο να αφιερώσω. Σε συνδυασμό με το ότι (ύστερα από μια διαγώνια ανάγνωση) δεν πρόσεξα κάποιο σαφές ερώτημα και ότι αφορούσε transactional replication, θεώρησα ότι θα έπρεπε να στήσω ένα τέτοιο σενάριο για να ασχοληθώ με ένα θεωρητικό κομμάτι του transactional replication, οπότε το προσπέρασα.

Βέβαια, τώρα βλέπω ότι η απάντηση είναι πολύ απλή. Διαβάζοντας στα Books On Line στο Controlling Constraints, Identities, and Triggers with NOT FOR REPLICATION λέει ότι

Identity columns

The identity column value is not incremented when a replication agent performs an insert operation.

Άρα είναι λογική η συμπεριφορά...

---

Vir prudens non contra ventum mingit

kelman αυτό που αναφέρεις είναι ο λόγος που υπάρχει το NFR και έχω τεστάρει ότι όντως δουλεύει. Η ερώτησή μου ήταν αλλού: (αντιγράφω από το αρχικό post και προσθέτω κάτι ελπίζοντας να γίνει πιο ξεκάθαρο)

Κάνοντας δοκιμές με: ΙD+NFR είδα ότι για τα record που έβαζα με το χέρι παράγονταν ID (αναμενόμενο και σωστό όπως λες kelman), αλλά όχι μεγαλύτερα από το μεγαλύτερο που υπήρχε ήδη στη βάση. Παράγονταν έτσι που να κλείνουν τα όποια κενά μπορεί να είχαν προκύψει (και τα οποία θεωρούμε δεδομένα στην περίπτωσή μας). Αλλάζοντας το ID σε "απλό" (χωρίς NFR-πράγμα που στον subscriber απαγορεύεται), και βάζοντας record πάλι με το χέρι, μου έδινε κανονικά το επόμενο ID αφήνοντας τα κενά άθικτα.
Αυτό ρωτούσα αν είναι φυσιολογικό κι έχει κάποιο λόγο να γίνεται.

Με δεδομένο ότι θέλω τα κενά να διατηρούνται, δεν μου κάνει το NFR... Οπότε αναγκαστικά βγάζω τελείως το Identity και στην περίπτωση που χρειαστεί να δουλέψει η βάση μου σαν primary έχω έτοιμο ένα scriptάκι και ξαναβαζω ID...


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

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

Χμ – μάλλον  εγώ είμαι που δεν κατάλαβα. Λέγοντας – «βάζω εγγραφές με το χέρι» – εγώ κατάλαβα ότι αυτά έγιναν στο subscriber. Διαφορετικά δεν κατάλαβα – βάζοντας τα στο publisher δεν σου παράγει next id > από αυτό που υπάρχει? Τότε πώς δεν χτυπάi primary key violation?

Όντως έγιναν στον subscriber, καλώς κατάλαβες!
Έγιναν για να δοκιμάσω τι γίνεται αν χρειαστεί να δουλέψει κάποτε ο subscriber σαν primary db. Τότε θα έπρεπε να έχει τη συμπεριφορά που έχει τώρα η primary. Ήθελα η βάση να ενημερώνεται με replication αλλά να είναι έτοιμη χωρίς μετατροπές να παίξει και κανονικά με το χέρι. Χάρη στο replication θα συνέχιζε από εκεί που σταμάτησε η άλλη...

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

Ναι, κατάλαβα τι λες. Και αυτό που περιγράφεις είναι ακριβώς το αποτέλεσμα του NFR Identity.

Ας υποθέσουμε ότι έχουμε έναν πίνακα με τέτοιο PK που δεν έχω κάνει καμία εγγραφή χειροκίνητα και περιέχει τις εγγραφές με ID: 1,2,3,6,7,8,10,11 από replication που έχει γίνει προηγουμένως. Αν πάει να κάνει INSERT ο Replication Agent, τότε το engine θα βάλει ό,τι ID του πει ο Agent. Αν πάω και κάνω εγώ INSERT, τότε το πρώτο ID που θα χρησιμοποιηθεί θα είναι το 4. Κατόπιν 5 και μετά 9 και μετά 12. Αυτό συμβαίνει γιατί, ας πούμε "ο pointer" του identity cοlumn έχει μείνει πίσω και προσπαθεί να κάνει catch-up.

Είναι φυσιολογική η συμπεριφορά που περιγράφεις, ωστόσο δεν είναι ανάγκη να εγκαταλείψεις το NFR αν σε βολεύει. Αυτό που μπορείς να κάνεις στην περίπτωση που γυρίσει η replicated βάση ως primary, είναι να πάρεις το max identity και κατόπιν να κάνεις re-seed με το DBCC CHECKIDENT ώστε να θέσεις νέο seed και ουσιαστικά να ξεκινήσεις από εκεί που είχε μείνει το identity. Όπως καταλαβαίνεις, κάτι τέτοιο είναι εφικτό να εφαρμοσθεί σε όλους τους πίνακες της βάσης με ένα απλό script...

 

---

Vir prudens non contra ventum mingit

Κοντά είμαστε. Στις εγγραφές που έδωσες όμως, αν γυρίσω σε κανονικό ID (που βέβαια σημαίνει ότι το replication θα είχε σταματήσει), τότε στο επόμενο INSERT το πρώτο ID που χρησιμοποιείται είναι το 12... Δηλαδή στην ίδια βάση με τα ίδια υπάρχοντα record, όταν έχω NFR ο pointer προσπαθεί να κάνει catch-up αλλά αν δεν έχω NFR δεν προσπαθεί...

To NFR υπό αυτές τις συνθήκες δεν με βολεύει. Αυτό που ήθελα ήταν η βάση να είναι έτοιμη να παίξει με την ελάχιστη δυνατή παρέμβαση. Από τη στιγμή που απαιτείται ένα script για να "παίξει" η subscriber βάση σαν κύρια, μου φαίνεται προτιμότερο ένα script που να προσθέτει το απλό IDENTITY, αφού όπως είδα συμπεριφέρεται by default όπως θέλω. Όσο δουλεύει το replication εννοείται ο πίνακας δεν θα έχει καθόλου ID ώστε να έρχονται καρφωτά αυτά του replication. Τι λες γι' αυτό;

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

kcb:

Κοντά είμαστε. Στις εγγραφές που έδωσες όμως, αν γυρίσω σε κανονικό ID (που βέβαια σημαίνει ότι το replication θα είχε σταματήσει), τότε στο επόμενο INSERT το πρώτο ID που χρησιμοποιείται είναι το 12... Δηλαδή στην ίδια βάση με τα ίδια υπάρχοντα record, όταν έχω NFR ο pointer προσπαθεί να κάνει catch-up αλλά αν δεν έχω NFR δεν προσπαθεί...

Ακριβώς...

kcb:

To NFR υπό αυτές τις συνθήκες δεν με βολεύει. Αυτό που ήθελα ήταν η βάση να είναι έτοιμη να παίξει με την ελάχιστη δυνατή παρέμβαση. Από τη στιγμή που απαιτείται ένα script για να "παίξει" η subscriber βάση σαν κύρια, μου φαίνεται προτιμότερο ένα script που να προσθέτει το απλό IDENTITY, αφού όπως είδα συμπεριφέρεται by default όπως θέλω. Όσο δουλεύει το replication εννοείται ο πίνακας δεν θα έχει καθόλου ID ώστε να έρχονται καρφωτά αυτά του replication. Τι λες γι' αυτό;

Εξαρτάται ποιά είναι η ιδέα που έχεις για την "ελάχιστη δυνατή παρέμβαση". Αν εξαιρέσουμε ένα clustering σύστημα, καμία άλλη λύση δεν έχει ελάχιστη δυνατή παρέμβαση. Πάντοτε υπάρχουν διαδικασίες που θα πρέπει να τρέξεις/ενεργοποιήσεις για να κάνεις το fail-over. Από την άλλη, για να διαλέξεις Disaster Recovery στρατηγική πρέπει να λάβεις υπόψην πολλούς παράγοντες όπως για παράδειγμα πόσα data σε παίρνει να χάσεις, πόσο downtime σε παίρνει να έχεις και τι budget έχεις για να υλοποιήσεις την DR στρατηγική σου.

Στον SQL Server 2000 οι επιλογές είναι τέσσερις και κάθε μία έχει πλεονεκτήματα και μειονεκτήματα. Το clustering για παράδειγμα σου δίνει τον καλύτερο availability αλλά είναι ακριβό τόσο σε H/W, όσο και σε S/W καθώς απαιτεί SQL Server Ent. και Windows Adv. Server. Επιπρόσθετα το administration είναι πιο tricky.

Μια άλλη επιλογή είναι να χρησιμοποιήσεις stand-by server και log-shipping. Το μειονέκτημα με αυτή τη λύση είναι ότι οι εφαρμογές σου θα πρέπει να είναι με τέτοιο τρόπο γραμμένες ώστε σε περίπτωση disaster να μπορούν να συνδεθούν με τον stand-by server που θα γίνει κύριος. Ο stand-by server δεν μπορεί να χρησιμοποιηθεί εωσότου βγει από το stand-by mode.

Το transactional replication ως DR μηχανισμός σου δίνει το πλεονέκτημα ότι μπορείς να χρησιμοποιήσεις και τον server που γίνονται replicated τα δεδομένα. Οι αλλαγές περνάνε άμεσα από τον έναν server στον άλλον αλλά θα πρέπει να ξανα-σετάρεις το replication όταν αλλάζει το schema της βάσης και όταν κάνεις switch τον δευτερεύον server από subscriber σε publisher και το ανάποδο. Άσε που ισχύει το ίδιο για τις εφαρμογές όπως στο log-shipping.

Τέλος, η μέθοδος που ακολουθούμε όλοι σε πρώτη φάση είναι το backup/restore... Το μειονέκτημα είναι ότι έχεις μεγαλύτερο downtime μέχρι να κάνεις το restore αλλά παράλληλα μπορείς να υλοποιήσεις πολύ σοφιστικέ λύσεις με τεχνολογίες SAN, snapshot backups, κλπ που τελικά να καταλήξεις σε μια πολύ καλή DR στρατηγική.

Διαλέγεις και παίρνεις...

 

---

Vir prudens non contra ventum mingit

Κατ'αρχήν μαρκάρω το θέμα σαν λυμένο αφού καταλήξαμε ότι όντως έτσι συμπεριφέρεται το ID.

Τώρα για την επιλογή στρατηγικής DR, δεν έχω "λόγο" (ευτυχώς θα έλεγα) οπότε παίρνω σαν δεδομένη (μέχρι να μου πουν κάτι διαφορετικό) τη λύση του replication. Στο transactional κατέληξα εγώ από τις προδιαγραφές που μου έδωσαν και αφού διάβασα τι και πως γιατί πριν δεν είχα ιδέα. Όπως είναι προφανές δεν είμαι db admin .

Τα data πέφτουν όλη μέρα βροχή και ο προβληματισμός μου είναι ότι όντως, ακόμα και με το transactional replication, είναι αδύνατο οι 2 servers να είναι απολύτως συγχρονισμένοι όταν "μας βρει το κακό". Έτσι το έχω περίπου θέσει σαν δεδομένο ότι δεν υπάρχει λύση στα πλαίσια replication που να μας εξασφαλίζει 100% από απώλεια data. Το backup/restore ή π.χ. ένα snapshot replication το ξεχνάω με τέτοια ροή data.... Στο να το αποδεχτούν βοηθάει ότι τα δεδομένα πρωτογενώς αποθηκεύονται σε άλλα μηχανήματα με AIX και στέλνονται μετά στα Windows και την SQL Server DB. Στο AIX δεν έχω την ευθύνη αλλά απότι ξέρω παίζει clustering Mirroring και άλλα τέτοια μυστήρια. Οπότε σε 2η φάση μετά το κακό μπορούμε να ξετρυπώσουμε από κάπου τα χαμένα data αν απαιτείται.

Η μετάβαση στον DR server έχω καταλήξει κι εγώ μετά απ' όλα αυτά ότι δεν γίνεται με τίποτα τελείως αυτόματα οπότε προσπαθώ να ελαχιστοποιήσω τα scripts κλπ
Το ακόμη χειρότερο πρόβλημα είναι η αντίστροφη διαδικασία της επιστροφής στον αρχικό server όταν αποκατασταθεί η όποια βλάβη. Αυτό μόνο με backup/restore το βλέπω. Δεν έχει νόημα να στήσω αντίστροφο replication αφού ο DR server θεωρείται μόνο προσωρινή λύση μέχρι να ξανανέβει ο primary. Βέβαια θα μου πεις αν κρατήσει πολύ αυτό, για ένα διάστημα δεν έχεις λύση αν πάθει και ο DR server. Αλλά εκεί σταματάω τον προβληματισμό

Ευχαριστώ πολύ για τον χρόνο και τις απαντήσεις!

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!

kcb:

Τώρα για την επιλογή στρατηγικής DR, δεν έχω "λόγο" (ευτυχώς θα έλεγα) οπότε παίρνω σαν δεδομένη (μέχρι να μου πουν κάτι διαφορετικό) τη λύση του replication. Στο transactional κατέληξα εγώ από τις προδιαγραφές που μου έδωσαν και αφού διάβασα τι και πως γιατί πριν δεν είχα ιδέα. Όπως είναι προφανές δεν είμαι db admin .

Με μπέρδεψες... Αφού δεν έχεις λόγο, πως επέλεξες το transactional replication?

kcb:

Τα data πέφτουν όλη μέρα βροχή και ο προβληματισμός μου είναι ότι όντως, ακόμα και με το transactional replication, είναι αδύνατο οι 2 servers να είναι απολύτως συγχρονισμένοι όταν "μας βρει το κακό". Έτσι το έχω περίπου θέσει σαν δεδομένο ότι δεν υπάρχει λύση στα πλαίσια replication που να μας εξασφαλίζει 100% από απώλεια data.

Στις περισσότερες production βάσεις, τα data πέφτουν βροχή. Όλα τα σενάρια μπορούν να ανταποκριθούν σε μεγάλο φόρτο αρκεί να έχεις ένα κατάλληλα σχεδιασμένο σύστημα. Το transactional replication επιβάλει το δικό του overhead στο σύστημα. Τρέχει τον Agent, βάζει jobs, κλπ. Δεν πρέπει να θεωρείται ελαφρύ για ένα σύστημα με υψηλό workload. Εξάλλου μην σκέφτεσαι ως απώλεια μόνο το ποσοστό των δεδομένων που θα χάσεις μετά από ένα καταστροφικό περιστατικό. Μπορεί για κάθε ώρα που είναι κάτω ο server να υπάρχει μεγαλύτερη οικονομική ζημιά σε σχέση με τα χαμένα transactions.

kcb:

Το backup/restore ή π.χ. ένα snapshot replication το ξεχνάω με τέτοια ροή data....

Διευκρίνηση: Εγώ δεν είπα για snapshot replication, είπα για snapshot backup.

Από εκεί και πέρα, πιστεύω ότι θα έπρεπε να αξιολογίσεις σοβαρά και την περίπτωση του Log Shipping.

 

---

Vir prudens non contra ventum mingit

Δεν είχα "λόγο" στο ότι θα γίνει με replication. Από εκεί και πέρα τι είδους replication και πως θα δουλέψει το έψαξα εγώ και κατέληξα στο transactional και όχι π.χ. στο snapshot.

Η οικονομική ζημιά για κάθε ώρα που είναι κάτω το σύστημα είναι όντως παράγοντας αλλά θεωρώ ότι το να τρέξουν 2 script και να σηκωθεί ο subscriber είναι ικανοποιητικά γρήγορη διαδικασία. Το ότι δεν προβλέπεται να στηθεί replication αντίστροφα όπως ανέφερα απλοποιεί πολύ τα πράγματα. Αυτό το πλάνο έχει γίνει αποδεκτό και από "πιο πάνω" από μένα οπότε κοιμάμαι κάπως πιο ήσυχος... (Βέβαια δεν έχει τύχει ακόμη στην πράξη να εφαρμοστούν όλα αυτά και μπορεί να γελάσει και το παρδαλό κατσίκι)

Μην ξεχνάς όπως είπα δεν είμαι db admin, ασχολήθηκα με το replication κατόπιν εντολής "άνωθεν" κι έτσι δεν γνωρίζω τίποτα για τις εναλλακτικές που μου λες (Log Shipping κλπ). Ακόμη και για το replication παρά το διάβασμα έχω όπως είναι φυσικό κάποια σκοτεινά σημεία όπως το ότι μου φαίνεται δύσκολη η απόφαση για το αν πρέπει να το κάνω initialize με snapshot ή να το παρακάμπτω με ένα απλό backup/restore. Και οι δύο λύσεις έχουν συν και πλην και όταν καταλήξεις σε μία δεν μπορείς μετά να αλλάξεις...

---

Εις τον στρατό Καραμάνο δεν γίνονται διακρίσεις! Και επιστήμων να είσαι, σκατά θα καθαρίσεις!