Recuperarea unei încărcări din SQL Server în Oracle după căderea VPN-ului

Un transfer între baze de date moare când VPN-ul cade, iar „rulează-l din nou“ nu este un plan de recuperare. Extragerea din sursă poate fi completă, ținta poate fi făcut deja commit, sau răspunsul pur și simplu s-a pierdut pe drumul de întoarcere. Aceste trei stări necesită acțiuni diferite, iar un client care cunoaște doar „eroare“ nu le poate distinge.

Soluția este arhitecturală: dați fiecărei execuții o identitate de lot durabilă și lăsați bazele de date să răspundă la întrebări în loc să lăsați clientul să ghicească.

Ce garantează de fapt baza de date

SQL Server și Oracle oferă ambele atomicitate în interiorul unei tranzacții. Niciunul nu vă oferă atomicitate între cele două. O conexiune pierdută nu corupe baza de date și nici nu impune un rollback manual, pentru că serverul își rezolvă propria tranzacție fără dvs. Ceea ce se rupe este cunoașterea apelantului despre rezultat.

Commit separat înseamnă commit separat. Un VPN care transportă ambele conexiuni nu fuzionează două commit-uri într-o singură unitate de lucru.

Commit-ul de care nu ați auzit niciodată

Un mod de eșec pedepsește logica de reîncercare naivă: serverul face commit, iar confirmarea nu ajunge niciodată la apelant. Oracle documentează acest lucru ca problema rezultatului necunoscut și oferă Transaction Guard pentru aceasta în documentația tranzacțiilor. O eroare de comunicare nu este dovada că un commit trimis a eșuat, iar tratarea ei ca dovadă este modul în care un lot este publicat de două ori. Distincția contează cel mai mult pe calea de reîncercare, unde operatorul are un mesaj de eroare și niciun alt semnal pe care să acționeze.

Prin urmare, pasul de recuperare trebuie să citească rezultatul din țintă în loc să îl deducă din textul erorii.

Dați transferului o identitate de lot

Fiecare execuție primește un ID de lot imuabil, iar ținta înregistrează ce a făcut cu acel ID. Ciclul de viață are patru pași și arată la fel indiferent de furnizor:

1. Extrageți un lot sursă identificat și imuabil, cu schemă și limită înregistrate.
2. Transferați-l în zona de pregătire a țintei și detectați conținut incomplet sau contradictoriu înainte de a-l declara pregătit.
3. Aplicați-l conform regulilor proprii de unicitate sau blocare ale țintei și înregistrați finalizarea în aceeași tranzacție locală.
4. Reconciliați rezultatul durabil prin protocolul acceptat înainte de a confirma sau reîncerca.

Reîncercările refolosesc același ID. Un ID nou pentru fiecare încercare anulează prevenirea duplicatelor pe care tocmai ați construit-o, ceea ce pare evident până când un wrapper de reîncercare generează unul automat.

ID-ul vă oferă și ceva cu care să reconciliați mai târziu, mult după ce procesul clientului a dispărut.

Revendicați lotul, apoi aplicați

Pasul de aplicare trebuie să revendice ID-ul lotului, să facă modificările de business și să înregistreze finalizarea într-o singură tranzacție locală. Efectuarea verificării și a inserării ca instrucțiuni separate reintroduce cursa pe care încercați să o eliminați. Dacă doi lucrători concurează, exact o revendicare câștigă, iar celuilalt i se spune.

O înregistrare de finalizare absentă nu este dovada că o tranzacție în curs nu va face niciodată commit. Revendicarea trebuie să serialiseze încercările concurente, sau protocolul trebuie să citească rezultatul durabil înainte de a decide ceva.

Folosiți mecanismul acceptat al bazei de date pentru această serializare în locul unei bucle verifică-și-repetă în codul aplicației.

Ce încă nu poate promite designul

Pregătirea face munca reluabilă și reduce dependența de o singură sesiune de lungă durată. Nu creează un singur commit atomic peste SQL Server, Oracle și orice efect secundar extern pe care îl execută lucrarea. Dacă afacerea are cu adevărat nevoie de asta, proiectați și calificați o tranzacție distribuită acceptată sau un proces de reconciliere, inclusiv cine deține munca cu rezultat incert. Orice este mai slab de atât aparține unui runbook de reconciliere, nu codului de transfer.

Acceptați întreruperea în trei locuri: în timpul transferului, în timpul aplicării și după commit dar înainte de confirmare. Apoi verificați rezultatul de business în locul mesajului clientului și lăsați registrul loturilor să spună dacă munca este incompletă, commitată sau încă nerezolvată.