Limitations and Non-Supported Objects and Operations

GoldenGate Replicat carries the same limitations that exist in Google Cloud Spanner. The application developer should be aware of these limitations and need to design their application load accordingly.

Following are the operations that are not supported by Oracle GoldenGate Replicat for Google Spanner, in the current release:

• Parallel Replicat is not supported in the preview release.

• DDL replication is not supported with Replicat for Google Cloud Spanner.

• SQLEXEC is not supported.

• Automatic Schema Evolution is not supported.

• Conflict Detection and Resolution is not supported with Replicat for Google Cloud Spanner.

• Oracle GoldenGate Replicat does not support PKUPDATE for the tables that have enforced referential integrity constraint (for both ON DELETE CASCADE and ON DELETE NO ACTION).

• Replicat for Google Spanner does not support SUSPEND EVENT ACTION because Google Cloud Spanner database auto-aborts any Read/Write transaction that is idle for more than 10 seconds and does not support any configuration that allows increasing 10 seconds idle timeout. If you use SUSPEND as an event action, then the transaction will stay open for more than 10 seconds and will auto-abort on RESUME.

  In such cases, you can use REPERROR RETRY rule on ABORTED error(error code 10), to retry the transaction when replicat encounters an aborted transaction. This also applies to per DML REPERROR RETRY rules where retrying the DML after more than 10 seconds, will cause Spanner to auto-abort the ongoing transaction.

• If the Replicat for Spanner finds any table that has enforced foreign key, then it abends with the following 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.

• Following are the details regarding the limitations of heartbeattable support:

  • Google Spanner only supports Oracle GoldenGate Replicat not Extract, so the TARGETONLY / NOTARGETONLY parameter is explicitly not supported on Google Spanner like in TimesTen and Teradata databases.

  • Oracle GoldenGate supports only delivery on Google Spanner, so no mechanism is required to populate or update the heartbeat tables using any event or job schedulers.

  • The ADD HEARTBEATTABLE command with the FREQUENCY, PURGE_FREQUENCY, or RETENTION_TIME options is not supported in Google Spanner. When any of these options are specified with the ADD HEARTBEATTABLE command, an information message is displayed indicating that the option is ignored.

  • The heartbeat jobs and frequencies are not supported in Google Spanner, so the ALTER HEARTBEATTABLE command is not supported on Google Spanner. If used, the command is silently ignored.

  • Spanner does not have any internal event or job schedulers, so automatic purging of heartbeat history tables cannot occur. You need to explicitly truncate the corresponding heartbeat objects.

• If the a transaction causes more than 80,000 mutations, Spanner returns an error and Replicat abends with that error.

  In the same way, Spanner’s transaction size is 100 MiB and if the data written by the transaction exceeds 100 MiB (including indexes and change streams), then that transaction fails and Replicat abends with error.

  To handle Spanner’s 80000 mutation/100MB transaction limits, you need to use the Replicat parameter MAXTRANSOPS to split large source transactions into smaller target batches, before hitting Spanner’s commit limits.

• Spanner enforces that a read‐write transaction sees a single, consistent schema version from start to finish. When a DDL statement (any table/index in the database) is committed, the database’s schema version advances. The transactions that started under the previous version are aborted with an error, indicating schema change. The abort is by design and is treated in a similar way as the other retryable aborts due to contention or transient faults. To recover from this error, wait for the ongoing DDL operation to complete and then restart the Replicat.