• Tables where all columns can be used to identify uniqueness (bad_column='N')
• Tables where not all columns can be used (bad_column='Y')

To show what happens when primary keys are missing in GoldenGate replication, let’s see a few examples. In all the examples, I will extract data from APP_SOURCE schema and replicate it into an APP_TARGET schema.

The parameters of the replication do not really matter here, but to be precise, here is the extract parameter file:

EXTRACT EXT1
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1
DDL INCLUDE MAPPED
TABLE APP_SOURCE.*;

And here is the replicat parameter file:

REPLICAT REP2
USERIDALIAS target_pdb DOMAIN OracleGoldenGate
DDL INCLUDE MAPPED
MAP PDB1.APP_SOURCE.*, TARGET PDB2.APP_TARGET.*;

First test : simple table with primary key

First, let’s try the most common example, with a table APP_SOURCE.TEST_PK created with a primary key. You can skip this part if you know how GoldenGate works, but I just wanted to include this for comparison.

CREATE TABLE APP_SOURCE.TEST_PK
(
    id   NUMBER PRIMARY KEY,
    data VARCHAR2(100)
);

Let’s insert a few rows in this table and look at the content of the table in both the source and the target.

INSERT INTO APP_SOURCE.TEST_PK VALUES (1,'A');
INSERT INTO APP_SOURCE.TEST_PK VALUES (2,'B');
COMMIT;

-- Verify source/target
SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

You will see the same content in both tables.

SQL> SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;

        ID DATA
---------- --------------------
         1 A
         2 B

Now, if you update the row with id=1, it will be updated in both tables as well.

UPDATE APP_SOURCE.TEST_PK SET data='A_UPDATED' WHERE id=1;
COMMIT;

-- Verify
SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

Checking the tables will give you the updated data.

SQL> SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

        ID DATA
---------- --------------------
         1 A_UPDATED
         2 B

Until then, nothing really interesting, but let’s look at the report file of the extract on the source. You will see the following information:

2026-06-06 07:00:52  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_PK: ID.

Because the table has a primary key, GoldenGate knows that it should only use this column to identify unique rows.

Second test : table with no primary key and no LOB columns

In this second test, I will create a table without a primary key, but using only types that GoldenGate can use to identify uniqueness.

CREATE TABLE APP_SOURCE.TEST_NOPK
(
    id   NUMBER,
    data VARCHAR2(100)
);

We can already query the DBA_GOLDENGATE_NOT_UNIQUE view to find this new table listed with bad_column='N' :

SELECT *
FROM dba_goldengate_not_unique
WHERE owner='APP_SOURCE'
ORDER BY owner, table_name;

OWNER                          TABLE_NAME                     BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_SOURCE                     TEST_NOPK                      N

Let’s do the same steps as before, inserting data and updating the content.

INSERT INTO APP_SOURCE.TEST_NOPK VALUES (1,'A');
INSERT INTO APP_SOURCE.TEST_NOPK VALUES (2,'B');
COMMIT;

SELECT * FROM APP_SOURCE.TEST_NOPK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_NOPK ORDER BY id;

UPDATE APP_SOURCE.TEST_NOPK SET data='A_UPDATED' WHERE id=1;
COMMIT;

The content of the table is the same on source and target, as expected.

SQL> SELECT * FROM APP_TARGET.TEST_NOPK ORDER BY id;

        ID DATA
---------- --------------------
         1 A_UPDATED
         2 B

And looking at the extract report file, we can see that all viable columns were used. In that case, it meant taking ID and DATA.

2026-06-06 07:08:13  INFO    OGG-06508  Wildcard MAP (TABLE) resolved (entry PDB1.APP_SOURCE.*): TABLE "PDB1"."APP_SOURCE"."TEST_NOPK".

2026-06-06 07:08:13  WARNING OGG-06439  No unique key is defined for table TEST_NOPK. All viable columns will be used to represent the key, but may not guarantee uniqueness. KEYCOLS may be used to define the key. If using KEYCOLS, make sure that you create an INDEX in the target database for those column(s) as well.

2026-06-06 07:08:13  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_NOPK: ID, DATA.

As mentioned in the other blog about primary keys in GoldenGate, this will work, but you will of course have performance issues when replicating data.

Third test : Table with no PK and a CLOB column

Now, let me show you the bad use case, where you don’t have a primary key and the table contains a non-viable column for uniqueness identification. In this example, I will use a CLOB column, but it could be another unbounded data type.

CREATE TABLE APP_SOURCE.TEST_CLOB
(
    id   NUMBER,
    code VARCHAR2(10),
    txt  CLOB
);

If we check the DBA_GOLDENGATE_NOT_UNIQUE view, we see the new table listed with bad_column='Y'.

SELECT *
FROM dba_goldengate_not_unique
WHERE owner='APP_SOURCE'
ORDER BY owner, table_name;

OWNER                          TABLE_NAME                     BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_SOURCE                     TEST_CLOB                      Y
APP_SOURCE                     TEST_NOPK                      N

Let’s insert some data. But this time, I will add two more rows that are unique, but for which only the TXT content differs.

INSERT INTO app_source.test_clob VALUES (1,'A',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (2,'B',TO_CLOB('LOB_2'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
COMMIT;

The data was correctly inserted, and the content is the same on the source and target.

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt FROM app_target.test_clob ORDER BY id;

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_1
       100 DUP	      LOB_2

In the report file, we do not see any difference between this example and the one before. GoldenGate mentions using two columns for uniqueness identification : ID and CODE. GoldenGate never mentions that a third column existed and was not used. The warning displayed is the same as before.

2026-06-06 07:10:13  INFO    OGG-06508  Wildcard MAP (TABLE) resolved (entry PDB1.APP_SOURCE.*): TABLE "PDB1"."APP_SOURCE"."TEST_CLOB".

2026-06-06 07:10:13  WARNING OGG-06439  No unique key is defined for table TEST_CLOB. All viable columns will be used to represent the key, but may not guarantee uniqueness. KEYCOLS may be used to define the key. If using KEYCOLS, make sure that you create an INDEX in the target database for those column(s) as well.

2026-06-06 07:10:13  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_CLOB: ID, CODE.

And now, the main problem I wanted to discuss regarding LOB replication with GoldenGate. If you try to delete one row by specifying all three columns, it will not always work.

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;

Sometimes, the line with LOB_1 will be deleted:

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_2

But sometimes, the line with LOB_2 will be deleted:

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_1

More precisely, it will just delete the first line that was inserted. You then have two cases. If you insert LOB_1 first, it will be deleted correctly:

DROP TABLE app_source.test_clob PURGE;

CREATE TABLE app_source.test_clob (id NUMBER, code VARCHAR2(10), txt CLOB);

INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
COMMIT;

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;
COMMIT;

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt
FROM app_target.test_clob
WHERE code='DUP';

        ID CODE       TXT
---------- ---------- ----------------------------------------
       100 DUP	      LOB_2

And if you insert LOB_2 first, the incorrect line will be deleted:

DROP TABLE app_source.test_clob PURGE;

CREATE TABLE app_source.test_clob (id NUMBER, code VARCHAR2(10), txt CLOB);

INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
COMMIT;

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;
COMMIT;

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt
FROM app_target.test_clob
WHERE code='DUP';

        ID CODE       TXT
---------- ---------- ----------------------------------------
       100 DUP	      LOB_1

You now know why you should always pay attention to tables in the DBA_GOLDENGATE_NOT_UNIQUE view with bad_column='Y'. If you have such tables, there are several scenarios that I presented in the last blog on the topic. But ignoring them is not one of them. This way, you will avoid issues regarding LOB replication with GoldenGate.

L’article LOB Replication With GoldenGate and Importance of Primary Keys est apparu en premier sur dbi Blog.

Before explaining what this view contains and how to interpret it, you should remember that GoldenGate replicates data by replaying changes that occurred on the source database. One of the most important problems GoldenGate must solve is to identify the exact row that must be updated or deleted on the target database. This means that GoldenGate needs a way to uniquely identify every row in a table.

The simplest solution is a primary key, but GoldenGate row identification can also be done through a non-null unique index. When neither exists, GoldenGate must fall back to less efficient mechanisms. This means using all available columns to identify a row.

The DBA_GOLDENGATE_NOT_UNIQUE view contains tables that have no primary key and no non-null unique index. It is there to help you identify potential issues in your database schema and prepare in the best possible way a migration with GoldenGate or any replication work.

Here is an example of the content of the view:

OWNER			       TABLE_NAME		      BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_PDB1		       TEST_NOPK		      N
APP_PDB1		       TEST_CLOB		      Y

The view is very simple, yet very often misunderstood. The owner and table_name column names are self-explanatory, but let’s talk about bad_column. This column has two possible values: Y and N.

First case – bad_column = 'N'

N is what you will most often see in this view. You should treat these as warnings. If you intend to replicate a table from this list, you can choose to ignore the warning if you don’t care about replication performance.

Tables in this list will be replicated using all columns as a substitute key. GoldenGate can usually handle these tables without any functional issue. However, UPDATE and DELETE operations become more expensive because every column must be used to identify the target row.

From my experience, you should still always discuss with the application owner or someone who knows the underlying database schema to try to avoid performance issues. A list of solutions is given at the end of the blog.

Second case – bad_column = 'Y'

If there is one point to remember from this blog, it’s this: you should never replicate data from tables with bad_column='Y' without thorough investigation.

Tables listed here contain one or more columns that GoldenGate cannot safely use as part of a substitute key, such as LONG or CLOB.

Since GoldenGate cannot build a complete substitute key from all columns, row identification becomes problematic. Depending on the table structure and replication configuration, GoldenGate may be unable to correctly locate rows for UPDATE or DELETE operations.

In practice, a table with bad_column='Y' should be considered a candidate for schema remediation before replication (see the list of options below).

Will there be an error if GoldenGate cannot identify uniqueness ?

This is a very common misconception when talking about these primary key issues. GoldenGate does not verify that the columns used for row identification are truly unique. If duplicate rows exist, a replicat may update or delete an unintended row. In many cases no explicit GoldenGate error will be generated because, from GoldenGate’s perspective, a matching row was found. It could silently delete the wrong row, and you will never hear a word about it. In the logs, you won’t see the difference.

What can be done to solve these issues ?

Essentially, there are four possible approaches:

• If you have the ability to create a primary key or a non-null unique index on the source database, go for it before the initial load of your target database. This is the safest approach because uniqueness is enforced by the database itself.
• If you cannot alter the source schema but are 100% sure that a subset of columns that already exists in the table can uniquely identify every row, you can use the KEYCOLS keyword in your parameter files.
• Sometimes, the application design prevents duplicates from being generated. Again, you need to be sure about this. But sometimes, it means that you could rely on the application design.
• When bad_column is N, you could decide to not do anything. For tables with a lot of activity, it could slow down your replication. During a migration, it could even completely block it in production. This should only be done in last resort.

A common misconception is that every table listed in DBA_GOLDENGATE_NOT_UNIQUE is unsupported by GoldenGate. This is not the case. At the other end of the spectrum, I’ve heard countless of times that these warnings can be ignored. Do that, and you will have nightmares solving issues once you hit production. The view merely highlights tables for which GoldenGate cannot rely on a primary key or a non-null unique index for row identification. The real concern is the bad_column flag: N is a performance warning, while Y deserves immediate investigation before any replication project.

L’article GoldenGate Row Identification: Misconceptions and Solutions est apparu en premier sur dbi Blog.

# odacli describe-job -i 2ff3fd5d-f611-4ae6-aae0-63df7c08ec71
 
Job details
----------------------------------------------------------------
                     ID:  2ff3fd5d-f611-4ae6-aae0-63df7c08ec71
            Description:  DB Home Patching to 19.31.0.0.0: Home ID is 1c101fd3-2ca8-55f6-9415-22ec5abc53da
                 Status:  Failure (To view Error Correlation report, run "odacli describe-job -i 2ff3fd5d-f611-4ae6-aae0-63df7c08ec71 --ecr" command)
                Created:  June 09, 2026 15:07:23 CEST
                Message:  DCS-10001:Internal error encountered: Unable to autoextend tablespace TEMP.

The issue is that Oracle tries to “set autoextend on” on the temporary files in 19.31., but runs a syntactically wrong command. E.g. in the alert.log I could see

2026-06-09T15:54:14.898088+02:00
alter database tempfile '/u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4kz32_.tmp /u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4l3wf_.tmp' autoextend on next 100m maxsize 20g
ORA-1516 signalled during:  alter database tempfile '/u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4kz32_.tmp /u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4l3wf_.tmp' autoextend on next 100m maxsize 20g ...

I.e. Oracle just listed all tempfiles separated by blank in one string. This is of course wrong and produces the error.

The workaround was to 

 – create a temporary tablespace temp2

 – make temp2 the default temporary tablespace

 – drop temporary tablespace temp

 – create the temporary tablespace temp with just 1 tempfile

 – make temp the default temporary tablespace

 – drop temporary tablespace temp2

Then run the “odacli update-dbhome” again and it will be successful. Afterwards add your temporary files to tablespace temp again. 

Please consider that it is not obvious in the produced errors of odacli in what DB the error happened (odacli update-dbhome patches all DBs running in the specified ORACLE_HOME). To find out what DB is affected it’s a good idea to scan the alert-logs for the error:

$ find /u01/app/odaorabase/oracle/diag/rdbms/*/*/trace -name "alert*.log" -exec grep -il "ORA-1516" {}\;

To proactively avoid the issue when patching to 19.31. on the ODA, I’d recommend to check your databases in advance if they have more than 1 tempfile in the temporary tablespace and implement the workaround mentioned above.

select count(*) from dba_temp_files where tablespace_name='TEMP';

We opened a SR with Oracle to get the issue fixed for the next release.

Update 18.06.2026:

If you do use a Standby DB (Data Guard) and use the workaround mentioned above, then please consider that you have to add the tempfiles at the standby site as well after recreating TEMP. See here, here and here.

L’article Temporary tablespace and ODA 19.31. est apparu en premier sur dbi Blog.

In fact, when using a reverse proxy with a single deployment, some endpoints are different from a multi-deployment configuration.

Let’s take the extract listing endpoint as example: GET /services/v2/extracts. With a basic GoldenGate configuration without NGINX reverse proxy, you could list the extracts with the following URL: https://vmogg:7809/services/v2/extracts

In a single-deployment setting using NGINX, the /services/v2/extracts endpoint is still valid and will list the extracts of your only deployment (API response given below).

{
    "$schema": "api:standardResponse",
    "links": [
        {
            "rel": "canonical",
            "href": "https://vmogg_single_deployment/services/v2/extracts",
            "mediaType": "text/html"
        },
        {
            "rel": "self",
            "href": "https://vmogg_single_deployment/services/v2/extracts",
            "mediaType": "text/html"
        },
        {
            "rel": "describedby",
            "href": "https://vmogg_single_deployment/services/ogg_test_01/adminsrvr/v2/metadata-catalog/extracts",
            "mediaType": "application/schema+json"
        }
    ],
    "messages": [],
    "response": {
        "$schema": "ogg:collection",
        "items": [
            {
                "links": [
                    {
                        "rel": "parent",
                        "href": "https://vmogg_single_deployment/services/v2/extracts",
                        "mediaType": "application/json"
                    },
                    {
                        "rel": "canonical",
                        "href": "https://vmogg_single_deployment/services/v2/extracts/EXT1",
                        "mediaType": "application/json"
                    }
                ],
                "$schema": "ogg:collectionItem",
                "name": "EXT1",
                "status": "running"
            }
        ]
    }
}

In a multi-deployment configuration, the endpoint does not work:

{
	"links": [],
	"messages": [
		{
			"$schema": "ogg:message",
			"title": "The requested resource does not exist.",
			"code": "OGG-12031",
			"severity": "ERROR",
			"issued": "2026-05-28T18:25:48Z",
			"type": "https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes"
		}
	]
}

This is an behavior is expected, since you cannot query multiple deployments at once.

• With a single deployment, you can list extracts without specifying the deployment name.
• With multiple deployments, there is no meaning in listing extracts without having to specify which deployment you are targeting.

In the NGINX reverse proxy configuration file, this is materialized by a change of behavior for all endpoints that are deployment-specific. To keep the extracts endpoint as example, here is what the configuration looks like in a single-deployment setup:

location ~ ^/services/ogg_test_01/(?<version>[^/]+)/(?<resource>extracts.*)$ {
location ~ ^/services/(?<version>[^/]+)/(?<resource>extracts.*)$ {

And here is what it looks like in a multi-deployment setup:

location ~ ^/services/ogg_test_01/(?<version>[^/]+)/(?<resource>extracts.*)$ {
location ~ ^/services/ogg_test_02/(?<version>[^/]+)/(?<resource>extracts.*)$ {

With a single deployment, we could access the extracts endpoint through the deployment or with the default endpoint. With multiple deployments, this second option is not available anymore, and you have to specify the deployment name every time.

This is why a best practice is to always use deployment-specific endpoints whenever it is possible, to avoid NGINX behavior changes in GoldenGate when adding or deleting deployments.

Can I still use deployment-specific endpoints if I don’t have a reverse proxy ?

In the same way that it does not make sense to have a single endpoint to list extracts if you have multiple deployments with a reverse proxy, it does not make sense to include the deployment name in the URL if you do not have a reverse proxy. If you try to access this:

http(s)://vmogg:port/services/deployment_name/adminsrvr/v2/extracts

You will receive an error stating that “The requested resource does not exist“. Without a reverse proxy, the port is what determines both the deployment and the service to which you connect.

L’article GoldenGate NGINX Reverse Proxy Behavior Changes est apparu en premier sur dbi Blog.

As for Oracle databases, the idea is to:

• Set up a new GoldenGate home.
• Switch the running processes to the new version of GoldenGate.

The nice thing is that since a few patches, Oracle now always delivers GoldenGate patches in two versions: the standard patch, applied on top of an existing installation, and a complete installation, which includes the patch. In this blog, we will use the second option.

Installing the latest version of GoldenGate

At the time of writing, version 23.26.2.0.1 (patch 39299258) was just released, but you should definitely check on the Oracle Support website to see if a new patch is available.

As instructed in the installation guide for GoldenGate, just unzip the patched installation to a temporary directory and use the runInstaller with the following oggcore.rsp response file.

> cat /home/oracle/oggcore.rsp
oracle.install.responseFileVersion=/oracle/install/rspfmt_ogginstall_response_schema_v26_1_0
INSTALL_OPTION=ORA23ai
SOFTWARE_LOCATION=/u01/app/ogg/product/23.26.2.0.1
INVENTORY_LOCATION=/u01/app/oraInventory
UNIX_GROUP_NAME=oinstall

> /u01/stage/fbo_ggs_Linux_x64_Oracle_services_shiphome/Disk1/runInstaller -silent -responseFile /home/oracle/oggcore.rsp
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 120 MB.   Actual 17094 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 4095 MB    Passed
[...]
Successfully Setup Software.
The installation of Oracle GoldenGate Services was successful.

50% of the work is already done, but it’s definitely not the hardest part ! If you’re wondering how to take this out-of-place patching procedure and adapt it to GoldenGate 19c, just remember to set INSTALL_OPTION=ORA19c in the oggcore.rsp response file.

Changing OGG_HOME from the web UI

Now that you have your new GoldenGate home, you are ready to switch. There are multiple ways of doing it, starting with updating your installation from the web UI. Here are the steps in the process:

• Updating the OGG_HOME of the Service Manager
• Restarting the Service Manager
• Optionally, restart the services attached to the Service Manager.
• Updating the OGG_HOME of the deployments (one at a time)
• Restarting the deployments
• Restarting extracts, replicats and distribution paths

To start, just log in to the service manager and go to the Deployments > Service Manager > Details tab.

All you need to do is to edit the Deployment detail, by setting the new value for OGG_HOME.

After updating the Service Manager, you can safely restart it from the web UI Home tab.

If you check on your server, you should see the ServiceManager process using the latest OGG_HOME location:

oracle@vmogg:~/ [ogg] ps -ef|grep ServiceManager
oracle      1709       1  0 14:47 ?        00:00:03 /u01/app/ogg/product/23.26.2.0.1/bin/ServiceManager --quiet

A new process named AIService was introduced in 26ai. If it is still running on the old OGG_HOME even after restarting the ServiceManager deployment, you should restart it from the web UI. Just click on the ServiceManager deployment, stop the AI Service and restart it.

At this point, it is important to know that all your deployment processes, including extracts and replicats, are still running on the old GoldenGate home directory. Besides checking the server processes, you can verify the version from the web UI by clicking on the top-right profile icon and on About.

In the service manager UI, you will have the new version:

And in the administration service UI, the old version is still there:

You can now update your deployments, one at a time, by repeating the exact same procedure. From the Service Manager web UI, go to the Details tab of your deployments. Then, edit the Deployment detail and set OGG_HOME to the new value.

Once updated, restart the deployment from the same Home tab where you restarted the Service Manager earlier.

Once all your deployments are running on the new home, you can restart the extracts, replicats and distribution paths. Connected to the Administration Service in the web UI, restart them one by one or using the Group Action button.

Some services are still running on the old OGG_HOME

If some services are still running on the old OGG_HOME, do not worry. The web UI or the REST API will return a response before restarting all services. More specifically, for the deployments, the restart will succeed as long as the Administration Service (adminsrvr) is restarted. The Receiver Service (recvsrvr) or the Distribution Service (distsrvr) might take more time to restart. Just wait a bit and it should be good. If, after a few minutes, the services are still running on the old home, restart them manually (still from the web UI).

Other things to consider

If you decide to change the name of your home at every release, remember to change the OGG_HOME in all scripts and environments. This might include:

• DMK environment files.
• systemd service file, which might include the OGG_HOME variable.

L’article GoldenGate 26ai out-of-place patching with the web UI est apparu en premier sur dbi Blog.

If you don’t, part of your installation will not be working anymore. This is what will happen in the web UI:

In the adminclient, you will receive an OGG-12031 error when connecting to the deployment, with the same error : “The requested resource does not exist“.

OGG (not connected) > connect https://vmogg deployment ogg_test_02 user ogg
Password for 'ogg' at 'https://vmogg':

2026-05-28T12:42:54Z  ERROR   OGG-12031  The requested resource does not exist.

And the same error will happen when calling the REST API of your new deployment:

RuntimeError: ERROR (code 404) - https://vmogg/services/ogg_test_02/adminsrvr/v2/extracts: The requested resource does not exist.

The NGINX configuration generated by GoldenGate is static. Indeed, the file located in the /etc/nginx/conf.d directory contains deployment-specific routes generated from the GoldenGate setup at the time of execution. You can verify this by searching for an existing deployment name in the configuration:

> grep ogg_test_01 /etc/nginx/conf.d/ogg.conf | wc -l
187

Since the deployment name is an integral part of the API calls, and given that the configuration is not dynamic, after adding or removing a deployment, you will have to regenerate the configuration file.

Reconfiguring NGINX reverse proxy

You can regenerate the configuration with the ReverseProxySettings utility in the $OGG_HOME/lib/utl/reverseproxy directory. With the oracle user:

$OGG_HOME/lib/utl/reverseproxy/ReverseProxySettings --user ogg --port 443 --output /home/oracle/ogg.conf http://localhost:7809

Make sure to adapt the GoldenGate username and the port to the Service Manager (7809 is the default). If GoldenGate is accessed through a VIP (in a RAC setup, for instance), add the --host parameter:

$OGG_HOME/lib/utl/reverseproxy/ReverseProxySettings --user ogg --port 443 --output /home/oracle/ogg.conf http://localhost:7809 --host ogg-vip

Once the new configuration is available, as root, edit the new file to include SSL parameters. If you don’t do this, NGINX will fail to restart, and your whole GoldenGate installation will not be accessible anymore.

> grep ssl_certificate /etc/nginx/conf.d/ogg.conf
    ssl_certificate         /etc/nginx/ssl/ogg.pem;
    ssl_certificate_key     /etc/nginx/ssl/ogg.key;

For these parameters, just reuse the ones you already had in your current configuration. With the root user, replace the old configuration with the new one.

cd /etc/nginx/conf.d/
mv ogg.conf ogg.conf_old
mv /home/oracle/ogg.conf .
chown root:root ogg.conf

Before restarting NGINX, test the configuration:

> nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Finally, restart NGINX to apply the new configuration.

systemctl restart nginx

After restarting NGINX, the new deployment becomes accessible from the web UI, the adminclient and the REST API.

L’article GoldenGate : Regenerate NGINX Reverse Proxy After Deployment Changes est apparu en premier sur dbi Blog.

Environment and problem description

At our customer environment, client connection run from the HelperVM does not establish database connections directly to the database listener. The connection goes through the Network Load Balancer, so called NLB, and the Oracle Connection Manager, so called CMAN.

The diagram below describes the database connection establishment process.

This is how it works.

• 1 – Client seeks for connection details (ideally, get the connection details from Oracle Directory Service)
• 2 – Client connects to Network Load Balancer
• 3 – Network Load Balancer “forwards” the request to Oracle Connection MANager using Virtual IP
• 4 – Oracle Connection MANager acts as a rule-based firewall and ensure the database target service is running on the “white listed targets (next_hop)
• 5 – Oracle Database establish connectivity upon credential validate (Oracle listener acts in between). The listener hands the connection over to the Oracle CMAN gateway process, which passes data back and forth between the client and the db-server and collects statistics.

We could observed per reverse engineering  technique that the TCP connection established between the Oracle client and Oracle CMAN works upon Network Load Balancer Virtual IP.

The Network Load Balancer needs for Session persistence “statefullnes” to be enabled. This means that once the connection is established, the NLB “remembers” established connections and fails them over in case of planned downtime.

We have been facing some broken connectivity issue. Checking Linux socket connection with linux ss command (# ss -nop) we could see TCP connection hungs between client and NLB virtual IP (CNAME DNS entry). On CMAN and DB-Server side the connection were already cleaned up as per Dead Connection Detection configuration. We can see in the diagram that EXPIRE_TIME is setup with a value of 10 minutes on the CMAN side and the listener configuration from the VM Cluster database.

The connection was still opened on the client side because:

• The client was still waiting on a result which would never come
• TCP connection to the NLB Virtual IP was still existing albeit closed with the CMAN and database listener
• TCP connection to the NLB would remain alive for days

The problem is that by default Oracle client does not enable TCP Keepalive, which is an expected behavior. Oracle expects the keepalive to be set on the server side. The “Dead Connection Detection” will then be enforced for all clients.

TCP Keepalive should then be managed in our case on the client side. And we are currently running Oracle 19c Client.

EXPIRE_TIME handled on Oracle 19c Client

Oracle 19c client does not come with SQLNET.EXPIRE_TIME aka “Oracle dead connection detection”, unless hacked over connection string hidden (unsupported) parameter ENABLE_BROKEN. 

See following blog from a one of my former colleagues:

sqlnet-expire_time and enablebroken

And what about Oracle 26ai Client? Let’s do some test…

Installation of Oracle 26ai Client

On the lab, I will use the VM called bastion to act as the client. The bastion has already an Oracle 19c Client installed. I’m going to installed new Oracle 26ai Client on it.

First we need to download the client version, which can be done from the following website:

https://www.oracle.com/database/technologies/oracle26ai-linux-downloads.html

I will install Oracle 26ai Client version in /opt/oracle.

[root@bastion oracle]# pwd
/opt/oracle

[root@bastion oracle]# ls -ld client*
drwxr-xr-x. 52 oracle oinstall 4096 Jun  6  2024 client19c
drwxr-xr-x. 47 oracle oinstall 4096 Nov 11  2025 client_21c
[root@bastion oracle]#

I will first unzip the downloaded oracle zip file.

[oracle@bastion oracle]$ pwd
/opt/oracle

[oracle@bastion oracle]$ unzip -q LINUX.X64_2326100_client.zip

I will then rename the client installation directory:

[oracle@bastion oracle]$ ls -ld client*
drwxr-xr-x.  5 oracle oinstall   90 Jan 17 13:59 client
drwxr-xr-x. 52 oracle oinstall 4096 Jun  6  2024 client19c
drwxr-xr-x. 47 oracle oinstall 4096 Nov 11  2025 client_21c

[oracle@bastion oracle]$ mv client client26ai
[oracle@bastion oracle]$

[oracle@bastion oracle]$ ls -ld client*
drwxr-xr-x. 52 oracle oinstall 4096 Jun  6  2024 client19c
drwxr-xr-x. 47 oracle oinstall 4096 Nov 11  2025 client_21c
drwxr-xr-x.  5 oracle oinstall   90 Jan 17 13:59 client26ai
[oracle@bastion oracle]$

I will prepare the response file for the command line installation.

[oracle@bastion client26ai]$ cp -p response/client_install.rsp response/client_install_custom.rsp

[oracle@bastion client26ai]$ vi response/client_install_custom.rsp

[oracle@bastion client26ai]$ diff response/client_install.rsp response/client_install_custom.rsp
22c22
 UNIX_GROUP_NAME=oinstall
26c26
 INVENTORY_LOCATION=/opt/oracle/oraInventory
30c30
 ORACLE_HOME=/opt/oracle/client26ai
34c34
 ORACLE_BASE=/opt/oracle
48c48
 oracle.install.client.installType=Administrator
[oracle@bastion client26ai]$

And I will run the Oracle 26ai Client installation.

[oracle@bastion client26ai]$ pwd
/opt/oracle/client26ai

[oracle@bastion client26ai]$ ls -ltrh
total 24K
-rwxrwx---.  1 oracle oinstall  500 Feb  6  2013 welcome.html
-rwxr-xr-x.  1 oracle oinstall 8.7K Jan 17 12:38 runInstaller
drwxr-xr-x.  4 oracle oinstall 4.0K Jan 17 12:38 install
drwxr-xr-x. 15 oracle oinstall 4.0K Jan 17 13:37 stage
drwxr-xr-x.  2 oracle oinstall   82 May 21 16:13 response

[oracle@bastion client26ai]$ ./runInstaller -silent -responseFile /opt/oracle/client26ai/response/client_install_custom.rsp
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 415 MB.   Actual 5025 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 4095 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2026-05-21_04-16-17PM. Please wait ... [WARNING] [INS-32016] The selected Oracle home contains directories or files.
   ACTION: To start with an empty Oracle home, either remove its contents or specify a different location.
*********************************************
Package: compat-openssl10-1.0.2 (x86_64): This is a prerequisite condition to test whether the package "compat-openssl10-1.0.2 (x86_64)" is available on the system.
Severity: IGNORABLE
Overall status: VERIFICATION_FAILED
Error message: PRVF-7532 : Package "compat-openssl10(x86_64)-1.0.2" is missing on node "bastion"
Cause:  A required package is either not installed or, if the package is a kernel module, is not loaded on the specified node.
Action:  Ensure that the required package is installed and available.
-----------------------------------------------
[WARNING] [INS-13014] Target environment does not meet some optional requirements.
   CAUSE: Some of the optional prerequisites are not met. See logs for details. /opt/oraInventory/logs/installActions2026-05-21_04-16-17PM.log.
   ACTION: Identify the list of failed prerequisite checks from the log: /opt/oraInventory/logs/installActions2026-05-21_04-16-17PM.log. Then either from the log file or from installation manual find the appropriate configuration to meet the prerequisites and fix it manually.
The response file for this session can be found at:
 /opt/oracle/client26ai/install/response/client_2026-05-21_04-16-17PM.rsp

You can find the log of this install session at:
 /opt/oraInventory/logs/installActions2026-05-21_04-16-17PM.log

The installation of Oracle Client 26ai was successful.
Please check '/opt/oraInventory/logs/silentInstall2026-05-21_04-16-17PM.log' for more details.
Successfully Setup Software with warning(s).
[INS-10115] All configuration tools were previously ran successfully, no further configuration is required.

[oracle@bastion client26ai]$

And the Oracle 26ai Client is now installed.

Prepare target database

I will create a user on the target lab PDB, named TESTZ_TMR_003I, in order to establish sqlplus connection and test the EXPIRE_TIME configuration.

I will create a user test01 and grant the connect permissions.

[oracle@svl-oat ~]$ echo $ORACLE_SID
CDB001I

[oracle@svl-oat ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Thu May 21 14:30:39 2026
Version 19.23.0.0.0

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


Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL> show pdbs

    CON_ID CON_NAME           OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     2 PDB$SEED           READ ONLY  NO
     3 TESTZ_APP_006I         READ WRITE NO
     4 RCLON_TMR_003I         MOUNTED
     5 RCLON_TMR_002I         MOUNTED
     6 RCLON_TMR_001I         MOUNTED
     7 CLONZ_TMR_002I         MOUNTED
     8 TESTZ_TMR_003I         READ WRITE NO
    10 TESTZ_APP_004I         READ WRITE NO
    11 CLONZ_APP_001I         READ WRITE NO
    12 RCLON_APP_003I         READ WRITE NO

SQL> alter session set container=TESTZ_TMR_003I;

Session altered.

SQL> create user test01 identified by "test_expire";

User created.

SQL> grant connect to test01;

Grant succeeded.

SQL>

Test connection with Oracle 26ai Client

I will first set the ORACLE_HOME variable on the appropriate client directory.

[oracle@bastion client26ai]$ echo $ORACLE_HOME
/opt/oracle/client19c

[oracle@bastion client26ai]$ export ORACLE_HOME=/opt/oracle/client26ai

[oracle@bastion client26ai]$ echo $ORACLE_HOME
/opt/oracle/client26ai
[oracle@bastion client26ai]$

I will update the PATH variable to get tnsping and sqlplus binary from the appropriate Oracle 26ai Client.

[oracle@bastion client26ai]$ echo $PATH
/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/oracle/client19c/bin:/opt/oracle/sqlcl-24.1.0.087.0929//bin

[oracle@bastion client26ai]$ export PATH=/opt/oracle/client26ai/bin

[oracle@bastion client26ai]$ echo $PATH
/opt/oracle/client26ai/bin
[oracle@bastion client26ai]$

I will check that the appropriate tnsping and sqlplus is taken.

[oracle@bastion client26ai]$ which sqlplus
/opt/oracle/client26ai/bin/sqlplus

[oracle@bastion client26ai]$ which tnsping
/opt/oracle/client26ai/bin/tnsping

I checked that the connection to target PDB is working.

[oracle@bastion ~]$ tnsping svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

TNS Ping Utility for Linux: Version 23.26.1.0.0 - Production on 21-MAY-2026 16:28:56

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

Used parameter files:
/opt/oracle/client19c/network/admin/sqlnet.ora

Used EZCONNECT adapter to resolve the alias
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=testz_tmr_003i.db.jewlab.oraclevcn.com))(ADDRESS=(PROTOCOL=tcp)(HOST=X.X.1.135)(PORT=1521)))
OK (0 msec)
[oracle@bastion ~]$

The TNS_ADMIN used is from the 19c Oracle client directory, which is absolutely not a problem.

[oracle@bastion ~]$ echo $TNS_ADMIN
/opt/oracle/client19c/network/admin
[oracle@bastion ~]$

Test sqlplus connection with Oracle 26ai Client

As I can see on my client side, I do not have any sqlplus connection running right now.

[opc@bastion ~]$ ss -nop | grep 1521
[opc@bastion ~]$

I will generate a sqlplus connection.

[oracle@bastion client26ai]$ sqlplus test01/test_expire@svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

SQL*Plus: Release 23.26.1.0.0 - Production on Thu May 21 16:34:23 2026
Version 23.26.1.0.0

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


Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL>

And I can see that I have got a sqlplus connection with no timer/keepalive.

[opc@bastion ~]$ ss -nop | grep 1521
tcp   ESTAB  0      0   X.X.0.89:51404    X.X.1.135:1521
[opc@bastion ~]$

I will now configure Oracle Dead Connection Detection with SQLNET.EXPIRE_TIME parameter set in the client sqlnet.ora with a value of 1 minute.

[oracle@bastion ~]$ cd $TNS_ADMIN

[oracle@bastion admin]$ /usr/bin/grep -i expire sqlnet.ora
[oracle@bastion admin]$ 

[oracle@bastion admin]$ /usr/bin/vi sqlnet.ora

[oracle@bastion admin]$ /usr/bin/grep -i expire sqlnet.ora
SQLNET.EXPIRE_TIME=1
[oracle@bastion admin]$

I will run a new sqlplus connection.

[oracle@bastion admin]$ sqlplus test01/test_expire@svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

SQL*Plus: Release 23.26.1.0.0 - Production on Thu May 21 16:41:06 2026
Version 23.26.1.0.0

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

Last Successful login time: Thu May 21 2026 16:34:23 +02:00

Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL>

I can now see that I have got a connection configured with a timer and keep alive remaining of 38s.

[opc@bastion ~]$ ss -nop | grep 1521
tcp   ESTAB  0      0     X.X.0.89:62868    X.X.1.135:1521   timer:(keepalive,38sec,0)
[opc@bastion ~]$

Let’s configure the EXPIRE_TIME with a value of 15 minutes.

[oracle@bastion admin]$ /usr/bin/vi sqlnet.ora

[oracle@bastion admin]$ /usr/bin/grep -i expire sqlnet.ora
SQLNET.EXPIRE_TIME=15

I run a new sqlplus connection.

[oracle@bastion admin]$ sqlplus test01/test_expire@svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

SQL*Plus: Release 23.26.1.0.0 - Production on Thu May 21 16:43:25 2026
Version 23.26.1.0.0

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

Last Successful login time: Thu May 21 2026 16:42:29 +02:00

Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL>

And I now have got a connection configured with a timer and keep alive remaining of 14min.

[opc@bastion ~]$ ss -nop | grep 1521
tcp   ESTAB  0      0     X.X.0.89:60630    X.X.1.135:1521   timer:(keepalive,14min,0)
[opc@bastion ~]$

So, all good Oracle 26ai Client is supporting Dead Connection Detection with SQLNET.EXPIRE_TIME parameter.

Let’s test it with Oracle 19c Client

We can easily confirm again that Oracle 19c Client does not support Dead Connection Detection on the client side.

Let’s move back to Oracle 19c Client home.

[oracle@bastion admin]$ export PATH=/opt/oracle/client19c/bin

[oracle@bastion admin]$ which sqlplus
/opt/oracle/client19c/bin/sqlplus

Run a sqlplus connection.

[oracle@bastion admin]$ sqlplus test01/test_expire@svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

SQL*Plus: Release 19.0.0.0.0 - Production on Thu May 21 16:48:09 2026
Version 19.3.0.0.0

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

Last Successful login time: Thu May 21 2026 16:46:07 +02:00

Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL>

And check connection configuration.

[opc@bastion ~]$ ss -nop | grep 1521
tcp   ESTAB      0      0    X.X.0.89:64078    X.X.1.135:1521
[opc@bastion ~]$

There is no timer/keepalive handled with Oracle 19c Client.

To wrap up…

Oracle Database 26ai Client is now supporting Dead Connection Detection on the client side. For our customer configuration this will help the client to check every X minutes (EXPIRE_TIME configured value) for Dead Connection. So if the CMAN and listener connections have already died and if for any reason the Network Load Balancer is still keeping the connection with the client, the client will close the connection after X minutes.

L’article Oracle Database 26ai Client and SQLNET.EXPIRE_TIME est apparu en premier sur dbi Blog.

You probably refresh your non-production Oracle databases with production data from time to time or on a regular basis. Without Multitenant, the most common procedure to do this refresh is a DUPLICATE FROM BACKUP with RMAN. The drawback is the unavailability of the database being refreshed during the DUPLICATE. You first need to remove the old version of the database, then start the DUPLICATE and wait until it’s finished. If you have Enterprise Edition and enough CPU, you can lower the time needed for the refresh by allocating a sufficient number of channels. But with a small number of CPU (which is normal for a non-production server), or eventually with Standard Edition (single channel RMAN operations only), a multi-TB database refresh can take several hours to complete. And if it fails for some reasons, you need to retry the refresh, extending even more the downtime.

Multitenant brought new possibilities for refreshing a database, and my favorite one is a CREATE PLUGGABLE DATABASE from a database link (DB link). It’s dead easy compared to a DUPLICATE FROM BACKUP on a non-CDB database. And you can lower the downtime to the very minimum. Here is how I did this for several projects.

How to lower the downtime to the minimum when refreshing a non-production PDB?

You probably know that one of the advantage of a pluggable database is the easiness of changing its name. You just need to stop the PDB, rename it, and restart it. You can then use this technique to refresh a PDB under a temporary name and let the actual PDB available during the refresh. Once the refresh is finished, drop or rename the actual PDB, and rename the newest one to its target name. Even if your refresh takes hours, your downtime is limited to a couple of seconds/minutes.

Step 1: add an additional grant for source PDB’s administrator

The PDB administrator on the source database must have the CREATE PLUGGABLE DATABASE privilege:

ssh oracle@p01-srv-ora
. oraenv <<< P19PMT
sqlplus / as sysdba
Alter session set container=P19_ERP;
grant create pluggable database to SYSERP;
exit

Step 2: add a TNS entry on the target server

The target server must have a TNS entry to the source PDB (production). If your source PDB and its container are protected by a Data Guard configuration, dont’t forget to add both addresses:

ssh root@t01-srv-ora
su – oracle
. oraenv <<< D19PMT
vi $ORACLE_HOME/network/admin/tnsnames.ora
…
P19_ERP =
(DESCRIPTION =
   (LOAD_BALANCE = OFF)
   (FAILOVER = ON)
   (ADDRESS_LIST =
     (ADDRESS = (PROTOCOL = TCP)(HOST = p01-srv-ora)(PORT = 1521))
     (ADDRESS = (PROTOCOL = TCP)(HOST = p02-srv-ora)(PORT = 1521))
   )
   (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = P19_ERP)
   )
)

tnsping P19_ERP
…

Step 3: create a DB link on the target container

A DB link is required on the target container:

ssh root@t01-srv-ora
su – oracle
. oraenv <<< D19PMT
sqlplus / as sysdba
CREATE DATABASE LINK P19_ERP CONNECT TO SYSERP IDENTIFIED BY "*************"  USING 'P19_ERP';

select count(*) from dual@P19_ERP;
  COUNT(*)
----------
         1
exit

Step 4: prepare the scripts for the refresh

Basically, refresh will have 5 main tasks:

• create a new PDB with a temporary name _NEW on the target container from the source PDB
• start the new PDB for its correct registration in the container
• run an optional script for modifying production data (masking, disabling tasks, …)
• stop and rename the current PDB to _OLD, then start it again
• stop and rename the new PDB to its target name and start it again

Task 2 is needed because you cannot rename a PDB immediately after creation. You first need to open it, then close it for being able to change its name.

Let’s create 2 scripts on the target server, one shell script and one SQL script:

vi /home/oracle/scripts/refresh_D19_ERP.sh
#!/bin/bash
export ORACLE_SID=D19PMT
export REFRESH_LOG=/home/oracle/scripts/log/refresh_D19_ERP_`date +%d_%m_%Y-%H_%M_%S`.log
export ORACLE_HOME=`cat /etc/oratab | grep $ORACLE_SID | awk -F ':' '{print $2;}'`
date >> $REFRESH_LOG
$ORACLE_HOME/bin/sqlplus / as sysdba @/home/oracle/scripts/refresh_D19_ERP.sql >> $REFRESH_LOG
date >> $REFRESH_LOG
exit 0

vi /home/oracle/scripts/refresh_D19_ERP.sql
set timing on
show pdbs
alter pluggable database D19_ERP_OLD close immediate;
Drop pluggable database D19_ERP_OLD including datafiles;
show pdbs
create pluggable database D19_ERP_NEW from P19_ERP@P19_ERP ;
show pdbs
alter pluggable database D19_ERP_NEW open;
show pdbs
alter session set container=D19_ERP_NEW;
@/home/oracle/scripts/post_refresh_D19_ERP.sql 
alter session set container=CDB$ROOT;
alter pluggable database D19_ERP close immediate;
alter pluggable database D19_ERP rename global_name to D19_ERP_OLD;
alter pluggable database D19_ERP_OLD open;
show pdbs
alter pluggable database D19_ERP_NEW close immediate;
alter pluggable database D19_ERP_NEW rename global_name to D19_ERP;
Alter pluggable database D19_ERP open;
Alter pluggable database D19_ERP save state;
show pdbs
exit

It does the job, although these are very basic scripts: further controls could be added to trap errors, manage services, and so on.

Step 5: schedule the refresh

Scheduling can be done through the crontab, for example every evening at 11.30PM:

crontab -l | grep D19_ERP | grep refresh
30 23 * * * sh /home/oracle/scripts/refresh_D19_ERP.sh

Conclusion

This is definitely a smart solution as soon as you have enough space on disk to have 2 copies of the PDB. It’s quite reliable and ticks all the boxes where I deployed these scripts.

L’article Reduce downtime when refreshing your non-production databases using Multitenant est apparu en premier sur dbi Blog.

Recently, after a successful migration to GoldenGate 26ai, a customer complained that he was seeing a lot of the following error in the ggserr.log file of a GoldenGate deployment (I replaced the names for the purpose of this blog).

2026-05-18T14:32:35.948+0200  ERROR   OGG-08502. Oracle GoldenGate Receiver Service for Oracle:   Path path21 not found.

More precisely, in that case, path21 is a distribution path sending trail files from deployment ogg_test_02 to ogg_test_01. And the error shown above appeared in the log file of the ogg_test_01 deployment.

While this error did not seem to indicate any operational issue in the replication, after checking on multiple environments, I confirmed that it appears everywhere. So what is happening exactly ?

If you get this error and do not know where it comes from, log in to the web UI of the affected deployment, and go to the Receiver Service Paths tab. You should see a list of the distribution paths that are connecting to your deployments. The example below shows the path21 that is mentioned in the error.

How to reproduce the error ?

If you click on this path… Nothing happens ! And by “nothing”, I mean “nothing abnormal”. In fact, the statistics are properly displayed (see below), and there is no error shown to the user. However, if you look at your ggserr.log file you will see that the error given above appears.

At first glance, this might not seem like a huge issue, because if you don’t click on the receiver path, you will not get the error. However, in the log file of the customer, the error appeared regularly. Every minute, to be precise.

Why do I get this error even when I’m not accessing the web UI ?

Luckily, when debugging this issue, I started by putting the target in a blackout in the Oracle Enterprise Manager. To my surprise, the error was gone during the blackout and reappeared right after.

In this case, the Enterprise Manager Plug-in for Oracle GoldenGate is monitoring the status of the deployment every minute and generates the error in the process.

When looking at the targets in the OEM, there is no error. Again, no operational impact.

Does it depend on the way you create the distribution path ?

GoldenGate offers multiple ways of managing deployments : REST API, adminclient, or the web UI. Unfortunately, some bugs (and some features…) mean that you should avoid managing some objects with some of these tools (read why you shouldn’t create profiles through the adminclient, for instance).

In this specific case, all distribution path creation methods lead to the same error in the log file. It doesn’t matter whether you create the distribution path with the adminclient, the REST API or the web UI. They will all lead to this error.

Advanced – What’s happening exactly ?

Let’s dig a bit to see what is happening behind the scenes. By looking at the restapi.log file (read my blog on how to analyze REST API logs efficiently), we can see the full error:

2026-05-18 09:08:58.402+0000 ERROR|RestAPI.recvsrvr | Request #9: {
     "context": {
         "httpContextKey": 140097141801744,
         "verbId": 2,
         "verb": "GET",
         "originalVerb": "GET",
         "uri": "/services/v2/targets/path21",
         "protocol": "http",
         "headers": {
             ...
         },
         "host": "vmogg",
         "securityEnabled": false,
         "authorization": {
             "authUserName": "ogg",
             "authUserRole": "Security",
             "authMode": "Cookie"
         },
         "requestId": 8,
         "uriTemplate": "/services/{version}/targets/{path}",
         "catalogUriTemplate": "/services/{version}/metadata-catalog/path"
     },
     "isScaRequest": true,
     "content": null,
     "parameters": {
         "uri": {
             "path": "path21",
             "version": "v2"
         },
         "query": {
             "WindowRef": "%2Fservices%2Fv2%2Fcontent%2F%23%2FrecvsrvrPaths%2Fpath21%2FpathNetworkStats"
         }
     }
 }
 Response: {
     "context": {
         ...
     },
     "isScaResponse": true,
     "content": {
         "$schema": "api:standardResponse",
         "links": [
             {
                 "rel": "canonical",
                 "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/targets/path21",
                 "mediaType": "application/json"
             },
             {
                 "rel": "self",
                 "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/targets/path21",
                 "mediaType": "application/json"
             }
         ],
         "messages": [
             {
                 "$schema": "ogg:message",
                 "title": "Path path21 not found",
                 "code": "OGG-08502",
                 "severity": "ERROR",
                 "issued": "2026-05-18T09:08:58Z",
                 "type": "https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes"
             }
         ]
     }
 }

The issue comes from the following endpoint : /services/v2/targets/path21. It is described in the documentation under Retrieve an existing Oracle GoldenGate Collector Path. But looking at another endpoint described in Get a list of distribution paths, we get the following response:

{
    "$schema": "api:standardResponse",
    "links": [
        {
            "rel": "canonical",
            "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/targets",
            "mediaType": "text/html"
        },
        {
            "rel": "self",
            "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/targets",
            "mediaType": "text/html"
        },
        {
            "rel": "describedby",
            "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/metadata-catalog/targets",
            "mediaType": "application/schema+json"
        }
    ],
    "messages": [],
    "response": {
        "$schema": "ogg:collection",
        "items": [
            {
                "links": [
                    {
                        "rel": "parent",
                        "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/targets",
                        "mediaType": "application/json"
                    },
                    {
                        "rel": "canonical",
                        "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/targets/path21_ogg26dist2_7811",
                        "mediaType": "application/json"
                    }
                ],
                "$schema": "ogg:collectionItem",
                "name": "path21",
                "status": "running",
                "targetInitiated": false
            }
        ]
    }
}

Here, we see that the endpoint associated with the path21 object is not recvsrvr/v2/targets/path21 but recvsrvr/v2/targets/path21_ogg26dist2_7811. And looking at this second endpoint, we do not get an error.

{
    "$schema": "api:standardResponse",
    "links": [
        {
            "rel": "canonical",
            "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/targets/path21_ogg26dist2_7811",
            "mediaType": "text/html"
        },
        {
            "rel": "self",
            "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/targets/path21_ogg26dist2_7811",
            "mediaType": "text/html"
        },
        {
            "rel": "describedby",
            "href": "https://vmogg/services/ogg_test_01/recvsrvr/v2/metadata-catalog/path",
            "mediaType": "application/schema+json"
        }
    ],
    "messages": [],
    "response": {
        "name": "path21",
        "status": "running",
        "$schema": "ogg:distPath",
        "source": {
            "uri": "trail://localhost:7811/services/v2/sources?trail=pdb2/bb"
        },
        "target": {
            "$schema": "ogg:distPathEndpoint",
            "uri": "ws://vmogg/services/v2/targets?trail=pdb2/bb"
        },
        "options": {
            "network": {
                "appOptions": {
                    "appFlushBytes": 27985,
                    "appFlushSecs": 1
                },
                "socketOptions": {
                    "tcpOptions": {
                        "ipDscp": "DEFAULT",
                        "ipTos": "DEFAULT",
                        "tcpNoDelay": false,
                        "tcpQuickAck": true,
                        "tcpCork": false,
                        "tcpSndBuf": 16384,
                        "tcpRcvBuf": 131072
                    }
                }
            }
        }
    }
}

The problem is that it was never decided for path21 to be referred to as path21_ogg26dist2_7811 internally. And it looks like GoldenGate does not know about it either… So until the bug is corrected, you will have to filter this OGG-08502 Path not found error out of the ggserr.log file if you use it for monitoring.

L’article OGG-08502 Path not found error from OGG Receiver Service est apparu en premier sur dbi Blog.

In this blog, I will use the latest version of the Enterprise Manager (24ai) and monitor GoldenGate 26ai deployments. The overall workflow is the same for other versions of the Enterprise Manager and GoldenGate, provided OGG is in the Microservices Architecture.

Here are the main steps to monitor GoldenGate targets from the Enterprise Manager:

• Update the catalog in the Enterprise Manager
• Deploy the plug-in on the management server
• Deploy the plug-in on the agent
• Configure the discovery module
• Promote the new targets

Checking if the plugin is already installed

Before attempting to install the plug-in, make sure it is not already installed in your environment. To check this, go to Setup > Extensibility > Plug-ins, and expand the Middleware section. If you do not see any line named Oracle GoldenGate, it means the plug-in is not installed yet.

Update the Enterprise Manager catalog

Since most OEM environments do not have access to the Oracle Support directly, we’ll download the plug-in in offline mode. To do so, go to the Setup > Provisioning and Patching > Offline Patching section.

Once in the Offline Patching section, make sure Offline is selected for the connection and download the catalog file as instructed from an environment with access to the Oracle support website. Transfer it to where you have access to the OEM UI, and upload it.

Once the catalog is uploaded, you should see the following information message.

Then, go to Setup > Extensibility > Self Update and click on Check Updates.

You should see the following pop-up appear, with a link from where you will be able to download the OEM Self Update catalog file. For reference, the one I had when writing this blog was the following : https://updates.oracle.com/Orion/Download/download_patch/p9348486_112000_Generic.zip

As instructed, transfer this patch to the OMS host and import it with emcli and the import_update_catalog action. You can also import it from another managed host. It should take around twenty seconds to import everything.

oracle@oem24:~/ [oem24] emcli import_update_catalog -file=/tmp/p9348486_112000_Generic.zip -omslocal
Processing catalog for Diagnostic Tools
Processing update: Diagnostic Tools - AHFFI 25.1.0.1.0 for Linux
Processing update: Diagnostic Tools - AHF 25.5.0.0.0 for HP

[...]

Processing update: Plug-in - GoldenGate Plug-in now supports monitoring of Oracle GoldenGate Microservices, in addition to the Oracle GoldenGate Classic
Processing update: Plug-in - GoldenGate Plug-in now supports monitoring of Oracle GoldenGate Microservices, in addition to the Oracle GoldenGate Classic
Processing update: Plug-in - GoldenGate Plug-in now supports monitoring of Oracle GoldenGate Microservices, in addition to the Oracle GoldenGate Classic
Processing update: Plug-in - GoldenGate Plug-in now supports monitoring of GoldenGate Microservices Architecture, in addition to the GoldenGate Classic Architecture

[...]

Successfully uploaded the Self Update catalog to Enterprise Manager. Use the Self Update Console to view and manage updates.
Time taken for import catalog is 17.289 seconds.

Download GoldenGate plug-in

When this is done, go back to the Self Update page, click on the Plug-In section. You will see the different versions of GoldenGate that are available. When I’m writing this blog, the latest version of the plug-in is 13.5.2.0.0 (the latest patch released in January 2026, 13.5.2.0.6, will be a topic for another blog). Click on the latest version and then on Download.

The following pop-up gives you the link from which you should download the plug-in update file. In my case, it was https://updates.oracle.com/Orion/Services/download/p34651099_112000_Generic.zip?aru=24962501&patch_file=p34651099_112000_Generic.zip.

Once the file is downloaded, import it in the same way as before with the catalog, but this time with the emcli import_update action.

oracle@oem24:~/ [oem24] emcli import_update -omslocal -file=/tmp/p34651099_112000_Generic.zip
Processing update: Plug-in - GoldenGate Plug-in now supports monitoring of Oracle GoldenGate Microservices, in addition to the Oracle GoldenGate Classic
Successfully uploaded the update to Enterprise Manager. Use the Self Update Console to manage this update.

Once this is done, go back to the Setup > Extensibility > Plug-in tab and expand the Middleware section. You should now see Oracle GoldenGate, and 13.5.2.0.0 as the downloaded version.

Deploy the GoldenGate plug-in on the Management Server

Warning : Deploying the plug-in on the management server will temporarily restart OMS components and briefly interrupt monitoring operations. To deploy the plug-in, you have two options:

• Deploying the plug-in from the web UI.
• Deploying the plug-in from the CLI.

Deploying the plug-in from the web UI

From the web UI, click on the Oracle GoldenGate plug-in, then on Deploy On, and deploy the plug-in on the Management Servers.

Make sure the correct version of the plug-in is chosen (13.5.2.0.0), and click on Next to run the prerequisite checks.

Once the checks are successfully completed, click on Next.

You should now select the repository credentials for the OEM. You should either use new credentials (if it’s a new environment) or use existing named credentials. Click on Next.

Once everything is done, click on Deploy.

As instructed, you can check the status of the deployment with the emctl status oms -details command.

oracle@oem24:~/ [oem24] emctl status oms
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
WebTier is Up
Oracle Management Server is Down

This is due to the following plug-ins being deployed on the management server or undeployed from it:
----------------------------------------
Plugin name:    : Oracle GoldenGate
Version:        : 13.5.2.0.0
ID:             : oracle.fmw.gg
----------------------------------------

Deploying the plug-in from the CLI

Alternatively, you can deploy the plug-in with the following command, using the oracle.fmw.gg ID for the plug-in and the latest 13.5.2.0.0 version.

emcli deploy_plugin_on_server -plugin="oracle.fmw.gg:13.5.2.0.0"

Once the plug-in is deployed on the Management Server, you can check again in the web UI : the latest version should be in the On Management Server section.

Deploy the plug-in on the agent

For each GoldenGate host where an OEM agent is running, deploy the plug-in. To do so, from the web UI, click on the Oracle GoldenGate plug-in, then on Deploy On, and select Management Agent.

There is currently a bug with the Supported Target Versions. No matter your patch level, you will not see the latest versions of GoldenGate. Do not worry about this yet. Just make sure 13.5.2.0.0 is selected.

Then, select the agent on which you want to deploy the plug-in.

Let the prerequisite checks run…

And once everything is ready, click on Deploy.

You can check that everything is running properly with the emcli get_plugin_deployment_status command.

Configure GoldenGate monitoring in the Enterprise Manager

Once the plug-in is correctly deployed on the OMS host and on the GoldenGate host agent, you can configure the module. I will only cover the configuration for the Microservices Architecture. Go to the Setup > Add Target > Configure Auto Discovery tab.

Choose the correct agent host, and click on Discovery Modules.

Enable the Oracle GoldenGate Microservices module, click on it, and then on Edit Parameters.

If you deployed GoldenGate with a reverse proxy, set up the plug-in as such.

If you deployed GoldenGate with a port for each service, enter the service manager port (7809, by default).

Warning : if your installation is secured with certificates, make sure to follow the instructions I gave in a blog to avoid EM-90000 errors when discovering new targets.

Once this is done, just go back to the Configure Auto Discovery section, click on the correct host, and then click on Discover Now. Then, go back to the Configure Auto Discovery section. You should now see a greater number of targets in the Discovered targets section.

If the number of targets did not increase, despite a successful discovery, check the blog linked above.

Click on the number of targets to jump to the Auto Discovery Results section. Select the newly discovered Service Manager target, and click on Promote. Once the target is promoted, you should see the new GoldenGate targets being monitored by the Enterprise Manager !

L’article Install and configure OEM plug-in for GoldenGate est apparu en premier sur dbi Blog.