Feed aggregator

I have a task to modify PDB parameters, for example, setting `RECYCLEBIN` to `ON`. I changed the parameter on the primary PDB, but the change is not reflected on the standby database. The Parmeter is dynamic even its not reflected on standby side.

Hello, I was messing around with Application Containers, Roots, and PDBs and ran into something very interesting that I do not fully understand. It appears that the Application Root creates clones of itself when performing application sync - more specifically an uninstall. Please see below example: <code> create pluggable database app_root2 as application container admin user pdbadmin identified by "c0nn0r_h3lp!" -- use only if you're not using oracle managed files -- ensure you set the directory to where your datafiles are stored file_name_convert=('/u03/datafiles/ORCL/pdbseed/','/u03/datafiles/ORCL/APP_ROOT2/'); alter pluggable database APP_ROOT2 open; alter session set container = APP_ROOT2; alter pluggable database application test1 begin install '1.0'; create table test1 sharing=data (column1 number, column2 varchar2(120)); alter pluggable database application test1 end install; create pluggable database cust3 admin user pdbadmin identified by "cust1_pwd!" file_name_convert=('/u03/datafiles/ORCL/pdbseed/','/u03/datafiles/ORCL/APP_ROOT2/CUST3/'); alter pluggable database cust3 open; -- look at the list of PDBs prior: alter session set container = CDB$ROOT; show pdbs; -- go back into the root and sync: alter session set container = APP_ROOT2; alter session set container = CUST3; alter pluggable database application test1 sync; alter session set container = APP_ROOT2; alter pluggable database application test1 begin uninstall; drop table test1; alter pluggable database application test1 end uninstall; alter session set container = cust3; alter pluggable database application test1 sync; alter session set container = CDB$ROOT; select con_id, name, application_root, application_pdb, application_root_con_id from v$pdbs where name like 'F%'; select con_id, name, application_root, application_pdb, application_root_con_id from v$pdbs -- be sure to put YOUR application root con id returned from the above query here in this where clause where con_id = 12; </code> Any attempt to close, alter, etc. this "fake" PDB is rejected with an "ORA-65266 - application root clone may not be dropped, unplugged or altered" Another interesting note it is classified as an application root and an application PDB - which if we look at the root PDB it is an Application Root but not an application PDB. My two questions: 1. What exactly is this PDB? 2. Why is it created during application synchronization/uninstallation? Thank you

Hello Tom, I have just upgraded to APEX v26.1 and enabled Natural Language Support for Interactive Report on one of my IRs, as a new feature of this upgrade. I have also created a Generative AI provider using OpenAI using the gpt-5.6-terra model. Using this AI provider for other AI features of APEX works fine. When I then try to search or ask a question on the said IR, it throws an error: ?<i>ORA-20954: The HTTP request to Generative AI Service at https://api.openai.com/v1/chat/completions failed with HTTP-400: Function tools with reasoning_effort are not supported for gpt-5.6-terra in /v1/chat/completions. To use function tools, use /v1/responses or set reasoning_effort to 'none?.</i>" Upon reading the latest APEX documentation further, it clearly says: <i>OpenAI - Uses /chat/completions for chat and /embeddings for vector generation. OpenAI expects JSON with messages[] and model parameters, and authenticates using a Bearer token. APEX maps its internal format to the OpenAI schema, injects credentials, and normalizes responses so applications see a consistent structure across models and providers.</i> That explains the problem. OpenAI have also made it clear that they?re migration their tools to use /v1/responses, though /v1/chat/completions is till supported for some things. Is there a workaround for this, other than using a different AI provider? Personally, the limitation as far as I can tell is that Oracle APEX does not seem to be providing the flexibility, at least on the Natural Language Support for Interactive Report feature, to select a REST API to an AI provider tool. The Natural Language Support for Interactive Report feature relies on APEX?s preconfigured internal mapping to the supported AI providers. Am I wrong?

Hi, If I?m reading the documentation (picture of timing_point_section in https://docs.oracle.com/en/database/oracle/oracle-database/19/lnpls/CREATE-TRIGGER-statement.html) correctly, variable declarations are not allowed within the timing-point-section. However, the compiler accepts the declarations and the code works as well. The question is: Is the documentation incomplete or is my code wrong? Here?s a meaningless but working example: <code> CREATE OR REPLACE TRIGGER cmptrg_test FOR UPDATE OR INSERT OR DELETE ON my_table COMPOUND TRIGGER l_var number; AFTER STATEMENT IS l_cnt NUMBER; --possible here? The documentation doesn?t mention this or am I wrong? BEGIN NULL; --do something with l_cnt... END AFTER STATEMENT; END cmptrg_test; /</code> Thank you for clarifying, Florian.

I am looking for feedback from DBAs and performance experts who have experience managing highly volatile tables in Oracle Database 19.31. In our environment, we have work tables, processing tables, and staging tables that can grow from a few thousand rows to several million rows during the same processing cycle. Managing optimizer statistics on these objects has become a challenge. If statistics are unlocked, Oracle may automatically gather statistics while business processes are running. In some situations, this introduces additional overhead and can increase execution times. On the other hand, when statistics become stale or do not accurately reflect the current data volume, the optimizer may choose inefficient execution plans, resulting in significant performance regressions. I would like to understand the most effective strategy for this type of workload: ?Do you regularly gather statistics on highly volatile tables, or do you prefer to lock them? ?How do you handle tables whose row counts change dramatically within a single batch process? ?What role do Dynamic Statistics (Dynamic Sampling) and Real-Time Statistics play in this scenario? ?Can these features provide sufficiently accurate cardinality estimates to help the optimizer consistently choose good execution plans without frequent statistics gathering? ?Have you observed plan instability or regressions when relying mainly on Dynamic Statistics or Real-Time Statistics? ?Are there any Oracle 19c (specifically 19.31) best practices that you would recommend for this type of environment? My main objective is to maintain stable and efficient execution plans while minimizing the overhead of statistics collection on large volatile tables. I would be very interested in hearing about real-world experiences, lessons learned, and practical recommendations from those who have faced similar challenges. Thank you in advance for your insights.

I am interested in learning about the best practices for ensuring that the Oracle optimizer consistently chooses efficient execution plans without relying on hints, SQL patches, SQL profiles, or forced execution plans that may become outdated over time. In your experience, what database features, parameters, and maintenance practices should be implemented to help the optimizer make the right decisions and minimize plan regressions? For example: Which optimizer-related parameters are most important to review? What are the recommended statistics gathering strategies for Oracle 19c? How effective are Real-Time Statistics, Dynamic Statistics, SQL Plan Management (SPM), and Automatic Indexing in preventing regressions? What role do histograms, extended statistics, and accurate object statistics play? How do you manage volatile tables and changing data distributions? What monitoring and validation processes do you use to detect and prevent plan changes before they impact production? I am particularly interested in feedback from teams running large Oracle 19c environments and the lessons they have learned in maintaining stable performance while allowing the optimizer to adapt naturally to data changes. Thank you in advance for sharing your recommendations and real-world experiences.

We use Os authentication for management access control and automating backups and scripts on windows rdbms servers to avoid using any passwords. This works fine on PDBs, but on the cdb level, if we want to access the database as a user with no sys_dba for automating clonning of pdbs we cannot use that as the common_user_prefix and os_authentication_prefix does not allow for a user to be both... Is there a solution around this? I can set the prefix to be the same, but Then Os authentication will not be available on the pdbs!

Hello, I would like to ask for technical guidance on the following scenario. I have a Node.js 24 backend running on Linux, deployed either on AWS EC2 or in an Amazon ECS container. It uses node-oracledb 6.8, also tested with 6.9, in Thin mode with a connection pool to an Amazon RDS for Oracle 19c Single-AZ instance. During planned Oracle/RDS maintenance, the database becomes temporarily unavailable while the Node.js process remains running. After maintenance has completed and RDS is available again, the application does not correctly re-establish database connectivity. The service only starts working again after restarting the Node.js process or container. This has occurred several times with two independent Node.js applications in two different AWS accounts, both based on the same Node.js and RDS for Oracle architecture and configuration. I have already searched Ask TOM and reviewed these related questions: https://asktom.oracle.com/ords/f?p=100:11:0::::P11_QUESTION_ID:45249405283766 https://asktom.oracle.com/ords/f?p=100:11:0::::P11_QUESTION_ID:16008986393518 https://asktom.oracle.com/ords/asktom.search?tag=node-reliability-issues However, I could not find an answer covering this complete configuration and planned Amazon RDS maintenance scenario. Is this combination of AWS, Linux, Node.js, node-oracledb Thin mode, and RDS for Oracle 19c commonly used in production? According to current best practices, what is the correct configuration across AWS, RDS for Oracle, Linux, Node.js, and the node-oracledb parameters to handle this scenario reliably and safely? At the application level, how should the JavaScript code behave while the database is unavailable and after it becomes available again? How should connection-pool management, in-flight requests, and the return to normal operation be structured so that no restart is required? Thank you in advance for any technical guidance or direct experience you can share.

A few weeks ago I did a sample blog post to use local LLM to create a PL/SQL package to encrypt and decrypt data in an Oracle database - AI Comparison for Oracle Security Code Generation . In that blog....[Read More]

Posted by Pete On 19/08/26 At 12:42 PM

There are many components that are part of Database Vault. At the lowest level are factors that encapsulate the individual pieces of data that you may use in the rest of the set up. Then there are DV rules that....[Read More]

Posted by Pete On 17/08/26 At 12:51 PM

I am using my local LLM using a mac book pro M5 64gb and running Ollama, open-webui via docker and the interface on my Windows laptop. I posted a blog recently Can local LLM AI generate the top 100 most....[Read More]

Posted by Pete On 05/08/26 At 09:35 AM

As part of a previous investigation when looking at timestamps and dates for changes recorded to the database meta data I noticed in addition to the normal columns the SYS.USER$.SPARE6 column as it was populated for some users. I also....[Read More]

Posted by Pete On 03/08/26 At 01:59 PM

One area I have not covered in previous blogs about Oracle Security and AI is sovereignty of that AI and of course in particular of the data. This means that the control of the hardware (compute and GPU) and the....[Read More]

Posted by Pete On 29/07/26 At 02:20 PM

My day to day focus is helping customers secure data in their Oracle databases. As you will have seen from a small number of blogs here recently I have been writing a little about AI and in particular local LLMs....[Read More]

Posted by Pete On 28/07/26 At 08:41 AM

I am working on a simple password audit tool for Oracle Apex and I have written a simple password cracker in PL/SQL to test if a password is found or not; i.e. is the password weak or not. To allow....[Read More]

Posted by Pete On 23/07/26 At 12:01 PM

Sometimes in forensic analysis of an Oracle database it is necessary to understand how data is stored on disk. Actually we must understand that if we were to create our own database we might start with a file that holds....[Read More]

Posted by Pete On 13/07/26 At 09:11 AM

In a previous blog, I presented how to set up a distribution path between two GoldenGate deployments both secured with NGINX. The method I used there was purely through the Web UI. But GoldenGate also exposes a full REST API, and everything you can do in the UI can be done through the API as well, which is useful for automation, scripting, or when the UI is not reachable.

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

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

Prerequisites

The prerequisites are the same as in the previous blog :

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

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

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

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

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

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

from oggrestapi import OGGRestAPI

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

Create the path connection

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

With the client, just call the create_alias method :

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

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

import requests

auth = ("ogg", "ogg_password")

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

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

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

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

Register the target’s CA certificate

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

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

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

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

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

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

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

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

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

Create and start the distribution path

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

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

With the client :

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

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

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

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

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

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

The remote peer submitted a certificate that failed validation

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

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

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

A few weeks ago Laurent Schneider messaged me to say Oracle Database 26ai (23.26.2) was supported on Oracle Linux 10 (OL10). That started the usual series of test builds. Basic Installations I already had an installation article for 26ai on OL10, but I updated it, including using the new preinstall package which is now in … Continue reading "Oracle AI Database 26ai (23.26.2) Supported on Oracle Linux 10 (OL10)"

The post Oracle AI Database 26ai (23.26.2) Supported on Oracle Linux 10 (OL10) first appeared on The ORACLE-BASE Blog.Oracle AI Database 26ai (23.26.2) Supported on Oracle Linux 10 (OL10) was first posted on August 21, 2026 at 7:13 am.
©2024 "The ORACLE-BASE Blog". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please contact me at timseanhall@gmail.com

I already covered out-of-place patching from the web UI, but patching tasks should be automated, and clicking through the same screens for every deployment can get repetitive. Let’s do the exact same out-of-place patch of a GoldenGate Microservices Architecture deployment, this time entirely with the REST API.

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

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

Installing the latest version of GoldenGate

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

Patching the Service Manager with the REST API

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

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

Updating OGG_HOME is a PATCH call on the ServiceManager deployment:

import requests

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

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

With oggrestapi.py:

from oggrestapi import OGGRestAPI

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

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

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

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

client.restart_deployment(deployment="ServiceManager")

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

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

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

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

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

Patching each deployment with the REST API

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

deployment = "ogg_test_01"

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

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

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

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

admin_url = "https://vmogg:7810"

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

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

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

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

Automating the whole patching in one call

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

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

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

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

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

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

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

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

Some services are still running on the old OGG_HOME

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

Other things to consider

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

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

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

Recently, I decided to conduct an initial test involving a review in one of our test environments. The aim was twofold: to explore the new features and to verify the update process. You can read about my experience and the outcome in this blog post.

In week 29 of 2026, M-Files released a new version of its widely known and used M-Files Compliance Kit. This is especially useful if you are looking for advanced workflow capabilities or working in a regulated environment. The Compliance Kit is an essential tool.
This first version of the 2026 edition was followed by several smaller updates and fixes, culminating in version 2026 (26.9.16376.0).In this blog, I will highlight some of the improvements that I consider significant. The full release notes can be found on the M-Files official website.

New features and improvements

This does not reflect the complete list, but it does include some of the most important parts.

Features

• Object Creator commands and groups can use custom icons (including your own SVG or image-based icons).
• You can create and arrange custom task bar groups, control their placement and priority, and merge them with built-in groups.
• Commands can be shown outside their group in the context menu to match the classic client’s layout.
• Existing configurations continue to work with no changes required — classic client behavior is preserved, and legacy icons are reused automatically in newer clients where appropriate.
• CAD File Preview Support
  CAD files with extensions .dwg, .dxf, .dwt, and .dgn can be previewed within the new Clients Preview tab, utilizing the active layout. The maximum supported file size is 50 MB. Previews are generated using a converted PDF format. Administrators have the capability to enable this conversion process for workflow state transitions or on-demand PDF conversion through the “Configuration>PDF Conversion (Indexing, File Preview, Workflows)>CAD Files>Enable On-Demand Conversion” setting, which is disabled by default.

Improvements

• Activity feed now identifies AI-driven changes
  When an object’s metadata is edited automatically based on an AI response, the activity feed now shows “M-Files AI” as the editor instead of a generic “M-Files” entry, making it clearer when a change was made by AI rather than a person.
• Icons in view listing columns
  The new M-Files client now shows a small icon next to value-list values in view listing columns — Workflow, Workflow state, Class, Object Type, and any custom value list item — so users can recognise the state, class, and type of each object at a glance without opening it.
• Improved metadata card appearance
  The metadata card now correctly displays custom colors for property group headers and descriptions. This ensures a more consistent and visually clear experience when viewing object details.
• Drag-and-drop support for relationships and document collection management
  Users can now drag and drop one or multiple objects onto another object in the listing to add documents to a document collection, establish relationships, append files to a multi-file document, or replace a file’s content.
• Edit documents stored in M365 Storage using Web Co-Authoring
  You can now open and co-author documents directly in the Office Web version using the new ‘Edit in Web’ option in the context menu. This makes it easier to collaborate online without needing the Office Desktop application.
• UIXv2: show multiple dashboards in a popup window
  You can now display up to three dashboards side by side in a pop-up window using the UI extensibility framework (UIXv2). This helps you compare information and work more efficiently without switching views.

As previously mentioned, a large number of improvements have been made and many defects have been fixed. Please refer to the official M-Files documentation for further details.

Installation and Update process

I can confirm that the installation and update process was very straightforward and worked without any issues. As always, you can simply install the new Vault Framework application in the Vault. There is no need to uninstall the previous version.

After installation, navigate to the Compliance Kit configuration in the Vault. As in previous versions, an update button will be displayed. Pressing this button starts the update process, which went very well in my test. Afterwards, the Compliance Kit worked as expected, with all configurations and settings remaining intact.

After restarting and refreshing the vault, the upgrade application is shown under configuration. Next, we can start the final update process by pressing the button, as shown in the screenshot.

Once again, the M-Files Admin Tool is refreshed and the result of the update confirms that the new version of the Compliance Kit is 2026.

Example of new features

The examples below demonstrates the new features of the M-Files Compliance Kit 2026, as implemented in a Quality Management System (QMS) demo vault.

The picture below shows the new features based on an approved change request. Refer to the cycle in the picture to see the commands available for an approved change request. This makes it very easy to create a new document based on the approved change request.
This function was already available in the classic client but was sorely missed by almost every user in the new client.

New M-Files Client Web Client Conclusion

With all the improvements and fixes, particularly the new client’s command retrieval function. This is a step in the right direction. If you’re wondering how it works in the web client.Tthe answer is that anything that works in the new client also works in the web client.

If you have any questions or would like a demonstration, please get in touch with us. We can also assist with installation, updates and configuration.

L’article M-Files Compliance Kit 2026 is available est apparu en premier sur dbi Blog.