Obnovenie načítania zo SQL Servera do Oracle po výpadku VPN

Prenos medzi databázami umiera, keď VPN vypadne, a „spusti to znova“ nie je plán obnovy. Extrakcia zo zdroja môže byť dokončená, cieľ už mohol vykonať commit alebo sa odpoveď jednoducho stratila na ceste späť. Tieto tri stavy vyžadujú rôzne kroky a klient, ktorý pozná len „chyba“, ich nedokáže rozlíšiť.

Oprava je architektonická: dajte každému spusteniu trvalú identitu dávky a nechajte databázy odpovedať na otázky namiesto toho, aby klient hádal.

Čo databáza skutočne garantuje

SQL Server aj Oracle poskytujú atomickosť vnútri transakcie. Ani jeden neposkytuje atomickosť naprieč oboma. Stratené pripojenie databázu nepoškodí a nevynúti ani ručné vrátenie, pretože server si svoju transakciu vyrieši sám bez vás. Čo sa pokazí, je znalosť volajúceho o výsledku.

Commitované oddelene znamená commitované oddelene. VPN, ktorá nesie obe pripojenia, nezlúči dva commity do jednej pracovnej jednotky.

Commit, o ktorom ste nikdy nepočuli

Jeden režim zlyhania trestá naivnú logiku opakovania: server vykoná commit a potvrdenie sa k volajúcemu nikdy nedostane. Oracle to dokumentuje ako problém neznámeho výsledku a poskytuje preň Transaction Guard v dokumentácii transakcií. Komunikačná chyba nie je dôkazom, že odoslaný commit zlyhal, a zaobchádzať s ňou ako s dôkazom je spôsob, akým sa dávka odošle dvakrát. Rozdiel je najdôležitejší na ceste opakovania, kde má operátor chybovú správu a žiadny iný signál, podľa ktorého by konal.

Krok obnovy preto musí výsledok prečítať z cieľa, nie ho odvodiť z textu chyby.

Dajte prenosu identitu dávky

Každé spustenie dostane nemenný identifikátor dávky a cieľ zaznamená, čo s týmto identifikátorom urobil. Životný cyklus má štyri kroky a vyzerá rovnako bez ohľadu na dodávateľa:

1. Extrahujte identifikovanú, nemennú zdrojovú dávku so zaznamenanou schémou a hranicou.
2. Preneste ju do prípravnej oblasti cieľa a pred vyhlásením za pripravenú odhaľte neúplný alebo konfliktný obsah.
3. Aplikujte ju podľa vlastných pravidiel jedinečnosti alebo zamykania cieľa a zaznamenajte dokončenie v tej istej lokálnej transakcii.
4. Zosúlaďte trvalý výsledok podporovaným protokolom pred potvrdením alebo opakovaním.

Opakovania používajú rovnaký identifikátor. Nový identifikátor pre každý pokus marí prevenciu duplikátov, ktorú ste práve postavili, čo znie samozrejme, kým obal opakovania nejaký nevygeneruje automaticky.

Identifikátor vám tiež dáva niečo, proti čomu možno neskôr zosúlaďovať, dlho po tom, ako proces klienta zmizol.

Nárokujte si dávku, potom aplikujte

Krok aplikácie musí nárokovať identifikátor dávky, vykonať obchodné zmeny a zaznamenať dokončenie v jednej lokálnej transakcii. Vykonanie kontroly a vloženia ako samostatných príkazov vráti pretek, ktorý ste sa snažili odstrániť. Ak dvaja pracovníci pretekajú, vyhrá presne jeden nárok a druhému sa to oznámi.

Chýbajúci záznam o dokončení nie je dôkazom, že prebiehajúca transakcia nikdy nevykoná commit. Nárok musí serializovať konkurenčné pokusy, alebo musí protokol prečítať trvalý výsledok pred akýmkoľvek rozhodnutím.

Na túto serializáciu použite podporovaný mechanizmus databázy namiesto slučky skontroluj-a-opakuj v kóde aplikácie.

Čo návrh stále nemôže sľúbiť

Príprava robí prácu znovu spustiteľnou a znižuje závislosť od jednej dlhej relácie. Nevytvára jediný atomický commit naprieč SQL Serverom, Oracle a akýmkoľvek vonkajším vedľajším efektom, ktorý práca vykonáva. Ak to obchod skutočne potrebuje, navrhnite a kvalifikujte podporovanú distribuovanú transakciu alebo proces zosúladenia, vrátane toho, kto vlastní prácu s neistým výsledkom. Čokoľvek slabšie patrí do runbooku pre zosúladenie, nie do kódu prenosu.

Prijmite prerušenie na troch miestach: počas prenosu, počas aplikácie a po commite, ale pred potvrdením. Potom skontrolujte obchodný výsledok, nie správu klienta, a nechajte knihu dávok povedať, či je práca neúplná, commitovaná alebo stále nevyriešená.