Oracle 19c GoldImage Install on OL9.8 — Restart, ASM & 19.32.0

October 1, 2026 10 Min Read

In my previous Oracle Database 19c deployment on Oracle Linux 9.8, I documented the traditional installation approach using the 19.3.0 base software followed by patching to 19.32.0 RU.

In this article, I’m documenting a different approach:

Using Oracle 19c Gold Images created from an existing working 19.32.0 environment to deploy Oracle Grid Infrastructure and Database software on a new Oracle Linux 9.8 server.

The objective was to test whether a pre-patched Oracle 19c software home could simplify deployment and avoid repeating the traditional:

Install 19.3.0
      ↓
Upgrade OPatch
      ↓
Apply 19.32.0 RU
      ↓
Configure Oracle software

Instead, the Gold Image approach becomes:

Existing working 19.32.0 Home
             ↓
       Create Gold Image
             ↓
       Copy to new server
             ↓
       Extract software
             ↓
       Configure Oracle

This was a hands-on deployment in Oracle Cloud, and the article documents the actual commands, configuration, troubleshooting, and validation encountered during the process.

📂 Detailed Installation Commands & Output

This article focuses on the deployment approach, important configuration steps, troubleshooting and validation.

For readers who want to review the complete installation commands and actual command execution output, I have published the detailed command/output log separately on GitHub:

👉 Complete Oracle 19c GoldImage Installation Commands & Output Log

Quick Navigation

Environment and Gold Image Overview
Create the Grid Gold Image
Prepare the New Oracle Linux 9.8 Server
Configure OS Prerequisites and ASMLIB
Prepare the ASM Voting Disk
Deploy the Grid Gold Image and Run CVU
Install Grid Infrastructure and Configure Oracle Restart
Resolve the ASM Configuration Issue
Create the Remaining ASM Disk Groups
Deploy the Database Gold Image
Configure ASM Compatibility and Create the Database
Validate Database, SQL Patching and Oracle Restart
Traditional vs Gold Image Deployment
Key Findings and Conclusion

1. Environment and Gold Image Overview

The Gold Image used in this deployment was generated from an already working Oracle 19.32.0 environment.

The Grid Gold Image was approximately:

4.8 GB

A Gold Image is essentially a reusable Oracle software home that has already been installed and patched to the required version.

The important distinction is:

A Gold Image contains the Oracle software home. It should not be treated as a copy of the source server’s complete Oracle configuration.

OS configuration, users, ASM devices, response files, Oracle Restart configuration, ASM disk groups, and database creation still need to be performed on the target server.

2. Create the Grid Gold Image

The first step was to create a Gold Image from my existing working Grid Infrastructure 19.32.0 installation. I ran the following command from the existing Grid Home:

./gridSetup.sh \
-createGoldImage \
-destinationLocation /u01/app/oracle/software

Oracle generated the Gold Image as:

grid_home_2026-09-10_04-21-35AM.zip

with a size of approximately:

4.8 GB

This Gold Image represented the working 19.32.0 Grid software, which in this lab had originally been built from the 19.3.0 base software and patched to 19.32.0.

3. Prepare the New Oracle Linux 9.8 Server

The new Oracle Linux 9.8 server was prepared before deploying the Gold Image.

The preparation included:

Creating Oracle OS groups
Creating the oracle software owner
Creating the Oracle Inventory
Creating Grid and Database Home directories
Increasing filesystem capacity
Creating swap
Installing required Oracle RPMs
Installing ASMLIB
Installing CVUQDISK
Updating the operating system
Configuring required services

Create the Oracle User

The Oracle user was created with UID 1001:

/usr/sbin/useradd -u 1001 -g oinstall -G dba oracle

The final user configuration was validated with:

id oracle

showing UID 1001 and membership in the required Oracle and ASM groups.

Extend the OL9.8 Filesystem

The OL9.8 environment required the operating-system filesystem to be extended before continuing with the Oracle installation.

The tested sequence was:

growpart
   ↓
lvextend
   ↓
xfs_growfs

For example:

growpart /dev/sda 3

Configure 16 GB Swap

Create the swap logical volume:

lvcreate -L 16G -n lv_swap ocivolume

swapon -s

swapoff -v /.swapfile

mkswap /dev/ocivolume/lv_swap

Add the following entry to /etc/fstab and disable the old entries:

/dev/ocivolume/lv_swap  swap  swap  defaults  0 0

Enable:

swapon -va

Validate:

swapon -s
free -m

The final environment showed approximately 16 GB of swap.

4. Configure OS Prerequisites and ASMLIB

Install Oracle Prerequisites

Install the required packages:

dnf install -y perl xterm xhost

dnf install -y oracle-database-preinstall-19c

dnf localinstall -y oracleasmlib-3.1.3-1.el9.x86_64.rpm

Additional packages required by the installation were also installed.

The Grid Home contained the CVUQDISK RPM, which was installed using:

CVUQDISK_GRP=oinstall
export CVUQDISK_GRP

dnf install cvuqdisk-1.0.10-1.rpm -y

The operating system was then updated before continuing with the Oracle installation.

Finally:

yum update -y

Configure the Operating System

For this lab environment, several operating-system configuration changes were made before starting the Oracle installation.

These included:

vi /etc/selinux/config

SELinux was configured as permissive.

The following services were also stopped/disabled for the test environment:

systemctl stop firewalld.service
systemctl disable firewalld.service

systemctl stop chronyd.service
systemctl disable chronyd.service

mv /etc/chrony.conf /etc/chrony.confbkp

A symbolic link for sudo was also created for the CVU verification process:

ln -s /usr/bin/sudo /usr/local/bin/sudo

The following was also configured:

NOZEROCONF=yes

The server was then rebooted.

Note: These settings are specific to this lab/test environment. Production security, firewall, SELinux and time-service requirements should be evaluated according to the organization’s standards.

Configure ASMLIB

The Gold Image contains Oracle software, but the ASM storage configuration still needs to be prepared on the target server.

ASMLIB was configured with:

oracleasm configure -i

The configuration used:

Default user:  oracle
Default group: oinstall
Start on boot: y
Scan disks on boot: y

The ASMLIB service was restarted:

systemctl restart oracleasm

The resulting status showed that ASMLIB was using io_uring and that the ASM I/O filter was configured successfully.

5. Prepare the ASM Voting Disk

A disk was prepared for the Oracle Restart voting disk.

For example:

parted /dev/sdb --script -a optimal mklabel gpt mkpart primary 0% 100%

The disk was then labeled using ASMLIB:

oracleasm createdisk VOTK /dev/sdb1

After scanning the disks:

oracleasm scandisks
oracleasm listdisks

the following disk was available:

VOTK

6. Deploy the Grid Gold Image and Run CVU

Copy the previously generated Grid Gold Image to the new server.

The image was then extracted directly into the Grid Home:

unzip -q \
/u01/app/oracle/software/grid_home_2026-09-10_04-21-35AM.zip \
-d /u01/app/19.3.0/grid

At this point, the Grid Home contained the 19.32.0 software, rather than an unpatched 19.3.0 installation.

This is one of the major differences from the traditional installation approach.

Run Grid Prerequisite Checks

Before configuring Oracle Restart, CVU was executed.

First:

export CV_ASSUME_DISTID=OEL9

Then:

$ORACLE_HOME/runcluvfy.sh stage -pre hacfg

/u01/app/19.3.0/grid/runcluvfy.sh \
 stage -pre crsinst \
 -n caoradboelcl9 \
 -verbose \
 -method sudo \
 -user oracle

The prerequisite checks passed, including:

Physical memory
Swap
Free space
Oracle user
Oracle groups
User/group membership
Root consistency
Network connectivity

Result:

 Daemon "proxyt" not configured and running ...PASSED
  User Equivalence ...PASSED
  RPM Package Manager database ...PASSED
  Maximum locked memory check ...PASSED
  /dev/shm mounted as temporary file system ...PASSED
  File system mount options for path /var ...PASSED
  DefaultTasksMax parameter ...PASSED
  zeroconf check ...PASSED
  ASM Filter Driver configuration ...PASSED
  Systemd login manager IPC parameter ...PASSED
  ORAchk checks ...INFORMATION (PRVH-1507)

Pre-check for cluster services setup was successful.

A more detailed CRS prerequisite check was also executed using sudo, and the checks passed for ASMLIB, CVUQDISK, networking, user/group configuration and other prerequisites.

7. Install Grid Infrastructure and Configure Oracle Restart

For the silent Grid installation, I backed up the response file and modified it.

The important settings included:

oracle.install.option=HA_CONFIG
INVENTORY_LOCATION=/u01/app/oraInventory
ORACLE_BASE=/u01/app/oracle
oracle.install.crs.config.ClusterConfiguration=STANDALONE
oracle.install.asm.diskGroup.name=VOTK
oracle.install.asm.diskGroup.redundancy=EXTERNAL
oracle.install.asm.diskGroup.disks=/dev/disk/by-label/VOTK
oracle.install.asm.diskGroup.diskDiscoveryString=/dev/disk/by-label/*

Start the Grid software installation:

$ORACLE_HOME/gridSetup.sh \
-ignorePrereq \
-silent \
-responseFile /u01/app/oracle/software/gridSetup.rsp

The important point here is that the Grid Home was already populated with the 19.32.0 Gold Image.

The installer reported:

Successfully Setup Software.

It then requested execution of:

/u01/app/oraInventory/orainstRoot.sh
/u01/app/19.3.0/grid/root.sh

The root scripts were executed:

/u01/app/oraInventory/orainstRoot.sh

/u01/app/19.3.0/grid/root.sh

The Grid root configuration completed successfully and reported:

CLSRSC-327: Successfully configured Oracle Restart for a standalone server

8. Resolve the ASM Configuration Issue

This was one of the most interesting parts of the deployment.

The initial Grid software installation completed successfully, but the subsequent configuration tools reported:

[WARNING] [INS-43080]
Some of the configuration assistants failed, were cancelled or skipped.

The issue occurred during the stage where the ASM instance and initial voting disk group were being configured.

The initial CRS status showed:

ora.cssd       ONLINE
ora.evmd       ONLINE
ora.asm        not yet configured

This demonstrated an important distinction:

Installing the Grid software is not the same as completing the Oracle Restart + ASM configuration.

Instead of relying on the failed configuration assistant to create the initial ASM configuration, ASMCA was used.

asmca -silent \
-configureASM \
-sysAsmPassword "<REDACTED>" \
-asmMonitorPassword "<REDACTED>" \
-diskString 'ORCL:*,/dev/disk/by-label/*' \
-diskGroupName VOTK \
-diskList 'ORCL:VOTK' \
-redundancy EXTERNAL \
-au_size 4

ASMCA successfully reported:

ASM has been created and started successfully.

[DBT-30001] Disk groups created successfully.

After this step, the Oracle Restart resources showed:

ora.VOTK.dg    ONLINE
ora.asm        ONLINE
ora.cssd       ONLINE

9. Create the Remaining ASM Disk Groups

The additional ASM disk groups were created using ASMCA:

asmca -silent \
-createDiskGroup \
-diskString 'ORCL:*' \
-diskGroupName DATA \
-diskList 'ORCL:DATA' \
-redundancy EXTERNAL \
-au_size 4

The same approach was used for:

REDO
FRA

All three operations returned:

[DBT-30001] Disk groups created successfully.

10. Deploy the Database Gold Image

The same Gold Image concept was then used for the Database Home.

The Database Gold Image was extracted into:

/u01/app/19.3.0/db

using:

unzip -q \
/u01/app/oracle/software/db_home_2026-09-10_04-42-53AM.zip \
-d /u01/app/19.3.0/db

A database installation response file was then prepared.

The configuration used:

INSTALL_DB_SWONLY
ORACLE_HOME=/u01/app/19.3.0/db
ORACLE_BASE=/u01/app/oracle

Database Software Prerequisite Check

Before installing:

/u01/app/19.3.0/db/runInstaller \
-executePrereqs \
-silent \
-responseFile /u01/app/oracle/software/db_install.rsp

The prerequisite checks completed successfully.

I then installed the Database software:

/u01/app/19.3.0/db/runInstaller \
-silent \
-responseFile /u01/app/oracle/software/db_install.rsp

The installer reported:

Successfully Setup Software.

The database root.sh was then executed.

Verify the Database Home patches:

I verified the Database Home using:

/u01/app/19.3.0/db/OPatch/opatch lspatches

The output showed:

39526364  OCW RELEASE UPDATE 19.32.0.0.0
39472050  Database Release Update 19.32.0.0.260721

OPatch succeeded.

Again, there was no need to perform the traditional 19.3 → 19.32 database patching sequence on the target server.

11. Configure ASM Compatibility and Create the Database

Before creating the database, I checked the ASM disk groups.

Initially, the database compatibility value was:

database compatibility = 10.1.0.0.0
ASM compatibility      = 19.0.0.0.0

Set the database compatibility for all disk groups:

asmcmd

setattr -G VOTK compatible.rdbms 19.0.0.0.0
setattr -G DATA compatible.rdbms 19.0.0.0.0
setattr -G REDO compatible.rdbms 19.0.0.0.0
setattr -G FRA  compatible.rdbms 19.0.0.0.0

I then validated the values with:

select name,
       state,
       allocation_unit_size,
       compatibility,
       database_compatibility
from v$asm_diskgroup;

All four disk groups showed:

COMPATIBILITY           19.0.0.0.0
DATABASE_COMPATIBILITY  19.0.0.0.0

Create the Database Using DBCA

The final database was created using DBCA in silent mode.

The configuration included:

Database      : TESTCDB
PDB           : TESTPDB
Database Type : MULTIPURPOSE
Storage       : ASM
Data          : +DATA
Recovery      : +REDO
CDB           : Yes
PDB Count     : 1
Character Set : AL32UTF8

DBCA completed successfully:

100% complete.
Database creation complete.

12. Validate Database, SQL Patching and Oracle Restart

Validate the Database

Run:

select name,
       db_unique_name,
       database_role,
       open_mode,
       protection_mode,
       force_logging,
       switchover_status
from gv$database;

The result showed:

TESTCDB
PRIMARY
READ WRITE
MAXIMUM PERFORMANCE

Validate Database Components

select comp_name,
       version,
       version_full,
       status
from dba_registry;

The relevant components reported:

VERSION_FULL = 19.32.0.0.0
STATUS       = VALID

Validate SQL Patching

select install_id,
       patch_uid,
       patch_id,
       action,
       status,
       action_time,
       description,
       source_version,
       target_version
from dba_registry_sqlpatch;

The 19.32.0 Database Release Update showed:

PATCH_ID       39472050
ACTION         APPLY
STATUS         SUCCESS
TARGET_VERSION 19.32.0.0.0

Final Oracle Restart Validation

The final Oracle Restart resource status showed:

ora.DATA.dg       ONLINE  ONLINE STABLE
ora.FRA.dg        ONLINE  ONLINE STABLE
ora.LISTENER.lsnr ONLINE  ONLINE STABLE
ora.REDO.dg       ONLINE  ONLINE STABLE
ora.VOTK.dg       ONLINE  ONLINE STABLE
ora.asm           ONLINE  ONLINE Started,STABLE
ora.cssd          ONLINE  ONLINE STABLE
ora.evmd          ONLINE  ONLINE STABLE
ora.testcdb.db    ONLINE  ONLINE Open,STABLE

This confirmed that:

SQL patch level was 19.32.0
Oracle Restart was operational
ASM was online
all ASM disk groups were online
the database was online
the database was managed by Oracle Restart
SQL patch level was 19.32.0

13. Traditional vs Gold Image Deployment

This deployment demonstrated the practical difference between a traditional Oracle 19c installation and a Gold Image-based deployment.

Traditional approach

19.3.0 Base
     ↓
Install
     ↓
Upgrade OPatch
     ↓
Apply 19.32 RU
     ↓
Configure

Gold Image approach

Working 19.32 Environment
          ↓
    Create Gold Image
          ↓
      Copy Image
          ↓
    Extract to Home
          ↓
      Configure

The target server therefore received pre-patched 19.32.0 Grid and Database software, avoiding a separate patching operation after installing the base software.

The lab also demonstrated an important practical point:

Gold Image deployment simplifies the software installation and patching portion, but it does not eliminate target-server configuration.

OS prerequisites
Users/groups
ASMLIB
ASM disks
Oracle Restart configuration
Response files
ASM disk groups
Database creation
Validation

That is one of the most important lessons from this exercise.

14. Key Findings and Conclusion

This Gold Image test demonstrated that a pre-patched Oracle Home can significantly simplify the software installation and patching portion of a repeated Oracle deployment.

Instead of performing this sequence on every server:

Install 19.3.0
      ↓
Update OPatch
      ↓
Apply 19.32.0 RU

the target server receives the already patched software home.

The overall workflow I successfully tested was:

Working Oracle 19.32 Environment
             ↓
Create Grid Gold Image
             ↓
Prepare OL 9.8 Target Server
             ↓
Configure OS + ASMLIB + ASM Disk
             ↓
Extract Grid Gold Image
             ↓
Run CVU
             ↓
Install Grid Software
             ↓
Configure Oracle Restart
             ↓
Configure ASM / VOTK
             ↓
Create DATA / REDO / FRA
             ↓
Extract Database Gold Image
             ↓
Install Database Software
             ↓
Configure ASM Compatibility
             ↓
Create Database with DBCA
             ↓
Validate Database Components
             ↓
Validate SQL Patching
             ↓
Validate Oracle Restart

The most interesting troubleshooting issue was:

INS-43080
Some of the configuration assistants failed,
were cancelled or skipped.

The Grid software installation itself had succeeded.

The failure occurred during the ASM/voting-disk configuration phase.

Explicitly configuring ASM with ASMCA resolved the issue:

asmca -silent \
-configureASM \
...
-diskGroupName VOTK \
-diskList 'ORCL:VOTK' \
-redundancy EXTERNAL \
-au_size 4

After that, ASM and the voting disk group came online successfully.

For environments where the same Oracle version and patch level need to be deployed repeatedly, Gold Images can provide a much cleaner and more standardized software-deployment approach.

In this OL9.8 environment, I successfully tested:

Gold Image
   ↓
Grid 19.32
   ↓
Oracle Restart
   ↓
ASM
   ↓
Database Gold Image 19.32
   ↓
DBCA
   ↓
SQL Patch Validation
   ↓
Final Oracle Restart Validation

The complete command execution log—including the actual installation output and troubleshooting—is available separately in GitHub.

This article represents hands-on testing. Production deployments should always be evaluated against the applicable Oracle documentation, certification/support requirements, security standards, and platform-specific prerequisites.

My earlier article documents the traditional Oracle 19c installation approach on OL9.8, including the 19.3.0 → 19.32.0 patching process.

👉Oracle 19c on OL9.8 – Silent Install, ASM, Restart & 19.32

That article demonstrates the:

19.3.0 → OPatch → 19.32.0 RU

approach, while this article demonstrates deployment using pre-patched 19.32.0 Gold Images.

📂 Detailed Installation Commands & Execution Output

The complete installation command sequence and actual execution output from the deployment are available on GitHub.

👉 Oracle 19c Oracle Linux 9.8 — Gold Image Installation Commands & Execution Output

This article documents my own hands-on installation and troubleshooting experience. Always verify the Oracle support matrix, certification information, RU requirements, and platform-specific prerequisites for your target environment before implementing the procedure in production.

Tags: