Ανάκτηση φόρτωσης από SQL Server σε Oracle μετά την πτώση του VPN

Μια μεταφορά μεταξύ βάσεων δεδομένων πεθαίνει όταν πέφτει το VPN, και το «τρέξε το ξανά» δεν είναι σχέδιο ανάκτησης. Η εξαγωγή από την πηγή μπορεί να έχει ολοκληρωθεί, ο προορισμός μπορεί να έχει ήδη κάνει commit, ή η απάντηση μπορεί απλώς να χάθηκε στον δρόμο της επιστροφής. Αυτές οι τρεις καταστάσεις απαιτούν διαφορετικές ενέργειες, και ένας πελάτης που γνωρίζει μόνο «σφάλμα» δεν μπορεί να τις ξεχωρίσει.

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

Τι εγγυάται στην πραγματικότητα η βάση δεδομένων

Το SQL Server και το Oracle παρέχουν και τα δύο ατομικότητα μέσα σε μια συναλλαγή. Κανένα δεν σας δίνει ατομικότητα και στα δύο μαζί. Μια χαμένη σύνδεση δεν καταστρέφει τη βάση δεδομένων και δεν επιβάλλει χειροκίνητη επαναφορά, επειδή ο διακομιστής επιλύει τη δική του συναλλαγή χωρίς εσάς. Αυτό που σπάει είναι η γνώση του καλούντος για το αποτέλεσμα.

Commit χωριστά σημαίνει commit χωριστά. Ένα VPN που μεταφέρει και τις δύο συνδέσεις δεν συγχωνεύει δύο commit σε μία μονάδα εργασίας.

Το commit που δεν ακούσατε ποτέ

Ένας τρόπος αποτυχίας τιμωρεί την αφελή λογική επανάληψης: ο διακομιστής κάνει commit, και η επιβεβαίωση δεν φτάνει ποτέ στον καλούντα. Η Oracle το τεκμηριώνει ως το πρόβλημα άγνωστου αποτελέσματος και παρέχει γι' αυτό το Transaction Guard στην τεκμηρίωση συναλλαγών. Ένα σφάλμα επικοινωνίας δεν είναι απόδειξη ότι ένα commit που υποβλήθηκε απέτυχε, και το να το αντιμετωπίζετε ως απόδειξη είναι ο τρόπος με τον οποίο μια παρτίδα αναρτάται δύο φορές. Η διάκριση μετράει περισσότερο στη διαδρομή επανάληψης, όπου ο χειριστής έχει ένα μήνυμα σφάλματος και κανένα άλλο σήμα για να ενεργήσει.

Επομένως το βήμα ανάκτησης πρέπει να διαβάζει το αποτέλεσμα από τον προορισμό αντί να το συμπεραίνει από το κείμενο του σφάλματος.

Δώστε στη μεταφορά ταυτότητα παρτίδας

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

1. Εξαγωγή μιας προσδιορισμένης, αμετάβλητης παρτίδας πηγής με καταγεγραμμένο σχήμα και όριο.
2. Μεταφορά της στην περιοχή προετοιμασίας του προορισμού και εντοπισμός ελλιπούς ή αντικρουόμενου περιεχομένου πριν δηλωθεί έτοιμη.
3. Εφαρμογή της σύμφωνα με τους δικούς του κανόνες μοναδικότητας ή κλειδώματος και καταγραφή της ολοκλήρωσης στην ίδια τοπική συναλλαγή.
4. Συμφιλίωση του διαρκούς αποτελέσματος μέσω του υποστηριζόμενου πρωτοκόλλου πριν από την επιβεβαίωση ή την επανάληψη.

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

Το αναγνωριστικό σας δίνει επίσης κάτι για να συμφιλιώσετε αργότερα, πολύ μετά την εξαφάνιση της διεργασίας του πελάτη.

Διεκδικήστε την παρτίδα και μετά εφαρμόστε

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

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

Χρησιμοποιήστε τον υποστηριζόμενο μηχανισμό της βάσης δεδομένων για αυτή τη σειριοποίηση αντί για βρόχο ελέγχου-και-επανάληψης στον κώδικα της εφαρμογής.

Τι δεν μπορεί ακόμη να υποσχεθεί ο σχεδιασμός

Η προετοιμασία κάνει την εργασία επανεκκινήσιμη και μειώνει την εξάρτηση από μία μακρόβια συνεδρία. Δεν δημιουργεί ένα ενιαίο ατομικό commit σε SQL Server, Oracle και οποιαδήποτε εξωτερική παρενέργεια εκτελεί η εργασία. Αν η επιχείρηση το χρειάζεται πραγματικά, σχεδιάστε και πιστοποιήστε μια υποστηριζόμενη κατανεμημένη συναλλαγή ή μια διαδικασία συμφιλίωσης, συμπεριλαμβανομένου του ποιος κατέχει την εργασία με αβέβαιη έκβαση. Οτιδήποτε ασθενέστερο ανήκει σε ένα εγχειρίδιο συμφιλίωσης, όχι στον κώδικα μεταφοράς.

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