Endurheimta hleðslu frá SQL Server til Oracle eftir að VPN dettur

Flutningur milli gagnagrunna deyr þegar VPN dettur, og „keyrðu það aftur“ er ekki endurheimtaráætlun. Útdrátturinn úr upprunanum getur verið búinn, markið getur þegar framkvæmt commit, eða svarið kann einfaldlega að hafa glatast á leiðinni til baka. Þessi þrjú ástand krefjast mismunandi aðgerða, og biðlari sem þekkir aðeins „villu“ getur ekki greint þau.

Lausnin er byggingarleg: gefðu hverri keyrslu varanlega lotuauðkennu, og láttu gagnagrunnana svara spurningum í stað þess að láta biðlarann giska.

Hvað gagnagrunnurinn ábyrgist í raun

SQL Server og Oracle veita bæði atómleika innan færslu. Hvorugt gefur þér atómleika yfir bæði. Týnd tenging skemmir ekki gagnagrunninn og þvingar ekki handvirka afturköllun heldur, því þjónninn leysir sína eigin færslu án þín. Það sem brotnar er þekking kallandans á niðurstöðunni.

Commit sérstaklega þýðir commit sérstaklega. VPN sem ber báðar tengingarnar sameinar ekki tvö commit í eina vinnueiningu.

Commitið sem þú heyrðir aldrei um

Ein bilanatilvik refsar barnalegri endurtilraunarrökfræði: þjónninn framkvæmir commit, og staðfestingin nær aldrei til kallandans. Oracle skjalfestir þetta sem vandamálið óþekkt niðurstaða og býður Transaction Guard fyrir það í færsluskjölunum. Samskiptavilla er ekki sönnun þess að sent commit hafi mistekist, og að meðhöndla hana sem sönnun er leiðin sem lota er send tvisvar. Greinin skiptir mestu á endurtilraunaleiðinni, þar sem stjórnandinn hefur villuboð og ekkert annað merki til að bregðast við.

Því verður endurheimtarskrefið að lesa niðurstöðuna úr markinu í stað þess að álykta hana út frá villutextanum.

Gefðu flutningnum lotuauðkennu

Hver keyrsla fær óbreytanlegt lotuauðkenni, og markið skráir hvað það gerði með það auðkenni. Lífsferillinn er fjögur skref, og hann lítur eins út óháð söluaðila:

1. Dragðu út auðkennt, óbreytanlegt upprunalotu með skráðri skemu og mörkum.
2. Fluttu það á undirbúningssvæði marksins og greindu ófullnægjandi eða misvísandi efni áður en það er lýst tilbúið.
3. Beittu því samkvæmt eigin reglum marksins um einstakt eða læsingu og skráðu lokun í sömu staðbundnu færslunni.
4. Samræmdu varanlegu niðurstöðuna í gegnum studda siðaregluna áður en staðfest er eða reynt aftur.

Endurtilraunir nota sama auðkenni. Nýtt auðkenni fyrir hverja tilraun eyðileggur tvítekningarvörnin sem þú byggðir rétt í þessu, sem hljómar augljóst þar til endurtilraunarvafningur býr til eitt sjálfkrafa.

Auðkennið gefur þér líka eitthvað til að samræma við síðar, löngu eftir að ferli biðlarans er horfið.

Krefðu lotunnar, og beittu henni svo

Beitingarskrefið verður að krefjast lotuauðkennisins, gera viðskiptabreytingarnar og skrá lokun í einni staðbundinni færslu. Að gera athugunina og innsetninguna sem aðskildar setningar endurleiðir kapphlaupið sem þú reyndir að fjarlægja. Ef tveir starfsmenn keppa vinnur nákvæmlega ein krafa og hinum er tilkynnt það.

Fjarvera lokaskráningar er ekki sönnun þess að færsla sem er í gangi muni aldrei framkvæma commit. Krafan verður að raðgreina samkeppnistilraunir, eða siðareglan verður að lesa varanlegu niðurstöðuna áður en nokkuð er ákveðið.

Notaðu studda kerfi gagnagrunnsins fyrir þá raðgreiningu í stað athuga-og-endurtaka lykkju í forritakóðanum.

Hvað hönnunin getur samt ekki lofað

Undirbúningur gerir verkið endurræsanlegt og dregur úr ósjálfstæði á einni langlífri lotu. Hann býr ekki til eitt atómt commit yfir SQL Server, Oracle og hvaða ytri aukaverkun sem verkið framkvæmir. Ef viðskiptin þurfa það sannarlega, hannaðu og flokkaðu studda dreifða færslu eða samræmingarferli, þar á meðal hver á verkið með óvissri niðurstöðu. Allt veikara en það á heima í samræmingarhandbók, ekki í flutningskóðanum.

Samþykktu truflun á þremur stöðum: meðan á flutningi stendur, meðan á beitingu stendur, og eftir commit en fyrir staðfestingu. Athugaðu svo viðskiptaniðurstöðuna í stað skilaboða biðlarans, og láttu lotubókina segja hvort verkið er ófullkomið, commit-að eða enn óupplýst.