Ibalik ang pag-load mula SQL Server patungong Oracle matapos bumagsak ang VPN

Namamatay ang paglilipat sa pagitan ng mga database kapag bumagsak ang VPN, at ang «patakbuhin muli» ay hindi plano sa pagbawi. Maaaring kumpleto na ang extraction mula sa pinagmulan, maaaring nag-commit na ang target, o maaaring nawala lang ang tugon sa daan pabalik. Ang tatlong estadong ito ay nangangailangan ng magkakaibang aksyon, at ang kliyenteng alam lamang ang «error» ay hindi kayang ipagkaiba ang mga ito.

Ang solusyon ay arkitektural: bigyan ang bawat pagtakbo ng matibay na pagkakakilanlang batch, at hayaang sagutin ng mga database ang mga tanong sa halip na hayaang manghula ang kliyente.

Ano ang talagang ginagarantiyahan ng database

Ang SQL Server at Oracle ay parehong nagbibigay ng atomicity sa loob ng transaksyon. Wala sa kanila ang nagbibigay ng atomicity sa pagitan ng dalawa. Ang nawalang koneksyon ay hindi sumisira sa database at hindi rin nagpipilit ng manual na rollback, dahil nilulutas ng server ang sarili nitong transaksyon nang wala ka. Ang nasisira ay ang kaalaman ng tumatawag tungkol sa resulta.

Ang commit nang hiwalay ay nangangahulugang commit nang hiwalay. Ang VPN na nagdadala ng dalawang koneksyon ay hindi nagsasama ng dalawang commit sa isang yunit ng trabaho.

Ang commit na hindi mo kailanman narinig

Isang paraan ng pagpalya ang nagpaparusa sa walang muwang na lohika ng pagretry: nag-commit ang server, at ang pagkilala ay hindi kailanman umabot sa tumatawag. Dokumentado ito ng Oracle bilang problema ng hindi kilalang resulta at nagbibigay ito ng Transaction Guard para dito sa dokumentasyon ng transaksyon. Ang error sa komunikasyon ay hindi ebidensya na nabigo ang ipinadalang commit, at ang ituring itong ebidensya ay ang paraan kung paano naipapaskil nang dalawang beses ang isang batch. Ang pagkakaiba ay pinakamahalaga sa landas ng pagretry, kung saan may mensahe ng error ang operator at walang ibang senyales na gagamitin.

Kaya dapat basahin ng hakbang sa pagbawi ang resulta mula sa target sa halip na hinuha ito mula sa teksto ng error.

Bigyan ang paglilipat ng pagkakakilanlang batch

Ang bawat pagtakbo ay tumatanggap ng hindi nababagong batch ID, at itinatala ng target kung ano ang ginawa nito sa ID na iyon. Ang siklo ng buhay ay may apat na hakbang, at mukhang pareho ito anuman ang vendor:

1. I-extract ang natukoy at hindi nababagong batch ng pinagmulan na may nakatalang schema at hangganan.
2. Ilipat ito sa staging area ng target at tuklasin ang hindi kumpleto o magkasalungat na nilalaman bago ito ideklarang handa.
3. Ilapat ito sa ilalim ng sariling mga tuntunin ng target sa pagiging natatangi o pag-lock at itala ang pagkumpleto sa parehong lokal na transaksyon.
4. Itugma ang matibay na resulta sa pamamagitan ng sinusuportahang protocol bago kumpirmahin o subukang muli.

Ginagamit muli ng mga pagretry ang parehong ID. Ang bagong ID bawat pagtatangka ay sumisira sa pag-iwas sa doble na binuo mo lang, na parang halata hanggang sa ang wrapper ng pagretry ay kusang gumawa ng isa.

Binibigyan ka rin ng ID ng isang bagay na maaaring itugma sa ibang pagkakataon, matagal matapos mawala ang proseso ng kliyente.

Angkinin ang batch, pagkatapos ilapat

Dapat angkinin ng hakbang ng paglalapat ang batch ID, gawin ang mga pagbabago sa negosyo, at itala ang pagkumpleto sa isang lokal na transaksyon. Ang paggawa ng pagsusuri at pagpasok bilang magkahiwalay na pahayag ay nagbabalik ng karera na sinusubukan mong alisin. Kung dalawang manggagawa ang nagkakarera, eksaktong isang pag-angkin ang nananalo at ang isa ay ipinapaalam.

Ang kawalan ng talaan ng pagkumpleto ay hindi ebidensya na ang isang transaksyong tumatakbo ay hindi kailanman mag-commit. Dapat i-serialize ng pag-angkin ang mga konkretong pagtatangka, o dapat basahin ng protocol ang matibay na resulta bago magpasya ng anuman.

Para sa serialization na iyon, gamitin ang sinusuportahang mekanismo ng database sa halip na loop na suriin-at-ulitin sa code ng aplikasyon.

Ano ang hindi pa maipapangako ng disenyo

Ginagawang maipagpapatuloy ang trabaho ng paghahanda at binabawasan ang pag-asa sa isang mahabang sesyon. Hindi ito lumilikha ng isang atomikong commit sa SQL Server, Oracle at anumang panlabas na side effect na ginagawa ng trabaho. Kung talagang kailangan ito ng negosyo, idisenyo at kuwalipikahin ang isang sinusuportahang distributed transaction o proseso ng pagkakasundo, kasama kung sino ang may-ari ng trabahong may hindi tiyak na resulta. Anumang mas mahina kaysa roon ay nabibilang sa isang runbook ng pagkakasundo, hindi sa code ng paglilipat.

Tanggapin ang pagkaantala sa tatlong lugar: habang naglilipat, habang naglalapat, at pagkatapos ng commit ngunit bago ang pagkilala. Pagkatapos suriin ang resulta ng negosyo sa halip na ang mensahe ng kliyente, at hayaang sabihin ng ledger ng batch kung ang trabaho ay hindi kumpleto, na-commit, o hindi pa nalutas.