The goal was to evaluate OCI-managed MCP servers and determine whether extending their available toolsets with additional database operations could reduce reliance on agent skills. By exposing reusable operations as MCP tools, we aimed to reduce token consumption and associated costs while improving execution efficiency, without compromising the security of databases hosted in private VCN subnets.

Provision OCI-resources: When RTFM Isn’t Enough

Provisioning an MCP server requires an underlying database connection that combines database credentials with network connectivity to the target database, typically through a private endpoint. This connection allows the MCP server to access the database securely while keeping it within the private VCN.

The detailed setup procedure is beyond the scope of this article, as Oracle provides official documentation covering the prerequisites, configuration, and provisioning for Database Tools Private Endpoints

In short, the documentation mentions using Zero Trust Packet Routing (ZPR) alongside, or instead of, Network Security Groups (NSGs) to control network access.

So far, so good. We already use NSGs exclusively to manage network traffic.

However, the documentation does not clearly spell out which specific NSG rules are required or whether ingress rules alone are sufficient. After digging deeper into the documentation, we found the missing piece of the puzzle:

Creating a Database Management Private Endpoint

The key takeaway is that the Network Security Groups (NSGs) associated with the private endpoint must have appropriate ingress and egress rules to permit the required network traffic.

This is where things got more interesting. Our environment already hosted several databases interconnected through Oracle database links, with ingress and egress rules in place for the relevant subnets, including the newly provisioned private endpoint. Yet, despite these existing network configurations, the MCP server still could not connect to the target database.

ORA-12170: Cannot connect. TCP connect timeout

Clearly, something was missing. We therefore dug deeper into the private endpoint’s specific network security requirements to identify the root cause of the connectivity issue.

Still Getting ORA-12170, But Why?

Hold on a minute! We quickly went through the OCI Console to double-check our network configuration:

• Verified the private endpoint’s NSG ingress and egress rules.
• Confirmed that the databases and the private endpoint were deployed in the same subnet.

Everything looked correct at first glance, yet the dreaded ORA-12170: TNS:Connect timeout occurred error persisted.

What were we missing? Time to bring in Oracle Support!

While working with Oracle Support, we took a closer look at the NSG configuration and the private endpoint’s VNIC. Something caught our attention: an entry was missing from the list, but we hadn’t initially considered it relevant.

This prompted us to inspect the private endpoint configuration in greater detail using the OCI Command Line Interface (OCI CLI).

jerome_witt@cloudshell:~ (eu-zurich-1)$ oci dbtools private-endpoint get \
  --private-endpoint-id ${EDP_OCID}  \
  --query 'data.{"nsg-ids": "nsg-ids", "private-endpoint-vnic-id": "private-endpoint-vnic-id", "security-attributes": "security-attributes"}' \
  --output json
{
  "nsg-ids": null,
  "private-endpoint-vnic-id": "ocid1.vnic.oc1.eu-zurich-1.xxxxxxxxxxxxxxxxx",
  "security-attributes": {}
}

Oh! The nsg-ids field is null! That was the missing piece of the puzzle.

After updating the private endpoint with the appropriate NSG, we ran the following OCI CLI command:

oci dbtools private-endpoint update \ 
  --private-endpoint-id ${EDP_OCID} \
  --nsg-ids '["${NSG_ATTACHED_TO_DB_OCID}"]'

And then, the magic happened! The database connection succeeded, and the dreaded ORA-12170 error was gone.

After explicitly associating the appropriate NSG with the Database Tools private endpoint, connectivity was restored. The OCI CLI output had revealed that the nsg-ids field was null, a detail we had overlooked when initially checking the configuration through the OCI Console.

This behavior may be related to recent changes in OCI as Oracle continues to rapidly develop and roll out its core Deep Data Security capabilities.

What had initially looked like a correctly configured network turned out to be missing a crucial piece: the NSG association explicitly configured on the Database Tools private endpoint itself.

Lessons Learned

• Never blindly trust the console! Always verify the underlying configuration using the OCI CLI.
• Have fun troubleshooting! Sometimes, the smallest configuration detail makes all the difference.

By the way, it seems we’re not alone. Others have apparently encountered similar database connectivity issues when configuring OCI Database Tools but none were using NSGs exclusively.

For further reference, these Oracle Support knowledge base articles may be useful:

• KB64948 — How to Connect to the Autonomous Database (Private Endpoint Access)
• KB42277 — OCI — Enable Database Management Fails

L’article OCI-managed MCP Server: Troubleshooting ORA-12170 errors with Private Endpoint connectivity 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.

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.

These discussions usually involve critical environments based on Oracle WebLogic Server, Oracle Forms, and sometimes Oracle Reports. The objective is rarely just to “move to the cloud”. It is about understanding what can realistically be migrated, what should be modernized, what must be validated, and where the main technical, operational, and licensing risks are.

Based on these discussions, I would like to share a few practical considerations that may be useful when evaluating a cloud migration strategy for Oracle Fusion Middleware workloads.

Lift and shift is not a shortcut, it is a controlled migration strategy

For Oracle WebLogic, Forms and Reports platforms, a cloud migration should not automatically be presented as an application modernization project.

In many cases, the first realistic step is a lift-and-shift migration. The goal is not to rewrite Forms modules, redesign the full application, or replace every legacy component immediately. The goal is to rebuild a controlled target platform in the cloud while preserving the application behavior as much as possible.

However, lift and shift does not mean copying virtual machines and hoping that everything will work.

A serious migration requires a detailed comparison between the existing platform and the target one: WebLogic domain configuration, Managed Servers, Datasources, Wallets, Certificates, JVM version, Patch level, Forms runtime configuration, Reports configuration, File system dependencies, Fonts, Printers, Batch jobs, Monitoring, Backup, Restart procedures, and Operational scripts.

Oracle documents several WebLogic migration approaches to OCI, including manual deployment, WebLogic Deploy Tooling, and WLST-based deployment scripts targeted to a new domain. Oracle also describes WebLogic Server for OCI as a way to provision a WebLogic domain in OCI more quickly than a traditional on-premises setup.

This is why lift and shift should be seen as an engineering exercise, not as a low-effort infrastructure move.

Why OCI is naturally aligned with Oracle Fusion Middleware

It would not be accurate to say that Oracle Fusion Middleware can only run on OCI. Oracle’s own cloud licensing policy lists AWS, Azure, and Google Cloud Platform as “Authorized Cloud Environments” for specific Oracle software licensing rules. The same policy also explains how vCPUs must be counted in these environments and states that the Oracle Processor Core Factor Table is not applicable there.

So the real point is not that other clouds are impossible. The point is that OCI is naturally aligned with Oracle Fusion Middleware workloads.

For WebLogic, Oracle provides OCI-specific deployment models, Marketplace-based options, and documented migration patterns. For Kubernetes-based deployments, Oracle also documents WebLogic Server for OKE using a Marketplace stack, including lifecycle-management components such as Jenkins and the WebLogic Kubernetes Operator.

From an operational and licensing perspective, OCI also gives Oracle customers options such as BYOL and Universal Credits-based models. Oracle’s Support Rewards FAQ states that BYOL services on the Universal Credits Model rate card are eligible for the Support Rewards program.

This does not remove the need for a proper license review. But it does mean that for Oracle middleware workloads, OCI often provides a more Oracle-native discussion: infrastructure, middleware, licensing, support model, and target architecture can be addressed within the same ecosystem.

Oracle Reports must be treated as a specific risk

For Oracle Forms and WebLogic, a structured lift-and-shift approach to OCI can be a realistic option. For Oracle Reports, the discussion must be more careful.

Oracle Reports is still present in many enterprise Forms platforms, but it has technical characteristics that must be validated before any cloud migration. Reports cluster members or clients use multicast to discover other nodes, and that there is no workaround for using multicast in that context.

This is a critical point because multicast is generally not available in all cloud network architectures.

In practical terms, Oracle Reports should not be treated as a simple checkbox in the migration plan. It requires a dedicated technical validation: Reports Server configuration, naming service, generated output, cache behavior, fonts, printers, file paths, batch execution, restart behavior, and integration with the Forms application.

Conclusion

The conclusion is therefore simple: WebLogic and Forms can be good candidates for a controlled lift-and-shift migration to OCI. Oracle Reports must be assessed separately, tested carefully, and challenged architecturally.

OCI can reduce complexity for Oracle Fusion Middleware migrations, but it does not remove the need for deep product expertise. A successful migration is not only a cloud project, it is a WebLogic, Forms, Reports, licensing, operations, and validation project.

If you are planning to migrate an Oracle Fusion Middleware platform to the cloud, or if you simply want to assess whether such a migration is realistic for your environment, feel free to contact me. I would be happy to help you challenge the architecture, identify the risks, and define a pragmatic migration approach.

More related blogs here.

L’article Oracle Fusion Middleware to the Cloud est apparu en premier sur dbi Blog.

But when migrating a database or just performing the initial load of a single table to prepare a GoldenGate replication, the known procedure is very often still the old one: start an extract, note down an SCN, run expdp with FLASHBACK_SCN=<that SCN>, import the data on the target, and finally start a replicat with the AFTERCSN clause.

It takes a long time to get used to new habits, so let’s refresh your memory, explaining how instantiation CSN work in GoldenGate.

Historic FLASHBACK_SCN + AFTERCSN initial load

Historically, precise instantiation of a table worked like this:

• START EXTRACT. It is the first step, to ensure that no transaction is lost.
• Wait for long running transactions to be committed.
• Select an SCN, which should not be prior to the registration SCN of the extract.
• Export the data with expdp ... FLASHBACK_SCN=<scn> so the dump is consistent.
• Import the data with impdp on the target.
• Start the replicat with the AFTERCSN <csn> clause, so the replicat does not replicate anything committed at or before the instantiation CSN.

While still perfectly valid, and even necessary under certain conditions, this method becomes hard to operate on complex replications or when the size of the database increases:

• UNDO retention: very often, using the FLASHBACK_SCN clause will generate ORA-01555: snapshot too old errors.
• Splitting the initial load is not possible, since the AFTERCSN clause will apply on the whole replicat.

Instantiation CSN in practice

GoldenGate instantiation CSN provides a simple solution: a per table instantiation CSN, on the target database, instead of a single one applied on the replicat.

This instantiation CSN is stored on the target database in the DBA_APPLY_INSTANTIATED_OBJECTS table, with one row per source object.

SET PAGES 100 LINES 200
COL source_object_owner FORMAT A20
COL source_object_name FORMAT A30
COL instantiation_scn FORMAT 999999999999999
SELECT source_object_owner, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
ORDER BY 1, 2;

This table is populated by Data Pump, and is then read by GoldenGate. When applying changes, a replicat will compare the commit CSN of a record to the table’s instantiation CSN. If the commit CSN is higher, the transaction will be discarded.

Because the comparison is done for every table, there is no need for them to share one instantiation CSN using FLASHBACK_SCN.

Why FLASHBACK_SCN is no longer required

The instantiation CSN is the read-consistent SCN as of which Data Pump reads the table during export. It is stored in the dump and imported on the target when using impdp. It does not come from when the source table is prepared with PREPARECSN. PREPARECSN is what makes the table eligible for instantiation CSN.

Let’s see the difference with three different scenarios:

• Standard initial load without FLASHBACK_SCN
• Historic method with FLASHBACK_SCN
• Instantiation with PREPARECSN NONE

I will use the same two tables, HR.EMPLOYEES and HR.DEPARTMENTS.

ENABLE_INSTANTIATION_FILTERING vs ATCSN/AFTERCSN

Before running the three scenarios, here is what the instantiation filtering replaces:

1. Prepare the tables on the source

Using ADD SCHEMATRANDATA, we will start by preparing the table on the source. The full clause is ADD SCHEMATRANDATA <schema_name> PREPARECSN {WAIT | LOCK | NOWAIT | NONE}, and NOWAIT is the default. In other words, ADD SCHEMATRANDATA prepares tables for instantiation whether you include PREPARECSN or not.

OGG> DBLOGIN USERIDALIAS gg_source DOMAIN OracleGoldenGate
OGG> ADD SCHEMATRANDATA HR
2026-07-26 09:41:07  INFO    OGG-01788  SCHEMATRANDATA has been added on schema HR.
2026-07-26 09:41:07  INFO    OGG-10154  Schema level PREPARECSN set to mode NOWAIT on schema HR.

If you do not want instantiation CSN filtering for a schema, you can opt out explicitly with ADD SCHEMATRANDATA HR PREPARECSN NONE. It is the only way to get a table with zero rows in dba_apply_instantiated_objects after a load. Everything else on this page happens by default.

The full clause, PREPARECSN {WAIT | LOCK | NOWAIT | NONE}, controls how invasive the preparation is on a live table:

For an OLTP table with a lot of concurrent DML, WAIT or LOCK can stall application sessions while GoldenGate waits for or takes the lock. NOWAIT is almost always the correct option.

Confirm both tables are prepared:

OGG> INFO SCHEMATRANDATA HR
Schema HR has 2 prepared tables for instantiation.

2. Start the extract

Capture has to be running before the export, so that any change committed during and after the dump is safely in the trail:

OGG> START EXTRACT EXTA

3. Wait for long running transactions to finish

A transaction that began before the extract could be missed, so wait for every long running transaction to finish before exporting. See Checking Long Running Transactions in GoldenGate for how to list them with the adminclient and the REST API.

4. Export without FLASHBACK_SCN

expdp hr/*** dumpfile=hr.dmp schemas=HR

Without the FLASHBACK_SCN clause, each table’s boundary will be the SCN as of which Data Pump reads it during the export, recorded automatically because the table was prepared with PREPARECSN.

5. Import on the target

impdp gg_target/*** dumpfile=hr.dmp full=y

As part of this import, Data Pump populates dba_apply_instantiated_objects for every prepared table it loads. No extra option is needed.

6. Retrieve the instantiation CSN for each table

Let’s query the table that replaces the SCN you used to write down by hand:

SQL> SELECT source_object_owner, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'HR'
ORDER BY 1, 2;

SOURCE_OBJECT_OWNER SOURCE_OBJECT_NAME INSTANTIATION_SCN
------------------- ------------------ -----------------
HR                  DEPARTMENTS                 17662585
HR                  EMPLOYEES                   17662582

The two tables come from the same export, but with two different INSTANTIATION_SCN. Without FLASHBACK_SCN on the export, each table was read (and stamped) as the dump progressed. That per-table granularity is the entire point, and it is exactly what a single AFTERCSN could never express.

7. Configure the replicat and start it, without AFTERCSN

REPLICAT REPA
DBOPTIONS ENABLE_INSTANTIATION_FILTERING
USERIDALIAS gg_target DOMAIN OracleGoldenGate
MAP HR.*, TARGET HR.*;

OGG> START REPLICAT REPA

DBOPTIONS ENABLE_INSTANTIATION_FILTERING tells the replicat to look each table’s boundary in dba_apply_instantiated_objects instead of expecting an AFTERCSN on the start command. The replicat discards trail records committed at or before its boundary and applies everything after it. Both tables are in sync with the source, with no flashback SCN ever chosen.

Same initial load with FLASHBACK_SCN

Let’s run the same initial load again for a second schema, but add FLASHBACK_SCN to the export and watch what changes in the instantiation table. Pick an SCN and pass it to expdp:

expdp system/*** schemas=HR2 flashback_scn=17663448 dumpfile=hr2.dmp
impdp system/*** dumpfile=hr2.dmp full=y

Then the same step 6 query against the target:

SQL> SELECT source_object_owner, source_object_name, instantiation_scn
FROM dba_apply_instantiated_objects
WHERE source_object_owner = 'HR2'
ORDER BY 1, 2;

SOURCE_OBJECT_OWNER SOURCE_OBJECT_NAME INSTANTIATION_SCN
------------------- ------------------ -----------------
HR2                 DEPARTMENTS                 17663448
HR2                 EMPLOYEES                   17663448

This time, both tables carry the same instantiation CSN, and it is exactly the FLASHBACK_SCN (17663448). FLASHBACK_SCN pins the whole export to one consistent point in time, so Data Pump stamps every table in the dump with that single SCN. Please note that FLASHBACK_SCN is still not required for the instantiation mechanism to work. It only gives a consistent export.

Same initial load with PREPARECSN NONE

Let’s see what happens when we disable instantiation, by preparing a third schema with PREPARECSN NONE and run the same export and import:

OGG> ADD SCHEMATRANDATA HR3 ALLCOLS, PREPARECSN NONE
INFO OGG-10154  Schema level PREPARECSN set to mode NONE on schema "HR3"
OGG> INFO SCHEMATRANDATA HR3
Schema "HR3" has 0 prepared tables for instantiation

expdp system/*** schemas=HR3 dumpfile=hr3.dmp
impdp system/*** dumpfile=hr3.dmp full=y

The import succeeds and the rows land on the target as normal, but the instantiation table stays empty for this schema:

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

no rows selected

In that case, a replicat running with DBOPTIONS ENABLE_INSTANTIATION_FILTERING would find no boundary for these tables and therefore would not filter them. It would apply every trail record it sees, including changes the dump already contains.

The boundary outlives the schema

dba_apply_instantiated_objects is independent from the schema it describes. Dropping the target schema with DROP USER ... CASCADE and recreating it does not clear its row:

SQL> DROP USER hr4 CASCADE;

User dropped.

SQL> CREATE USER hr4 IDENTIFIED BY Welcome1;

User created.

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

SOURCE_OBJECT_OWNER SOURCE_OBJECT_NAME INSTANTIATION_SCN
------------------- ------------------ -----------------
HR4                 EMPLOYEES                   52356545

A stale boundary from a previous initial load can silently attach itself to the next import of an object with the same name. The same table, re-imported a second time from a dump whose source was never prepared with PREPARECSN, does not delete the row from the first prepared initial load.

A replicat with ENABLE_INSTANTIATION_FILTERING reading this table afterward would filter every record against a boundary that has no relationship to what the last import actually put on the target.

A command exists in the adminclient to clear the instantiation table:

OGG> DBLOGIN USERIDALIAS gg_target DOMAIN OracleGoldenGate
OGG> CLEAR INSTANTIATION CSN FOR hr.employees FROM PDB_SOURCE
INFO OGG-10464  Instantiation CSN has been cleared successfully.

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

no rows selected

Remember to check the dba_apply_instantiated_objects view before reusing a target schema name for an initial load.

When should I still set instantiation SCN by hand ?

There are multiple scenarios where automatic instantiation filtering does not work.

• If your initial load is not done by Data Pump. GoldenGate initial extract, a manual INSERT ... SELECT over a database link, transportable tablespaces, do not alter the dba_apply_instantiated_objects view.
• If the workload during the initial load is not just DML. Instantiation filtering does not work on DDL, for instance.

In that case, you can either go back to the FLASHBACK_SCN method, or set the instantiation CSN by hand in the adminclient:

OGG> DBLOGIN USERIDALIAS gg_target DOMAIN OracleGoldenGate
OGG> SET INSTANTIATION CSN FOR hr.legacy_orders CSN 12345678 FROM PDB_SOURCE

Common questions

A table added after PREPARECSN never gets a boundary

If a table is created on the source after you ran ADD SCHEMATRANDATA HR, it is not part of that preparation. Exporting it later with expdp means Data Pump has no CSN bookkeeping to carry into the dump, and dba_apply_instantiated_objects is not populated during import. The fix is to run ADD TRANDATA ... before exporting it.

Removing the parameter once instantiation is complete

DBOPTIONS ENABLE_INSTANTIATION_FILTERING can be removed from the replicat parameter file once it has processed every transaction past the instantiation CSN of every table it maps (there is no harm in leaving it in indefinitely).

Summary

• The instantiation CSN is a per-table replication boundary, stored in dba_apply_instantiated_objects on the target, compared against each record’s commit CSN.
• Data Pump stamps it automatically on impdp, because ADD SCHEMATRANDATA/ADD TRANDATA prepare tables for instantiation by default (PREPARECSN NOWAIT). Use PREPARECSN NONE to not use instantiation SCN.
• Because that boundary is per table and set by Data Pump, FLASHBACK_SCN and AFTERCSN are no longer needed just to define where the dump ends and replication begins. Retrieve the boundary with a query instead of tracking an SCN by hand.
• FLASHBACK_SCN still has a use (making one large export internally consistent), but it is no longer needed just to drive the replication boundary. Data Pump records that boundary either way.
• The boundary outlives the schema it describes. Dropping and recreating a target schema does not clear its row in dba_apply_instantiated_objects. Check the view, and use CLEAR INSTANTIATION CSN if you see stale rows.

L’article GoldenGate instantiation CSN explained est apparu en premier sur dbi Blog.

This blog covers multiple aspects, including latest changes introduced in GoldenGate 26ai:

• Difference between extract and replicat filtering
• DDL filtering model and syntax
• AND/OR logic
• DDLOPTIONS parameter
• Tag-based filtering (EXCLUDETAG/INCLUDETAG)
• Edge cases

Extract vs Replicat DDL filtering

Before diving into the syntax, you should understand that DDL filtering means something different for an extract and a replicat.

For an extract, filtering controls what gets written to the trail file. If a DDL statement is excluded at the extract level, it is gone forever, and will never reach any downstream replicat. This makes extract-level filtering absolute and decisive. On the other side, it keeps trail files smaller and ensures no downstream replicat ever sees unwanted DDL.

For a replicat, filtering controls what gets applied to the target database. In that case, the DDL statement is considered to be already in the trail file. The replicat simply chooses to apply it or skip it. This gives more flexibility. For instance, multiple replicats can read the same trail and each apply a different subset of DDL. Of course, the trail files are larger, and generate more I/O.

This does not mean that you should choose one or another. A common use case is to do generic filtering at the extract level (removing clearly irrelevant DDL like CREATE USER or GRANT), and more targeted filtering for each replicat (for example, suppressing TRUNCATE on a target holding additional rows).

Enabling DDL replication

DDL replication is disabled by default. You must explicitly enable it in both extract and replicat parameter files.

The simplest form is:

DDL

This enables DDL replication with no filtering. All DDL is captured (extract) or applied (replicat). In practice this is almost never what you want. You will almost always pair it with INCLUDE or EXCLUDE clauses.

Scopes: MAPPED, UNMAPPED, OTHER, ALL

Every DDL statement GoldenGate encounters is classified into one of four scopes based on whether the object it operates on matches your TABLE (extract) or MAP (replicat) parameter list.

If you do not specify a scope, GoldenGate defaults to ALL.

Example

With this extract parameter file:

EXTRACT EXT
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1
DDL INCLUDE ALL
TABLE APP_SCHEMA.*;

• CREATE TABLE APP_SCHEMA.ORDERS (...) is MAPPED (matches APP_SCHEMA.*)
• CREATE TABLE AUDIT_SCHEMA.LOGS (...) is UNMAPPED (does not match APP_SCHEMA.*)
• GRANT SELECT ON APP_SCHEMA.ORDERS TO READONLY is MAPPED (a GRANT on a specific object follows that object’s scope, not OTHER. OTHER is only for DDL with no target object at all, like CREATE USER)

Switching to DDL INCLUDE MAPPED would capture the first and third statements.

The DDL statement’s scope depends on the operation: see “Interaction with TABLE and MAP Parameters” below for more details.

Filter keywords

On top of scope filtering, you can also filter DDL by object type, operation type, object name, and DDL text content. These filters are specified as comma-separated conditions within a single DDL clause. All conditions in a single clause are added together (logical AND).

OBJTYPE

Filters by the type of database object the DDL operates on.

Common Oracle object types: TABLE, INDEX, SEQUENCE, VIEW, PROCEDURE, FUNCTION, TRIGGER, PACKAGE, TYPE, SYNONYM, DATABASE LINK, TABLESPACE, USER.

-- Only capture DDL on tables
DDL INCLUDE MAPPED, OBJTYPE 'TABLE'

-- Only capture DDL on indexes
DDL INCLUDE MAPPED, OBJTYPE 'INDEX'

OPTYPE

Filters by the type of DDL operation.

Common operation types: CREATE, ALTER, DROP, RENAME, TRUNCATE, GRANT, REVOKE, COMMENT.

-- Only capture CREATE TABLE statements
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE

-- Exclude DROP operations on all object types
DDL EXCLUDE MAPPED, OPTYPE DROP

OPTYPE RENAME exists and works, but classification depends on the exact SQL used. A RENAME old TO new; statement matches OPTYPE RENAME (GoldenGate logs OGG-10457 DDL RENAME found ... RENAME converted to ALTER TABLE while writing it, then classifies the resulting OGG-10451/OGG-10452 line as optype [RENAME]). But ALTER TABLE ... RENAME TO ... (the form most people write, since RENAME cannot be schema-qualified) matches OPTYPE ALTER instead, with no RENAME classification and no conversion message at all.

OBJNAME

Filters by object name. Supports wildcards (* for any sequence of characters, ? for a single character). For Oracle, use the schema.object format, or container.schema.object in multitenant. Write the value with no quotes at all. OBJNAME 'APP_SCHEMA.*' (single-quoted) abends with OGG-06377 Single quote marks cannot be used to delimit OBJNAME, and OBJNAME "APP_SCHEMA.*" (double-quoted) abends differently, with OGG-06585 No schema is specified. A double-quoted value is taken as one literal token and never splits on its dot into schema and object.

-- Only capture DDL for tables starting with ORD_ in APP_SCHEMA
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OBJNAME APP_SCHEMA.ORD_*

-- Exclude DDL on any staging table
DDL EXCLUDE MAPPED, OBJNAME APP_SCHEMA.*_STG

INSTR

Filters based on whether a literal string appears anywhere in the DDL text (case-sensitive). This is especially useful for excluding certain kinds of DDL.

-- Exclude any DDL containing NOLOGGING
DDL EXCLUDE MAPPED, INSTR 'NOLOGGING'

-- Exclude DDL referencing a specific tablespace by name
DDL EXCLUDE MAPPED, INSTR 'ARCHIVE_TBS'

INSTRWORDS

Similar to INSTR, but performs word-level matching. The order of the words does not matter, and partial matches within longer words are not counted.

-- Exclude DDL that contains both the words COMPRESS and OLTP (in any order)
DDL EXCLUDE MAPPED, INSTRWORDS 'COMPRESS OLTP'

EVENTACTIONS

Unlike the keywords above, EVENTACTIONS is not specific to DDL: it is a general GoldenGate keyword also usable on TABLE and MAP clauses, for triggering an action (REPORT, LOG, and others) whenever a record matches that clause. It happens to be usable inside a DDL clause too, comma-separated alongside OBJTYPE/OPTYPE/OBJNAME/INSTR like any other filter keyword, and it comes with real, DDL-specific behavior worth knowing.

EVENTACTIONS (REPORT) forces the same DDL replication statistics block that DDLOPTIONS REPORT writes on demand (see the DDLOPTIONS section below). However, it only works on an INCLUDE clause:

DDL INCLUDE MAPPED, EVENTACTIONS (REPORT)

2026-09-05 11:52:47  INFO    OGG-01487  DDL found, operation [create table ddltest.evt1 (id number) (size 37)], start SCN [24368602], commit SCN [24368634] instance [ (1)], DDL seqno [0], marker seqno [0].

2026-09-05 11:52:47  INFO    OGG-10451  DDL operation included [INCLUDE MAPPED, EVENTACTIONS (REPORT)], optype [CREATE], objtype [TABLE], catalog "PDB1", objowner "DDLTEST", objname "EVT1".

***********************************************************************
*                   ** Run Time Statistics **                         *
***********************************************************************


Report at 2026-09-05 11:52:47.388472 (activity since 2026-09-05 11:50:36.261708)

Output to dt:



DDL replication statistics:

                    Operations:         0
             Mapped operations:         0
           Unmapped operations:         0
              Other operations:         0
           Excluded operations:         0


No records extracted.

This is verbose. A second CREATE TABLE matching the same clause produced a second, identical-shaped block right after the OGG-10451 line. This means that every matching DDL gets a full statistics dump on top of the usual OGG-01487/OGG-10451/OGG-10452 lines. On a replication with any real amount of DDL traffic, this multiplies report file growth well past what DDLOPTIONS REPORT alone produces. Try to restrict EVENTACTIONS (REPORT) to a narrow INCLUDE clause: a specific OBJTYPE, OPTYPE, or OBJNAME you want to log in the report file.

Please note that the behavior is different for EXCLUDE clauses. The same EVENTACTIONS (REPORT) written on an EXCLUDE clause instead (see below example) excludes a TRUNCATE normally (OGG-10452 DDL operation excluded [EXCLUDE MAPPED, OPTYPE TRUNCATE, EVENTACTIONS (REPORT)]), but no DDL replication statistics block follows it.

DDL INCLUDE MAPPED &
    EXCLUDE MAPPED, OPTYPE TRUNCATE, EVENTACTIONS (REPORT)

AND/OR Logic

Only one DDL parameter is allowed per parameter file. A parameter file with two separate DDL lines abends at startup with OGG-00403 There can be only one DDL filtering statement: “Only one DDL parameter can be used in a parameter file, but you can combine multiple inclusion and exclusion options to filter the DDL to the required level.” Everything below happens inside that single DDL parameter: each clause after the first drops the leading DDL keyword and starts directly with INCLUDE or EXCLUDE, and the whole thing is continued with &.

AND: conditions within a single DDL clause

A DDL statement must satisfy all conditions to match.

-- Capture only CREATE TABLE in APP_SCHEMA (all three conditions must be true)
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE, OBJNAME APP_SCHEMA.*

A DROP TABLE APP_SCHEMA.ORDERS would not match this clause because OPTYPE DROP is different from OPTYPE CREATE.

OR: multiple INCLUDE/EXCLUDE clauses

Only one DDL parameter is allowed per parameter file, but that parameter can carry multiple INCLUDE/EXCLUDE clauses, separated with &. Multiple INCLUDE clauses are evaluated as a logical OR: a DDL statement is captured if it matches any INCLUDE clause. The indentation is optional.

-- Capture CREATE TABLE or CREATE SEQUENCE (either clause is sufficient)
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE CREATE

EXCLUDE always wins over INCLUDE

If a DDL statement matches both an INCLUDE clause and an EXCLUDE clause, the EXCLUDE wins. This lets you set broader INCLUDE rules and choose specific exceptions. An EXCLUDE clause always needs a corresponding INCLUDE clause in the same DDL parameter, it cannot stand alone.

-- Include all MAPPED DDL, but exclude TRUNCATE
DDL INCLUDE MAPPED &
    EXCLUDE MAPPED, OPTYPE TRUNCATE

A lone EXCLUDE clause with no corresponding INCLUDE still abends (OGG-06374 Invalid DDL statement: No INCLUDE). EXCLUDE narrows an INCLUDE; it cannot stand alone. Every multi-clause example in this post uses this single-DDL-parameter, &-continued form.

Filtering Examples

You can build nearly all sorts of DDL filtering in GoldenGate. But you should always ensure that they are relevant to the workload on the source and target databases !

Example 1: Structural DDL only, no destructive operations

Goal: replicate CREATE and ALTER on tables and sequences, but never DROP or TRUNCATE.

DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE ALTER &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE ALTER

Any DROP TABLE, TRUNCATE TABLE, or DROP SEQUENCE on a mapped object will be silently ignored.

Example 2: Everything except NOLOGGING directives

Here, the goal is to replicate all MAPPED DDL, but exclude any DDL containing the NOLOGGING directive.

DDL INCLUDE MAPPED &
    EXCLUDE MAPPED, INSTR 'NOLOGGING'

Example 3: Replicat applies only a subset of a rich trail

If a trail was generated with DDL INCLUDE ALL at the extract level, and you need the replicat to apply only CREATE TABLE and ALTER TABLE on mapped objects:

DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE ALTER
MAP APP_SCHEMA.*, TARGET TARGET_SCHEMA.*;

All other DDLs in the trail (DROP, TRUNCATE, index changes, sequences) are skipped by this replicat.

Example 4: Mapped objects plus a specific unmapped schema

-- Capture DDL for APP_SCHEMA (mapped) and also for SHARED_SCHEMA (not in the TABLE filtering)
DDL INCLUDE MAPPED &
    INCLUDE UNMAPPED, OBJNAME SHARED_SCHEMA.* &
    EXCLUDE MAPPED, OPTYPE TRUNCATE &
    EXCLUDE UNMAPPED, OPTYPE DROP
TABLE APP_SCHEMA.*;

DDLOPTIONS parameter

DDLOPTIONS often comes with DDL and controls what happens when DDL is processed. It is a global setting which applies to all DDL replication.

REPORT

Writes each DDL statement encountered (whether included or excluded) to the extract or replicat report file.

DDLOPTIONS REPORT

With DDL INCLUDE ALL, a CREATE TABLE DDLTEST.PROMOTIONS on the source produces entries like these in the report file:

2026-09-05 16:10:12  INFO    OGG-01487  DDL found, operation [create table ddltest.promotions (id number, discount number) (size 60)], start SCN [23026101], commit SCN [23026117] instance [ (1)], DDL seqno [0], marker seqno [0].
2026-09-05 16:10:12  INFO    OGG-10451  DDL operation included [INCLUDE ALL], optype [CREATE], objtype [TABLE], catalog "PDB1", objowner "DDLTEST", objname "PROMOTIONS".

This is very useful for testing, or when the DDL volume is low. However, never include DDLOPTIONS REPORT if you have a lot of DDLs. Your report files will grow without control.

A running process also keeps a running count of DDL statements by scope, separate from the per-statement DDLOPTIONS REPORT lines above. Request it on demand with SEND EXTRACT <name>, REPORT (or SEND REPLICAT <name>, REPORT) through the adminclient. It also gets written automatically whenever the process stops.

***********************************************************************
*                   ** Run Time Statistics **                         *
***********************************************************************

Report at 2026-09-05 11:34:23.315905 (activity since 2026-09-05 11:31:27.204191)

DDL replication statistics:

                    Operations:         1
             Mapped operations:         1
           Unmapped operations:         0
              Other operations:         0
           Excluded operations:         0

The report (Mapped/Unmapped/Other/Excluded) mirrors the scope model from the “Scopes” section above, so it is a quick way to check whether your filtering is doing what you expect without scrolling through every individual OGG-01487/OGG-10451/OGG-10452 line.

DDLERROR (replicat only)

Controls what happens when a DDL statement fails on the target. The default is to abend.

DDLERROR DEFAULT DISCARD

DDLERROR is a top-level parameter, not a DDLOPTIONS sub-keyword. As you can imagine, use DISCARD with caution. It could silently leave the target schema out of sync.

Tag-based DDL filtering: EXCLUDETAG and INCLUDETAG

Oracle GoldenGate 26ai adds a second, independent filtering layer on top of everything above. You can now filter by tag rather than by scope or object. Every DDL statement GoldenGate encounters carries a tag identifying its origin.

By default, an extract applies DDLOPTIONS EXCLUDETAG +, which excludes all tagged DDL unless a tag is explicitly allowed with INCLUDETAG:

-- Exclude every tagged DDL statement by default (implicit default)
DDLOPTIONS EXCLUDETAG +

-- Explicitly allow DDL carrying tag 00 (Data Pump)
DDLOPTIONS INCLUDETAG 00

The practical impact is on tools that stamp a session tag on the DDL they issue. For instance, impdp tags its DDL with tag 00. Under GoldenGate 26ai default behavior, that DDL is excluded from replication unless the extract explicitly adds DDLOPTIONS INCLUDETAG 00. Please note that this is a behavioral change from earlier versions of GoldenGate. Before, impdp DDL was captured without any extra configuration needed. If an import via impdp is expected to replicate its DDL, check for this setting before assuming the default behavior still applies.

EXCLUDETAG/INCLUDETAG do not replace the scope and filter-keyword model. A DDL statement still has to pass the DDL INCLUDE/DDL EXCLUDE scope and keyword filtering described above. Both filtering systems have to allow the DDL.

Interaction with TABLE and MAP parameters

Here are the scope (MAPPED/UNMAPPED/…) assignment rules for standard TABLE DDL.

Edge cases

DDL errors from cascading object dependencies

Some DDL operations have cascading effects that GoldenGate does not replicate automatically.

Source action:

DROP TABLE DDLTEST.CUSTOMERS CASCADE CONSTRAINTS;

GoldenGate captures and replicates the DROP TABLE. On the source, any views or constraints that depended on DDLTEST.CUSTOMERS are automatically dropped or invalidated. On the target, dependent objects created outside of the GoldenGate replication remain, as invalid objects.

For instance, if you create a view named DDLTEST_TGT.CUSTOMERS_V directly on the target (outside of GoldenGate) on DDLTEST_TGT.CUSTOMERS, the DROP TABLE ... CASCADE CONSTRAINTS on the source replicates and applies cleanly:

2026-09-05 20:23:38  INFO    OGG-00482  DDL found, operation [drop table ddltest.customers cascade constraints].
2026-09-05 20:23:38  INFO    OGG-00489  DDL is of mapped scope, after mapping new operation [drop table "DDLTEST_TGT"."CUSTOMERS" cascade constraints].
2026-09-05 20:23:38  INFO    OGG-10451  DDL operation included [INCLUDE MAPPED], optype [DROP], objtype [TABLE], catalog "PDB1", objowner "DDLTEST_TGT", objname "CUSTOMERS".
2026-09-05 20:23:38  INFO    OGG-00484  Executing DDL operation.
2026-09-05 20:23:38  INFO    OGG-00483  DDL operation successful.

But DDLTEST_TGT.CUSTOMERS_V is left behind, now referencing a table that no longer exists:

SQL> SELECT object_name, object_type, status
FROM dba_objects
WHERE owner = 'DDLTEST_TGT'
AND object_name = 'CUSTOMERS_V';

OBJECT_NAME OBJECT_TYPE STATUS
----------- ----------- -------
CUSTOMERS_V VIEW        INVALID

There is no built-in GoldenGate mechanism for cascading DDL effects. You must either manage dependent objects manually, or filter the DROP and handle cleanup separately.

Complete parameter file examples

Here is an example of an extract/replicat pair, and how you could build complex DDL handling.

EXTRACT EXT
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1

-- Capture structural DDL on mapped objects, exclude storage directives,
-- and also capture DDL on a shared utility schema not in the TABLE list
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE ALTER &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE RENAME &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'SEQUENCE', OPTYPE ALTER &
    EXCLUDE MAPPED, INSTR 'NOLOGGING' &
    EXCLUDE MAPPED, INSTR 'COMPRESS' &
    INCLUDE UNMAPPED, OBJNAME SHARED_SCHEMA.*, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE UNMAPPED, OBJNAME SHARED_SCHEMA.*, OBJTYPE 'TABLE', OPTYPE ALTER

-- Write DDL activity to the report file for auditing
DDLOPTIONS REPORT

TABLE APP_SCHEMA.*;
TABLE SHARED_SCHEMA.*;

REPLICAT REP
USERIDALIAS target_db DOMAIN OracleGoldenGate

-- Apply only CREATE and ALTER TABLE on mapped objects, plus shared-schema DDL;
-- skip sequences, drops, truncates, etc.
DDL INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE CREATE &
    INCLUDE MAPPED, OBJTYPE 'TABLE', OPTYPE ALTER &
    INCLUDE MAPPED, OBJNAME SHARED_SCHEMA.*

-- Write DDL activity to report file
DDLOPTIONS REPORT

-- Write discarded/failed DDL to discard file rather than abending
DDLERROR DEFAULT DISCARD

MAP APP_SCHEMA.*, TARGET TARGET_SCHEMA.*;
MAP SHARED_SCHEMA.*, TARGET SHARED_SCHEMA.*;

Summary

DDL filtering in GoldenGate is a layered system:

• Scope (MAPPED/UNMAPPED/OTHER/ALL) restricts DDL replication, based on your TABLE/MAP configuration
• Filter keywords (OBJTYPE, OPTYPE, OBJNAME, INSTR, INSTRWORDS) restricts DDL replication within the scope
• Only one DDL parameter is allowed per parameter file, but it can carry multiple INCLUDE/EXCLUDE clauses continued with &. AND logic applies within a single clause, while OR logic applies across clauses. EXCLUDE always wins over INCLUDE and always needs a corresponding INCLUDE
• DDLOPTIONS controls what happens when DDL is captured or replicated.
• Extract filtering is irreversible. You should filter at the replicat level when multiple replicats need different DDL settings.

L’article DDL filtering in GoldenGate extract and replicat est apparu en premier sur dbi Blog.

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

I had to dig further, looking into the Enterprise Manager SYSMAN schema.

Metric extensions are not stored under MGMT$ views

At first, I checked in the MGMT$ views, in the SYSMAN schema. They usually hold all the relevant information you need when doing automation with the Enterprise Manager. The documentation gave me nothing about Metric Extensions there, and I did not find anything either:

SQL> SELECT owner, object_name, object_type
FROM dba_objects
WHERE owner = 'SYSMAN'
AND UPPER(object_name) LIKE '%EXTENSION%'
ORDER BY object_name;

OWNER  OBJECT_NAME       OBJECT_TYPE
------ ----------------- ------------
SYSMAN EM_TYPE_EXTENSION PACKAGE
SYSMAN EM_TYPE_EXTENSION PACKAGE BODY

After a lot of searching, I found the undocumented MEXT views, where all the information on Metric Extensions is stored.

SELECT owner, object_name, object_type
FROM dba_objects
WHERE object_name LIKE '%MEXT%'
AND object_type IN ('TABLE', 'VIEW')
ORDER BY object_name;

This query returns more than a hundred objects. Among them, you can find a EM_MEXT_VERSIONS table.

EM_MEXT_VERSIONS is the catalog

EM_MEXT_VERSIONS has one row per Metric Extension. Drafts, editable versions and published metrics are all stored here, with the same name column.

SQL> DESC sysman.em_mext_versions

Name            Null?    Type
--------------- -------- -------------
MEXT_VERSION_ID NOT NULL NUMBER
TARGET_TYPE     NOT NULL VARCHAR2(256)
NAME            NOT NULL VARCHAR2(64)
VERSION         NOT NULL NUMBER
DISPLAY_NAME    NOT NULL VARCHAR2(64)
STATUS          NOT NULL NUMBER(2)
CREATION_DATE            DATE
...

Using a few useful columns, let’s see what’s inside:

SQL> SELECT name, version, display_name, target_type, status, creation_date
FROM sysman.em_mext_versions
ORDER BY name, version;

NAME                          VERSION DISPLAY_NAME         TARGET_TYPE STATUS CREATION_DATE
----------------------------- ------- -------------------- ----------- ------ -------------
ME$minimal_uptime_check             1 Minimal Uptime Check host             2 24-AUG-26
ME$minimal_uptime_check             2 Minimal Uptime Check host             2 24-AUG-26
ME$minimal_uptime_check_clone       1 Minimal Uptime Check host             2 24-AUG-26

Every Metric Extension name starts with the ME$ prefix. If you ever created a Metric Extension by hand in the web UI, the prefix is automatically added in the creation wizard. Regarding the status column, they are defined in the SYSMAN.EM_MEXT package:

• 0 – MEXT_STATUS_EDITABLE: for Metric Extensions still under development. They can still be edited, but can’t be deployed to targets.
• 1 – MEXT_STATUS_DEPLOYABLE_DRAFT: for Metric Extensions which can’t be edited anymore, but can be deployed. Accessible only to you.
• 2 – MEXT_STATUS_PUBLISHED: for published Metric Extensions, accessible by any EM user.

Every row above shows status = 2, meaning that all versions were published.

You can of course combine multiple SYSMAN views to retrieve the list of Metric Extensions and the targets they are deployed on:

SQL> SELECT t.target_name, t.target_type, v.name AS metric_name, v.version, v.display_name AS metric_display_name
FROM sysman.em_mext_versions v
JOIN sysman.em_mext_target_assoc ta ON ta.mext_version_id = v.mext_version_id
JOIN sysman.mgmt$target t ON t.target_guid = ta.target_guid
ORDER BY t.target_name, v.name, v.version;

TARGET_NAME TARGET_TYPE METRIC_NAME             VERSION METRIC_DISPLAY_NAME
----------- ----------- ----------------------- ------- --------------------
vmogg       host        ME$minimal_uptime_check       1 Minimal Uptime Check
...

How to know what a metric extension runs ?

If a Metric Extension runs OS commands, querying SYSMAN.EM_MEXT_VERSIONS is enough to know everything about it. This becomes wrong if the Metric Extension carries a custom uploaded script or runs against the repository instead of a target. For these Metric Extensions, you should query SYSMAN.EM_MEXT_ATTACHMENTS, where the FILENAME gives you the name of the script being shipped with the metric:

SQL> DESC sysman.em_mext_attachments

Name            Null?    Type
--------------- -------- -------------
MEXT_VERSION_ID NOT NULL NUMBER
FILENAME        NOT NULL VARCHAR2(255)
FILE_CONTENTS            BLOB

I cloned ME$minimal_uptime_check with Create Like, then in the Adapter step changed the command from a literal /bin/echo to %perlBin%/perl running an uploaded script, referenced as %scriptsDir%/uptime_check.pl. Custom files are attached from the same step, in the Upload Custom Files panel:

Once confirmed, the file shows up in the adapter’s file list with its size, and gets packaged into the Metric Extension itself:

Querying the repository afterward confirms it landed exactly where the package source implied:

SQL> SELECT v.name, v.version, a.filename, DBMS_LOB.GETLENGTH(a.file_contents) AS bytes
FROM sysman.em_mext_versions v
JOIN sysman.em_mext_attachments a ON a.mext_version_id = v.mext_version_id
WHERE v.name = 'ME$script_uptime_check';

NAME                   VERSION FILENAME        BYTES
---------------------- ------- --------------- -----
ME$script_uptime_check       1 uptime_check.pl    39

Retrieving the full metric definition

There are a few other relevant LOB columns in SYSMAN.EM_MEXT_VERSIONS: METADATA_DEFINITION, COLLECTION_DEFINITION and MEXT_ARCHIVE. Selecting METADATA_DEFINITION for minimal_uptime_check returns the whole <Metric> definition as XML:

SQL> SELECT metadata_definition
FROM sysman.em_mext_versions
WHERE name = 'ME$minimal_uptime_check'
AND version = 1;

<Metric NAME="ME$minimal_uptime_check" TYPE="TABLE">
    <Display>
        <Label NLSID="NLS_METRIC_hostME$minimal_uptime_check">Minimal Uptime Check</Label>
        <Description NLSID="NLS_DESCRIPTION_hostME$minimal_uptime_check">Minimal test ME - single OS command column, no credentials.</Description>
    </Display>
    <TableDescriptor>
        <ColumnDescriptor NAME="value" TYPE="NUMBER">
            <Display>
                <Label NLSID="NLS_COLUMN_hostME$minimal_uptime_checkvalue">Value</Label>
            </Display>
        </ColumnDescriptor>
    </TableDescriptor>
    <QueryDescriptor FETCHLET_ID="OSLineToken">
        <Property NAME="command" SCOPE="GLOBAL">/bin/echo</Property>
        <Property NAME="scriptLoc" SCOPE="GLOBAL" OPTIONAL="TRUE">%scriptsDir%</Property>
        <Property NAME="args" SCOPE="GLOBAL" OPTIONAL="TRUE">em_result=1</Property>
        <Property NAME="delimiter" SCOPE="GLOBAL" OPTIONAL="TRUE">|</Property>
        <Property NAME="startsWith" SCOPE="GLOBAL" OPTIONAL="TRUE">em_result=</Property>
        <Property NAME="ENVEM_TARGET_NAME" SCOPE="INSTANCE" OPTIONAL="TRUE">NAME</Property>
        <CredentialRef NAME="OSCreds"></CredentialRef>
    </QueryDescriptor>
</Metric>

A few observations here:

• FETCHLET_ID="OSLineToken" is the fetchlet
• command, args, delimiter and startsWith are the fields filled when creating the metric.

Another column, COLLECTION_DEFINITION, gives the schedule of the Metric Extension. Here, it is set to run every 15 minutes, which is the default schedule for Metric Extensions.

SQL> SELECT collection_definition
FROM sysman.em_mext_versions
WHERE name = 'ME$minimal_uptime_check'
AND version = 1;

<CollectionItem NAME="ME$minimal_uptime_check" UPLOAD="YES">
	<Schedule>
		<IntervalSchedule INTERVAL="15" TIME_UNIT="Min"/>
	</Schedule>
	<MetricColl NAME="ME$minimal_uptime_check">
	</MetricColl>
</CollectionItem>

Finally, MEXT_ARCHIVE holds the whole archive as a single BLOB. Exporting it to a file with UTL_FILE gives us a .zip file which holds the full definition of the Metric Extension. But you don’t need to do all of this, because this is the exact same zip that emcli export_metric_extension generates.

A side note on repository-side Metric Extensions, which can also be created from the web UI. For these, there are a few pre-requisites: TARGET_GUID must be the first column, the query can only reference MGMT$ repository views (not other SYSMAN tables), and it runs as the MGMT_VIEW user.

Querying SYSMAN.EM_MEXT_VERSIONS gives you the full SQL query, under the REPOS_SQL column. Use IS_REPOSITORY to filter repository-side Metric Extensions.

SQL> SELECT name, version, is_repository, repos_sql
FROM sysman.em_mext_versions
WHERE name = 'ME$sql_target_count';

NAME                VERSION IS_REPOSITORY REPOS_SQL
------------------- ------- ------------- --------------------------------------------------------------------------------------------
ME$sql_target_count       1             1 SELECT target_guid, target_type, 1 AS host_count FROM mgmt$target WHERE target_type = 'host'

I hope this will help you navigate Metric Extensions outside of the web UI, for automation work. This gave us a first glimpse of the archive format, which deserves a closer look.

L’article Listing and querying Oracle Enterprise Manager metric extensions est apparu en premier sur dbi Blog.

Oracle uses some configuration files (*.ora) related to the network.

• tnsnames.ora: A mapping of an alias name to a connect string for Oracle. A kind of “/etc/hosts” for Oracle databases
• ldap.ora: Configuration of ldap servers to use. A kind of “/etc/resolv.conf” for Oracle products.
• sqlnet.ora: General network settings like domain, timeout-parameters, wallet-location and more.
• listener.ora: Configuration of the listeners

Location of the *.ora files used

Per default, Oracle will look for these files in $ORACLE_HOME/network/admin; If you have more than one ORACLE_HOME, then you have to maintain it for each home, or you can create symbolic links to the “master” file.

And if you use Readonly-Oracle-Home (“rooh”, roohctl -enable). That is a great feature to relocate all database- and configuration specific files from the software directory to the ORACLE_BASE. The dbs-directories of all homes will be centralized in $ORACLE_BASE/dbs, and the home-specific configuration- and log-files will be moved to the ORACLE_BASE/homes/homename. With rooh enabled, Oracle looks for the TNS configuration in $ORACLE_BASE/homes/homename/network/admin; homename is the name in the oraInventory. To show the current top-level directory, use

oracle>  orabasehome
/u00/app/oracle/homes/OraDB23Home4

Instead of the default, depending on the ORACLE_HOME, you can set the variable TNS_ADMIN in your environment to a central directory containing above *.ora files.

oracle>  export TNS_ADMIN=/u01/app/oracle/network/admin

If this variable is set, then Oracle uses this directory instead of the default $ORACLE_HOME/network/admin or orabasehome/network/admin.

In this context, “Oracle” means the binary you use. If $TNS_ADMIN is set in the shell where the binary is started, it takes the value of it to look for Oracle’s network files.

If you use sqlplus, then it looks for the *.ora files in $TNS_ADMIN to resolve the given connect alias of your connect string.

If you start the Oracle database-instance, then it uses the *.ora files in $TNS_ADMIN to resolve connect aliases for database links and data guard connects. If unset, it uses the default location as fallback.

In summary the priority of the TNS locations:

1. $TNS_ADMIN, if it is set
2. $ORACLE_BASE/homes/<home_name>/network/admin, if readonly-oracle_home is activated
3. $ORACLE_HOME/network/admin

Find out the TNS location that is used

tnsping

For sqlplus it is easy to find out what it will use. You can check it before start in your shell with tnsping:

oracle>  tnsping DB01

TNS Ping Utility for IBM/AIX RISC System/6000: Version 19.0.0.0.0 - Production on 12-DEC-2025 09:16:10

Copyright (c) 1997, 2025, Oracle.  All rights reserved.

Used parameter files:
/u01/app/oracle/network/sqlnet.ora

Used LDAP adapter to resolve the alias
Attempting to contact (DESCRIPTION=...)

“Used parameter files” shows the directory it looks for the *.ora files.

If we start an instance interactively with sqlplus, we also know the location, as described above.

But caution: If you use Grid Infrastructrue (clusterware) and you start the instance with “srvctl”, then a TNS_ADMIN in your current shell is irrelevant. The instance is started by clusterware in background and it uses a minimal shell. It does not source the shell-profile of Oracle (.profile, .bash_profile), so probably your TNS_ADMIN is unknown to clusterware.

That means, if a database is started interactively or via clusterware, it may behave differently. Maybe with one method db-links are working, with the other not.

Best practice: Alwas start database instances with the same mechanism. If using clusterware, always use srvctl to start it.

But if we have issuses with connects of db-links or Data Guard, how we can find out what directory the instance uses to look for the network files?

OS-tools

On the database server, we can find it out by OS tools:

Get the process-ID of an instance-process, e.g. pmon (ps -ef |grep pmon_$ORACLE_SID)

Then, for this process-ID we can show the environment-variables of this process (ps eww ID) and look for TNS_ADMIN. If we do not find it, TNS_ADMIN is the default $ORACLE_HOME/network/admin or $ORACLE_BASE/homes/homename/network/admin

ps eww `ps -ef |grep -v grep|grep pmon_$ORACLE_SID|awk '{print $2}'`  \
   | grep TNS_|sed -e 's/.*TNS_ADMIN=//' |sed -e 's/ .*$//g'

Caution! On Linux, often it does not work for the process owner oracle, even if /proc/<pid>/environment shows readable for Oracle. If $ORACLE_HOME/bin/oracle has the suid-bit (-rws-s–x), the kernel blocks the access. In this case, you need root privileges to run above command. If the 1st line (without \) does not return any variables, then you are affected by this security limitation.

Inside the database

But, can we find it out by connecting to the database by running the following code?

set serveroutput on;
DECLARE
  V_ENVIROMENT VARCHAR2(500);
BEGIN
  SYS.DBMS_SYSTEM.GET_ENV('TNS_ADMIN', V_ENVIROMENT);
  DBMS_OUTPUT.PUT_LINE('TNS_ADMIN='||V_ENVIROMENT);
END;
/

Unfortunately not. The Oracle process connecting the database inherits the environment of our environment. For a direct connect (/ as sysdba) it is our shell-environment, for a remote-connect (@sqlnet-alias) it is the environment of the listener. This way we get the TNS_ADMIN environment of our process, and not that of the server processes.

But how can we get the environment of the running server processes? For this we need a little trick: We make the query via a DBMS_SCHEDULER job. This means that it is executed via a server process.

 DBMS_SCHEDULER.create_job (
      job_name   => 'TNS_ADMIN',
      job_type   => 'PLSQL_BLOCK',
      job_action => q'[
        DECLARE
          v_tns_admin VARCHAR2(4000);
        BEGIN
          DBMS_SYSTEM.GET_ENV('TNS_ADMIN', v_tns_admin);
          DBMS_OUTPUT.PUT_LINE(v_tns_admin);
        END;
      ]',
      start_date => SYSTIMESTAMP,
      enabled    => TRUE,
      auto_drop  => TRUE
    );

The result can be found in ALL_SCHEDULER_JOB_RUN_DETAILS. Relevant are only records after startup time, because the environment can only be changed at startup. That’s why we should get exactly 1 result with “distinct”.

select distinct output from ALL_SCHEDULER_JOB_RUN_DETAILS 
where job_name='TNS_ADMIN' 
and log_date > (select startup_time from v$instance);

An empty result means that the TNS_ADMIN variable was not set and the database is using the default (see above).

Debugging name resolution problems

Next time, if you get errors using a database link in a scheduled job (using the server processes environment):

ORA-12154: TNS:could not resolve the connect identifier specified

Check what the database link will connect to (e.g. DB01.domain) and what TNS_ADMIN (or default-value) your database is using.

For Data Gurad debugging it is not so easy. For the primary site above trick works, but not on the standby site. It is mounted or read-only. If you have root-access, you can check the environment file of the process (see above). Otherwise I recommend to restart the standby database, then you know what TNS_ADMIN was set.

L’article TNS_ADMIN – which *.ora files Oracle will use est apparu en premier sur dbi Blog.

I found it a very good question. From the user’s perspective, both methods look similar: the Forms application opens in its own Java window. The real difference is how the application is launched, deployed, secured, and maintained on the workstation.

Here is the practical answer, based on experience with Oracle Forms environments.

First, both methods use the same Forms architecture

Whether you use Java Web Start or FSAL:

• The Forms application remains hosted centrally on the application server.
• The .fmx, .mmx, and .plx modules stay on the server.
• A Java-based Forms client runs on the user’s workstation.
• The client communicates with Oracle Forms Services, generally hosted on WebLogic Server.
• The application itself normally does not need to be rewritten when changing the launch method.

Therefore, FSAL is not a return to the old Forms 6i client/server architecture. It only provides a similar desktop experience,

Java Web Start

Java Web Start, or JWS, launches the application using a JNLP file.

The user normally opens a Forms URL:

https://forms.example.com/forms/frmservlet?config=webstart

The server generates a .jnlp file, which is downloaded and opened by Java Web Start. The Forms application then runs in a separate Java window.

Oracle describes Java Web Start as a semi-browserless configuration: the browser can be used to initiate the application, but the application does not run inside the browser window.

Advantages of Java Web Start

• Users can start the application from a familiar web link.
• The JNLP configuration is generated centrally by the Forms server.
• Java archives can be downloaded and cached automatically.
• It can integrate well with environments where authentication starts in the browser.
• It usually requires limited change when replacing an older browser-based Forms deployment.

Disadvantages of Java Web Start

• It depends on Java Web Start technology, which is associated mainly with Java 8.
• Java Web Start is no longer included in modern JDK releases.
• JNLP file associations can behave differently depending on the workstation and browser.
• Browser security settings may prevent the JNLP file from opening automatically.
• Java cache problems are relatively common.
• Certificate changes, proxies, and local Java security settings can affect application startup.
• Troubleshooting frequently involves the user’s workstation rather than the Forms server.

My experience with Java Web Start

Once correctly configured, Java Web Start works well. However, many operational incidents are related to the client environment:

• The .jnlp file is downloaded but not opened.
• The workstation uses the wrong Java version.
• The operating system loses the JNLP file association.
• An old JAR remains in the Java cache.
• A certificate renewal causes a new security warning.
• Browser updates change how downloaded JNLP files are handled.

These are rarely Forms application problems, but they still generate support requests.

When should you choose Java Web Start?

Java Web Start remains reasonable when:

• The organization already has a stable and managed Java 8 environment.
• The existing JWS deployment works reliably.
• Users need to launch Forms from a browser-based portal.
• The authentication or SSO process requires a browser.
• The objective is a short-term migration with minimal client-side change.

I would be more cautious about selecting JWS for a completely new, long-term deployment because of its dependency on legacy Java deployment technology.

Forms Standalone Launcher

The Forms Standalone Launcher, or FSAL, launches Oracle Forms without relying on a browser or Java Web Start.

The workstation runs the frmsal.jar launcher directly:

java -jar frmsal.jar -url "https://forms.example.com/forms/frmservlet?config=standaloneapp"

In practice, users do not need to enter this command. It can be included in a desktop shortcut, shell script, batch file, or software deployment package.

Advantages of FSAL

• It is fully independent of the browser.
• It does not require Java Web Start or a browser plug-in.
• It provides a clean desktop application experience.
• Browser updates do not affect the application launch.
• The startup command can be standardized and controlled by the IT team.
• Java parameters, memory settings, truststores, and logging can be explicitly configured.
• It is generally easier to reproduce and troubleshoot startup issues.
• It aligns better with current Java versions and Oracle’s modern Forms direction.

Disadvantages of FSAL

• The frmsal.jar launcher must be distributed to every workstation.
• The launcher version must match the Oracle Forms server version and patch level.
• IT must maintain the desktop shortcut or startup script.
• Java and the required certificates must be correctly deployed on each workstation.
• Updating or patching Forms may require redistributing frmsal.jar.
• SSO, single sign-off, JavaScript integration, and communication with web pages require careful validation.
• The initial workstation packaging may require more preparation than simply publishing a URL.

My experience with FSAL

FSAL generally requires more preparation during the initial rollout. The Java runtime, frmsal.jar, truststore, startup parameters, and shortcut must be packaged correctly.

Once that work is completed, the result is usually more predictable.

The application is no longer affected by browser behavior, JNLP file associations, or Java Web Start cache issues. When a startup problem occurs, the launch command and console output also provide a clearer troubleshooting path.

One important operational point is the management of frmsal.jar. It should not be treated as a generic launcher that can be reused forever. It is version-specific and must remain aligned with the Forms installation.

When should you choose FSAL?

FSAL is generally the better choice when:

• You are implementing a new Oracle Forms deployment.
• You are upgrading to a recent Oracle Forms release.
• You want to remove browser dependencies.
• You want to use a modern and centrally managed Java runtime.
• Workstations are managed using tools such as Microsoft Intune, SCCM, or another software distribution platform.
• You need predictable startup parameters and easier troubleshooting.
• Forms is primarily used as a business desktop application.

Direct comparison

My recommendation

For an existing, stable Java Web Start environment, I would not migrate to FSAL only for the sake of changing technology. The migration should provide a clear operational or security benefit.

For a new deployment or a major Oracle Forms upgrade, I would generally choose FSAL.

It removes the browser and Java Web Start dependencies, gives the IT team better control over the client runtime, and provides a more predictable operational model.

The final choice should nevertheless be validated against:

• The Oracle Forms version
• The certified client Java version
• The SSO implementation
• WebUtil and custom JAR usage
• JavaScript integration
• Proxy and TLS requirements
• The workstation deployment strategy

The key point is simple: Java Web Start is easier to expose through a URL, while FSAL is easier to control as a managed desktop application.

Oracle documentation

• Oracle Forms 12.2.1.4 – Client Configurations, Java Web Start and FSAL
• Oracle Forms 14.1.2 – Forms Standalone Launcher
• Oracle Forms 14.1.2 – Working with Oracle Forms

L’article Oracle Forms: Java Web Start or FSAL? est apparu en premier sur dbi Blog.