Manejo de Errores en BATCHSQL para Operaciones de Replicación de Google Spanner

Los siguientes errores son gestionados por GoldenGate Replicat cuando se utiliza BATCHSQL con Google Spanner:

INSERT: error de clave duplicada
UPDATE/DELETE: Error de fila no encontrada
Actualización de clave primaria: error de clave no encontrada y error de nueva clave ya existe

Si alguna operación DML falla con cualquiera de estos errores, la transacción se aborta por defecto y Replicat finaliza de forma anormal. Si el usuario ha activado HANDLECOLLISIONS, OVERRIDEDUPS, INSERT_MISSING_UPDATES o cualquier otra regla REPERROR, reintentará, omitirá o modificará y, a continuación, ejecutará el DML para resolver el error.

Si alguna operación DML falla con cualquier otro error, la transacción se anula y Replicat finaliza de forma anormal. Como alternativa, en función de las reglas REPERROR, Replicat aborta y reintenta toda la transacción.

Un error RESOURCE_EXHAUSTED en Cloud Spanner suele indicar que el límite de transacción se ha superado para el número de mutaciones o el tamaño total de la transacción. Se produce un error similar al siguiente, que sugiere reducir MAXTRANSOPS o BATCHTRANSOPS.

Error: Operation failed on Spanner database due to quota, session limit, or batch size limit error:

Poosible causes :
BATCH LIMIT: Transaction >80,000 mutations or >100 MiB
QUOTA LIMIT: Spanner API quota exhausted (rate-limited)
SESSION LIMIT: Max concurrent sessions (100,000+) exceeded

Action:
For BATCH LIMIT: Reduce batch size or reduce MAXTRANSOPS and restart Replicat.
For QUOTA LIMIT: Increase Spanner quota in Google Cloud Console and restart Replicat.
For SESSION LIMIT: Reduce concurrent sessions to the Spanner and restart Replicat.
Retry using REPERROR with TRANSABORT, MAXRETRIES 5, DELAYSECS 1 is suggested.

Uso de la API Spanner Mutations

El parámetro BATCHSQL USEMUTATIONS es necesario para aumentar la eficiencia al aplicar DML en Spanner, denominadas mutaciones de Spanner.

Esto significa que ExecuteBatchDml es más atractivo para los datos iniciales de carga inicial en los que las operaciones son inserciones predominantemente contiguas para la misma tabla.

Para cargas de trabajo genéricas con DML mixtas en tiempo real, el modo USEMUTATION de BATCHSQL proporciona mejores métricas de rendimiento.

Limitaciones Operativas al Utilizar la Opción USEMUTATIONS de BATCHSQL

Existen las siguientes limitaciones al utilizar mutaciones de llaves:

Estadísticas de colisión: las estadísticas de colisión están incompletas porque los resultados de la mutación de tiempo de confirmación no identifican cuántas inserciones se han convertido efectivamente en actualizaciones, cuántas actualizaciones de filas faltantes se han convertido efectivamente en inserciones o cuántas actualizaciones/operaciones de supresión se han omitido.
Acciones REPERROR de nivel DML: las acciones REPERROR no se pueden aplicar a sentencias DML individuales en modo BATCHSQL mientras se utilizan las mutaciones de Spanner porque Spanner no devuelve resultados de nivel de sentencia para las mutaciones en buffer y se obtiene un error para toda la transacción en el momento de la confirmación.
Operaciones de supresión de filas faltantes: las operaciones de supresión en las filas faltantes se omiten por semántica DeleteMutation de Spanner, por lo que, a diferencia de otras bases de datos, BATCHSQL con USEMUTATIONS siempre devolverá el éxito en caso de que falten operaciones de supresión de filas.
Devolver al modo normal para actualizaciones de clave primaria: Replicat vuelve al modo normal; para cualquier transacción que contenga una actualización de clave primaria, se volverá a intentar en el modo clásico en cuanto encuentre una actualización de clave primaria.

Aunque el comportamiento de la mutación del espaciador no cambia debido a estas limitaciones, puede provocar una degradación del rendimiento.

Comportamiento del Modo BATCHSQL con USEMUTATIONS

A continuación se muestra un resumen de cómo cada modo BATCHSQL GoldenGate se asigna a los tipos de mutación Spanner:

Mayúsculas/Minúsculas por Defecto:

1,1 Inserciones: la transacción debe fallar en caso de inserciones de clave duplicada y el error solo se devuelve en el momento de la confirmación.

1,2 Actualizaciones: la transacción debe fallar en caso de que falten actualizaciones de fila y el error solo se devuelve en el momento de la confirmación.

1,3 Supresiones: omite la supresión si la fila es NOT_FOUND
HANDLECOLLISIONS/OVERRIDEDUPS:

2,1 Inserciones: la inserción se debe convertir en una actualización en caso de un error de clave duplicada y el error se devuelve solo en el momento de la confirmación y no tendríamos ninguna estadística de colisión de clave primaria.

2,2 Actualizaciones: las actualizaciones se deben omitir en caso de que falten errores de fila.
```
 **NOTE:** Spanner locks the row for that specific primary key using Replicat transaction even if it does not exist, which means that Spanner would not allow any other transaction to INSERT that row until Replicat transaction is committed or aborted.  
 {: .infoboxnote}
```
2,3 Supresiones: DELETEMUTATION omite la supresión si la fila es NOT_FOUND.
Insertar Actualizaciones que Faltan:

3,1 Inserciones: la transacción debe fallar en caso de inserciones de clave duplicada y el error solo se devuelve en el momento de la confirmación.

3,2 Actualizaciones: la actualización debe insertar la fila en caso de que falte un error de fila y el error solo se devuelve en el momento de la confirmación.