Limitaciones y Operaciones y Objetos No Soportados

GoldenGate Replicat conlleva las mismas limitaciones que existen en Google Cloud Spanner. El desarrollador de la aplicación debe ser consciente de estas limitaciones y debe diseñar su carga de aplicación en consecuencia.

A continuación se muestran las operaciones no soportadas por Oracle GoldenGate Replicat para Google Spanner, en la versión actual:

• Parallel Replicat no está soportado en la versión de vista previa.

• La replicación de DDL no está soportada con Replicat para Google Cloud Spanner.

• SQLEXEC no está soportado.

• La evolución automática del esquema no está soportada.

• La detección y resolución de conflictos no están soportadas con Replicat para Google Cloud Spanner.

• Oracle GoldenGate Replicat no soporta PKUPDATE para las tablas que han aplicado la restricción de integridad referencial (tanto para ON DELETE CASCADE como para ON DELETE NO ACTION).

• Replicat para Google Spanner no soporta SUSPEND EVENT ACTION porque la base de datos de Google Cloud Spanner aborta automáticamente cualquier transacción de lectura/escritura que esté inactiva durante más de 10 segundos y no admite ninguna configuración que permita aumentar el timeout de inactividad de 10 segundos. Si utiliza SUSPEND como acción de evento, la transacción permanecerá abierta durante más de 10 segundos y se anulará automáticamente en RESUME.

  En estos casos, puede utilizar la regla REPERROR RETRY en el error ABORTED (código de error 10) para volver a intentar la transacción cuando el replicador encuentre una transacción abortada. Esto también se aplica a las reglas REPERROR RETRY por DML en las que el reintento de DML después de más de 10 segundos provocará que Spanner aborte automáticamente la transacción en curso.

• Si Replicat for Spanner encuentra cualquier tabla que haya aplicado una clave ajena, finaliza de forma anormal con el siguiente error.

  Google Spanner does not natively support PKUpdate.
  The PKUpdate operation is implemented in GoldenGate as DELETE followed by INSERT OR IGNORE
  operation.
  
  If the table contains enforced foreign key, PKUpdate (delete followed by insert) might
  unintentionally delete the records from the child table.
  
  In this case, you can take any of the following actions to continue:
  
        1. If you do not intend to perform PKUpdate on table, use ALLOW_ENFORCED_FK in the Replicat parameter file.
  
        2. Modify the enforced foreign keys to informational foreign keys
  
        3. If the table is not required, exclude the target table from Replicat mapping to continue.

• A continuación se detallan las limitaciones del soporte latido:

  • Google Spanner solo soporta Oracle GoldenGate Replicat, no Extract, por lo que el parámetro TARGETONLY / NOTARGETONLY no está soportado explícitamente en Google Spanner, como en las bases de datos TimesTen y Teradata.

  • Oracle GoldenGate solo soporta la entrega en Google Spanner, por lo que no se necesita ningún mecanismo para rellenar o actualizar las tablas de latidos mediante ningún programador de eventos o trabajos.

  • El comando ADD HEARTBEATTABLE con las opciones FREQUENCY, PURGE_FREQUENCY o RETENTION_TIME no está soportado en Google Spanner. Cuando se especifica cualquiera de estas opciones con el comando ADD HEARTBEATTABLE, se muestra un mensaje de información que indica que la opción se ignora.

  • Los trabajos de latido y las frecuencias no son compatibles con Google Spanner, por lo que el comando ALTER HEARTBEATTABLE no es compatible con Google Spanner. Si se utiliza, el comando se ignora silenciosamente.

  • El controlador no tiene programadores de eventos ni trabajos internos, por lo que no se puede realizar una depuración automática de las tablas de historial de latidos. Debe truncar explícitamente los objetos de latido correspondientes.

• Si la transacción provoca más de 80 000 mutaciones, Spanner devuelve un error y Replicat finaliza de forma anormal con ese error.

  Del mismo modo, el tamaño de la transacción de Spanner es 100 MiB y si los datos escritos por la transacción superan los 100 MiB (incluidos los índices y los flujos de cambio), esa transacción falla y Replicat finaliza de forma anormal con error.

  Para manejar los límites de transacción de mutación 80000/100 MB de Spanner, debe utilizar el parámetro Replicat MAXTRANSOPS para dividir las transacciones de origen grandes en lotes de destino más pequeños, antes de alcanzar los límites de confirmación de Spanner.

• Spanner exige que una transacción de lectura y escritura vea una única versión de esquema consistente de principio a fin. Cuando se confirma una sentencia DDL (cualquier tabla/índice de la base de datos), la versión del esquema de la base de datos avanza. Las transacciones que se iniciaron en la versión anterior se anulan con un error que indica un cambio de esquema. El aborto es por diseño y se trata de una manera similar a los otros abortos reintentables debido a la contención o fallas transitorias. Para recuperarse de este error, espere a que finalice la operación DDL en curso y, a continuación, reinicie Replicat.