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.

In a previous blog, I presented all the log files available in GoldenGate. Each of them has its own format and characteristics, but they have one common aspect: they can be customized.

Standard GoldenGate logging configuration files are located in the $OGG_HOME/lib/utl/logging directory.

> ll $OGG_HOME/lib/utl/logging
-rw-r-----. 1 oracle oinstall  1066 Nov 17  2018 app-adminsrvr-debug.xml
-rw-r-----. 1 oracle oinstall  1076 Jan 10  2019 app-adminsrvr-events.xml
-rw-r-----. 1 oracle oinstall  1066 Nov 17  2018 app-distsrvr-debug.xml
-rw-r-----. 1 oracle oinstall  1040 Apr 17  2017 app-extract-events.xml
-rw-r-----. 1 oracle oinstall  1066 Nov 17  2018 app-pmsrvr-debug.xml
-rw-r-----. 1 oracle oinstall  1397 Apr  1  2018 app-pmsrvr-default.xml
-rw-r-----. 1 oracle oinstall  1066 Nov 17  2018 app-recvsrvr-debug.xml
-rw-r-----. 1 oracle oinstall  1048 Jan 22  2020 app-replicat-debug509.xml
-rw-r-----. 1 oracle oinstall  1040 Apr 17  2017 app-replicat-events.xml
-rw-r-----. 1 oracle oinstall  1066 Nov 17  2018 app-ServiceManager-debug.xml
-rw-r-----. 1 oracle oinstall  2459 Jan 17  2024 app-ServiceManager-services.xml
-rw-r-----. 1 oracle oinstall  1282 Dec 19 18:44 ogg-AIService.xml
-rw-r-----. 1 oracle oinstall  4946 May 14  2020 ogg-audit.xml
-rw-r-----. 1 oracle oinstall  1582 Jun 28  2023 ogg-ConfigService.xml
-rw-r-----. 1 oracle oinstall  4487 Jan 10  2019 ogg-ggserr.xml
-rw-r-----. 1 oracle oinstall 18162 Jun 26  2020 ogg-loggers.json
-rw-r-----. 1 oracle oinstall  1095 Sep 25  2019 ogg-loggers.xml
-rw-r-----. 1 oracle oinstall  2180 Sep 11  2024 sca-default.xml
-rw-r-----. 1 oracle oinstall  1211 Jan 10  2019 sca-restapi.xml
-rw-r-----. 1 oracle oinstall  1210 Jun  6  2022 sca-stdout.xml

The process to modify logging properties of any GoldenGate log file is to copy one of these files in your deployment and update it. It means that you can have different logging properties between your deployments.

Oracle GoldenGate Microservices uses a hierarchical logger framework with Log4j-style appenders, layouts, logger inheritance, and category namespaces. I will not dwell on all the configuration files in this blog, but let’s try to describe the most useful ones.

sca-restapi.xml

<?xml version="1.0"?>
<configuration>

  <!--
   /- ============================================================= -\
   !-   s c a - r e s t a p i . x m l                               -|
   !-                                                               -|
   !-   Logging control file for recording all REST API calls       -|
   !-   to an OGG deployment.                                       -|
   \- ============================================================= -/
  ! -->

  <appender  name="sca-restapi.log"  class="RollingFileAppender">
    <level  value="info"/>
    <param   name="File"             value="restapi.log"/>
    <param   name="MaxFileSize"      value="10MB"/>
    <param   name="MaxBackupIndex"   value="9"/>
    <param   name="BufferedIO"       value="false"/>
    <param   name="Append"           value="true"/>
    <layout class="PatternLayout">
      <param name="Pattern"          value="%d{%Y-%m-%d %H:%M:%S%z} %-5p|%-36.36c| %m%n"/>
    </layout>
  </appender>

  <!--
   !-   M i c r o s e r v i c e s   A r c h i t e c t u r e
  ! -->
  <logger          name="RestAPI">
    <appender-ref  name="sca-restapi.log"/>
    <level        value="info"/>
  </logger>

</configuration>

The sca-restapi.xml file is the logging configuration file for the restapi.log file.

REST API logs are the most verbose across all GoldenGate log files. In production environments where the REST API is often called, you could easily go over the 10 log files in a day or even less. If you have enough space, I would strongly recommend increasing the retention and/or the maximum size of a single log file. This way, you ensure that you keep enough logs for debugging and analysis.

To modify the retention, change MaxFileSize to set the maximum log file size and MaxBackupIndex to choose the number of files you want to keep (on top of the active log file).

Let’s copy the file in the deployment home (it could be any deployment, including the Service Manager home).

cd $OGG_DEPLOYMENT_HOME/etc/conf/logging
cp -p $OGG_HOME/lib/utl/logging/sca-restapi.xml .
vim sca-restapi.xml

For instance, to have 5 files of 50 MB each, edit the following lines:

    <param   name="MaxFileSize"      value="50MB"/>
    <param   name="MaxBackupIndex"   value="4"/>

Once this is done, just restart the administration service.

What about the other log files ?

If you want to increase the retention or the log file size of any other log file in GoldenGate, just use the following mapping and repeat the same process. If you want to edit the Service Manager logging properties, you should also restart it.

Warning: If you want to use the same configuration across all your deployments, you could modify the standard files in $OGG_HOME/lib/utl/logging and create links from the deployments to this file. However, make sure you do not lose these changes when patching out-of-place !

Can I increase the retention to more than 10 files ?

Yes, there is no problem having more than 10 log files. Just increase the MaxBackupIndex (9, by default) to the number of log files you want, minus 1. For 20 log files, set MaxBackupIndex to 19.

L’article Increase GoldenGate 26ai Log Retention est apparu en premier sur dbi Blog.

Let’s now talk about the INS-85038 error, which is rather generic. You will definitely need more details to investigate, and this blog does not cover all possibilities. Still, I will try to give you solutions, including one that should work in most cases.

As a reminder, there are three steps when deleting a GoldenGate deployment with oggca.sh :

• Verify the deployment credentials
• Stop the deployment services
• Unregister the deployment in the Service Manager

In my case, the problem I noticed is that the configuration assistant waits for the deployment to be stopped. However, it fails after some time with the following error details:

Log of this session available at: /u01/app/oraInventory/logs/OGGCAConfigActions2026-04-22_12-51-46PM
Setup completed with overall status as Succeeded
Setup completed with overall status as Failed
Verification failed. Expected value: (NOT) 'running', actual value: 'running'
Verification (0) failed for property 'response/status'.
Verification failed for REST call to '/services/v2/deployments/ogg_test_blog'
Results for "Stop the deployment":
..."Retrieving the 'ogg_test_blog' deployment details.": SUCCEEDED
..."Stop the 'ogg_test_blog' deployment.": SUCCEEDED
..."Verify the 'ogg_test_blog' deployment is stopped": FAILED
(1) Errors ocurred when trying to stop deployment. Make sure Service Manager is running. Check Service Manager log files for more details.

However, when debugging this issue, I observed the following strange behavior. While the configuration assistant complains about the deployment being started, my deployment was stopped when checking its status a few seconds after.

I decided to analyze the restapi.log file of my deployment. What I discovered was that the configuration assistant was checking the status of the deployment every ten seconds for two minutes. After this period, it fails with the abovementioned error.

What to do after an INS-85038 error ?

If you still want to delete this deployment, you have two options:

• Deleting the deployment with the REST API, with the method described in this blog, using the dedicated endpoint.
• Restarting the deployment and re-running the configuration assistant. But this time, if you get the same error as before, remember to wait. Once the deployment is completely stopped, click on Skip in the configuration assistant. The assistant will follow with the next step, unregistering the deployment from the Service Manager.

To summarize, if you get an INS-85038 error in the configuration assistant, try to remove the deployment with the REST API. But if the reason for this error is just a deployment that is not stopping soon enough, just use the Skip button to continue removing the deployment when it is finally stopped.

L’article Deployment removal failed in GoldenGate Configuration Assistant (INS-85038) est apparu en premier sur dbi Blog.

If you are upgrading to GoldenGate 26ai and migrating from Classic to Microservices Architecture, you must re-discover GoldenGate targets in the Enterprise Manager. The discovery module settings vary from one setup to another, but for a GoldenGate deployment exposed via an NGINX reverse proxy, you should set up the discovery module with the following:

While this could be enough in some GoldenGate setups, it will fail if the certificate chain is not trusted by the OEM agent. In fact, if you run a discovery of your host with the settings mentioned above, no target will be discovered. This is especially tricky, since the Enterprise Manager will tell you “Discover Now – Completed Successfully“.

Open the ogg_so_logs.log.0 file in the agent_inst/sysman/emd directory of your target agent. You will see that the discovery has failed with the following error : INFO: Exception occured when tried with SSL deployment. SSLHandshakeException.

oracle@vmogg:~ [emagent] vim ogg_so_logs.log.0
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery createDiscovery
INFO: Discovery : Discovering Oracle Goldengate Instances . Discovery parameters values are , Port=443, UserName=ogg, HostName=vmogg, OGG Mode=Microservices, EMStateDir=/u01/app/oracle/agent_24ai/agent_inst
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery createDiscovery
INFO: Discovery :Target name prefix =oggtest:
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery createDiscovery
INFO: agentTrustLocation:/u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrl
INFO: Discovery : Invoking URL request :https://vmogg:443/services/v2/deployments
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrlForSSL
INFO: Trying to connect as a ssl connection https://vmogg:443/services/v2/deployments
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrlForSSL
INFO: SSLHandshakeException while getting response for URL:https://vmogg:443/services/v2/deployments . javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrl
INFO: Exception occured when tried with SSL deployment. SSLHandshakeException: Failed to connect to ssl Microservices . Retrying via non ssl microservices. Trying with http.
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrl
SEVERE: For the Url = http://vmogg:443/services/v2/deployments , HTTP/response error code = 307
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery generateTargetsXML
SEVERE: Exception getting response from URL:https://vmogg:443/services/v2/deployments - com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery$GGDiscoveryException: Discovery failed : HTTP error code : 307 from URL:http://vmogg:443/services/v2/deployments
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery main
SEVERE: Exception during Targets discovery: EM-90000 - Target Discovery failed. Internal Error. Please contact System Administrator. - com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery$GGDiscoveryException: EM-90000 - Target Discovery failed. Internal Error. Please contact System Administrator.

The problem here is that the OEM agent does not trust the certificate chain being used in your GoldenGate installation. For the discovery (and the monitoring) to work, you need to register the certificates in the agent’s truststore.

Displaying the content of the truststore

First, let’s have a look at the content of the agent’s truststore. To do so, use the keytool utility shipped with the agent. Here is an example of a default AgentTrust.jks content. When prompted for the keystore password, use the configured truststore password (welcome, by default).

oracle@vmogg:~ [emagent] /u01/app/oracle/agent_24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/keytool -list -keystore /u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 9 entries

verisignclass1pca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 13:B8:4A:BA:EC:A3:DE:8C:71:9A:06:7D:E8:CF:18:5F:65:DC:19:E0:3E:BD:92:C2:0B:D3:8C:75:09:7B:E1:13
verisignclass3ca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): E7:68:56:34:EF:AC:F6:9A:CE:93:9A:6B:25:5B:7B:4F:AB:EF:42:93:5B:50:A2:65:AC:B5:CB:60:27:E4:4E:70
gtecybertrustglobalca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): A5:31:25:18:8D:21:10:AA:96:4B:02:C7:B7:C6:DA:32:03:17:08:94:E5:FB:71:FF:FB:66:67:D5:E6:81:0A:36
entrustsslca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 62:F2:40:27:8C:56:4C:4D:D8:BF:7D:9D:4F:6F:36:6E:A8:94:D2:2F:5F:34:D9:89:A9:83:AC:EC:2F:FF:ED:50
entrust2048ca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): D1:C3:39:EA:27:84:EB:87:0F:93:4F:C5:63:4E:4A:A9:AD:55:05:01:64:01:F2:64:65:D3:7A:57:46:63:35:9F
verisignserverca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 29:30:BD:09:A0:71:26:BD:C1:72:88:D4:F2:AD:84:64:5E:C9:48:60:79:07:A9:7B:5E:D0:B0:B0:58:79:EF:69
gtecybertrustca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 52:7B:05:05:27:DF:52:9C:0F:7A:D0:0C:EF:1E:7B:A4:21:78:81:82:61:5C:32:6C:8B:6D:1A:20:61:A0:BD:7C
entrustgsslca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 2F:2F:87:02:A6:ED:EC:B6:46:92:94:BC:A0:40:F6:3B:88:49:42:1F:CE:E1:C3:7D:1C:FB:EE:89:DC:CD:43:83
verisignclass2ca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): BD:46:9F:F4:5F:AA:E7:C5:4C:CB:D6:9D:3F:3B:00:22:55:D9:B0:6B:10:B1:D0:FA:38:8B:F9:6B:91:8B:2C:E9

Warning:
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1000-bit RSA key which is considered a security risk and is disabled.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.

Importing the certificate in the truststore

Let’s add the certificate in the agent’s truststore with the following command.

/u01/app/oracle/agent_24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/keytool -importcert -alias ogg_capath -file /path/to/ogg_certs/RootCA_cert.pem -keystore /u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks

If you are not sure which file you should add, keep in mind that it should be the same file you are using in the OGG_CLIENT_TLS_CAPATH environment variable when loading the GoldenGate environment and connecting to your deployments with the adminclient.

oracle@vmogg:~ [emagent] export OGG_CLIENT_TLS_CAPATH=/path/to/ogg_certs/RootCA_cert.pem
oracle@vmogg:~ [emagent] /u01/app/oracle/agent_24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/keytool -importcert -alias ogg_capath -file $OGG_CLIENT_TLS_CAPATH -keystore /u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks
Enter keystore password:
Owner: CN=OGG RootCA, O=OGG ROOT CA, C=AU
Issuer: CN=OGG RootCA, O=OGG ROOT CA, C=AU
Serial number: 1a11d06e7d73700aa85e35ffc0ce4a27dcfdaf7d
Valid from: Fri Mar 21 15:22:22 GMT 2026 until: Mon Mar 18 15:22:22 GMT 2036
Certificate fingerprints:
SHA1: 3C:99:5B:3A:D9:A4:64:6D:23:F0:0A:48:16:FA:AF:85:BD:26:E3:C7
SHA256: 8D:6F:1D:67:ED:D9:7B:C0:C8:0E:D1:0E:50:2F:15:25:45:5D:F2:1D:A2:AB:22:C7:2D:AE:05:19:F1:DE:28:31
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.35 Criticality=false

AuthorityKeyIdentifier [
KeyIdentifier [
0000: E3 BC BD 71 43 FD 85 B0 48 E1 44 A1 81 04 FA A9 …qC…H.D…..
0010: 1D 1C 45 16 ..E.
]
]

#2: ObjectId: 2.5.29.19 Criticality=true

BasicConstraints:[
CA:true
PathLen:2147483647
]

#3: ObjectId: 2.5.29.14 Criticality=false

SubjectKeyIdentifier [
KeyIdentifier [
0000: E3 BC BD 71 43 FD 85 B0 48 E1 44 A1 81 04 FA A9 …qC…H.D…..
0010: 1D 1C 45 16 ..E.
]
]

Trust this certificate? [no]: yes
Certificate was added to keystore

If you check the content of the keystore again, you will see the new entry under the alias you just added. We will use the -alias ogg_capath option to only display the new alias.

oracle@vmogg:~ [emagent] /u01/app/oracle/agent_24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/keytool -list -keystore /u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks -alias ogg_capath
Enter keystore password:
ogg_capath, Apr 19, 2026, trustedCertEntry,
Certificate fingerprint (SHA-256): 8D:6F:1D:67:ED:D9:7B:C0:C8:0E:D1:0E:50:2F:15:25:45:5D:F2:1D:A2:AB:22:C7:2D:AE:05:19:F1:DE:28:31

Without modifying anything in the Enterprise Manager, you can re-run the discovery. This time, the GoldenGate targets will be discovered ! To promote the new targets, just click on the number of targets discovered. You can also go in the Setup > Add Target > Auto Discovery Results section to view all discovered targets. Once this is done, the new targets will be monitored.

To summarize, in this NGINX context, OEM GoldenGate discovery fails with EM-90000 due to missing CA certificates in the agent truststore. Importing the proper CA chain into AgentTrust.jks resolves the SSL handshake failure.

L’article EM-90000 SSL Error With GoldenGate Targets in OEM est apparu en premier sur dbi Blog.

What we need:

• Internet access
• Oracle Support account
• new installation of Oracle Linux 8 or 9, RHEL 8 or 9, SLES 15 with enough space for Oracle binaries
• Java JDK 8 to JDK 11
• latest version of AutoUpgrade

Steps to proceed:

• update the system if not already performed
• install OpenJDK if java not yet installed on the system
• install Oracle preinstall package for 26ai
• create oracle base, inventory and home directories with relevant permissions
• change to oracle user created during installation of preinstall package for 26ai
• create AutoUpgrade home with some subdirectories
• download latest AutoUgrade version
• check version of AutoUpgrade
• create AutoUpgrade configuration file for software download
• configure AutoUpgrade keystore to enable access to Oracle Support
• launch software download
• create AutoUpgrade configuration file for Oracle Home creation
• launch Oracle Home creation
• check the newly installed Oracle AI Database 26ai environment

1) Update the system

sudo dnf update

2) Install OpenJDK if java not yet installed on the system

sudo dnf install -y java-11-openjdk

3) Install Oracle preinstall package for 26ai

sudo dnf install -y oracle-database-preinstall-23ai

4) Create oracle base, inventory and home directories with relevant permissions

sudo mkdir -p /u01/app/oracle
sudo mkdir -p /u01/app/oraInventory
sudo mkdir -p /u01/app/oracle/product/23.26.2/dbhome_1
sudo chown -R oracle:oinstall /u01/app/oracle
sudo chown -R oracle:oinstall /u01/app/oraInventory

5) Change to oracle user created during installation of preinstall package for 26ai

sudo su - oracle

6) Create AutoUpgrade home with some subdirectories

mkdir autoupgrade
mkdir autoupgrade/logs
mkdir autoupgrade/patches
mkdir autoupgrade/keystore
mkdir autoupgrade/etc
cd autoupgrade

7) Download latest version of AutoUpgrade

wget -O /home/oracle/autoupgrade/autoupgrade.jar https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

8) Check version of AutoUpgrade

java -jar autoupgrade.jar -version

9) Create AutoUpgrade configuration file for software download

vi etc/au-download.cfg

global.global_log_dir=/home/oracle/autoupgrade/logs
global.keystore=/home/oracle/autoupgrade/keystore

dl.folder=/home/oracle/autoupgrade/patches
dl.patch=RU,OPATCH
dl.target_version=23
dl.platform=LINUX.X64

10) Configure AutoUpgrade keystore to enable access to Oracle Support

java -jar autoupgrade.jar -config etc/au-download.cfg -patch -load_password
Processing config file ...

Starting AutoUpgrade Patching Password Loader - Type help for available options
Creating new AutoUpgrade Patching keystore - Password required
Enter password:
Enter password again:
AutoUpgrade Patching keystore was successfully created

MOS> add -user <your-mos-account-name>
Enter your secret/Password:
Re-enter your secret/Password:
MOS> save
Convert the AutoUpgrade Patching keystore to auto-login [YES|NO] ? YES
MOS> exit

AutoUpgrade Patching Password Loader finished - Exiting AutoUpgrade Patching

11) Launch software download

java -jar autoupgrade.jar -config etc/au-download.cfg -patch -mode download
AutoUpgrade Patching 26.3.260401 launched with default internal options
Processing config file ...
Loading AutoUpgrade Patching keystore
AutoUpgrade Patching keystore is loaded

Connected to MOS - Searching for specified patches

-----------------------------------------------------
Downloading files to /home/oracle/autoupgrade/patches
-----------------------------------------------------
DATABASE RELEASE UPDATE 23.26.2.0.0
    File: p39099680_230000_Linux-x86-64.zip \ 16%
...

After download has completed, we get the following output:

AutoUpgrade Patching 26.3.260401 launched with default internal options
Processing config file ...
Loading AutoUpgrade Patching keystore
AutoUpgrade Patching keystore is loaded

Connected to MOS - Searching for specified patches

-----------------------------------------------------
Downloading files to /home/oracle/autoupgrade/patches
-----------------------------------------------------
DATABASE RELEASE UPDATE 23.26.2.0.0
    File: p39099680_230000_Linux-x86-64.zip - VALIDATED

OPatch 12.2.0.1.51 for DB 23.0.0.0.0 (Apr 2026)
    File: p6880880_230000_Linux-x86-64.zip - VALIDATED
-----------------------------------------------------

At time of writing, 23.26.2 was just released and Data Pump Bundle Patch could not yet be downloaded for this Release Update.

12) Create AutoUpgrade configuration file for Oracle Home creation

vi etc/au-create-home.cfg

global.global_log_dir=/home/oracle/autoupgrade/logs

crh.folder=/home/oracle/autoupgrade/patches
crh.patch=RU,OPATCH
crh.target_version=23
crh.platform=LINUX.X64
crh.target_home=/u01/app/oracle/product/23.26.2/dbhome_1
crh.home_settings.edition=ee
crh.home_settings.oracle_base=/u01/app/oracle
crh.home_settings.inventory_location=/u01/app/oraInventory
crh.download=no

13) Launch Oracle Home creation

java -jar autoupgrade.jar -config etc/au-create-home.cfg -patch -mode create_home
AutoUpgrade Patching 26.3.260401 launched with default internal options
Processing config file ...
+-----------------------------------------+
| Starting AutoUpgrade Patching execution |
+-----------------------------------------+
Type 'help' to list console commands
patch>lsj -a
patch> +----+-------------+-------+---------+-------+----------+-------+---------------------+
|Job#|      DB_NAME|  STAGE|OPERATION| STATUS|START_TIME|UPDATED|              MESSAGE|
+----+-------------+-------+---------+-------+----------+-------+---------------------+
| 100|create_home_1|EXTRACT|EXECUTING|RUNNING|  09:29:32|37s ago|Extracting gold image|
+----+-------------+-------+---------+-------+----------+-------+---------------------+
Total jobs 1

patch> Job 100 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]
Jobs restored                  [0]
Jobs pending                   [0]

# Run the root.sh script as root for the following jobs:
For create_home_1 -> /u01/app/oracle/product/23.26.2/dbhome_1/root.sh

# Run the orainstRoot.sh script as root for the following jobs:
For create_home_1 -> /u01/app/oraInventory/orainstRoot.sh

Please check the summary report at:
/home/oracle/autoupgrade/logs/cfgtoollogs/patch/auto/status/status.html
/home/oracle/autoupgrade/logs/cfgtoollogs/patch/auto/status/status.log

To complete the installation, we need to execute with root privileges the two scripts mentioned at the end of the output.

14) Check the newly installed Oracle AI Database 26ai environment

more /home/oracle/autoupgrade/logs/cfgtoollogs/patch/auto/status/status.log
==========================================
   AutoUpgrade Patching Summary Report
==========================================
[Date]           Fri May 01 09:33:13 GMT 2026
[Number of Jobs] 1
==========================================
[Job ID] 100
==========================================
[DB Name]                create_home_1
[Version Before AutoUpgrade Patching] 23.0.0.0.0
[Version After AutoUpgrade Patching]  23.26.2.0.0
------------------------------------------
[Stage Name]    PENDING
[Status]        SUCCESS
[Start Time]    2026-05-01 09:29:32
[Duration]      0:00:00
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/pending
------------------------------------------
[Stage Name]    PREACTIONS
[Status]        SUCCESS
[Start Time]    2026-05-01 09:29:32
[Duration]      0:00:00
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/preaction
------------------------------------------
[Stage Name]    EXTRACT
[Status]        SUCCESS
[Start Time]    2026-05-01 09:29:32
[Duration]      0:01:17
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/extract
------------------------------------------
[Stage Name]    DBTOOLS
[Status]        SUCCESS
[Start Time]    2026-05-01 09:30:51
[Duration]      0:00:00
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/dbtools
------------------------------------------
[Stage Name]    INSTALL
[Status]        SUCCESS
[Start Time]    2026-05-01 09:30:52
[Duration]      0:02:20
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/install
------------------------------------------
[Stage Name]    OH_PATCHING
[Status]        SUCCESS
[Start Time]    2026-05-01 09:33:13
[Duration]      0:00:00
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/opatch
------------------------------------------
[Stage Name]    OPTIONS
[Status]        SUCCESS
[Start Time]    2026-05-01 09:33:13
[Duration]      0:00:00
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/options
------------------------------------------
[Stage Name]    ROOTSH
[Status]        SUCCESS
[Start Time]    2026-05-01 09:33:13
[Duration]      0:00:00
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/rootsh
------------------------------------------
[Stage Name]    DISPATCH
[Status]        SUCCESS
[Start Time]    2026-05-01 09:33:13
[Duration]      0:00:00
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/dispatch
------------------------------------------
[Stage Name]    POSTACTIONS
[Status]        SUCCESS
[Start Time]    2026-05-01 09:33:13
[Duration]      0:00:00
[Log Directory] /home/oracle/autoupgrade/logs/create_home_1/100/postaction
------------------------------------------

sqlplus -V

SQL*Plus: Release 23.26.2.0.0 - Production
Version 23.26.2.0.0

And that’s it.

L’article AutoUpgrade powered easy download and installation of Oracle AI Database 26ai on Linux est apparu en premier sur dbi Blog.