Odzyskiwanie ładowania z SQL Server do Oracle po zerwaniu VPN

Transfer między bazami danych ginie, gdy VPN się zrywa, a „uruchom to ponownie“ nie jest planem odzyskiwania. Ekstrakcja ze źródła może być zakończona, cel mógł już wykonać commit albo odpowiedź po prostu zginęła w drodze powrotnej. Te trzy stany wymagają różnych działań, a klient, który zna tylko „błąd“, nie potrafi ich rozróżnić.

Rozwiązanie jest architektoniczne: nadaj każdemu uruchomieniu trwałą tożsamość partii i pozwól bazom danych odpowiadać na pytania, zamiast pozwalać klientowi zgadywać.

Co baza danych naprawdę gwarantuje

SQL Server i Oracle oba dają atomowość wewnątrz transakcji. Żaden nie daje atomowości między nimi dwoma. Utracone połączenie nie psuje bazy danych i nie wymusza ręcznego wycofania, ponieważ serwer samodzielnie rozstrzyga swoją transakcję bez ciebie. Psuje się wiedza wywołującego o wyniku.

Zacommitowane osobno oznacza zacommitowane osobno. VPN przenoszący oba połączenia nie scala dwóch commitów w jedną jednostkę pracy.

Commit, o którym nigdy nie słyszałeś

Jeden tryb awarii karze naiwną logikę ponowień: serwer wykonuje commit, a potwierdzenie nigdy nie dociera do wywołującego. Oracle dokumentuje to jako problem nieznanego wyniku i udostępnia dla niego Transaction Guard w dokumentacji transakcji. Błąd komunikacji nie jest dowodem, że wysłany commit się nie powiódł, a traktowanie go jako dowodu jest sposobem, w jaki partia zostaje opublikowana dwa razy. Ta różnica ma największe znaczenie na ścieżce ponowień, gdzie operator ma komunikat błędu i żaden inny sygnał do działania.

Dlatego krok odzyskiwania musi odczytać wynik z celu, a nie wywnioskować go z tekstu błędu.

Nadaj transferowi tożsamość partii

Każde uruchomienie otrzymuje niezmienny identyfikator partii, a cel zapisuje, co zrobił z tym identyfikatorem. Cykl życia ma cztery kroki i wygląda tak samo niezależnie od dostawcy:

1. Wyodrębnij zidentyfikowaną, niezmienną partię źródłową z zapisanym schematem i granicą.
2. Przenieś ją do obszaru przygotowawczego celu i wykryj niekompletną lub sprzeczną treść, zanim zostanie uznana za gotową.
3. Zastosuj ją zgodnie z własnymi regułami unikalności lub blokowania celu i zapisz ukończenie w tej samej lokalnej transakcji.
4. Uzgodnij trwały wynik przez obsługiwany protokół przed potwierdzeniem lub ponowieniem.

Ponowienia używają tego samego identyfikatora. Nowy identyfikator dla każdej próby niweczy zapobieganie duplikatom, które właśnie zbudowałeś, co brzmi oczywiście, dopóki otoczka ponowień nie wygeneruje go automatycznie.

Identyfikator daje ci też coś, względem czego można później uzgadniać, długo po zniknięciu procesu klienta.

Zajmij partię, a następnie zastosuj

Krok zastosowania musi zająć identyfikator partii, wykonać zmiany biznesowe i zapisać ukończenie w jednej lokalnej transakcji. Wykonywanie sprawdzenia i wstawienia jako osobnych instrukcji przywraca wyścig, który próbowałeś usunąć. Jeśli dwóch pracowników konkuruje, wygrywa dokładnie jedno zajęcie, a drugi zostaje o tym poinformowany.

Brak wpisu ukończenia nie jest dowodem, że trwająca transakcja nigdy nie wykona commita. Zajęcie musi serializować konkurencyjne próby albo protokół musi odczytać trwały wynik, zanim cokolwiek zostanie postanowione.

Do tej serializacji używaj obsługiwanego mechanizmu bazy danych zamiast pętli sprawdź-i-powtórz w kodzie aplikacji.

Czego projekt wciąż nie może obiecać

Przygotowanie czyni pracę wznawialną i zmniejsza zależność od jednej długotrwałej sesji. Nie tworzy jednego atomowego commita przez SQL Server, Oracle i jakikolwiek zewnętrzny skutek uboczny, który wykonuje zadanie. Jeśli biznes naprawdę tego potrzebuje, zaprojektuj i zakwalifikuj obsługiwaną transakcję rozproszoną lub proces uzgadniania, w tym kto posiada pracę o niepewnym wyniku. Cokolwiek słabszego należy do runbooka uzgadniania, a nie do kodu transferu.

Zaakceptuj przerwanie w trzech miejscach: podczas transferu, podczas zastosowania i po commicie, ale przed potwierdzeniem. Następnie sprawdź wynik biznesowy, a nie komunikat klienta, i pozwól księdze partii powiedzieć, czy praca jest nieukończona, zacommitowana, czy wciąż nierozstrzygnięta.