Let’s now talk about the INS-85038 error, which is rather generic. You will definitely need more details to investigate, and this blog does not cover all possibilities. Still, I will try to give you solutions, including one that should work in most cases.

As a reminder, there are three steps when deleting a GoldenGate deployment with oggca.sh :

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

In my case, the problem I noticed is that the configuration assistant waits for the deployment to be stopped. However, it fails after some time with the following error details:

Log of this session available at: /u01/app/oraInventory/logs/OGGCAConfigActions2026-04-22_12-51-46PM
Setup completed with overall status as Succeeded
Setup completed with overall status as Failed
Verification failed. Expected value: (NOT) 'running', actual value: 'running'
Verification (0) failed for property 'response/status'.
Verification failed for REST call to '/services/v2/deployments/ogg_test_blog'
Results for "Stop the deployment":
..."Retrieving the 'ogg_test_blog' deployment details.": SUCCEEDED
..."Stop the 'ogg_test_blog' deployment.": SUCCEEDED
..."Verify the 'ogg_test_blog' deployment is stopped": FAILED
(1) Errors ocurred when trying to stop deployment. Make sure Service Manager is running. Check Service Manager log files for more details.

However, when debugging this issue, I observed the following strange behavior. While the configuration assistant complains about the deployment being started, my deployment was stopped when checking its status a few seconds after.

I decided to analyze the restapi.log file of my deployment. What I discovered was that the configuration assistant was checking the status of the deployment every ten seconds for two minutes. After this period, it fails with the abovementioned error.

What to do after an INS-85038 error ?

If you still want to delete this deployment, you have two options:

• Deleting the deployment with the REST API, with the method described in this blog, using the dedicated endpoint.
• Restarting the deployment and re-running the configuration assistant. But this time, if you get the same error as before, remember to wait. Once the deployment is completely stopped, click on Skip in the configuration assistant. The assistant will follow with the next step, unregistering the deployment from the Service Manager.

To summarize, if you get an INS-85038 error in the configuration assistant, try to remove the deployment with the REST API. But if the reason for this error is just a deployment that is not stopping soon enough, just use the Skip button to continue removing the deployment when it is finally stopped.

L’article Deployment removal failed in GoldenGate Configuration Assistant (INS-85038) est apparu en premier sur dbi Blog.

If you are upgrading to GoldenGate 26ai and migrating from Classic to Microservices Architecture, you must re-discover GoldenGate targets in the Enterprise Manager. The discovery module settings vary from one setup to another, but for a GoldenGate deployment exposed via an NGINX reverse proxy, you should set up the discovery module with the following:

While this could be enough in some GoldenGate setups, it will fail if the certificate chain is not trusted by the OEM agent. In fact, if you run a discovery of your host with the settings mentioned above, no target will be discovered. This is especially tricky, since the Enterprise Manager will tell you “Discover Now – Completed Successfully“.

Open the ogg_so_logs.log.0 file in the agent_inst/sysman/emd directory of your target agent. You will see that the discovery has failed with the following error : INFO: Exception occured when tried with SSL deployment. SSLHandshakeException.

oracle@vmogg:~ [emagent] vim ogg_so_logs.log.0
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery createDiscovery
INFO: Discovery : Discovering Oracle Goldengate Instances . Discovery parameters values are , Port=443, UserName=ogg, HostName=vmogg, OGG Mode=Microservices, EMStateDir=/u01/app/oracle/agent_24ai/agent_inst
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery createDiscovery
INFO: Discovery :Target name prefix =oggtest:
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery createDiscovery
INFO: agentTrustLocation:/u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrl
INFO: Discovery : Invoking URL request :https://vmogg:443/services/v2/deployments
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrlForSSL
INFO: Trying to connect as a ssl connection https://vmogg:443/services/v2/deployments
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrlForSSL
INFO: SSLHandshakeException while getting response for URL:https://vmogg:443/services/v2/deployments . javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrl
INFO: Exception occured when tried with SSL deployment. SSLHandshakeException: Failed to connect to ssl Microservices . Retrying via non ssl microservices. Trying with http.
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery getJSONDataFromUrl
SEVERE: For the Url = http://vmogg:443/services/v2/deployments , HTTP/response error code = 307
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateMicroServicesDiscovery generateTargetsXML
SEVERE: Exception getting response from URL:https://vmogg:443/services/v2/deployments - com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery$GGDiscoveryException: Discovery failed : HTTP error code : 307 from URL:http://vmogg:443/services/v2/deployments
Apr 19, 2026 8:01:32 AM com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery main
SEVERE: Exception during Targets discovery: EM-90000 - Target Discovery failed. Internal Error. Please contact System Administrator. - com.oracle.sysman.goldengate.discovery.GoldenGateDiscovery$GGDiscoveryException: EM-90000 - Target Discovery failed. Internal Error. Please contact System Administrator.

The problem here is that the OEM agent does not trust the certificate chain being used in your GoldenGate installation. For the discovery (and the monitoring) to work, you need to register the certificates in the agent’s truststore.

Displaying the content of the truststore

First, let’s have a look at the content of the agent’s truststore. To do so, use the keytool utility shipped with the agent. Here is an example of a default AgentTrust.jks content. When prompted for the keystore password, use the configured truststore password (welcome, by default).

oracle@vmogg:~ [emagent] /u01/app/oracle/agent_24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/keytool -list -keystore /u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks
Enter keystore password:
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 9 entries

verisignclass1pca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 13:B8:4A:BA:EC:A3:DE:8C:71:9A:06:7D:E8:CF:18:5F:65:DC:19:E0:3E:BD:92:C2:0B:D3:8C:75:09:7B:E1:13
verisignclass3ca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): E7:68:56:34:EF:AC:F6:9A:CE:93:9A:6B:25:5B:7B:4F:AB:EF:42:93:5B:50:A2:65:AC:B5:CB:60:27:E4:4E:70
gtecybertrustglobalca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): A5:31:25:18:8D:21:10:AA:96:4B:02:C7:B7:C6:DA:32:03:17:08:94:E5:FB:71:FF:FB:66:67:D5:E6:81:0A:36
entrustsslca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 62:F2:40:27:8C:56:4C:4D:D8:BF:7D:9D:4F:6F:36:6E:A8:94:D2:2F:5F:34:D9:89:A9:83:AC:EC:2F:FF:ED:50
entrust2048ca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): D1:C3:39:EA:27:84:EB:87:0F:93:4F:C5:63:4E:4A:A9:AD:55:05:01:64:01:F2:64:65:D3:7A:57:46:63:35:9F
verisignserverca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 29:30:BD:09:A0:71:26:BD:C1:72:88:D4:F2:AD:84:64:5E:C9:48:60:79:07:A9:7B:5E:D0:B0:B0:58:79:EF:69
gtecybertrustca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 52:7B:05:05:27:DF:52:9C:0F:7A:D0:0C:EF:1E:7B:A4:21:78:81:82:61:5C:32:6C:8B:6D:1A:20:61:A0:BD:7C
entrustgsslca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): 2F:2F:87:02:A6:ED:EC:B6:46:92:94:BC:A0:40:F6:3B:88:49:42:1F:CE:E1:C3:7D:1C:FB:EE:89:DC:CD:43:83
verisignclass2ca, Oct 20, 2009, trustedCertEntry,
Certificate fingerprint (SHA-256): BD:46:9F:F4:5F:AA:E7:C5:4C:CB:D6:9D:3F:3B:00:22:55:D9:B0:6B:10:B1:D0:FA:38:8B:F9:6B:91:8B:2C:E9

Warning:
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1000-bit RSA key which is considered a security risk and is disabled.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.
uses a 1024-bit RSA key which is considered a security risk. This key size will be disabled in a future update.

Importing the certificate in the truststore

Let’s add the certificate in the agent’s truststore with the following command.

/u01/app/oracle/agent_24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/keytool -importcert -alias ogg_capath -file /path/to/ogg_certs/RootCA_cert.pem -keystore /u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks

If you are not sure which file you should add, keep in mind that it should be the same file you are using in the OGG_CLIENT_TLS_CAPATH environment variable when loading the GoldenGate environment and connecting to your deployments with the adminclient.

oracle@vmogg:~ [emagent] export OGG_CLIENT_TLS_CAPATH=/path/to/ogg_certs/RootCA_cert.pem
oracle@vmogg:~ [emagent] /u01/app/oracle/agent_24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/keytool -importcert -alias ogg_capath -file $OGG_CLIENT_TLS_CAPATH -keystore /u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks
Enter keystore password:
Owner: CN=OGG RootCA, O=OGG ROOT CA, C=AU
Issuer: CN=OGG RootCA, O=OGG ROOT CA, C=AU
Serial number: 1a11d06e7d73700aa85e35ffc0ce4a27dcfdaf7d
Valid from: Fri Mar 21 15:22:22 GMT 2026 until: Mon Mar 18 15:22:22 GMT 2036
Certificate fingerprints:
SHA1: 3C:99:5B:3A:D9:A4:64:6D:23:F0:0A:48:16:FA:AF:85:BD:26:E3:C7
SHA256: 8D:6F:1D:67:ED:D9:7B:C0:C8:0E:D1:0E:50:2F:15:25:45:5D:F2:1D:A2:AB:22:C7:2D:AE:05:19:F1:DE:28:31
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.35 Criticality=false

AuthorityKeyIdentifier [
KeyIdentifier [
0000: E3 BC BD 71 43 FD 85 B0 48 E1 44 A1 81 04 FA A9 …qC…H.D…..
0010: 1D 1C 45 16 ..E.
]
]

#2: ObjectId: 2.5.29.19 Criticality=true

BasicConstraints:[
CA:true
PathLen:2147483647
]

#3: ObjectId: 2.5.29.14 Criticality=false

SubjectKeyIdentifier [
KeyIdentifier [
0000: E3 BC BD 71 43 FD 85 B0 48 E1 44 A1 81 04 FA A9 …qC…H.D…..
0010: 1D 1C 45 16 ..E.
]
]

Trust this certificate? [no]: yes
Certificate was added to keystore

If you check the content of the keystore again, you will see the new entry under the alias you just added. We will use the -alias ogg_capath option to only display the new alias.

oracle@vmogg:~ [emagent] /u01/app/oracle/agent_24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/keytool -list -keystore /u01/app/oracle/agent_24ai/agent_inst/sysman/config/montrust/AgentTrust.jks -alias ogg_capath
Enter keystore password:
ogg_capath, Apr 19, 2026, trustedCertEntry,
Certificate fingerprint (SHA-256): 8D:6F:1D:67:ED:D9:7B:C0:C8:0E:D1:0E:50:2F:15:25:45:5D:F2:1D:A2:AB:22:C7:2D:AE:05:19:F1:DE:28:31

Without modifying anything in the Enterprise Manager, you can re-run the discovery. This time, the GoldenGate targets will be discovered ! To promote the new targets, just click on the number of targets discovered. You can also go in the Setup > Add Target > Auto Discovery Results section to view all discovered targets. Once this is done, the new targets will be monitored.

To summarize, in this NGINX context, OEM GoldenGate discovery fails with EM-90000 due to missing CA certificates in the agent truststore. Importing the proper CA chain into AgentTrust.jks resolves the SSL handshake failure.

L’article EM-90000 SSL Error With GoldenGate Targets in OEM est apparu en premier sur dbi Blog.

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

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

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

Deleting the deployment from oggca.sh won’t work

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

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

Deleting a deployment with the REST API

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

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

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

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

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

And for this, we never needed the deployment password !

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

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

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

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

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

Extract with no profile assigned

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

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

Extract with a profile set

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

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

Extract with a custom configuration

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

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

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

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

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

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

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

How to modify all extracts and replicats ?

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

from oggrestapi import OGGRestAPI

profile_name = 'dbiProfile'

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

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

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

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

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

REST API Log Files

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

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

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

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

Admin Client Log File

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

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

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

Service Manager Log Files

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

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

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

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

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

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

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

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

Deployment Log Files

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

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

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

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

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

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

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

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

GoldenGate Logs in the Web UI

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

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

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

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

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

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

Here are the prerequisites before attempting the distribution path creation:

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

In my environment, I have the following:

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

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

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

Path Connection Creation

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

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

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

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

Certificate Management

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

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

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

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

How should I register a certificate chain ?

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

Distribution Path Creation

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

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

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

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

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

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

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

The remote peer submitted a certificate that failed validation

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

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

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

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

Code: OGG-30007

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

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

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

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

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

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

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

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

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

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

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

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

What is the bug exactly ?

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

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

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

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

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

Is there a workaround ?

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

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

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

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

Certificates types in GoldenGate

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

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

Certificate monitoring from the web UI

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

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

Certificate monitoring with the REST API

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

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

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

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

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

from datetime import datetime, timezone
import sys

from oggrestapi import OGGRestAPI

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

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

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

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

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

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

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

    sys.exit(exit_code)

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

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

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

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

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

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

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

from oggrestapi import OGGRestAPI

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

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

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

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

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

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

Updating the Default profile directly

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

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

We can check by retrieving the configuration again.

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

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

Setting a custom profile to Default

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

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

After this, you need to do two things:

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

Here is how to do the creation of the flag:

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

And to update the Default profile:

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

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

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