Obnova načtení ze SQL Serveru do Oracle po výpadku VPN

Přenos mezi databázemi umírá, když VPN vypadne, a „spusť to znovu“ není plán obnovy. Extrakce ze zdroje může být dokončená, cíl už mohl provést commit nebo se odpověď prostě ztratila na cestě zpět. Tyto tři stavy vyžadují různé kroky a klient, který zná jen „chyba“, je nedokáže rozlišit.

Oprava je architektonická: dejte každému běhu trvalou identitu dávky a nechte databáze odpovídat na otázky, místo aby klient hádal.

Co databáze skutečně garantuje

SQL Server i Oracle poskytují atomicitu uvnitř transakce. Ani jeden neposkytuje atomicitu napříč oběma. Ztracené připojení databázi nepoškodí a nevynutí ani ruční rollback, protože server si svou transakci vyřeší sám bez vás. Co se rozbije, je znalost volajícího o výsledku.

Commitovat odděleně znamená commitovat odděleně. VPN, která nese obě připojení, neslévá dva commity do jedné pracovní jednotky.

Commit, o kterém jste nikdy neslyšeli

Jeden režim selhání trestá naivní logiku opakování: server provede commit a potvrzení se nikdy nedostane k volajícímu. Oracle to dokumentuje jako problém neznámého výsledku a poskytuje pro něj Transaction Guard v dokumentaci transakcí. Komunikační chyba není důkazem, že odeslaný commit selhal, a zacházet s ní jako s důkazem je způsob, jak se dávka odešle dvakrát. Rozdíl je nejdůležitější na cestě opakování, kde má operátor chybovou zprávu a žádný jiný signál, podle kterého by jednal.

Krok obnovy tedy musí výsledek přečíst z cíle, místo aby ho odvodil z textu chyby.

Dejte přenosu identitu dávky

Každý běh dostane neměnný identifikátor dávky a cíl zaznamená, co s tímto identifikátorem udělal. Životní cyklus má čtyři kroky a vypadá stejně bez ohledu na dodavatele:

1. Extrahujte identifikovanou, neměnnou zdrojovou dávku se zaznamenaným schématem a hranicí.
2. Přeneste ji do přípravné oblasti cíle a před prohlášením za připravenou odhalte neúplný nebo konfliktní obsah.
3. Aplikujte ji podle vlastních pravidel jedinečnosti nebo zamykání cíle a zaznamenejte dokončení ve stejné místní transakci.
4. Vyrovnejte trvalý výsledek podporovaným protokolem před potvrzením nebo opakováním.

Opakování používají stejný identifikátor. Nový identifikátor pro každý pokus maří prevenci duplicit, kterou jste právě postavili, což zní samozřejmě, dokud obal opakování nějaký nevygeneruje automaticky.

Identifikátor vám také dává něco, proti čemu lze později vyrovnávat, dlouho poté, co proces klienta zmizel.

Nárokujte si dávku, potom aplikujte

Krok aplikace musí nárokovat identifikátor dávky, provést obchodní změny a zaznamenat dokončení v jedné místní transakci. Když kontrolu a vložení provedete jako samostatné příkazy, vrátíte závod, který jste se snažili odstranit. Když dva pracovníci závodí, vyhraje přesně jeden nárok a druhému se to oznámí.

Chybějící záznam o dokončení není důkaz, že probíhající transakce nikdy neprovede commit. Nárok musí serializovat soupeřící pokusy, nebo musí protokol přečíst trvalý výsledek, než cokoli rozhodne.

Pro tuto serializaci použijte podporovaný mechanismus databáze, místo smyčky zkontroluj-a-opakuj v kódu aplikace.

Co návrh stále nemůže slíbit

Příprava činí práci znovu spustitelnou a snižuje závislost na jedné dlouhé relaci. Nevytváří jediný atomický commit napříč SQL Serverem, Oracle a jakýmkoli vnějším vedlejším efektem, který práce provádí. Pokud to byznys skutečně potřebuje, navrhněte a kvalifikujte podporovanou distribuovanou transakci nebo proces vyrovnání, včetně toho, kdo vlastní práci s nejistým výsledkem. Cokoli slabšího patří do runbooku pro vyrovnání, ne do kódu přenosu.

Přijměte přerušení na třech místech: během přenosu, během aplikace a po commitu, ale před potvrzením. Potom zkontrolujte obchodní výsledek, ne zprávu klienta, a nechte knihu dávek říct, zda je práce neúplná, commitovaná, nebo stále nevyřešená.