Recupera una càrrega de SQL Server a Oracle després que caigui la VPN

Una transferència entre bases de dades mor quan cau la VPN, i «torna-ho a executar» no és un pla de recuperació. L’extracció d’origen pot estar completa, el destí pot haver fet ja el commit, o la resposta simplement s’ha pogut perdre pel camí de tornada. Aquests tres estats necessiten accions diferents, i un client que només coneix «error» no els pot distingir.

La solució és arquitectònica: dona a cada execució una identitat de lot duradora i deixa que les bases de dades responguin preguntes en lloc de deixar que el client endevini.

Què garanteix realment la base de dades

SQL Server i Oracle donen tots dos atomicitat dins d’una transacció. Cap dels dos et dona atomicitat entre tots dos. Una connexió perduda no corromp la base de dades ni obliga a un rollback manual, perquè el servidor resol la seva pròpia transacció sense tu. El que es trenca és el coneixement del cridador sobre el resultat.

Comès per separat vol dir comès per separat. Una VPN que transporta les dues connexions no fusiona dos commits en una sola unitat de treball.

El commit que mai no vas sentir

Un mode de fallada castiga la lògica de reintent ingènua: el servidor fa commit i l’acknowledgment no arriba mai al cridador. Oracle ho documenta com el problema de resultat desconegut i hi proporciona Transaction Guard a la documentació de transaccions. Un error de comunicació no és evidència que un commit enviat hagi fallat, i tractar-lo com a evidència és com un lot s’envia dues vegades. La distinció és més important al camí de reintent, on l’operador té un missatge d’error i cap altre senyal per actuar.

Per tant, el pas de recuperació ha de llegir el resultat del destí en lloc d’inferir-lo del text de l’error.

Dona una identitat de lot a la transferència

Cada execució rep un identificador de lot immutable, i el destí enregistra què ha fet amb aquest identificador. El cicle de vida té quatre passos i sembla igual independentment del proveïdor:

1. Extreu un lot d’origen identificat i immutable amb un esquema i un límit enregistrats.
2. Transfereix-lo a l’àrea de preparació del destí i detecta contingut incomplet o en conflicte abans de declarar-lo a punt.
3. Aplica-l segons les regles d’unicitat o bloqueig del destí i enregistra la finalització en la mateixa transacció local.
4. Reconcilia el resultat durador pel protocol suportat abans de confirmar o reintentar.

Els reintents reutilitzen l’identificador. Un identificador nou per intent desfà la prevenció de duplicats que acabes de construir, cosa que sona òbvia fins que un embolcall de reintent en genera un automàticament.

L’identificador també et dona alguna cosa amb què reconciliar més tard, molt després que el procés del client hagi desaparegut.

Reclama el lot i després aplica

El pas d’aplicació ha de reclamar l’identificador de lot, fer els canvis de negoci i enregistrar la finalització en una única transacció local. Fer la comprovació i la inserció com a sentències separades reintrodueix la cursa que intentaves eliminar. Si dos treballadors competeixen, exactament una reclamació guanya i a l’altre se li diu.

Un registre de finalització absent no és prova que una transacció en curs no farà mai commit. La reclamació ha de serialitzar els intents competidors, o el protocol ha de llegir el resultat durador abans de decidir res.

Utilitza el mecanisme suportat de la base de dades per a aquesta serialització en lloc d’un bucle de comprova-i-repeteix al codi de l’aplicació.

Què encara no pot prometre el disseny

La preparació fa la feina reiniciable i redueix la dependència d’una sessió llarga. No crea un únic commit atòmic entre SQL Server, Oracle i qualsevol efecte secundari extern que faci la feina. Si el negoci realment ho necessita, dissenya i qualifica una transacció distribuïda suportada o un procés de reconciliació, incloent-hi qui posseeix la feina amb resultat dubtós. Qualsevol cosa més feble pertany a un runbook de reconciliació, no al codi de transferència.

Accepta la interrupció en tres llocs: durant la transferència, durant l’aplicació i després del commit però abans de l’acknowledgment. Després comprova el resultat de negoci en lloc del missatge del client, i deixa que el llibre de lots digui si la feina està incompleta, comesa o encara no resolta.