Gjenopprett en last fra SQL Server til Oracle etter at VPN-en faller

En overføring mellom databaser dør når VPN-en faller, og «kjør det igjen» er ikke en gjenopprettingsplan. Uttrekket fra kilden kan være fullført, målet kan allerede ha committet, eller svaret kan rett og slett ha gått tapt på veien tilbake. Disse tre tilstandene krever ulike handlinger, og en klient som bare kjenner «feil» kan ikke skille dem.

Løsningen er arkitektonisk: gi hver kjøring en varig batch-identitet, og la databasene svare på spørsmål i stedet for å la klienten gjette.

Hva databasen faktisk garanterer

SQL Server og Oracle gir begge atomisitet inne i en transaksjon. Ingen av dem gir deg atomisitet på tvers av de to. En tapt tilkobling ødelegger ikke databasen og tvinger heller ikke frem en manuell rollback, fordi serveren løser sin egen transaksjon uten deg. Det som bryter sammen, er kallerens kunnskap om resultatet.

Committet separat betyr committet separat. En VPN som bærer begge tilkoblingene smelter ikke to commits sammen til én arbeidsenhet.

Commiten du aldri hørte om

Én feilmodus straffer naiv gjenforsøkslogikk: serveren committer, og bekreftelsen når aldri frem til kalleren. Oracle dokumenterer dette som problemet med ukjent resultat og tilbyr Transaction Guard for det i transaksjonsdokumentasjonen. En kommunikasjonsfeil er ikke bevis for at en sendt commit mislyktes, og å behandle den som bevis er måten en batch blir publisert to ganger på. Forskjellen betyr mest på gjenforsøksveien, der operatøren har en feilmelding og ingen annen signal å handle på.

Så gjenopprettingstrinnet må lese resultatet fra målet i stedet for å utlede det fra feilteksten.

Gi overføringen en batch-identitet

Hver kjøring får en uforanderlig batch-ID, og målet registrerer hva det gjorde med den ID-en. Livssyklusen er fire trinn, og den ser lik ut uansett leverandør:

1. Trekk ut en identifisert, uforanderlig kildebatch med registrert skjema og grense.
2. Overfør den til målets stagingområde, og avdekk ufullstendig eller motstridende innhold før den erklæres klar.
3. Bruk den under målets egne regler for entydighet eller låsing, og registrer fullføringen i samme lokale transaksjon.
4. Avstem det varige resultatet via den støttede protokollen før du bekrefter eller prøver på nytt.

Gjenforsøk bruker samme ID. En ny ID per forsøk undergraver duplikatforebyggingen du nettopp bygde, noe som høres opplagt ut helt til en gjenforsøksinnpakning genererer en automatisk.

ID-en gir deg også noe å avstemme mot senere, lenge etter at klientprosessen er borte.

Krev batchen, og bruk den deretter

Anvendelsestrinnet må kreve batch-ID-en, gjøre forretningsendringene og registrere fullføringen i én lokal transaksjon. Å gjøre kontrollen og innsettingen som separate setninger gjeninnfører kappløpet du forsøkte å fjerne. Hvis to arbeidere kappes, vinner nøyaktig én krevning, og den andre får beskjed om det.

En manglende fullføringsregistrering er ikke bevis for at en pågående transaksjon aldri vil committe. Krevningen må serialisere konkurrerende forsøk, eller protokollen må lese det varige resultatet før noe avgjøres.

Bruk databasens støttede mekanisme for den serialiseringen i stedet for en sjekk-og-gjenta-løkke i applikasjonskoden.

Hva designet fortsatt ikke kan love

Staging gjør arbeidet omstartbart og reduserer avhengigheten av én langlivet økt. Det skaper ikke én enkelt atomisk commit på tvers av SQL Server, Oracle og hvilken som helst ekstern sideeffekt jobben utfører. Hvis forretningen virkelig trenger det, må du designe og kvalifisere en støttet distribuert transaksjon eller en avstemmingsprosess, inkludert hvem som eier arbeid med usikkert utfall. Alt svakere enn det hører hjemme i en avstemmings-runbook, ikke i overføringskoden.

Aksepter avbrudd tre steder: under overføring, under anvendelse og etter commit men før bekreftelse. Kontroller deretter forretningsresultatet i stedet for klientens melding, og la batchjournalen si om arbeidet er ufullstendig, committet eller fortsatt uavklart.