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

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

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

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

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

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

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

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

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

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

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

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

restapi.log analysis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How to recreate a GoldenGate user with the REST API ?

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

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

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

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

L’article The undocumented GoldenGate ‘all’ role you should know about est apparu en premier sur dbi Blog.

When patching a GoldenGate installation and restarting it, we had the following error with the credential store: OGG-30555 Timeout waiting for credential store wallet upgrade. The patching corrupted GoldenGate credential store.

NB: You can apply the same method if you encounter the following error: OGG-03556 Auto-login wallet conversion failed. Error: 29,105.

GGSCI (vmogg) 1> info credentialstore

Reading from credential store:

Source Context
  SourceModule            : [ggsec.CCredentialStore]
  SourcelD                : [ggsec/CCredentialStore.cpp]
  SourceMethod            : [load]
  SourceLine              : [352]
  ThreadBacktrace         : [15]
...
                          : [/lib64/1ibc.so.6(__libc_start_main)]
                          : [./ggsci()]

2026-02-12 14:49:32 ERROR   OGG-30555  Timeout waiting for credential store wallet upgrade.

2026-02-12 14:49:32 ERROR   OGG-01668  PROCESS ABENDING.

I tried rolling back the patch, and the credential store was accessible. Applying the patch did break something, but how to solve this ?

If you encounter this error, you have three possibilities:

• If you are in a hurry, just roll back the patch. Whenever I had this issue, rolling back the patch corrected the issue. After rolling back, I had access to the credential store again. This is just a temporary workaround, of course, but it’s better than stopping all your replication processes. For this specific patch, you can do it with opatch rollback -id 38781237
• If you have the time, contact the Oracle Support. There might be a bigger problem here.
• Sometimes, recreating the credential store is the only solution.

We will focus on the third option here, trying to rebuild the credential store. But of course, if you cannot access the credential store, it is hard to know what needs to be recreated. This is why you should always make a backup of the credential store before patching ! In our case, rolling back the patch gave back access to the credential store, so I could retrieve the entries.

But because I was tired of encountering this issue, I made this script that will generate the instructions to recreate the credential store in case you have an issue when patching.

#!/bin/bash

OGG_HOME="/u01/app/oracle/product/ogg"
GGSCI="$OGG_HOME/ggsci"
domain="${1:-OracleGoldenGate}"
DEBUG="${DEBUG:-0}"

log() {
    [ "$DEBUG" -eq 1 ] && printf '%s\n' "$*" >&2
}

log "Processing domain: $domain"
log "Running: info credentialstore domain $domain"

domain_output="$(
    "$GGSCI" <<EOF
info credentialstore domain $domain
EOF
)"

log "Raw output:"
log "$domain_output"

commands="$(
    awk -v dom="$domain" '
    /Alias:/ {
        alias = $2
        getline
        if ($1 == "Userid:") {
            user = $2
            printf "alter credentialstore add user %s alias %s domain %s\n",
                   user, alias, dom
        }
    }' <<< "$domain_output"
)"

if [[ -n "$commands" ]]; then
    printf '%s\n' "$commands"
else
    log "No aliases found in domain $domain"
fi

You just have to run the script to get the credential store recreation instructions. If you have one or more custom domains in your credential store, run the script with the custom domain as an argument.

> ./recreate_credentialstore.sh
alter credentialstore add user ggadmin@DB01.WORLD alias db01 domain OracleGoldenGate
alter credentialstore add user ggadmin@DB02.WORLD alias db02 domain OracleGoldenGate
alter credentialstore add user ggadmin@DB03.WORLD alias db03 domain OracleGoldenGate
alter credentialstore add user ggadmin@DB04.WORLD alias db04 domain OracleGoldenGate

Or with a custom domain:

> ./recreate_credentialstore.sh CustomDomain
alter credentialstore add user ggadmin@DB99.WORLD alias db99 domain CustomDomain

Once you have this backup plan organized, to get rid of the OGG-30555 error after patching:

• Stop all GoldenGate processes
• Backup your credential store files. In the classic architecture, they are located in $OGG_HOME/dircrd
• Patch your GoldenGate setup
• Recreate the credential store with the following commands

GGSCI (vmogg) 1> drop credentialstore

Credential store deleted.

GGSCI (vmogg) 2> info credentialstore

Reading from credential store:

ERROR: Unable to open credential store.

GGSCI (vmogg) 3> add credentialstore

Credential store added.

GGSCI (vmogg) 4> alter credentialstore add user ggadmin@DB01.WORLD alias db01 password ***

Credential store altered.

GGSCI (vmogg) 5> info credentialstore

Reading from credential store:

Default domain: OracleGoldenGate

  Alias: db01
  Userid: ggadmin@DB01.WORLD

Make sure to integrate this in your GoldenGate patching strategy to avoid being surprised with a corrupted GoldenGate credential store ! And of course, this is also valid for GoldenGate 26ai.

L’article Save your credential store before patching GoldenGate ! est apparu en premier sur dbi Blog.