Berreskuratu SQL Server-etik Oracle-rako karga VPN-a erori ondoren

Datu-baseen arteko transferentzia bat hiltzen da VPN-a erortzen denean, eta «exekutatu berriro» ez da berreskuratze-plan bat. Iturburuaren erauzketa osatuta egon daiteke, helburuak jada commit egin dezake, edo erantzuna itzultzeko bidean galdu besterik ez da egin. Hiru egoera horiek ekintza desberdinak behar dituzte, eta «errorea» baino ez dakien bezeroak ezin ditu bereizi.

Konponbidea arkitektonikoa da: eman exekuzio bakoitzari batch-identitate iraunkorra, eta utzi datu-baseei galderak erantzuten bezeroak asmatzen utzi beharrean.

Zer bermatzen duen datu-baseak benetan

SQL Server-ek eta Oracle-k biak ematen dute atomikotasuna transakzio baten barruan. Batek ere ez dizu atomikotasunik ematen bien artean. Galdutako konexio batek ez du datu-basea hondatzen eta ez du eskuzko rollbackik behartzen, zerbitzariak bere transakzioa zuk gabe ebazten baitu. Apurtzen dena deitzaileak emaitzari buruz duen ezagutza da.

Bereizita commit egiteak bereizita commit egitea esan nahi du. Bi konexioak daramatzan VPN batek ez ditu bi commit lan-unitate bakarrean fusionatzen.

Inoiz entzun ez zenuen commit-a

Porrot-modu batek logika naiboa zigortzen du: zerbitzariak commit egiten du, eta aitorpena ez da inoiz deitzailera iristen. Oracle-k emaitza ezezagunaren arazoa bezala dokumentatzen du eta Transaction Guard eskaintzen du horretarako transakzioen dokumentazioan. Komunikazio-errore bat ez da froga commit bat bidalitakoan huts egin duenik, eta frogatzat hartzea da batch bat bi aldiz argitaratzeko modua. Bereizketa garrantzitsuena berriz saiatzeko bidean da, non operadoreak errore-mezu bat duen eta jarduteko beste seinale bat ere ez.

Beraz, berreskuratze-urratsak emaitza helburutik irakurri behar du, errore-testutik ondorioztatu beharrean.

Eman transferentziari batch-identitatea

Exekuzio bakoitzak batch-ID aldaezina jasotzen du, eta helburuak ID horrekin zer egin zuen erregistratzen du. Bizi-zikloak lau urrats ditu, eta berdin ikusten da hornitzailea edozein dela ere:

1. Erauzi erregistratutako eskema eta muga dituen iturburu-batch identifikatu eta aldaezina.
2. Eraman helburuaren prestaketa-eremura eta detektatu eduki osatugabea edo gatazkatsua prest dagoela aldarrikatu aurretik.
3. Aplikatu helburuaren berezko bakartasun- edo blokeo-arauen arabera eta erregistratu amaiera transakzio lokal berean.
4. Adiskidetu emaitza iraunkorra onartutako protokoloaren bidez, berretsi edo berriro saiatu aurretik.

Berriz saiatzeek ID bera erabiltzen dute. Saiakera bakoitzeko ID berri batek eraiki berri duzun bikoizketen prebentzioa hondatzen du, eta hori nabarmena dirudi berriz saiatzeko bilgarri batek automatikoki bat sortu arte.

ID-ak, gainera, geroago adiskidetzeko zerbait ematen dizu, bezeroaren prozesua aspaldi desagertu ondoren.

Eskatu batch-a, gero aplikatu

Aplikazio-urratsak batch-ID-a eskatu, negozio-aldaketak egin eta amaiera transakzio lokal bakar batean erregistratu behar ditu. Egiaztapena eta txertaketa adierazpen bereizi gisa egiteak kendu nahi zenuen lasterketa berriro sartzen du. Bi langilek lehiatzen badute, eskabide bat bakarrik irabazten du eta besteari jakinarazten zaio.

Amaiera-erregistrorik ez egotea ez da froga abian den transakzio bat inoiz commit egingo ez duenik. Eskabideak lehiatzen ari diren saiakerak serializatu behar ditu, edo protokoloak emaitza iraunkorra irakurri behar du ezer erabaki aurretik.

Erabili datu-basearen onartutako mekanismoa serializazio horretarako, aplikazioaren kodean egiaztatu-eta-errepikatu begizta baten ordez.

Diseinuak oraindik ere agintzen ez duena

Prestaketak lana berriro hasgarria egiten du eta saio luze bakarrarekiko mendekotasuna murrizten du. Ez du commit atomiko bakarra sortzen SQL Server, Oracle eta lanak egiten duen kanpoko alboko efektu edozein barne. Negozioak benetan behar badu, diseinatu eta egiaztatu onartutako transakzio banatu bat edo adiskidetze-prozesu bat, emaitza zalantzazkoa duen lana norena den barne. Horren baino ahulagoa dena adiskidetze-runbook batean dago, ez transferentzia-kodean.

Onartu etena hiru lekutan: transferentzian zehar, aplikazioan zehar, eta commit ondoren baina aitorpena baino lehen. Gero egiaztatu negozio-emaitza bezeroaren mezua baino, eta utzi batch-liburuak esaten lana osatugabea, commitatua edo oraindik konpondu gabea den.