Gjenopprett ei lasting frå SQL Server til Oracle etter at VPN-en fell

Ei overføring mellom databasar døyr når VPN-en fell, og «køyr det igjen» er ikkje ein gjenopprettingsplan. Uttrekket frå kjelda kan vere fullført, målet kan allereie ha committa, eller svaret kan rett og slett ha gått tapt på vegen tilbake. Desse tre tilstandane krev ulike handlingar, og ein klient som berre kjenner «feil» kan ikkje skilje dei.

Løysinga er arkitektonisk: gje kvar køyring ein varig batch-identitet, og lat databasane svare på spørsmål i staden for å la klienten gjette.

Kva databasen faktisk garanterer

SQL Server og Oracle gir begge atomisitet inne i ein transaksjon. Ingen av dei gir deg atomisitet på tvers av dei to. Ei tapt tilkopling øydelegg ikkje databasen og tvingar heller ikkje fram ein manuell rollback, fordi tenaren løyser sin eigen transaksjon utan deg. Det som bryt saman, er kunnskapen til kallaren om resultatet.

Committa separat betyr committa separat. Ein VPN som ber begge tilkoplingane smeltar ikkje to commit saman til éi arbeidseining.

Committen du aldri høyrde om

Éin feilmodus straffar naiv gjenforsøkslogikk: tenaren committar, og stadfestinga når aldri fram til kallaren. Oracle dokumenterer dette som problemet med ukjent resultat og tilbyr Transaction Guard for det i transaksjonsdokumentasjonen. Ein kommunikasjonsfeil er ikkje prov på at ein send commit mislukkast, og å handsame han som prov er måten ein batch blir publisert to gonger på. Skilnaden tel mest på gjenforsøksvegen, der operatøren har ei feilmelding og ingen annan signal å handle på.

Så gjenopprettingstrinnet må lese resultatet frå målet i staden for å lese det ut av feilteksten.

Gje overføringa ein batch-identitet

Kvar køyring får ein uforanderleg batch-ID, og målet registrerer kva det gjorde med den ID-en. Livssyklusen er fire trinn, og han ser lik ut uansett leverandør:

1. Trekk ut ein identifisert, uforanderleg kjeldebatch med registrert skjema og grense.
2. Overfør han til stagingområdet til målet, og avdekk ufullstendig eller motstridande innhald før han blir erklært klar.
3. Bruk han under målet sine eigne reglar for eintydigheit eller låsing, og registrer fullføringa i same lokale transaksjon.
4. Stem av det varige resultatet via den støtta protokollen før du stadfestar eller prøver på nytt.

Gjenforsøk brukar same ID. Ein ny ID per forsøk undergrev duplikatførebygginga du nettopp bygde, noko som høyrest opplagt ut heilt til ein gjenforsøksinnpakning genererer ein automatisk.

ID-en gir deg også noko å stemme av mot seinare, lenge etter at klientprosessen er borte.

Krev batchen, og bruk han deretter

Brukssteget må krevje batch-ID-en, gjere forretningsendringane og registrere fullføringa i éin lokal transaksjon. Å gjere kontrollen og innsettinga som separate setningar gjeninnfører kappløpet du prøvde å fjerne. Viss to arbeidarar kappast, vinn nøyaktig éin krevnad, og den andre får beskjed om det.

Ei manglande fullføringsregistrering er ikkje prov på at ein pågåande transaksjon aldri vil committe. Krevnaden må serialisere konkurrerande forsøk, eller protokollen må lese det varige resultatet før noko blir avgjort.

Bruk den støtta mekanismen til databasen for den serialiseringa i staden for ei sjekk-og-gjenta-løkke i applikasjonskoden.

Kva designet framleis ikkje kan love

Staging gjer arbeidet omstartbart og reduserer avhengnaden av éin langliva økt. Det skaper ikkje éin einaste atomisk commit på tvers av SQL Server, Oracle og kva som helst ekstern sideeffekt jobben utfører. Viss forretninga verkeleg treng det, må du designe og kvalifisere ein støtta distribuert transaksjon eller ein avstemmingsprosess, inkludert kven som eig arbeid med usikkert utfall. Alt svakare enn det høyrer heime i ein avstemmings-runbook, ikkje i overføringskoden.

Godta avbrot tre stader: under overføring, under bruk og etter commit men før stadfesting. Kontroller deretter forretningsresultatet i staden for meldinga til klienten, og lat batchjournalen seie om arbeidet er ufullstendig, committa eller framleis uavklart.