Een lading van SQL Server naar Oracle herstellen nadat de VPN wegvalt

Een overdracht tussen databases sterft wanneer de VPN wegvalt, en „voer het opnieuw uit“ is geen herstelplan. De extractie uit de bron kan voltooid zijn, het doel kan al commit hebben gedaan, of het antwoord is simpelweg onderweg terug verloren gegaan. Die drie toestanden vragen verschillende acties, en een client die alleen „fout“ kent, kan ze niet onderscheiden.

De oplossing is architectonisch: geef elke uitvoering een duurzame batch-identiteit, en laat de databases vragen beantwoorden in plaats van de client te laten gissen.

Wat de database werkelijk garandeert

SQL Server en Oracle bieden beide atomiciteit binnen een transactie. Geen van beide biedt u atomiciteit over de twee heen. Een verloren verbinding beschadigt de database niet en dwingt ook geen handmatige rollback af, omdat de server zijn eigen transactie zonder u afhandelt. Wat breekt, is de kennis van de aanroeper over de uitkomst.

Apart gecommit betekent apart gecommit. Een VPN die beide verbindingen draagt, smelt twee commits niet samen tot één werkeenheid.

De commit waarvan u nooit hoorde

Eén faalmodus straft naïeve herhaalpogingslogica: de server commit, en de bevestiging bereikt de aanroeper nooit. Oracle documenteert dit als het probleem van de onbekende uitkomst en biedt daarvoor Transaction Guard in de transactiedocumentatie. Een communicatiefout is geen bewijs dat een verzonden commit is mislukt, en die als bewijs behandelen is de manier waarop een batch twee keer wordt gepost. Het onderscheid telt het meest op het herhaalpad, waar de operator een foutmelding heeft en geen ander signaal om op te handelen.

De herstelstap moet de uitkomst dus bij het doel lezen in plaats van die uit de fouttekst af te leiden.

Geef de overdracht een batch-identiteit

Elke uitvoering krijgt een onveranderlijke batch-ID, en het doel registreert wat het met die ID heeft gedaan. De levenscyclus bestaat uit vier stappen, en ziet er hetzelfde uit ongeacht de leverancier:

1. Extraheer een geïdentificeerde, onveranderlijke bronbatch met een vastgelegd schema en een vastgelegde grens.
2. Draag die over naar het staginggebied van het doel en ontdek onvolledige of tegenstrijdige inhoud voordat die gereed wordt verklaard.
3. Pas die toe onder de eigen regels van het doel voor uniciteit of vergrendeling en registreer de voltooiing in dezelfde lokale transactie.
4. Stem de duurzame uitkomst af via het ondersteunde protocol voordat u bevestigt of opnieuw probeert.

Herhaalpogingen hergebruiken de ID. Een nieuwe ID per poging ondermijnt de duplicaatpreventie die u net hebt gebouwd, wat vanzelfsprekend klinkt tot een herhaalwrapper er automatisch een genereert.

De ID geeft u ook iets om later tegen af te stemmen, lang nadat het clientproces weg is.

Eis de batch op en pas die dan toe

De toepassingsstap moet de batch-ID opeisen, de zakelijke wijzigingen uitvoeren en de voltooiing in één lokale transactie registreren. De controle en de invoeging als afzonderlijke statements uitvoeren, herintroduceert de race die u probeerde te verwijderen. Als twee werkers racen, wint precies één opeising en de ander krijgt dat te horen.

Een ontbrekend voltooiingsrecord is geen bewijs dat een lopende transactie nooit zal committen. De opeising moet concurrerende pogingen serialiseren, of het protocol moet de duurzame uitkomst lezen voordat er iets wordt besloten.

Gebruik het ondersteunde mechanisme van de database voor die serialisatie in plaats van een controleer-en-herhaal-lus in de applicatiecode.

Wat het ontwerp nog steeds niet kan beloven

Staging maakt het werk herstartbaar en vermindert de afhankelijkheid van één langlevende sessie. Het creëert geen enkele atomische commit over SQL Server, Oracle en welk extern neveneffect de taak ook uitvoert. Als de business dat echt nodig heeft, ontwerp en kwalificeer dan een ondersteunde gedistribueerde transactie of een afstemmingsproces, inclusief wie het werk met onzekere uitkomst bezit. Alles zwakker dan dat hoort in een afstemmingsrunbook, niet in de overdrachtscode.

Accepteer onderbreking op drie plaatsen: tijdens de overdracht, tijdens de toepassing en na commit maar voor de bevestiging. Controleer daarna het bedrijfsresultaat in plaats van het bericht van de client, en laat het batchjournaal zeggen of het werk onvolledig, gecommit of nog onopgelost is.