Recuperar unha carga de SQL Server a Oracle tras a caída da VPN

Unha transferencia entre bases de datos morre cando cae a VPN, e «execútao outra vez» non é un plan de recuperación. A extracción da orixe pode estar completa, o destino pode ter feito xa o commit, ou a resposta pode simplemente terse perdido no camiño de volta. Eses tres estados esixen accións distintas, e un cliente que só coñece «erro» non pode distinguiros.

A solución é arquitectónica: dálle a cada execución unha identidade de lote duradeira e deixa que as bases de datos respondan preguntas en lugar de deixar que o cliente adiviñe.

O que a base de datos garante realmente

SQL Server e Oracle dan ambos atomicidade dentro dunha transacción. Ningún che dá atomicidade entre os dous. Unha conexión perdida non corrompe a base de datos nin obriga a un rollback manual, porque o servidor resolve a súa propia transacción sen ti. O que se rompe é o coñecemento do chamador sobre o resultado.

Confirmado por separado significa confirmado por separado. Unha VPN que transporta ambas as conexións non fusiona dous commits nunha soa unidade de traballo.

O commit do que nunca oíches falar

Un modo de fallo castiga a lóxica de reintento inxenua: o servidor fai commit e o acuse nunca chega ao chamador. Oracle documenta isto como o problema de resultado descoñecido e fornece Transaction Guard para iso na documentación de transaccións. Un erro de comunicación non é proba de que un commit enviado fallase, e tratalo como proba é a forma en que un lote se publica dúas veces. A distinción importa sobre todo na ruta de reintento, onde o operador ten unha mensaxe de erro e ningunha outra sinal sobre a que actuar.

Así que o paso de recuperación ten que ler o resultado no destino en lugar de inferilo do texto do erro.

Dálle unha identidade de lote á transferencia

Cada execución recibe un identificador de lote inmutable, e o destino rexistra que fixo con ese identificador. O ciclo de vida ten catro pasos e vese igual independentemente do provedor:

1. Extrae un lote de orixe identificado e inmutable cun esquema e un límite rexistrados.
2. Transfire á área de preparación do destino e detecta contido incompleto ou en conflito antes de declaralo listo.
3. Aplica baixo as regras de unicidade ou bloqueo do propio destino e rexistra a finalización na mesma transacción local.
4. Reconcilia o resultado duradeiro mediante o protocolo admitido antes de confirmar ou reintentar.

Os reintentos reutilizan o identificador. Un identificador novo por intento anula a prevención de duplicados que acabas de construír, o que soa obvio ata que un envoltorio de reintento xera un automaticamente.

O identificador tamén che dá algo contra o que reconciliar máis tarde, moito despois de que o proceso do cliente desapareza.

Reclama o lote e despois aplica

O paso de aplicación debe reclamar o identificador de lote, facer os cambios de negocio e rexistrar a finalización nunha única transacción local. Facer a comprobación e a inserción como sentenzas separadas reintroduce a carreira que intentabas eliminar. Se dous traballadores compiten, exactamente unha reclamación gaña e ao outro comunícaselle.

Un rexistro de finalización ausente non é proba de que unha transacción en curso nunca vaia confirmar. A reclamación ten que serializar os intentos competidores, ou o protocolo ten que ler o resultado duradeiro antes de decidir nada.

Utiliza o mecanismo admitido da base de datos para esa serialización en lugar dun bucle de comprobar-e-repetir no código da aplicación.

O que o deseño aínda non pode prometer

A preparación fai que o traballo se poida reiniciar e reduce a dependencia dunha única sesión de longa duración. Non crea un commit atómico único a través de SQL Server, Oracle e calquera efecto secundario externo que realice o traballo. Se o negocio realmente o necesita, deseña e cualifica unha transacción distribuída admitida ou un proceso de reconciliación, incluído quen posúe o traballo con resultado incerto. Calquera cousa máis feble pertence a un runbook de reconciliación, non ao código de transferencia.

Acepta a interrupción en tres lugares: durante a transferencia, durante a aplicación e despois do commit pero antes do acuse. Despois comproba o resultado de negocio en lugar da mensaxe do cliente, e deixa que o libro de lotes diga se o traballo está incompleto, confirmado ou aínda sen resolver.