Oracle Enterprise Manager Cloud Control 13.5 Installation on Oracle Linux 9 (9.7) raises libclntshcore.so.12.1 No such file or directory

 To test an upgrade from an existing Oracle Enterprise Manager Cloud Control 13.5 to 24ai, I've installed in our lab environment a fresh Oracle Enterprise Edition Database on Oracle Enterprise Linux 9 (with the latest dnf update it is a 9.7). 


As 13.5 is supported and certified on Oracle Enterprise Linux 9 and Red Hat Linux 9 from Release Update (RU) 22 on, I followed the following note EM 13.5: Steps To Install OMS 13.5 On RHEL/OL 9. I've ensured that all gcc, glib-devel, etc. things are installed, as this is NOT checked within the prerequisite checks of the installer. One package is not available in Linux 9 (compat-libpthread-nonshared-2.28-225.el8.x86_64) - I come to this a little bit later.

To install the 13.5 EMCC on Linux 9 means to make a software only installation first, patching omspatcher and opatch and afterwards install the three java patches and on top the RU29, using the bitonly option (and ignoring the warning about metadata). As far, as good. 

When everything is patched, one can start the Configuration, in my environment I needed to run the /u01/app/oracle/product/em135/sysman/install/ConfigureGC.sh script. 

This works well, unless the point where the OMS should be started.  Then you will run in an error. 



Well, I was aware, that this can happen, because of the missing package in Linux 9. Another Oracle Note exists telling us, what to do in that case: EM13c: 13.5 OMS Installation on RHEL/OL9 Fails at OMS Start "libclntshcore.so.12.1: cannot open shared object file"

So I downloaded the patch 35775632, extracted the stubs tar and re-run /u01/app/oracle/product/em135/bin/genclntsh - everything went well. 



I re-tried the Start Oracle Management Service in the Installer UI, but I've got the same error. (If you need to look into the logfiles, try to start the OMS manually with emctl start oms - you will get an output of the location of the logfiles. don't forget to stop the OMS with emctl stop oms later, before you retry to start it with the installation UI)


Checking for the existence of the libclntshcore.so.12.1 (or any links), I've found one at the agents lib directory (which was installed together with the Oracle Management Server automatically). I needed to copy that to the lib directories /u01/app/oracle/product/em135/lib AND to the OHS lib directory. This is NOT mentioned in the Oracle Support KB!


After doing so, I was able to re-run the start process at the UI and now the Enterprise Manager Cloud Control 13.5 on Oracle Linux 9 is up and running. 




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.