Introduction
Installing Oracle Database 19c Standard Edition 2 on Oracle Linux 9 is not quite the same as installing Oracle 19c on Oracle Linux 7 or 8.
Oracle's downloadable Linux Database Home image is still the 19.3 base image, while Oracle Linux 9 support was introduced at later Oracle 19c Release Update levels. Oracle currently documents Oracle Linux 9 support beginning with Oracle Database 19c Release 19.19 and recommends installing 19.22 or later on OL9. Oracle's OL9 installation procedure uses the 19.3 image and applies a later Release Update during installation.
This distinction can lead to several confusing installation failures if the 19.3 installer is started directly on a modern Oracle Linux 9 server.
In this implementation we encountered and resolved issues including:
INS-08101: Unexpected error while executing the action at state: 'supportedOSCheck' java.lang.NullPointerException
and:
PRVF-7532 : Package "compat-libcap1" is missing
We also had to consider the difference between Oracle Linux 9's default newer UEK kernel and the kernels currently documented for Oracle Database 19c.
This article walks through the complete process.
1. Installation architecture
The target architecture is:
Oracle Linux 9 x86-64 | +-- Oracle Database 19c | +-- Standard Edition 2 | +-- Single Instance | +-- File-system based storage
The database server uses dedicated storage for software, database files, recovery files and RMAN backups.
Oracle storage layout
| Mount point | Size | Purpose |
|---|---|---|
/u01 | 100 GB | Oracle software, Oracle Inventory, ADR and trace files |
/u02/oradata | 300 GB | Datafiles, tempfiles, undo, control files and online redo |
/u03/fra | 300 GB | Fast Recovery Area, archived logs and recovery files |
/u04/backup | 300–400 GB | RMAN backupsets with two-day retention |
A production layout therefore looks like:
/u01 └── app ├── oracle │ ├── product │ │ └── 19.0.0 │ │ └── dbhome_1 │ └── diag └── oraInventory /u02/oradata └── Database files /u03/fra └── Fast Recovery Area /u04/backup └── RMAN backupsets
Keeping database software, active database storage and recovery/backup storage separate improves operational management and limits the effect of one filesystem becoming full.
Oracle recommends keeping the fast recovery area on storage separate from the primary database files where practical.
2. High-level installation plan
A production Oracle 19c SE2 deployment on Oracle Linux 9 should follow this sequence:
Build Oracle Linux VM ↓ Validate OS and CPU architecture ↓ Validate Oracle-supported kernel ↓ Install oracle-database-preinstall-19c ↓ Verify OL9 prerequisite packages ↓ Prepare /u01 /u02 /u03 /u04 ↓ Create Oracle environment ↓ Download Oracle 19.3 Database Home ↓ Download current OPatch and 19c RU ↓ Extract Oracle Home ↓ Apply current RU during runInstaller ↓ Install Oracle Database 19c SE2 software ↓ Run root scripts ↓ Configure listener ↓ Run DBCA ↓ Configure database/FRA/archive logging ↓ Configure RMAN ↓ Verify SE2 edition, NLS, storage and patching ↓ Perform backup/restore validation ↓ Test database restart/reboot
This approach separates Oracle software installation from database creation, making troubleshooting significantly easier.
3. Confirm Oracle Linux version
Check the operating system:
cat /etc/oracle-release cat /etc/os-release uname -m uname -r
Our server was:
Oracle Linux Server release 9.8 Architecture: x86_64
Oracle Database 19c supports Oracle Linux 9 x86-64 from later 19c Release Updates. Oracle currently lists the following minimum kernels:
UEK7: 5.15.0-1.43.4.2.el9uek.x86_64 or later RHCK: 5.14.0-70.22.1.0.2.el9_0.x86_64 or later
4. Kernel compatibility issue on newer Oracle Linux 9
Our Oracle Linux 9.8 server initially booted using:
6.12.0-206.104.4.4.el9uek.x86_64
This is from the newer UEK8 kernel family.
However, Oracle Database 19c's current OL9 support documentation explicitly lists:
UEK7 5.15 or RHCK 5.14
rather than UEK8 6.12.
The server already contained two RHCK kernels:
5.14.0-687.49.1.el9_8.x86_64 5.14.0-687.5.3.el9_8.x86_64
We selected the newer RHCK kernel.
Check installed kernels:
rpm -qa | grep -E '^kernel' | sort
Check available boot images:
ls -l /boot/vmlinuz-5.14*
Set the appropriate RHCK kernel as default:
grubby --set-default \ /boot/vmlinuz-5.14.0-687.49.1.el9_8.x86_64
Verify:
grubby --default-kernel
Expected:
/boot/vmlinuz-5.14.0-687.49.1.el9_8.x86_64
Reboot:
reboot
Then:
uname -r
Expected:
5.14.0-687.49.1.el9_8.x86_64
There is no requirement to uninstall the UEK kernels. Keeping another bootable kernel provides a fallback.
Also, do not permanently pin a server to one old kernel version. Continue applying supported Oracle Linux security/kernel updates and validate Oracle Database certification before changing kernel families. Oracle explicitly cautions against indefinitely pinning OL systems to old kernel/update levels because this prevents security updates.
5. Install Oracle's preinstallation package
Oracle Linux provides a very useful package:
dnf install -y oracle-database-preinstall-19c
Verify:
rpm -q oracle-database-preinstall-19c
For example:
oracle-database-preinstall-19c-1.0-3.el9.x86_64
Oracle recommends this package because it installs Oracle Database prerequisites and performs operating-system configuration such as creating the Oracle account/groups and setting required limits.
6. Verify prerequisite packages explicitly
Even when oracle-database-preinstall-19c is installed, it is worthwhile validating the system before starting OUI.
Run:
rpm -q \ bc \ binutils \ compat-openssl11 \ elfutils-libelf \ fontconfig \ glibc \ glibc-devel \ ksh \ libaio \ libasan \ liblsan \ libX11 \ libXau \ libXi \ libXrender \ libXtst \ libxcrypt-compat \ libgcc \ libibverbs \ libnsl \ librdmacm \ libstdc++ \ libxcb \ libvirt-libs \ make \ policycoreutils \ policycoreutils-python-utils \ smartmontools \ sysstat \ xz-devel
Oracle's current Oracle Linux 9 prerequisite list includes these packages, including compat-openssl11.
In our installation:
compat-openssl11
was missing.
Install it:
dnf install -y compat-openssl11
Verify:
rpm -q compat-openssl11
7. Disable Transparent HugePages
Oracle recommends disabling Transparent HugePages for Oracle Database and using standard HugePages where appropriate.
Check:
cat /sys/kernel/mm/transparent_hugepage/enabled
For example:
[always] madvise never
A persistent kernel parameter can be added with:
grubby --update-kernel=ALL \ --args="transparent_hugepage=never"
Reboot and verify:
cat /sys/kernel/mm/transparent_hugepage/enabled
Expected:
always madvise [never]
Static HugePages should then be sized according to the database SGA rather than configured arbitrarily.
8. Create Oracle directories
Create the Oracle Home and Oracle Inventory:
mkdir -p /u01/app/oracle/product/19.0.0/dbhome_1 mkdir -p /u01/app/oraInventory
Ensure database storage exists:
mkdir -p /u02/oradata mkdir -p /u03/fra mkdir -p /u04/backup mkdir -p /u04/backup/ORCL
Ownership:
chown -R oracle:oinstall /u01 chown -R oracle:oinstall /u02 chown -R oracle:oinstall /u03 chown -R oracle:oinstall /u04
Permissions can be established according to site security standards, for example:
chmod 775 /u01 /u02 /u03 chmod 750 /u04/backup
Verify filesystems:
df -hT /u01 /u02/oradata /u03/fra /u04/backup
9. Configure the Oracle environment
Log in as:
su - oracle
Configure ~/.bash_profile:
export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 export ORACLE_SID=ORCL export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib export TMP=/tmp export TMPDIR=/tmp umask 022
Apply:
source ~/.bash_profile
Verify:
echo $ORACLE_BASE echo $ORACLE_HOME echo $ORACLE_SID
10. Download the Oracle Database software
Oracle provides the Linux x86-64 Database Home image as:
LINUX.X64_193000_db_home.zip
The official SHA-256 currently published by Oracle is:
ba8329c757133da313ed3b6d7f86c5ac42cd9970a28bf2e6233f3235233aa8d8
Oracle Database 19c Linux x86-64 Downloads
For Standard Edition 2, use the Database Home ZIP. Do not install the downloadable:
oracle-database-ee-19c-1.0-1.x86_64.rpm
because that package is specifically the Enterprise Edition RPM.
The ZIP image allows the required edition to be selected during Oracle Universal Installer.
11. Do not treat 19.3 as the final OL9 installation
This is one of the most important points.
Oracle's download image is 19.3, but Oracle recommends installing 19.22 or later when deploying Oracle 19c on Oracle Linux 9 and applying the RU during installation.
At the time of writing in September 2026, Oracle Database 19c RU 19.32, released in July 2026, is current, and Oracle identifies DBRU patch 39472050 for the 19.32 Database RU.
Always check My Oracle Support and the current RU README before installation because patch numbers, OPatch minimum levels and required one-off patches change over time.
12. Update OPatch
Download the current Oracle OPatch utility from My Oracle Support using:
Patch 6880880 Release: 19.0.0.0.0 Platform: Linux x86-64
For the 19.32 installation documentation Oracle specifies OPatch 12.2.0.1.52 or later.
Assume the files are staged under:
/u01/stage
Extract the Oracle Database Home first:
cd $ORACLE_HOME unzip /u01/stage/LINUX.X64_193000_db_home.zip
Check existing OPatch:
$ORACLE_HOME/OPatch/opatch version
Back it up:
cd $ORACLE_HOME mv OPatch OPatch.193
Extract the newer OPatch:
unzip /u01/stage/p6880880_190000_Linux-x86-64.zip \ -d $ORACLE_HOME
Verify:
$ORACLE_HOME/OPatch/opatch version
13. Extract the Release Update
For example:
mkdir -p /u01/stage/patches cd /u01/stage/patches unzip /u01/stage/p39472050_190000_Linux-x86-64.zip
This results in a patch directory similar to:
/u01/stage/patches/39472050
Check:
ls -ld /u01/stage/patches/39472050
14. Running Oracle Universal Installer using MobaXterm
The graphical Oracle installer requires an X display.
MobaXterm conveniently includes an X server.
Connect directly as the Oracle account with X11 forwarding enabled.
Check:
whoami echo $DISPLAY
Expected:
oracle localhost:10.0
The display number may be different.
Test X11:
xdpyinfo | head
If the command displays information about the X display, graphical forwarding is working.
If $DISPLAY is empty:
echo $DISPLAY
and returns nothing, do not continue with OUI.
Verify SSH server configuration:
sudo sshd -T | grep -i x11
Expected:
x11forwarding yes x11uselocalhost yes
Install X authentication tools if required:
sudo dnf install -y \ xorg-x11-xauth \ xorg-x11-utils \ dbus-x11
Then disconnect MobaXterm completely and reconnect with X11 forwarding enabled.
15. Error: Oracle installer requires X display
One error encountered was:
ERROR: Unable to verify the graphical display setup. This application requires X display. Make sure that xdpyinfo exist under PATH variable. No X11 DISPLAY variable was set
This does not indicate an Oracle software problem.
It means the SSH session did not establish X forwarding.
The correct checks are:
echo $DISPLAY which xdpyinfo xauth list xdpyinfo | head
Once xdpyinfo works, runInstaller should be able to display through MobaXterm.
For unattended installations, the alternative is Oracle's silent response-file installation, which does not require an X display.
16. Error: INS-08101 supportedOSCheck
Starting the unpatched 19.3 installer directly resulted in:
[INS-08101] Unexpected error while executing the action at state: 'supportedOSCheck' java.lang.NullPointerException
The underlying issue is that the old 19.3 installer does not natively handle Oracle Linux 9 in the same way as later RUs.
Oracle's documented OL9 single-instance installation procedure explicitly sets:
export CV_ASSUME_DISTID=OL7
and applies a later Database RU during installation.
Therefore, rather than ignoring INS-08101 and installing bare 19.3, use:
export CV_ASSUME_DISTID=OL7
Then start OUI with the RU:
cd $ORACLE_HOME ./runInstaller \ -applyRU /u01/stage/patches/39472050
For your environment, substitute the actual current RU directory.
Do not permanently add:
CV_ASSUME_DISTID=OL7
to the Oracle user's profile. It is an installer compatibility setting and is only required during installation.
17. Oracle Universal Installer selections
For a Standard Edition deployment select:
Configuration Option: Set Up Software Only Database Installation Option: Single instance database installation Database Edition: Standard Edition 2
Configure:
Oracle Base: /u01/app/oracle Oracle Home: /u01/app/oracle/product/19.0.0/dbhome_1 Oracle Inventory: /u01/app/oraInventory Inventory Group: oinstall OSDBA: dba
Use the additional Oracle groups created by the preinstall RPM as appropriate.
The critical selection is:
Standard Edition 2
Do not select Enterprise Edition.
18. Error: compat-libcap1 missing
Another prerequisite warning encountered was:
Package: compat-libcap1-1.10 PRVF-7532: Package "compat-libcap1" is missing
Oracle's current Oracle Linux 9 Database prerequisite list does not include compat-libcap1; it does include packages such as compat-openssl11, libxcrypt-compat, libnsl and others.
Oracle also documents a known OL9 installation prerequisite issue in which the older installer reports compat-libcap1-1.10 as missing and permits this check to be ignored after other prerequisite issues are resolved.
The important rule is:
Do not blindly click "Ignore All".
First verify the real Oracle Linux 9 dependencies.
For example:
rpm -q oracle-database-preinstall-19c rpm -q compat-openssl11
Fix any genuine missing OL9 prerequisite packages.
Only then ignore the legacy compat-libcap1 prerequisite check if it remains.
Avoid installing random EL7 compatibility RPMs onto a production Oracle Linux 9 server simply to make an old prerequisite check turn green.
19. Run Oracle root scripts
Toward the end of OUI, Oracle requests privileged scripts.
Run as root:
/u01/app/oraInventory/orainstRoot.sh
then:
/u01/app/oracle/product/19.0.0/dbhome_1/root.sh
Return to Oracle Universal Installer and complete the software installation.
20. Verify the Oracle Home and RU
As the Oracle account:
$ORACLE_HOME/OPatch/opatch lspatches
and:
$ORACLE_HOME/OPatch/opatch lsinventory
Check SQL*Plus:
sqlplus -v
After database creation, also verify SQL patch registration:
SELECT patch_id, patch_type, action, status, description, action_time FROM dba_registry_sqlpatch ORDER BY action_time;
The RU should show:
ACTION = APPLY STATUS = SUCCESS
21. Configure the Oracle Listener
Run:
netca
Configure:
Listener Name: LISTENER Protocol: TCP Port: 1521
Verify:
lsnrctl status
and:
lsnrctl services
Only allow TCP/1521 through network firewalls from systems that actually need Oracle connectivity.
22. Create the database using DBCA
Start:
dbca
For a single-instance server select:
Create Database Advanced Configuration Oracle Single Instance Database General Purpose / Transaction Processing
Specify the database name and SID appropriate to the application.
Whether the database should be a CDB/PDB or non-CDB depends on the migration/application requirement.
For a new architecture, CDB/PDB should generally be considered. Where the objective is a like-for-like migration of a legacy non-CDB application, a non-CDB may be deliberately chosen for compatibility.
23. DBCA storage configuration
For the storage layout described earlier:
Database files: /u02/oradata Fast Recovery Area: /u03/fra RMAN backup destination: /u04/backup
A useful starting FRA limit on a dedicated 300 GB filesystem might be approximately:
270 GB
rather than setting the Oracle FRA quota equal to every byte available in the filesystem.
For example:
DB_CREATE_FILE_DEST=/u02/oradata DB_RECOVERY_FILE_DEST=/u03/fra DB_RECOVERY_FILE_DEST_SIZE=270G
Oracle explains that the FRA can contain archived redo, control-file copies, online redo, flashback logs and RMAN recovery files and should be sized according to the recovery strategy rather than merely database size.
24. Character-set selection during migration
This deserves special attention.
Our existing database had:
SELECT property_name, property_value FROM database_properties WHERE property_name IN ( 'NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET' );
Result:
NLS_CHARACTERSET US7ASCII NLS_NCHAR_CHARACTERSET UTF8
And:
SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ( 'NLS_LANGUAGE', 'NLS_TERRITORY' );
Result:
NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA
Therefore the new database was configured to match:
Database character set: US7ASCII National character set: UTF8 Default language: American Default territory: America
A common mistake is selecting:
AL32UTF8
because the existing database reports an UTF8 national character set.
These are different settings.
In this case:
Main database character set = US7ASCII National NCHAR character set = UTF8
For a completely new application database, AL32UTF8 would normally be the preferable modern choice. For a migration requiring a like-for-like NLS environment, however, changing the character set should be treated as a separate migration project rather than an incidental DBCA setting.
25. Verify Standard Edition 2 was actually installed
Once DBCA is finished:
sqlplus / as sysdba
Run:
SELECT banner_full FROM v$version WHERE banner_full LIKE 'Oracle Database%';
A correctly installed SE2 home/database should identify:
Oracle Database 19c Standard Edition 2 ...
If the output says:
Enterprise Edition
then the wrong edition was installed.
This is one of the simplest and most important post-install checks.
26. Determine whether the database is CDB or non-CDB
Run:
SELECT name, cdb, open_mode, database_role FROM v$database;
A non-CDB will report:
CDB = NO
In that case:
SHOW PDBS;
is not relevant because there are no pluggable databases.
If:
CDB = YES
then PDB configuration should also be verified.
27. Verify NLS configuration
Immediately after DBCA, check:
SELECT property_name, property_value FROM database_properties WHERE property_name IN ( 'NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET' );
For the migration example:
US7ASCII UTF8
Then:
SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ( 'NLS_LANGUAGE', 'NLS_TERRITORY' );
Expected:
AMERICAN AMERICA
Perform this check before importing production data.
28. Verify datafile locations
Run:
SET LINESIZE 200 SELECT tablespace_name, file_name, ROUND(bytes/1024/1024/1024,2) AS size_gb FROM dba_data_files ORDER BY tablespace_name, file_name;
Datafiles should reside underneath:
/u02/oradata
Check temporary files:
SELECT tablespace_name, file_name, ROUND(bytes/1024/1024/1024,2) AS size_gb FROM dba_temp_files;
Also:
SHOW PARAMETER db_create_file_dest;
29. Verify FRA
Run:
SHOW PARAMETER db_recovery_file_dest; SHOW PARAMETER db_recovery_file_dest_size;
Expected conceptually:
/u03/fra 270G
Check utilisation:
SELECT name, ROUND(space_limit/1024/1024/1024,2) AS limit_gb, ROUND(space_used/1024/1024/1024,2) AS used_gb, ROUND(space_reclaimable/1024/1024/1024,2) AS reclaimable_gb, number_of_files FROM v$recovery_file_dest;
Also:
SELECT file_type, percent_space_used, percent_space_reclaimable, number_of_files FROM v$flash_recovery_area_usage ORDER BY file_type;
FRA monitoring is important because a full FRA can eventually prevent new archive logs from being generated and therefore stop transactional processing.
30. Configure ARCHIVELOG mode
Check:
ARCHIVE LOG LIST;
If the database is not in archive mode:
SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN;
Check again:
ARCHIVE LOG LIST;
With the FRA configured, archived redo can use:
USE_DB_RECOVERY_FILE_DEST
Check:
SHOW PARAMETER log_archive_dest;
Generate test archives:
ALTER SYSTEM SWITCH LOGFILE; ALTER SYSTEM SWITCH LOGFILE; ALTER SYSTEM SWITCH LOGFILE;
Verify:
SELECT sequence#, name, completion_time FROM v$archived_log WHERE name IS NOT NULL ORDER BY sequence# DESC FETCH FIRST 10 ROWS ONLY;
The archive logs should be appearing underneath the FRA.
31. Multiplex control files
Oracle strongly recommends at least two control files on different physical disks.
Check:
SELECT name FROM v$controlfile;
Ideally the configuration protects against losing one storage volume, for example:
/u02/oradata/...control... /u03/fra/...control...
Check:
SHOW PARAMETER control_files;
Oracle writes to every control file specified by CONTROL_FILES, so loss of one configured control file still requires remediation, but multiplexing protects the database metadata from a single-disk loss.
32. Multiplex online redo logs
Check the current configuration:
SELECT l.group#, l.thread#, ROUND(l.bytes/1024/1024) AS size_mb, l.status, lf.member FROM v$log l JOIN v$logfile lf ON l.group# = lf.group# ORDER BY l.group#, lf.member;
A resilient design contains multiple members per redo group on different underlying storage, conceptually:
GROUP 1 /u02/... /u03/... GROUP 2 /u02/... /u03/... GROUP 3 /u02/... /u03/...
Do not assume DBCA created this arrangement—verify it.
Redo-log sizing should eventually be based on actual workload and log-switch frequency rather than database size alone.
33. Configure RMAN backups on /u04
The dedicated backup filesystem is:
/u04/backup
Create a database-specific directory:
mkdir -p /u04/backup/ORCL chown -R oracle:oinstall /u04/backup chmod 750 /u04/backup
Start RMAN:
rman target /
For a two-day recovery-window requirement:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;
Enable automatic control-file backup:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
Use compressed backupsets if appropriate:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
Review:
SHOW ALL;
34. Perform the initial RMAN backup
For example:
RUN { BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT '/u04/backup/ORCL/DB_%d_%T_%U.bkp'; BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL FORMAT '/u04/backup/ORCL/ARC_%d_%T_%U.bkp'; }
Then:
LIST BACKUP SUMMARY;
Maintenance:
CROSSCHECK BACKUP; DELETE NOPROMPT EXPIRED BACKUP; DELETE NOPROMPT OBSOLETE;
35. Understanding two-day backup retention versus five-day archive retention
These are different requirements.
For example:
RMAN recovery window: 2 days Local archive-log target: 5 days
A five-day archive-log retention period does not automatically provide a five-day database recovery window.
Recoverability depends on having both:
a suitable backup + all required archived redo
Oracle recommends coordinating the backup retention policy and archived-redo deletion policy.
Archive generation should be measured rather than estimated from database size:
SELECT TRUNC(completion_time) AS archive_date, ROUND( SUM(blocks * block_size)/1024/1024/1024, 2 ) AS archive_gb FROM v$archived_log WHERE completion_time >= SYSDATE - 7 GROUP BY TRUNC(completion_time) ORDER BY archive_date;
A 100 GB database could generate only a few GB of archived redo per day—or hundreds of GB—depending entirely on transactional activity.
36. Test RMAN recoverability
A backup job reporting success is not enough.
Perform validation:
RESTORE DATABASE VALIDATE;
Also validate archived redo where appropriate.
Review:
LIST BACKUP;
and:
CROSSCHECK BACKUP;
A production database should have a documented restore procedure and ideally periodic recovery tests.
37. Verify listener registration
Run:
lsnrctl status
and:
lsnrctl services
If necessary from SQL:
ALTER SYSTEM REGISTER;
Then:
lsnrctl services
Verify the required database service is registered.
38. Verify database health
Run:
SELECT instance_name, status, database_status, version FROM v$instance;
Expected:
STATUS OPEN DATABASE_STATUS ACTIVE
Then:
SELECT name, open_mode, database_role FROM v$database;
Expected for the primary database:
OPEN_MODE READ WRITE DATABASE_ROLE PRIMARY
39. Check the alert log
Oracle ADR will normally be located under:
/u01/app/oracle/diag
Use ADRCI:
adrci
Then:
show homes
Select the appropriate database home and inspect:
show alert -tail 100
Look for:
ORA- WARNING ERROR incident
after installation, startup, archive configuration and backup testing.
40. Configure automatic database startup
Check:
cat /etc/oratab
DBCA might create an entry resembling:
ORCL:/u01/app/oracle/product/19.0.0/dbhome_1:N
If you plan to use Oracle's dbstart/dbshut mechanism, change the final value to:
:Y
Then validate manually:
dbshut $ORACLE_HOME dbstart $ORACLE_HOME
For production, integrate Oracle startup/shutdown into the organisation's standard boot/service-management approach, such as a tested systemd unit or Oracle Restart where appropriate.
Do not wait for an unexpected VM reboot to discover that the database does not start automatically.
41. Perform a full VM reboot test
Before production cutover:
grubby --default-kernel
Verify the intended supported kernel.
Then reboot:
reboot
After the server returns:
uname -r
Confirm the expected RHCK kernel.
Then:
ps -ef | grep pmon
Check the listener:
lsnrctl status
Connect:
sqlplus / as sysdba
Verify:
SELECT instance_name, status, database_status FROM v$instance;
This simple reboot test validates several things simultaneously:
Kernel selection Filesystem mounts Oracle environment Database startup Listener startup Storage accessibility Database open status
42. Should the server be switched back to UEK8 after installation?
No—there is no reason to switch back simply because the installation has completed.
At the time of this implementation, Oracle Database 19c's OL9 requirements explicitly list:
UEK7 5.15 or later within that supported family or RHCK 5.14 or later
while Oracle Linux itself may install newer UEK generations depending on the OL9 update level.
Therefore, continuing to boot the documented RHCK 5.14 kernel is reasonable for a support-sensitive Oracle 19c environment.
The important distinction is:
Oracle Linux supports a kernel
does not necessarily mean:
Every Oracle Database release is certified for that kernel.
Keep the server patched within a supported kernel family and periodically review Oracle's current certification documentation.
43. Final Oracle 19c SE2 verification script
The following SQL provides a useful post-install snapshot:
SET LINESIZE 200 SET PAGESIZE 100 PROMPT === DATABASE EDITION / VERSION === SELECT banner_full FROM v$version WHERE banner_full LIKE 'Oracle Database%'; PROMPT === DATABASE === SELECT name, db_unique_name, open_mode, database_role, cdb FROM v$database; PROMPT === INSTANCE === SELECT instance_name, status, database_status, version FROM v$instance; PROMPT === CHARACTER SET === SELECT property_name, property_value FROM database_properties WHERE property_name IN ( 'NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET' ); PROMPT === LANGUAGE / TERRITORY === SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ( 'NLS_LANGUAGE', 'NLS_TERRITORY' ); PROMPT === CONTROL FILES === SELECT name FROM v$controlfile; PROMPT === REDO LOGS === SELECT l.group#, l.thread#, ROUND(l.bytes/1024/1024) size_mb, l.status, lf.member FROM v$log l JOIN v$logfile lf ON l.group# = lf.group# ORDER BY l.group#, lf.member; PROMPT === FRA === SELECT name, ROUND(space_limit/1024/1024/1024,2) limit_gb, ROUND(space_used/1024/1024/1024,2) used_gb, ROUND(space_reclaimable/1024/1024/1024,2) reclaimable_gb FROM v$recovery_file_dest; PROMPT === SQL PATCHES === SELECT patch_id, action, status, description, action_time FROM dba_registry_sqlpatch ORDER BY action_time;
44. Final operating-system verification
Run:
echo "=== OS ===" cat /etc/oracle-release echo "=== KERNEL ===" uname -r echo "=== DEFAULT KERNEL ===" grubby --default-kernel echo "=== ORACLE PREINSTALL ===" rpm -q oracle-database-preinstall-19c echo "=== ORACLE HOME ===" echo $ORACLE_HOME echo "=== ORACLE BASE ===" echo $ORACLE_BASE echo "=== STORAGE ===" df -hT /u01 /u02/oradata /u03/fra /u04/backup echo "=== PATCHES ===" $ORACLE_HOME/OPatch/opatch lspatches echo "=== LISTENER ===" lsnrctl status echo "=== ORACLE PROCESSES ===" ps -ef | grep -E 'pmon|tnslsnr' | grep -v grep
Keep this output with the server build documentation.
45. Production readiness checklist
Before application migration or production cutover, validate all of the following:
✓ Oracle Linux release validated ✓ Oracle-supported kernel running ✓ oracle-database-preinstall-19c installed ✓ All genuine Oracle Linux 9 prerequisites installed ✓ Transparent HugePages disabled ✓ /u01, /u02, /u03 and /u04 mounted correctly ✓ Oracle Database 19c RU applied successfully ✓ Oracle edition verified as Standard Edition 2 ✓ Database open READ WRITE ✓ CDB/non-CDB architecture verified ✓ Database character set validated ✓ National character set validated ✓ NLS language and territory validated ✓ Datafiles located under /u02 ✓ FRA located under /u03 ✓ ARCHIVELOG mode enabled ✓ FRA utilisation validated ✓ Control files multiplexed ✓ Online redo protected/multiplexed ✓ Listener operational ✓ Required database services registered ✓ RMAN configured ✓ Initial full backup completed ✓ RESTORE VALIDATE successful ✓ Alert log reviewed ✓ Automatic startup configured ✓ Complete VM reboot tested ✓ Application connectivity tested ✓ Monitoring configured
Lessons learned
The biggest lesson from installing Oracle Database 19c SE2 on modern Oracle Linux 9 is that the 19.3 download version should not be confused with the final Oracle patch level.
Oracle's OL9 procedure specifically calls for using the 19.3 Database Home image and applying a later supported RU during installation. It also explicitly documents CV_ASSUME_DISTID=OL7 for the OL9 single-instance installation workflow.
The second lesson is to verify the database certification requirements independently of the operating system's default kernel. Oracle Linux may offer newer kernels before a specific Oracle Database release's published requirements are updated for that kernel family.
The third is not to blindly resolve old installer prerequisite warnings by installing packages from older Linux releases. On Oracle Linux 9, validate requirements against Oracle's current OL9 package list, install genuine missing dependencies such as compat-openssl11, and distinguish them from legacy prerequisite checks such as compat-libcap1.
Finally, installation success is only the beginning. A production Oracle deployment is not complete until edition, patch level, character set, storage, archive logging, control/redo protection, RMAN backups, restore validation, listener connectivity and reboot behaviour have all been tested.
Conclusion
A carefully planned Oracle Database 19c Standard Edition 2 deployment on Oracle Linux 9 can provide a stable long-term database platform, but Oracle Linux 9 introduces several important differences compared with older 19c installation procedures.
Using a supported kernel, installing the Oracle Linux 9 prerequisite packages, applying a current 19c Release Update during installation, designing storage around separate database/recovery/backup areas, and completing rigorous post-install verification avoids many of the common problems encountered with 19c on OL9.
For organisations running Oracle databases on-premises, in Azure, AWS or other virtualised environments, the same principles apply: validate supportability first, separate database and recovery storage, patch before production use, and verify the recovery process—not merely the installation.
Onsys Technologies provides Oracle database installation, migration, performance tuning, patching, backup and recovery, health checks and managed DBA services for Australian businesses.