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)

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 holds 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.

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.

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.

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:

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 carries 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.

This part is about putting it back: translating the views, rebuilding the keys and indexes under a Standard Edition licence that makes every build offline, and compressing 3.2 TB of heaps that turned out to be mostly empty space.

The logbook resumes at day 5.

Day 5. Four thousand views to convert

4,658 of the 4,784 views live in a single schema, and nobody needed all of them. We went through the list with the client first and kept the ones that actually matter to the business, which brought the scope down to about 710. SSMA converted around 600 of those on its own.

SSMA fails mostly on CONNECT BY, START WITH and SYS_CONNECT_BY_PATH. For some easy cases, DECODE to CASE and NVL handles it well, for the record. For more complex use case, we needed to find an automatic solution process. So first, we discussed with the client to know which view were critical and needed to be migrated. Then, with this list, we leveraged the power of AI to help us converting the remaining views based on the following workflow:

The workflow

SSMA converts what it can. The failures get extracted from dba_views into files. Then, and this is the step that changes the economics, they get classified by pattern in the Oracle source rather than one at a time by error message.

Translation itself was done in batches of one family at a time, outside production, on extracted files, with an AI assistant and a context file describing the type mapping decisions, the column types of the referenced tables and the target version. Then human review, tests against Oracle and finally, deployment.

The catalogue of families is the real deliverable. Eight of them closed the great majority of the cases:

And a word on the AI, since that is the part people ask about. No data ever left the environment: only the view definitions were processed, and every test against the live database was run by hand so we kept control of the process. We could have added MCP connectors and let a local model run the tests itself, but with the number of days allocated to the project and the small number of views left to fix, doing it manually was simpler. Around 85 percent of the views wanted by the client had already come through SSMA.

Day 6. Putting the indexes back and making the database smaller

Recovering what I had thrown away

The primary keys I dropped to load into heaps had left no trace on the SQL Server side. Nothing in sys.indexes, no disabled definition, nothing.

What Standard Edition costs

Index builds are offline and single-threaded. The table is locked for the duration, metadata reads queue behind it, but we managed to run 4 builds in parallel. SORT_IN_TEMPDB = OFF for the clustered builds. The sort covers the entire table, and 36 GB of tempdb was never going to hold a 900 GB sort.

Meanwhile percent_complete sits at 0 for the whole build, with the serene confidence of something that has never been asked to account for itself. It works for BACKUP DATABASE. It does not work here. Real progress lives in sys.dm_exec_query_profiles, operator by operator :

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT physical_operator_name, row_count, estimate_row_count,
       CAST(row_count*100.0/NULLIF(estimate_row_count,0) AS decimal(5,1)) AS pct
FROM sys.dm_exec_query_profiles WITH (NOLOCK)
WHERE session_id = <spid of the build> 
ORDER BY node_id;

Those are not three parallel counters. They are three sequential phases of one pipeline, and only one of them moves at a time. The scan reads the source table, and while it runs its percentage is the only honest progress figure available. The sort is a blocking operator: it cannot emit a single row until it has consumed all 31.9 million, so it stays at zero through the whole scan and then through the whole sort. That is the blind spot. Once the scan reaches 100 percent you get a long stretch where all three counters report nothing while the server works flat out, and if the sort spills to disk that stretch can outlast the other two phases combined. Index Insert starts moving only when the sort begins handing rows over, and it is the first number that means the end is actually in sight.

Why compress, and what it returned

On a read-only database, PAGE compression has no recurring write cost. You keep the read benefit and pay nothing back. The argument is rarely this clean.

Compression trades CPU for I/O, and on an archive that trade is one-sided. These pages are read rarely, and when they are, nothing heavy is competing for the processor, so the decompression cost lands on a machine with nothing better to do. What you get back is density: more rows per page, which means fewer reads to find the one row somebody asked for and more of the table sitting in memory at once.

The data was unusually well suited to it, for a reason worth spelling out. These tables carry roughly 200 numeric columns, mostly null, plus five nvarchar(200) aggregation labels that repeat endlessly. Here is the part that surprises people: a fixed-length numeric column that is NULL still occupies its full width in SQL Server. “Mostly null” saves nothing before compression. It is precisely why the heap was that large, and precisely what the page dictionary destroys.

The allocated space per row tells the story:

Three tables hold 2.7 TB of the 3.2 TB total. At around 4 KB of allocated space per row against an 8 KB page, the top two fit around two rows per page and waste most of what is left.

Then the first build, on 505,819,544 rows with a five-column primary key:

ALTER TABLE <TABLE6>
ADD CONSTRAINT PK_TABLE6 PRIMARY KEY CLUSTERED
    (<COLUMNS_NAME>)
WITH (DATA_COMPRESSION = PAGE, SORT_IN_TEMPDB = OFF);

117 GB to 30.7 GB. A ratio of 3.81.

Finally, as you can see above, more than 2.5 T have been reclaimed (datafiles were full with the heaps). Compression has made huge benefits and that means less data on disks, which means fewer pages to take in the buffer (less IO).

The script that puts everything back

Across every schema that is two cursors, one rebuilding the disabled indexes with compression and one re-enabling the foreign keys. It is driven by the same #Schemas table as the disable script in part 1:

SET NOCOUNT ON;
DECLARE @Execute bit = 0;   -- 0 = preview ; 1 = execute
  
DECLARE @cmd nvarchar(max);
DECLARE @n   int = 0;
  
DECLARE reb_cur CURSOR LOCAL FAST_FORWARD FOR
    SELECT N'ALTER INDEX ' + QUOTENAME(i.name)
         + N' ON ' + QUOTENAME(s.name) + N'.' + QUOTENAME(t.name)
         + N' REBUILD WITH (DATA_COMPRESSION = PAGE);'
    FROM   sys.indexes  i
    JOIN   sys.tables   t ON i.object_id = t.object_id
    JOIN   sys.schemas  s ON t.schema_id = s.schema_id
    WHERE  s.name IN (SELECT schema_name FROM #Schemas)
      AND  i.is_disabled = 1          
    ORDER BY s.name, t.name, i.name;
  
OPEN reb_cur;
FETCH NEXT FROM reb_cur INTO @cmd;
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @n += 1;
    PRINT @cmd;
    IF @Execute = 1
    BEGIN
        BEGIN TRY EXEC sys.sp_executesql @cmd; END TRY
        BEGIN CATCH PRINT N'   -- FAILED: ' + ERROR_MESSAGE(); END CATCH
    END
    FETCH NEXT FROM reb_cur INTO @cmd;
END
CLOSE reb_cur;
DEALLOCATE reb_cur;
  
PRINT N'---';
PRINT CONVERT(nvarchar(10), @n) + N' index '
    + CASE WHEN @Execute = 1 THEN N'rebuilt.' ELSE N'to be rebuilt (preview).' END;
GO
  
  
SET NOCOUNT ON;
DECLARE @Execute bit = 1;   -- 0 = preview ; 1 = executer
  
DECLARE @cmd nvarchar(max);
DECLARE @n   int = 0;
  
DECLARE fkc_cur CURSOR LOCAL FAST_FORWARD FOR
    SELECT N'ALTER TABLE ' + QUOTENAME(s.name) + N'.' + QUOTENAME(t.name)
         + N' WITH NOCHECK CHECK CONSTRAINT ' + QUOTENAME(fk.name) + N';'
    FROM   sys.foreign_keys fk
    JOIN   sys.tables  t ON fk.parent_object_id = t.object_id
    JOIN   sys.schemas s ON t.schema_id = s.schema_id
    WHERE  s.name IN (SELECT schema_name FROM #Schemas);
  
OPEN fkc_cur;
FETCH NEXT FROM fkc_cur INTO @cmd;
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @n += 1;
    PRINT @cmd;
    IF @Execute = 1
    BEGIN
        BEGIN TRY EXEC sys.sp_executesql @cmd; END TRY
        BEGIN CATCH PRINT N'   -- FAILED : ' + ERROR_MESSAGE(); END CATCH
    END
    FETCH NEXT FROM fkc_cur INTO @cmd;
END
CLOSE fkc_cur;
DEALLOCATE fkc_cur;
  
PRINT N'---';
PRINT CONVERT(nvarchar(10), @n) + N' FK '
    + CASE WHEN @Execute = 1 THEN N'activated and validated.' ELSE N'to be activated (preview).' END;
GO

The foreign keys, which turned out to be free

All 6,072 foreign keys were already back, active and marked not trusted, because the loading script re-enabled them with NOCHECK. Revalidating them with WITH CHECK would mean full joins against the largest tables in the database.

On a read-only archive whose source integrity was enforced by Oracle for fifteen years, that buys one thing: the optimizer regains the right to eliminate redundant joins. Worth having on a schema of deeply nested views, not worth days of scanning here. They stayed not trusted.

Day 7. Testing 600 views

The principle is simple: run every view, record what happened, and never lose the record. Each one gets a SELECT TOP (100) * inside a TRY/CATCH, so a view that fails is logged rather than fatal, and the outcome lands in a table with its duration in milliseconds. The cursor only picks up views that are not already recorded, which means an interrupted run resumes where it stopped instead of starting over, and the duration column is what you sort on once it is done:

SET NOCOUNT ON;
 
IF OBJECT_ID('dbo.ViewTestResults') IS NULL
    CREATE TABLE dbo.ViewTestResults (
        schema_name  sysname,
        view_name    sysname,
        statut       varchar(20),
        duree_ms     int,
        message      nvarchar(2048),
        tested_at    datetime2 DEFAULT SYSDATETIME(),
        CONSTRAINT PK_ViewTestResults PRIMARY KEY (schema_name, view_name)
    );
 
DECLARE @sch sysname, @vue sysname, @sql nvarchar(max), @t0 datetime2, @ms int, @i int = 0, @n int;
 
SELECT @n = COUNT(*)
FROM   sys.views v JOIN sys.schemas s ON v.schema_id = s.schema_id
WHERE  s.name = 'SCDAT'
  AND  NOT EXISTS (SELECT 1 FROM dbo.ViewTestResults r
                   WHERE r.schema_name = s.name AND r.view_name = v.name);
 
RAISERROR('=== %d view remaining ===', 0, 1, @n) WITH NOWAIT;
 
DECLARE c CURSOR FAST_FORWARD FOR
  SELECT s.name, v.name
  FROM   sys.views v JOIN sys.schemas s ON v.schema_id = s.schema_id
  WHERE  s.name = 'SCDAT'
    AND  NOT EXISTS (SELECT 1 FROM dbo.ViewTestResults r
                     WHERE r.schema_name = s.name AND r.view_name = v.name)
  ORDER  BY v.name;
 
OPEN c;
FETCH NEXT FROM c INTO @sch, @vue;
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @i += 1;
    RAISERROR('[%d/%d] %s.%s', 0, 1, @i, @n, @sch, @vue) WITH NOWAIT;
 
    SET @t0 = SYSDATETIME();
    BEGIN TRY
        SET @sql = N'SELECT TOP (100) * FROM ' + QUOTENAME(@sch) + N'.' + QUOTENAME(@vue) + N';';
        EXEC sp_executesql @sql;
        SET @ms = DATEDIFF(MILLISECOND, @t0, SYSDATETIME());
        INSERT dbo.ViewTestResults (schema_name, view_name, statut, duree_ms, message)
        VALUES (@sch, @vue, 'OK', @ms, NULL);
    END TRY
    BEGIN CATCH
        SET @ms = DATEDIFF(MILLISECOND, @t0, SYSDATETIME());
        INSERT dbo.ViewTestResults (schema_name, view_name, statut, duree_ms, message)
        VALUES (@sch, @vue, 'FAILED', @ms, ERROR_MESSAGE());
        RAISERROR('    -> FAILED: %s', 0, 1, @vue) WITH NOWAIT;
    END CATCH
 
    FETCH NEXT FROM c INTO @sch, @vue;
END
CLOSE c; DEALLOCATE c;
 
RAISERROR('=== Done ===', 0, 1) WITH NOWAIT;
 
-- summary
SELECT statut, COUNT(*) AS nb, SUM(duree_ms) AS duree_totale_ms
FROM dbo.ViewTestResults GROUP BY statut;
 
-- failed
SELECT schema_name, view_name, duree_ms, message
FROM dbo.ViewTestResults WHERE statut='FAILED' ORDER BY view_name;
 
-- all
SELECT schema_name, view_name, statut, duree_ms
FROM dbo.ViewTestResults ORDER BY duree_ms DESC;

The result looked excellent: 604 views OK, zero errors, against real data. Six skipped because they are not implemented to be run without an explicit filter added. SELECT TOP 100 * without a filter is not a representative test but still confirms that definition and joins are working fine. So: test with the filter the users will actually write. A view that only misbehaves when queried in a way nobody queries it is not a broken view, but you cannot know that from a green tick.

Day 8. Closing the hatch

Database set to read-only, final backup taken and user’s specific queries tested with success, the story now comes to a happy end.

What I would tell the next person

An archive migration is not a cheap application migration. It is a different decision set, and read-only is the input that drives most of it. 25,000 triggers are pointless, PAGE compression free, and untrusted foreign keys perfectly acceptable. It even tells you how to index: broadly and in advance, because nobody can tell you which row an auditor will want in three years. Before anything else, ask what the target will be used for. The answer rewrites the plan before the first byte moves.

Measure, and distrust anything that presents itself as progress. The SSMA counter refreshes per batch and sits still for minutes at a time. percent_complete stays at zero for an entire index build. A green tick on SELECT TOP 100 confirms that the joins resolve and nothing beyond that. In every one of those cases the real number was sitting in a DMV.

On views, the conversion rate is the least useful number in the report. What made four thousand views a finite piece of work was not the translation but the two steps around it: agreeing the real scope with the client first, then classifying what remained by pattern in the Oracle source rather than one error message at a time. An AI assistant translates a family of twenty views very well. It validates nothing, and the test against the source stays yours.

Compression on an archive is the rare decision with nothing to weigh against it. 117 GB down to 30.7 GB on the first table, more than 2.5 TB reclaimed across the set, and not a single write to pay it back with. If your heap is mostly null numeric columns, it is bigger than you think, and it will compress better than you expect.

L’article Archiving 5 TB from Oracle into SQL Server: views, indexes and compression (part 2) est apparu en premier sur dbi Blog.

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.

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:

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.

Oracle Database Mission-critical Technologies by Ashish Ray (Oracle)

In his presentation, Ashish definitively confirmed that the new driver is AI. We discuss about the roadmap and latest innovations in Oracle AI database.
Trusted AI is a very important case, as we need to have trust in the AI application to access the data, and this is not easy to accept.
Deep data security uniquely enables enterprises to declare flexible and powerful end-user specific data privacy rules in the database.

Extreme performance subject was also highlighted. Next-generation intelligent Data Architecture, with Exadata evolution, is very important.
Exadata Exascale, new modern storage architecture is the future and will certainly replace ASM. With Exascale, storage management tasks are moved directly onto the storage servers. It is the next generation storage.
We also addressed Exadata system software new features. 26.2 release has just been announced recently.

The next big part is High availability and scalability. 26ai brings a lot in Maximum Availability Architecture (MAA) features. The great example is the how faster database role transitions in Oracle Data Guard now is. Comparing 19c and 26ai, for small configuration, the switchover duration was reduced from 76s to 22s, and failover duration from 80s to 15s. For large configuration, the duration drops down from 77s to 29s for switchover and 94s to 26s for failover. Ashish mentioned the great work of Ludovico teams. We can easily find this information in Ludovico blogs: https://www.ludovicocaldara.net/blog/dg-26ai-faster-role-transitions/.

Ashish also recommended to have multiple standby per regions mentioning the recent event that happened in the world.

We also spoke about Intelligent data protection with On-Premises ZDLRA (zero data loss recovery appliance) and ZRCV (zero data loss autonomous recovery service) in the cloud. It is so easy to enable automatic backup in the Cloud and choosing as backup destination autonomous recovery service, will guarantee customer RPO.

Ashish also highlighted deployment flexibility across on-premises and the cloud with On-premises databases, exadata Cloud@Customer (hybrid cloud), public cloud exadata database service, …
ODA on premises, with Oracle Base Database Cloud@Customer, has also now its public cloud solution. You can read more here.
https://blogs.oracle.com/database/announcing-oracle-base-database-cloudcustomer

Also know that exadata database-developer is available at no cost for develppers.

What’s new in the third edition of troubleshooting Oracle Performance by Chris Antognini

Chris presented some great updates in terms of performance troubleshooting that 26ai is bringing. He wrote a third edition from his book, titled “Troubleshooting Oracle Performance” that will be available in December this year.

We talked about several topics like:

Signatures:

• Signatures are used to recognize SQL statements that are equivalent from a functional point of view
• DBMS_SQLTUNE.SQLTXT_TO_SIGNATURE
• SYS.SQLLOG$ is containing the signature of SQL statements that were executed in the past
  • 19.11 bug 32238935 mix of both literals and bind variables leads to a wrong computation o fthe force-matching signature

Possibility in 23ai to push down group-by function when using union all (23+):

• Push group by clauses inside views or inline views that contain union all operators
• cost based query transformation

Subsumption of views and subqueries:

• Purpose is to replace multiple query blocks that are created due to views, inline views or subqueries accessing the same tables with one query block
• Purpose is to avoid double execution

DBMS_STATS: gather stale option specific when gathering object statistics at the database or schema level

• only objects with stale statistics are processed
• 23.7 DBA_AUTO_STAT_OBJ_GATHER_DETAILS view with column REASON_TO_GATHER will give the reason why stats were gathered

Dynamic statistics/sampling and PL/SQL functions (23.8):

• Sampling queries only call PL/SQL functions that are referenced in predicates
• DYNAMIC_STATS preference: choose, on, off

Add verified SQL Plan baseline (23.3):

• Let the database engine search for the best-known execution plan for a given SQL statement
• New function ADD_VERIFIED_SQL_PLAN_BASELINE provided by DBMS_SPM package
• Backported to 19c starting 19.22

Real-time SQL Plan Management (23):

• verify during a hard parse if the exec plan is the same as one one contained in ASTS
• AUTO_SPM_EVOLVE_TASK=AUTO

IN conditions with many expressions (23.4):

• long lists of expressions frequently lead to performace problems, in condition with 64 or more expressions re implemetned differently when a full table sacn is executed
• instead of using disjunctive predicates a key vector containing the expressions is created

Parallel executions downgrades:

• downgrades are now outlined in real-time monitoring reports
• x$qksxa_reason to find what the code means (degree of parallelism downgrade reason)

Logical Partition change tracking (23+):

• For materialized view the database can track the staleness at the table and partition level
• 23 comes with logical PCT (partition change tracking) that means the database is able to use logical range partitions now
• Logical PCT will help on faster refresh

I also would like to hightlight that Chris had really good demos.

Beyond the Service Request: A view from the other side of the screen by Laurentiu Cotescu (Oracle)

Purpose of this presentation is for us to somehow meet the support guys, people working behind a Service Request.

Laurentiu talked about Oracle EU Sovereign Cloud.
But What is Oracle EU Sovereign Cloud?
Oracle EU Sovereign Cloud enables commercial and public sector organizations to place sensitive data and applications in the cloud—in alignment with EU data privacy and sovereignty requirements.

Laurentiu provided us some inside of oracle support. When we go to MOS and log a SR, Oracle support expect for fast handling to have following information already mentioned during SR creation: Problem summary, OCID’s, timestamp of the issue, exadata cloud versions, evidence with logs as of TFA logs, business impact.
Setting the right severity is also important:
Critical Outage -> SEV 1
Significant Impairment -> SEV 2
Technical issue -> SEV 3
General Guidance -> SEV 4

Critical outage + system unavailable + production env -> Most critical, management of oracle support will be informed.

Product classification very important to have the SR going in the right queue.

And what does Oracle Development?
Oracle Developpement is composed of product engineering behind software improvements and fixes. They will work with support on production issue, develop product capabilities and code fixes and fix delivery (patches and Release Updates).

When the progress feels slow, what can we do?

• Option 1 – Trigger/initiate Chat widget, type agent to connect with a live agent
  • Describe the business impact, is there WA, explain the concern, …
• Option 2 – Request manager Actions from Details page
  • Front line manager or level 1 duty manager or level 2 director and duty (after 45 min of no reaction)

How can we do Better together?

• Initiate zoom session (or any other conference system, just need to provide an invitation link) after several goes and back
• Proactive Milestone SR procedural document – KB127520
• Request manager action to ask for a consolidated ownership of all the SRs opened
• Useful exchange with impact, context, evidence, …

Once SR is created, there is no more AI agent or chatbot. AI is only used as tool like AI parsers to help analyzing the logs.

Upgrade to Oracle AI Database 26ai – Best Practices and more by Mike Dietrich

As you know Mike Dietrich, we spoke a lot about patching and upgrade.

Mike spoke about release strategy:

• 11.2.0.4, 12.1, 12.2, 18c -> 19c -> 26ai upgrade (with downtime) or directly with datapump
• 23ai -> 26ai release update (no downtime)
• October 2025 Oracle AI Database 26ai version is named 23.26.0.0.0
• January 2026 is named 23.26.1.0.0, see 1 for quarter and not months
• Which will make July 2026 release name as been 23.26.3.0.0
• What will be 2027? Let’s see what will come
• For 26ai release schedule, see PNEWS1360

We also spoke about:

• Converting DB to PDB
• To set alter system set max_pdbs=3; in order to prevent license violations (change spfile, it is very important)
• Going to pdb no application changes, does not impact application only connection sqlplus / as sysdba connection might be impacted
• Multitenant extra license when you have more than 3 PDBs
• Recommendation for noncdb to pdb migration is to start with 3 databases and consolidate them early enough into Multitenant
• It is important not to forget client / server interoperability, see KB141043. For security reason it is important to uplift the client. Same matrix applies to database link
  • select * from gv$session_connect_info; to know client version
• Traditional auditing is desupported in 26ai
  • It is still possible for the database to generate audit records but you can not create new policies or change existing ones.
  • KB120309 for syntax to converter script

For an upgrade:

• Look at the Upgrade guide
• Use oradiff tool (https://oradiff.oracle.com) to compare 2 releases and know fixes covered. oradiff has a rest API.
• Execute a dictionary check before upgrade KB150043
• Ensure dictionary and fixed objects statistics.
• Purge recyclebin and gather dictionary stats 24 hours before upgrade

How to upgrade and convert:

• Installation of Oracle home is simpler, gold images, use autoupgrade
• Create container database first
  • character set, always choose AL32UTF8 to not take care of PDB character set and accept any
  • components, only install the components that is only needed, for faster upgrade and patching
  • compatible parameter, 23.6.0 (default), if downgrade would be needed first manually change it
  • unplug always possible in higher version but not to a lower compatible settings
  • new command: alter database set downgrade compatibility to '23.9.0';
  • update the compatible parameter on the fly without restarting the database
  • cdb_registry to check component
    • pdb$seed might not be seeing
      • alter system set "_exclude_seed_cdb_view"=false; to make it visible

Use Autoupgrade tool for upgrade, non-cdb to pdb conversion and patching:

• 1- plugin, 2- upgrade, 3- convert
• Get it through KB123450
• Or using www.oracle.com/goto/upgrade

It is important to know that DBUA is retired. Upgrade with autoupgrade is simple. Need a config file with all parameters
We can also easily collect autoupgrade logs with option -zip.

Conversion to pdb is irreversible. Rollback options would be: backup/restore or copy data files or refreshable clone PDB.

PDB creation does not propagate to the standby.

tips for view parameter:
alter system set "_cursor_obsolete_treshold"=1024 comment="Added XXX";, comment for _ paraameter
alter system set "_column_tracking_level"=1;

By the way, here can you find Mike’s slides: https://mikedietrichde.com/slides/

Upgrade, Patch, Repeat – Stay Secure and up to date with Oracle AutoUpgrade and Ansible by Martin Berger

Martin spoke about how security is important. Attackers comes at the oracle db using listener, privilege, sql inection, data exfiltration db links or datapump. This is why patching is so important and patch are more and more frequent.
For release and patch we have Release Update (RU), Monthly Recommended Patch (MRP), Critical Security Patch Update (CSPU) and Critical Patch Update (CPU).
To cover his explanation, Martin highlighted that there were 656 total fixes between 19.31 (MRP) and next month 19.32 (RU).
Martins also point how useful oradiff.oracle.com was.
When out of place upgrade is the prob move, the in-place is the classic way to do. Let’s push for out of the place upgrade, new home can be rollbacked and there is minimal downtime.

Oracle autoupgrade and how to create new oracle home with autoupgrade:

• Get latest autoupgrade
• Create MOS keystore
• Get release update
• Create db_home

With autoupgrade we can patch OEM as well to 24.1, lastest autoupgrade version 26.5.260807 required.

3 modes of autoupgrade: analyze, fixups and deploy (change only -mode option value)
Remaining tasks : timezone, gather dictionary statistics, compatible parameter (change when 100% no downgrade), use and drop restore point

With Data Guard we can run standby-first patching.

ansible : autoupgrade takes care of the database. Ansible handles everything else.
ansible is agentless, idempotent, declarative

OLAM: Oracle Linux Automation Manager for automation and the oracle Autonomous Database for tracking.

Martin did a great demo with OLAM and ansible.

4 years Oracle 19c (Exadata sparse) Pluggable Database cloning, did it bring something by Jérôme Witt

Great presentation from my Collegue who spoke about various pluggable database cloning method and mainly with Exadata sparse.
This presentation comes from a real case customer project migrating from on premises to Exadata Cloud@Customer project, and migrating an existing cloning NetApp platform to an Oracle technlogy cloning method system using PDB cloning and Exdata Spare technology.

Maintenance:

• PDB relocation
• un-plug/plug
• RTO in case of Disaster Recovery and all with automation

Automation:

• centralized, highly-available scheduler
• log, config management
• CI pipelines
• self-service

Jerôme explained PDB cloning techniques and method: PDB clone local vs remote, Non-CDB to PDB conversion, snapshot copy (storage based vs sparse) and refreshable clones

Exadata Sparse Clone:

• Single source, multiple targets
• small storage footing
• one command line
• transform sparse clone to full clone materialization process
• 3 cons: requires a Test-Master-Read-Only source, dependency on shared storage and capacity management for Oracle ASM (%DATA, %REDO, %SPARSE)

Finally Jérôme provided perfect Demos and provided also real-world challenges, experience coming from customer projects.

Great explanation how to remote full clone in Oracle Data Guard environment (as for example STANDBY=NONE)

Exadata sparse clone:

• Create a Test Master Read-Only (TMR)
  • Refreshable clone
  • Read-Only standby database
  • Read-Only full clone (full clone subset PDB)
• Provision sparse clones
  • Locally within same CDB
  • Remotely over database link
• Drop or Materialize sparse clone
• Revert source PDB datafiles read-write
  • SQL> DBMS_DNFS.RESTORE_DATAFILE_PERMISSIONS(pdb_name=> 'PDB');
• Re-create / Refresh TMR

Jérôme successfully ran several nice demos:

• Demo remote full clone with Oracle Data Guard.
• Demo create refreshable clone from Orale Data Guard (active) standby
• Demo refresh refreshable clone from Oracle ADG standby

TNS Connections – what can be going wrong? by Axel Vom Stein

Axel introduced the presentation by reminding on the TCP basics connections and then presented a real case TCP issue troubleshooting: ncat, nestat, tcpdump, … tcpdump with wireshark analyses

Transparent Network Substrate (TNS): Protocol TCP, TCPS, IPC, BEQ.
Listener endpoints: sqlnet.ora, tnsnames.ora, listener.ora

What can go wrong:

• sqlnet.ora with EZCONNECT and HOSTNAME,
• listener.ora with DEFAULT_SERVICE_LISTNER: no service, take this service
• sqlnet.ora OUTBOUND_CONNECT_TIMEOUT overriden by tnsnames.ora CONNECT_TIMEOUT
• sqlnet.ora EXPIRE_TIME can be mitigated with firewall configuration
• listener configuration with dynamic and static registration
• Service managed by DBMS_SERVICE or srvctl grid infra
• listener name
• listener USE_SID_AS_SERVICE and DEFAULT_SERVICE
• TNS Connection with LISTENER and SCAN_LISTENER
• Do not minimize the firewall configuration (with RAC, needs to configuration scan listener and listener)
• TNS Connection timeouts (Data Guard address list in tnsnames.ora).
  Pay attention on the connect_timeout, retry_count and retry_delay
  transport_connect_timeout parameter
• Duplicate tns names entries in tnsnames.ora (the last always wins)
• IFILE with max 3 levels for tnsnames.ora, listener.ora and sqlnet.ora
• TWO_TASK (linux) %LOCAL% (windows) variables
• Encryption sqlnet.ora parameter

Analyze can be done with gv$session_connect_info and gv$session

During the troubleshooting funny Oracle errors have been highlighted: ORA-28041, ORA-1699 error

And what about the DJ?

At dbi services we can even have our expert shine as DJs! Thanks Clemens! Good job!

L’article SOUG Day October 2026 est apparu en premier sur dbi Blog.

Product evolution

AI integration in Oracle Enterprise Manager 24ai was quite evolving rapidly.

• Ask EM
  Was first introduced with Enterprise Manager 24ai Release 1 Update 4.
  Dependent of OCI Ops Insight for the chatbot functionality and processing.
• Oracle AI Database Assistant
  Was introduced in Enterprise Manager 24ai Release 1 Update 10.
  Replacing Ask EM
  Use of LLM provider: OCI GenAI or BYO LLM
• MCP server
  Enterprise Manager 24ai Release 1 Update 12 is now integrating a MCP server which will bring a brand of new possibilities.
  The MCP server is directly built in OEM.
• Finally Enterprise Manager 24ai Release 1 Update 13 will bring a new good feature:
  Autocompletion suggestions. We just write on the prompt “oracle databases” and many suggestions might come : “Show Oracle Databases by average active sessions” or “Show Oracle Databases by CPU time”

In a nutshell

Oracle AI Database Assistant will help me interacting with OEM with Natural-Language questions, like “What happened to prod?”. The assistant will then understand my question and retrieves data directly from OMR (Oracle Management Repository). OMR is storing all data for all my targets related to their health, issues and performance.

Oracle AI Database Assistant no longer depends on OCI Ops Insight. OCI Ops Insights subscription is not needed any more.

Oracle AI Database Assistant will use LLM (Large-Language Model). Multiple LLM are supported:

• You can use the one from Enterprise Manager, so OEM as provider. Oracle AI Database Assistant will access directly OCI Generative AI.
• Or you can bring your own LLM Provider. Two Models are supported : OpenAI or Ollama. To use external LLM provider you will need some additional access between OMS server and OCI.

Prerequisites

There is a few prerequisites to configure and use Oracle AI Database Assistant. I will remind them here, but please refer to my other blogs explaining how to configure Oracle AI Database Assistant for guidance with screenshots.

• Log as SYSMAN for configuring Oracle AI Database Assistant
• Choice in LLM provider
• To use Enterprise Manager provider one account in a supported region is needed
  • Japan Central (Osaka): ap-osaka-1
  • Germany Central (Frankfurt): eu-frankfurt-1
  • Brazil East (Sao Paulo): sa-saopaulo-1
  • UK South (London): uk-london-1
  • US Midwest (Chicago): us-chicago-1
• Oracle AI Database Assistant to be enabled in Enterprise Manager
  • Activated per default
  • Command line
    emctl set property -name enable_genai_assistant -value false|true
• OCI policies so that Enterprise Manager can access the OCI Generative AI service
  allow group to manage opsi-genai-em-session in compartment
allow group to use generative-ai-family in compartment
• An OCI Named Credential for communication with OCI LLM service
  • Use of Enterprise Manager LLM provider
  • OCI Authentication through API key

With Oracle AI Database Assistant, you can bring your own LLM Provider:

• Bring-Your-Own LLM Providers
• OpenAI or Ollama
• API Key for LLM provider authentication
• Name of the model to be used
• Model endpoint URL
  • OMS property oracle.sysman.llm.provider.allowedProviderUrls
• Network connectivity between OMS and the provider endpoint

And what about the cost? Oracle AI Database Assistant includes a complimentary allocation of AI tokens for OCI Generative AI models. The cost can be visible through the OCI Ops Insights service.Once the allocated tokens are consumed, extended cost charged to the OCI account based on the AI model and the OCI region. See following oracle documentations:
https://www.oracle.com/cloud/price-list/#pricing-ai
https://docs.oracle.com/en-us/iaas/Content/generative-ai/home.htm

Let’s do some further tests!

Let’s have fun and test the Oracle AI Database Assistant, now I could configure it.

Asking for targets…

I first asked about status summary for all my targets. Answer was coherent with the OEM summary dashboard.

I then asked to list the target that are down, which of course is ok as the host was not up and running.

I then started the lab node.

I confirmed there is no more target down.

I can see that no more targets are down. I took the opportunity to test the language wording, and as we can see, Oracle AI Database Assistant was not able to understand the situation, and my question “and now?” referring to make it (we would have been attracted to write him, but let’s use it ) understand that I wanted the same previous questions was not understandable. We can only use specific OEM language.

I could list the targets that are up. What is cool is that I do not need to make full sentences. “List target up” was enough for the assistant to understand the question.

I could also ask to filter on host type, which was successfully.

Asking for documentation…

As we can see, the assistant will not provide me any OEM documentation, and the expected prompt stick on OEM data model language.

Asking for incidents…

I could also successfully list open incidents.

Asking for databases status…

I could list database target status, and also the assistant understand pdb, pluggable database.

Asking the assistant to list databases that have currently problems, I could get as answer… All databases. We can easily understand that the assistant take word that it understands and that it can put in correlation with any data from the OMR without making a full analyse of the full question.

Asking for critical alerts…

I could also ask the assistant to list the critical alerts. This was working as expected. I was only a quite of surprised that asking the same for the last 24 hours, I got no data displayed. Which is incoherent knowing I have one running… We can see that the “last 24 hours” has been understood, as the filter “Last 24 hours” appeared.

I stopped BITS999P_PDB1 Pluggable Database to see if it will been displayed in the critical alerts.

Stopping PDB:

[oracle@svl-orap-chz0-cl1n1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Sep 22 13:18:36 2026
Version 19.31.0.0.0

Copyright (c) 1982, 2026, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.31.0.0.0

SQL> show pdbs

    CON_ID CON_NAME           OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     2 PDB$SEED               READ ONLY  NO
     3 BITS999P_PDB1          READ WRITE NO

SQL> alter session set container=BITS999P_PDB1;

Session altered.

SQL> alter pluggable database close abort;

Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME           OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     3 BITS999P_PDB1          MOUNTED

Let’s check the critical alerts again.

Working as expected. I could even be more precise filtering on pluggable database only.

I restarted the PDB:

SQL> alter pluggable database open;

Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME           OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     3 BITS999P_PDB1          READ WRITE NO
SQL>

And I could confirm the alerts disappeared.

Oh by the way, now my Data Guard alerts for last 24 hours filter is working. No idea why.

Asking what happened to my database…

I can ask what happened to a specific database in the last night, and the answer is totally coherent. We can see how the filters are appearing according to the content of my prompt: “Pluggable Database”, “BITS999P_PDB1”, “Last 1 day”.

Asking what happened to the PDB in the last 2 years, the filter automatically applied is “Last 60 minutes”. This might be related to a purge parameter, I guess… I have no explanation so far.

Asking what is the status of BITS999P_PDB1, we can see that the assistant did not understand the question, but added some drop-down list, where I can choose data.

Which will give me the possibility to get some valid information.

I could also successfully query what happened to the PDB in a time frame. Which is a very good added value.

Asking for tablespace usage…

I also asked for pluggable database tablespace usage, for the same PDB. I could get an answer, which really is not that readable.

But the more surprising is the assistant might not be so trustable. Let me explain why. Later on, I could see get coherent results for target status, incidents, but I could not get any information any more for the tablespace usage.

Even if the metrics are available in OEM, see next pictures.

To wrap up…

Following is the pros and cons I see in this new Oracle AI assistant.

When I think it is a good startup, with an assistant that will help to get more quickly the health, issue and performance on any target monitored by OEM, the tool still need to improve the stability and the trust we can put on him.

L’article AI meets OEM, let’s test Oracle AI Database Assistant est apparu en premier sur dbi Blog.

Indeed, a fresh extract writing to the same trail name/path keeps appending after the old sequence numbers instead of restarting at 000000000. A fresh replicat starts reading from 000000000 by default. If you don’t remove the trail files when re-creating an extract and replicat pair, the extract will do its job. However, the new replicat has no way to tell leftover files apart from new ones. It will read whatever is still sitting in 000000000 and onward as if it were live data.

The adminclient does have a command for this, PURGE EXTTRAIL, but it only works once nothing is using the trail anymore:

OGG (http://vmogg:7810 ogg_test_01) 3> purge exttrail PDB1/aa

Error: Cannot purge trail 'PDB1/aa', the trail is in use by EXTRACT 'EOGG375'

From the adminclient, you need to delete the extract first. Then, PURGE EXTTRAIL removes every sequence file and the trail resource:

OGG (http://vmogg:7810 ogg_test_01) 2> purge exttrail PDB1/aa
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000000'. Purge rule: Purging all files for trail 'PDB1/aa'.
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000001'. Purge rule: Purging all files for trail 'PDB1/aa'.
[...]
2026-09-20T13:52:35Z  INFO    OGG-00957  Purged old extract file 'PDB1/aa000000035'. Purge rule: Purging all files for trail 'PDB1/aa'.

So from an interactive session, PURGE EXTTRAIL is the easy way. But when automating, the REST API is often easier to handle, so let’s see how it should be done with it.

Deleting a trail

Calling the DELETE /services/{version}/trails/{trail} endpoint seems like a good call. Let’s try this first, on a trail still attached to a stopped (but not deleted) extract, using the delete_trail method of the oggrestapi Python package:

from oggrestapi import OGGRestAPI

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

client.delete_trail(trail="aa", path_query="PDB1")

RuntimeError: ERROR (code 400) - http://vmogg:7810/services/v2/trails/aa: Unable to delete trail resource 'PDB1/aa' because there are processes using it.

This is expected: a trail still referenced by a process cannot be deleted. Delete the extract, then retry:

RuntimeError: ERROR (code 500) - http://vmogg:7810/services/v2/trails/aa: There was a problem updating the Administration Service resources.

On a non-empty trail, once the process that was using it is gone, this call still fails with an OGG-30375 error (code 500) and a generic There was a problem updating the Administration Service resources.

To delete a trail with the GoldenGate REST API, you must first empty the trail sequence. Once the trail sequence is empty, the trail resource is automatically deleted. The method delete_trail_sequence_collection(), mapping DELETE /services/{version}/trails/{trail}/sequences, does this in one call: it takes a sequence range, first and last, as named keyword arguments:

result = client.delete_trail_sequence_collection(
    trail="aa",
    path="PDB1",
    first=0,
    last=999999999
)
[(m["code"], m["title"]) for m in result["messages"]]

[('OGG-30282', "Using actual highest sequence number '000000001' instead of last sequence number '999999999' specified in the request for trail 'PDB1/aa'."), ('OGG-30277', "Successfully deleted '2' of '2' trail sequences for trail 'PDB1/aa'."), ('OGG-30282', "Using actual highest sequence number '000000001' instead of last sequence number '999999999' specified in the request for trail 'PDB1/aa'."), ('OGG-30277', "Successfully deleted '2' of '2' trail sequences for trail 'PDB1/aa'.")]

An oversized value for last is a safe way to delete “everything”. Both first and last are required: omitting either one fails with an OGG-12104 error (no “from first to the end” shortcut).

Background operations of PURGE EXTTRAIL

PURGE EXTTRAIL from the adminclient does not call this endpoint. Tracing its requests through restapi.log shows it calling the generic command endpoint instead, POST /services/{version}/commands/execute, equivalent of the execute_command method, with a purge command:

data = {
    "name": "purge",
    "purgeType": "trails",
    "trails": [{"name": "aa", "path": "PDB1"}],
    "useCheckpoints": False,
    "keep": [{"type": "min", "units": "files", "value": 0}],
}

result = client.execute_command(data=data)
[(m["code"], m["title"]) for m in result["messages"]]

[('OGG-00957', "Purged old extract file 'PDB1/aa000000000'. Purge rule: Purging all files for trail 'PDB1/aa'."), ('OGG-00957', "Purged old extract file 'PDB1/aa000000001'. Purge rule: Purging all files for trail 'PDB1/aa'.")]

keep with value: 0 means “keep zero files”, or purge everything. It has the same end result as delete_trail_sequence_collection(), but with one OGG-00957 message per file instead of the range-clamp/success pair.

Whether it’s from the adminclient or with the REST API, the procedure to delete trail files is the same: make sure processes are deleted before deleting their trail files, and delete them one by one or with a purge command.

L’article Deleting GoldenGate trail files via the REST API (OGG-30375) est apparu en premier sur dbi Blog.