Julien Delattre, auteur/autrice sur dbi Blog

applyOps and manual oplog replay for MongoDB PITR

Julien Delattre — Thu, 05 Nov 2026 07:21:00 +0000

mongorestore --oplogReplay gives you point-in-time recovery for a whole instance, replayed from the captured oplog of a single backup. It has no equivalent for a single database or a single collection. Say you need “restore just this one collection to 4:35pm” instead of the whole instance. The supported tooling has nothing to offer for in-place namespace point-in-time recovery (PITR). The only way to build it yourself is with applyOps, the server command mongorestore uses to replay oplog entries.

In fact, mongorestore refuses to combine --oplogReplay with any filter, like --db or --nsInclude:

$ mongorestore --oplogReplay --db myapp --drop dump/myapp
The --db and --collection flags are deprecated for this use-case; please use --nsInclude instead, i.e. with --nsInclude=${DATABASE}.${COLLECTION}
Failed: cannot use --oplogReplay with includes specified
0 document(s) restored successfully. 0 document(s) failed to restore.

$ mongorestore --oplogReplay --nsInclude 'myapp.*' --drop dump
Failed: cannot use --oplogReplay with includes specified
0 document(s) restored successfully. 0 document(s) failed to restore.

I was facing these issues while adding point-in-time recovery to the MongoDB DMK. I ran into several things that were not obvious from the applyOps reference page alone.

What `applyOps` does

applyOps is a database command that takes a list of raw operations, in the exact format oplog entries are stored in. It applies them directly, bypassing the normal insert/update/delete driver API:

db.adminCommand({
  applyOps: [
    { op: "i", ns: "myapp.orders", o: { _id: 1, status: "shipped" } }
  ]
})

Each entry uses the oplog field names:

op is i for insert, u for update, d for delete, c for a collection-level command.
ns is the target namespace.
o the operation data. The MongoDB documentation describes it as primarily an internal command, mainly there to support sharding. mongorestore uses it as its replay mechanism, by reading oplog entries out of a backup, and handing them to applyOps.

This is the part that makes namespace-scoped PITR possible. To achieve this in-place, you need to read the oplog, keep only the entries for the database or collection you care about, and replay just these operations.

Batch problem: not every write is a separate oplog entry

The first problem comes from something as simple as insertMany(). A batch of statements committed together doesn’t produce one oplog entry per statement. It produces a single top-level entry with op: "c", ns: "admin.$cmd", and the real operations nested inside o.applyOps:

{"op":"c","ns":"admin.$cmd","o":{"applyOps":[
    {"op":"i","ns":"myapp.orders","o":{"_id":1,"n":1}},
    {"op":"i","ns":"myapp.orders","o":{"_id":2,"n":2}},
    {"op":"i","ns":"myapp.orders","o":{"_id":3,"n":3}}
]},"ts":{"$timestamp":{"t":1787326648,"i":2}}}

A namespace filter that only looks at the top-level ns field never sees myapp.orders here at all. It sees admin.$cmd and moves on, skipping every write inside the batch. Any manual oplog replay must recursively unpack nested applyOps entries before filtering by namespace, or it will drop real writes without any error.

`applyOps` rejects entries from a freshly restored collection

Once the batch problem was fixed, replaying entries against a just-restored collection still failed:

MongoServerError: applyOps had one or more errors applying ops

The response contained no per-entry detail beyond results: [false, false]. The real cause is that every oplog entry also has a ui field. It is the internal UUID of the collection at the moment the entry was written. applyOps checks that UUID against the UUID of the live collection and rejects the operation on any mismatch.

mongorestore always assigns a new UUID to a collection it creates during a restore. The exception is when you explicitly pass both --drop and --preserveUUID together. The UUID of a restored collection never matches what the oplog entries reference, which is why every single op gets rejected, correctly but without saying why.

mongorestore oplog replay code strips the ui field before calling applyOps, unless --preserveUUID was explicitly requested:

if !restore.OutputOptions.PreserveUUID {
    op.UI = nil
}

When building a custom oplog replay instead of using mongorestore, you need the same fix. Drop ui from every entry before using it with applyOps. The operation then resolves by namespace, instead of a UUID that no longer exists.

`EJSON` relaxed mode changes your data types

Reading oplog entries back out of an archive, to filter and replay them, means going through EJSON.stringify() and EJSON.parse() in mongosh. Both default to relaxed mode, and relaxed mode collapses NumberLong into a JavaScript number:

> EJSON.stringify({txnNumber: NumberLong(1)})
'{"txnNumber":1}'

> EJSON.stringify({txnNumber: NumberLong(1)}, null, 0, {relaxed: false})
'{"txnNumber":{"$numberLong":"1"}}'

If you feed the relaxed-mode output back into applyOps, the server rejects it:

BSON field 'OplogEntryBase.txnNumber' is the wrong type 'int', expected type 'long'

In this case, nothing about the data itself was wrong, the type was just downgraded through JSON. You must pass {relaxed: false} on both EJSON.stringify() and EJSON.parse(). Do it whenever oplog entries (or any BSON document with Long, Timestamp, or Decimal128 fields) need to persist through a JSON stringify–parse round trip.

`dropDatabase` inside a replay window

The last important point is more a warning than a bug. A dropDatabase in the oplog window is replayed like any other entry, and it deletes data. I tested it in three steps.

applyOps refuses a batch that mixes dropDatabase with other operations:

> print(EJSON.stringify(db.adminCommand({applyOps: [
...     {op: "i", ns: "myapp.orders", o: {_id: 10}},
...     {op: "c", ns: "myapp.$cmd", o: {dropDatabase: 1}}
... ]})))
dropDatabase in an applyOps must be the only entry

The same dropDatabase sent alone is accepted and applied:

> print(EJSON.stringify(db.adminCommand({applyOps: [{op: "c", ns: "myapp.$cmd", o: {dropDatabase: 1}}]})))
{"applied":1,"results":[true],"ok":1,...}

mongorestore --oplogReplay does not stop on a dropDatabase. The base dump had the document _id: 1. The captured oplog then inserted _id: 2, dropped the database, re-created the collection and inserted _id: 3:

$ mongorestore --oplogReplay --drop dump
replaying oplog
applied 6 oplog entries

> db.getSiblingDB("myapp").orders.find()
[
  {
    _id: 3
  }
]

Documents created before the drop are gone, because the restore followed the history up to the end of the window. Whether to stop at a dropDatabase depends on what you restore:

A single collection restored in place: stop before any dropDatabase. Replaying the drop would also delete the other collections of the database, which are not part of the restore.
A whole database or instance: replaying dropDatabase is correct, since the drop is part of the history. The risk is a target time set after the drop, which restores an empty database.

In both cases, I would recommend to detect the dropDatabase in the replay window and report its timestamp. If your target moment is after a real dropDatabase, replay deletes the data, because the drop is part of the history. Pick a target just before the drop’s timestamp instead. Of course, this works only if your base backup is older than the drop. The oplog slices must also cover the gap, since a backup taken after the drop no longer contains the data.

Summary

Building point-in-time recovery (PITR) for a single database or collection on top of applyOps means dealing with four things. mongorestore already handles them for a full-instance restore, and you now have to handle them yourself:

Unpack nested applyOps batches before filtering by namespace, or multi-document writes are silently ignored.
Strip the ui field from every entry before replay, matching what mongorestore does by default.
Use {relaxed: false} on every EJSON.stringify()/EJSON.parse() round trip, or Long/Timestamp/Decimal128 and other fields can be changed.
Stop at a dropDatabase when restoring a single collection in place.

L’article applyOps and manual oplog replay for MongoDB PITR est apparu en premier sur dbi Blog.

GoldenGate captures TRUNCATE on a global temporary table and the replicat abends

Julien Delattre — Mon, 02 Nov 2026 07:38:00 +0000

In an extract report, I noticed that the CREATE and DROP of a global temporary table were excluded (OGG-10473), while the TRUNCATE of the same table was included (OGG-00487). If the extract writes the TRUNCATE to the trail but not the CREATE, the replicat will try to apply it on a target where the table does not exist. The replicat abends with ORA-00942. Oracle support confirmed that this is the designed behavior for temporary tables, so the TRUNCATE has to be excluded or its error discarded in the replicat parameters. This post shows the failure, the affected DDL statements and ways to keep the replicat running.

Why global temporary table DDL is excluded

The data of a global temporary table is private to each session and is not replicated. The extract therefore skips the DDL that creates and drops it, and the table does not exist on the target. However, TRUNCATE operations are captured by GoldenGate.

Setup

GoldenGate 23.26.4.0.0 Microservices Architecture, deployment ogg_test_01.
Source: CDB01/PDB1, Oracle 19c. Target: CDB02/PDB2, Oracle 19c.
A GTTTEST schema exists in both PDBs.
Integrated extract EGTT connects to PDB1 directly (PDB-level capture), with DDL INCLUDE ALL.
Integrated replicat RGTT applies to PDB2, with DDL INCLUDE ALL.

The parameter file of the extract:

EXTRACT EGTT
EXTTRAIL gt
USERIDALIAS source_pdb1 DOMAIN OracleGoldenGate
DDL INCLUDE ALL
DDLOPTIONS REPORT
TABLE GTTTEST.*;

The parameter file of the replicat:

REPLICAT RGTT
USERIDALIAS oggadmin_pdb2 DOMAIN OracleGoldenGate
DDL INCLUDE ALL
DDLOPTIONS REPORT
MAP GTTTEST.*, TARGET GTTTEST.*;

The extract is registered with REGISTER EXTRACT EGTT DATABASE, and the replicat uses the checkpoint table OGGADMIN.CHECKPOINT.

Workload on the source

The three statements run as GTTTEST on PDB1:

SQL> CREATE GLOBAL TEMPORARY TABLE temp_test (c number) ON COMMIT PRESERVE ROWS;

Table created.

SQL> TRUNCATE TABLE temp_test;

Table truncated.

SQL> DROP TABLE temp_test PURGE;

Table dropped.

What the extract does

The extract report shows the three DDL statements:

CREATE and DROP are excluded.
TRUNCATE is included.

2026-10-24 07:26:05  INFO    OGG-01487  DDL found, operation [CREATE GLOBAL TEMPORARY TABLE temp_test (c number) ON COMMIT PRESERVE ROWS (size 74)], ... ].
2026-10-24 07:26:05  INFO    OGG-10473  DDL on global temporary table excluded, optype [CREATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
2026-10-24 07:26:05  INFO    OGG-01487  DDL found, operation [TRUNCATE TABLE temp_test (size 24)], ... ].
2026-10-24 07:26:05  INFO    OGG-00487  DDL operation included [INCLUDE ALL], optype [TRUNCATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
2026-10-24 07:26:05  INFO    OGG-01487  DDL found, operation [DROP TABLE temp_test PURGE (size 26)], ... ].
2026-10-24 07:26:05  INFO    OGG-10473  DDL on global temporary table excluded, optype [DROP], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".

Only the TRUNCATE reaches the trail.

What the replicat does

The replicat maps the TRUNCATE to GTTTEST.TEMP_TEST and executes it on PDB2. The table does not exist there, and the replicat abends:

2026-10-24 07:26:08  INFO    OGG-00482  DDL found, operation [TRUNCATE TABLE temp_test (size 24)].
2026-10-24 07:26:08  INFO    OGG-00489  DDL is of mapped scope, after mapping new operation [TRUNCATE TABLE "GTTTEST"."TEMP_TEST" (size 36)].
2026-10-24 07:26:08  INFO    OGG-00487  DDL operation included [INCLUDE ALL], optype [TRUNCATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
2026-10-24 07:26:08  INFO    OGG-00484  Executing DDL operation.
2026-10-24 07:26:08  ERROR   OGG-00519  Fatal error executing DDL replication: error [Error code [942], ORA-00942: table or view does not exist
2026-10-24 07:26:08  ERROR   OGG-30538  Fatal error executing DDL statement [TRUNCATE TABLE "GTTTEST"."TEMP_TEST"].
2026-10-24 07:26:08  ERROR   OGG-00664  Error 942 on OCI call [ORA] - ORA-00942: table or view does not exist
2026-10-24 07:26:13  ERROR   OGG-01668  PROCESS ABENDING.

The status in the adminclient:

OGG (http://localhost:7810 ogg_test_01) 2> INFO ALL

Program     Status      Group       Type                   Lag at Chkpt       Time Since Chkpt
EXTRACT     RUNNING     EGTT        INTEGRATED                  00:00:03           00:00:04
REPLICAT    ABENDED     RGTT        INTEGRATED                  00:00:04           00:00:13

`DDLOPTIONS` for global temporary tables

The DDLOPTIONS documentation describes two options for global temporary tables. By default, GTT DDL is not visible to the extract, which does not match the TRUNCATE captured above.

CAPTUREGLOBALTEMPTABLE (extract): makes GTT DDL visible to the extract. It is filtered like any other DDL and, if it passes, written to the trail.
NOAPPLYGLOBALTEMPTABLE (replicat): prevents the replicat from applying GTT DDL. Without it, the replicat applies all GTT DDL from the trail.

Every case uses the same workload. It has the three GTT statements, then a regular table with one row going through CREATE, TRUNCATE and DROP. Each case starts from a new extract, replicat and trail.

`NOAPPLYGLOBALTEMPTABLE` on the replicat

The parameter file of the replicat:

REPLICAT RGTT
USERIDALIAS oggadmin_pdb2 DOMAIN OracleGoldenGate
DDL INCLUDE ALL
DDLOPTIONS REPORT, NOAPPLYGLOBALTEMPTABLE
MAP GTTTEST.*, TARGET GTTTEST.*;

The replicat still abends on the TRUNCATE, with the same errors as without the option:

INFO    OGG-00482  DDL found, operation [TRUNCATE TABLE temp_test (size 24)].
ERROR   OGG-00519  Fatal error executing DDL replication: error [Error code [942], ORA-00942: table or view does not exist
ERROR   OGG-01668  PROCESS ABENDING.

If the GTT already exists on the target, the replicat does not abend, because the TRUNCATE is applied to that table.

`CAPTUREGLOBALTEMPTABLE` on the extract

With DDLOPTIONS REPORT, CAPTUREGLOBALTEMPTABLE in the extract, the CREATE and DROP are no longer excluded:

OGG-00487  DDL operation included [INCLUDE ALL], optype [CREATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
OGG-00487  DDL operation included [INCLUDE ALL], optype [TRUNCATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
OGG-00487  DDL operation included [INCLUDE ALL], optype [DROP], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".

The replicat creates the table on the target, truncates it and drops it. It keeps running:

INFO    OGG-00482  DDL found, operation [CREATE GLOBAL TEMPORARY TABLE temp_test (c number) ON COMMIT PRESERVE ROWS (size 74)].
INFO    OGG-00489  DDL is of mapped scope, after mapping new operation [CREATE GLOBAL TEMPORARY TABLE "GTTTEST"."TEMP_TEST" (c number) ON COMMIT PRESERVE ROWS (size 86)].
INFO    OGG-00482  DDL found, operation [TRUNCATE TABLE temp_test (size 24)].
INFO    OGG-00482  DDL found, operation [DROP TABLE temp_test PURGE (size 26)].

Both options together

With CAPTUREGLOBALTEMPTABLE on the extract and NOAPPLYGLOBALTEMPTABLE on the replicat, the replicat excludes the CREATE and still executes the TRUNCATE:

INFO    OGG-00482  DDL found, operation [CREATE GLOBAL TEMPORARY TABLE temp_test (c number) ON COMMIT PRESERVE ROWS (size 74)].
INFO    OGG-10473  DDL on global temporary table excluded, optype [CREATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-00482  DDL found, operation [TRUNCATE TABLE temp_test (size 24)].
ERROR   OGG-00519  Fatal error executing DDL replication: error [Error code [942], ORA-00942: table or view does not exist
ERROR   OGG-01668  PROCESS ABENDING.

The replicat abends on the TRUNCATE before it reaches the DROP. To check the DROP, the same two options run with a workload that has no TRUNCATE on the global temporary table. The replicat excludes both the CREATE and the DROP and keeps running:

INFO    OGG-00482  DDL found, operation [CREATE GLOBAL TEMPORARY TABLE temp_test (c number) ON COMMIT PRESERVE ROWS (size 74)].
INFO    OGG-10473  DDL on global temporary table excluded, optype [CREATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-00482  DDL found, operation [DROP TABLE temp_test PURGE (size 26)].
INFO    OGG-10473  DDL on global temporary table excluded, optype [DROP], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".

So NOAPPLYGLOBALTEMPTABLE skips the CREATE and DROP of a global temporary table, but not its TRUNCATE.

Which DDL statements are affected

The TRUNCATE is not the only statement that behaves differently from CREATE and DROP. This workload runs on the source with the default extract (no CAPTUREGLOBALTEMPTABLE):

CREATE GLOBAL TEMPORARY TABLE temp_test (c number) ON COMMIT PRESERVE ROWS;
ALTER TABLE temp_test ADD (d number);
COMMENT ON TABLE temp_test IS 'gtt';
CREATE INDEX temp_test_i ON temp_test(c);
TRUNCATE TABLE temp_test;
ALTER TABLE temp_test RENAME TO temp_test2;
DROP TABLE temp_test2 PURGE;

The extract excludes five of the seven statements and includes COMMENT and TRUNCATE:

INFO    OGG-10473  DDL on global temporary table excluded, optype [CREATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-10473  DDL on global temporary table excluded, optype [ALTER], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-00487  DDL operation included [INCLUDE ALL], optype [COMMENT], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-10473  DDL on global temporary table excluded, optype [CREATE], objtype [INDEX], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-00487  DDL operation included [INCLUDE ALL], optype [TRUNCATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-10473  DDL on global temporary table excluded, optype [ALTER], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST2".
INFO    OGG-10473  DDL on global temporary table excluded, optype [DROP], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST2".

With CAPTUREGLOBALTEMPTABLE on the extract and NOAPPLYGLOBALTEMPTABLE on the replicat, the extract captures every statement and the replicat makes the same decision. It excludes CREATE and ALTER (OGG-10473), then applies the COMMENT and abends:

INFO    OGG-00482  DDL found, operation [ALTER TABLE temp_test ADD (d number) (size 36)].
INFO    OGG-10473  DDL on global temporary table excluded, optype [ALTER], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-00482  DDL found, operation [COMMENT ON TABLE temp_test IS 'gtt' (size 35)].
INFO    OGG-00487  DDL operation included [INCLUDE ALL], optype [COMMENT], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
ERROR   OGG-00519  Fatal error executing DDL replication: error [Error code [942], ORA-00942: table or view does not exist
ERROR   OGG-30538  Fatal error executing DDL statement [COMMENT ON TABLE "GTTTEST"."TEMP_TEST" IS 'gtt'].
ERROR   OGG-01668  PROCESS ABENDING.

Each statement runs separately to see what the replicat does with it:

Statement on the global temporary table	Replicat
`CREATE TABLE`, `DROP TABLE`	Excluded (`OGG-10473`)
`ALTER TABLE ... ADD`, `ALTER TABLE ... RENAME TO`	Excluded (`OGG-10473`)
`CREATE INDEX`, `GRANT`	Excluded (`OGG-10473`)
`TRUNCATE TABLE`	Applied, abends with `ORA-00942`
`COMMENT ON TABLE`, `COMMENT ON COLUMN`	Applied, abends with `ORA-00942`

Scope and truncate options do not change it

A difference in DDL scope could explain why CREATE is excluded and TRUNCATE is not. However, with DDL INCLUDE MAPPED on the replicat, the TRUNCATE is still included and the replicat abends:

INFO    OGG-00482  DDL found, operation [TRUNCATE TABLE temp_test (size 24)].
INFO    OGG-00487  DDL operation included [INCLUDE MAPPED], optype [TRUNCATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
ERROR   OGG-00519  Fatal error executing DDL replication: error [Error code [942], ORA-00942: table or view does not exist
ERROR   OGG-30538  Fatal error executing DDL statement [TRUNCATE TABLE "GTTTEST"."TEMP_TEST"].
ERROR   OGG-01668  PROCESS ABENDING.

The same happens with GETTRUNCATES and with IGNORETRUNCATES in the replicat, and with a global temporary table created with ON COMMIT DELETE ROWS. Those parameters control the truncate operation of the data, not the TRUNCATE DDL statement.

Answer from Oracle Support

I opened a service request with Oracle. The Product Team answered that TRUNCATE TABLE is a DDL operation and has to be excluded with an EXCLUDE clause of the DDL parameter. DDL cannot be filtered by temporary versus permanent tables, so the exclusion is done by table name. If that is too much work, the alternative is DDLERROR 942 DISCARD. I then pointed out that CREATE and DROP are DDL operations too and are excluded. The answer was that this is how it is designed for temporary tables.

Keeping the replicat running

Exclude the `TRUNCATE` by table name

The DDL parameter of the replicat excludes the TRUNCATE of the table:

REPLICAT RGTT
USERIDALIAS oggadmin_pdb2 DOMAIN OracleGoldenGate
DDL INCLUDE ALL, EXCLUDE OBJNAME GTTTEST.TEMP_TEST OPTYPE TRUNCATE
DDLOPTIONS REPORT, NOAPPLYGLOBALTEMPTABLE
MAP GTTTEST.*, TARGET GTTTEST.*;

The replicat finds the TRUNCATE and skips it with an informational message, OGG-00488. It keeps running:

INFO    OGG-00482  DDL found, operation [CREATE GLOBAL TEMPORARY TABLE temp_test (c number) ON COMMIT PRESERVE ROWS (size 74)].
INFO    OGG-10473  DDL on global temporary table excluded, optype [CREATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-00482  DDL found, operation [TRUNCATE TABLE temp_test (size 24)].
INFO    OGG-00489  DDL is of mapped scope, after mapping new operation [TRUNCATE TABLE "GTTTEST"."TEMP_TEST" (size 36)].
INFO    OGG-00488  DDL operation excluded [EXCLUDE OBJNAME GTTTEST.TEMP_TEST OPTYPE TRUNCATE], optype [TRUNCATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-00482  DDL found, operation [DROP TABLE temp_test PURGE (size 26)].
INFO    OGG-10473  DDL on global temporary table excluded, optype [DROP], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".

The exclusion works per table name, so it has to list every global temporary table. COMMENT ON TABLE and COMMENT ON COLUMN abend the same way, so the exclusion must cover them too.

Discard the `ORA-00942` error

DDLERROR 942 DISCARD needs no table list. The replicat applies the TRUNCATE, receives ORA-00942 from the target and discards the error:

REPLICAT RGTT
USERIDALIAS oggadmin_pdb2 DOMAIN OracleGoldenGate
DISCARDFILE RGTT.dsc, APPEND
DDL INCLUDE ALL
DDLOPTIONS REPORT
DDLERROR 942 DISCARD
MAP GTTTEST.*, TARGET GTTTEST.*;

The report shows OGG-00494 instead of the abend:

INFO    OGG-00482  DDL found, operation [TRUNCATE TABLE temp_test (size 24)].
INFO    OGG-00487  DDL operation included [INCLUDE ALL], optype [TRUNCATE], objtype [TABLE], objowner "GTTTEST", objname "TEMP_TEST".
INFO    OGG-00494  DDL error discarded: error code [942], filter [include all (default)], error text [Current time: 2026-10-24 07:55:57
 Error text [Error code [942], ORA-00942: table or view does not exist

OGG (http://localhost:7810 ogg_test_01) 2> INFO ALL

Program     Status      Group       Type                   Lag at Chkpt       Time Since Chkpt
EXTRACT     RUNNING     EGTT        INTEGRATED                  00:00:03           00:00:07
REPLICAT    RUNNING     RGTT        INTEGRATED                  00:00:00           00:00:06

The discard file RGTT.dsc has the statement:

Current time: 2026-10-24 07:55:57
 Error text [Error code [942], ORA-00942: table or view does not exist
Help: https://docs.oracle.com/error-help/db/ora-00942/
], operation [TRUNCATE TABLE "GTTTEST"."TEMP_TEST" (size 36)]
Operation failed at seqno 0 rba 1,333.

The parameter applies to every DDL statement that fails with ORA-00942, not only to temporary tables. A statement that fails because a regular table is missing on the target is discarded too, so check the discard file regularly.

Summary

With DDL INCLUDE ALL, the extract excludes CREATE, ALTER, CREATE INDEX and DROP of a global temporary table (OGG-10473) but includes TRUNCATE and COMMENT (OGG-00487).
The TRUNCATE is written to the trail and applied by the replicat on a target that has no such table.
The replicat abends with ORA-00942 (OGG-00519, OGG-30538, OGG-01668).
DDL INCLUDE MAPPED, GETTRUNCATES and IGNORETRUNCATES do not change the abend.
NOAPPLYGLOBALTEMPTABLE on the replicat does not prevent it, because the TRUNCATE is still executed.
CAPTUREGLOBALTEMPTABLE on the extract makes the whole CREATE, TRUNCATE and DROP sequence replicate without error.
Oracle support confirmed that this is the designed behavior for temporary tables.

DDL EXCLUDE OBJNAME  OPTYPE TRUNCATE on the replicat skips the TRUNCATE for the listed tables.DDLERROR 942 DISCARD on the replicat keeps it running for all tables and writes the failed statement to the discard file.
L’article GoldenGate captures TRUNCATE on a global temporary table and the replicat abends est apparu en premier sur dbi Blog.

Retrieving GoldenGate logs, reports, and diagnostics with the REST API
Julien Delattre — Mon, 26 Oct 2026 07:52:00 +0000

I often need to retrieve report files or logs from GoldenGate deployments, and I wanted to find ways of automating this. Hence this blog, about retrieving all available logs with GoldenGate REST API.



I previously wrote about the GoldenGate log files. Some of them (extract.log, replicat.log and others) are in fact just filters of other logs (ggserr.log or restapi.log). These reconstructed logs do not have a REST API endpoint. For the others, let’s see how to retrieve them, using the GoldenGate Python client I released earlier.



Authenticating to the REST API



With oggrestapi.py, authentication is handled once at client creation. When using auto_discovery, you won’t have to bother thinking about the port.



from oggrestapi import OGGRestAPI

ogg_client = OGGRestAPI(
    url="https://vmogg:7809",
    username="ogg",
    deployment="ogg_test_01",
    auto_discovery=True,
)



With auto_discovery, the client picks the right service port for each call. If you make direct curl/requests calls instead, you have to choose the service yourself:




Service Manager for ServiceManager.log and the deployment service logs (adminsrvr.log, distsrvr.log, etc.)



Administration Service for report files, diagnostic files, ggserr.log. You can also retrieve adminsrvr.log from here.




The list of log files can be retrieved through GET /services/v2/logs. Each individual log is obtained through GET /services/v2/logs/{log}, on the port of the service you connect to. default is the service log: against adminsrvr (port 7810), default is adminsrvr.log. To retrieve the content of the file, you need to send the Accept: text/plain header, or use the content toggle in oggrestapi.py.



# /services/v2/logs - List all logs
>>> ogg_client.list_logs(ogg_service="adminsrvr")
[{'name': 'default'}, {'name': 'restapi'}, {'name': 'stdout'}, {'name': 'debug'}, {'name': 'events'}]

# /services/v2/logs/default - Get adminsrvr.log metadata
>>> ogg_client.get_log(log="default", ogg_service="adminsrvr")
{'$schema': 'ogg:log', 'enabled': True, 'dataExists': True}

# /services/v2/logs/default (Accept: text/plain) - Get adminsrvr.log content
>>> ogg_client.get_log(log="default", ogg_service="adminsrvr", content=True)
"...\n2026-09-26T17:21:30.612+0000 INFO | Registering containers  (Thread 7)\n2026-09-26T17:21:31.820+0000 INFO | Configuration file 'EXT.prm' changed (Thread 7)\n2026-09-26T17:21:31.881+0000 INFO | Starting extract 'EXT' (EXTRACT:EXT)\n2026-09-26T17:21:31.915+0000 INFO | Task 'EXTRACT:EXT' started with process id 39143 (EXTRACT:EXT)\n"



You can also use the get_service_log directly, when using a reverse proxy or connecting to the Service Manager:



# /services/v2/deployments/ogg_test_01/services/distsrvr/logs/default (Accept: text/plain) - Service Manager endpoint
# /services/ServiceManager/v2/deployments/ogg_test_01/services/distsrvr/logs/default (Accept: text/plain) - reverse proxy endpoint
>>> ogg_client.get_service_log(deployment="ogg_test_01", service="distsrvr", content=True)
"...\n2026-09-26T17:33:46.183+0000 INFO | remove path Command Received for path PATHX (PATHX)\n2026-09-26T17:33:46.183+0000 WARN | Path stopped. (PATHX)\n"



The debug log is only relevant when you enable debug logging on a specific service. events is the critical events log (same content as ER-events.log), reachable directly as GET /services/v2/logs/events too, wrapped as list_log_events() :



# /services/v2/logs/events (Accept: text/plain)
>>> ogg_client.list_log_events(content=True)
"...Oracle GoldenGate Capture for Oracle, EXT.prm:  Checkpoint marked as from graceful shutdown, but records found after checkpoint in trail pdb1/e1.  Expected EOF Seqno 0, RBA 0.  Found Seqno 7, RBA 8884.\n"



Service Manager logs



From the Service Manager (port 7809 in my lab), default is the ServiceManager.log:



# /services/v2/logs/default (Accept: text/plain)
>>> ogg_client.get_service_manager_log()
"...2026-09-26T15:46:20.138+0000 INFO | CSRFTokenProtection: ENABLED.\n                                    Cross-Site Request Forgery checks using CSRF-Tokens will be performed. (Thread 12)\n"



get_service_manager_log() defaults to content=True, since fetching the metadata for this one specific log is not relevant (this log is always enabled).



ggserr.log



ggserr.log, the deployment-wide message log, is not one of the names any /logs collection returns. It is provided by a separate Administration Service endpoint at /services/v2/messages. A messages key returns the log lines.



# /services/v2/messages
>>> lines = ogg_client.list_messages()["messages"]
>>> len(lines)
53035



Once you find an OGG- message code in these lines, another endpoint (GET /services/v2/oggerr/{message}) returns its explanation:



>>> ogg_client.get_ogg_error_info(message="OGG-30375", ogg_service="adminsrvr")
{'$schema': 'ogg:messageExplanation', 'severity': 'ERROR', 'title': 'There was a problem updating the Administration Service resources.', 'cause': 'An internal error occurred when trying to update the service resources. Possible causes include a corrupted or incorrect resources repository.', 'action': 'Check the error log for other messages adjacent to this one that might help you resolve the problem. If you cannot resolve the problem, contact Oracle Support.'}



adminclient.log: no REST endpoint



adminclient.log is the client’s connection log. It is located in the client installation at $OGG_HOME/var/log/adminclient.log, not in any deployment, and no service can read it.



Report files (.rpt)



The report files are accessible with list_extract_reports and get_extract_report:



# /services/v2/extracts/EXT/info/reports
>>> ogg_client.list_extract_reports(extract="EXT")
[{'name': 'EXT.dsc'}, {'name': 'EXT.rpt'}]

# /services/v2/extracts/EXT/info/reports/EXT.rpt
>>> ogg_client.get_extract_report(extract="EXT", report="EXT.rpt")
{'lines': ['', '***********************************************************************', '                 Oracle GoldenGate Capture for Oracle', ...], '$schema': 'ogg:report'}



get_current_extract_report() skips the .dsc, resolves the current .rpt for you, and returns None if the extract has no report listed :



# /services/v2/extracts/EXT/info/reports
# /services/v2/extracts/EXT/info/reports/EXT.rpt
>>> ogg_client.get_current_extract_report(extract="EXT")
{'lines': ['', '***********************************************************************', '                 Oracle GoldenGate Capture for Oracle', ...], '$schema': 'ogg:report'}



The same endpoints/methods exist for replicats.



Diagnostics



If a diagnostics collection exists, it is a resource named {process}.diagnostics, listed under the same info path as reports. It has a status while it runs, and the start and finish times once done :



# /services/v2/extracts/EXT/info/diagnostics - while running
>>> ogg_client.list_extract_diagnostics(extract="EXT")
[{'name': 'EXT.diagnostics', 'status': 'running', 'started': '2026-09-26T17:23:21Z'}]

# /services/v2/extracts/EXT/info/diagnostics - when done
>>> ogg_client.list_extract_diagnostics(extract="EXT")
[{'name': 'EXT.diagnostics', 'status': 'stopped', 'started': '2026-09-26T17:23:21Z', 'finished': '2026-09-26T17:33:22Z'}]



When several collections exist, the previous ones are kept as EXT.diagnostics.1 (and so on), and the newest keeps the base name. An extract that never had a collection returns an empty list. It returns a JSON, but unlike reports and configuration files, it is a structured document with one entry per sample:



# /services/v2/extracts/EXT/info/diagnostics/EXT.diagnostics
>>> diag = ogg_client.get_extract_diagnostic(extract="EXT", diagnostic="EXT.diagnostics")
>>> list(diag)
['$schema', 'started', 'finished', 'collectionFrequency', 'collectionDuration', 'status', 'samples']
>>> diag["samples"][0]["processSamples"][0]["process"]
{'type': 'capture', 'state': {'status': 'waiting', 'detail': 'WAITING FOR TRANSACTION'}, 'bytesMined': 2264, 'bytesSent': 1524, 'messagesCaptured': 5, 'lag': 0}



The same pair exists for a replicat: list_replicat_diagnostics() / get_replicat_diagnostic().



Configuration files



GLOBALS, parameter files, and the rest of what a deployment keeps under its config directory come from /services/v2/config/files. That directory is $OGG_CONF_HOME, or $OGG_DEPLOYMENT_HOME/etc/conf. They return their content directly:



# /services/v2/config/files
>>> ogg_client.list_configuration_files(ogg_service="adminsrvr")
[{'name': 'EXT1.prm'}, {'name': 'EXT2.prm'}, {'name': 'REP1.prm'}, ...]

# /services/v2/config/files/EXT1.prm
>>> ogg_client.get_configuration_file(file="EXT1.prm", ogg_service="adminsrvr")
{'lines': ['EXTRACT EXT1', 'USERIDALIAS pdb1 DOMAIN OracleGoldenGate', 'EXTTRAIL qa/xa', 'TABLE APP_PDB1.TEST;'], '$schema': 'ogg:config'}



To summarize, for each file:












File API endpoint oggrestapi.py call
Service logs (adminsrvr.log, etc.) /services/v2/logs/default with Accept: text/plain get_log('default', content=True) / get_service_log('default', content=True)
Service Manager logs (ServiceManager.log, restapi.log) Same resource, against the Service Manager’s port get_service_manager_log()
ggserr.log /services/v2/messages list_messages()
adminclient.log None, it is a client-side file under /var/log None (filesystem only)
extract.log or replicat.log None, they are filtered views of ggserr.log None (filtered view)
Reports (.rpt) /services/v2/extracts/{extract}/info/reports[/{report}] (or replicats), content returned directly list_extract_reports() / get_extract_report(), or get_current_extract_report() / get_current_replicat_report()
Diagnostics /services/v2/extracts/{extract}/info/diagnostics[/{diagnostic}] list_extract_diagnostics() / get_extract_diagnostic()
Configuration files /services/v2/config/files/{file} (content returned directly) list_configuration_files() / get_configuration_file()
L’article Retrieving GoldenGate logs, reports, and diagnostics with the REST API est apparu en premier sur dbi Blog.

File	API endpoint	`oggrestapi.py` call
Service logs (`adminsrvr.log`, etc.)	`/services/v2/logs/default` with `Accept: text/plain`	`get_log('default', content=True)` / `get_service_log('default', content=True)`
Service Manager logs (`ServiceManager.log`, `restapi.log`)	Same resource, against the Service Manager’s port	`get_service_manager_log()`
`ggserr.log`	`/services/v2/messages`	`list_messages()`
`adminclient.log`	None, it is a client-side file under `/var/log`	None (filesystem only)
`extract.log` or `replicat.log`	None, they are filtered views of `ggserr.log`	None (filtered view)
Reports (`.rpt`)	`/services/v2/extracts/{extract}/info/reports[/{report}]` (or `replicats`), content returned directly	`list_extract_reports()` / `get_extract_report()`, or `get_current_extract_report()` / `get_current_replicat_report()`
Diagnostics	`/services/v2/extracts/{extract}/info/diagnostics[/{diagnostic}]`	`list_extract_diagnostics()` / `get_extract_diagnostic()`
Configuration files	`/services/v2/config/files/{file}` (content returned directly)	`list_configuration_files()` / `get_configuration_file()`



Anatomy of an Enterprise Manager metric extension
Julien Delattre — Fri, 23 Oct 2026 11:09:17 +0000

Recently, I was working on deploying Metric Extensions automatically in Enterprise Manager, but the more I looked into it, the more it turned into a different question: what does a Metric Extension look like ? In a previous blog, I presented the SYSMAN tables containing the metric extensions definitions. I also showed how to retrieve the targets where a metric extension is deployed. Now, it’s time to look at formatting metric extensions.



Once again, emcli help does not show any verb for creating metric extensions:



$ emcli help | grep -i metric_extension
    export_metric_extension           -- Export a metric extension to an archive file
    get_unused_metric_extensions      -- Get a list of unused metric extensions
    import_metric_extension           -- Import a metric extension archive file
    publish_metric_extension          -- Publish a metric extension for use by all administrators
    save_metric_extension_draft       -- Save a deployable draft of a metric extension



Unfortunately, nothing in the documentation will help us to create a metric extension outside of the web UI. So let’s reverse engineer them. The plan is the following:




Create metric extensions in the web UI



Export the XML files with emcli



Later, create new metric extensions or update existing metrics more easily, directly with emcli




Building a minimal metric extension



Let’s build the most basic metric extension first, with Host as the target type. I will choose the OS Command - Multiple Columns adapter, and just an echo command.







The adapter itself is /bin/echo with em_result=1 as its argument and em_result= as the Starts With prefix. It is the same em_result=-prefixed, delimiter-tokenized convention the OEM plugin’s OSLineToken fetchlet uses, which turned out not to be a coincidence (more on that below). One column, value, type Number:







The Test step lets you run the metric job for real against a live target before committing to anything. Since the idea is to have a valid archive that we can play with, it should definitely be tested.







Exporting the metric extension



You cannot export an Editable metric. The docs restrict export_metric_extension to Production, Deployable Draft, and Published versions. So the first step is promoting it, either via the UI or with emcli:



$ emcli save_metric_extension_draft -target_type=host -name='ME$minimal_uptime_check' -version=1



Don’t worry if you receive no output, this is expected. Then, you can export the metric:



$ emcli export_metric_extension -file_name=/tmp/minimal_uptime_check_v1.zip -target_type=host -name='ME$minimal_uptime_check' -version=1
Metric extension [host, ME$minimal_uptime_check, 1] exported successfully to file /tmp/minimal_uptime_check_v1.zip



There are three files in the archive:



metadata/ME#24#minimal_uptime_check.xml
collection/ME#24#minimal_uptime_check.xml
mea.xml



The first one is the manifest, mea.xml:










The metric definition is in metadata/ME#24#minimal_uptime_check.xml:





Minimal Uptime Check
Minimal test ME - single OS command column, no credentials.




Value




/bin/echo
%scriptsDir%
em_result=1
|
em_result=
NAME







Here, we can see that:




FETCHLET_ID="OSLineToken" is the same fetchlet a full OEM plugin’s TargetMetadata XML uses for its OSLineToken-based collectors. The wizard is just generating the same fetchlet configuration.



command, args, delimiter and startsWith are the basic properties fields the adapter step.



ENVEM_TARGET_NAME is set even though I did not alter the Environment Variables section. This is the default.




The last file, collection/ME#24#minimal_uptime_check.xml, is the schedule:




	
		
	
	
	





Adding a second column and a real environment variable



Let’s build a second metric extension from the UI with the same command, but with two columns instead of one. I will also add a custom environment variable this time.







For comparison, this is what the Environment Variables table looks like before you add anything to it: EM_TARGET_NAME is already there.







And the second column added on the Columns step:







Exporting this metric extension and comparing the metadata against the first archive shows exactly what each choice changes:



$ diff unpacked/metadata/*.xml unpacked_v2/metadata/*.xml
1c1
< 
---
> 
3,4c3,4
< Minimal Uptime Check
< Minimal test ME - single OS command column, no credentials.
---
> Minimal Uptime Check V2
> Variant with env var and 2 columns, for archive-format comparison.
9c9,14
< Value
---
> Value
> 
> 
> 
> 
> State
16c21
< em_result=1
---
> em_result=1|running
19a25
> hello_world



The second extension was saved under a new name, ME$minimal_uptime_check_v2, so every EXT_NAME, NAME and NLSID differs. Removing this noise, there are three changes that matter: the new state column, the args property, and the environment variable ENVMY_CUSTOM_VAR.



...
> 
> 
> State
> 
> 

...

< em_result=1
---
> em_result=1|running

...

> hello_world



The new column is a second ColumnDescriptor, in the same order as the pipe-delimited output (em_result=1|running). The environment variable becomes ENVMY_CUSTOM_VAR=hello_world.



Adding an uploaded script



Both examples above run an OS command directly. Let’s create a metric extension that runs an uploaded script instead of a literal command. Exporting a metric extension with an uploaded Perl script adds a fourth path to the archive, alongside the usual mea.xml/metadata/collection:



mea.xml
metadata/ME#24#script_uptime_check.xml
collection/ME#24#script_uptime_check.xml
scripts/uptime_check.pl



The manifest lists the script by its real name, in a  element, with an updated attach_digest parameter.












The QueryDescriptor has a new property called script, giving the script name. The command property is also updated, pointing at perl instead of /bin/echo.




%perlBin%/perl
%scriptsDir%/uptime_check.pl
%scriptsDir%
|
em_result=
NAME





Repository-side metric extension



Let’s conclude by creating a repository-side metric extension, which runs SQL against the OMS repository. With a repository-side Metric Extension, the FETCHLET_ID is REPOSITORY_SQL, and the properties are replaced by a Source property containing the SQL query:




SQL
SELECT target_guid,
       target_type,
       1 AS host_count
FROM mgmt$target
WHERE target_type = 'host'




In the manifest, is_repos="TRUE" is what differentiates this kind of metric extension. The  element itself picks up REPOSITORY="TRUE" too, and the columns default to the query SELECT list (TARGET_TYPE, HOST_COUNT here) rather than anything typed by hand on the Columns step.










With all of this in mind, let’s try to feed the Enterprise Manager a custom metric extension built entirely by hand, using a small Python script as the collector instead of a literal command.



Import our first custom metric extension



Here is a script reading the 1-minute load average from /proc/loadavg and printing it with the same em_result= prefix expected by OSLineToken.



#!/usr/bin/env python3
with open("/proc/loadavg") as f:
    load1 = f.read().split()[0]
print(f"em_result={load1}")



We have three XML files and the script, written by hand rather than exported from the wizard. metadata/ME#24#python_load_check.xml:





Python Load Check
Runs an uploaded Python script that reads the 1-minute load average from /proc/loadavg.




Value




/usr/bin/python3
%scriptsDir%/load_check.py
%scriptsDir%
|
em_result=
NAME







The command property points at the interpreter (/usr/bin/python3 instead of %perlBin%/perl), while script points at the uploaded file. Everything else is untouched. Here is the collection/ME#24#python_load_check.xml file:




	
		
	
	
	





And the manifest mea.xml:












The digests are just zeroes here. The OMS recomputes and stores new digests when you import the metric.



Now, let’s build the archive with the same layout export_metric_extension produces, assembled by hand instead:



$ find build -type f
build/mea.xml
build/metadata/ME#24#python_load_check.xml
build/collection/ME#24#python_load_check.xml
build/scripts/load_check.py

$ cd build && zip -rq ../python_load_check.zip . && cd ..
$ unzip -l python_load_check.zip
Archive:  python_load_check.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  08-27-2026 14:38   metadata/
     1212  08-27-2026 14:38   metadata/ME#24#python_load_check.xml
        0  08-27-2026 14:38   collection/
      321  08-27-2026 14:38   collection/ME#24#python_load_check.xml
        0  08-27-2026 14:38   scripts/
      116  08-27-2026 14:38   scripts/load_check.py
      529  08-27-2026 14:38   mea.xml
---------                     -------
     2178                     7 files



The last step is to import the metric extension with emcli:



$ emcli import_metric_extension -file_name=python_load_check.zip
Metric extension file python_load_check.zip imported successfully



You now know how to build metric extensions without going through the web UI.
L’article Anatomy of an Enterprise Manager metric extension est apparu en premier sur dbi Blog.



How to detect a suspended GoldenGate extract
Julien Delattre — Mon, 19 Oct 2026 06:59:00 +0000

While testing EVENTACTIONS (SUSPEND) on an extract, I noticed that nothing in INFO tells you the process is suspended. The extract shows as RUNNING, the lag might look fine for a while, and yet it has stopped capturing. You may use SUSPEND on purpose (to pause an extract when a specific DDL goes by, for instance). Or someone else put it in a parameter file and you have to monitor the result. Either way, you need another way to know.



In the end, SEND EXTRACT ... STATUS is the only command that reports the suspended state, and it works the same way through the REST API, where the text is already parsed for you. A simpler check exists in the report file, generating an OGG-01281, but it has a limit I will show at the end.



In this blog, I will run an EXT1 extract capturing from PDB1. It has a DDL EVENTACTIONS trigger on a CREATE USER statement run in PDB1. The trigger suspends the extract whenever a user is created:



EXTRACT EXT1
USERIDALIAS pdb1 DOMAIN OracleGoldenGate
EXTTRAIL pdb1/e1
DDL INCLUDE ALL OBJTYPE 'USER' OPTYPE CREATE EVENTACTIONS (SUSPEND)
DDLOPTIONS REPORT
TABLE APP_PDB1.*;



Extract status before SUSPEND



Once started, the extract shows as RUNNING in INFO ALL:



OGG (http://vmogg:7810 ogg_test_01) 2> INFO ALL
Program     Status      Group       Type                   Lag at Chkpt       Time Since Chkpt

EXTRACT     RUNNING     EXT1        INTEGRATED                  00:00:00           00:00:06



SEND EXTRACT EXT1 STATUS reports where the extract is in its life cycle. Here, the extract has nothing to capture, so the status is At EOF:



OGG (http://vmogg:7810 ogg_test_01) 2> SEND EXTRACT EXT1 STATUS

Sending STATUS request to Extract group EXT1 ...

EXTRACT EXT1 (PID 21617)
  Current status: Recovery complete: At EOF

  Current read position:
  Redo thread #: 0
  Sequence #: 0
  RBA: 0
  Timestamp: 2026-09-26 06:26:24.000000
  SCN: 0.115334476 (115334476)
  Current write position:
  Sequence #: 11
  RBA: 6942
  Timestamp: 2026-09-26 06:26:20.463368
  Extract Trail: pdb1/e1



Suspending the extract



Let’s create a user in PDB1, which matches the DDL rule:



SQL> CREATE USER SUSPTEST IDENTIFIED BY "Suspend_Test_1";

User created.



Half a minute later, INFO EXT1 still says RUNNING with a lag of 0 seconds, but the checkpoint was last updated 30 seconds ago:



OGG (http://vmogg:7810 ogg_test_01) 2> INFO EXT1

Extract    EXT1      Last Started 2026-09-26 06:26   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:30 ago)
Process ID           21617
Log Read Checkpoint  Oracle Integrated Redo Logs, per-PDB
                     2026-09-26 06:26:18
                     SCN 0.115334462 (115334462)
Encryption Profile   LocalWallet
No Replicat groups found, but some coordinated threads may have been excluded.



Two minutes after the CREATE USER, the same command gives:



OGG (http://vmogg:7810 ogg_test_01) 2> INFO EXT1

Extract    EXT1      Last Started 2026-09-26 06:26   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:02:00 ago)
Process ID           21617
Log Read Checkpoint  Oracle Integrated Redo Logs, per-PDB
                     2026-09-26 06:26:18
                     SCN 0.115334462 (115334462)
Encryption Profile   LocalWallet
No Replicat groups found, but some coordinated threads may have been excluded.



The status is still RUNNING, and the lag value does not grow: Checkpoint Lag stays at 00:00:00. What grows is the time since the checkpoint was updated (updated 00:00:30 ago, then updated 00:02:00 ago), and the checkpoint position (SCN 0.115334462) never moves. That is a hint that something is wrong (or right), but nothing in this output says it is a suspend.



SEND EXTRACT STATUS shows the suspended state



Now the same SEND EXTRACT EXT1 STATUS as before:



OGG (http://vmogg:7810 ogg_test_01) 2> SEND EXTRACT EXT1 STATUS

Sending STATUS request to Extract group EXT1 ...

EXTRACT EXT1 (PID 21617)
  Current status: Recovery complete: Suspended, waiting to be resumed

  Current read position:
  Redo thread #: 1
  Sequence #: 3045
  RBA: 58777616
  Timestamp: 2026-09-26 06:26:27.000000
  SCN: 0.115334507 (115334507)
  Current write position:
  Sequence #: 11
  RBA: 6942
  Timestamp: 2026-09-26 06:26:20.463368
  Extract Trail: pdb1/e1



Comparing the two outputs, the only line that tells you the extract is suspended is Current status:




Before: Current status: Recovery complete: At EOF. It could have been some other message if it was still extracting.



After: Current status: Recovery complete: Suspended, waiting to be resumed




Everything else in INFO is compatible with a healthy extract. To resume it, run SEND EXTRACT EXT1 RESUME.



Which command shows the suspend?



STATUS EXTRACT looks like the natural command, but it is not the same as SEND EXTRACT ... STATUS. On the suspended extract, STATUS EXTRACT gives:



OGG (http://vmogg:7810 ogg_test_01) 4> STATUS EXTRACT EXT1
EXTRACT EXT1: RUNNING



INFO EXT1 DETAIL adds the trail, the outbound server SCNs and the file locations, but its header is the same as INFO EXT1:



OGG (http://vmogg:7810 ogg_test_01) 5> INFO EXT1 DETAIL

Extract    EXT1      Last Started 2026-09-26 06:26   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:02:00 ago)
Process ID           21617
Log Read Checkpoint  Oracle Integrated Redo Logs, per-PDB
                     2026-09-26 06:26:18
                     SCN 0.115334462 (115334462)
Encryption Profile   LocalWallet

  Target Extract Trails:

  Trail Name                                       Seqno        RBA     Max MB Trail Type

  pdb1/e1                                             11       6942       2000 EXTTRAIL

Integrated Extract outbound server first scn: 0.115313606 (115313606)

Integrated Extract outbound server filtering start scn: 0.115313606 (115313606)



Command Before the suspend After the suspend
INFO ALL RUNNING RUNNING
INFO EXT1 RUNNING RUNNING
INFO EXT1 DETAIL RUNNING RUNNING
STATUS EXTRACT EXT1 RUNNING RUNNING
SEND EXTRACT EXT1 STATUS Recovery complete: At EOF Recovery complete: Suspended, waiting to be resumed



Only SEND EXTRACT ... STATUS shows the suspend. STATUS EXTRACT, like INFO, just reports the state of the process.



Getting the status with the REST API



The SEND commands are available through the /services/{version}/extracts/{extract}/command endpoint, and the response already contains the parsed status.



With the oggrestapi Python client



With the GoldenGate Python client, execute_command_extract sends the request. First, initialize the client:



>>> from oggrestapi import OGGRestAPI
>>> ogg_client = OGGRestAPI(
    url='http://vmogg:7810',
    username='ogg',
    password='ogg'
)
Connected to OGG REST API at http://vmogg:7810



Here is the raw output given by the execute_command_extract method:



>>> resp = ogg_client.execute_command_extract('EXT1', data={'command': 'STATUS'})
>>> resp
{'$schema': 'er:commandResult', 'reply': 'OKNODOT\tEXTRACT EXT1 (PID 41522)\n  Current status: Recovery complete: Suspended, waiting to be resumed\n\n  Current read position:\n  Redo thread #: 1\n  Sequence #: 3047\n  RBA: 92686352\n  Timestamp: 2026-09-26 08:48:41.000000\n  SCN: 0.115434621 (115434621)\n  Current write position:\n  Sequence #: 1\n  RBA: 5679\n  Timestamp: 2026-09-26 08:48:37.669072\n  Extract Trail: pdb1/r1\n\n', 'replyData': {'$schema': 'er:statusResult', 'status': {'groupName': 'EXT1', 'processId': '41522', 'processType': 'extract', 'status': 'Recovery complete: Suspended, waiting to be resumed', 'extractReadingPosition': [{'$schema': 'dbms:positionInfo', 'position': {'redoThread': 1, 'csn': 115434621, 'seqno': 3047, 'rba': 92686352, 'timestamp': '2026-09-26T08:48:41.000Z'}}], 'extractWritingPosition': [{'$schema': 'ogg:trailPosition', 'sequence': 1, 'offset': 5679, 'name': 'r1', 'path': 'pdb1/'}]}}}



In GoldenGate REST API, the status is available in replyData.status.status:



>>> resp['replyData']['status']['status']
'Recovery complete: Suspended, waiting to be resumed'



To avoid repeating the replyData navigation everywhere, custom methods are available in oggrestapi:



def get_extract_status_detail(self, extract):
    result = self.execute_command_extract(extract, data={'command': 'STATUS'})
    return str(result.get('replyData', {}).get('status', {}).get('status', ''))

def is_extract_suspended(self, extract):
    return 'suspended' in self.get_extract_status_detail(extract).lower()



>>> ogg_client.get_extract_status_detail('EXT1')
'Recovery complete: Suspended, waiting to be resumed'

>>> ogg_client.is_extract_suspended('EXT1')
True



With the requests module



Without the client, send STATUS as the command with the requests library:



import requests

url = 'http://vmogg:7810/services/v2/extracts/EXT1'
auth = ('ogg', 'ogg')

response = requests.post(f'{url}/command', auth=auth, json={'command': 'STATUS'}).json()['response']



The response contains the same replyData field, with the status already extracted:



>>> response['replyData']['status']['status']
'Recovery complete: Suspended, waiting to be resumed'



Note that this is not the same as the info/status endpoint, which returns the process state as INFO does. It says running for a suspended extract, but it contains the two values behind the lag line of INFO:



>>> requests.get(f'{url}/info/status', auth=auth).json()['response']
{'$schema': 'ogg:extractStatus', 'status': 'running', 'processId': 21617, 'lastStarted': '2026-09-26T06:26:09.798Z', 'lag': 0, 'sinceLagReported': 125, 'position': '0.115334462'}



lag is the checkpoint lag of INFO, and sinceLagReported is the updated ... ago value in seconds.



Adding a lag check



For a monitoring script, the status can be paired with a lag check. get_extract_status costs a single GET call, and a healthy extract keeps updating its checkpoint. A large sinceLagReported is a cheap first filter before sending the STATUS command:



>>> status = ogg_client.get_extract_status('EXT1')
>>> status['status'] == 'running' and status['sinceLagReported'] > 60 and ogg_client.is_extract_suspended('EXT1')
True



When this returns True, you have a running extract that has not moved for more than a minute and that reports itself as suspended. Whether you should then resume it depends on why the SUSPEND was there in the first place. An alert is usually the right answer. If you do want to resume it from the script, it is another execute_command_extract call:



>>> ogg_client.execute_command_extract('EXT1', data={'command': 'RESUME'})



A simpler check: OGG-01281 in the report



The suspend also leaves a trace in the extract report file, with the OGG-01281 message:



2026-09-26 06:26:29  INFO    OGG-00487  DDL operation included [INCLUDE ALL OBJTYPE 'USER' OPTYPE CREATE EVENTACTIONS (SUSPEND)], optype [CREATE], objtype [USER], objowner "", objname "SUSPTEST".

2026-09-26 06:26:30  INFO    OGG-01281  Processed SUSPEND event from DDL on object name SUSPTEST, DDL seqno 0, marker seqno 0.



Is this message specific to SUSPEND? To check it, I ran the same DDL rule with other EVENTACTIONS, recreating the user each time:



# DDL INCLUDE ALL OBJTYPE 'USER' OPTYPE CREATE EVENTACTIONS (ROLLOVER)
2026-09-26 06:29:32  INFO    OGG-01285  Processed ROLLOVER event from DDL on object name SUSPTEST, DDL seqno 0, marker seqno 0.

# DDL INCLUDE ALL OBJTYPE 'USER' OPTYPE CREATE EVENTACTIONS (LOG INFO)
2026-09-26 06:30:37  INFO    OGG-06117  Processed LOG event from DDL on object name SUSPTEST, DDL seqno 0, marker seqno 0.

# DDL INCLUDE ALL OBJTYPE 'USER' OPTYPE CREATE EVENTACTIONS (LOG WARNING)
2026-09-26 06:31:40  WARNING OGG-06118  Processed LOG event from DDL on object name SUSPTEST, DDL seqno 0, marker seqno 0.



ROLLOVER raises OGG-01285, and LOG raises OGG-06117 (or OGG-06118 with WARNING). IGNORE raises nothing at all beyond the OGG-00487 line. So OGG-01281 is only raised by SUSPEND.



The limit of this check is that the report is a history, not a state. When resuming the extract, the OGG-01281 line stays in the report, and a new message is written after it:



2026-09-26 06:26:30  INFO    OGG-01281  Processed SUSPEND event from DDL on object name SUSPTEST, DDL seqno 0, marker seqno 0.
2026-09-26 06:28:29  INFO    OGG-01824  Resume processing from SUSPEND state for process EXT1.



Finding OGG-01281 in the report does not mean the extract is suspended now. You have to check that no OGG-01824 comes after it. On top of that, the report is rolled over at each restart of the extract, so it only covers the current run. With the REST API, the report is available through get_extract_report, whose lines key contains the list of lines:



>>> report = ogg_client.get_extract_report('EXT1', 'EXT1.rpt')
>>> [line for line in report['lines'] if 'OGG-01281' in line or 'OGG-01824' in line]
['2026-09-26 06:26:30  INFO    OGG-01281  Processed SUSPEND event from DDL on object name SUSPTEST, DDL seqno 0, marker seqno 0.']



This is useful to find out when and why the extract was suspended, since the message contains the object that triggered it. But to know whether it is suspended right now, STATUS is the reliable way.



The full check in one script



Here is a small script with everything seen in this blog. It runs the lag check, the suspend check, and the log analysis to find the culprit, then prints an info message.



from oggrestapi import OGGRestAPI

ogg_client = OGGRestAPI(url='http://vmogg:7810', username='ogg', password='ogg')

extract = 'EXT1'
status = ogg_client.get_extract_status(extract)

# Lag check: a running extract whose checkpoint has not moved for a minute
if status['status'] == 'running' and status['sinceLagReported'] > 60:
    # Suspend check
    if ogg_client.is_extract_suspended(extract):
        # Log analysis: the last OGG-01281 or OGG-01824 tells who suspended it
        report = ogg_client.get_extract_report(extract, f'{extract}.rpt')
        events = [line for line in report['lines'] if 'OGG-01281' in line or 'OGG-01824' in line]
        if events and 'OGG-01281' in events[-1]:
            print(f'INFO: {extract} is suspended. Culprit: {events[-1]}')
        else:
            print(f'INFO: {extract} is suspended, but no OGG-01281 in the current report')
    else:
        print(f'INFO: {extract} is not suspended, but its checkpoint has not moved for {status["sinceLagReported"]} seconds')
else:
    print(f'INFO: {extract} is not suspended')



INFO: EXT1 is suspended. Culprit: 2026-09-26 06:26:30  INFO    OGG-01281  Processed SUSPEND event from DDL on object name SUSPTEST, DDL seqno 0, marker seqno 0.



What about replicats?



It works the same way for a replicat. I tested it with an integrated replicat applying the trail of EXT1, with DDL INCLUDE ALL OBJTYPE 'USER' OPTYPE CREATE EVENTACTIONS (SUSPEND) in its parameter file. INFO reports RUNNING, and SEND REPLICAT REP1 STATUS reports the suspended state. is_replicat_suspended returns True, and SEND REPLICAT REP1 RESUME resumes it with an OGG-01824.



The suspend is still logged with OGG-01281, but the culprit is not named. The replicat suspends before applying the DDL, so the report says object name N/A. The user name only appears in the OGG-00487 line after the resume operation:



2026-09-26 08:56:19  INFO    OGG-01281  Processed SUSPEND event from DDL on object name N/A in file /u01/app/ogg/deployments/ogg_test_01/var/lib/data/pdb1/q1000000000, RBA 5284.
2026-09-26 08:58:02  INFO    OGG-01824  Resume processing from SUSPEND state for process REP1.
2026-09-26 08:58:02  INFO    OGG-00487  DDL operation included [INCLUDE ALL OBJTYPE 'USER' OPTYPE CREATE EVENTACTIONS (SUSPEND)], optype [CREATE], objtype [USER], objowner "", objname "SUSPTEST".



Summary



To know whether a GoldenGate extract is suspended by an EVENTACTIONS (SUSPEND) rule:




Do not rely on INFO ALL, INFO, INFO DETAIL or STATUS EXTRACT. They all report RUNNING, and the checkpoint lag stays the same. Only the updated ... ago value grows.



Run SEND EXTRACT EXT1 STATUS in the adminclient: Current status: Recovery complete: Suspended, waiting to be resumed appears when the extract is suspended.



In a script, use is_extract_suspended from the Python client, or send the same STATUS command to /services/v2/extracts/EXT1/command and read replyData.status.status.



Filter with sinceLagReported from info/status (for instance more than 60 seconds) before sending the STATUS command.



Use OGG-01281 in the report to find out when and why the extract was suspended, and check that no OGG-01824 came after it.



Resume with SEND EXTRACT EXT1 RESUME, or with the RESUME command through execute_command_extract.

L’article How to detect a suspended GoldenGate extract est apparu en premier sur dbi Blog.



Import order matters for GoldenGate instantiation filtering
Julien Delattre — Thu, 15 Oct 2026 15:37:47 +0000

When migrating a large database with GoldenGate, most of the volume is sometimes in old partitions which no longer change. A common shortcut is to move them first with expdp/impdp, even before GoldenGate is set up. Everything else, the active partitions and the non-partitioned tables, is exported once the extract is running, with PREPARECSN set. Instantiation filtering then makes the replicat skip what Data Pump already loaded.



However, there is an important aspect here: dba_apply_instantiated_objects has one row per table. Every impdp overwrites it, and there is no way for GoldenGate or Data Pump to know which import should be considered the correct one for populating the dba_apply_instantiated_objects view. The old partitions and the live data of a table share that row, so in a multi-import initial load the last import always wins.



Standard scenario: importing old partitions first



The old partitions of all partitioned tables are moved first, in one dump, before GoldenGate is involved. Since no GoldenGate extract exists yet, PREPARECSN has not run either:



$ expdp sales/***@PDB1 dumpfile=old_part.dmp tables=SALES.ORDERS_PART:P_OLD,SALES.ITEMS_PART:P_OLD
. . exported "SALES"."ITEMS_PART":"P_OLD"                 5.523 KB       5 rows
. . exported "SALES"."ORDERS_PART":"P_OLD"                5.523 KB       5 rows
Job "SALES"."SYS_EXPORT_TABLE_01" successfully completed at Sun Oct 11 13:52:08 2026 elapsed 0 00:00:10

$ impdp sales/***@PDB2 dumpfile=old_part.dmp
. . imported "SALES"."ITEMS_PART":"P_OLD"                 5.523 KB       5 rows
. . imported "SALES"."ORDERS_PART":"P_OLD"                5.523 KB       5 rows
Job "SALES"."SYS_IMPORT_FULL_01" successfully completed at Sun Oct 11 13:52:12 2026 elapsed 0 00:00:02



Querying the instantiation view on the target returns nothing, as expected:



SQL> SELECT source_database, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'SALES';

no rows selected



Data Pump only populates this view when the table was prepared with PREPARECSN before the export. These first imports are invisible to GoldenGate.



Starting the extract



The extract connects to PDB1 and captures the SALES schema into the trail pt. It is added, registered and started in the adminclient, logged in to PDB1. The registration SCN is where capture begins:



OGG (http://localhost:7810 ogg_test_01) 2> DBLOGIN USERIDALIAS oggadmin_pdb1 DOMAIN OracleGoldenGate
Successfully logged into database PDB1.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 3> ADD EXTRACT EXTPT, INTEGRATED TRANLOG, BEGIN NOW
2026-10-11T13:52:13Z  INFO    OGG-08100  Integrated Extract added.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 4> REGISTER EXTRACT EXTPT DATABASE
2026-10-11T13:52:14Z  INFO    OGG-02003  Extract group EXTPT successfully registered with database at SCN 189554050.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 5> ADD EXTTRAIL pt, EXTRACT EXTPT
2026-10-11T13:52:14Z  INFO    OGG-08100  EXTTRAIL added.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 6> VIEW PARAMS EXTPT
EXTRACT EXTPT
USERIDALIAS oggadmin_pdb1 DOMAIN OracleGoldenGate
EXTTRAIL pt
TABLE SALES.*;

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 7> START EXTRACT EXTPT
2026-10-11T13:52:14Z  INFO    OGG-00975  Extract group EXTPT starting.
2026-10-11T13:52:14Z  INFO    OGG-15426  Extract group EXTPT started.



Some workload follows on the live data, before PREPARECSN:



SQL> INSERT INTO sales.orders_part VALUES (1001, 'ACTIVE');

1 row created.

SQL> INSERT INTO sales.orders_part VALUES (1002, 'ACTIVE');

1 row created.

SQL> INSERT INTO sales.items_part VALUES (1001, 'ACTIVE');

1 row created.

SQL> INSERT INTO sales.items_part VALUES (1002, 'ACTIVE');

1 row created.

SQL> INSERT INTO sales.customers VALUES (4, 'LIVE');

1 row created.

SQL> COMMIT;

Commit complete.



Then the schema is prepared in the adminclient. ADD SCHEMATRANDATA ... ALLCOLS sets PREPARECSN on the schema in NOWAIT mode:



OGG (http://localhost:7810 ogg_test_01) 2> DBLOGIN USERIDALIAS oggadmin_pdb1 DOMAIN OracleGoldenGate
Successfully logged into database PDB1.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 3> ADD SCHEMATRANDATA SALES ALLCOLS
2026-10-11T13:52:15Z  INFO    OGG-01788  SCHEMATRANDATA has been added on schema "SALES".
2026-10-11T13:52:15Z  INFO    OGG-01976  SCHEMATRANDATA for scheduling columns has been added on schema "SALES".
2026-10-11T13:52:15Z  INFO    OGG-01977  SCHEMATRANDATA for all columns has been added on schema "SALES".
2026-10-11T13:52:15Z  INFO    OGG-10154  Schema level PREPARECSN set to mode NOWAIT on schema "SALES"



Exporting and importing the live data



The active partitions are exported next, in a single expdp, deliberately without FLASHBACK_SCN. Data Pump chooses a consistent SCN itself, for each table:



$ expdp sales/***@PDB1 dumpfile=active_part.dmp tables=SALES.ORDERS_PART:P_ACTIVE,SALES.ITEMS_PART:P_ACTIVE
FLASHBACK automatically enabled to preserve database integrity.
. . exported "SALES"."ITEMS_PART":"P_ACTIVE"                5.5 KB       2 rows
. . exported "SALES"."ORDERS_PART":"P_ACTIVE"               5.5 KB       2 rows
Job "SALES"."SYS_EXPORT_TABLE_01" successfully completed at Sun Oct 11 13:52:29 2026 elapsed 0 00:00:12



Live inserts after that export are therefore not in the dump:



SQL> INSERT INTO sales.orders_part VALUES (1003, 'ACTIVE');

1 row created.

SQL> INSERT INTO sales.items_part VALUES (1003, 'ACTIVE');

1 row created.

SQL> COMMIT;

Commit complete.



Every other table goes in a third export, at the schema level, excluding the partitioned tables. Any number of normal tables fits in this one export, and a new partitioned table is added to the exclusion:



$ cat rest.par
dumpfile=rest.dmp
schemas=SALES
exclude=TABLE:"IN ('ORDERS_PART','ITEMS_PART')"



$ expdp sales/***@PDB1 parfile=rest.par
FLASHBACK automatically enabled to preserve database integrity.
. . exported "SALES"."CUSTOMERS"                          5.515 KB       4 rows
Job "SALES"."SYS_EXPORT_SCHEMA_01" successfully completed at Sun Oct 11 13:52:55 2026 elapsed 0 00:00:24



A live insert after this export is not in the dump either:



SQL> INSERT INTO sales.customers VALUES (5, 'LIVE');

1 row created.

SQL> COMMIT;

Commit complete.



The partitioned tables already exist on the target, so the active partitions are appended. A regular import creates the normal tables:



$ impdp sales/***@PDB2 dumpfile=active_part.dmp table_exists_action=append
Table "SALES"."ORDERS_PART" exists. Data will be appended to existing table but all dependent metadata will be skipped due to table_exists_action of append
Table "SALES"."ITEMS_PART" exists. Data will be appended to existing table but all dependent metadata will be skipped due to table_exists_action of append
. . imported "SALES"."ITEMS_PART":"P_ACTIVE"                5.5 KB       2 rows
. . imported "SALES"."ORDERS_PART":"P_ACTIVE"               5.5 KB       2 rows
Job "SALES"."SYS_IMPORT_FULL_01" successfully completed at Sun Oct 11 13:53:00 2026 elapsed 0 00:00:03

$ impdp sales/***@PDB2 dumpfile=rest.dmp
. . imported "SALES"."CUSTOMERS"                          5.515 KB       4 rows
Job "SALES"."SYS_IMPORT_FULL_01" successfully completed at Sun Oct 11 13:53:04 2026 elapsed 0 00:00:02



The instantiation view now has one row per table. The partitioned tables have SCNs from the second export, while CUSTOMERS has one from the third export:



SQL> SELECT source_database, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'SALES'
ORDER BY source_object_name;

SOURCE_DATABASE SOURCE_OBJECT_NAME INSTANTIATION_SCN
--------------- ------------------ -----------------
PDB1            CUSTOMERS                  189585331
PDB1            ITEMS_PART                 189572011
PDB1            ORDERS_PART                189572008

3 rows selected.



Replicat with instantiation filtering



Each instantiation SCN applies to the whole table, and we use instantiation filtering in the replicat. It is added and started in the adminclient:



OGG (http://localhost:7810 ogg_test_01) 2> DBLOGIN USERIDALIAS oggadmin_pdb2 DOMAIN OracleGoldenGate
Successfully logged into database PDB2.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb2@CDB02/PDB2) 3> ADD REPLICAT REPPT, INTEGRATED, EXTTRAIL pt, CHECKPOINTTABLE OGGADMIN.CHECKPOINT
2026-10-11T13:53:05Z  INFO    OGG-08100  Integrated Replicat added.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb2@CDB02/PDB2) 4> VIEW PARAMS REPPT
REPLICAT REPPT
DBOPTIONS ENABLE_INSTANTIATION_FILTERING
USERIDALIAS oggadmin_pdb2 DOMAIN OracleGoldenGate
MAP SALES.*, TARGET SALES.*;

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb2@CDB02/PDB2) 5> START REPLICAT REPPT
2026-10-11T13:53:05Z  INFO    OGG-00975  Replicat group REPPT starting.
2026-10-11T13:53:05Z  INFO    OGG-15445  Replicat group REPPT started.



Once the replicat has caught up, the target tables have the same number of rows as the source:



SQL> SELECT COUNT(*) FROM sales.orders_part;

COUNT(*)
--------
       8

1 row selected.

SQL> SELECT COUNT(*) FROM sales.items_part;

COUNT(*)
--------
       8

1 row selected.

SQL> SELECT COUNT(*) FROM sales.customers;

COUNT(*)
--------
       5

1 row selected.



In the adminclient, we can see the transaction done after creating the extract, on each table:



OGG (http://localhost:7810 ogg_test_01) 2> STATS REPLICAT REPPT, TOTAL, TABLE SALES.*

Sending STATS TOTAL TABLE SALES.* request to Replicat group REPPT ...


Start of statistics at 2026-10-11 13:53:18.


Integrated Replicat statistics:

        Total transactions                                 2.00
        Redirected                                         0.00
        Replicated procedures                              0.00
        DDL operations                                     0.00
        Stored procedures                                  0.00
        Datatype functionality                             0.00
        Operation type functionality                       0.00
        Event actions                                      0.00
        Database compatibility                             0.00
        Direct transactions ratio                          0.00%

Replicating from SALES.ORDERS_PART to PDB2.SALES.ORDERS_PART:

*** Total statistics since 2026-10-11 13:53:07 ***
    Total inserts                              1.00
    Total updates                              0.00
    Total deletes                              0.00
    Total upserts                              0.00
    Total discards                             0.00
    Total operations                           1.00

Replicating from SALES.ITEMS_PART to PDB2.SALES.ITEMS_PART:

*** Total statistics since 2026-10-11 13:53:07 ***
    Total inserts                              1.00
    Total updates                              0.00
    Total deletes                              0.00
    Total upserts                              0.00
    Total discards                             0.00
    Total operations                           1.00

Replicating from SALES.CUSTOMERS to PDB2.SALES.CUSTOMERS:

*** Total statistics since 2026-10-11 13:53:07 ***
    Total inserts                              1.00
    Total updates                              0.00
    Total deletes                              0.00
    Total upserts                              0.00
    Total discards                             0.00
    Total operations                           1.00

End of statistics.



The only inserts are the three rows added after the exports, one per table. There is no ORA-00001: the rows inserted before the exports were replayed from the trail and skipped by the instantiation filtering. Without ENABLE_INSTANTIATION_FILTERING they would have hit the primary key.



FLASHBACK_SCN is not needed here. The replicat compares commit CSNs against instantiation_scn, not against the export’s flashback point. You only need PREPARECSN to have run before the export of the live data.



Foreign keys between tables that are in different exports are something to keep in mind.



Wrong order: importing old partitions after



What happens if, for some reason, you run the initial load of the active partitions first, with PREPARECSN and instantiation filtering, and then migrate the old partitions? Let’s try this, by first adding trandata:



OGG (http://localhost:7810 ogg_test_01) 2> DBLOGIN USERIDALIAS oggadmin_pdb1 DOMAIN OracleGoldenGate
Successfully logged into database PDB1.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 3> ADD TRANDATA SALES.ORDERS_PART PREPARECSN NOWAIT
2026-10-11T13:53:42Z  INFO    OGG-15132  Logging of supplemental redo data enabled for table SALES.ORDERS_PART.
2026-10-11T13:53:42Z  INFO    OGG-15133  TRANDATA for scheduling columns has been added on table SALES.ORDERS_PART.
2026-10-11T13:53:42Z  INFO    OGG-15438  Enabling logical replication (with all keys) on auto capture table SALES.ORDERS_PART.
2026-10-11T13:53:42Z  INFO    OGG-15135  TRANDATA for instantiation CSN has been added on table SALES.ORDERS_PART.



The old partitions are exported before the extract exists:



$ expdp sales/***@PDB1 dumpfile=b_old.dmp tables=SALES.ORDERS_PART:P_OLD
FLASHBACK automatically enabled to preserve database integrity.
. . exported "SALES"."ORDERS_PART":"P_OLD"                5.523 KB       5 rows
Job "SALES"."SYS_EXPORT_TABLE_01" successfully completed at Sun Oct 11 13:53:55 2026 elapsed 0 00:00:11



The extract is then registered and started, as in the first scenario:



OGG (http://localhost:7810 ogg_test_01) 2> DBLOGIN USERIDALIAS oggadmin_pdb1 DOMAIN OracleGoldenGate
Successfully logged into database PDB1.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 3> ADD EXTRACT EXTPT, INTEGRATED TRANLOG, BEGIN NOW
2026-10-11T13:53:57Z  INFO    OGG-08100  Integrated Extract added.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 4> REGISTER EXTRACT EXTPT DATABASE
2026-10-11T13:54:00Z  INFO    OGG-02003  Extract group EXTPT successfully registered with database at SCN 189596053.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 5> ADD EXTTRAIL pt, EXTRACT EXTPT
2026-10-11T13:54:00Z  INFO    OGG-08100  EXTTRAIL added.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb1@CDB01/PDB1) 6> START EXTRACT EXTPT
2026-10-11T13:54:00Z  INFO    OGG-00975  Extract group EXTPT starting.
2026-10-11T13:54:00Z  INFO    OGG-15426  Extract group EXTPT started.



Rows 1001 and 1002 are inserted into P_ACTIVE, and the live data is exported. Row 1003 is inserted after the export:



$ expdp sales/***@PDB1 dumpfile=b_active.dmp tables=SALES.ORDERS_PART:P_ACTIVE
FLASHBACK automatically enabled to preserve database integrity.
. . exported "SALES"."ORDERS_PART":"P_ACTIVE"               5.5 KB       2 rows
Job "SALES"."SYS_EXPORT_TABLE_01" successfully completed at Sun Oct 11 13:54:09 2026 elapsed 0 00:00:08



This time, on the target, the live data is imported first:



$ impdp sales/***@PDB2 dumpfile=b_active.dmp
. . imported "SALES"."ORDERS_PART":"P_ACTIVE"               5.5 KB       2 rows
Job "SALES"."SYS_IMPORT_FULL_01" successfully completed at Sun Oct 11 13:54:14 2026 elapsed 0 00:00:02



For now, the boundary is above the registration SCN 189596053:



SQL> SELECT source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'SALES'
AND source_object_name = 'ORDERS_PART';

SOURCE_OBJECT_NAME INSTANTIATION_SCN
------------------ -----------------
ORDERS_PART                189610870

1 row selected.



The old partitions are then imported:



$ impdp sales/***@PDB2 dumpfile=b_old.dmp table_exists_action=append
Table "SALES"."ORDERS_PART" exists. Data will be appended to existing table but all dependent metadata will be skipped due to table_exists_action of append
. . imported "SALES"."ORDERS_PART":"P_OLD"                5.523 KB       5 rows
Job "SALES"."SYS_IMPORT_FULL_01" successfully completed at Sun Oct 11 13:54:17 2026 elapsed 0 00:00:01



If we check the table again, the boundary is now below the registration SCN, and more importantly below the instantiation SCN of the live data !



SQL> SELECT source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'SALES'
AND source_object_name = 'ORDERS_PART';

SOURCE_OBJECT_NAME INSTANTIATION_SCN
------------------ -----------------
ORDERS_PART                189594418

1 row selected.



This means that a replicat using instantiation filtering will not filter the transactions which happened before the first import. If we add the replicat in the adminclient, and start it:



OGG (http://localhost:7810 ogg_test_01) 2> DBLOGIN USERIDALIAS oggadmin_pdb2 DOMAIN OracleGoldenGate
Successfully logged into database PDB2.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb2@CDB02/PDB2) 3> ADD REPLICAT REPPT, INTEGRATED, EXTTRAIL pt, CHECKPOINTTABLE OGGADMIN.CHECKPOINT
2026-10-11T13:54:19Z  INFO    OGG-08100  Integrated Replicat added.

OGG (http://localhost:7810 ogg_test_01 as oggadmin_pdb2@CDB02/PDB2) 4> START REPLICAT REPPT
2026-10-11T13:54:19Z  INFO    OGG-00975  Replicat group REPPT starting.
2026-10-11T13:54:19Z  INFO    OGG-15445  Replicat group REPPT started.



The replicat reads the instantiation SCN 189594418 from the target. It is now older than the live data export, so the transactions that export already contains are no longer filtered, and the replicat fails on the first trail record:



OGG (http://localhost:7810 ogg_test_01) 2> INFO REPLICAT REPPT

Replicat   REPPT     Last Started 2026-10-11 13:54   Status ABENDED
INTEGRATED
Checkpoint Lag       00:00:00 (updated 00:00:19 ago)
Log Read Checkpoint  File pt000000000
                     First Record  RBA 0
Encryption Profile   LocalWallet



The replicat report shows the boundary and the error:



2026-10-11 13:54:25  INFO    OGG-10155  Instantiation CSN filtering is enabled on table SALES.ORDERS_PART at CSN 189,594,418.
2026-10-11 13:54:31  WARNING OGG-02544  Unhandled error (ORA-00001: unique constraint (.) violated
ORA-00001: unique constraint (SALES.SYS_C0010450) violated) while processing the record at SEQNO 0, RBA 1793 in Integrated mode. REPLICAT will retry in Direct mode.



1001 and 1002 were already on the target from the live-data import, but their commit CSNs are now above the boundary.



Conclusion




instantiation_scn is per table, not per partition. The last impdp will decide the boundary being used by instantiation filtering.



impdp overwrites it unconditionally, with no warning.



When using instantiation filtering, always import the dump which should contain the boundary last.



Keep in mind that, depending on the context of your real replication, another instantiation method might be needed. Foreign keys, DDL replication, or many aspects a GoldenGate replication might need to address, were not covered in this blog.

L’article Import order matters for GoldenGate instantiation filtering est apparu en premier sur dbi Blog.



Removing instantiation filtering from a GoldenGate replicat
Julien Delattre — Mon, 12 Oct 2026 06:59:00 +0000

In a recent blog, I explained how instantiation filtering works. DBOPTIONS ENABLE_INSTANTIATION_FILTERING makes a replicat discard any record whose commit CSN is at or below a table’s instantiation CSN. It applies everything above it. This replicat parameter should be kept during the whole initial load process.



At some point the replicat has processed past the instantiation boundary for every table, and the filter has nothing left to do. Let’s answer the subsequent and very practical question: how to confirm, before editing the parameter file, that the replicat has cleared the boundary for every table it maps?



Which SCN should I check ?



To summarize what needs to be checked: it is safe to remove DBOPTIONS ENABLE_INSTANTIATION_FILTERING once the replicat last applied CSN is greater than the instantiation CSN of every table it maps.



To answer this question, you have two sources of information:




The per-table boundary, stored in dba_apply_instantiated_objects, with one row per source object.



The replicat last applied CSN, stored in the checkpoint table in the log_csn column.




SQL check



Read the boundaries first:



SQL> SELECT source_database, source_object_owner, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
ORDER BY instantiation_scn DESC;

SOURCE_DATABASE SOURCE_OBJECT_OWNER SOURCE_OBJECT_NAME INSTANTIATION_SCN
--------------- ------------------- ------------------ -----------------
PDB1            APP_PDB1            SALES                       52642820
PDB1            APP_PDB1            ORDERS                      52642649



Then read the replicat last applied CSN from its checkpoint table:



SELECT group_name, log_csn FROM oggadmin.checkpoint WHERE group_name = 'REP1';



You can safely remove ENABLE_INSTANTIATION_FILTERING when log_csn is greater than the highest instantiation_scn among the tables it maps. A one-shot verdict, scoped to a single source database:



SELECT 'REP1' AS group_name,
c.log_csn,
MAX(o.instantiation_scn) AS max_boundary,
CASE WHEN c.log_csn > MAX(o.instantiation_scn) THEN 'SAFE TO REMOVE' ELSE 'NOT YET' END AS verdict
FROM dba_apply_instantiated_objects o
LEFT JOIN oggadmin.checkpoint c ON c.group_name = 'REP1'
WHERE o.source_database = 'PDB1'
GROUP BY c.log_csn;



Before a replicat starts for the first time, log_csn is NULL and the verdict is NOT YET:



GROUP_NAME LOG_CSN MAX_BOUNDARY VERDICT
---------- ------- ------------ -------
REP1                   52642820 NOT YET



A replicat may map more than one source database, or only a subset of the instantiated objects. Then narrow the join to the objects applied.



WARNING: A replicat that has never started has no checkpoint row at all, so log_csn returns nothing. Treat that as “not safe”: there is no applied position, so it cannot have cleared anything. The verdict query above handles this case. It starts from the instantiated objects and left joins the checkpoint table. A missing row gives a NULL log_csn, and the verdict falls to NOT YET instead of the query returning no row at all.



After some time, once the replicat catches up with the initial load, the same query returns:



GROUP_NAME LOG_CSN  MAX_BOUNDARY VERDICT
---------- -------- ------------ --------------
REP1       52643651     52642820 SAFE TO REMOVE



You can now delete the DBOPTIONS ENABLE_INSTANTIATION_FILTERING parameter and restart your replicat.



adminclient check



From the adminclient, INFO REPLICAT REP1, DETAIL reports the applied CSN without using sqlplus:



OGG> INFO REPLICAT REP1, DETAIL
...
Last Committed Transaction CSN value: 52643651



Compare that number against the instantiation_scn from the view exactly as above.



REST API check



The CSN is reachable over the REST API, just not from a GET endpoint. You need to execute a command against the replicat using the POST /services/{version}/replicats/{replicat}/command endpoint. Using execute_command_replicat in the oggrestapi Python client:



from oggrestapi import OGGRestAPI

client = OGGRestAPI(url="http://localhost:7810", username="ogg", password="ogg")

resp = client.execute_command_replicat("REP1", data={"command": "INFO", "arguments": "DETAIL"})
output = "".join(r["reply"])
print(output)



Replicat   REP1      Last Started 2026-09-20 13:29   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:02 ago)
Process ID           102660
Log Read Checkpoint  File aa000000002
                     2026-09-20 13:30:17.000000  RBA 18926
Encryption Profile   LocalWallet

Current Log BSN value: 52643543

Last Committed Transaction CSN value: 52646310

  Extract Source                          Begin             End

  aa000000002                             2020-01-01 00:00  2026-09-20 13:30:17.00
  aa000000000                             * Initialized *   2020-01-01 00:00:00.00
  aa000000000                             * Initialized *   First Record



To be truly automated, Last Committed Transaction CSN value has to be parsed out:



import re

match = re.search(r"Last Committed Transaction CSN value: (\d+)", output)
applied_csn = int(match.group(1))
print(applied_csn)



52646310



Information in the report file



When starting a replicat during an initial load, the report file is filled with the following lines:



OGG-10155  Instantiation CSN filtering is enabled on table PDB1.APP_PDB1.ORDERS at CSN 52,642,649.
OGG-10185  Instantiation CSN filtering on table PDB1.APP_PDB1.ORDERS has started at CSN 52642649.
OGG-10186  Instantiation CSN filtering on table PDB1.APP_PDB1.ORDERS has ended, now passing transactions starting at CSN 52642649.




If the trail the replicat reads on that start contains records below a boundary, it filters them, and these lines appear.



If the trail begins at or after the boundary, nothing is filtered and no line appears at all.




Performance impact of leaving ENABLE_INSTANTIATION_FILTERING



When migrating a database online with GoldenGate, you want your replicat to catch up quickly. I tested whether keeping ENABLE_INSTANTIATION_FILTERING in the parameter file had any effect on the lag of a replicat. I found no significant statistical evidence of this.



Summary




ENABLE_INSTANTIATION_FILTERING is safe to remove when the replicat log_csn (last applied CSN) is above the instantiation_scn of every table it maps.



Get the applied CSN from oggadmin.checkpoint.log_csn (sqlplus), INFO REPLICAT REP1, DETAIL (adminclient), or execute_command_replicat("REP1", data={"command": "INFO", "arguments": "DETAIL"}) over REST, which returns the same information.



The OGG-10155/10185/10186 report lines appear only when the replicat filters records on that start.

L’article Removing instantiation filtering from a GoldenGate replicat est apparu en premier sur dbi Blog.



GoldenGate 26ai AutoSchema TYPEMAP: overriding the default datatype mapping
Julien Delattre — Thu, 08 Oct 2026 06:20:00 +0000

In my blog about the new automatic schema evolution feature in GoldenGate 26ai, I was replicating the following table from Oracle to PostgreSQL:



CREATE TABLE autosch.t1 (
    id NUMBER PRIMARY KEY,
    name VARCHAR2(50),
    amount NUMBER(10,2),
    created DATE DEFAULT SYSDATE,
    note VARCHAR2(20) DEFAULT 'added'
);



The replicat created a PostgreSQL table from an Oracle one during an initial load. It worked, but one choice was not mine: the NUMBER primary key became a varchar(50). Automatic Schema Evolution takes its datatypes from a default mapping, and the TYPEMAP option is how you override it.



Automatic schema evolution is a preview feature in GoldenGate 26ai: its syntax, messages and behavior can change before it becomes generally available, so the results below apply to the 23.26.3 release I tested.



Where the default mapping comes from



Each GoldenGate 26ai home ships the default mappings as one JSON file per source database and per target database. They are in $OGG_HOME/lib/utl/autoschema/MappingJSON, where MappingGenerator.py combines a source and a target file. For this example, the files are AutoSchemaOracleSourceMappings.json and AutoSchemaPostgreSQLTargetMappings.json.



Reading the two JSON files for an Oracle source and a PostgreSQL target, the default mappings that matter for the example table are:



Oracle source type PostgreSQL target type
number(precision,scale) decimal(precision,scale)
number varchar(precision), if the source data length is at most 10485760
number text, if the value is still too large to be accommodated
date timestamp(precision)



A NUMBER without precision maps to varchar, and a NUMBER(p,s) maps to decimal(p,s). This is why the key of my source table did not become a number.



For each test below, I drop autosch.t1 on PostgreSQL and start a new replicat, always named REPTM, on the same file.



Overriding one type



AUTOSCHEMAOPTIONS TYPEMAP must be written on a separate line, next to DDL AUTOSCHEMA INCLUDE ALL. The source type and the target type are separated by an equal sign. The option maps every occurrence of the source type to the given target type. Both types must be enclosed in single quotes, otherwise the replicat abends with OGG-30694:



REPLICAT REPTM
TARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate
DDL AUTOSCHEMA INCLUDE ALL
AUTOSCHEMAOPTIONS TYPEMAP 'number' = 'bigint'
MAP AUTOSCH.*, TARGET AUTOSCH.*;



The replicat report logs that the override was read:



2026-09-19T15:23:47.078+0000  INFO    OGG-30632  Oracle GoldenGate Delivery for PostgreSQL, REPTM.prm:  AutoSchemaOptions TypeMap is used, TypeNameMap: number -> bigint.



The table created in PostgreSQL, seen with \d autosch.t1 in psql, now shows a bigint as primary key



ogg_test_pg=# \d autosch.t1
                            Table "autosch.t1"
 Column  |              Type              | Collation | Nullable | Default
---------+--------------------------------+-----------+----------+---------
 id      | bigint                         |           | not null |
 name    | character varying(50)          |           |          |
 amount  | numeric(10,2)                  |           |          |
 created | timestamp(0) without time zone |           |          |
 note    | character varying(20)          |           |          |
Indexes:
    "t1_pkey" PRIMARY KEY, btree (id)



The amount column type did not change, since 'number' matches the source type NUMBER without precision. NUMBER(10,2) is another source type, and is not affected by the TYPEMAP instruction.



Mapping several types with AUTOSCHEMAOPTIONS



When mapping multiple types, each mapping needs a dedicated AUTOSCHEMAOPTIONS line:



DDL AUTOSCHEMA INCLUDE ALL
AUTOSCHEMAOPTIONS TYPEMAP 'number' = 'bigint'
AUTOSCHEMAOPTIONS TYPEMAP 'date' = 'date'
AUTOSCHEMAOPTIONS TYPEMAP 'number(10,2)' = 'real'



Every entry is logged separately:



2026-09-19T16:29:07.403+0000  INFO    OGG-30632  Oracle GoldenGate Delivery for PostgreSQL, REPTM.prm:  AutoSchemaOptions TypeMap is used, TypeNameMap: date -> date.
2026-09-19T16:29:07.403+0000  INFO    OGG-30632  Oracle GoldenGate Delivery for PostgreSQL, REPTM.prm:  AutoSchemaOptions TypeMap is used, TypeNameMap: number -> bigint.
2026-09-19T16:29:07.403+0000  INFO    OGG-30632  Oracle GoldenGate Delivery for PostgreSQL, REPTM.prm:  AutoSchemaOptions TypeMap is used, TypeNameMap: number\(10,2\) -> real.



And this is the resulting table:



 Column  |         Type          | Collation | Nullable | Default
---------+-----------------------+-----------+----------+---------
 id      | bigint                |           | not null |
 name    | character varying(50) |           |          |
 amount  | real                  |           |          |
 created | date                  |           |          |
 note    | character varying(20) |           |          |



All three overrides are applied. An interesting feature is that the replicat logs an OGG-03056 warning about the target column being smaller than the source column:



2026-09-19T16:29:07.419+0000  WARNING OGG-03056  Oracle GoldenGate Delivery for PostgreSQL, REPTM.prm:  Source table AUTOSCH.T1 column CREATED data size exceeds the maximum target table autosch.t1 column created size. Automatic truncation is enabled for all tables/columns without further warnings.



As expected, mapping DATE to a PostgreSQL date loses the time part, and it can be seen in the target table:



 id | name  | amount |  created   | note
----+-------+--------+------------+-------
  1 | row 1 |  10.25 | 2026-09-19 | added
  2 | row 2 |   20.5 | 2026-09-19 | added



An Oracle DATE has a time, so the default timestamp(0) mapping is the right one.



AUTOSCHEMAOPTIONS at the MAP level



The same option can be set on a MAP statement, between parentheses. It then only applies to the tables of that MAP statement instead of the whole replicat:



MAP AUTOSCH.*, TARGET AUTOSCH.*, AUTOSCHEMAOPTIONS (TYPEMAP 'number' = 'bigint');



2026-09-19T16:29:33.344+0000  INFO    OGG-06506  Oracle GoldenGate Delivery for PostgreSQL, REPTM.prm:  Wildcard MAP resolved (entry AUTOSCH.*): MAP "AUTOSCH"."T1", TARGET AUTOSCH."T1", AUTOSCHEMAOPTIONS (TYPEMAP 'number' = 'bigint').
2026-09-19T16:29:33.344+0000  INFO    OGG-30632  Oracle GoldenGate Delivery for PostgreSQL, REPTM.prm:  AutoSchemaOptions TypeMap is used, TypeNameMap: number -> bigint.



The table has a bigint key again. In this case, the other number columns outside of the MAP statement would keep the default varchar(50) mapping.



Remapping a single column



To change a single column, write the column name on the left side of the equal sign, instead of specifying the source type. The two forms work, first with the full name of the column:



AUTOSCHEMAOPTIONS TYPEMAP AUTOSCH.T1.NAME = 'text'



And at the MAP level, with the column name alone:



MAP AUTOSCH.T1, TARGET AUTOSCH.T1, AUTOSCHEMAOPTIONS (TYPEMAP NAME = 'text');



Both give the same table, with only name changed into text:



 Column  |              Type              | Collation | Nullable | Default
---------+--------------------------------+-----------+----------+---------
 id      | character varying(50)          |           | not null |
 name    | text                           |           |          |
 amount  | numeric(10,2)                  |           |          |
 created | timestamp(0) without time zone |           |          |
 note    | character varying(20)          |           |          |



To remap several columns on the same MAP, separate the mappings with commas inside the parentheses, and write TYPEMAP only once:



MAP AUTOSCH.T1, TARGET AUTOSCH.T1, AUTOSCHEMAOPTIONS (TYPEMAP NAME = 'text', NOTE = 'text');



 Column  |              Type              | Collation | Nullable | Default
---------+--------------------------------+-----------+----------+---------
 id      | character varying(50)          |           | not null |
 name    | text                           |           |          |
 amount  | numeric(10,2)                  |           |          |
 created | timestamp(0) without time zone |           |          |
 note    | text                           |           |          |



A type and a column can be mixed in the same list. For example, AUTOSCHEMAOPTIONS (TYPEMAP 'number' = 'bigint', NAME = 'text') gives a bigint key and a text name.



To summarize




The default mapping files are located in $OGG_HOME/lib/utl/autoschema/MappingJSON. Check them before letting a replicat create tables. A NUMBER without precision becomes a varchar on PostgreSQL, for instance.



The override syntax is AUTOSCHEMAOPTIONS TYPEMAP 'source_type' = 'target_type'. Use an equal sign, both types in single quotes, and one mapping per line.



A source type is matched as written. An override on 'number' does not change a NUMBER(10,2) column, which needs a separate 'number(10,2)' entry.



On a MAP, put the option between parentheses to limit it to those tables. For one column, use AUTOSCH.T1.NAME = 'text' globally or NAME = 'text' on the MAP.



Pay attention to OGG-03056 warnings: a target type smaller than the source, like DATE to date, truncates the data without stopping the initial load.

L’article GoldenGate 26ai AutoSchema TYPEMAP: overriding the default datatype mapping est apparu en premier sur dbi Blog.



GoldenGate AI Service bug confirmed in the Maximum Input Characters setting
Julien Delattre — Tue, 06 Oct 2026 05:25:17 +0000

In a previous blog, I noted that there might be a bug with the Maximum Input Characters setting in GoldenGate 26ai AI Service. The bug was confirmed by Oracle, so let’s see what it is exactly.



Bug found in GoldenGate 26ai AI Service



Maximum Input Characters is a setting in the AI Service. You can set it when registering a new model in the web UI.







In the Oracle documentation, the parameter is described as a cap on how much text is sent to the embedding model before it leaves GoldenGate. This ensures that an @AISERVICE mapping cannot send more than intended, and does not reach a token limit, or increase your consumption.



If this setting worked, a model with Maximum Input Characters set to 1 should truncate any input to a single character before calling the AI Service. This is not what I found when testing it.



Proof of the bug



Model registration



I registered two AI Service models against the same Gemini provider and the same remote model (gemini-embedding-001). They differ only in Maximum Input Characters: one set to 1000, the other to 1.











If I query both models with the REST API, I can see the settings properly saved, in limits.maxInputCharacters:



{
    "id": "gemini_embed_max1000",
    "name": "gemini-embedding-max1000",
    "type": "remote",
    "enabled": true,
    "loaded": false,
    "description": "Model with 1000 character limit",
    "capabilities": [
        "embed"
    ],
    "providerId": "gemini",
    "remoteModelName": "gemini-embedding-001",
    "parameters": {},
    "limits": {
        "maxInputCharacters": 1000
    }
}



{
    "id": "gemini_embed_max1",
    "name": "gemini-embedding-max1",
    "type": "remote",
    "enabled": true,
    "loaded": false,
    "description": "Model with 1 character limit",
    "capabilities": [
        "embed"
    ],
    "providerId": "gemini",
    "remoteModelName": "gemini-embedding-001",
    "parameters": {},
    "limits": {
        "maxInputCharacters": 1
    }
}



Replicat used in the test



I built an EXTAI/REPAI pair between PDB1.APP_PDB1.PRODUCTS on the source and PDB26.APP_PDB26.PRODUCTS on the target. Its COLMAP maps the description column through three separate @AISERVICE calls into three different VECTOR(3072, FLOAT32) columns:



MAP PDB1.APP_PDB1.PRODUCTS, TARGET APP_PDB26.PRODUCTS,
COLMAP (
    USEDEFAULTS,
    desc_vector_max1000 = @AISERVICE(embed, 'gemini_embed_max1000', description),
    desc_vector_max1000_run2 = @AISERVICE(embed, 'gemini_embed_max1000', description),
    desc_vector_max1 = @AISERVICE(embed, 'gemini_embed_max1', description));



The first two calls use the same model (gemini_embed_max1000). This is to show the baseline argument that the same input, embedded with the same model twice, produce the same vector. The third call uses the 1 character model, to test the bug.



Baseline and embedding noise



The truncation is only relevant if identical inputs reliably produce identical output. Before comparing vectors across models, I first confirmed the embedding had no noise, by inserting the same 100 character description into two source rows and let both flow through the pipeline:



INSERT INTO app_pdb1.products (id, name, description) VALUES (101, 'AI Service Max Input Chars Test Row 1', 'GoldenGate 26ai AI Service test row for comparing embeddings across the max1000 and max1 test models');
INSERT INTO app_pdb1.products (id, name, description) VALUES (102, 'AI Service Max Input Chars Test Row 2', 'GoldenGate 26ai AI Service test row for comparing embeddings across the max1000 and max1 test models');
COMMIT;



Then, I compared the gemini_embed_max1000 vector between the two rows. I also compared the two separate @AISERVICE calls to the same model within row 101 itself. Both come back with a cosine distance of 0:



SQL> SELECT VECTOR_DISTANCE(a.desc_vector_max1000, b.desc_vector_max1000, COSINE) dist_101_vs_102_same_input
FROM app_pdb26.products a, app_pdb26.products b
WHERE a.id = 101
AND b.id = 102;

DIST_101_VS_102_SAME_INPUT
--------------------------
                         0




The conclusion is that gemini-embedding-001 is deterministic for identical input. Now, if the max1 vector is identical to the max1000 vector, we can rule out embedding noise.



Does the 1 character limit change anything?



With the same transaction, let’s look at the two different @AISERVICE calls, against a model capped at 1000 characters and one capped at 1:



SQL> SELECT id, VECTOR_DISTANCE(desc_vector_max1000, desc_vector_max1, COSINE) dist_max1000_vs_max1, VECTOR_DISTANCE(desc_vector_max1000, desc_vector_max1000_run2, COSINE) dist_max1000_vs_rerun
FROM app_pdb26.products
WHERE id IN (101, 102);

ID  DIST_MAX1000_VS_MAX1 DIST_MAX1000_VS_RERUN
--- -------------------- ---------------------
101                    0                     0
102                    0                     0



On both models, the distance between the resulting vectors is zero. If the Maximum Input Characters were enforced, the vectors should be different between both models. This proves that the Maximum Input Characters setting saved as 1 had no effect on what was sent to Gemini.



GoldenGate even has a documented warning for a situation where the input would exceed the limit. OGG-30677 is defined as @AISERVICE source column {0} contains {1} characters, exceeding model {2}'s maximum input limit of {3} characters. But in my case, the warning never appeared in the log files.



What can break?



I added a fourth @AISERVICE call to the same replicat, mapping a CLOB column (big_description) through the 1000 character model. I then tried pushing progressively larger inputs.



With 100000 characters, the countTokens endpoint reports this input at 23679 tokens, way more than the documented inputTokenLimit of gemini-embedding-001. It applied without any error and produced a real 3072 dimension vector, distinct from every other vector in this blog.



SQL> SELECT id, VECTOR_DIMS(desc_vector_bigtest) dims
FROM app_pdb26.products
WHERE id = 103;

ID  DIMS
--- ----
103 3072



Here, we can see that even the documented token limit of your provider might not stop the AI Service to work.



Reaching quota limit



On top of the per-request token limit, depending on your billing settings, you might have a usage quota on the API key. A request can be rejected by Gemini, and this error is raised in AIService.log:



{
    "error": {
        "code": 429,
        "message": "You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https://ai.dev/rate-limit. ",
        "status": "RESOURCE_EXHAUSTED"
    }
}



And in this case, the replicat abends with the following error:



2026-09-27 08:22:21  WARNING OGG-30679  Response from EMBED endpoint using model gemini_embed_max1000 returned error: code REMOTE_INFERENCE_FAILED, message 'HTTP 429 - Too Many Requests: {
  "error": {
    "code": 429,
    "message": "You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https://ai.dev/rate-limit. ",
    "status": "RESOURCE_EXHAUSTED"
  }
}
'.

2026-09-27 08:22:21  WARNING OGG-01431  Canceled grouped transaction on PDB26.APP_PDB26.PRODUCTS, Mapping error.
2026-09-27 08:22:27  ERROR   OGG-01668  PROCESS ABENDING.



Summary



Maximum Input Characters does not protect a replicat from an oversized @AISERVICE mapping. Because of this, the only real limit to your embeddings in GoldenGate is a usage quota. This can affect your replication, whether you rely on the setting for functional truncation or to lower your costs. Until the bug is fixed, be careful when using the AI Service!
L’article GoldenGate AI Service bug confirmed in the Maximum Input Characters setting est apparu en premier sur dbi Blog.



GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load
Julien Delattre — Mon, 05 Oct 2026 05:00:44 +0000

For as long as I have used GoldenGate, an initial load had one prerequisite: the target tables must already exist. Data Pump takes care of it between two Oracle databases. For anything else, you write the CREATE TABLE statements yourself, with the datatypes you choose, or choose another initial load method. The Automatic Schema Evolution feature launched in GoldenGate 26ai promises to “automatically detect and propagate supported schema changes as part of the replication flow”. I wanted to see it work, so I tried it from an Oracle 19c PDB to a PostgreSQL database.



And it works. The replicat creates the missing table itself, with a default datatype mapping, and loads the rows in the target.



Automatic schema evolution is a preview feature in GoldenGate 26ai: its syntax, messages and behavior can change before it becomes generally available, so the results below apply to the 23.26.3 release I tested.



How it works



The feature replicates table structure changes between databases of the same or of different types. The exception is Oracle to Oracle, where regular DDL replication is the solution. It also creates tables during an initial load. The replicat must be 26ai or higher, but the extract writing the trail can be 19c or higher. On a live trail, the replicat also adds a column that appears on the source. The documentation lists ADD COLUMN as the one supported ALTER TABLE. But an initial load never alters an existing table: it leaves it alone or, with OPTYPE RECREATE, drops and recreates it.



The replicat does not need anything from the source database. It builds the CREATE TABLE statement from the Table Definition Record (TDR) that GoldenGate already writes in the trail file.



AUTOSCHEMA is a replicat-only option of DDL: the DDL parameter of the extract does not accept it. I put DDL AUTOSCHEMA INCLUDE ALL in the extract’s parameter file. The extract abends at startup with the same parsing error as an unrecognized keyword:



2026-09-26T05:54:27Z  ERROR   OGG-10151  (EXTPGL.prm) line 3: Parsing error, parameter [DDL] has unrecognized keyword or extra value "AUTOSCHEMA".



That makes sense given what the feature does. It creates missing tables on the target, and the extract never touches the target database.



The setup




Source: Oracle 19c, PDB1, schema AUTOSCH, table AUTOSCH.T1 with 5 rows, managed by the 26ai deployment ogg_test_01 in GoldenGate 23.26.3.0.0.



Target: PostgreSQL 16, database pgstore, an empty schema autosch, managed by a separate deployment ogg_pg_01 from GoldenGate for PostgreSQL 23.26.3.0.1.




The source table:



CREATE TABLE autosch.t1 (
    id NUMBER PRIMARY KEY,
    name VARCHAR2(50),
    amount NUMBER(10,2),
    created DATE DEFAULT SYSDATE
);



For the initial load, on the ogg_test_01 deployment, EXTPGL is added as a SOURCEISTABLE extract.



OGG (http://localhost:7810 ogg_test_01) 2> DBLOGIN USERIDALIAS pdb1 DOMAIN OracleGoldenGate
Successfully logged into database PDB1.

OGG (http://localhost:7810 ogg_test_01 as pdb1@CDB01/PDB1) 3> ADD EXTRACT EXTPGL, SOURCEISTABLE
2026-09-26T05:53:26Z  INFO    OGG-08100  Extract added.

OGG (http://localhost:7810 ogg_test_01 as pdb1@CDB01/PDB1) 4> EDIT PARAMS EXTPGL
2026-09-26T05:53:26Z  INFO    OGG-10183  Parameter file EXTPGL.prm passed validity check.

OGG (http://localhost:7810 ogg_test_01 as pdb1@CDB01/PDB1) 5> VIEW PARAMS EXTPGL
EXTRACT EXTPGL
USERIDALIAS pdb1 DOMAIN OracleGoldenGate
EXTFILE p1 MEGABYTES 100 PURGE
TABLE AUTOSCH.T1;

OGG (http://localhost:7810 ogg_test_01 as pdb1@CDB01/PDB1) 6> START EXTRACT EXTPGL
2026-09-26T05:53:26Z  INFO    OGG-00975  Extract group EXTPGL starting.
2026-09-26T05:53:26Z  INFO    OGG-15426  Extract group EXTPGL started.



The extract report confirms the 5 rows went out to the file:



Report at 2026-09-26 05:53:26 (activity since 2026-09-26 05:53:26)

Output to p1:

From table AUTOSCH.T1:
       #                   inserts:         5
       #                   updates:         0
       #                   deletes:         0
       #                   upserts:         0
       #                  discards:         0



The target is a separate deployment, ogg_pg_01, from the Oracle GoldenGate for PostgreSQL binaries. A distribution path delivers the p1 trail from ogg_test_01 to ogg_pg_01. The replicat there, REPPGL, is added straight against the trail name, with EXTSEQNO 0 telling it where to start reading. The checkpoint table is oggadmin.checkpoint:



OGG (http://localhost:7859 ogg_pg_01) 2> DBLOGIN USERIDALIAS pgalias DOMAIN OracleGoldenGate
Successfully logged into database.

OGG (http://localhost:7859 ogg_pg_01 as pgalias@pgstore) 3> ADD REPLICAT REPPGL, EXTFILE p1, EXTSEQNO 0, CHECKPOINTTABLE oggadmin.checkpoint
2026-09-26T09:14:42Z  INFO    OGG-30509  Connected to database server using ODBC DSN: ogg_pg_01 with SSLMODE 'disable'
2026-09-26T09:14:42Z  INFO    OGG-08100  Replicat added.



Baseline: without the feature



REPPGL’s parameter file starts with just a MAP, no DDL clause at all:



REPLICAT REPPGL
TARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate
MAP AUTOSCH.*, TARGET AUTOSCH.*;



With this replicat, the initial load stops on the first table, as it always did:



2026-09-26 05:52:11  WARNING OGG-00869  Could not retrieve definition for table AUTOSCH.T1.
2026-09-26 05:52:11  ERROR   OGG-00199  Table AUTOSCH.T1 does not exist in target database.



Enabling automatic schema evolution



The feature is called AUTOSCHEMA, but as a parameter on a line by itself, it is rejected:



2026-09-26T05:52:30Z  ERROR   OGG-10141  (REPPGL.prm) line 3 column 1: Parsing error, value "AUTOSCHEMA" syntax error.
2026-09-26T05:52:30Z  ERROR   OGG-10184  Parameter file REPPGL.prm failed validity check.



AUTOSCHEMA is an option of the DDL parameter, followed by the usual INCLUDE and EXCLUDE clauses:



REPLICAT REPPGL
TARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate
DDL AUTOSCHEMA INCLUDE ALL
MAP AUTOSCH.*, TARGET AUTOSCH.*;



The replicat starts and announces the feature, then finds the table missing and creates it:



2026-09-26 05:52:41  INFO    OGG-30684  The Automatic Schema Evolution feature is enabled. Please refer to the GoldenGate documentation for the supported operations, the datatype mappings, and the corresponding parameter options to enable/disable/override the functionality.
2026-09-26 05:52:41  WARNING OGG-00869  Could not retrieve definition for table AUTOSCH.T1.
2026-09-26 05:52:41  WARNING OGG-30633  Table AUTOSCH.T1 does not exist in target database, AutoSchema will attempt to create the missing table.
2026-09-26 05:52:41  INFO    OGG-02756  The definition for table AUTOSCH.T1 is obtained from the trail file.



The same warning OGG-00869 as in the baseline is still there. But it is followed by OGG-30633 and by OGG-02756, which shows that the definition comes from the trail file. In PostgreSQL:



pgstore=# \d autosch.t1
                            Table "autosch.t1"
 Column  |              Type              | Collation | Nullable | Default
---------+--------------------------------+-----------+----------+---------
 id      | character varying(50)          |           | not null |
 name    | character varying(50)          |           |          |
 amount  | numeric(10,2)                  |           |          |
 created | timestamp(0) without time zone |           |          |
Indexes:
    "t1_pkey" PRIMARY KEY, btree (id)

pgstore=# select * from autosch.t1 order by 1;
 id | name  | amount |       created
----+-------+--------+---------------------
 1  | row 1 |  10.25 | 2026-09-26 05:43:53
 2  | row 2 |  20.50 | 2026-09-26 05:43:53
 3  | row 3 |  30.75 | 2026-09-26 05:43:53
 4  | row 4 |  41.00 | 2026-09-26 05:43:53
 5  | row 5 |  51.25 | 2026-09-26 05:43:53
(5 rows)



The table was created, the primary key too, and the 5 rows were loaded. This is the default datatype mapping at work:



Oracle column PostgreSQL column
ID NUMBER (primary key) character varying(50)
NAME VARCHAR2(50) character varying(50)
AMOUNT NUMBER(10,2) numeric(10,2)
CREATED DATE timestamp(0) without time zone



The primary key is the surprise: a NUMBER without precision becomes a varchar on PostgreSQL. Check the mapping before you let a replicat create tables that an application will query. It can be overridden, which is the subject of another post.



What happens when the table already exists



Between two loads, I added a column to the source table (ALTER TABLE autosch.t1 ADD (note VARCHAR2(20) DEFAULT 'added')). I also inserted a stray row in the PostgreSQL table. Then I reran EXTPGL and pointed the same REPPGL, still with DDL AUTOSCHEMA INCLUDE ALL, at the new file. It did not change the existing table:



2026-09-26 05:53:26  INFO    OGG-06511  Using following columns in default map by name: id, name, amount, created.
2026-09-26 05:53:26  WARNING OGG-01004  Canceled grouped transaction on table autosch.t1. Database error 3505685, (SQLState = 23000 SQLError = 3,505,685 SQLErrorHex = 00357e15 SQLErrorText = [Oracle][ODBC PostgreSQL Wire Protocol driver][PostgreSQL]ERROR: VERROR; duplicate key value violates unique constraint "t1_pkey"(Detail Key (id)=(1) already exists.; sautosch; tt1; nt1_pkey; File nbtinsert.c; Line 666; Routine _bt_check_unique; )).
2026-09-26 05:53:26  ERROR   OGG-01296  Error mapping from AUTOSCH.T1 to autosch.t1.



The new source column NOTE is silently left out of the column mapping: an initial load does not alter an existing table. The load then abends on duplicate key value violates unique constraint "t1_pkey", as the rows are already there. So DDL AUTOSCHEMA INCLUDE ALL creates missing tables only.



The documentation says that for an initial load trail, DDL AUTOSCHEMA “automatically creates or replaces target tables”. It does not say how to get the replacement. The replicat binary has a RECREATE token, and it is a DDL operation type, so it goes in the INCLUDE filter:



DDL AUTOSCHEMA INCLUDE ALL OPTYPE RECREATE



Testing RECREATE



To see what RECREATE does, I prepare a PostgreSQL table that already exists. It has a column that is not on the source and a row that is not in the load:



CREATE TABLE autosch.t1 (
  id varchar(50) PRIMARY KEY,
  name varchar(50),
  amount numeric(10,2),
  created timestamp(0),
  legacy text
);
INSERT INTO autosch.t1 (id, name, legacy)
VALUES ('99', 'stray row', 'pre-existing');



The initial load is delivered the way the documentation describes it:




A SOURCEISTABLE extract writes the 5 rows of AUTOSCH.T1 to the extract file ci.



A distribution path sends ci to the receiver of the PostgreSQL deployment, as the trail di.



A replicat reads the trail di with DDLOPTIONS REPORT and an explicit MAP AUTOSCH.T1, TARGET AUTOSCH.T1;.




With DDL AUTOSCHEMA INCLUDE ALL, the replicat recognizes the initial load by itself. It builds a RECREATE operation from the table definition record, then excludes it: INCLUDE ALL does not cover that operation type.



2026-10-03 13:11:47  INFO    OGG-00489  DDL is of mapped scope, after mapping new operation [ /* AutoSchema */ create table "autosch"."t1" (ID varchar(50) not null, NAME varchar(50), AMOUNT decimal(10,2), CREATED timestamp(0), primary key(ID)) (size 150)].
2026-10-03 13:11:47  INFO    OGG-00488  DDL operation excluded [not included by any filter], optype [RECREATE], objtype [TABLE], objowner "autosch", objname "t1".



The 5 rows are loaded into the existing table, next to the stray row, and the legacy column is still there:



 id |   name    | amount |       created       |    legacy
----+-----------+--------+---------------------+--------------
 1  | row 1     |  10.25 | 2026-09-26 09:11:40 |
 2  | row 2     |  20.50 | 2026-09-26 09:11:40 |
 3  | row 3     |  30.75 | 2026-09-26 09:11:40 |
 4  | row 4     |  41.00 | 2026-09-26 09:11:40 |
 5  | row 5     |  51.25 | 2026-09-26 09:11:40 |
 99 | stray row |        |                     | pre-existing
(6 rows)



Second run with the RECREATE filter



The parameter file for this second run only differs from the previous one by the OPTYPE RECREATE filter:



REPLICAT REPPGL
TARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate
DDLOPTIONS REPORT
DDL AUTOSCHEMA INCLUDE ALL OPTYPE RECREATE
MAP AUTOSCH.T1, TARGET AUTOSCH.T1;



With this file and the same table reset, the replicat warns about what it is going to do, then drops the table:



2026-10-03 13:12:34  WARNING OGG-30687  The OPTYPE 'RECREATE' is specified with DDL AUTOSCHEMA option. Please note that the corresponding pre-existing tables will be attempted to be dropped and re-created, only when the REPLICAT is applying initial load trail files. In case of CDC trails, REPLICAT would attempt to create the tables, only when the corresponding tables do not exist already.
2026-10-03 13:12:34  INFO    OGG-00487  DDL operation included [INCLUDE ALL OPTYPE RECREATE], optype [RECREATE], objtype [TABLE], objowner "autosch", objname "t1".
2026-10-03 13:12:34  INFO    OGG-30640  Table autosch.t1 is dropped successfully.
2026-10-03 13:12:34  INFO    OGG-00484  Executing DDL operation.
2026-10-03 13:12:34  INFO    OGG-00483  DDL operation successful.



The table is recreated from the table definition record and loaded, and the legacy column and the stray row are gone.



                            Table "autosch.t1"
 Column  |              Type              | Collation | Nullable | Default
---------+--------------------------------+-----------+----------+---------
 id      | character varying(50)          |           | not null |
 name    | character varying(50)          |           |          |
 amount  | numeric(10,2)                  |           |          |
 created | timestamp(0) without time zone |           |          |
Indexes:
    "t1_pkey" PRIMARY KEY, btree (id)

 id | name  | amount |       created
----+-------+--------+---------------------
 1  | row 1 |  10.25 | 2026-09-26 09:11:40
 2  | row 2 |  20.50 | 2026-09-26 09:11:40
 3  | row 3 |  30.75 | 2026-09-26 09:11:40
 4  | row 4 |  41.00 | 2026-09-26 09:11:40
 5  | row 5 |  51.25 | 2026-09-26 09:11:40
(5 rows)



No parameter tells the replicat that it applies an initial load: a trail written by a SOURCEISTABLE extract is enough. I got the same drop and recreate in three setups. The replicat was added on the trail with EXTTRAIL, added with EXTFILE, or reading a copy of the raw extract file. On a CDC trail, RECREATE does not drop anything, as the warning says.



A wildcard MAP breaks RECREATE on PostgreSQL



The MAP of the previous test was explicit (MAP AUTOSCH.T1, TARGET AUTOSCH.T1;). The baseline of this post used MAP AUTOSCH.*, TARGET AUTOSCH.*;. I replaced it with the wildcard on the same table and the same trail, and nothing else changed:



REPLICAT REPPGL
TARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate
DDLOPTIONS REPORT
DDL AUTOSCHEMA INCLUDE ALL OPTYPE RECREATE
MAP AUTOSCH.*, TARGET AUTOSCH.*;



This time, the replicat never drops the table. There is no OGG-30640 in the report, and the CREATE TABLE that follows abends because the table is still there:



2026-10-03 13:17:02  INFO    OGG-06506  Wildcard MAP resolved (entry AUTOSCH.*): MAP "AUTOSCH"."T1", TARGET AUTOSCH."T1".
2026-10-03 13:17:02  INFO    OGG-00487  DDL operation included [INCLUDE ALL OPTYPE RECREATE], optype [RECREATE], objtype [TABLE], objowner "autosch", objname "T1".
2026-10-03 13:17:02  INFO    OGG-00484  Executing DDL operation.
2026-10-03 13:17:02  ERROR   OGG-00519  Fatal error executing DDL replication: error [Error code [6844183], [Oracle][ODBC PostgreSQL Wire Protocol driver][PostgreSQL]ERROR: VERROR; relation "t1" already exists(File heap.c; Line 1167; Routine heap_create_with_catalog; )], no error handler present.
2026-10-03 13:17:02  ERROR   OGG-30538  Fatal error executing DDL statement [ /* AutoSchema */ create table "autosch"."t1" (ID varchar(50) not null, NAME varchar(50), AMOUNT decimal(10,2), CREATED timestamp(0), primary key(ID))].



The first line of the report explains it. The wildcard is resolved from the table name in the trail, so the target becomes AUTOSCH."T1": the case of the source (uppercase on Oracle), and quoted. PostgreSQL stores an unquoted name in lowercase, so my existing table is t1, not "T1". The replicat looks for "T1" to drop it, finds nothing, and the CREATE TABLE that follows hits the real t1. To check this, I created the existing table in PostgreSQL as "T1" (quoted, so uppercase). Then I ran the same wildcard replicat: this time the drop works.



2026-10-03 13:27:14  INFO    OGG-06506  Wildcard MAP resolved (entry AUTOSCH.*): MAP "AUTOSCH"."T1", TARGET AUTOSCH."T1".
2026-10-03 13:27:14  INFO    OGG-00487  DDL operation included [INCLUDE ALL OPTYPE RECREATE], optype [RECREATE], objtype [TABLE], objowner "autosch", objname "T1".
2026-10-03 13:27:14  INFO    OGG-30640  Table autosch.T1 is dropped successfully.
2026-10-03 13:27:14  INFO    OGG-00483  DDL operation successful.



The names are matched exactly. With an explicit MAP AUTOSCH.T1, TARGET AUTOSCH."T1"; on a lowercase t1, the replicat created a second table "T1" and left t1 alone. Without quotes, the target of an explicit MAP is lowercased for PostgreSQL, which is why the first test dropped t1. So with RECREATE on PostgreSQL, the target name in the MAP must be spelled exactly like the existing table. Write one explicit MAP per table, unquoted for a lowercase table. The RECREATE parameter file with the explicit MAP above does exactly that.



Limitations




AUTOSCHEMA is not for Oracle-to-Oracle replication. Pointing the same DDL AUTOSCHEMA INCLUDE ALL replicat at an Oracle target instead of PostgreSQL abends immediately:
2026-09-26 05:54:11  ERROR   OGG-30624  AUTOSCHEMA is not allowed in an Oracle to Oracle replication scenario. Please use the DDL replication to control schema evolution.
Between two Oracle databases, regular DDL replication is still the standard tool for schema evolution, and a GoldenGate initial load still has no automatic way to create the target table.



The trail must be format 19.1 or higher with Table Definition Records.



UNMAPPED and OTHER scope are not valid with AUTOSCHEMA. Adding INCLUDE UNMAPPED (or INCLUDE OTHER) next to INCLUDE ALL parses fine, but the replicat rejects it at startup:
2026-09-26 07:12:06  ERROR   OGG-30689  The 'UNMAPPED' is not a valid DDL SCOPE to be used with Automatic Schema Evolution.




To summarize




Automatic schema evolution is enabled on the replicat with DDL AUTOSCHEMA INCLUDE ALL.



During an initial load from Oracle to PostgreSQL, it creates the missing table and its primary key from the Table Definition Record of the trail (OGG-30633). Then it loads the rows.



The datatypes come from a default mapping: check it first, as a NUMBER primary key became a varchar(50).



An initial load leaves an existing table alone. A column added on the source is not added on the target, and the rows are loaded into it.



DDL AUTOSCHEMA INCLUDE ALL OPTYPE RECREATE drops and recreates an existing table, only when the trail is an initial load trail (OGG-30640). INCLUDE ALL alone excludes that operation (OGG-00488).



Use one explicit MAP per table with RECREATE on PostgreSQL. A wildcard MAP looks for the table under the source name in quotes and misses a lowercase table. The CREATE TABLE then abends with relation "t1" already exists.



It is not available between two Oracle databases. Pointing it at an Oracle target from an Oracle source abends with OGG-30624. An Oracle-to-Oracle initial load still needs the target table to already exist, exactly as before.

L’article GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load est apparu en premier sur dbi Blog.

Command	Before the suspend	After the suspend
`INFO ALL`	`RUNNING`	`RUNNING`
`INFO EXT1`	`RUNNING`	`RUNNING`
`INFO EXT1 DETAIL`	`RUNNING`	`RUNNING`
`STATUS EXTRACT EXT1`	`RUNNING`	`RUNNING`
`SEND EXTRACT EXT1 STATUS`	`Recovery complete: At EOF`	`Recovery complete: Suspended, waiting to be resumed`

Oracle source type	PostgreSQL target type
`number(precision,scale)`	`decimal(precision,scale)`
`number`	`varchar(precision)`, if the source data length is at most 10485760
`number`	`text`, if the value is still too large to be accommodated
`date`	`timestamp(precision)`

Oracle column	PostgreSQL column
`ID NUMBER` (primary key)	`character varying(50)`
`NAME VARCHAR2(50)`	`character varying(50)`
`AMOUNT NUMBER(10,2)`	`numeric(10,2)`
`CREATED DATE`	`timestamp(0) without time zone`

Julien Delattre, auteur/autrice sur dbi Blog

applyOps and manual oplog replay for MongoDB PITR

What applyOps does

Batch problem: not every write is a separate oplog entry

applyOps rejects entries from a freshly restored collection

EJSON relaxed mode changes your data types

dropDatabase inside a replay window

Summary

GoldenGate captures TRUNCATE on a global temporary table and the replicat abends

Why global temporary table DDL is excluded

Setup

Workload on the source

What the extract does

What the replicat does

DDLOPTIONS for global temporary tables

NOAPPLYGLOBALTEMPTABLE on the replicat

CAPTUREGLOBALTEMPTABLE on the extract

Both options together

Which DDL statements are affected

Scope and truncate options do not change it

Answer from Oracle Support

Keeping the replicat running

Exclude the TRUNCATE by table name

Discard the ORA-00942 error

Summary

Retrieving GoldenGate logs, reports, and diagnostics with the REST API

Authenticating to the REST API

Service Manager logs

ggserr.log

adminclient.log: no REST endpoint

Report files (.rpt)

Diagnostics

Configuration files

Anatomy of an Enterprise Manager metric extension

Building a minimal metric extension

Exporting the metric extension

Adding a second column and a real environment variable

Adding an uploaded script

Repository-side metric extension

Import our first custom metric extension

How to detect a suspended GoldenGate extract

Extract status before SUSPEND

Suspending the extract

SEND EXTRACT STATUS shows the suspended state

Which command shows the suspend?

Getting the status with the REST API

With the oggrestapi Python client

With the requests module

Adding a lag check

A simpler check: OGG-01281 in the report

The full check in one script

What about replicats?

Summary

Import order matters for GoldenGate instantiation filtering

Standard scenario: importing old partitions first

Starting the extract

Exporting and importing the live data

Replicat with instantiation filtering

Wrong order: importing old partitions after

Conclusion

Removing instantiation filtering from a GoldenGate replicat

Which SCN should I check ?

SQL check

adminclient check

REST API check

Information in the report file

Performance impact of leaving ENABLE_INSTANTIATION_FILTERING

Summary

GoldenGate 26ai AutoSchema TYPEMAP: overriding the default datatype mapping

Where the default mapping comes from

Overriding one type

Mapping several types with AUTOSCHEMAOPTIONS

AUTOSCHEMAOPTIONS at the MAP level

Remapping a single column

To summarize

GoldenGate AI Service bug confirmed in the Maximum Input Characters setting

Bug found in GoldenGate 26ai AI Service

Proof of the bug

Model registration

Replicat used in the test

What `applyOps` does

`applyOps` rejects entries from a freshly restored collection

`EJSON` relaxed mode changes your data types

`dropDatabase` inside a replay window

`DDLOPTIONS` for global temporary tables

`NOAPPLYGLOBALTEMPTABLE` on the replicat

`CAPTUREGLOBALTEMPTABLE` on the extract

Exclude the `TRUNCATE` by table name

Discard the `ORA-00942` error

`ggserr.log`

`adminclient.log`: no REST endpoint

Report files (`.rpt`)

Extract status before `SUSPEND`

`SEND EXTRACT STATUS` shows the suspended state

With the `oggrestapi` Python client

With the `requests` module

A simpler check: `OGG-01281` in the report

`adminclient` check

Performance impact of leaving `ENABLE_INSTANTIATION_FILTERING`

Mapping several types with `AUTOSCHEMAOPTIONS`

`AUTOSCHEMAOPTIONS` at the `MAP` level

Testing `RECREATE`

Second run with the `RECREATE` filter

A wildcard `MAP` breaks `RECREATE` on PostgreSQL