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.

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.5.0

Sharding support

The biggest addition in DMK 2.5.0 is full sharding support. DMK can now create, start, stop, restart, and display the status of every component of a sharded MongoDB cluster: config server replica sets, shard replica sets, and mongos routers.

Internally, instance management was refactored into a class hierarchy: a MongoInstance base class handles what is common to all MongoDB processes (URI construction, mongosh command execution, status gathering), and MongodInstance / MongosInstance extend it for their respective types. From a day-to-day usage perspective, this is transparent: you use the same dmk_db_ctl.py and dmk_status.py commands for all instance types.

A few behaviours are specific to mongos: stopping a mongos router uses SIGTERM instead of the --shutdown command (which mongos does not support), and trying to back up a mongos instance now raises an explicit error, since mongos processes hold no data. In a sharded configuration, the underlying shards should be backed up instead.

New configuration templates for each sharding component type are available in $DMK_HOME/templates/dbcreate/, in both forked (no systemd) and non-forked (systemd-managed) variants. A dedicated systemd unit file template (mongos.service.template) was also added for mongos routers.

Three new generic JavaScript scripts in $DMK_HOME/js/ handle the initialization steps:

• csrs_initiate.js — initiate a config server replica set
• rs_initiate.js (updated) — initiate a shard or standalone replica set, now with optional arbiter support
• sh_addshards.js — register shards in the cluster via a mongos router

All three receive their parameters via the mongosh --eval flag, keeping them reusable across any cluster topology:

# Initiate the config server replica set
mongosh 127.0.0.1:27017 \
  --eval "var rsName='csrs'; var rsHosts=['127.0.0.1:27017','127.0.0.1:27018','127.0.0.1:27019'];" \
  $DMK_HOME/js/csrs_initiate.js

# Initiate shard 1 with an arbiter
mongosh 127.0.0.1:27020 \
  --eval "var rsName='rs1'; var rsHosts=['127.0.0.1:27020','127.0.0.1:27021']; var arbiterHost='127.0.0.1:27022';" \
  $DMK_HOME/js/rs_initiate.js

# Add all shards from a mongos router
mongosh 127.0.0.1:27030 \
  --eval "var shards=['rs1/127.0.0.1:27020,127.0.0.1:27021','rs2/127.0.0.1:27023,127.0.0.1:27024','rs3/127.0.0.1:27026,127.0.0.1:27027'];" \
  $DMK_HOME/js/sh_addshards.js

New --check-status option in dmk_db_ctl.py

The dmk_db_ctl.py script now accepts a --check-status flag. When provided, it polls the instance after the start, stop, or restart command to confirm the instance has reached the expected state. This was the default behaviour until now, which led to unwanted errors when setting up DMK.

dmk_db_ctl.py -i mdb01 -a start --check-status
dmk_db_ctl.py -i mdb01 -a stop --check-status
dmk_db_ctl.py -i mdb01 -a restart --check-status

Without this flag, the script returns immediately after issuing the command. It should be noted that when using the restart option, the status will be checked after stopping the instance. Otherwise, if the instance is still running when the start was issued, the restart could silently succeed without actually restarting anything.

Changes made to dmk_status.py

Colored status output. STARTED is now displayed in green, STOPPED in red — making it easier to spot unhealthy instances at a glance. To disable colors (for log files, CI pipelines, or terminals that don’t support ANSI), set COLORED_STATUS=no in your local configuration file (dmkl) by uncommenting the following line:

# var::COLORED_STATUS::=::nowarn::no::  # Disable colored status output in dmk_status.py (yes/no)

CSV output. The table view now supports CSV export via the --csv option, useful for piping output to other tools or exporting to a file:

# Export status as semicolon-delimited CSV
> dmk_status.py -t -a --csv ";"
Instance;Status;Version;Port;Bind IPs
mdb01;STARTED;8.0.26;27417;127.0.0.1
mdb02;STARTED;8.0.26;27418;127.0.0.1
mdbcfg01;STARTED;8.0.26;27017;127.0.0.1
mdbmgs01;STARTED;8.0.26;27030;127.0.0.1

The session view (sess) supports the same option.

Process-only check. The new -p / --process option performs a quick process presence check without connecting to MongoDB. This is faster and does not require credentials, making it useful for lightweight health checks:

dmk_status.py -t -a --process

Improved version display. The -mv option now shows all installed MongoDB versions side by side in a single table instead of separate blocks, making it much easier to compare binary versions across multiple installations.

Session display refactoring. Session data gathering was moved into the instance class, and the display logic (including filtering and formatting) was centralized in dmk_status.py. This also fixes the --include-inactive flag, which was not working correctly in the previous release.

New update_mongo_conf.py script

The new update_mongo_conf.py script modifies MongoDB configuration file parameters from the command line using dot-notation for nested keys, without manually editing YAML:

# Enable TLS on an existing instance
update_mongo_conf.py mdb01 net.tls.mode requireTLS
update_mongo_conf.py mdb01 net.tls.certificateKeyFile /u01/app/mongodb/admin/mdb01/secret/server.pem

New set_uri.py script

The new set_uri.py script generates and persists a MONGO_URI in the local DMK configuration for a given instance. It supports both standalone and replica set connection strings:

# Standalone
set_uri.py mdb01 sa 127.0.0.1:27017

# Replica set
set_uri.py mdbrs01 rs 127.0.0.1:27411,127.0.0.1:27412,127.0.0.1:27413 rs1

The resulting URI is stored in the local configuration file and available as $MONGO_URI in the instance context.

Improvements to dmk_dbcreate.py

dmk_dbcreate.py now reads the [instance_name] section from the local DMK configuration file when creating an instance, so instance-specific variables defined in your local config are picked up automatically. Empty values for MONGO_BACKUP, MONGO_JOURNAL, and MONGO_LOG are also now accepted — directories are only created for paths that are explicitly set.

The storageEngine key was removed from all YAML configuration templates. WiredTiger is the only storage engine available in MongoDB Community Edition, making the field redundant.

A new mongod.service.template_fork systemd unit (Type=simple, delegating start/stop to dmk_db_ctl.py) was also added, alongside the existing mongod.service.template that runs mongod in the foreground. dmk_dbcreate.py generates the mongod unit for mongod instances and the mongos unit for routers.

Installation improvements

Auto-creation of .bash_profile. If the .bash_profile of the mongodb user does not contain the DMK block, DMK now creates it automatically from the template on first sourcing. If the file already exists with a DMK block, only that block is updated in place (with a backup created first). This removes a manual step from first-time installation.

DMK temp files. The dmk_env.sh file used to source instance environments is now written to $DMK_HOME/tmp/ rather than /tmp, keeping temporary DMK files within the DMK directory tree.

Security improvements

The default bindIp in all DMK configuration templates was changed from 0.0.0.0 to 127.0.0.1. This is a safer default for freshly created instances that limits network exposure from the start.

A new MONGO_TLS_CERTIFICATE_KEY_FILE environment variable allows specifying a custom client certificate for DMK connections. This is useful for instances secured with serverAuth-only TLS, where the default certificate path may not be the right client certificate to use.

New TLS templates for replica sets (mongo_conf_rs_tls.yaml, mongo_conf_rs_tls_fork.yaml, mongo_conf_rs_keyfile.yaml) were also added.

Aliases and environment variables added in DMK 2.5.0

New aliases in DMK 2.5.0:

• mglogrotate: rotate the MongoDB log file (db.adminCommand({ logRotate: 1 })).
• certrotate: rotate the TLS certificate of an instance (db.rotateCertificates()).

New environment variables:

• COLORED_STATUS: set to no to disable colored status output in dmk_status.py. Enabled by default.
• MONGO_TLS_CERTIFICATE_KEY_FILE: custom client TLS certificate path for DMK connections.
• MONGO_URI: the MongoDB connection URI, now easily managed with set_uri.py.
• INSTANCE_NAMING_CONVENTION: the regular expression used to validate instance names. This variable is now optional — if not set, no naming convention is enforced.

Bug fixes

A few notable bugs were fixed in this release:

• Quoted values in the MongoDB configuration file (viewed with vic / dmkc) could cause the DMK environment to fail loading due to unescaped double quotes. This is now handled correctly.
• Restart could silently succeed without actually restarting the instance if it was still running. The stop phase now always waits for the instance to be fully stopped first.
• --include-inactive flag in the session view was not working correctly and has been fixed.

Upgrading from an earlier version of DMK

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

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

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

L’article MongoDB DMK 2.5.0: Sharding support and new features est apparu en premier sur dbi Blog.

The client had two GoldenGate 26ai installations running on the same server.

• One extracting data from DB2, with GoldenGate for DB2/zOS.
• One replicating into an Oracle 19c database, reading from the same trail files.

Both setups were using the initial release of GoldenGate 26ai.

On both, I tried to set up trail purge tasks from the Administration Service web UI, and both GoldenGate trail purge failed with the same error.

Purge task creation from the web UI

To add a purge task, go to the Administration Service web UI, and on the left navigation panel, click on Tasks > Purge Trail.

From there, create a new task. You will be asked to provide a task name, one or multiple trail paths, retention rules, and whether to use checkpoints when purging trail files.

In my case, right after the creation, the purge task was failing with the OGG-12111 error. This happened no matter how I configured the task. The task was correctly configured, but it would fail every time it was scheduled to run

OGG-12111 in the web UI

The full error displayed was the following:

JSON element '/csn' does not match any schemas
Code: OGG-12111
Cause: The JSON item does not validate against the provided JSON schema.
Action: Correct the JSON so that it conforms to the JSON schema.

I first thought that it was a configuration issue on my side, but there is no such csn field when configuring the task. I quickly realized that if something was wrong, it was internal to GoldenGate. And unfortunately, all trail files were affected in this setup, so there was no working example to investigate further. On all other setups that I worked on, I never faced the OGG-12111 error.

Analysis of adminsrvr.log

Digging into the Administration Service log, I found the real error underneath:

2026-04-20T14:18:41.377+0200 ERROR| ERROR   OGG-01072  Oracle GoldenGate Administration Service for Oracle:  NUMCNV_getUnsignedNumFromStr: Buffer overflow, needed: 21, allocated: 20. (Purge)

OGG-01072 is a buffer overflow in an internal GoldenGate method. It looked like a corrupted value gets embedded into the purge task JSON, and the JSON fails schema validation. And in the end, you get the OGG-12111 error in the web UI.

OGG-12111 was just the symptom, while OGG-01072 was the actual bug.

Unfortunately, I couldn’t find any MOS bug filed for this. However, by trial and error, I discovered that the fix appears to have been introduced silently in a later patch, maybe through another bug resolution (that I could not identify).

How to solve OGG-12111 errors in GoldenGate 26ai ?

The only solution I found was patching GoldenGate to 23.26.2.0.1. I didn’t test the intermediate patch levels between 23.26.1.0.0 and 23.26.2.0.1, so I can’t say exactly which patch introduced the fix, but upgrading to 23.26.2.0.1 resolved the issue.

After patching, I went back to the Purge Trail section of the web UI, and the existing purge tasks were already working. I did not even have to recreate them.

So if you face this bug and your GoldenGate trail purge fails, don’t spend time reviewing the purge task parameters. Your tasks are most probably fine. The bug is inside the Administration Service’s numeric conversion method, and patching is the only way out.

L’article GoldenGate Trail Purge Task Fails with “OGG-12111: JSON element ‘/csn’ does not match any schemas” est apparu en premier sur dbi Blog.

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

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

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

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

And here is the replicat parameter file:

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

First test : simple table with primary key

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

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

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

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

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

You will see the same content in both tables.

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

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

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

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

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

Checking the tables will give you the updated data.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Third test : Table with no PK and a CLOB column

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sometimes, the line with LOB_1 will be deleted:

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

But sometimes, the line with LOB_2 will be deleted:

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

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

DROP TABLE app_source.test_clob PURGE;

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

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

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

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

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

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

DROP TABLE app_source.test_clob PURGE;

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

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

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

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

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

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

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

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

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

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

Here is an example of the content of the view:

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

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

First case – bad_column = 'N'

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

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

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

Second case – bad_column = 'Y'

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

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

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

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

Will there be an error if GoldenGate cannot identify uniqueness ?

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

What can be done to solve these issues ?

Essentially, there are four possible approaches:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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