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.

The business requirements to be able to get hands on clones of production databases are nowadays countless:

• developer agility (needing separate and isolated databases),
• production-like shared environment providing same model and code but with a smaller footprint,
• test databases for software update testing,
• data sharing,
• point-in-time reporting, what-if scenario modeling or data audit.

For environments with big databases (tens of terabytes and more), Exascale is very well suited to do the job, with the following main features and advantages:

• source database flexibility: you can now clone read-write and read-only 23/26ai databases, at the PDB and CDB level
• no upstream dependencies: unlike ASM, Exascale no longer requires a test-master read-only copy
• storage reclamation is automatically performed by Exascale for extents no longer referenced by a file
• redirect-on-write techniques enable quick clone creation and maintenance with unprecedented space efficiency
• and last but not least, clone/snapshot is independent of source, which can be dropped without impacting clone

Before going through the details on how to make clones and snapshots, let’s remind what clones and snapshots are.

Snapshot

A snapshot is a read-only point-in-time copy of a file. Possible sources for snapshot creation are regular files, clones or another snapshot.

Clone

A clone is a read-write point-in-time copy of a file, possibly created from a regular file, another clone or a snapshot.

There are actually two types of clones: thin (space efficient) or full (byte-for-byte copy of source).

Cloning implicitly creates snapshots.

How do we create clones or snapshots of PDBs ?

This is where database kernel and Exascale integration really shines: physical storage operations are encapsulated in single SQL commands, thus there is no need to learn new tricky commands and clauses to leverage Exascale cloning and snapshoting capabilities. You use SQL commands you are already familiar with:

CREATE|ALTER PLUGGABLE DATABASE

Creating PDB snapshots

To create a read-only point-in-time reference to a PDB, use:

ALTER PLUGGABLE DATABASE pdb_name SNAPSHOT pdb_snapshot_name;

Remember that snapshots are inconsistent by default (which precisely makes quick creation possible); so cloning a snapshot triggers recovery based on redo data before the new clone can be opened read-write. Thus, required redo data has to be retained or restored from backup.

The DBA_PDB_SNAPSHOTS dictionary view is available to display snapshots information.

Creating PDB thin clones

A PDB thin clone is a space-efficient clone of an existing PDB. You need to use the SNAPSHOT COPY clause like in the following syntax:

CREATE PLUGGABLE DATABASE pdb_name FROM source_pdb_name SNAPSHOT COPY;

Thin cloning a PDB

CREATE PLUGGABLE DATABASE thin_clone_pdb_name FROM source_pdb_name SNAPSHOT COPY;
ALTER PLUGGABLE DATABASE thin_clone_pdb_name OPEN INSTANCES=ALL;

Thin cloning a PDB snapshot

CREATE PLUGGABLE DATABASE thin_clone_pdb_name FROM source_pdb_name USING SNAPSHOT pdb_snapshot_name SNAPSHOT COPY;
ALTER PLUGGABLE DATABASE thin_clone_pdb_name OPEN INSTANCES=ALL;

Creating PDB full clones

As already mentioned, a full clone is a byte-for-byte copy of an existing PDB and therefore takes the same storage space than source PDB. The command to be used is a simple:

CREATE PLUGGABLE DATABASE … FROM …

The missing SNAPSHOT COPY clause directs the database to create a complete block-for-block copy of the PDB.

CREATE PLUGGABLE DATABASE full_clone_pdb_name FROM source_pdb_name;
ALTER PLUGGABLE DATABASE full_clone_pdb_name OPEN INSTANCES=ALL;

Existing snapshots or thin clones can also be referenced as a source in the preceding commands.

What about cloning an entire container database ?

Space-efficient clones of an entire container database are possible thanks to the powerful gDBClone utility written by Ruggero Citton, to whom we owe other great utilities ODABR (consistent and incremental backup and restore for Oracle Database Appliance nodes), KVMBR (backup and restore of KVM domains) or more recently DSCM & DSCMREST (deployment of Oracle database containers with efficient storage snapshots).

The gDBClone utility enables:

• End-to-end thin and full cloning of a CDB with all its PDB
• File clone operations
• RMAN calls to make cloned files consistent
• Instance related files (such as password, spfile or TDE wallet files) creation
• GI registration

Here are some simple examples to respectively thin clone and full clone an entire CDB:

gDBClone.bin snap –sdbname source_db_name –tdbname target_db_name

gDBClone.bin clone –sdbname source_db_name –tdbname target_db_name

More on this powerful tool in Exascale documentation and Oracle Support KB145187 article.

Performance

Thin cloning a 2.4 TB PDB takes less than 12 seconds while opening the new thin clone on a two instances cluster database takes another 11 seconds, for a total elapsed time of the entire operation under 30 seconds !!!

Additional details can be found in this Alex Blyth blog post.

Conclusion

By leveraging state-of-the-art redirect-on-write technologies, Exascale is a leap forward and game changing technology when it comes to clone and snapshot features and capabilities. It is CI/CD friendly and the ideal tool to address the business requirements for test and qualification environments by letting DBAs provide very quickly space efficient copies of production or standby databases or PDBs.

Give it a try to be definitely convinced.

L’article Exascale new clone and snapshot capabilities est apparu en premier sur dbi Blog.

As a reminder, you have two main ways of creating and deleting deployments in GoldenGate:

• Using the configuration assistant oggca.sh
• Using the REST API and its deployment endpoints

I already covered the creation and removal of deployments with the configuration assistant in a previous blog. I also wrote about deployment creation with the REST API, but not yet about deletion.

Deleting the deployment from oggca.sh won’t work

From the GoldenGate Configuration Assistant (oggca.sh script), deleting a deployment is straightforward, but as shown below, you will be asked to input not only the Service Manager credentials, but also the deployment credentials !

This means that oggca.sh cannot be used for such a task.

Deleting a deployment with the REST API

To overcome this issue, let’s list the steps taken by oggca.sh when deleting GoldenGate deployment:

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

While asking for the deployment’s password might be relevant to avoid deleting the wrong deployment, you do not strictly need it. In fact, you can stop the deployment services from the Service Manager itself. To do so, use the update_deployment endpoint (PATCH /services/{version}/deployments/{deployment}) to change the status of the deployment to stopped. Using the Python client I presented in another blog, I will open a connection to the Service Manager and stop the deployment ogg_test_01.

>>> from oggrestapi import OGGRestAPI
>>> ogg_client = OGGRestAPI(url="http://vmogg:7809", username="ogg", password="***")
>>> ogg_client.update_deployment('ogg_test_01', data={"status":"stopped"})
{'$schema': 'api:standardResponse', 'links': [{'rel': 'canonical', 'href': 'https://vmogg/services/ServiceManager/v2/deployments/ogg_test_01', 'mediaType': 'application/json'}, {'rel': 'self', 'href': 'https://vmogg/services/ServiceManager/v2/deployments/ogg_test_01', 'mediaType': 'application/json'}], 'messages': []}

Once this is done, you can unregister the deployment from the Service Manager with the remove_deployment endpoint (DELETE /services/{version}/deployments/{deployment})

And for this, we never needed the deployment password !

To clean your installation, make sure to remove all files related to the old deployment. More specifically:

• The deploymentConfiguration.dat of your Service Manager was already edited, you do not need to clean it manually.
• You can delete or archive the deployment main directory.
• The $OGG_SM_HOME/var/run directory should be cleaned of the .dat files named after the deployment : rm $OGG_SM_HOME/var/run/ogg_test_01*

That’s it. You have successfully deleted your deployment, and you can re-create it anytime you want. And this time, remember to store the password !

L’article Delete a GoldenGate deployment when the password is lost est apparu en premier sur dbi Blog.

The patching of an Oracle Database Appliance needs to be secured. This is because it won’t limit to patching the databases: there is plenty of other components embedded with the patch, the goal being to keep everything updated. A possible rollback may be needed.

For sure, there is no possible rollback for firmwares, BIOS and ILOM (it’s unlikely you would need to go back to previous version), but you may need to rollback when it comes to patching the OS and the GI stack. Unlike DB homes, OS and GI stack are located on the ODA local disks, and can be protected during patching with LVM snapshots. This is the purpose of ODABR: making LVM snapshots of /, /u01 and /opt before applying the patch. If something goes wrong, you can revert to the previous stable state.

ODABR will need enough space on local disks for creating the snapshots, and sometimes available free space is not enough. How to deal with that?

When taking the snapshots?

Before using ODABR, I would recommend doing a cleanup of the following filesystems: /, /u01 and /opt. You will need 20+% of free space in these filesystems, otherwise the patch prechecks won’t give you the green light. ODABR is based on Copy-On-Write technology, meaning that old versions of the changed blocks will be kept for going back in time if needed. Don’t unzip the patch files after taking the snapshots if the patch files reside on the local disks! Once you’re ready to patch, the minute before registering the patch and applying the DCS components update, you can use ODABR to take the snapshots.

When releasing the snapshots?

Once you successfully applied the system patch and GI patch, and once you verified that everything runs fine with the new GI binaries, you can safely use ODABR to delete the snapshots. If you need to apply multiple patches, make new snapshots before each jump, you will never need to revert to the oldest version once you are in a stable intermediate version.

Are the ODABR snapshots useful for DB homes?

Absolutely not. DB homes are located under /u01/app/odaorahome, a dedicated ACFS filesystem on the DATA diskgroup. You don’t need snapshot features on this very filesystem because patching a DB home will create a new home and move the database into this new DB home, the old one being kept as long as you want to. You can delete older DB homes months after patching was done. I usually delete old ones as part of the patching job once everything is fine, but I always backup the old DB home with a tar czf in case of. If you need to revert a database to an old DB home, you can do it manually and use a RMAN backup to restore the database, or eventually rollback the datapatch if needed. This is rarely used.

Location of the snapshots

ODABR relies on LVM snapshots, not something really specific to ODA. Snapshots are stored in the remaining space of the Volume Group. Most ODAs were sold with 2x 500GB local disks (SSDs) protected with a software RAID and allocated to a single Volume Group VolGroupSys. When doing the ODA setup, only a part of the storage is allocated to the system volumes as Logical Volumes (LogVolSwap, LogVolOpt, LogVolU01, LogVolRoot), meaning that a comfortable amount of space is available for ODABR:

pvs
  PV           VG          Fmt  Attr PSize   PFree
  /dev/md126p3 VolGroupSys lvm2 a--  446.09g 285.09g

/opt/odabr/odabr backup -snap
...
SUCCESS: 2026-04-22 17:10:33: LVM snapshots backup done successfully

pvs
  PV           VG          Fmt  Attr PSize   PFree
  /dev/md126p3 VolGroupSys lvm2 a--  446.09g 150.09g

ODABR additionally backups ASM metadata, because if you revert to a previous set of LVM snapshots with an older GI release, your ASM metadata would also need to be in the corresponding version.

Default snapshot sizes and real needs

Default snapshots size is the size of the Logical Volumes, here is an example for a 30GB /, a 55GB /opt and a 50GB /u01:

/opt/odabr/odabr infosnap

│▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│
 odabr - ODA node Backup Restore - Version: 2.0.2-06
 Copyright 2013, 2025, Oracle and/or its affiliates.
 --------------------------------------------------------
 RACPack, Cloud Innovation and Solution Engineering Team
│▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒│

LVM snap name         status                COW Size              Data%
-------------         ----------            ----------            ------
root_snap             active                30.00 GiB             0.01%
opt_snap              active                55.00 GiB             0.01%
u01_snap              active                50.00 GiB             0.01%

This is quite confortable, there won’t be 100% blocks changed during the patching, for sure. If you don’t have these 135GB of free space, you can specify lower values for the snapshots, but make sure to limit modifications on the files residing on these 3 Logical Volumes during the patch:

/opt/odabr/odabr backup -snap -osize 18 -rsize 10 -usize 25

These settings were enough for my latest patches.

The ODA X9-2 series exception

As far as I remember, ODAs always had a confortable system disk sizes. 500GB is large enough for OS, odacli and GI stack plus a couple of files of your own. Since version 19.10, DB homes and diagnostic destination are now located within ACFS volumes, meaning that it doesn’t take a single MB from the local disks:

df -h | grep -e Filesystem -e u01
Filesystem                          Size  Used Avail Use% Mounted on
/dev/mapper/VolGroupSys-LogVolU01    49G   27G   20G  58% /u01
/dev/asm/odabase_n0-225              30G  2.5G   28G   9% /u01/app/odaorabase0
/dev/asm/orahome_sh-225              80G   44G   37G  54% /u01/app/odaorahome

As 19.10 was already available when X9-2 was released, Oracle decided to decrease the system disks from 500GB to 250GB, meaning that you didn’t have the margin you had with the previous generations. The problem was solved with X10 series and onwards, system disks are now back to 500GB as they were on X8-2 series.

What I mean is that you’ll be most probably concerned about filesystem contention for ODABR if you have X9-2 series.

How can you deal with insufficient disk space when using ODABR?

Imagine you have this kind of configuration:

pvs
  PV           VG          Fmt  Attr PSize   PFree
  /dev/md126p3 VolGroupSys lvm2 a--  222.56g 2.56g

On this ODA, /opt and /u01 have been extended for some reasons, and there is almost no space left on the Volume Group.

If you try to use ODABR to take snapshots, you will get this error:

Available LVM size X is less than required snapshot size Y

2.56GB is way too small for using ODABR: you will need to reduce the size of /u01, /opt or both. First, a cleanup is needed to free up some space. Once done, you’ll be able to reduce the size of /u01 and/or /opt. But these filesystems will need to be unmounted. And it cannot be done without stopping/starting some processes. Actually, pretty much all the processes running on your ODA.

Stopping the processes and reducing the filesystems

Let’s reduce the /u01 and /opt Logical Volumes’ size in this example:

su - root

df -h /u01 /opt

Filesystem                          Size  Used Avail Use% Mounted on
/dev/mapper/VolGroupSys-LogVolU01    61G   23G   36G  39% /u01
/dev/mapper/VolGroupSys-LogVolOpt    70G   48G   22G  68% /opt

export ORACLE_HOME=/u01/app/19.30.0.0/grid
$ORACLE_HOME/bin/crsctl stop crs

lvreduce -L 50G /dev/VolGroupSys/LogVolU01 -r
Do you want to unmount "/u01" ? [Y|n] y
umount: /u01: target is busy.
fsadm: Cannot proceed with mounted filesystem "/u01".
  /usr/sbin/fsadm failed: 1
  Filesystem resize failed.

lsof /u01/
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
java    23727 root   26r   REG  252,3 16303574 1208968 /u01/app/19.30.0.0/grid/jlib/srvm.jar

kill -9 23727 ; umount /u01
umount: /u01: target is busy.

kill -9 23727 ; umount /u01
-bash: kill: (23727) - No such process

lvreduce -L 50G /dev/VolGroupSys/LogVolU01 -r
fsck from util-linux 2.32.1
/dev/mapper/VolGroupSys-LogVolU01: 76718/4063232 files (7.3% non-contiguous), 6220430/16252928 blocks
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/mapper/VolGroupSys-LogVolU01 to 13107200 (4k) blocks.
The filesystem on /dev/mapper/VolGroupSys-LogVolU01 is now 13107200 (4k) blocks long.

  Size of logical volume VolGroupSys/LogVolU01 changed from 62.00 GiB (1984 extents) to 50.00 GiB (1600 extents).
  Logical volume VolGroupSys/LogVolU01 successfully resized.


systemctl stop initdcsagent
systemctl stop initdcscontroller
systemctl stop initdcsadmin
systemctl stop oda-mysql
systemctl stop oracle-ODA_DCS-ODA_DCS0
systemctl stop oracle-tfa
systemctl stop oracle-ohasd


lsof /opt
COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
bash       6697 root  cwd    DIR  252,2     4096 1703937 /opt/dbi
OSWatcher  7799 grid  cwd    DIR  252,2     4096 2235031 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/oswbb
OSWatcher  7799 grid    1w   REG  252,2     4703 2228894 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/run_1773762195.log (deleted)
OSWatcher  7799 grid    2w   REG  252,2     4703 2228894 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/run_1773762195.log (deleted)
OSWatcher  7799 grid  255r   REG  252,2    65286 2235047 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/oswbb/OSWatcher.sh
OSWatcher  9903 grid  cwd    DIR  252,2     4096 2235031 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/oswbb
OSWatcher  9903 grid    1w   REG  252,2     4703 2228894 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/run_1773762195.log (deleted)
OSWatcher  9903 grid    2w   REG  252,2     4703 2228894 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/run_1773762195.log (deleted)
OSWatcher  9903 grid  255r   REG  252,2     8035 2235046 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/oswbb/OSWatcherFM.sh
sleep     56757 grid  cwd    DIR  252,2     4096 2235031 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/oswbb
sleep     56757 grid    1w   REG  252,2     4703 2228894 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/run_1773762195.log (deleted)
sleep     56757 grid    2w   REG  252,2     4703 2228894 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/run_1773762195.log (deleted)
sleep     56835 grid  cwd    DIR  252,2     4096 2235031 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/oswbb
sleep     56835 grid    1w   REG  252,2     4703 2228894 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/run_1773762195.log (deleted)
sleep     56835 grid    2w   REG  252,2     4703 2228894 /opt/oracle/dcs/oracle.ahf/data/repository/suptools/dbioda01/oswbb/grid/run_1773762195.log (deleted)

kill -9 7799 9903


lvreduce -L 55G /dev/VolGroupSys/LogVolOpt -r
Do you want to unmount "/opt" ? [Y|n] y
fsck from util-linux 2.32.1
/dev/mapper/VolGroupSys-LogVolOpt: Inode 655911 extent tree (at level 1) could be narrower.  IGNORED.
/dev/mapper/VolGroupSys-LogVolOpt: 57911/4587520 files (2.4% non-contiguous), 12785629/18350080 blocks
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/mapper/VolGroupSys-LogVolOpt to 14417920 (4k) blocks.
The filesystem on /dev/mapper/VolGroupSys-LogVolOpt is now 14417920 (4k) blocks long.

  Size of logical volume VolGroupSys/LogVolOpt changed from 70.00 GiB (2240 extents) to 55.00 GiB (1760 extents).
  Logical volume VolGroupSys/LogVolOpt successfully resized.

As I don’t want to manually restart the various processes, and as I usually do a sanity reboot before patching, let’s reboot the server. Everything will then be properly started after.

reboot
...

df -h /u01 /opt
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/VolGroupSys-LogVolU01   49G   23G   25G  49% /u01
/dev/mapper/VolGroupSys-LogVolOpt   54G   48G  4.0G  93% /opt

Further recommendations

You don’t really need a lot of space on the system disks. Put your patch files and other specific files on a NFS volume shared across your ODAs, and keep the system disks to their default’s size to keep a confortable margin for ODABR, especially on ODA X9-2 series. Eventually, allow a few more GB to /u01 and/or /opt but keep at least 70GB free for ODABR snapshots. Anticipate the patching and test ODABR several days before, it does not cost anything, and snapshots can be removed immediately without any downtime. Worst case is having to patch now and discovering that there is no space left on disks for using ODABR.

Not being able to secure your patch with ODABR is the second NOGO for patching, the first one being a faulty component reported by odaadmcli show server.

Conclusion

If you don’t have enough free space for ODABR snapshots, postpone the patching. ODABR is a mandatory safety net. Reducing /u01 and /opt filesystems’s size is possible. It will require stopping everything, but as you will patch your ODA, you’ve already allocated a sufficient downtime.

L’article Not enough space for using ODABR? Reduce /u01 and /opt size on your ODA est apparu en premier sur dbi Blog.

To explain this further, let’s look at an extract setting using the retrieve_extract endpoint. I’m using the Python client I presented in another blog. Everything I’m talking about here is not specific to extracts, and can be extended to replicats. However, it doesn’t apply to distribution paths.

Extract with no profile assigned

If an extract was created in the most basic configuration, it inherits the Default profile implicitly, but this information is not registered in the extract definition. Below is the configuration of such an extract. To save you time, just remember that there is no mention of any profile setting.

>>> ogg_client.retrieve_extract('EXTSRC')
{'$schema': 'ogg:extract', 'credentials': {'alias': 'cdb01', 'domain': 'OracleGoldenGate'}, 'begin': 'now', 'encryptionProfile': 'LocalWallet', 'targets': [{'name': 'aa', 'path': 'PDB1', 'sizeMB': 2000, 'sequenceLength': 9, 'sequenceLengthFlip': False, 'sequence': 1, 'offset': 1399, 'remote': False}], 'config': ['--- Auto generated Parameter File, do not edit ---', 'EXTRACT EXTSRC', 'USERIDALIAS cdb01 DOMAIN OracleGoldenGate', 'EXTTRAIL PDB1/aa', '--- End of auto generated Parameter File ---', 'SOURCECATALOG PDB1', 'TABLE APP_PDB1.*;'], 'source': 'tranlogs', 'type': 'Integrated', 'registration': {'share': False, 'containers': ['PDB1'], 'csn': 2809889}, 'status': 'running'}

Extract with a profile set

If a profile is assigned to the extract, the managedProcessSettings key is added to the extract configuration. This is true whether you assign a custom profile or re-assign the Default profile after having changed the extract configuration. Below, we can see the difference with the following key/value pair : 'managedProcessSettings': 'ogg:managedProcessSettings:dbiProfile'

{'$schema': 'ogg:extract', 'credentials': {'alias': 'cdb01', 'domain': 'OracleGoldenGate'}, 'begin': 'now', 'encryptionProfile': 'LocalWallet', 'managedProcessSettings': 'ogg:managedProcessSettings:dbiProfile', 'targets': [{'name': 'aa', 'path': 'PDB1', 'sizeMB': 2000, 'sequenceLength': 9, 'sequenceLengthFlip': False, 'sequence': 1, 'offset': 1399, 'remote': False}], 'config': ['--- Auto generated Parameter File, do not edit ---', 'EXTRACT EXTSRC', 'USERIDALIAS cdb01 DOMAIN OracleGoldenGate', 'EXTTRAIL PDB1/aa', '--- End of auto generated Parameter File ---', 'SOURCECATALOG PDB1', 'TABLE APP_PDB1.*;'], 'source': 'tranlogs', 'type': 'Integrated', 'registration': {'share': False, 'containers': ['PDB1'], 'csn': 2809889}, 'status': 'running'}

Extract with a custom configuration

If an extract has a custom unique configuration that is not a profile, the full configuration is added as a JSON to the extract definition under the same managedProcessSettings key. I give below an example:

{'$schema': 'ogg:extract', 'credentials': {'alias': 'cdb01', 'domain': 'OracleGoldenGate'}, 'begin': 'now', 'encryptionProfile': 'LocalWallet', 'managedProcessSettings': {'autoStart': {'enabled': True, 'delay': 60}, 'autoRestart': {'enabled': False, 'onSuccess': False, 'delay': 0, 'retries': 9, 'window': 0, 'disableOnFailure': True, 'failures': 0}}, 'targets': [{'name': 'aa', 'path': 'PDB1', 'sizeMB': 2000, 'sequenceLength': 9, 'sequenceLengthFlip': False, 'sequence': 1, 'offset': 1399, 'remote': False}], 'config': ['--- Auto generated Parameter File, do not edit ---', 'EXTRACT EXTSRC', 'USERIDALIAS cdb01 DOMAIN OracleGoldenGate', 'EXTTRAIL PDB1/aa', '--- End of auto generated Parameter File ---', 'SOURCECATALOG PDB1', 'TABLE APP_PDB1.*;'], 'source': 'tranlogs', 'type': 'Integrated', 'registration': {'share': False, 'containers': ['PDB1'], 'csn': 2809889}, 'status': 'running'}

How to modify a single extract’s profile with the REST API ?

Modifying the profile of an extract or replicat with the REST API means updating the managedProcessSettings key of the process. For an extract, you would use the update_extract endpoint, with a data payload that only contains the managedProcessSettings key, and its value. It can be the profile name or the full profile definition, as shown above. Here is an example of a single update of an extract:

>>> ogg_client.update_extract(
extract='EXTSRC',
    data={
        'managedProcessSettings': 'ogg:managedProcessSettings:dbiProfile'
    }
)

And do not worry about entering a wrong name for the profile. If you do this, the API returns the following error:

>>> ogg_client.update_extract(
    extract='EXTSRC',
    data={
        'managedProcessSettings': 'ogg:managedProcessSettings:NonExistingProfile'
    }
)
Exception: ERROR - https://vmogg/services/ogg_test_01/adminsrvr/v2/extracts/EXTSRC: The managed process settings profile 'ogg:managedProcessSettings:NonExistingProfile' does not exist. ; INFO - https://vmogg/services/ogg_test_01/adminsrvr/v2/extracts/EXTSRC: The item type  with name 'ogg:managedProcessSettings:NonExistingProfile' does not exist.

How to modify all extracts and replicats ?

Based on the above, modifying all extracts and replicats is easy. You should just iterate over your extracts and replicats and apply the profile that you want. Below is an example script where you can modify the profile_name variable and the connection details to the Administration Service of your deployment. You could even decide to have different profiles assigned to extracts and replicats, if needed.

from oggrestapi import OGGRestAPI

profile_name = 'dbiProfile'

ogg_client = OGGRestAPI(
    url='https://vmogg',
    user='ogg',
    password='ogg',
    reverse_proxy=True,
    deployment='ogg_test_01'
)

for extract in ogg_client.list_extracts():
    extract_name = extract['name']
    print(f"Updating extract {extract_name}")
    ogg_client.update_extract(
        extract=extract_name,
        data={
            'managedProcessSettings': f'ogg:managedProcessSettings:{profile_name}'
        }
    )

for replicat in ogg_client.list_replicats():
    replicat_name = replicat['name']
    print(f"Updating replicat {replicat_name}")
    ogg_client.update_replicat(
        replicat=replicat_name,
        data={
            'managedProcessSettings': f'ogg:managedProcessSettings:{profile_name}'
        }
    )

After running this against the Administration Service, all your extracts and replicats will now follow the same new profile.

L’article Bulk Update of GoldenGate Extract Profiles est apparu en premier sur dbi Blog.

Data Preserving Reprovisioning will allow you reprovisioning an already deployed Oracle Database Appliance system keeping the storage and the databases on the appliance, so without any modifications on the information stored in the ASM (storage). The information of the source system will be saved in a server data archive files. The appliance will then be reimaged with Oracle Database Appliance release iso image and the saved metadata will be used to directly reprovision the system and bring back all the resources such as databases, DB systems, Oracle ASR, and others.

The reimage can only be done using the java remote console, available with the ILOM. Remember that to attach the iso on the java console and use it during the reimage, you need to add it and connect it as described in the next picture.

It is important to see the following red message to ensure that the connection with the iso is made and that it can be used.

The problem is that after a time, during the reimage process, the java remote console lost full control on the node, having as consequence a lost of the iso connection and a failure in the reimage process.

This could be seen in the console with the message (View Only) displayed in the bar and the Red Cross on the top of the Computer (screen)/mouse image.

Here:

When it should be:

Here the whole picture showing the connection problem.

And we can see the message : “Sorry, keyboard and mouse connection has been lost. \nIf storage was being shared it has been lost also”.

When a correct connection would be the following one, having (Full Control) message displayed in the bar, with no lost of keyboard/mouse and storage (iso) connection.

After several tries it was always the same problem. After a few minutes, lost of the connection…

I then decided to check the ILOM sessions, connecting to the ILOM through ssh connection.

login as: root
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server

Oracle(R) Integrated Lights Out Manager

Version 5.1.1.23 r151958

Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Warning: HTTPS certificate is set to factory default.

Hostname: ODA01-ilo

-> show /SP/sessions

 /SP/sessions
    Targets:
        55342
        55346 (current)

    Properties:

    Commands:
        cd
        delete
        show

I found surprising to see so high sessions id. I decided to reset the ILOM. This would of course not restart the node.

-> reset /SP
Are you sure you want to reset /SP (y/n)? y
Performing reset on /SP

And connected again to the ILOM through ssh to checked the sessions:

login as: root
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server

Oracle(R) Integrated Lights Out Manager

Version 5.1.1.23 r151958

Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Warning: HTTPS certificate is set to factory default.

Hostname: ODA01-ilo

-> show /SP/sessions

 /SP/sessions
    Targets:
        1 (current)

    Properties:

    Commands:
        cd
        delete
        show

The sessions id were back to one, and I did not have any lost connection issue any more. I could successfully reimage the ODA to 19.24 version.

L’article Loosing java remote console full control during ODA Reimage est apparu en premier sur dbi Blog.

REST API Log Files

The restapi.log files are one of the most important logs because of the amount of information they provide. They allow you to completely understand what is happening behind the scenes. It takes time to learn how to analyze them, but I wrote a dedicated article on REST API log analysis to help you through this. There is one restapi.log file per deployment, because the REST API calls are always made to a specific deployment. This is also true when using a reverse proxy.

These restapi.log files are also a source of information for other GoldenGate log files. For instance, REST API logs on the AI Service will be cleaned and filtered before ending up in the log dedicated to the AI Service. This is another reason why you should understand the content of these restapi.log files.

Here is a log example from a restapi.log file. Again, for more details, read the blog linked above.

2026-04-09 19:46:36.789+0000 ERROR|RestAPI.adminsrvr | Request #1581: {
    "context": {
        "httpContextKey": 140353514441552,
        "verbId": 7,
        "verb": "PATCH",
        "originalVerb": "PATCH",
        "uri": "/services/v2/extracts/EXTSRC",
        "protocol": "http",
        "headers": {
            "X-OGG-Context": "services/ogg_test_01/adminsrvr",
            "X-OGG-Deployment": "ogg_test_01",
            "X-OGG-Service": "adminsrvr",
            "X-OGG-Version": "v2",
            "X-OGG-Resource": "extracts/EXTSRC",
            "X-Real-IP": "**",
            "X-Forwarded-For": "**",
            "X-Forwarded-Host": "vmogg",
            "X-Forwarded-Proto": "https",
            "X-Forwarded-Server": "oggvm1",
            "X-SSL-Client-Verify": "NONE",
            "Connection": "keep-alive",
            "Host": "vmogg",
            "Content-Length": "75",
            "User-Agent": "python-requests/2.32.3",
            "Accept-Encoding": "gzip, deflate",
            "Accept": "application/json",
            "Content-Type": "application/json",
            "Cookie": "** Masked **",
            "Authorization": "** Masked **",
            "X-OGG-Requestor-Id": "",
            "X-OGG-Feature-List": ""
        },
        "host": "vmogg",
        "securityEnabled": false,
        "authorization": {
            "authUserName": "ogg",
            "authPassword": "** Masked **",
            "authMode": "Basic",
            "authUserRole": "Security"
        },
        "requestId": 4,
        "uriTemplate": "/services/{version}/extracts/{extract}"
    },
    "content": {
        "managedProcessSettings": "ogg:managedProcessSettings:NonExistingProfile"
    },
    "isScaRequest": true,
    "parameters": {
        "uri": {
            "extract": "EXTSRC",
            "version": "v2"
        }
    }
}
Response: {
    "context": {
        "httpContextKey": 140353514441552,
        "requestId": 4,
        "code": "404 Not Found",
        "headers": {
            "Content-Type": "application/json",
            "Set-Cookie": "** Masked **"
        },
        "Content-Type": "application/json",
        "contentType": "application/json"
    },
    "isScaResponse": true,
    "content": {
        "$schema": "api:standardResponse",
        "links": [
            {
                "rel": "canonical",
                "href": "https://vmogg/services/ogg_test_01/adminsrvr/v2/extracts/EXTSRC",
                "mediaType": "application/json"
            },
            {
                "rel": "self",
                "href": "https://vmogg/services/ogg_test_01/adminsrvr/v2/extracts/EXTSRC",
                "mediaType": "application/json"
            }
        ],
        "messages": [
            {
                "$schema": "ogg:message",
                "title": "The managed process settings profile 'ogg:managedProcessSettings:NonExistingProfile' does not exist.",
                "code": "OGG-08122",
                "severity": "ERROR",
                "issued": "2026-04-09T19:46:36Z",
                "type": "https://docs.oracle.com/en/middleware/goldengate/core/23.26/error-messages/"
            },
            {
                "$schema": "ogg:message",
                "title": "The item type  with name 'ogg:managedProcessSettings:NonExistingProfile' does not exist.",
                "code": "OGG-12029",
                "severity": "INFO",
                "issued": "2026-04-09T19:46:36Z",
                "type": "https://docs.oracle.com/en/middleware/goldengate/core/23.26/error-messages/"
            }
        ]
    }
}

Admin Client Log File

Depending on your configuration, the adminclient log file might not always be in the same location. More specifically, you can have multiple adminclient.log files for a single GoldenGate installation. The reason behind this is that the logs go to the location of your OGG_VAR_HOME environment variable. The adminclient.log can be located in :

• In your Service Manager var/log directory, if your GoldenGate user has the Service Manager OGG_VAR_HOME set in the environment.
• In your deployment var/log directory, if you change the OGG_VAR_HOME environment variable when switching between deployments at the OS level. This is not recommended, as it can lead to multiple adminclient.log files and mixed-up logs between deployments.
• In your GoldenGate binaries, if you misconfigured your environment and are calling the adminclient with an empty OGG_VAR_HOME variable. This is not ideal, as you could lose the log file after patching or upgrading.

There is not much to see in this file with the default logging configuration, but it can be used to troubleshoot connection issues with the adminclient.

Service Manager Log Files

Let’s look at the var/log folder of the Service Manager deployment.

oggsm/var/log:
ServiceManager.log
restapi.log
AIService.log

In GoldenGate 26ai, there are three different logs for the Service Manager:

• ServiceManager.log : In a healthy installation, this log file should only contain logs generated when services start or stop. But if your Administration Server doesn’t start, this log is a good starting point for troubleshooting.

2026-04-09T19:20:28.124+0000 INFO | Task 'ogg_test_01:adminsrvr' started with process id 2505 (ogg_test_01:adminsrvr)
2026-04-09T19:20:28.159+0000 INFO | Task 'ServiceManager:AIService' started with process id 2515 (ServiceManager:AIService)
2026-04-09T19:20:28.182+0000 INFO | Task 'ogg_test_01:distsrvr' started with process id 2522 (ogg_test_01:distsrvr)
2026-04-09T19:20:28.215+0000 INFO | Task 'ogg_test_01:recvsrvr' started with process id 2542 (ogg_test_01:recvsrvr)
2026-04-09T19:20:28.234+0000 INFO | Task 'ogg_test_01:pmsrvr' started with process id 2553 (ogg_test_01:pmsrvr)
2026-04-09T19:20:29.243+0000 INFO | Installation topology updated (ServiceManager.Topology)

• restapi.log : See the chapter above about REST API Log Files.

• AIService.log : This is where logs from the AI Service are gathered. It mostly consists of a cleaned collection of the REST API logs from calls made against the AI Service. For instance, here is a log you can get when adding an AI Provider to the Service Manager.

2026-04-09 19:32:21.056 DATA |AIService      |AIService.RestApi             |  247 RequestHandlers.cpp      | 00000000-0000-0000-D5F8-000000000006> {"$schema":"api:standardResponse","links":[],"response":{"providers":[{"id":"1","name":"GeminiAiStudio","type":"gemini","baseUrl":"https://generativelanguage.googleapis.com/v1beta/models/gemini-flash-latest:generateContent","authentication":{"type":"api_key","configured":true},"links":[{"rel":"parent","href":"/api/v1/providers","mediaType":"application/json"},{"rel":"canonical","href":"/api/v1/providers/1","mediaType":"application/json"}]}],"metadata":{"fromCache":false,"providerCount":1,"lastUpdatedEpochMicroseconds":1775827941054749}},"messages":[]} (Thread 2)

Deployment Log Files

GoldenGate deployments have more log file types than the Service Manager. In the var/log folder of your deployments, you should have the following files:

ogg_test_01/var/log:
adminsrvr.log
distsrvr.log
ER-events.log
extract.log
ggserr.log
pmsrvr.log
recvsrvr.log
replicat.log
restapi.log

• adminsrvr.log, distsrvr.log, recvsrvr.log and pmsrvr.log : These files contain all the information, warning and error messages from actions or events in the main GoldenGate services (Administration, Distribution, Receiver and Performance Metrics Services). They are not as extensive as what you can find in the restapi.log file, but they provide a really good overview of what is happening inside your deployment.
• ER-events.log : This is a log file that can be used for monitoring your GoldenGate deployments. All warning and error messages on your extracts and replicats are available here. It is sometimes verbose, but still very useful for monitoring.

2026-04-10T07:11:17.844+0000  ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, EXTA.prm:  PROCESS ABENDING.
2026-04-10T07:12:24.447+0000  WARNING OGG-06658  Oracle GoldenGate Capture for Oracle, EXTB.prm:  Unable to restore a failed connection to the database after 3 retries.

• extract.log and replicat.log : In these log files, you can find status information, statistics, and transactions processed by your extracts and replicats. This does not provide fundamentally new information compared to other sources (adminclient, for instance), but it is a useful view when observing all processes at the same time.

2026-04-08T09:13:10.249+0000 INFO | INFO    OGG-01026  Oracle GoldenGate Capture for Oracle, EXTA.prm:  Rolling over remote file PDB1/aa000000321. (main)
2026-04-08T09:14:10.540+0000 INFO | INFO    OGG-01026  Oracle GoldenGate Capture for Oracle, EXTB.prm:  Rolling over remote file PDB1/ab000000645. (main)
2026-04-08T09:14:32.963+0000 INFO | INFO    OGG-01026  Oracle GoldenGate Capture for Oracle, EXTC.prm:  Rolling over remote file PDB1/ac000000128. (main)

• ggserr.log : This log serves the same purpose as it did in the old Classic Architecture, containing all information about your deployment. Contrary to what its name suggests, it does not only contain the errors happening in your deployment.

• restapi.log : See the chapter above about REST API Log Files.

GoldenGate Logs in the Web UI

In the GoldenGate web UI, you can access, filter, or query some of the logs listed above. From the Service Manager, the Diagnosis Log tab displays the ServiceManager.log file with filtering options.

You can also quickly enable debug logs for the Service Manager, which is usually only needed when the Oracle Support requests it. This will generate a ServiceManager-debug.log file in your var/log directory, and it can be downloaded from the web UI and sent to the Oracle Support or your dbi GoldenGate expert for analysis.

When connected to a deployment in the web UI, you can also view different logs.

• From the home page, the Critical Events view displays the content of the ER-events.log file.

• From the Services page, you have access to the Diagnosis Log of each service. They will respectively display the adminsrvr.log, distsrvr.log, recvsrvr.log and pmsrvr.log files. Similar to what I just explained, you can also enable debug logs temporarily if needed.

L’article GoldenGate 26ai Logs Explained est apparu en premier sur dbi Blog.