Differences in DBCA responsefiles in Oracle Database 19c and Oracle AI Database 26ai

 After the release of Oracle Database AI 26ai (Enterprise Edition only) there are some questions to ask. 

One is, can I reuse my response files created with the Database Configuration Assistant of my 19c database, where do I maybe need to or would be able to do changes? To answer this question, a view/comparison of the two response files is necessary. The configuration was done on both database versions with “advanced configuration” on Linux (as all other 26ai versions are not available yet, the 19c dbca response file was created with 19c RU 24).

So, let’s start with the comparison. One interesting fact is found at the beginning of the response file. The file version is 12.2.0 (because 19c was/should have been a 12.2.X release) while the 26ai is using response file 23.0.0 – not a big surprise, as 26ai is showing itself as a 23.26 in a lot of different places.

The next interesting fact is the databaseConfigType. In 19c there was SI (Single Node), RAC and RACONENODE available, with 26ai Oracle added SEHA (Standard Edition High Availability). As today (Feb. 5th, 2026) the Standard Edition Software is not available for 26ai there is no chance to test this, but it should make the configuration of SEHA environments easier in the future. Therefore, 26ai added also more SEHA related parameters, e.g the sehaServiceName and the sehaNodeList (unfortunately it is not grouped together in the response file, so one must search for the parameters manually).

The next topic added is the managementPolicy. It controls, how the database handles PDBs when restarting. Flora has a very informative blog post done for 23c, so details how to use that can be found here: https://oracleandme.com/2023/05/16/23c-floating-pdbs-the-lab/

As there is no Database Express management possibility anymore in 26ai, emConfiguration now does only allow CENTRAL (Enterprise Manager Cloud Control) or NONE as values. DBEXPRESS and BOTH are not allowed anymore.

One interesting fact: In my 19c response file the fast recovery area was part of the InitParams line, with 26ai a new parameter recoveryAreaSize was added, but the value is also still part of the initParams line. What will happen, if there are two different sizes specified in the response file? Is there a difference between the setup part and the running part later?

Also new are the specification of the dbOptions and pdboptions, which now can be different, e.g. SPATIAL can be installed at CDB level with dbOptions SPATIAL:true but can be excluded from the PDB pdbOptions with SPATIAL:false.

The last new parameter I found in the 26ai response file is useOMF, which can be set to true of false. In the 19c response file, there is no useOMF parameter – it was set at the background to true.

The last new parameter I’ve found is enableArchive which is default set to false, meaning the database is not using archive log mode after it was created.

sampleSchema installation is now removed from the 26ai response file, typically now one installs them in a production or test environment.

All in all, there are not so many differences in the response files. All new parameters are not mandatory except of SEHA, if one uses this option the depending parameters must be inserted, and the default values are typically set to none.

One funny thing in 26ai is, that createAsContainerDatabase is not mandatory, but the default value is still false. As 26ai can’t be installed as non-CDB, I question myself, why this was inserted (also inserted is the initParams entry “enable_pluggable_database=true”):

#-----------------------------------------------------------------------------
# Name          : createAsContainerDatabase
# Datatype      : Boolean
# Description   : flag to create database as container database
# Valid values  : Check Oracle12c Administrator's Guide
# Default value : false
# Mandatory     : No
#-----------------------------------------------------------------------------
createAsContainerDatabase=true

If you are interested in the response files, you can download them from my storage:

19c: dbca_19c.rsp
26ai: dbca_26ai.rsp

Oracle Linux Virtualization Manager (OLVM), Hard Partitioning and SSO error with olvm-vmcontrol

Oracle Linux Virtualization Manager is one of the few remaining options for performing hard partitioning to restrict the use of Oracle licenses on a system.

In this case, a customer already had an (outdated) OLVM environment with three servers, each with two CPU licenses for the Oracle database, for a total of six CPU licenses, which corresponds to the use of twelve cores on the Intel/AMD environment. Due to hardware replacement cycles, the existing OLVM was not upgraded but reinstalled.

The environment in the new setting now consists of two nodes, each with 8 cores, for a total of 16, and an OLVM engine on an additional VM (in VMWare). In order to avoid having to add additional licenses for the Oracle database and since the company already has the necessary expertise in-house, the requirement was to limit the CPU cores or threads when moving the virtual machines (VMs) to the new OLVM environment. 

This is usually relatively easy to do by following the few steps in the document https://www.oracle.com/a/ocom/docs/linux/ol-kvm-hard-partitioning.pdf.

olvm-vmcontrol must be installed on the engine host, and then CPU pinning to the threads can be performed using a command with olvm-vmcontrol.

Unfortunately, however, the customer encountered an error when executing olvm-vmcontrol: Either it said that the user admin@internal could not connect due to incorrect credentials, or that admin@ovirt, which is actually used on the engine interface, did not exist at all:

'Error during SSO authentication “access_denied”: “Cannot authenticate user No valid profile found in credentials..”'

However, the problem was not an incorrect password, but rather that KeyCloak was suggested as the default during installation (never change default values, if unsure is not always a good advice). KeyCloak is still “experimental” and is responsible for preventing olvm-vmcontrol from connecting to the engine.

You can easily check whether KeyCloak is installed on the host running the engine:
grep KEYCLOAK_BUNDLED /etc/ovirt-engine/engine.conf.d/12-setup-keycloak.conf

If the value is “True,” you will definitely encounter the problem that olvm-vmcontrol cannot log in to the OLVM engine. Fortunately, there is a solution – KeyCloak must be disabled. Since this involves several steps, I refer you to the relevant post in Oracle's support portal under note KB495706 (simply enter this in the search field at the new portal of support.oracle.com).

Once disabling has been done, olvm-vmcontrol can then login with the user admin@internal and the CPU/thread binding to the VM can be configured as desired. For subsequent installations, the customer now knows that KeyCloak configuration should not be set to "Yes" when configuring the engine at the beginning.

In order to achieve the most distributed utilization of the CPU NUMAs possible, when pinning the threads, care should be taken to ensure that they are distributed as evenly as possible across the available NUMAs (in this case 2). VMs not intended for the operation of Oracle licenses can then be distributed across the remaining threads.

However, pinning the CPUs has one disadvantage: live migrations of a VM from one node to another are no longer supported. This means that the VM must be stopped, the definition edited (hosts), and the VM restarted. This is a (small organizational/high availability) price to pay in return for the license savings. 

Install RLWRAP on Oracle Database Appliance without internet connection

 If you need to install RLWRAP on an Oracle Database Appliance (ODA) with actual releases (19.26-19.28 ) you need to install the following rpms. As we use rlwrap a lot also in our Robotron DBA tool set, we install it nearly everywhere. 

While it is easy to install rlwarp with a working internet connection and the ODAs yum/dnf repository configuration, most of our customers don't allow the ODAs access to the public internet (except of ASR). 

Here is the list of the rpms you need to install (ordered) from the public yum base repository:
- ncurses-c++-libs: https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/ncurses-c++-libs-6.1-10.20180224.el8.x86_64.rpm
- ncurses-devel: https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/ncurses-devel-6.1-10.20180224.el8.x86_64.rpm
- readline-devel: https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/readline-devel-7.0-10.el8.x86_64.rpm
- readline: should be already installed, if not: https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/readline-7.0-10.el8.x86_64.rpm
- m4: https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/m4-1.4.18-7.el8.x86_64.rpm

The following must be installed using the rpms from the Appstream folder. 
- autoconf: https://yum.oracle.com/repo/OracleLinux/OL8/appstream/x86_64/getPackage/autoconf-2.69-29.el8_10.1.noarch.rpm
- automake: https://yum.oracle.com/repo/OracleLinux/OL8/appstream/x86_64/getPackage/automake-1.16.1-8.el8.noarch.rpm
- perl-file-slurp: https://yum.oracle.com/repo/OracleLinux/OL8/appstream/x86_64/getPackage/perl-File-Slurp-9999.19-19.el8.noarch.rpm

rlwrap can either be installed from oracle yum epel oder fedoraproject repository
- rlwrap from oracle yum epel : https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/x86_64/getPackage/rlwrap-0.46.2-3.el8.x86_64.rpm
- rlwrap from fedoraproject: https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/r/rlwrap-0.46.2-3.el8.x86_64.rpm  

If you install rlwrap from the fedoraproject und you get an error "GPG check FAILED" you need to download the public key RPM-GPG-KEY-EPEL-8  from https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-8, save it, e.g. as RPM-GPG-KEY-EPEL-8.txt and import it with "rpm --import RPM-GPG-KEY-EPEL-8.txt" before installing the rpm.
  
If you patch an ODA you might get an error at the prepatchreport for the server. If so, uninstall automake, autoconf and m4 with dnf remove <package> and re-install them after you finished the ODA patch (server and storage). 
  
If you download everything locally and upload/put all rpms into the /tmp folder of the ODA, you can run dnf install /tmp/<name-of-the-rpm> and install them one after the other. 

My Oracle Support portal changed to worse. How to find at least some DocIDs you still have...

Well, we all looked forward to a new support portal starting at Dec. 7th, enabling us to use AI and to work better and faster than before. What really happend? Links are broken, all bookmarks gone (in my case roundabout 100 sorted for different technical products and problems, patches, white papers), the patch search does not work like it did before, and so on, and so on... At the end, it is not better than before - it is a lot more worse. 

At least for all the links in my blog I hope I have found a solution. Typically, all blogs do not tell you the document title, but you can see the DocID. 
As the DocID has changed into a "KB" with a number, they still seem to be used in the background. If you do know the DocID which consists of a number, followed by a "Dot" and a second number, you may get access by using the following procedure. 

First is, login to your support.oracle.com environment. Then, put the old DocID without the "Dot" and everything following into this URL, replacing <SHORT_DOC_ID> with the value you have. 

https://support.oracle.com/support/?anchorId=&kmContentId=<SHORT_DOC_ID>&page=sptemplate&sptemplate=km-article

One of my favorite notes is 888.1, the title is something with "Oracle Database", but if you search for "Oracle Database primary note", well, you don't find it in the search results. 

E.g. to get the DocID 888.1 you can use 

https://support.oracle.com/support/?anchorId=&kmContentId=888&page=sptemplate&sptemplate=km-article

The title by the way is now "(KB106822) Primary Note for Database Quarterly Release Updates".  If you look at the first lines, you can see the following text 

"This was MOS Document ID: 888.1 in Legacy MOS.  Post migration, we will be moving to KB888 (Date TBA)"

What the f*... 

Ok, back to another note I really need a lot - the last version of OPatch was at DocID 293369.1. Again, changing the link to 

https://support.oracle.com/support/?anchorId=&kmContentId=293369&page=sptemplate&sptemplate=km-article

leads to the Primary Note for OPatch. 

I'm still mourning the lost bookmarks, but at least for the most documents I find at the internet, I may have found a solution to bring them back without struggling with the new search functionality. Unfortunately it seems to not work with all DocIDs, some do show a "404" error, but most do work. 

Please comment if this works for the things you need or if you still struggle.