Here are the prerequisites before attempting the distribution path creation:

• Having two servers, each running a GoldenGate Microservices Architecture. I will use the latest version here, 26ai.
• Having a running extract on the source setup.
• Port openings: port 443 should be open between the two deployments.

In my environment, I have the following:

• Source environment: oggvm1, with a deployment named ogg_test_01, a CDB01 with a PDB1 containing a APP_PDB1 schema and a table1 table.
• Target environment: oggvm2, with the equivalent deployment ogg_test_02, CDB02, PDB2, APP_PDB2 schema, and a table2 table.

With all of this in mind, here are the three steps needed to create a working distribution path between two GoldenGate deployments secured with NGINX:

• Create a Path Connection
• Add the certificates used in NGINX to secure the target deployment to the source’s certificate management store.
• Create and start the distribution path.

Path Connection Creation

To open a connection to the target deployment ogg_test_02, the source deployment needs a path connection. As explained in a previous blog, path connections are aliases of an existing user on a target deployment.

It is recommended to separate roles and not use the administrator account of your target deployment, so let’s first create the user.

• On ogg_test_02 (target deployment), go to the User Administration tab and add a new user. For the role, Oracle recommends using the Operator role, so there is no reason to use the higher-privileged Administrator or Security roles.

• On ogg_test_01 (source deployment), create the path connection. Only the Userid and Password fields must match what you just created on the target. The alias is just known on the source side and doesn’t have to match the username set on the target deployment. The alias defined here in the source deployment will only appear when choosing a connection during the distribution path creation.

Certificate Management

Because your deployments are secured with NGINX, you have to make sure that the certificates being used by one deployment are recognized by the other deployment. To do so, on the source only, you have to register the root certificate authority of the target deployment.

This can only be done at the Service Manager level. In the Service Manager web UI, go to Certificate Management and add a CA Certificate in the source deployment ogg_test_01. You have two options here.

• If the CA only needs to be registered on this specific deployment, you can register it with the Local option. This is the more secure option, but it is very often not needed.
• If the CA registration should be shared with other deployments, you can register it with the Shared option.

Paste the root certificate file used to secure your second deployment. The name used must be unique but will not be used anywhere else in the process.

How should I register a certificate chain ?

If the certificate file contains multiple certificates, GoldenGate doesn’t allow you to register them in one go. Instead, you need to break down the file and register each part individually. Again, the name and order in which you register the certificates do not matter, except for management purposes. I described the issue in more detail in a blog about the OGG-30007 error.

Distribution Path Creation

We can now finally create the distribution path. On the source deployment, go on the Distribution Service Paths tab and register the path as such:

• Path information: Specify the path name. If possible, make the target (and the source) visible in the name, to ease management when having multiple distribution paths.

• Source options: Here, you should only select the extract at the source of this distribution path. The rest will be filled automatically or can stay with the default value.

• Target options: This is where the configuration is specific. Because we are using a NGINX-secured deployment on the target, you must click on Reverse proxy enabled and choose the wss target protocol.

• Advanced, Filtering and Managed Options: Nothing here is specific to our setup, but you can of course customize these options as needed.

And that’s it. Your deployments are now connected, and you should see the trail files on the target once you start the distribution path.

oracle@oggvm2:~/ ll $OGG_DEPLOYMENT_HOME/var/lib/data/PDB1
total 0
-rw-r-----. 1 oracle oinstall 0 Mar 22 07:34 bb000000000

The remote peer submitted a certificate that failed validation

If your distribution path doesn’t start and generates a “certificate that failed validation” error, it means that you incorrectly registered your certificates. Make sure that the target deployment’s certificates are registered on the source deployment’s service manager and not the other way around.

You can also try to use the certificate in an OGG_CLIENT_TLS_CAPATH environment variable on the source and connect with the adminclient to check if it’s working.

L’article Create Distribution Paths in NGINX-Secured GoldenGate 26ai est apparu en premier sur dbi Blog.

Processing of the certificate PEM portion of the certificate bundle resulted in more than one (1) certificate objects.

Code: OGG-30007

Cause: The read and decode processing of the specified portion of the certificate bundle produced more than one (1) objects. More than one PEM encoded object is present in the data.

Action: Review the specified portion of the certificate bundle and correct as needed. Only a single PEM encoded object is expected.

This error occurs because GoldenGate expects exactly one PEM object per import, while a certificate chain file contains multiple certificates. In the web UI, a pop-up will alert you that something is wrong:

As mentioned, this typically happens when registering a certificate chain. For instance, you could face the issue when connecting two deployments secured with NGINX. The server presents a certificate chain including the intermediate, while the client (GoldenGate) must trust both the root and the intermediate.

But when the Certificate Authority doesn’t sign your certificate directly with the Root Certificate, but with an Intermediate Certificate, the server presents a certificate chain including the intermediate. A certificate like the following will generate an OGG-30007 error if you try to add it to the truststore:

-----BEGIN CERTIFICATE-----
(intermediate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(root)
-----END CERTIFICATE-----

And to make sure that your connections work, you should not only add the root certificate, but also the intermediate certificate. Because of the way GoldenGate stores these certificates, two separate entries must be created in the truststore. To ease monitoring and certificate management, you can name them rootCA_ogg_target and intermediateCA_ogg_target

With this, you should have no problem connecting GoldenGate deployments ! To avoid OGG-30007, ensure that each certificate is imported separately. In practice, this means extracting the root and intermediate certificates from the chain file and registering them as individual entries in the GoldenGate truststore.

L’article OGG-30007 : How To Register Certificates In GoldenGate ? est apparu en premier sur dbi Blog.

• autoStart.enabled: whether the process will start automatically after the Administration Server starts.
• autoStart.delay: delay in seconds before starting the process.
• autoRestart.enabled: whether to restart the process after it fails.
• autoRestart.onSuccess: the process is only restarted if it fails.
• autoRestart.delay: waiting time (in seconds) before attempting to restart a process once it fails.
• autoRestart.retries: maximum number of retries before stopping restart attempts.
• autoRestart.window: timeframe before GoldenGate will attempt to restart the process again.
• autoRestart.disableOnFailure: if set to True, GoldenGate will disable the restart if it fails to restart within the retries/window setting. You will have to start the process manually if this happens.

In the web UI, an extract profile can be customized during the third step of an extract creation called Managed Options. Here, you can choose to use the default profile, a user-defined profile or custom settings specific to the new process.

However, a bug was introduced in GoldenGate 26ai. If you create a custom profile with the adminclient, the web UI will sometimes hang when creating any new extract or replicat. This also affects 23ai installations that are patched to 26ai, so be very careful when patching an existing GoldenGate 23ai setup containing custom profiles ! After patching, you will not be able to access and manage your profiles anymore from the web UI.

What is the bug exactly ?

To reproduce the bug, simply create an extract from the adminclient.

OGG (https://vmogg ogg_test_01) 1> info profile *
                                   Auto     Delay     Auto                Wait     Reset     Disable
Name                              Start   Seconds  Restart   Retries   Seconds   Seconds  on Failure
--------------------------------  -----  --------  -------  --------  --------  --------  ----------
Default                              No                 No
OGG (https://vmogg ogg_test_01) 2> add profile TestProfile autostart no
OGG (https://vmogg ogg_test_01) 3> info profile *
                                   Auto     Delay     Auto                Wait     Reset     Disable
Name                              Start   Seconds  Restart   Retries   Seconds   Seconds  on Failure
--------------------------------  -----  --------  -------  --------  --------  --------  ----------
Default                              No                 No
TestProfile                          No                 No

In a GoldenGate 23ai web UI, you will see the following when creating an extract, in the Managed Options step:

However, in GoldenGate 26ai, the extract creation hangs indefinitely, and no error gets reported.

Before the bug is solved by Oracle, what can you do ? The first thing you can do is modify the Default GoldenGate profile, so that all extracts with this profile are affected. However, it means that you cannot fine-tune the settings for different processes, with different needs. After all, it is the reason why you should define profiles in the first place.

Is there a workaround ?

But if you still want to overcome this bug and having working profiles on 26ai until the bug gets corrected, you have two ways of doing this:

• Create profiles from the web UI. You can do this in the Managed Process Profiles tab of your deployment. Profiles created through this tab do not make the web UI hang indefinitely.
• Create profiles with the REST API. As presented in this blog, you can do this in two steps :
  • Creation of a new profile with the Create Configuration Value endpoint on the ogg:managedProcessSettings type.
  • Creation of a new configuration isDefault set to False on the ogg:configDataDescription type.

This way, you can create or recreate your profiles until the bug is solved.

L’article Overcome GoldenGate 26ai Bug On Custom Profiles est apparu en premier sur dbi Blog.

Certificates types in GoldenGate

The first thing you need to know is that there are three types of certificates in a GoldenGate deployment. Each of them can be monitored separately in the REST API.

• Server Certificates, which belong to the server type
• Client Certificates, which belong to the client type
• CA Certificates, which belong to the truststore type

Certificate monitoring from the web UI

Before presenting the REST API monitoring of certificates, let’s see what we are supposed to be looking at. From the web UI, when connected to the Service Manager, you can observe the details of your certificates in the Certificate Management tab. I give below an example for both the Service Manager and a deployment in a secure GoldenGate installation.

I create short-term certificates on purpose for the example, and we see that the UI is designed to tell the user when the certificates are close to expiration. But of course, it’s better to have some sort of monitoring do the job for us.

Certificate monitoring with the REST API

With GoldenGate REST API, it is rather easy to monitor certificate expiration. Unfortunately, you cannot ask the API for a list of certificates close to expiration, so you will have to iterate over all certificates in your monitoring script.

I will use the Python client I presented in another blog, but you can of course rebuild each call manually. Here are the methods / endpoints you should use:

• List Deployments – GET /services/{version}/deployments, to retrieve the list of deployments. The Service Manager is considered as a normal deployment here, so there is no need to separate it from the other deployments.
• Retrieve Available Certificate Types – GET /services/{version}/deployments/{deployment}/certificates, to retrieve the collection of certificate types. It should always be the list given earlier (client, server and truststore).
• Retrieve Certificate Types – GET /services/{version}/deployments/{deployment}/certificates/{type}, to get the list of certificates that belong to a specific type inside a deployment.
• Retrieve Certificate Information – GET /services/{version}/deployments/{deployment}/certificates/{type}/{certificate}/info, to retrieve the information on a specific certificate.

I share below a full monitoring script that you can use to monitor all certificates in a GoldenGate setup. Feel free to adapt it to your own monitoring tool.

#!/usr/bin/env python3
"""
Oracle GoldenGate Certificate Monitoring Script
"""

from datetime import datetime, timezone
import sys

from oggrestapi import OGGRestAPI

if __name__ == '__main__':
    exit_code = 0  # 0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN

    try:
        # Initialize the OGG REST API client
        ogg_client = OGGRestAPI(
            url='https://vmogg:7809',
            username='ogg',
            password='ogg',
            verify_ssl=False)

        # Retrieve the list of deployments
        deployments = ogg_client.list_deployments()
        print(f"Deployments: {[d['name'] for d in deployments]}")

        # For each deployment, retrieve the list of certificates and check their expiration dates
        for deployment in deployments:
            deployment_name = deployment['name']
            print(f"    Checking certificates for deployment: {deployment_name}")

            certificate_types = ogg_client.retrieve_available_certificate_types_deployment(
                deployment=deployment_name)
            print(f"    Certificate types for deployment {deployment_name}: {[ct['name'] for ct in certificate_types]}")
            for cert_type in certificate_types:
                cert_type_name = cert_type['name']
                print(f"        Checking certificates for type: {cert_type_name}")
                certificates = ogg_client.retrieve_certificate_types(
                    deployment=deployment_name,
                    type=cert_type_name)
                for cert in certificates:
                    cert_name = cert['name']
                    print(f"            Certificate: {cert_name}")
                    certificate_information = ogg_client.retrieve_certificate_information_deployment(
                        deployment=deployment_name,
                        type=cert_type_name,
                        certificate=cert_name)
                    expiration_date = certificate_information['certificate']['validTo']
                    print(f"                Certificate Expiry Date: {expiration_date}")
                    expire_in = datetime.strptime(expiration_date, "%Y-%m-%dT%H:%M:%SZ").replace(tzinfo=timezone.utc) - datetime.now(timezone.utc)
                    is_expired = expire_in.total_seconds() < 0

                    if is_expired:
                        print(f"                WARNING: Certificate '{cert_name}' in deployment '{deployment_name}' of type '{cert_type_name}' has expired on {expiration_date}")
                        exit_code = max(exit_code, 2)  # CRITICAL
                    else:
                        days_left = int(expire_in.total_seconds() / 86400)
                        print(f"                Certificate '{cert_name}' in deployment '{deployment_name}' of type '{cert_type_name}' will expire in {days_left} days on {expiration_date}")
                        if days_left < 30:
                            exit_code = max(exit_code, 1)  # WARNING

    except Exception as e:
        print(f"UNKNOWN: {e}")
        sys.exit(3)

    sys.exit(exit_code)

On an installation where certificates are close to expire, the output looks like this:

Deployments: ['ServiceManager', 'ogg_test_01']
    Checking certificates for deployment: ServiceManager
    Certificate types for deployment ServiceManager: ['client', 'server', 'truststore']
        Checking certificates for type: client
        Checking certificates for type: server
            Certificate: default
                Certificate Expiry Date: 2026-03-31T05:54:15Z
                Certificate 'default' in deployment 'ServiceManager' of type 'server' will expire in 0 days on 2026-03-31T05:54:15Z
        Checking certificates for type: truststore
    Checking certificates for deployment: ogg_test_01
    Certificate types for deployment ogg_test_01: ['client', 'server', 'truststore']
        Checking certificates for type: client
            Certificate: default
                Certificate Expiry Date: 2026-03-31T05:54:15Z
                Certificate 'default' in deployment 'ogg_test_01' of type 'client' will expire in 0 days on 2026-03-31T05:54:15Z
        Checking certificates for type: server
            Certificate: default
                Certificate Expiry Date: 2026-03-31T05:54:15Z
                Certificate 'default' in deployment 'ogg_test_01' of type 'server' will expire in 0 days on 2026-03-31T05:54:15Z
        Checking certificates for type: truststore
            Certificate: XCertUser-467fd0986deb
                Certificate Expiry Date: 2026-03-31T05:54:15Z
                Certificate 'XCertUser-467fd0986deb' in deployment 'ogg_test_01' of type 'truststore' will expire in 0 days on 2026-03-31T05:54:15Z
            Certificate: installed_0
                Certificate Expiry Date: 2026-03-31T05:54:15Z
                Certificate 'installed_0' in deployment 'ogg_test_01' of type 'truststore' will expire in 0 days on 2026-03-31T05:54:15Z

L’article Monitoring GoldenGate Certificates Expiration est apparu en premier sur dbi Blog.

Unfortunately, there is no easy way to modify an existing profile from the adminclient (there is no alter profile command). The Default profile makes no exception, so you will have to use the REST API for this. In this blog, I will present two ways of doing it:

• Updating the Default profile directly.
• Creating a custom profile, and setting it as Default.

Using the Python client for GoldenGate I presented in another blog post, you can easily create a session connecting to your GoldenGate setup and retrieve the existing configuration. For this, we will use the following methods / endpoints:

• retrieve_configuration_value to get the current configuration (GET /services/{version}/config/types/{type}/values/{value})
• replace_configuration_value to update the profile (PUT /services/{version}/config/types/{type}/values/{value})

from oggrestapi import OGGRestAPI

ogg_client=OGGRestAPI(
    url="https://vmogg:7810",
    username="ogg",
    password="ogg"
)

ogg_client.retrieve_configuration_value(
    value='ogg:managedProcessSettings:Default',
    type='ogg:managedProcessSettings')

This gives us the basic configuration of all new extracts and replicats in GoldenGate. Let’s see the default values:

>>> ogg_client.retrieve_configuration_value(
    value='ogg:managedProcessSettings:Default',
    type='ogg:managedProcessSettings')
{'$schema': 'ogg:managedProcessSettings', 'autoStart': {'enabled': False, 'delay': 0}, 'autoRestart': {'enabled': False, 'onSuccess': False, 'delay': 0, 'retries': 9, 'window': 60, 'disableOnFailure': True}}

Let’s have a look at the different parameters here:

• autoStart.enabled: whether the process will start automatically after the Administration Server starts.
• autoStart.delay: delay in seconds before starting the process.
• autoRestart.enabled: whether to restart the process after it fails.
• autoRestart.onSuccess: the process is only restarted if it fails.
• autoRestart.delay: waiting time (in seconds) before attempting to restart a process once it fails.
• autoRestart.retries: maximum number of retries before stopping restart attempts.
• autoRestart.window: timeframe before GoldenGate will attempt to restart the process again.
• autoRestart.disableOnFailure: if set to True, GoldenGate will disable the restart if it fails to restart within the retries/window setting. You will have to start the process manually if this happens.

Updating the Default profile directly

To update the Default profile, just create your own configuration and use the following example (based on the description given above) to push it to your GoldenGate deployment. Here, for instance, autoStart will be delayed by 30 seconds, and the process will try to restart every 5 minutes, and stop trying to restart after six retries. It will attempt to start again after two hours.

ogg_client.replace_configuration_value(
    value='ogg:managedProcessSettings:Default',
    type='ogg:managedProcessSettings',
    data={
        '$schema': 'ogg:managedProcessSettings',
        'autoStart': {
            'enabled': True,
            'delay': 30
        },
        'autoRestart': {
            'enabled': True,
            'retries': 6,
            'delay': 300,
            'window': 7200,
            'onSuccess': False,
            'disableOnFailure': False
        }
    }
)

We can check by retrieving the configuration again.

# Checking new configuration with the REST API
ogg_client.retrieve_configuration_value(
    value='ogg:managedProcessSettings:Default',
    type='ogg:managedProcessSettings')
{'$schema': 'ogg:managedProcessSettings', 'autoStart': {'enabled': True, 'delay': 30}, 'autoRestart': {'enabled': True, 'retries': 6, 'delay': 300, 'window': 7200, 'onSuccess': False, 'disableOnFailure': False}}

Or you can check in the web UI in the Managed Process Profiles tab.

Setting a custom profile to Default

If for some reason you would rather keep the Default profile and have a custom profile as default, you have to create a new profile first and set it as default. To do this, we use the create_configuration_value method / endpoint, which is the same endpoint as before but with the POST verb. If we keep the same profile as in the previous example, here is the script to run. Only the method changes, as well as the value, where Default is changed with the name of your profile (NewDefaultProfile, here).

ogg_client.create_configuration_value(
    value='ogg:managedProcessSettings:NewDefaultProfile',
    type='ogg:managedProcessSettings',
    data={
        '$schema': 'ogg:managedProcessSettings',
        'autoStart': {
            'enabled': True,
            'delay': 30
        },
        'autoRestart': {
            'enabled': True,
            'retries': 6,
            'delay': 300,
            'window': 7200,
            'onSuccess': False,
            'disableOnFailure': False
        }
    }
)

After this, you need to do two things:

• Create the isDefault flag for your new profile, and set it to True. This is done with the same create_configuration_value method, but on a different type called ogg:configDataDescription.
• Update the isDefault flag for the Default profile to False. Since the property already exists, we will use the replace_configuration_value method.

Here is how to do the creation of the flag:

ogg_client.create_configuration_value(
    value='ogg:managedProcessSettings:NewDefaultProfile',
    type='ogg:configDataDescription',
    data={
        'isDefault': True
    }
)

And to update the Default profile:

ogg_client.replace_configuration_value(
    value='ogg:managedProcessSettings:Default',
    type='ogg:configDataDescription',
    data={
        'isDefault': False
    }
)

From now on, any new extract or replicat will be assigned to this NewDefaultProfile !

L’article Change GoldenGate Default Extract Profile est apparu en premier sur dbi Blog.

I will not dwell on the differences between them, but you just have to know something important here: you cannot change the role assigned to a GoldenGate user. If you try to edit a user, the only thing that you can change is the password.

That being said, the only possible option to change the role of a user in GoldenGate is to recreate it. In the web UI, it is rather simple. You just delete it, and recreate it with the same credentials, but a different role.

But as mentioned, I wanted to do it for multiple deployments and users, without having to do the operation manually.every time. That is why I decided to use the GoldenGate REST API to quickly iterate over users and deployments. And this is where the trouble began.

According to the GoldenGate documentation on the REST API, there are two endpoints that appear to replicate the web UI behavior :

• Delete User : DELETE /services/{version}/authorizations/{role}/{user}

• Create User : POST /services/{version}/authorizations/{role}/{user}

However, when calling the API with these endpoints and the Python client I presented in another blog, I had the following error after trying to recreate the user:

# Deletion works as intended
>>> ogg_client.delete_user('dbiblog','Operator')
{'$schema': 'api:standardResponse', 'links': [{'rel': 'canonical', 'href': 'https://vmogg/se/Operator', 'mediaType': 'application/json'}, {'rel': 'self', 'href': 'https://vmogg/se/Operator', 'mediaType': 'application/json'}], 'messages': []}

# Creation doesn't work
>>> ogg_client.create_user('dbiblog', 'User', data={'credential':'**'})
Exception: ERROR - https://vmogg/services/ogg_test_01/adminsrvr/v2/authorizations/Operator/dbiblog: The specified user already exists.

In the UI, the user was gone, but I couldn’t recreate it with the REST API. And even from the UI, the user couldn’t be recreated. Instead, I had the following error: OGG-12430 : The specified user already exists.

At first, I thought something was wrong with either my deployment or my client, but I found nothing wrong. So I checked the restapi.log files of my deployment to understand:

• What the REST API calls were doing
• What the web UI was doing.

restapi.log analysis

Let’s try to create the exact same user (dbiblog / Operator) from the UI, and see what passes through the API. For more insight about how to query the restapi.log file efficiently, you can read a blog I wrote on the topic. Otherwise, you can just search through the logs.

As shown below, the creation of a user from the UI only generated one call to the API (excluding GET calls) to the same endpoint used by my method.

{
  "content": {
    "credential": "** Masked **",
    "type": "Basic"
  },
  "uri": "/services/v2/authorizations/Operator/dbiblog",
  "uriTemplate": "/services/{version}/authorizations/{role}/{user}",
  "verb": "POST",
  "restapi_datetime": "2026-03-27 05:40:58.776+0000",
  "restapi_reqno": 1840,
  "restapi_service": "adminsrvr",
  "restapi_status": "INFO"
}

Now, when deleting the user from the UI, two DELETE operations go through the API.

{
  "content": null,
  "uri": "/services/v2/authorizations/Operator/dbiblog",
  "uriTemplate": "/services/{version}/authorizations/{role}/{user}",
  "verb": "DELETE",
  "restapi_datetime": "2026-03-27 05:42:20.994+0000",
  "restapi_reqno": 1926,
  "restapi_service": "adminsrvr",
  "restapi_status": "INFO"
}
{
  "content": null,
  "uri": "/services/v2/authorizations/all/dbiblog",
  "uriTemplate": "/services/{version}/authorizations/{role}/{user}",
  "verb": "DELETE",
  "restapi_datetime": "2026-03-27 05:42:21.012+0000",
  "restapi_reqno": 1927,
  "restapi_service": "adminsrvr",
  "restapi_status": "INFO"
}

On top of making a DELETE call to the dbiblog / Operator pair, the UI generates another DELETE call on the dbiblog user with an undocumented all role !

This explains why you get an error when recreating a user with the REST API. If the user was deleted by a single REST API call, it still exists with the hidden all role.

To verify this hypothesis, let’s look at the list of users with the Operator and all roles before and after the user creation. Before, we only have the default ogg user (with the Security role, not shown here).

>>> ogg_client.list_users('Operator')
[]

>>> ogg_client.list_users('all')
[{'username': 'ogg'}]

But after, the newly created user also gets the all role.

>>> ogg_client.create_user(user='dbiblog', role='Operator', data={'credential':'**'})
{'$schema': 'api:standardResponse', 'links': [{'rel': 'canonical', 'href': 'https://vmogg/ser/Operator/dbiblog', 'mediaType': 'application/json'}, {'rel': 'self', 'href': 'https://vmogg/ser/Operator/dbiblog', 'mediaType': 'application/json'}], 'messages': []}

>>> ogg_client.list_users('Operator')
[{'username': 'dbiblog'}]

>>> ogg_client.list_users('all')
[{'username': 'ogg'}, {'username': 'dbiblog'}]

And of course, when deleting the user, I was only deleting it with the role I knew about.

How to recreate a GoldenGate user with the REST API ?

The conclusion is simple: to recreate a GoldenGate user with the REST API, you need to delete the user on its current role, but also on the all role. After doing this, you can recreate the user:

# User deletion on the 'Operator' role
>>> ogg_client.delete_user(user='dbiblog', role='Operator')
{'$schema': 'api:standardResponse', 'links': [{'rel': 'canonical', 'href': 'https://vmogg/Operator', 'mediaType': 'application/json'}, {'rel': 'self', 'href': 'https://vmogg/ser/Operator', 'mediaType': 'application/json'}], 'messages': []}

# User deletion on the 'all' role
>>> ogg_client.delete_user(user='dbiblog', role='all')
{'$schema': 'api:standardResponse', 'links': [{'rel': 'canonical', 'href': 'https://vmogg/ser/All', 'mediaType': 'application/json'}, {'rel': 'self', 'href': 'https://vmogg/ser/All', 'mediaType': 'application/json'}], 'messages': []}

# User creation on the 'Operator' role
>>> ogg_client.create_user(user='dbiblog', role='Operator', data={'credential':'**'})
{'$schema': 'api:standardResponse', 'links': [{'rel': 'canonical', 'href': 'https://vmogg/ser/Operator/dbiblog', 'mediaType': 'application/json'}, {'rel': 'self', 'href': 'https://vmogg/ser/Operator/dbiblog', 'mediaType': 'application/json'}], 'messages': []}

L’article The Undocumented GoldenGate ‘all’ Role You Should Know About est apparu en premier sur dbi Blog.

Differences in GoldenGate setup between Oracle and DB2

If you’re wondering how to set up GoldenGate 26ai for DB2 z/OS, it is very similar to what you would do with GoldenGate for Oracle. For more information on standard GoldenGate setups, you can read my blog posts about both 26ai and 23ai installations.

For the binary installation, the main difference is that INSTALL_OPTION should be set to DB2ZOS. A complete oggcore.rsp response file would look like this:

oracle.install.responseFileVersion=/oracle/install/rspfmt_ogginstall_response_schema_v23_1_0
INSTALL_OPTION=DB2ZOS
SOFTWARE_LOCATION=/u01/app/oracle/product/oggzos
INVENTORY_LOCATION=/u01/app/oraInventory
UNIX_GROUP_NAME=oinstall

When running the configuration assistant, some options are not available, but the main difference is in the environment variables section of the response file. You should have an IBMCLIDRIVER variable set to your DB2 driver’s path.

ENV_LD_LIBRARY_PATH=${IBMCLIDRIVER}/1ib:${OGG_HOME}/1ib
IBMCLIDRIVER=/path/to/ibmclidriver
ENV_USER_VARS=

Possible Solution for INS-85037

That being said, here is the exact error I had when running the Configuration Assistant oggca.sh:

[FATAL] [INS-85037] Deployment creation failed.
  ACTION: Check logs at /u01/app/oraInventory/logs/OGGCAConfigActions2026-03-22_15-19-15PM for more information.
*MORE DETAILS*
Return code 503 (Service Unavailable) does not match the expected code 201 (Created).
Verification failed for REST call to 'http://127.0.0.1:7810/services/v2/authorizations/security/ogguser'
Results for "Add a new deployment":
..."Verifying Service Manager deployment status.": SUCCEEDED
..."Adding 'zos_test' deployment.": SUCCEEDED
...."Configuring and starting the Administration Service.": SUCCEEDED
..."Verifying the initial Administration Service configuration.": SUCCEEDED
..."Adding user 'ogguser' to administer the deployment.": FAILED
Log of this session available at: /u01/app/oraInventory/logs/OGGCAConfigActions2026-03-22_15-19-15PM
The deployment creation failed and the associated files will be deleted from disk. Oracle recommends that if you want to keep the log files, you should move them to another location.
Log files will be copied to:
/u01/app/oraInventory/logs/OGGCAConfigActions2026-03-22_15-19-15PM/userdeploy_logs_2026-03-22_15-19-15PM
[WARNING] [INS-32090] Software installation was unsuccessful.
ACTION: Refer to the log files for details or contact Oracle Support Services.

Unfortunately, the installation logs did not show anything other than the following:

SEVERE: Deployment creation job failed.
INFO: Service Manager deployment that was created as part of the process needs to be removed.
INFO: Running clean-up job for Service Manager.
SEVERE: Removing Service Manager deployment.

The deployment and the service manager get deleted after the installation failure, but the logs are also copied to the oraInventory installation logs. Looking at the ServiceManager.log in the smdeploy folder, we don’t get much information.

ERROR| Configuration does not contain a 'config/network' specification. (ServiceManager.Topology)

The same applies to the restapi.log, where the logs start after the initial deployment creation error. Unfortunately, none of this was really helpful in my case. After quite some digging, I found that the response file I was using when running oggca.sh had an error. In the custom section for environment variables, I had the following settings:

# SECTION G - ENVIRONMENT VARIABLES
ENY_LD_LIBRARY_PATH-S{IBMCLIDRIVER}/1ib:${OGG_HOME}/11b
IBMCLIDRIVER=/u01/app/ibm/db2_odbc_cli_11_5
ENV_USER_VARS=

It looks like what I gave earlier, except that the path for the clidriver was incomplete.

oracle@vmogg:/home/oracle/ [ogg] ls -l /u01/app/ibm/db2_odbc_cli_11_5
drwxr-xr-x 3 oracle oinstall 23 Mar 22 2026 odbc_cli

oracle@vmogg:/home/oracle/ [ogg] ls -l /u01/app/ibm/db2_odbc_cli_11_5/odbc_cli/clidriver/
-r-xr-xr-x 1 oracle oinstall 4170 Mar 17 2021 Readme.txt
drwxr-xr-x 2 oracle oinstall 36 Mar 22 2026 adm
drwxr-xr-x 2 oracle oinstall 122 Mar 22 2026 bin
drwxr-xr-x 2 oracle oinstall 197 Mar 22 2026 bnd
drwxr-xr-x 2 oracle oinstall 157 Mar 22 09:16 cfg
drwxr-xr-x 2 oracle oinstall 24 Mar 22 2026 cfecache
drwxr-xr-x 4 oracle oinstall 27 Mar 22 2026 conv
drwxr-xr-x 3 oracle oinstall 49 Mar 22 09:26 db2dump
drwxr-xr-x 3 oracle oinstall 217 Mar 22 2026 lib
drwxr-xr-x 3 oracle oinstall 124 Mar 22 09:26 license
drwxr-xr-x 3 oracle oinstall 28 Mar 22 2026 msg
drwxr-xr-x 3 oracle oinstall 21 Mar 22 2026 properties
drwxr-xr-x 3 oracle oinstall 20 Mar 22 2026 security32
drwxr-xr-x 3 oracle oinstall 20 Mar 22 2026 security64

After correcting the oggca.rsp response file with the correct path, the configuration assistant ran successfully.

oracle@vmogg:/u01/app/oracle/product/ogg26/bin [ogg] oggca.sh -silent -responseFile /home/oracle/oggca.rsp
Successfully Setup Software.

Next time you encounter an error like this when setting up GoldenGate for DB2, make sure to check not only the variable value but also the actual content of the IBMCLIDRIVER directory !

NB: If you had this error for any other kind of setup, make sure to always check all the content of the response file you are using, as well as the prerequisites. (CLIDRIVER in this case, but it could be XAG, etc.)

L’article Deployment Creation INS-85037 Error With GoldenGate 26ai for DB2 z/OS est apparu en premier sur dbi Blog.

In the GoldenGate web UI, you can easily create Path Connections. Just go to the Path Connections tab, add a path, and specify the following information:

• Credential Alias: Alias used to connect to the target deployment. It doesn’t have to match any name on the target deployment.
• User ID: Real username that must exist on the target deployment.
• Password: Password associated with the User ID given before.

restapi.log analysis

But what about the REST API ? When looking at the list of endpoints given by Oracle, no REST endpoint explicitly refers to path connections, so how to create path connections through the REST API ?

The key point to understand is that path connections are not independent GoldenGate objects. In fact, they exist as a subset of another object, which you should know by now : aliases. Aliases are created to store credentials and are organized in domains. The default domain is called OracleGoldenGate, and Oracle has a reserved name for a subtype of domains : Network.

We can see this easily when creating a path connection through the web UI, and then looking at the restapi.log file. Open the log file located in the var/log folder of your deployment, or read the blog I wrote about restapi.log analysis. Using this method, we see the endpoint and the content of the API call. Here, for instance, I created a path connection from the web UI, to connect to ogg_user with the ogg_target alias.

oracle@vmogg: jq -c 'select (.request.context.verb == "POST" and .request.context.uriTemplate == "/services/{version}/credentials/{domain}/{alias}")' restapi.ndjson

{"request":{"context":{"verb":"POST","uri":"/services/v2/credentials/Network/ogg_target","uriTemplate":"/services/{version}/credentials/{domain}/{alias}"}},"content":{"userid":"ogg_user","password":"** Masked **"},...}

Path connection creation with the REST API

To summarize, path connections are just aliases in the Network domain. This simplifies the creation of path connections. You just need to make a POST API call to the alias endpoint, specifying Network as the domain. The exact endpoint is then /services/{version}/credentials/Network/{alias}.

Quick example: using the GoldenGate Python client I presented in another blog, let’s create an alias in the Network domain :

>>> from oggrestapi import OGGRestAPI

>>> ogg_client = OGGRestAPI(
    url="https://vmogg",
    username="ogg",
    password="ogg")
Connected to OGG REST API at https://vmogg

>>> ogg_client.create_alias(
    alias='ogg_dbi_blog',
    domain='Network',
    data={
        "userid": "ogg_user_on_target",
        "password": "***"
    }
)
{'$schema': 'api:standardResponse', 'links': [{'rel': 'canonical', 'href': 'https://vmogg/services/v2/credentials/Network/ogg_dbi_blog', 'mediaType': 'application/json'}, {'rel': 'self', 'href': 'https://vmogg/services/v2/credentials/Network/ogg_dbi_blog', 'mediaType': 'application/json'}], 'messages': [{'$schema': 'ogg:message', 'title': 'Credential store altered.', 'code': 'OGG-15114', 'severity': 'INFO', 'issued': '2026-03-22T10:14:01Z', 'type': 'https://docs.oracle.com/en/middleware/goldengate/core/23.26/error-messages/'}]}

After refreshing the web UI, the newly created path connection is visible.

L’article Creating Path Connections with GoldenGate REST API est apparu en premier sur dbi Blog.

One of them can lead to an OGG-15409 error during the migration. This error will not appear when running the migration tool in dryrun mode. You might then be faced with this issue only when doing the real migration. Here is the exact error:

ERROR: Unable to patch EXTRACT EXT, response is HTTP Status-Code 400: Bad Request..
[ERROR] OGG-15409 - Alias 'ggadmin_alias' not found in credential store domain 'OracleGoldenGate'.
Extract EXT Process Definitions patched.

Where does the error come from ?

The first step is to understand what is causing the issue. For this, you need to understand how the GoldenGate migration utility works.

When migrating extracts (or replicats), GoldenGate will make API calls to the new Microservices Architecture administration service to register the extract (or replicat). Once created, it will alter it with a PATCH request to update the credentials used.

We can see it in the restapi.log:

{"context":{"verb":"PATCH","uri":"/services/v2/extract/EXT",...},"content":{"credentials":{"alias":"ggadmin_alias","domain":"OracleGoldenGate"}},...}

Unfortunately, once the migration is done, you cannot re-run the migration. You will need to fix this manually.

But since this is the only post-migration task made on extracts and replicats, it is rather easy to do. You can just create the aliases first, and call the REST API to alter all extracts and replicats. In Python, using the client I presented in a previous blog post, it would look like the following. First, create the client connection.

from oggrestapi import OGGRestAPI
ogg_client = OGGRestAPI(url='https://vmogg:7810', username='ogg', password='***')

Then, check the content of the extract (or replicat) using the retrieve_extract (or retrieve_replicat) method. For the moment, we don’t see any credentials key.

# This retrieves all the configuration of an extract, except for the configuration file
>>> {k:v for k,v in ogg_client.retrieve_extract('EXT').items() if k != 'config'}
{'$schema': 'ogg:extract', 'targets': [{'name': 'aa', 'path': 'source', 'sizeMB': 500, ...}], 'description': 'dbi blog migration', 'source': 'tranlogs', 'type': 'Integrated'}

Then, create the alias(es) with the create_alias method.

ogg_client.create_alias(
    alias='ggadmin_alias',
    domain='OracleGoldenGate',
    data={
        "userid":"ggadmin@vmora:1521/DB",
        "password": "***"
    }
)

And finally, alter the extracts with the update_extract method.

ogg_client.update_extract(
    extract='EXT',
    data={
        "alias": "ggadmin_alias",
        "domain": "OracleGoldenGate"
    }
)

If you had the issue with a replicat, the syntax is exactly the same, with the update_replicat method.

ogg_client.update_replicat(
    replicat='REP',
    data={
        "alias": "ggadmin_alias",
        "domain": "OracleGoldenGate"
    }
)

You can check that the credentials are there by reusing the retrieve_extract (or retrieve_replicat) method. This time, we see the credentials key !

>>> {k:v for k,v in ogg_client.retrieve_extract('EXT').items() if k != 'config'}
{'$schema': 'ogg:extract', 'credentials': {'alias': 'ggadmin_alias', 'domain': 'OracleGoldenGate'}, 'targets': [{'name': 'aa', 'path': 'source', 'sizeMB': 500, ...}], 'description': 'dbi blog migration', 'source': 'tranlogs', 'type': 'Integrated', ...}

How to avoid this error ?

For some reason, the credentials of the source setup will not always be migrated. If you don’t have too many aliases, I would suggest creating the aliases in the target environment. This way, you know they are working even before attempting the migration. This should definitely be part of your new deployment tests.

L’article Credential Errors (OGG-15409) with GoldenGate Migration Utility est apparu en premier sur dbi Blog.

[ERROR] OGG-12020 - The request payload for 'POST /services/v2/config/files/ext.prm' is not defined as an object

It is a very cryptic error at first glance, but let’s try to understand what happened.

Where does the error come from ?

The first step is to understand what is causing the issue. For this, you need to understand how the GoldenGate migration utility works.

When migrating extracts (or any other GoldenGate object), GoldenGate will make API calls to the new microservices architecture administration service to register the extracts. The OGG-12020 error is just the API telling you that the POST call is invalid.

Let’s use the API log reader from a previous blog post to ease the analysis. You can also just read through the restapi.log of your target deployment, but it will be harder to read.

python3 restapi_to_ndjson.py $OGG_DEPLOYMENT_HOME/var/log restapi.ndjson

Using jq, we filter the failed POST calls against the URI given in the migration logs (/services/v2/config/files/ext.prm).

> jq -c 'select (.request.context.verb == "POST" and .request.context.uri == "/services/v2/config/files/ext.prm" and .restapi_status == "ERROR")' restapi.ndjson
{"request":{"context":{"httpContextKey":140077954104240,"verbId":4,"verb":"POST","originalVerb":"POST","uri":"/services/v2/config/files/ext.prm","protocol":"https","headers":{"Authorization":"** Masked **","Content-type":"application/json","User-Agent":"Java/1.8.0_482","Host":"oggma:port","Accept":"text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2","Connection":"keep-alive","Content-Length":"12417", "Content-Type":null,"X-OGG-Requestor-Id":"","X-OGG-Feature-List":""},"host":"oggma:port","securityEnabled":true,"authorization":{"authUserName":"ogg_user","authPassword":"** Masked **", "authMode":"Basic","authUserRole":"Security"},"requestId":5,"uriTemplate":"/services/{version}/config/files/{file}"},"content":null,"isScaRequest":true,"parameters":{"uri":{"file":"ext.prm","version":"v2"}}},"response":{"context":{"httpContextKey":140077954104240,"requestId":5,"code":"400 Bad Request","headers":{"Content-Type":"application/json","Strict-Transport-Security":"max-age=31536000;includeSubDomains","Set-Cookie":"** Masked **"},"Content-Type":"application/json","contentType":"text/html"},"isScaResponse":true,"content":{"$schema":"api:standardResponse","links":[{"rel":"canonical","href":"https://oggma:port/services/v2/config/files/ext.prm","mediaType":"text/html"},{"rel":"self","href":"https://oggma:port/services/v2/config/files/ext.prm","mediaType":"text/html"}],"messages":[{"$schema":"ogg:message","title":"The request payload for 'POST /services/v2/config/files/ext.prm' is not defined as an object.","code":"OGG-12020","severity":"ERROR","issued":"2026-03-05T09:55:24Z","type":"https://docs.oracle.com/en/middleware/goldengate/core/23.26/error-messages/"}]}},"restapi_datetime":"2026-03-05 10:55:24.448+0100","restapi_epoch":1772704524,"restapi_status":"ERROR","restapi_service":"adminsrvr","restapi_reqno":18}

You might not see the root cause at first, but if we only retrieve the content object:

> jq -c 'select (.request.context.verb == "POST" and .request.context.uri == "/services/v2/config/files/ext.prm" and .restapi_status == "ERROR") | {content:.request.content, message:.response.content.messages[0].title}' restapi.ndjson
{"content":null,"message":"The request payload for 'POST /services/v2/config/files/ext.prm' is not defined as an object."}

The migration utility is sending a request to the API with a null content, which obviously fails. Normally, the content key should contain a list with all the lines from the parameter file.

How to solve this issue ?

Unfortunately, there is no easy solution here. But here are the steps I took to solve the issue.

• First, you should make sure that the dryrun of the migration utility did not highlight any error in the formatting of the file.
• Then, make sure you are using the latest version of the migration utility.
• If it still doesn’t work, you unfortunately found a bug in the migration utility, and there is little you can do.

However, you can still use the tool to migrate. In my case, I managed to pinpoint the error to this line of the extract parameter file:

TOKENS (
    [...]
    TK_COL = [...] @STRSUB(column_name, '|', '\|', '\', '\\') [...]
);

The migration utility seems to have poor handling of these escape characters and does not fail properly. It should either fail before attempting the API call or send proper content to the API.

If you are sure that the incriminated syntax is valid in your target GoldenGate version, migrate with the following steps:

• Remove the incriminated syntax from the file. In my case, it meant removing the STRSUB section of the file.
• Migrate with the temporary parameter file
• Modify the parameter file in the target GoldenGate deployment, undoing the changes.

If you have a lot of extracts and replicats that need to be migrated, using this temporary file trick might be your best chance to secure your GoldenGate migration.

L’article OGG-12020 Payload Error in GoldenGate Migration Utility est apparu en premier sur dbi Blog.