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

Una transferencia entre bases de datos muere cuando cae la VPN, y «ejecútalo otra vez» no es un plan de recuperación. La extracción del origen puede estar completa, el destino puede haber hecho ya el commit, o la respuesta puede simplemente haberse perdido en el camino de vuelta. Esos tres estados exigen acciones distintas, y un cliente que solo conoce «error» no puede distinguirlos.

La solución es arquitectónica: dé a cada ejecución una identidad de lote duradera y deje que las bases de datos respondan preguntas en lugar de dejar que el cliente adivine.

Lo que la base de datos garantiza realmente

SQL Server y Oracle dan ambos atomicidad dentro de una transacción. Ninguno le da atomicidad entre los dos. Una conexión perdida no corrompe la base de datos ni obliga a un rollback manual, porque el servidor resuelve su propia transacción sin usted. Lo que se rompe es el conocimiento del llamador sobre el resultado.

Confirmado por separado significa confirmado por separado. Una VPN que transporta ambas conexiones no fusiona dos commits en una sola unidad de trabajo.

El commit del que nunca oyó hablar

Un modo de fallo castiga la lógica de reintento ingenua: el servidor hace commit y el acuse nunca llega al llamador. Oracle documenta esto como el problema de resultado desconocido y proporciona Transaction Guard para ello en la documentación de transacciones. Un error de comunicación no es prueba de que un commit enviado haya fallado, y tratarlo como prueba es la forma en que un lote se publica dos veces. La distinción importa sobre todo en la ruta de reintento, donde el operador tiene un mensaje de error y ninguna otra señal sobre la que actuar.

Así que el paso de recuperación tiene que leer el resultado del destino en lugar de inferirlo del texto del error.

Dele una identidad de lote a la transferencia

Cada ejecución recibe un identificador de lote inmutable, y el destino registra qué hizo con ese identificador. El ciclo de vida tiene cuatro pasos y se ve igual independientemente del proveedor:

1. Extraiga un lote de origen identificado e inmutable con un esquema y un límite registrados.
2. Transfieralo al área de preparación del destino y detecte contenido incompleto o en conflicto antes de declararlo listo.
3. Apliquelo bajo las reglas de unicidad o bloqueo del propio destino y registre la finalización en la misma transacción local.
4. Reconcilie el resultado duradero mediante el protocolo admitido antes de acusar recibo o reintentar.

Los reintentos reutilizan el identificador. Un identificador nuevo por intento anula la prevención de duplicados que acaba de construir, lo que suena obvio hasta que un envoltorio de reintento genera uno automáticamente.

El identificador también le da algo contra lo que reconciliar más tarde, mucho después de que el proceso del cliente haya desaparecido.

Reclame el lote y luego aplique

El paso de aplicación debe reclamar el identificador de lote, hacer los cambios de negocio y registrar la finalización en una única transacción local. Hacer la comprobación y la inserción como sentencias separadas reintroduce la carrera que intentaba eliminar. Si dos trabajadores compiten, exactamente una reclamación gana y al otro se le comunica.

Un registro de finalización ausente no es prueba de que una transacción en curso nunca vaya a confirmar. La reclamación tiene que serializar los intentos competidores, o el protocolo tiene que leer el resultado duradero antes de decidir nada.

Utilice el mecanismo admitido de la base de datos para esa serialización en lugar de un bucle de comprobar-y-repetir en el código de la aplicación.

Lo que el diseño todavía no puede prometer

La preparación hace que el trabajo se pueda reiniciar y reduce la dependencia de una única sesión de larga duración. No crea un commit atómico único a través de SQL Server, Oracle y cualquier efecto secundario externo que realice el trabajo. Si el negocio realmente lo necesita, diseñe y cualifique una transacción distribuida admitida o un proceso de reconciliación, incluido quién es dueño del trabajo con resultado incierto. Cualquier cosa más débil pertenece a un runbook de reconciliación, no al código de transferencia.

Acepte la interrupción en tres lugares: durante la transferencia, durante la aplicación y después del commit pero antes del acuse. Luego compruebe el resultado de negocio en lugar del mensaje del cliente, y deje que el libro de lotes diga si el trabajo está incompleto, confirmado o aún sin resolver.