The DMK is a set of standardized tools that aims at easing the work of DBAs by having dbi’s best practices embedded in common scripts across all the database servers of an organization.

dbi services provides the DMK (Database Management Kit) to its customers for multiple technologies: Oracle, Postgres, MongoDB, etc. This toolkit is provided free of charge to all clients who work with dbi services on a consulting project.

New features of the MongoDB DMK in 2.6.0

pymongo integration

DMK now uses pymongo as its default MongoDB connection backend where available, instead of always shelling out to mongosh. Every internal operation that used to spawn a mongosh subprocess and parse its printed output (status checks, session listing, replica set state) now runs the equivalent pymongo call directly in the same process. That skips the cost of starting a shell interpreter and a Node.js runtime for every single query. It also gets typed BSON values (timestamps, ObjectId, Decimal128) back natively instead of round-tripping them through JSON text.

A new mongo_connection.py module wraps either a pymongo client or a mongosh subprocess behind the same interface. It is automatically chosen based on whether pymongo is importable. Both backends return the same JSON-serializable shape, so the rest of DMK does not need to know which one is in use. pymongo is entirely optional: install it with pip3 install pymongo and DMK picks it up automatically the next time an alias or script runs. No restart and no configuration change are needed. Without it, DMK transparently falls back to the mongosh backend it has always used.

Set DMK_USE_PYMONGO=0 (or false/no) to force the mongosh backend even when pymongo is installed. This is useful to work around a pymongo-specific issue without uninstalling it. The dmkpymongo alias reports which backend is currently in use:

$ dmkpymongo
DMK is using the mongosh backend (pymongo is not installed).

Once pymongo is installed, the same alias instead reports DMK is using the pymongo backend (pymongo <version> installed).

Startup report in dmk_db_ctl.py

dmk_db_ctl.py gained a --startup-report option. After a start or restart, it scans the instance log for warnings/errors since the last startup and retrieves the server’s own startupWarnings buffer via getLog, then prints a combined report. If the start itself fails, the log is still scanned so the cause is visible.

dmk_db_ctl.py -i mdb01 -a start --startup-report
dmk_db_ctl.py -i mdb01 -a restart --startup-report --check-status

A successful restart reports both sources side by side, the log scan and the server’s own getLog buffer:

2026-09-02 15:22:05 | INFO | Restarting MongoDB instance mdb01 ...
2026-09-02 15:22:07 | INFO | MongoDB instance 'mdb01' is now 'STARTED'.
2026-09-02 15:22:08 | INFO | ------------------------------  Startup Report  ------------------------------
2026-09-02 15:22:08 | INFO | Log scan since last startup: 10 warning(s), 0 error(s)/fatal(s). Server startupWarnings buffer: 6 entrie(s).
2026-09-02 15:22:08 | INFO |   [W] 2026-09-02T15:22:05.865+00:00 (initandlisten) Access control is not enabled for the database. Read and write access to data and configuration is unrestricted
2026-09-02 15:22:08 | INFO |   [W] 2026-09-02T15:22:05.865+00:00 (initandlisten) We suggest setting swappiness to 0 or 1, as swapping can cause performance problems.
2026-09-02 15:22:08 | INFO |   [W] 2026-09-02T15:22:06.006+00:00 (ftdc) Use of deprecated server parameter 'sslMode', please use 'tlsMode' instead.
2026-09-02 15:22:08 | INFO |   [I] 2026-09-02T15:22:05.517+00:00 (initandlisten) Using the XFS filesystem is strongly recommended with the WiredTiger storage engine. See http://dochub.mongodb.org/core/prodnotes-filesystem (getLog)
2026-09-02 15:22:08 | INFO | ------------------------------------------------------------------------------

A failed start scans only the log, since the server was never reachable and there is no getLog buffer to add, then still re-raises so the command’s own exit code stays non-zero:

2026-09-02 15:21:45 | INFO | Restarting MongoDB instance mdb01 ...
2026-09-02 15:21:47 | ERROR | Instance failed to start. Scanning log for the cause ...
2026-09-02 15:21:47 | INFO | ------------------------------  Startup Report  ------------------------------
2026-09-02 15:21:47 | INFO | Log scan since last startup: 10 warning(s), 0 error(s)/fatal(s). Server startupWarnings buffer: 0 entrie(s).
2026-09-02 15:21:47 | INFO | ------------------------------------------------------------------------------

Without --check-status, dmk_db_ctl.py does not wait to confirm the server actually came up, so a start that silently fails to bind (a bad port in the configuration file, for example) still reports the previous startup’s log content as if it were current, with exit code 0. Pass --check-status alongside --startup-report whenever the report’s purpose is to catch a failed start, not just to review a successful one.

Default ~/.mongoshrc.js

DMK now bootstraps a ~/.mongoshrc.js on first run (never overwriting an existing one), setting a prompt that shows host:port, database name, and replica set/mongos role, plus a set of read-only show*() helper functions for users, database/collection/index sizes, locks, active sessions, replica set status, and sharding status.

On a standalone instance, the prompt reports standalone:

[standalone] 127.0.0.1:27017/admin>

On a replica set, it reports the replica set name and the member’s current role instead:

[dbirs:PRIMARY] 127.0.0.1:28001/admin>

Run showAliases() at any time to list every available show*() helper:

showUsers()             - users across all databases
showAllDBSizes()        - size of all databases, in MB
showAllCollections()    - all collections across all databases, including system ones
showCollections()       - all collections across all databases, excluding system ones
showIndexSizes()        - index sizes for collections in the current database
showUserRoles()         - user roles across all databases
showLocks()             - current lock statistics
showWaits()             - current lock queue / active clients
showActiveSessions()    - currently active sessions/operations
showMongoDBVersion()    - MongoDB server version
showMongoshVersion()    - mongosh version
showReplicaSetInfo()    - replica set status (rs.status())
showReplicaSetConfig()  - replica set configuration (rs.conf())
showShardStatus()       - list of shards in a sharded cluster
showChunkDistribution() - chunk count per shard, per sharded collection
showBalancerStatus()    - whether the sharding balancer is enabled

New oplog alias

A new oplog alias (msp ${DMK_HOME}/js/oplog_info.js) shows a replica set member’s oplog configured/used size and the time window (first entry to last entry) it currently covers, formatted as days/hours/minutes/seconds:

$ oplog
Oplog size:
-------------
  Configured size: 990.00 MB
  Used:            978.19 MB (98.81%)

Oplog window:
---------------
  First entry: Fri Aug 28 2026 15:44:01 GMT+0000 (Coordinated Universal Time)
  Last entry:  Wed Sep 02 2026 15:23:13 GMT+0000 (Coordinated Universal Time)
  Covers:      4d 23h 39m 12s (430752s)

sess alias improvements

The session view (sess / dmk_status.py --sessions) now hides internal/background operations (replication threads, Checkpointer, TTLMonitor, and similar) by default, since they have no client connection behind them and are noise for “who’s connected” questions. Pass --include-internal (or --show-all) to bring them back. Session rows also now show planSummary.

Configuration file parsing fixes

Quote parsing in the DMK configuration file received further fixes. The YAML parser gained list support, and a bug where it could silently re-parent sibling keys into the wrong nested block was fixed. update_mongo_conf.py now edits a configuration file’s lines directly instead of rewriting the whole file, so comments, lists, and header formatting are no longer destroyed. A password containing an unquoted # in cred.yaml is no longer silently truncated as an inline comment.

systemd sudo grant check

dmk_db_ctl.py now checks that the current user actually has the sudo grants to run systemctl start|stop on the instance’s service before attempting it, failing fast with a clear message instead of surfacing sudo’s own cryptic stderr.

dmk_dbcreate.py improvements

Directory/config path variables (admin_path, log_path, data_path) are now read from the installer template rather than re-derived from environment variables that could differ from it, which could set up an instance’s directories in the wrong place. dmk_dbcreate.py also now checks the configured port for conflicts before creating an instance: it verifies the port is a valid integer, is not already assigned to another instance in mongodb.lst, and is not already accepted by a listening process, failing fast with a clear error instead of creating an instance that silently squats on a port already in use.

New DMK_DEBUG=3 trace tier

Level 2 debug output previously mixed operational debug (instance, connection, status) with high-volume configuration-file parsing/computation output, making it hard to isolate the signal that actually matters when troubleshooting. That parsing/computation noise now only appears at a new DMK_DEBUG=3 (TRACE) tier; levels 0-2 keep their existing meaning unchanged.

Bug fixes

A few notable bugs were fixed in this release:

• Session runtime was truncated to the low 32 bits on the mongosh backend, so operations running over roughly 71 minutes showed a wrong, wrapped time. Fixed.
• Status table sorting on numeric columns was lexicographic, so port 9000 sorted after port 27017. Fixed.
• A process-existence check could raise an error if an instance stopped between reading its process list and reading its PID file. Fixed.

Upgrading from an earlier version of DMK

If you are upgrading from DMK 2.5.0, replace the DMK folder with the new one:

cd /u01/app/mongodb/local
mv dmk .dmk_old
unzip /path/to/dmk_mongodb-2.6.0.zip
dmk

If you are upgrading from DMK 2.4.0 or earlier, read the release notes of DMK 2.5.0 first.

L’article MongoDB DMK 2.6.0 : pymongo integration and new features est apparu en premier sur dbi Blog.

Please note that these operations are useful not just for renaming an extract. You can also use the same steps to move an extract to another deployment, or to another host.

Can’t I just directly rename the extract and restart it ?

Unfortunately, it is not possible to just rename the extract and restart it. Extracts are registered in the database and are associated with a specific SCN. If you stop an extract and try to start it with a new name, you will get an error because the extract is not registered with the new name inside the source database. Moreover, if you try to create a new extract with the new name, you will miss transactions if you do not follow the correct steps described in this blog.

Steps to rename a GoldenGate extract

The main steps to rename a GoldenGate extract are the following:

• Build the LogMiner data dictionary (if you don’t already build it regularly).
• Check for long running transactions in the source database.
• Stop the extract that you want to rename.
• Get the SCN of the oldest unprocessed transaction.
• Find the dictionary build to register the new extract.
• Create the new extract, registered and started at the correct SCNs.
• Copy the parameter file and start the new extract.

Build the LogMiner data dictionary

To register the new extract, you need a LogMiner data dictionary build that exists at or before the start SCN. If your dictionary build SCN is after the start SCN, this will not work. If you don’t already build the dictionary regularly, build one now with DBMS_CAPTURE_ADM.BUILD :

SET SERVEROUTPUT ON
DECLARE
    scn NUMBER;
BEGIN
    DBMS_CAPTURE_ADM.BUILD(first_scn => scn);
    DBMS_OUTPUT.PUT_LINE('Dictionary build starting SCN: ' || scn);
END;
/

Dictionary build starting SCN: 17218169

PL/SQL procedure successfully completed.

Check for long running transactions in the source database

The recovery checkpoint only moves forward when a transaction commits. This means that an open long running transaction will freeze the start SCN. It is worth checking for long running transactions here : the start SCN (the oldest unprocessed transaction) must stay after the dictionary build SCN, since that build is what you register the new extract with. The further back a long running transaction freezes the start SCN, the more likely it drops before your build, and the more redo the new extract has to re-mine before it catches up. I dedicated a full blog on checking long running transactions in GoldenGate both from the adminclient and the REST API, please have a look at it.

OGG (https://vmogg ogg_test_01) 1> send extract ext1 showtrans tabular

Sending showtrans tabular request to Extract group EXT1 ...

No transactions found.

Here, the idea is to wait until there are no transactions started before the dictionary build SCN.

Stop the extract that you want to rename

Once the dictionary is built and there are no long running transactions, you can stop the extract.

OGG (https://vmogg ogg_test_01) 2> stop extract ext1

Get the SCN of the oldest unprocessed transaction

The SCN you are looking for is the one of the oldest unprocessed transaction, which corresponds to the recovery checkpoint of the extract. In the rest of the blog, I will refer to it as the start SCN, because this is the SCN from which the new extract will be started. In this example, the start SCN is 17219083.

OGG (https://vmogg ogg_test_01) 3> info extract ext1 showch
...
  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Timestamp: 2026-08-12 18:35:47.000000
    SCN: 0.17219083 (17219083)
...

Find the dictionary build to register the new extract

If you waited for long running transactions to commit, as mentioned before, the dictionary build that you have will be before the start SCN. However, if you build the dictionary on a regular basis and did not check the long running transactions, you need to retrieve the most recent build that is still older than the start SCN:

SELECT first_change#
FROM v$archived_log
WHERE dictionary_begin = 'YES'
AND standby_dest = 'NO'
AND name IS NOT NULL
AND status = 'A'
AND first_change# < 17219083 -- the start SCN retrieved above
ORDER BY first_change# DESC
FETCH FIRST 1 ROWS ONLY;

FIRST_CHANGE#
-------------
   17218169

The first_change# < start_scn filter is the important part. Without it, you might pick the most recent dictionary build overall, which is not guaranteed to have happened before the start SCN. In the rest of the blog, I will refer to 17218169 as the dictionary build SCN.

If the query returns no rows at all, no build predates the start SCN yet. In that case, you must build the dictionary again, as shown above. Then, you must restart the extract and wait for the oldest unprocessed transaction (recovery checkpoint) to go beyond this SCN.

Create the new extract at the correct SCNs

We now have the two SCNs we need :

• The dictionary build SCN (17218169 in the example), used to register the extract.
• The start SCN (17219083 in the example), the oldest unprocessed transaction, used to add the extract.

From the adminclient, log into the database, then create and register the new extract :

OGG (https://vmogg ogg_test_01) 4> dblogin useridalias source_cdb
Successfully logged into database CDB$ROOT.

# Here, we are using the start SCN
OGG (https://vmogg ogg_test_01) 5> add extract ext2, integrated tranlog, scn 17219083
Integrated Extract added.

# Here, we are using the dictionary build SCN
OGG (https://vmogg ogg_test_01) 6> register extract ext2 database scn 17218169 container (pdb1)
Extract group EXT2 successfully registered with database at SCN 17218169.

Copy the parameter file and start the new extract

Finally, copy the content of the parameter file from the old extract to the new one, only changing the extract name. Here, you need to make one choice:

• Keep the same trail file name, aa in this case. You will have to delete the original EXT1 extract, since two extracts cannot write to the same trail file. EXT2 will start from the next trail sequence.
• Change to another trail file name. In that case, you would have to reconfigure all replicats or distribution paths consuming the trail file.

OGG (https://vmogg ogg_test_01) 7> view params ext1
EXTRACT EXT1
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL aa
SOURCECATALOG PDB1
TABLE SALES.ORDERS;

OGG (https://vmogg ogg_test_01) 8> edit params ext2
EXTRACT EXT2
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL aa
SOURCECATALOG PDB1
TABLE SALES.ORDERS;

In this case, after deleting EXT1 to free the trail, assign the trail to EXT2, then start the new extract. It will pick up exactly where the old one left off.

OGG (https://vmogg ogg_test_01) 9> add exttrail aa, extract ext2
EXTTRAIL added.

OGG (https://vmogg ogg_test_01) 10> start extract ext2

L’article Rename a GoldenGate Extract Without Missing Transactions est apparu en premier sur dbi Blog.

Why DB2 z/OS upgrades are different

With Oracle, a GoldenGate upgrade does not really involve the databases themselves. You just have to install the new home, and migrate or reconfigure extracts and replicats. Provided that you do not have a complex custom layer on top of it (automation, pipelines, etc.), this is everything you have to do. With DB2 z/OS, GoldenGate talks to the DB2 database through the CLI driver. This driver has its own version, its own licensing, and its own DB2-side procedures that need to be updated. If you only upgrade GoldenGate and the CLI driver but forget the DB2 z/OS side, you will hit errors when trying to extract data from DB2. On top of this, a stored procedure is installed in the DB2 database, for GoldenGate to work.

The SQL1598N licensing issue

The first error you might encounter when upgrading the CLI driver as part of a GoldenGate upgrade is related to the licensing file. I detailed this in a previous blog, but the short version is: the IBM Data Server Driver for ODBC and CLI does not ship with a license file to connect to DB2 for z/OS. A separate file, db2consv_zs.lic, has to be placed manually into the clidriver/license/ directory. This file is tied to the exact driver version ! Reusing the license from your old driver (11.1) in the new driver’s directory (12.1) will not work, and connections will fail with:

SQLState : 42968
NativeError : -1598
DiagMsg: [IBM][CLI Driver] SQL1598N An attempt to connect to the database
server failed because of a licensing problem. SQLSTATE=42968

Remember to get the new license file and test it way before the cutover. Whoever manages IBM software on your side, or IBM support directly, needs to provide a new db2consv_zs.lic matching the target driver version. Since getting a license file from IBM support is rarely instantaneous, plan some time to get this done.

The DB2-side stored procedure step

This is the part which is easy to miss because it doesn’t happen on the GoldenGate host at all. However, it is documented by Oracle. A GoldenGate extract for DB2 z/OS relies on an initialization and utility stored procedure which is installed directly in DB2 itself. This stored procedure ships with each GoldenGate release and is versioned against it. When you upgrade GoldenGate, the stored procedure sitting in the DB2 subsystem does not upgrade itself. It stays at whatever version was installed during the last GoldenGate install, until it is explicitly reinstalled.

When setting up a new GoldenGate home for DB2, a zOSutils.zip file is included under $OGG_HOME/lib. This is what you must use. The new stored procedure will replace the old one in the catalog.

Just like the CLI driver issues described above, this should be managed by DB2 engineers. Installing or replacing a stored procedure at the DB2 level requires the appropriate privileges, which a Database/GoldenGate/Linux administrator typically does not have. Talk with your DB2 for z/OS DBA or systems engineer as part of the upgrade plan, and treat the stored procedure reinstall as a mandatory step of the GoldenGate upgrade itself.

OGG-30121 or OGG-30057 with DB2 procedure upgrade

If GoldenGate itself gets upgraded but the stored procedure in the DB2 subsystem is left at its old version, the extract will detect the mismatch at startup and abend with OGG-30121:

OGG-30121  ERROR  The initialization and utility stored procedure major version is 210610 and is not compatible with this Extract. (The minor version is 00).

Getting an OGG-30121 error during a GoldenGate upgrade means that the DB2-side stored procedure reinstall was missed. There is no need to start debugging the GoldenGate configuration.

Also, please note that this stored procedure change needs to happen during the GoldenGate upgrade, not before. What I mean by this is that you cannot ask for the stored procedure to be updated a week before the GoldenGate upgrade. You will need to allocate time for updating the stored procedure in your upgrade scenario.

The reverse situation also exists. If you update the procedure but not GoldenGate, you will have an OGG-30057 error when attempting to restart the extracts.

OGG-30057  ERROR  The log reading user-defined function major version is 231010 and is not supported. (The minor version is 00)

Other things to check during the upgrade

Here are a few other points regarding issues I faced when upgrading GoldenGate for DB2 setups in the past:

• The response file contain an IBMCLIDRIVER variable. It must point to the actual root of the CLI driver installation, not a parent directory. A wrong path produces an INS-85037 deployment error when using oggca.sh.
• Confirm your GoldenGate version is still under Premier Support or Extended Support before you upgrade. Indeed, 19c and 21c Premier Support came to an end in May 2026, as covered in my migration planning blog.

Using the Migration Utility with DB2 z/OS sources

If part of your upgrade also involves moving from Classic Architecture to Microservices, the general procedure and its limitations are the same, regardless of source database, and covered in Upgrade GoldenGate from Classic to Microservices Architecture. You can use the migration utility delivered by Oracle (patch 37274898 / KB100447 in MOS). You will still have to pay attention to the points described above.

Checklist summary

Before upgrading GoldenGate for DB2 z/OS:

• Confirm your support status before deciding on a target version. You should upgrade to 26ai.
• Identify the current and target CLI driver version and request the matching db2consv_zs.lic from IBM (or your internal license owner) ahead of time, if needed.
• Open a change request with your DB2 for z/OS DBA/systems engineer to reinstall the GoldenGate stored procedure in every affected DB2 database. This must be done during the upgrade, after stopping and before restarting the new extracts.
• After cutover, if an extract abends with the OGG-30121 or OGG-30057 error, check the stored procedure at the DB2 level.

With this, I hope you will succeed in your GoldenGate for DB2 z/OS migrations and upgrades.

L’article GoldenGate DB2 z/OS Upgrade Checklist est apparu en premier sur dbi Blog.

This blog covers the exact same setup, using the REST API instead. I will show two ways of doing it :

• Using oggrestapi.py, the GoldenGate REST client I released in another blog.
• Using the requests library to call the REST API directly.

Prerequisites

The prerequisites are the same as in the previous blog :

• Two GoldenGate Microservices deployments, ogg_test_01 (source) on oggvm1 and ogg_test_02 (target) on oggvm2. I will use the latest 26ai version.
• Both OGG setups secured with NGINX acting as a reverse proxy, so everything goes through port 443.
• A running extract on the source, writing to a trail (aa in my case).

Just like in the Web UI, there are three steps to get a working distribution path :

• Create a path connection on the source, to authenticate against the target.
• Register the target’s CA certificate on the source Service Manager.
• Create and start the distribution path.

A quick note on URLs before we start. Behind an NGINX reverse proxy, each service has its own path prefix :

• Administration Service : /services/<deployment>/adminsrvr/v2/...
• Distribution Service : /services/<deployment>/distsrvr/v2/...
• Service Manager : /services/ServiceManager/v2/...

The oggrestapi.py client builds these for you as soon as you pass reverse_proxy=True and the deployment name, so let’s connect once and reuse the client. If you don’t provide the password argument, you will be prompted for it.

from oggrestapi import OGGRestAPI

ogg_source = OGGRestAPI(
    url="https://oggvm1",
    username="ogg",
    deployment="ogg_test_01",
    reverse_proxy=True,
)

Create the path connection

As explained in Creating Path Connections with GoldenGate REST API, a path connection is simply an alias in the Network domain. It stores the credentials of a user that exists on the target deployment, and its alias is only known on the source side.

With the client, just call the create_alias method :

ogg_source.create_alias(
    alias="ogg_target",
    domain="Network",
    data={
        "userid": "ogg_user_on_target",
        "password": "***",
    },
)

As mentioned in the introduction, here is the same call with requests, calling the Administration Service of oggvm1 through NGINX :

import requests

auth = ("ogg", "ogg_password")

response = requests.post(
    "https://oggvm1/services/ogg_test_01/adminsrvr/v2/credentials/Network/ogg_target",
    auth=auth,
    json={
        "userid": "ogg_user_on_target",
        "password": "***",
    },
)

After refreshing the source Web UI, the new path connection is visible under the Path Connections tab :

But of course, you can also view the new path connection by calling the REST API:

# Since path connections are aliases of the Network domain, we use the get_alias method to retrieve them
>>> ogg_source.get_alias('Network', 'ogg_target')
{'$schema': 'ogg:credentials', 'userid': 'ogg_user_on_target', 'type': 'PASSWORD'}

Register the target’s CA certificate

Because the deployments are secured with NGINX, the source has to trust the certificate authority that signed the target’s certificate. This is done on the source Service Manager, by registering the target’s root CA certificate.

With the client, use create_deployment_certificate against the source deployment. The certificate type to use is truststore, and the certificate content goes under trustpointBundle.trustpointPem:

target_ca = open("rootCA_ogg_test_02.pem").read()

ogg_source.create_deployment_certificate(
    deployment="ogg_test_01",
    type="truststore",
    certificate="rootCA_ogg_test_02",
    data={
        "trustpointBundle": {
            "trustpointPem": target_ca,
        }
    },
)

The same call with requests, this time on the Service Manager prefix :

target_ca = open("rootCA_ogg_test_02.pem").read()

response = requests.post(
    "https://oggvm1/services/ServiceManager/v2/deployments/ogg_test_01/certificates/truststore/rootCA_ogg_test_02",
    auth=auth,
    json={
        "trustpointBundle": {
            "trustpointPem": target_ca,
        }
    },
)

Registering under the specific deployment (ogg_test_01) is the equivalent of the Local option in the Web UI. To get the Shared behavior instead, register the same certificate under the ServiceManager deployment name, so it becomes available to every deployment on that node.

If the certificate file contains a chain of certificates, you must register each certificate individually, since GoldenGate does not accept them in one go. I described that issue in detail in a blog about the OGG-30007 error.

Create and start the distribution path

We can now create the distribution path itself. It has a source endpoint (the local trail) and a target endpoint (the target’s Receiver Service, reached over wss through NGINX). Because the target is NGINX-secured, the target URI :

• uses the wss protocol on port 443,
• points at the Receiver Service path prefix, recvsrvr, not distsrvr (that prefix is only for the Distribution Service on the source side),
• does not carry the path connection alias itself. The alias goes in a separate authenticationMethod key.

With the client :

ogg_source.create_distribution_path(
    distpath="path12",
    name="path12",
    source={
        "uri": "trail://localhost/services/v2/sources?trail=PDB1/aa",
    },
    target={
        "uri": "wss://oggvm2/services/ogg_test_02/recvsrvr/v2/targets?trail=PDB1/bb",
        "authenticationMethod": {
            "domain": "Network",
            "alias": "ogg_target",
        },
    },
    begin="now",
    status="running",
)

And the equivalent requests call, on the Distribution Service prefix (/services/ogg_test_01/distsrvr/):

response = requests.post(
    "https://oggvm1/services/ogg_test_01/distsrvr/v2/sources/path12",
    auth=auth,
    json={
        "name": "path12",
        "source": {
            "uri": "trail://localhost/services/v2/sources?trail=PDB1/aa",
        },
        "target": {
            "uri": "wss://oggvm2/services/ogg_test_02/recvsrvr/v2/targets?trail=PDB1/bb",
            "authenticationMethod": {
                "domain": "Network",
                "alias": "ogg_target",
            },
        },
        "begin": "now",
        "status": "running",
    },
)

The trail value in both URIs also has to match the path the extract actually registers, EXTTRAIL PDB1/aa on the source becomes trail=PDB1/aa in the source URI, and the same logic applies to the target’s bb trail. A bare trail=aa without the PDB path segment matches neither what the extract writes nor what the target’s own directory layout expects.

Once the path is created with status: "running", the trail files start flowing. You can confirm it on the target :

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 CA certificate is registered on the source Service Manager, and not the other way around.

And that’s it. With three REST calls, through oggrestapi.py or using the requests module, you get the exact same NGINX-secured distribution path as the Web UI method, but in a form you can script and repeat.

L’article NGINX Secured Distribution Path with GoldenGate REST API est apparu en premier sur dbi Blog.

Every step below shows two ways to make the same call:

• A standard requests call, the default Python module to handle REST APIs.
• The equivalent call using oggrestapi.py, the OGGRestAPI Python client I presented in another blog, which handles everything for you.

Installing the latest version of GoldenGate

This part does not change: the REST API cannot install software on the server, so you still need to unzip the patched installation to a new OGG_HOME and run runInstaller in silent mode, as described in the web UI blog.

Patching the Service Manager with the REST API

As with the web UI, the Service Manager has to be patched first. Assume the following setup:

• sm_url: https://vmogg:7809
• new_ogg_home: /u01/app/ogg/product/23.26.2.0.1
• username / password: an administrator on the Service Manager

Updating OGG_HOME is a PATCH call on the ServiceManager deployment:

import requests

sm_url = "https://vmogg:7809"
auth = ("oggadmin", "password")

requests.patch(
    f"{sm_url}/services/v2/deployments/ServiceManager",
    json={"oggHome": "/u01/app/ogg/product/23.26.2.0.1"},
    auth=auth,
)

With oggrestapi.py:

from oggrestapi import OGGRestAPI

client = OGGRestAPI(url="https://vmogg:7809", username="oggadmin", password="password")
client.update_deployment(deployment="ServiceManager", ogg_home="/u01/app/ogg/product/23.26.2.0.1")

Already, you can see that the REST API client simplifies the patching a lot.

Restarting the Service Manager is the same endpoint, this time setting status:

requests.patch(
    f"{sm_url}/services/v2/deployments/ServiceManager",
    json={"status": "restart"},
    auth=auth,
)

client.restart_deployment(deployment="ServiceManager")

restart_deployment is a dedicated method in oggrestapi.py, following the same pattern already used for restart_service, restart_extract and restart_replicat. It makes it easier to use the API, instead of building the {"status": "restart"} payload yourself. It also takes an optional only_if_running argument, so a deployment that was already stopped before the patch is left alone rather than being started by the restart call.

As with the web UI, all your deployment processes are still running on the old OGG_HOME at this point. The AIService, introduced in 26ai, does not pick up the new home automatically either. You should then list the services attached to the Service Manager and restart the ones that are not ServiceManager itself:

services = requests.get(
    f"{sm_url}/services/v2/deployments/ServiceManager/services",
    auth=auth,
).json()["response"]["items"]

for service in services:
    if service["name"] != "ServiceManager":
        requests.patch(
            f"{sm_url}/services/v2/deployments/ServiceManager/services/{service['name']}",
            json={"status": "restart"},
            auth=auth,
        )

for service in client.list_services("ServiceManager"):
    if service.get("name") != "ServiceManager":
        client.restart_service(deployment="ServiceManager", service=service.get("name"))

Patching each deployment with the REST API

Once the Service Manager runs on the new home, repeat the same update, then restart sequence for each deployment (oggHome, then status: restart):

deployment = "ogg_test_01"

requests.patch(
    f"{sm_url}/services/v2/deployments/{deployment}",
    json={"oggHome": "/u01/app/ogg/product/23.26.2.0.1"},
    auth=auth,
)

requests.patch(
    f"{sm_url}/services/v2/deployments/{deployment}",
    json={"status": "restart"},
    auth=auth,
)

client.update_deployment(deployment="ogg_test_01", ogg_home="/u01/app/ogg/product/23.26.2.0.1")
client.restart_deployment(deployment="ogg_test_01")

Once the deployment is back up, restart its extracts and replicats. Since these processes are not accessible through the Service Manager port, you need to change the URL. If you use a reverse proxy setup, or auto_discovery=True (see below), this is also easier with the Python client.

admin_url = "https://vmogg:7810"

extracts = requests.get(f"{admin_url}/services/v2/extracts", auth=auth).json()["response"]["items"]
for extract in extracts:
    requests.patch(f"{admin_url}/services/v2/extracts/{extract['name']}", json={"status": "stopped"}, auth=auth)
    requests.patch(f"{admin_url}/services/v2/extracts/{extract['name']}", json={"status": "running"}, auth=auth)

replicats = requests.get(f"{admin_url}/services/v2/replicats", auth=auth).json()["response"]["items"]
for replicat in replicats:
    requests.patch(f"{admin_url}/services/v2/replicats/{replicat['name']}", json={"status": "stopped"}, auth=auth)
    requests.patch(f"{admin_url}/services/v2/replicats/{replicat['name']}", json={"status": "running"}, auth=auth)

With oggrestapi.py, restart_all_extracts and restart_all_replicats do the same thing on an OGGRestAPI client already pointed at the deployment (either connected directly to its Administration Service, or through an NGINX reverse proxy with deployment= set):

admin_client = OGGRestAPI(url="https://vmogg:7810", username="oggadmin", password="password")
admin_client.restart_all_extracts(only_if_running=True)
admin_client.restart_all_replicats(only_if_running=True)

Automating the whole patching in one call

The steps listed above (update home, restart deployment, restart processes for every deployment) is exactly what patch_deployment (a single deployment) and patch_deployments (all of them) already do in oggrestapi.py, internally calling restart_deployment for the restart step. They also handle the ServiceManager special case (patch and restart the deployment and its services, but never restart extracts and replicats on it) and the wait_until_deployment_status polling in between:

client = OGGRestAPI(url="https://vmogg:7809", username="oggadmin", password="password", reverse_proxy=True)
client.patch_deployments(new_home="/u01/app/ogg/product/23.26.2.0.1", ask_credentials=False)

Both methods take restart_after_patch and restart_processes_after_patch (both default to True) if you need to skip either step, for example to patch every home first and restart everything in a separate maintenance window:

client.patch_deployments(
    new_home="/u01/app/ogg/product/23.26.2.0.1",
    restart_after_patch=False,
    restart_processes_after_patch=False,
    ask_credentials=False,
)

restart_processes_after_patch=True needs per-deployment routing: restarting extracts and replicats on ogg_test_01 is a different call than on ogg_test_02, and a plain connection to the Service Manager’s own port has no way to reach either one. oggrestapi.py gives you two ways to get that routing from a single client:

• reverse_proxy=True, shown above, if you already run NGINX in front of your deployments.
• auto_discovery=True, with no reverse proxy at all. The client looks up each deployment’s real Administration/Distribution/Performance Metrics Service port through the Service Manager itself (the same GET .../deployments/{deployment}/services/{service} call), the first time each one is actually needed, and reuses that lookup for the rest of the run:

client = OGGRestAPI(url="https://vmogg:7809", username="oggadmin", password="password", auto_discovery=True)
client.patch_deployments(new_home="/u01/app/ogg/product/23.26.2.0.1", ask_credentials=False)

Without either flag, patch with restart_processes_after_patch=False and restart each deployment’s processes yourself through a separate client pointed at that deployment’s own admin URL.

Some services are still running on the old OGG_HOME

Same as with the web UI: a restart call on a deployment returns as soon as the Administration Service (adminsrvr) is back up. The Receiver Service (recvsrvr) or the Distribution Service (distsrvr) can take a bit longer to restart. If, after polling for a few minutes, a service is still reporting the old home, restart it individually with the same PATCH .../services/{service} call shown above for the AIService, or with the restart_service method.

Other things to consider

If you change the name of your home at every release, remember to update OGG_HOME in every script and environment that references it, for example:

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

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

When and why should I worry about long running transactions ?

In a standard extract life-cycle, you should not be worrying about long running transactions. In fact, the only time you should think about these is when you plan an extract migration. By this, I mean moving an ongoing extract to a new GoldenGate environment.

This could be the case if you are moving the extract to a new GoldenGate deployment, whether it’s because of a version upgrade, system change or architecture change.

Another candidate scenario would be if you wanted to rename an extract.

Checking for Long Running Transactions with the adminclient

To check for long running transactions in the source database, you can use the adminclient and the showtrans tabular option of the send command.

OGG (https://vmogg ogg_test_01) 1> send extract ext showtrans tabular

Sending showtrans tabular request to Extract group EXT ...



XID                     Items    Extract   Redo Thread  Start Time           SCN                               Redo Seq  Redo RBA            Status
------------------------------------------------------------------------------------------------------------------------------------------------------
0.17.18.1700953         0        EXT       1            2026-06-06:08:04:12  629.3084780551 (2704619209735)    48911     156909584           Running

WARNING: This command will query the database for ALL active transactions ! There is absolutely no filter in place to only show transactions that are relevant for the extract you are targeting. To confirm this, let’s look in the database to get more information about this transaction.

-- Query to get the schema associated with a specific transaction, based on the XID column from the OGG output above
SELECT s.username, t.xidusn, t.xidslot, t.xidsqn, t.start_time, t.start_scn
FROM v$transaction t
JOIN v$session s ON t.ses_addr = s.saddr
WHERE t.xidusn = 17
AND t.xidslot = 18
AND t.xidsqn = 1700953;

USERNAME       XIDUSN     XIDSLOT      XIDSQN START_TIME          START_SCN
---------  ----------  ----------  ---------- ------------------- ----------------
DBIBLOG            17          18     1700953 06/06/26 08:04:12   2704619209735

But if I look at the extract parameter file, the DBIBLOG schema is not even being extracted.

OGG (https://vmogg ogg_test_01) 1> view params EXT
EXTRACT EXT
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1
TABLE APP_SCHEMA.*;

Of course, the DBIBLOG user might be editing data in the APP_SCHEMA schema, but there is no way to know for sure just by looking at the output of adminclient command above.

When searching for long running transactions, you should retrieve the START_SCN of the transaction. In the example given above, the START_SCN is 2704619209735.

Now that we have the START_SCN, we can check if the extract has already processed it or not by looking at the checkpoint information. From the adminclient, run the info extract EXT showch command:

OGG (https://vmogg ogg_test_01) 1> info extract EXT showch

Extract    EXT       Last Started 2026-06-06 07:45   Status RUNNING
Description          'Test extract'
Checkpoint Lag       00:01:45 (updated 00:00:32 ago)
Process ID           11711
Log Read Checkpoint  Oracle Integrated Redo Logs
                     2026-06-06:09:01:45
                     SCN 629.3086233843 (2704620663027)
Settings Profile     ogg:managedProcessSettings:dbiDefault


Current Checkpoint Detail:

Read Checkpoint #1

  Oracle Integrated Redo Log

  Startup Checkpoint (starting position in the data source):
    Timestamp: 2026-06-06:07:45:45.000000
    SCN: 0.0 (0)

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Timestamp: 2026-06-06:08:04:13.000000
    SCN: 629.3084780551 (2704619209735)

  Current Checkpoint (position of last record read in the data source):
    Timestamp: 2026-06-06:09:01:45.000000
    SCN: 629.3086233843 (2704620663027)

  BR Startup Recovery Checkpoint:
    Timestamp: 2026-06-02 10:17:33.403806
    SCN: 0.0 (0)

  BR Begin Recovery Checkpoint:
    Timestamp: 2026-06-06 08:04:13.000000
    SCN: 629.3084780551 (2704619209735)

  BR End Recovery Checkpoint:
    Timestamp: 2026-06-06 08:08:45.000000
    SCN: 629.3084879559 (2704619308743)

Write Checkpoint #1

  GGS Log Trail

  Current Checkpoint (current write position):
    Sequence #: 41
    RBA: 50476
...

If we put side to side the START_SCN of the long running transaction and the SCN of the recovery checkpoint, we can see that they are exactly the same (2704619209735). This is expected, and it means that the extract has not yet processed this transaction.

# From SQL query on the source database
USERNAME       XIDUSN     XIDSLOT      XIDSQN START_TIME          START_SCN
---------  ----------  ----------  ---------- ------------------- ----------------
DBIBLOG            17          18     1700953 06/06/26 08:04:12   2704619209735

# From adminclient
  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Timestamp: 2026-06-06:08:04:13.000000
    SCN: 629.3084780551 (2704619209735)

If you wanted to move the extract to another GoldenGate installation or rename it, this would be the SCN at which you would need to start the new extract to avoid missing transactions.

Checking for Long Running Transactions from the REST API

If you are trying to automate the process of checking for long running transactions, using the adminclient might not be the best option. In fact, the display of long running transactions in the adminclient is not designed to be easily parsed by scripts.

Fortunately, you can also check for long running transactions using the official GoldenGate REST API. The endpoint that you need to call is GET /services/{version}/connections/{connection}/activeTransactions. It is described in the GoldenGate REST API documentation.

The endpoint path parameters explain why the transactions shown in the output are not specific to the endpoint. In GoldenGate, a connection is database specific. Combine the domain name and the alias name with a dot separator to form the connection name. In my case, the connection name is OracleGoldenGate.source_cdb.

In Python, let’s see two ways of getting the same information:

• Using the production-ready Python client I presented in another blog.
• Using the requests library to call the REST API directly.

Using the Python client, you can just call the get_active_transactions method as follows:

from oggrestapi import OGGRestAPI

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

active_transactions = ogg_client.get_active_transactions('OracleGoldenGate.source_cdb')

>>> active_transactions
{'activeTransactions': [{'txnStartScn': 2704619209735, 'txnStatus': 'ACTIVE', 'txnStartDate': '2026-06-06T08:04:12.000Z', 'sid': 834, 'serialNum': 16450, 'instanceId': 1, 'userName': 'DBIBLOG', 'osUser': 'oracle', 'sessionStatus': 'INACTIVE', 'logonTime': '2026-06-06T08:04:11.456Z'}], 'currentScn': {'csn': 2704620465717, 'currentDate': '2026-06-06T08:27:45.717Z', 'userName': 'SYS'}, '$schema': 'ogg:activeTransactions'}

Otherwise, with the requests library, you can call the activeTransactions endpoint as follows:

import requests

connection_name = "OracleGoldenGate.source_cdb"
# Basic configuration
# Direct connection (no reverse proxy)
# url = f"https://vmogg:7809/services/v2/connections/{connection_name}/activeTransactions"
# NGINX reverse proxy
url = f"https://vmogg/services/ogg_test_01/adminsrvr/v2/connections/{connection_name}/activeTransactions"

auth = ("ogg", "ogg_password")
response = requests.get(
    url,
    auth=auth
)

Here is an example of the output that you should get when looking at the response.json() value:

>>> active_transactions = response.json()['response']
>>> active_transactions
{'activeTransactions': [{'txnStartScn': 2704619209735, 'txnStatus': 'ACTIVE', 'txnStartDate': '2026-06-06T08:04:12.000Z', 'sid': 834, 'serialNum': 16450, 'instanceId': 1, 'userName': 'DBIBLOG', 'osUser': 'oracle', 'sessionStatus': 'INACTIVE', 'logonTime': '2026-06-06T08:04:11.456Z'}], 'currentScn': {'csn': 2704620465717, 'currentDate': '2026-06-06T08:27:45.717Z', 'userName': 'SYS'}, '$schema': 'ogg:activeTransactions'}

Or using the json.dumps() method to get a more readable output:

>>> import json
>>> print(json.dumps(active_transactions, indent=4))
{
    "activeTransactions": [
        {
            "txnStartScn": 2704619209735,
            "txnStatus": "ACTIVE",
            "txnStartDate": "2026-06-06T08:04:12.000Z",
            "sid": 834,
            "serialNum": 16450,
            "instanceId": 1,
            "userName": "DBIBLOG",
            "osUser": "oracle",
            "sessionStatus": "INACTIVE",
            "logonTime": "2026-06-06T08:04:11.456Z"
        }
    ],
    "currentScn": {
        "csn": 2704620465717,
        "currentDate": "2026-06-06T08:27:45.717Z",
        "userName": "SYS"
    },
    "$schema": "ogg:activeTransactions"
}

Using the REST API, the information is more complete and easier to parse. As mentioned before, retrieving the SCN at which the transaction started is sometimes necessary. In that case, you can get it from the following command:

>>> start_scn = active_transactions['activeTransactions'][0]['txnStartScn']
>>> start_scn
2704619209735

If you have multiple long running transactions, you should retrieve the minimum value for the txnStartScn to be sure to get the SCN of the oldest long running transaction.

>>> start_scns = [txn['txnStartScn'] for txn in active_transactions['activeTransactions']]
>>> min(start_scns)
2704619209735

Now that we’ve retrieved the START_SCN of the long running transaction, we should check the checkpoint information.

Using the Python client, you can call the get_extract_checkpoint method as follows:

>>> extract_checkpoints = ogg_client.get_extract_checkpoint('EXT')
>>> extract_checkpoints
{'$schema': 'ogg:extractCheckpoints', 'current': {'input': [{'starting': {'timestamp': '2026-06-06T07:45:45.000Z', 'thread': 1, 'sequence': 0, 'offset': 0, 'csn': None, 'name': None}, 'recovery': {'timestamp': '2026-06-06T08:04:13.000Z', 'thread': 1, 'sequence': 48911, 'offset': 156909584, 'csn': 2704619209735, 'name': None}, 'current': {'timestamp': '2026-06-06T09:01:45.000Z', 'thread': 1, 'sequence': 0, 'offset': 0, 'csn': 2704620663027, 'name': None}, 'boundedRecoveryPrevious': {'timestamp': '2026-06-02 10:17:33.404Z', 'thread': 0, 'sequence': 0, 'offset': 0, 'csn': None, 'name': None}, 'boundedRecoveryBegin': {'timestamp': '2026-06-06T08:04:13.000Z', 'thread': 0, 'sequence': 48911, 'offset': 156909584, 'csn': 2704619209735, 'name': None}, 'boundedRecoveryEnd': {'timestamp': '2026-06-06T08:08:45.000Z', 'thread': 1, 'sequence': 48912, 'offset': 156918384, 'csn': 2704619308743, 'name': None}}]}

Or, using the requests library:

response = requests.get(
    "https://vmogg/services/ogg_test_01/adminsrvr/v2/extracts/EXT/checkpoint",
    auth=auth
)

extract_checkpoints = response.json()['response']

Here is a more readable output from the checkpoint information:

>>> print(json.dumps(extract_checkpoints, indent=4))
{
    "$schema": "ogg:extractCheckpoints",
    "current": {
        "input": [
            {
                "starting": {
                    "timestamp": "2026-06-06T07:45:45.000Z",
                    "thread": 1,
                    "sequence": 0,
                    "offset": 0,
                    "csn": null,
                    "name": null
                },
                "recovery": {
                    "timestamp": "2026-06-06T08:04:13.000Z",
                    "thread": 1,
                    "sequence": 48911,
                    "offset": 156909584,
                    "csn": 2704619209735,
                    "name": null
                },
                "current": {
                    "timestamp": "2026-06-06T09:01:45.000Z",
                    "thread": 1,
                    "sequence": 0,
                    "offset": 0,
                    "csn": 2704620663027,
                    "name": null
                },
                "boundedRecoveryPrevious": {
                    "timestamp": "2026-06-02T10:17:33.404Z",
                    "thread": 0,
                    "sequence": 0,
                    "offset": 0,
                    "csn": null,
                    "name": null
                },
                "boundedRecoveryBegin": {
                    "timestamp": "2026-06-06T08:04:13.000Z",
                    "thread": 0,
                    "sequence": 48911,
                    "offset": 156909584,
                    "csn": 2704619209735,
                    "name": null
                },
                "boundedRecoveryEnd": {
                    "timestamp": "2026-06-06T08:08:45.000Z",
                    "thread": 1,
                    "sequence": 48912,
                    "offset": 156918384,
                    "csn": 2704619308743,
                    "name": null
                }
            }
        ]
    }
}

And to finish with, from the json, you can retrieve the SCN of the recovery checkpoint:

>>> recovery_checkpoint_scn = extract_checkpoints['current']['input'][0]['recovery']['csn']
>>> recovery_checkpoint_scn
2704619209735

Whether it’s to rename or move an extract, you now know why you should check long running transactions in GoldenGate, and how to do it from the adminclient and the REST API.

L’article Checking Long Running Transactions in GoldenGate est apparu en premier sur dbi Blog.

In this GoldenGate upgrade, the previous driver was version 11.1 and the target version was 12.1. After installing the new driver, db2cli execsql commands that previously worked started failing with the following error:

db2cli execsql -db <database_alias> -user <username> -passwd <password> \
  -inputsql /home/oracle/input.sql

Where /home/oracle/input.sql just contains a trivial test query:

select 1 from sysibm.sysdummy1;

The sysibm.sysdummy1 table is DB2’s equivalent of Oracle’s DUAL, so this is about the simplest query you can run to check connectivity. It failed with the following error:

SQLError: 1 = 0 (SQL_SUCCESS)
SQLGetDiagRec: SQLState : 42968
NativeError : -1598
DiagMsg: [IBM][CLI Driver] SQL1598N An attempt to connect to the database server failed because of a licensing problem. SQLSTATE=42968

What SQL1598N means

SQL1598N means the DB2 client does not have a valid license to connect to this database. The CLI driver loaded fine. But when it tried to establish an authenticated connection the server rejected it on licensing grounds.

This is distinct from a connection failure or an authentication failure.

Root cause

It might not be obvious for Oracle-accustomed DBAs, but the DB2 CLI Driver does not ship with a license file for connecting to DB2 for z/OS. A separate license file named db2consv_zs.lic must be placed manually in the clidriver/license/ directory of the driver installation.

The critical point is that the license file is version-specific and cannot be reused across driver versions. The license file that worked with driver 11.1 is not valid for driver 12.1. After upgrading the driver, the new installation directory does not contain the license file in the license/ folder, and copying the old license file into it will not resolve the error.

Observed behavior

The error was reproducible every time the same command was run against the new driver. For reference, a successful run against a properly licensed driver returns:

FetchAll: Columns: 1
1
1
FetchAll: 1 rows fetched.

License file location

It is important to keep in mind that the license file belongs in the license/ subdirectory of the CLI driver installation. With CLI driver 11.1, the path looked like:

/opt/ibm/db2_odbc_cli_11_1/clidriver/license/db2consv_zs.lic

After upgrading to 12.1, the new driver has its own separate installation directory with its own license/ subdirectory. Placing the old 11.1 license file there will not work – the file is tied to the driver version.

How to fix the issue ?

Since the old file is unusable, you must obtain a new license file matching the installed driver version from IBM. Essentially, you have two options here:

• Contact your DB2 engineers: if someone on the team manages IBM software licenses, they should be able to provide the correct db2consv_zs.lic for the version you installed.
• Open a case with IBM customer support: IBM will provide the appropriate license file for the new driver version.

Once you have the correct file, place it in the clidriver/license/ directory of the new driver installation and retry the same db2cli execsql command given above. No restart is required.

DB2 CLI drivers are not that complicated to use and to debug. However, there are a few fundamentals that GoldenGate administrators should know before attempting a migration. Renewing the license file is one of them.

L’article DB2 SQL1598N Licensing Error When Upgrading GoldenGate est apparu en premier sur dbi Blog.

The client’s GoldenGate extract was running on a dedicated server, capturing changes from an Oracle 19c source database. Trail files were written on an NFS. Depending on the configuration, this is officially supported by Oracle, and works rather well.

OGG-02897 / OGG-01668 Input/Output Error

On a Monday morning, however, the extract was ABENDED. The extract had been down since Saturday night, with the following error messages:

2026-06-07T00:19:11.404+0200  ERROR   OGG-02897  Oracle GoldenGate Capture for Oracle, EXT.prm:  Failed to synchronize trail file. Error detail: Could not sync "PDB1/aa000000009" (error 5, Input/output error).
2026-06-07T00:19:11.404+0200  ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, EXT.prm:  PROCESS ABENDING.

The extract was failing with an OGG-02897 error. The OS-level error, errno 5: Input/output error, did not seem to indicate any good news for us. Needless to say that restarting the extract did not fix the issue.

Root Cause Analysis

A firewall upgrade had taken place that Saturday night. The firewall between the GoldenGate server and the NFS server was upgraded, and it briefly went down during the operation.

The real problem was what happened after the firewall came back up: some extracts caught up and managed to restart properly, while other were left in this ABENDED state, unable to restart. For these extracts, I/O operations kept failing even though the network path was healthy again.

Solution: Remount the NFS

The solution was to stop all GoldenGate processes whose trail files were generated on the NFS, including all the processes which were running fine, and then unmount and remount the NFS filesystem.

# Unmount the NFS path
umount /path/to/nfs

# Remount all filesystems defined in /etc/fstab, including the NFS
mount -a

Once that came back up, I restarted the extracts from the adminclient and they all started successfully.

In this case, the firewall upgrade happened during the night with no GoldenGate-aware procedure in place. Next time, a scheduled GoldenGate maintenance spanning over the firewall upgrade window will probably avoid crashing multiple replications during the week-end, or worse.

L’article GoldenGate Extract Abending on NFS Trail: OGG-02897 / OGG-01668 Input/Output Error est apparu en premier sur dbi Blog.

What is OpenID Connect (OIDC) ?

OpenID Connect (OIDC) is an authentication protocol built on top of the OAuth 2.0 framework. It allows clients (like mongosh) to check the identity of the user based on the authentication performed by an authorization server (like Okta). It also provides a standardized way of obtaining user profile information, resolving the authorization part of the connection.

OIDC use cases in MongoDB

MongoDB supports OIDC authentication for both:

• Users : Workforce Identity Federation
• Applications : Workload Identity Federation

In this blog, I will focus on the first use case.

Prerequisites

Before setting up OIDC authentication for MongoDB, you will need the following:

• MongoDB Enterprise Edition. OIDC authentication is only available in the Enterprise Edition of MongoDB. Alternatively, you can use Percona Server for MongoDB, which also supports OIDC authentication.
• Version 7.0.11 or later of MongoDB.
• A working Okta tenant. A 30-day trial can be obtained here.

Throughout this blog, I will use very generic names (dbiapp, dbiauth, etc.) to make sure you are not missing on configuration aspects. Some of these names will be used when configuring OIDC in MongoDB.

Configure OIDC in Okta

Create an application in Okta

Start by creating an application in Okta. From the Admin Console (available at https://trial-1234567-admin.okta.com/admin/dashboard), navigate to Applications > Applications and click on Create App Integration. Then, select OIDC – OpenID Connect as the sign-in method and Native as the application type. Click on Next.

Configuring the application

In the application configuration screen, fill in an application name (mine will be called dbiapp), and select Grant types among these three choices:

• Authorization Code: Activated by default, cannot be deactivated.
• Device Authorization: Required if you have no browser access when using mongosh. The shell will display a URL with which you will authenticate.
• Refresh Token: If enabled, the MongoDB driver caches the refresh token and renews the access token when it expires.

Then fill in the Sign-in redirect URIs with the following URL : http://localhost:27097/redirect

Finally, in the Assignments section, you can choose between multiple Controlled access options:

• Allow everyone in your organization to access
• Limit access to selected groups
• Skip group assignment for now

In this blog, I will choose Allow everyone in your organization to access. In production environments, you might choose something else. Make sure Enable immediate access with Federation Broker Mode is enabled, and click on Save.

You should now land on the newly created application page. Copy the Client ID displayed on the screen, you will need it later.

Authorization server configuration

In the navigation panel, click on Security > API, and Add Authorization Server.

Choose a name for the Authorization Server (mine will be named dbiauth), and paste the Client ID retrieved earlier in the Audience field.

From the newly created authorization server, copy the Issuer Metadata URI, from https until .well-known (excluded). You should have something like https://trial-1234567.okta.com/oauth2/aus27qkm93wcRptbz412.

Add a group claim

Staying on the authorization server summary, click on the Claims tab, and then on Add Claim.

You can choose any name for the claim. I will call it dbiclaim. The rest of the claim should be configured as follows, with the Filter set to Matches regex, using .* as filter.

WARNING: Make sure the filter is .*, not *.* or *. ! Otherwise, it could lead to MongoServerError: Authentication failed. errors.

Configure an access policy

Now, in the Access Policies tab of the authorization server, click on Add Policy.

You can choose the name of the policy that you want (mine is called dbipolicy), and you must add a Description. Set Assign to to All clients.

After creating the policy, click on Add rule.

This is the part where you should be customizing the rule based on your internal security policies. I will name my rule dbirule, and keep everything default except for the Refresh token lifetime, which is set to Unlimited.

Create a group and a user

If you already use Okta, you should have existing groups and users. But for the purpose of the blog, let’s create a group and a user. Navigate on the left to Directory > Groups, and click on Add Group.

MongoDB names the group OIDC, without stating whether it is the only name supported or not. But you can choose your own name. I will call the group dbigroup.

After creating the group, add a user in the Directory > People section, clicking on Add Person.

There are two important aspects here:

• Use an email for the Username field.
• Add the dbigroup group to the Groups.

Before continuing, make sure the user is activated following the procedure received by email

Configure MongoDB for OIDC authentication

Stop your MongoDB 7.0.11+ Enterprise Edition instance, and edit the configuration file by adding the following setParameter section:

• authenticationMechanisms: set it to MONGODB-OIDC if you want to enable only OIDC authentication, or MONGODB-OIDC,SCRAM-SHA-256 if you want to keep authentication with password for previous users.
• issuer: use the Issuer Metadata URI copied after creating the authorization server (https://trial-1234567.okta.com/oauth2/aus27qkm93wcRptbz412)
• audience and clientId: for both fields, use the Client ID associated with the application created at the very beginning (0oa89cvj16d4WFKrX307, for instance)
• authNamePrefix: okta-issuer
• authorizationClaim: use the name of the claim created on the authorization server. In my case, it is dbiclaim.

# Paste this at the end of your MongoDB configuration file
setParameter:
   authenticationMechanisms: "MONGODB-OIDC"
   oidcIdentityProviders: '[ {
      "issuer": "https://trial-1234567.okta.com/oauth2/aus27qkm93wcRptbz412",
      "audience": "0oa89cvj16d4WFKrX307",
      "authNamePrefix": "okta-issuer",
      "authorizationClaim": "dbiclaim",
      "clientId": "0oa89cvj16d4WFKrX307"
   } ]'

After changing the configuration file, you can restart your MongoDB instance. If security.authorization is not enabled yet, you should set it now and make sure you have a user able to create roles.

Log in with a privileged user to your MongoDB instance, and create a new role for OIDC authentication. The role name should be based on authNamePrefix (okta-issuer) and the group name (dbigroup). In this blog, I will create the okta-issuer/dbigroup role.

use admin
db.createRole( {
   role: "okta-issuer/dbigroup",
   privileges: [ ],
   roles: [ "readWriteAnyDatabase" ]
} )

Now, any member of the dbigroup group should be able to log in with mongosh or any other connection tool, with the following parameters:

• --authenticationMechanism flag set to MONGODB-OIDC. This parameter value is the official MongoDB parameter.
• --oidcFlows flag set to device-auth. This can be used in environments where mongosh will not be able to launch a browser.

# Change the MONGO_URI accordingly
MONGO_URI="mongodb://127.0.0.1:27017"
mongosh "$MONGO_URI" --authenticationMechanism MONGODB-OIDC --oidcFlows=device-auth

After a few seconds, you will receive the URL to complete authentication:

mongodb@mongodb-lab-01:/home/mongodb/ [mdb02] mongosh "$MONGO_URI" --authenticationMechanism MONGODB-OIDC --oidcFlows=device-auth
Current Mongosh Log ID:	6a64a98717240b2e9d9df8a2
Connecting to:		mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&authMechanism=MONGODB-OIDC&appName=mongosh+2.9.2

Visit the following URL to complete authentication: https://trial-1234567.okta.com/activate
Enter the following code on that page: RQXFMWTF
Waiting...

You can now open the link given (https://trial-1234567.okta.com/activate), and it will ask for the activation code (RQXFMWTF).

Once the device is activated, the mongosh prompt will succeed:

mongodb@mongodb-lab-01:/home/mongodb/ [mdb02] mongosh "$MONGO_URI" --authenticationMechanism MONGODB-OIDC --oidcFlows=device-auth
Current Mongosh Log ID:	6a64a98717240b2e9d9df8a2
Connecting to:		mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&authMechanism=MONGODB-OIDC&appName=mongosh+2.9.2

Visit the following URL to complete authentication: https://trial-1234567.okta.com/activate
Enter the following code on that page: RQXFMWTF
Waiting...
Using MongoDB:		8.0.26
Using Mongosh:		2.9.2

Enterprise test>

And if you run the db.runCommand({connectionStatus:1}) command, you will see the OIDC connection information:

Enterprise test> db.runCommand({connectionStatus:1})
{
  authInfo: {
    authenticatedUsers: [ { user: 'okta-issuer/dbiblog@dbi-services.com', db: '$external' } ],
    authenticatedUserRoles: [
      { role: 'okta-issuer/Everyone', db: 'admin' },
      { role: 'okta-issuer/dbigroup', db: 'admin' },
      { role: 'readWriteAnyDatabase', db: 'admin' }
    ]
  },
  ok: 1
}

Adapt DMK to work with OIDC

If you use the MongoDB DMK, you should either adapt the msp alias or create a new msoidc alias to connect to your instances. To do so, edit the local configuration file of DMK with the dmkl alias:

# Option 1: change the msp alias
alias::msp::novar_noforce::'ms --authenticationMechanism MONGODB-OIDC --oidcFlows=device-auth'::

# Option 2: add a new msoidc alias
alias::msoidc::novar_noforce::'ms --authenticationMechanism MONGODB-OIDC --oidcFlows=device-auth'::

L’article MongoDB OIDC Authentication with Okta est apparu en premier sur dbi Blog.

Bug 39415027: Generic – Simplified Distribution and Receiver Service Path Configuration

Enhanced the Create Distribution and Receiver Service Paths experience by introducing Simple and Advanced configuration modes. The simplified view displays only the required settings by default, while advanced options remain available for users who need additional configuration.

Anyone who has created a distribution path from the web UI knows the form used to be long. I already walked through the full setup in a previous blog on distribution paths in NGINX-secured deployments. This enhancement simplifies the creation form for most common use cases.

In this blog, I want to look at what changes: first in the web UI, then what the hidden fields default to, and finally whether anything changes at the REST API level.

What changes in the web UI

This enhancement is in fact two separate changes, shipped together.

First, the form collapsed to a single step. In 23.26.2 and earlier version of GoldenGate, creating a path was a six-step process: Path Information, Source Options, Target Options, Advanced Options, Filtering Options and Managed Options.

Starting with 23.26.3.0.0, these steps are gone. Instead, there are now only two steps: a configuration page, and a review page. Most of what used to be spread across the six screens now lives on the first page; the rest (the managed, format and network tuning options) moved onto the Review page, which is interactive rather than a read-only summary.

The second change is that this single page has a Default / Advanced toggle. This is the part the release notes mention:

Default mode: only the required settings are displayed, like path name, source (extract and trail) and target (host, port, protocol and target trail).

Advanced mode: the same single page, but every optional field is revealed: air gap security, trail file size, target type, HPE NonStop toggle, format options and network options. The reverse proxy toggle, encryption and filtering checkboxes are present in both modes (see below).

Switching to Advanced in 23.26.3 does not bring back the six steps. It stays on one page, revealing the hidden fields. Here are the two forms:

NB: The same Default / Advanced mechanism applies to the Receiver Service path creation form.

What do the hidden fields default to?

When Default mode hides a field, nothing is left blank. GoldenGate will silently apply a default value when calling the REST API. Knowing these defaults will help you decide whether to use the Default or the Advanced mode. Here is the list of what Advanced mode reveals.

So a path created in Default mode always gets a 2000 MB trail, no air gap security, and (for an ogg target) a Manager target type. If any of those needs to change, you should switch to Advanced mode.

The Review step carries the managed and tuning options

The second step (Review) is not a read-only summary. It always shows a summary of the path and an editable Managed Options section. In Advanced mode, it also shows Format options and a large Network Options section. The Default/Advanced mode toggle also changes what you see here:

To summarize, auto restart is on by default (10 retries, 2 minute delay) and you can adjust it without leaving Default mode. The network tuning parameters (compression, EOF delay, DSCP / TOS, TCP flags, socket buffers) keep their usual defaults unless you switch to Advanced mode and change them.

Default mode does not mean no security

The distribution path creation form is also adapted to the protocol you choose. Selecting the Target Protocol changes which fields appear, in both modes:

• ogg is the classic mode, without authentication fields. Advanced adds the Target Type and the HPE NonStop toggle.
• ws and wss: both add a reverse proxy toggle (disabled by default) and a Target Authentication Method: Certificate is the pre-selected value for wss. Switching to UserID Alias shows Domain: Network (greyed out, not editable) and an Alias dropdown (the same reserved Network domain used for path connection credentials).

Since GoldenGate 26ai, the default for trail file size is no longer 500 MB but 2000 MB. If you are fine with a 2000 MB trail, no air gap, a Manager target (for ogg protocol), and the default auto restart behaviour, you can keep the default mode. Switch to Advanced when you want a different trail size, air gap setup, a Collector or Receiver Service target, HPE NonStop, a specific target format, or any of the network tuning options.

Nothing changes in GoldenGate REST API

The Default / Advanced switch is purely a web UI convenience. It changes which fields the form renders, not what GoldenGate stores or how you create a path programmatically. The REST endpoints are unchanged:

If you automate distribution path creation (I will publish a blog about this soon) in your environments, nothing changes. The payload you send is identical before and after patching to 23.26.3.0.0.

From a web UI perspective, paths are created with the exact same payloads in Default and Advanced mode. For instance, I created one path from the web UI in Default mode (DEFPATH) and an equivalent one in Advanced mode (ADVPATH), with the same source and target, as well as every optional field left at its pre-filled value. Analyzing the restapi.log files, here is the content of the payload:

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

Captured DEFPATH (Default mode), POST /services/v2/sources/DEFPATH:

{
  "name": "DEFPATH",
  "status": "stopped",
  "source": {
    "uri": "trail://localhost:7811/services/v2/sources?trail=e1",
    "details": {}
  },
  "target": {
    "isDynamicOggPort": true,
    "uri": "ogg://vmogg2:7812/services/v2/targets?trail=ea",
    "details": {
      "trail": { "seqLength": 9, "sizeMB": 2000 },
      "compression": { "enabled": false }
    }
  },
  "options": {
    "eofDelayCSecs": 10,
    "checkpointFrequency": 10,
    "critical": false,
    "autoRestart": { "retries": 10, "delay": 2 },
    "streaming": true
  },
  "begin": { "sequence": 0, "offset": 0 }
}

Captured ADVPATH (Advanced mode), POST /services/v2/sources/ADVPATH:

{
  "name": "ADVPATH",
  "status": "stopped",
  "source": {
    "uri": "trail://localhost:7811/services/v2/sources?trail=e1",
    "details": {}
  },
  "target": {
    "isDynamicOggPort": true,
    "uri": "ogg://vmogg2:7812/services/v2/targets?trail=eb",
    "details": {
      "trail": { "seqLength": 9, "sizeMB": 2000 },
      "compression": { "enabled": false }
    }
  },
  "options": {
    "eofDelayCSecs": 10,
    "checkpointFrequency": 10,
    "critical": false,
    "autoRestart": { "retries": 10, "delay": 2 },
    "streaming": true
  },
  "begin": { "sequence": 0, "offset": 0 }
}

The two bodies differ only in name and the target trail letter. Every optional key that Default mode is supposed to “hide” (sizeMB, seqLength, compression.enabled, eofDelayCSecs, checkpointFrequency, critical, autoRestart, streaming) is sent explicitly by both modes, with the same value.

If you work mostly from the web UI and create paths by hand, the new form will help you. And if you automate with the REST API, this enhancement does not affect you at all. Your existing calls keep working exactly as before, and you were already, in effect, in “advanced mode” because you send whatever properties you choose.

L’article Simplified Distribution Path Creation in GoldenGate 26.3 est apparu en premier sur dbi Blog.