{"id":47508,"date":"2026-10-05T07:00:44","date_gmt":"2026-10-05T05:00:44","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/?p=47508"},"modified":"2026-10-05T07:00:53","modified_gmt":"2026-10-05T05:00:53","slug":"goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/","title":{"rendered":"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load"},"content":{"rendered":"\n

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

And it works. The replicat creates the missing table itself, with a default datatype mapping, and loads the rows in the target.<\/p>\n\n\n\n

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

How it works<\/h2>\n\n\n\n

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

The replicat does not need anything from the source database. It builds the CREATE TABLE<\/code> statement from the Table Definition Record<\/strong> (TDR) that GoldenGate already writes in the trail file.<\/p>\n\n\n\n

AUTOSCHEMA<\/code> is a replicat-only option of DDL<\/code>: the DDL<\/code> parameter of the extract does not accept it. I put DDL AUTOSCHEMA INCLUDE ALL<\/code> in the extract\u2019s parameter file. The extract abends at startup with the same parsing error as an unrecognized keyword:<\/p>\n\n\n\n

2026-09-26T05:54:27Z  ERROR   OGG-10151  (EXTPGL.prm) line 3: Parsing error, parameter [DDL] has unrecognized keyword or extra value \"AUTOSCHEMA\".<\/code><\/pre>\n\n\n\n
That makes sense given what the feature does. It creates missing tables on the target, and the extract never touches the target database.<\/p>\n\n\n\n
The setup<\/h2>\n\n\n\n
    \n
  • Source: Oracle 19c, PDB1<\/code>, schema AUTOSCH<\/code>, table AUTOSCH.T1<\/code> with 5 rows, managed by the 26ai deployment ogg_test_01<\/code> in GoldenGate 23.26.3.0.0<\/code>.<\/li>\n\n\n\n
  • Target: PostgreSQL 16, database pgstore<\/code>, an empty schema autosch<\/code>, managed by a separate<\/strong> deployment ogg_pg_01<\/code> from GoldenGate for PostgreSQL 23.26.3.0.1<\/code>.<\/li>\n<\/ul>\n\n\n\n
    The source table:<\/p>\n\n\n\n
    CREATE TABLE autosch.t1 (\n    id NUMBER PRIMARY KEY,\n    name VARCHAR2(50),\n    amount NUMBER(10,2),\n    created DATE DEFAULT SYSDATE\n);<\/code><\/pre>\n\n\n\n
    For the initial load, on the ogg_test_01<\/code> deployment, EXTPGL<\/code> is added as a SOURCEISTABLE<\/code> extract.<\/p>\n\n\n\n
    OGG (http:\/\/localhost:7810 ogg_test_01) 2> DBLOGIN USERIDALIAS pdb1 DOMAIN OracleGoldenGate\nSuccessfully logged into database PDB1.\n\nOGG (http:\/\/localhost:7810 ogg_test_01 as pdb1@CDB01\/PDB1) 3> ADD EXTRACT EXTPGL, SOURCEISTABLE\n2026-09-26T05:53:26Z  INFO    OGG-08100  Extract added.\n\nOGG (http:\/\/localhost:7810 ogg_test_01 as pdb1@CDB01\/PDB1) 4> EDIT PARAMS EXTPGL\n2026-09-26T05:53:26Z  INFO    OGG-10183  Parameter file EXTPGL.prm passed validity check.\n\nOGG (http:\/\/localhost:7810 ogg_test_01 as pdb1@CDB01\/PDB1) 5> VIEW PARAMS EXTPGL\nEXTRACT EXTPGL\nUSERIDALIAS pdb1 DOMAIN OracleGoldenGate\nEXTFILE p1 MEGABYTES 100 PURGE\nTABLE AUTOSCH.T1;\n\nOGG (http:\/\/localhost:7810 ogg_test_01 as pdb1@CDB01\/PDB1) 6> START EXTRACT EXTPGL\n2026-09-26T05:53:26Z  INFO    OGG-00975  Extract group EXTPGL starting.\n2026-09-26T05:53:26Z  INFO    OGG-15426  Extract group EXTPGL started.<\/code><\/pre>\n\n\n\n
    The extract report confirms the 5 rows went out to the file:<\/p>\n\n\n\n
    Report at 2026-09-26 05:53:26 (activity since 2026-09-26 05:53:26)\n\nOutput to p1:\n\nFrom table AUTOSCH.T1:\n       #                   inserts:         5\n       #                   updates:         0\n       #                   deletes:         0\n       #                   upserts:         0\n       #                  discards:         0<\/code><\/pre>\n\n\n\n
    The target is a separate deployment, ogg_pg_01<\/code>, from the Oracle GoldenGate for PostgreSQL binaries. A distribution path delivers the p1<\/code> trail from ogg_test_01<\/code> to ogg_pg_01<\/code>. The replicat there, REPPGL<\/code>, is added straight against the trail name, with EXTSEQNO 0<\/code> telling it where to start reading. The checkpoint table is oggadmin.checkpoint<\/code>:<\/p>\n\n\n\n
    OGG (http:\/\/localhost:7859 ogg_pg_01) 2> DBLOGIN USERIDALIAS pgalias DOMAIN OracleGoldenGate\nSuccessfully logged into database.\n\nOGG (http:\/\/localhost:7859 ogg_pg_01 as pgalias@pgstore) 3> ADD REPLICAT REPPGL, EXTFILE p1, EXTSEQNO 0, CHECKPOINTTABLE oggadmin.checkpoint\n2026-09-26T09:14:42Z  INFO    OGG-30509  Connected to database server using ODBC DSN: ogg_pg_01 with SSLMODE 'disable'\n2026-09-26T09:14:42Z  INFO    OGG-08100  Replicat added.<\/code><\/pre>\n\n\n\n
    Baseline: without the feature<\/h2>\n\n\n\n
    REPPGL<\/code>\u2019s parameter file starts with just a MAP<\/code>, no DDL<\/code> clause at all:<\/p>\n\n\n\n
    REPLICAT REPPGL\nTARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate\nMAP AUTOSCH.*, TARGET AUTOSCH.*;<\/code><\/pre>\n\n\n\n
    With this replicat, the initial load stops on the first table, as it always did:<\/p>\n\n\n\n
    2026-09-26 05:52:11  WARNING OGG-00869  Could not retrieve definition for table AUTOSCH.T1.\n2026-09-26 05:52:11  ERROR   OGG-00199  Table AUTOSCH.T1 does not exist in target database.<\/code><\/pre>\n\n\n\n
    Enabling automatic schema evolution<\/h2>\n\n\n\n
    The feature is called AUTOSCHEMA<\/code>, but as a parameter on a line by itself, it is rejected:<\/p>\n\n\n\n
    2026-09-26T05:52:30Z  ERROR   OGG-10141  (REPPGL.prm) line 3 column 1: Parsing error, value \"AUTOSCHEMA\" syntax error.\n2026-09-26T05:52:30Z  ERROR   OGG-10184  Parameter file REPPGL.prm failed validity check.<\/code><\/pre>\n\n\n\n
    AUTOSCHEMA<\/code> is an option of the DDL<\/code> parameter<\/strong>, followed by the usual INCLUDE<\/code> and EXCLUDE<\/code> clauses:<\/p>\n\n\n\n
    REPLICAT REPPGL\nTARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate\nDDL AUTOSCHEMA INCLUDE ALL\nMAP AUTOSCH.*, TARGET AUTOSCH.*;<\/code><\/pre>\n\n\n\n
    The replicat starts and announces the feature, then finds the table missing and creates it:<\/p>\n\n\n\n
    2026-09-26 05:52:41  INFO    OGG-30684  The Automatic Schema Evolution feature is enabled. Please refer to the GoldenGate documentation for the supported operations, the datatype mappings, and the corresponding parameter options to enable\/disable\/override the functionality.\n2026-09-26 05:52:41  WARNING OGG-00869  Could not retrieve definition for table AUTOSCH.T1.\n2026-09-26 05:52:41  WARNING OGG-30633  Table AUTOSCH.T1 does not exist in target database, AutoSchema will attempt to create the missing table.\n2026-09-26 05:52:41  INFO    OGG-02756  The definition for table AUTOSCH.T1 is obtained from the trail file.<\/code><\/pre>\n\n\n\n
    The same warning OGG-00869<\/code> as in the baseline is still there. But it is followed by OGG-30633<\/code> and by OGG-02756<\/code>, which shows that the definition comes from the trail file. In PostgreSQL:<\/p>\n\n\n\n
    pgstore=# \\d autosch.t1\n                            Table \"autosch.t1\"\n Column  |              Type              | Collation | Nullable | Default\n---------+--------------------------------+-----------+----------+---------\n id      | character varying(50)          |           | not null |\n name    | character varying(50)          |           |          |\n amount  | numeric(10,2)                  |           |          |\n created | timestamp(0) without time zone |           |          |\nIndexes:\n    \"t1_pkey\" PRIMARY KEY, btree (id)\n\npgstore=# select * from autosch.t1 order by 1;\n id | name  | amount |       created\n----+-------+--------+---------------------\n 1  | row 1 |  10.25 | 2026-09-26 05:43:53\n 2  | row 2 |  20.50 | 2026-09-26 05:43:53\n 3  | row 3 |  30.75 | 2026-09-26 05:43:53\n 4  | row 4 |  41.00 | 2026-09-26 05:43:53\n 5  | row 5 |  51.25 | 2026-09-26 05:43:53\n(5 rows)<\/code><\/pre>\n\n\n\n
    The table was created, the primary key too, and the 5 rows were loaded.<\/strong> This is the default datatype mapping at work:<\/p>\n\n\n\n
    Oracle column<\/th>PostgreSQL column<\/th><\/tr><\/thead>
    ID NUMBER<\/code> (primary key)<\/td>character varying(50)<\/code><\/td><\/tr>
    NAME VARCHAR2(50)<\/code><\/td>character varying(50)<\/code><\/td><\/tr>
    AMOUNT NUMBER(10,2)<\/code><\/td>numeric(10,2)<\/code><\/td><\/tr>
    CREATED DATE<\/code><\/td>timestamp(0) without time zone<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    The primary key is the surprise: a NUMBER<\/code> without precision becomes a varchar<\/code> on PostgreSQL. Check the mapping before you let a replicat create tables that an application will query. It can be overridden, which is the subject of another post.<\/p>\n\n\n\n
    What happens when the table already exists<\/h2>\n\n\n\n
    Between two loads, I added a column to the source table (ALTER TABLE autosch.t1 ADD (note VARCHAR2(20) DEFAULT 'added')<\/code>). I also inserted a stray row in the PostgreSQL table. Then I reran EXTPGL<\/code> and pointed the same REPPGL<\/code>, still with DDL AUTOSCHEMA INCLUDE ALL<\/code>, at the new file. It did not<\/strong> change the existing table:<\/p>\n\n\n\n
    2026-09-26 05:53:26  INFO    OGG-06511  Using following columns in default map by name: id, name, amount, created.\n2026-09-26 05:53:26  WARNING OGG-01004  Canceled grouped transaction on table autosch.t1. Database error 3505685, (SQLState = 23000 SQLError = 3,505,685 SQLErrorHex = 00357e15 SQLErrorText = [Oracle][ODBC PostgreSQL Wire Protocol driver][PostgreSQL]ERROR: VERROR; duplicate key value violates unique constraint \"t1_pkey\"(Detail Key (id)=(1) already exists.; sautosch; tt1; nt1_pkey; File nbtinsert.c; Line 666; Routine _bt_check_unique; )).\n2026-09-26 05:53:26  ERROR   OGG-01296  Error mapping from AUTOSCH.T1 to autosch.t1.<\/code><\/pre>\n\n\n\n
    The new source column NOTE<\/code> is silently left out of the column mapping: an initial load does not alter an existing table<\/strong>. The load then abends on duplicate key value violates unique constraint \"t1_pkey\"<\/code>, as the rows are already there. So DDL AUTOSCHEMA INCLUDE ALL<\/code> creates missing<\/strong> tables only.<\/p>\n\n\n\n
    The documentation says that for an initial load trail, DDL AUTOSCHEMA<\/code> \u201cautomatically creates or replaces target tables\u201d<\/em>. It does not say how to get the replacement. The replicat binary has a RECREATE<\/code> token, and it is a DDL operation type<\/strong>, so it goes in the INCLUDE<\/code> filter:<\/p>\n\n\n\n
    DDL AUTOSCHEMA INCLUDE ALL OPTYPE RECREATE<\/code><\/pre>\n\n\n\n
    Testing RECREATE<\/code><\/h3>\n\n\n\n
    To see what RECREATE<\/code> does, I prepare a PostgreSQL table that already exists. It has a column that is not on the source and a row that is not in the load:<\/p>\n\n\n\n
    CREATE TABLE autosch.t1 (\n  id varchar(50) PRIMARY KEY,\n  name varchar(50),\n  amount numeric(10,2),\n  created timestamp(0),\n  legacy text\n);\nINSERT INTO autosch.t1 (id, name, legacy)\nVALUES ('99', 'stray row', 'pre-existing');<\/code><\/pre>\n\n\n\n
    The initial load is delivered the way the documentation describes it:<\/p>\n\n\n\n
      \n
    • A SOURCEISTABLE<\/code> extract writes the 5 rows of AUTOSCH.T1<\/code> to the extract file ci<\/code>.<\/li>\n\n\n\n
    • A distribution path sends ci<\/code> to the receiver of the PostgreSQL deployment, as the trail di<\/code>.<\/li>\n\n\n\n
    • A replicat reads the trail di<\/code> with DDLOPTIONS REPORT<\/code> and an explicit MAP AUTOSCH.T1, TARGET AUTOSCH.T1;<\/code>.<\/li>\n<\/ul>\n\n\n\n
      With DDL AUTOSCHEMA INCLUDE ALL<\/code>, the replicat recognizes the initial load by itself. It builds a RECREATE<\/code> operation from the table definition record, then excludes it<\/strong>: INCLUDE ALL<\/code> does not cover that operation type.<\/p>\n\n\n\n
      2026-10-03 13:11:47  INFO    OGG-00489  DDL is of mapped scope, after mapping new operation [ \/* AutoSchema *\/ create table \"autosch\".\"t1\" (ID varchar(50) not null, NAME varchar(50), AMOUNT decimal(10,2), CREATED timestamp(0), primary key(ID)) (size 150)].\n2026-10-03 13:11:47  INFO    OGG-00488  DDL operation excluded [not included by any filter], optype [RECREATE], objtype [TABLE], objowner \"autosch\", objname \"t1\".<\/code><\/pre>\n\n\n\n
      The 5 rows are loaded into the existing table, next to the stray row, and the legacy<\/code> column is still there:<\/p>\n\n\n\n
       id |   name    | amount |       created       |    legacy\n----+-----------+--------+---------------------+--------------\n 1  | row 1     |  10.25 | 2026-09-26 09:11:40 |\n 2  | row 2     |  20.50 | 2026-09-26 09:11:40 |\n 3  | row 3     |  30.75 | 2026-09-26 09:11:40 |\n 4  | row 4     |  41.00 | 2026-09-26 09:11:40 |\n 5  | row 5     |  51.25 | 2026-09-26 09:11:40 |\n 99 | stray row |        |                     | pre-existing\n(6 rows)<\/code><\/pre>\n\n\n\n
      Second run with the RECREATE<\/code> filter<\/h3>\n\n\n\n
      The parameter file for this second run only differs from the previous one by the OPTYPE RECREATE<\/code> filter:<\/p>\n\n\n\n
      REPLICAT REPPGL\nTARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate\nDDLOPTIONS REPORT\nDDL AUTOSCHEMA INCLUDE ALL OPTYPE RECREATE\nMAP AUTOSCH.T1, TARGET AUTOSCH.T1;<\/code><\/pre>\n\n\n\n
      With this file and the same table reset, the replicat warns about what it is going to do, then drops the table:<\/p>\n\n\n\n
      2026-10-03 13:12:34  WARNING OGG-30687  The OPTYPE 'RECREATE' is specified with DDL AUTOSCHEMA option. Please note that the corresponding pre-existing tables will be attempted to be dropped and re-created, only when the REPLICAT is applying initial load trail files. In case of CDC trails, REPLICAT would attempt to create the tables, only when the corresponding tables do not exist already.\n2026-10-03 13:12:34  INFO    OGG-00487  DDL operation included [INCLUDE ALL OPTYPE RECREATE], optype [RECREATE], objtype [TABLE], objowner \"autosch\", objname \"t1\".\n2026-10-03 13:12:34  INFO    OGG-30640  Table autosch.t1 is dropped successfully.\n2026-10-03 13:12:34  INFO    OGG-00484  Executing DDL operation.\n2026-10-03 13:12:34  INFO    OGG-00483  DDL operation successful.<\/code><\/pre>\n\n\n\n
      The table is recreated from the table definition record and loaded, and the legacy<\/code> column and the stray row are gone<\/strong>.<\/p>\n\n\n\n
                                  Table \"autosch.t1\"\n Column  |              Type              | Collation | Nullable | Default\n---------+--------------------------------+-----------+----------+---------\n id      | character varying(50)          |           | not null |\n name    | character varying(50)          |           |          |\n amount  | numeric(10,2)                  |           |          |\n created | timestamp(0) without time zone |           |          |\nIndexes:\n    \"t1_pkey\" PRIMARY KEY, btree (id)\n\n id | name  | amount |       created\n----+-------+--------+---------------------\n 1  | row 1 |  10.25 | 2026-09-26 09:11:40\n 2  | row 2 |  20.50 | 2026-09-26 09:11:40\n 3  | row 3 |  30.75 | 2026-09-26 09:11:40\n 4  | row 4 |  41.00 | 2026-09-26 09:11:40\n 5  | row 5 |  51.25 | 2026-09-26 09:11:40\n(5 rows)<\/code><\/pre>\n\n\n\n
      No parameter tells the replicat that it applies an initial load: a trail written by a SOURCEISTABLE<\/code> extract is enough. I got the same drop and recreate in three setups. The replicat was added on the trail with EXTTRAIL<\/code>, added with EXTFILE<\/code>, or reading a copy of the raw extract file. On a CDC trail, RECREATE<\/code> does not drop anything, as the warning says.<\/p>\n\n\n\n
      A wildcard MAP<\/code> breaks RECREATE<\/code> on PostgreSQL<\/h3>\n\n\n\n
      The MAP<\/code> of the previous test was explicit (MAP AUTOSCH.T1, TARGET AUTOSCH.T1;<\/code>). The baseline of this post used MAP AUTOSCH.*, TARGET AUTOSCH.*;<\/code>. I replaced it with the wildcard on the same table and the same trail, and nothing else changed:<\/p>\n\n\n\n
      REPLICAT REPPGL\nTARGETDB ogg_pg_01 USERIDALIAS pgalias DOMAIN OracleGoldenGate\nDDLOPTIONS REPORT\nDDL AUTOSCHEMA INCLUDE ALL OPTYPE RECREATE\nMAP AUTOSCH.*, TARGET AUTOSCH.*;<\/code><\/pre>\n\n\n\n
      This time, the replicat never drops the table<\/strong>. There is no OGG-30640<\/code> in the report, and the CREATE TABLE<\/code> that follows abends because the table is still there:<\/p>\n\n\n\n
      2026-10-03 13:17:02  INFO    OGG-06506  Wildcard MAP resolved (entry AUTOSCH.*): MAP \"AUTOSCH\".\"T1\", TARGET AUTOSCH.\"T1\".\n2026-10-03 13:17:02  INFO    OGG-00487  DDL operation included [INCLUDE ALL OPTYPE RECREATE], optype [RECREATE], objtype [TABLE], objowner \"autosch\", objname \"T1\".\n2026-10-03 13:17:02  INFO    OGG-00484  Executing DDL operation.\n2026-10-03 13:17:02  ERROR   OGG-00519  Fatal error executing DDL replication: error [Error code [6844183], [Oracle][ODBC PostgreSQL Wire Protocol driver][PostgreSQL]ERROR: VERROR; relation \"t1\" already exists(File heap.c; Line 1167; Routine heap_create_with_catalog; )], no error handler present.\n2026-10-03 13:17:02  ERROR   OGG-30538  Fatal error executing DDL statement [ \/* AutoSchema *\/ create table \"autosch\".\"t1\" (ID varchar(50) not null, NAME varchar(50), AMOUNT decimal(10,2), CREATED timestamp(0), primary key(ID))].<\/code><\/pre>\n\n\n\n
      The first line of the report explains it. The wildcard is resolved from the table name in the trail, so the target becomes AUTOSCH.\"T1\"<\/code>: the case of the source (uppercase on Oracle), and quoted. PostgreSQL stores an unquoted name in lowercase, so my existing table is t1<\/code>, not \"T1\"<\/code>. The replicat looks for \"T1\"<\/code> to drop it, finds nothing, and the CREATE TABLE<\/code> that follows hits the real t1<\/code>. To check this, I created the existing table in PostgreSQL as \"T1\"<\/code> (quoted, so uppercase). Then I ran the same wildcard replicat: this time the drop works<\/strong>.<\/p>\n\n\n\n
      2026-10-03 13:27:14  INFO    OGG-06506  Wildcard MAP resolved (entry AUTOSCH.*): MAP \"AUTOSCH\".\"T1\", TARGET AUTOSCH.\"T1\".\n2026-10-03 13:27:14  INFO    OGG-00487  DDL operation included [INCLUDE ALL OPTYPE RECREATE], optype [RECREATE], objtype [TABLE], objowner \"autosch\", objname \"T1\".\n2026-10-03 13:27:14  INFO    OGG-30640  Table autosch.T1 is dropped successfully.\n2026-10-03 13:27:14  INFO    OGG-00483  DDL operation successful.<\/code><\/pre>\n\n\n\n
      The names are matched exactly. With an explicit MAP AUTOSCH.T1, TARGET AUTOSCH.\"T1\";<\/code> on a lowercase t1<\/code>, the replicat created a second table \"T1\"<\/code> and left t1<\/code> alone. Without quotes, the target of an explicit MAP<\/code> is lowercased for PostgreSQL, which is why the first test dropped t1<\/code>. So with RECREATE<\/code> on PostgreSQL, the target name in the MAP<\/code> must be spelled exactly like the existing table. Write one explicit MAP<\/code> per table<\/strong>, unquoted for a lowercase table. The RECREATE<\/code> parameter file with the explicit MAP<\/code> above does exactly that.<\/p>\n\n\n\n
      Limitations<\/h2>\n\n\n\n
        \n
      • AUTOSCHEMA<\/code> is not for Oracle-to-Oracle replication.<\/strong> Pointing the same DDL AUTOSCHEMA INCLUDE ALL<\/code> replicat at an Oracle target instead of PostgreSQL abends immediately:<\/p>\n
        2026-09-26 05:54:11  ERROR   OGG-30624  AUTOSCHEMA is not allowed in an Oracle to Oracle replication scenario. Please use the DDL replication to control schema evolution.<\/code><\/pre><\/div>\n
        Between two Oracle databases, regular DDL replication is still the standard tool for schema evolution, and a GoldenGate initial load still has no automatic way to create the target table.<\/p><\/li>\n\n\n\n
      • The trail must be format 19.1 or higher with Table Definition Records.<\/p><\/li>\n\n\n\n
      • UNMAPPED<\/code> and OTHER<\/code> scope are not valid with AUTOSCHEMA<\/code><\/strong>. Adding INCLUDE UNMAPPED<\/code> (or INCLUDE OTHER<\/code>) next to INCLUDE ALL<\/code> parses fine, but the replicat rejects it at startup:<\/p>\n
        2026-09-26 07:12:06  ERROR   OGG-30689  The 'UNMAPPED' is not a valid DDL SCOPE to be used with Automatic Schema Evolution.<\/code><\/pre><\/div><\/li>\n<\/ul>\n\n\n\n
        To summarize<\/h2>\n\n\n\n
          \n
        • Automatic schema evolution is enabled on the replicat with DDL AUTOSCHEMA INCLUDE ALL<\/code>.<\/li>\n\n\n\n
        • During an initial load from Oracle to PostgreSQL, it creates the missing table and its primary key from the Table Definition Record of the trail (OGG-30633<\/code>). Then it loads the rows.<\/li>\n\n\n\n
        • The datatypes come from a default mapping: check it first, as a NUMBER<\/code> primary key became a varchar(50)<\/code>.<\/li>\n\n\n\n
        • An initial load leaves an existing table alone. A column added on the source is not added on the target, and the rows are loaded into it.<\/li>\n\n\n\n
        • DDL AUTOSCHEMA INCLUDE ALL OPTYPE RECREATE<\/code> drops and recreates an existing table, only when the trail is an initial load trail (OGG-30640<\/code>). INCLUDE ALL<\/code> alone excludes that operation (OGG-00488<\/code>).<\/li>\n\n\n\n
        • Use one explicit MAP<\/code> per table with RECREATE<\/code> on PostgreSQL. A wildcard MAP<\/code> looks for the table under the source name in quotes and misses a lowercase table. The CREATE TABLE<\/code> then abends with relation \"t1\" already exists<\/code>.<\/li>\n\n\n\n
        • It is not available between two Oracle databases. Pointing it at an Oracle target from an Oracle source abends with OGG-30624<\/code>. An Oracle-to-Oracle initial load still needs the target table to already exist, exactly as before.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
          For as long as I have used GoldenGate, an initial load had one prerequisite: the target tables must already exist. Data Pump takes care of it between two Oracle databases. For anything else, you write the CREATE TABLE statements yourself, with the datatypes you choose, or choose another initial load method. The Automatic Schema Evolution […]<\/p>\n","protected":false},"author":152,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"","_members_access_role":[],"_members_access_error":""},"categories":[3787,59],"tags":[3804,4263,4220,328,2522,3229,3730,2602,3976,4264],"type_dbi":[3823,4266,4221,3740,4265,3231,3881,2749,3977,4267],"class_list":["post-47508","post","type-post","status-publish","format-standard","hentry","category-goldengate","category-oracle","tag-26ai","tag-autoschema","tag-ddl","tag-goldengate","tag-initial-load","tag-microservices","tag-ogg","tag-postgresql-2","tag-replicat","tag-schema-evolution","type-26ai","type-autoschema","type-ddl","type-goldengate","type-initial-load","type-microservices","type-ogg","type-postgresql","type-replicat","type-schema-evolution"],"acf":[],"yoast_head":"\nGoldenGate 26ai automatic schema evolution: creating missing tables during an initial load - dbi Blog<\/title>\n<meta name=\"description\" content=\"GoldenGate automatic schema evolution in 26ai creates missing PostgreSQL target tables in a SOURCEISTABLE initial load: syntax and tests.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load\" \/>\n<meta property=\"og:description\" content=\"GoldenGate automatic schema evolution in 26ai creates missing PostgreSQL target tables in a SOURCEISTABLE initial load: syntax and tests.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-10-05T05:00:44+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-10-05T05:00:53+00:00\" \/>\n<meta name=\"author\" content=\"Julien Delattre\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Julien Delattre\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/\"},\"author\":{\"name\":\"Julien Delattre\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/764ab019cc9dec42655b4c6b9b8e474e\"},\"headline\":\"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load\",\"datePublished\":\"2026-10-05T05:00:44+00:00\",\"dateModified\":\"2026-10-05T05:00:53+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/\"},\"wordCount\":1457,\"commentCount\":0,\"keywords\":[\"26ai\",\"autoschema\",\"ddl\",\"GoldenGate\",\"Initial load\",\"microservices\",\"ogg\",\"postgresql\",\"replicat\",\"schema evolution\"],\"articleSection\":[\"GoldenGate\",\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/\",\"name\":\"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2026-10-05T05:00:44+00:00\",\"dateModified\":\"2026-10-05T05:00:53+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/764ab019cc9dec42655b4c6b9b8e474e\"},\"description\":\"GoldenGate automatic schema evolution in 26ai creates missing PostgreSQL target tables in a SOURCEISTABLE initial load: syntax and tests.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/764ab019cc9dec42655b4c6b9b8e474e\",\"name\":\"Julien Delattre\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g\",\"caption\":\"Julien Delattre\"},\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/juliendelattre\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load - dbi Blog","description":"GoldenGate automatic schema evolution in 26ai creates missing PostgreSQL target tables in a SOURCEISTABLE initial load: syntax and tests.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/","og_locale":"en_US","og_type":"article","og_title":"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load","og_description":"GoldenGate automatic schema evolution in 26ai creates missing PostgreSQL target tables in a SOURCEISTABLE initial load: syntax and tests.","og_url":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/","og_site_name":"dbi Blog","article_published_time":"2026-10-05T05:00:44+00:00","article_modified_time":"2026-10-05T05:00:53+00:00","author":"Julien Delattre","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Julien Delattre","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/"},"author":{"name":"Julien Delattre","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/764ab019cc9dec42655b4c6b9b8e474e"},"headline":"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load","datePublished":"2026-10-05T05:00:44+00:00","dateModified":"2026-10-05T05:00:53+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/"},"wordCount":1457,"commentCount":0,"keywords":["26ai","autoschema","ddl","GoldenGate","Initial load","microservices","ogg","postgresql","replicat","schema evolution"],"articleSection":["GoldenGate","Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/","url":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/","name":"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2026-10-05T05:00:44+00:00","dateModified":"2026-10-05T05:00:53+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/764ab019cc9dec42655b4c6b9b8e474e"},"description":"GoldenGate automatic schema evolution in 26ai creates missing PostgreSQL target tables in a SOURCEISTABLE initial load: syntax and tests.","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/goldengate-26ai-automatic-schema-evolution-creating-missing-tables-during-an-initial-load\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"GoldenGate 26ai automatic schema evolution: creating missing tables during an initial load"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/764ab019cc9dec42655b4c6b9b8e474e","name":"Julien Delattre","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a97d00e680bbf237126e24b65281cbcb66cd20bd1ed2d14bf928991b2bf68eb5?s=96&d=mm&r=g","caption":"Julien Delattre"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/juliendelattre\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/47508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/152"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=47508"}],"version-history":[{"count":3,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/47508\/revisions"}],"predecessor-version":[{"id":47630,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/47508\/revisions\/47630"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=47508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=47508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=47508"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=47508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}