Rikthe ngarkesën nga SQL Server në Oracle pasi bie VPN-ja

Një transferim mes bazave të dhënash vdes kur bie VPN-ja, dhe «ekzekutoje përsëri» nuk është plan rikuperimi. Nxjerrja nga burimi mund të jetë e plotë, objektivi mund të ketë bërë tashmë commit, ose përgjigja thjesht mund të jetë humbur në rrugën e kthimit. Këto tre gjendje kërkojnë veprime të ndryshme, dhe një klient që njeh vetëm «gabim» nuk mund t'i dallojë ato.

Zgjidhja është arkitekturore: jepini çdo ekzekutimi një identitet grupi të qëndrueshëm, dhe lërini bazat e të dhënave të përgjigjen pyetjeve në vend që klienti të hamendësojë.

Çfarë garanton në të vërtetë baza e të dhënave

SQL Server dhe Oracle të dyja ofrojnë atomizëm brenda një transaksioni. Asnjëra nuk ju ofron atomizëm mes të dyjave. Një lidhje e humbur nuk e dëmton bazën e të dhënave dhe as detyron një kthim manual, sepse serveri e zgjidh vetë transaksionin e tij pa ju. Ajo që prishet është njohuria e thirrësit për rezultatin.

Commit-uar veçmas do të thotë commit-uar veçmas. Një VPN që mban të dyja lidhjet nuk shkrin dy commit-e në një njësi pune.

Commit-i për të cilin nuk keni dëgjuar kurrë

Një mënyrë dështimi ndëshkon logjikën naive të ripërpjekjes: serveri bën commit, dhe konfirmimi nuk arrin kurrë te thirrësi. Oracle e dokumenton këtë si problemin e rezultatit të panjohur dhe ofron Transaction Guard për të në dokumentacionin e transaksioneve. Një gabim komunikimi nuk është provë që një commit i dërguar ka dështuar, dhe trajtimi i tij si provë është mënyra se si një grup publikohet dy herë. Dallimi ka më shumë rëndësi në rrugën e ripërpjekjes, ku operatori ka një mesazh gabimi dhe asnjë sinjal tjetër për të vepruar.

Prandaj hapi i rikuperimit duhet të lexojë rezultatin nga objektivi në vend që ta nxjerrë nga teksti i gabimit.

Jepini transferimit një identitet grupi

Çdo ekzekutim merr një ID grupi të pandryshueshme, dhe objektivi regjistron çfarë bëri me atë ID. Cikli i jetës ka katër hapa, dhe duket i njëjtë pavarësisht nga furnizuesi:

1. Nxirrni një grup burimi të identifikuar dhe të pandryshueshëm, me skemë dhe kufi të regjistruar.
2. Transferojeni në zonën e përgatitjes së objektivit dhe zbuloni përmbajtje të paplotë ose kontradiktore përpara se ta shpallni gati.
3. Aplikojeni sipas rregullave të vetë objektivit për unicitet ose bllokim dhe regjistroni përfundimin në të njëjtin transaksion lokal.
4. Rakordojeni rezultatin e qëndrueshëm përmes protokollit të mbështetur përpara se të konfirmoni ose të riprovoni.

Ripërpjekjet ripërdorin të njëjtin ID. Një ID e re për çdo provë prish parandalimin e dublikatave që sapo ndërtuat, çka duket e qartë derisa një mbështjellës ripërpjekjeje të gjenerojë një automatikisht.

ID-ja ju jep gjithashtu diçka me të cilën të rakordoni më vonë, shumë kohë pasi procesi i klientit të jetë zhdukur.

Kërkoni grupin, pastaj aplikojeni

Hapi i aplikimit duhet të kërkojë ID-në e grupit, të bëjë ndryshimet e biznesit dhe të regjistrojë përfundimin në një transaksion të vetëm lokal. Kryerja e kontrollit dhe futjes si deklarata të veçanta rikthen garën që po përpiqeshit të hiqnit. Nëse dy punëtorë garojnë, saktësisht një kërkesë fiton dhe tjetrit i thuhet.

Mungesa e një regjistrimi përfundimi nuk është provë që një transaksion në vazhdim nuk do të bëjë kurrë commit. Kërkesa duhet të serializojë provat konkurruese, ose protokolli duhet të lexojë rezultatin e qëndrueshëm përpara çdo vendimi.

Për atë serializim përdorni mekanizmin e mbështetur të bazës së të dhënave në vend të një cikli kontrollo-dhe-përsërit në kodin e aplikacionit.

Çfarë dizajni ende nuk mund të premtojë

Përgatitja e bën punën të rifillueshme dhe zvogëlon varësinë nga një sesion i vetëm jetëgjatë. Ajo nuk krijon një commit të vetëm atomik përgjatë SQL Server, Oracle dhe çdo efekti anësor të jashtëm që kryen puna. Nëse biznesi ka vërtet nevojë, dizajnoni dhe kualifikoni një transaksion të shpërndarë të mbështetur ose një proces rakordimi, duke përfshirë kush zotëron punën me rezultat të pasigurt. Çdo gjë më e dobët se kaq i përket një runbook-u rakordimi, jo kodit të transferimit.

Pranoni ndërprerjen në tre vende: gjatë transferimit, gjatë aplikimit dhe pas commit-it por përpara konfirmimit. Pastaj kontrolloni rezultatin e biznesit në vend të mesazhit të klientit, dhe lëreni librin e grupeve të thotë nëse puna është e paplotë, e commit-uar apo ende e pazgjidhur.