Oracle provides the preinstallation RPM for Oracle Database version 11g and later, making the configuration and installation of Linux environments faster and easier. They eliminate many of the tasks database and system administrators perform to provision a new database host—creating users and groups, installing packages and dependencies, setting resource limits, and adjusting kernel parameters to satisfy database requirements—and assure organizations that their database environments are consistently (and properly!) built according to Oracle's recommendations.
Oracle introduced RPM-based installation of Oracle Database software with version 18c. In addition to creating and populating the Oracle Home, the RPM adds database creation through a service configuration script. The configuration calls the Database Configuration Assistant in the background and simplifies database creation. The entire process is performed by root and doesn't require interacting with DBCA, either through its GUI or via a response file.
This reduces the effort for users that want a database quickly. You needn't worry about how or what to run because it's done for you. It also has implications if you work with configuration management, deployment, and automation tools like Ansible, Chef, Docker, Puppet, or Terraform. Configuring prerequisites, installing software, and creating a database are reduced to three simple steps. This makes Oracle database installation more consistent with what you may find from other databases.
The ease and convenience of the Oracle RPM installation does come with some limitations:
These limits may lead you to conclude that package-based Oracle installations are only useful for quick and dirty database creation and not for operational workflows or "real" environments. The good news is that RPM-based installations can be modified and extended to address these limitations without too much effort while remaining automation-friendly! For example, Viscosity uses RPM-based installations for building Docker images and enjoys the same flexibility and options found in "normal" installations from the archive.
An RPM is a bundled set of files and instructions to install and configure software on Linux systems. RPM originally stood for Red Hat Package Manager but is now ubiquitous across many Linux flavors. RPM can be applied via the rpm command, but you may be more familiar with working with them through the yum package manager.
Installing software with a package manager has advantages - including simplicity, automation, and consistency.
Applying an RPM is a single command and eliminates most, if not all, human interaction. This makes installing software by RPM arguably safer, too. A single package file can be tracked and distributed through a repository, managed by version control, and validated with a checksum.
Modern provisioning workflows for Oracle often end before database installation. Prepared systems are handed off to database administrators, who complete the software installation and database creation and configuration. In many shops, this isn't a frequent event, and scripting the process may not make sense. Most DBAs have installed a database or two. The process is relatively straightforward, and carefully documenting methods can take a backseat to other, more important, and frequent tasks. Not to mention that we have the Internet, home to 1,001 ways to install Oracle!
This leads to environments of bespoke installations where base operating systems are built from configuration manifests, but databases aren't. Human involvement means we can't guarantee two environments are identical. With package-based installation, setup and configuration are built-in and assure identical outcomes across systems with the same foundation. Database installation and creation are easily adapted to existing automation without adding complex, database-specific instructions. This ultimately leads to leaner processes with functionality similar to other databases.
Installation by RPM can also result in a smaller footprint and take less time to run as well. Packages can be built to exclude unnecessary assets, and the Oracle 18c Express Edition RPM is a great example—it omits files and libraries for relinking the database binaries. The package installs Oracle "pre-linked," and those libraries and their relinking operations aren't needed. There is a potential downside to this I'll share later.
RPM installation is straightforward and well-documented by Oracle and on many blogs. Viscosity's team is no exception— Oracle 19c RPM Installation on OCI Free Tier and Installing the Oracle 19c RPM on Docker part 1 and part 2!
Briefly: download assets, apply the preinstallation and installation RPM, and run the configuration.
The Oracle Database RPM files for 19.3 Enterprise Edition and 18.4 Express Edition on Linux are available for download from the Oracle Database Software Download page.
The database RPM still requires a properly configured host. This is most easily accomplished with the appropriate preinstallation RPM.
On Oracle Enterprise Linux, the preinstallation packages are available locally.
On other systems, the preinstallation RPM must be downloaded. For Linux version 7, curl, install, and remove the RPM file:
For Oracle 18c, substitute the package name:
For installation, copy the Oracle Database RPM to a directory on the local system, cd to the directory, and perform a local yum install. For Oracle 19c:
There's no need to run the orainstRoot.sh or root.sh scripts; directory ownership and permissions are built into the package.
The Oracle inventory is created at /opt/oracle/oraInventory and the Oracle Home under /opt/oracle/product/19c/dbhome_1/.
Installation of Oracle 18c XE is similar:
The 18c Oracle Home is created as /opt/oracle/product/18c/dbhomeXE.
The RPM adds two additional files: a service file under /etc/init.d and a configuration file in /etc/sysconfig. The service file facilitates the creation and management of Oracle databases, including starting, stopping, and restarting the database and listener.
With the software installed, the next step is to create a database with a default setup using the service script with the configure option. For Oracle 19c:
For Oracle 18c:
This results in the creation of a standard database listener listening on port 1521 and a container database with a single pluggable database.
The default 19c CDB is ORCLCDB, and the PDB is ORCLPDB1.
The default 18c CDB is XE, and the PDB is XEPDB1.
If you need a database quickly and aren't interested in customizations, this is the end of the journey. For the rest of us—those who want to alter the defaults, extend the limits of package-based installations, or deploy Oracle software to different directory structures—this is the beginning!
Adaptations to Oracle's default RPM builds fall under two categories:
18c Express Edition and 19c Enterprise Edition database creation are controlled by two files that contain and control configurations. Altering defaults is done by changing these files prior to running the service file to configure a database.
Changing the Oracle Home and Oracle Inventory paths on 19c are done traditionally by moving and relinking the directories. Unfortunately, changing the Oracle Home for an 18c Express Edition database isn't an option. As noted before, the installation lacks the libraries needed to relink the Oracle Home. There's no way of moving the files and relinking Oracle. (Of course, it's unlikely you'll need to change an 18c XE database home to match something different since 18c XE can only be installed from RPM.)
There are two files of configuration in RPM-based installations. A very peculiar configuration file, and the database service file.
This file is located under /etc/sysconfig/oracledb_ORCLCDB-19c.conf for Oracle 19c and /etc/sysconfig/oracle—xe–18c.conf for Oracle 18c. For being a configuration file, it contains far fewer configuration options than you might anticipate:
If you have a need to change these ports or the data file location, edit this file before running the configure script.
The service file—the script called to configure and manage Oracle—is the source of most configurations you'd typically think of as "things to change." Located under /etc/init.d/oracledb_ORCLCDB-19c or /etc/init.d/oracle-xe-18c for Oracle 19c and 18c, respectively, the following entries appear near the top:
We can edit some of these entries to change the database setup:
(You can't change ORACLE_HOME here to alter the database software install location—by the time this script runs, the database software is already installed.)
Manual changes are a matter of editing the files. If the objective is something appropriate for automation, we can apply edits with sed and parameterize scripts with values passed at run time. That will work perfectly—you can change everything noted above, with the exception of ORACLE_SID.
To see why let's look at the code block that follows the environment variable settings:
Do you see it?
CONFIG_NAME (and CONFIGURATION) uses ORACLE_SID. If the SID is changed, a configuration file with the correct name must exist under /etc/sysconfig as expected by the service script.
When using RPM installations to create Docker images, I create the configuration file from a template as part of the container startup. I also overwrite the default service script with a custom version and replace the environment variables with boilerplate such as ###ORACLE_SID###. I then use sed to update the environment settings with whatever values are passed to the docker run command.
The configuration and service files combine to provide basic options for creating new databases. RPM installation buries the mechanism for creating databases inside service automation and streamlines the process. The mechanism itself is still the Database Configuration Assistant, but we don't need to create methods to interpret variables as we would if we called DBCA directly.
Code that's very specific to Oracle remains separate from the automation. It's not difficult to see how a few lines can be substituted as part of a template to create databases in general, passing common properties like database name and character set and using the same process to provision databases from multiple vendors; Oracle, MySQL, or others.
When the service script runs, it passes values set in the script itself, alongside those it finds in the configuration file, to DBCA. The call to DBCA looks like this:
These don't represent all options available with DBCA. For a more complete list, let's look at what's in the default response file under $ORACLE_HOME/assistants/dbca/dbca.rsp:
Theoretically, we can adapt the DBCA command in the service script to include any of those options. For starters, we can set the NLS character set with -nationalCharacterSet or define initialization parameters with -initParams.
Since the service file calls DBCA to create the database, any and all options available from DBCA are possible with an RPM-based installation—it's just a matter of updating the DBCA command in the service script to include the options we want!
The limitations of RPM installation, listed in the introduction, are a product of what Oracle chose to include under the service script's configure option. A relatively trivial change introduces all sorts of possibilities! If you're exploring this option, our recommendation is to update the DBCA command in the script to read a response file, then create response files with parameters and values generated at run time.
This allows us to create single instance, RAC, or RAC One Node databases; container databases with multiple PDB; enable security options like Database Vault and Label Security; use ASM, and disable AMM!
If your environment requires Oracle components to be installed in specific directories different from those used in the RPM installation, you can change them after the database software is installed. Unfortunately, they can't be altered as part of the installation itself. Packages embed directory paths, file ownership, and permissions. For Oracle database software installations, files are written to the system in an already-linked state and make relining and running root scripts unnecessary.
Once created, the Oracle Inventory and Oracle Home directories can be moved with a few commands. After moving directories, make sure to update the service file at /etc/init.d to reflect these changes.
The default location of the RPM-based Oracle Inventory—/opt/oracle/oraInventory, beneath ORACLE_BASE—oddly violates Oracle's own recommendations:
The recommended value for the inventory directory is /Oracle_base//../oraInventory, or one level above the Oracle base directory, in the oraInventory subdirectory. If your Oracle base directory is /u01/app/oracle, then the Oracle inventory directory defaults to /u01/app/oraInventory.
The following was used in the Docker build to change inventory locations:
When changing Oracle inventory and home directories, move the inventory first! The inventory pointer location is used when updating the Oracle Home.
As mentioned previously, the Oracle Home for 18c XE installations can't be changed because it lacks the libraries needed to relink. However, the 19c database is fully functional and can be relocated using Oracle built-in utilities.
In the Docker work, Oracle Homes installed from RPM can be moved with the following code:
In 19c clone.pl is deprecated but still available but may be de-supported in an upcoming release. For now, the same method works to move Oracle Homes for versions 11g onward and avoids the need for anything version-specific.
This method assumes the Oracle Base isn't changing. To change the entire Oracle Base:
Again, be sure to update the service script at /etc/init.d with the new paths for changed directories.
Package-based installation of Oracle 19c creates a fully-featured Oracle 19.3.0 Enterprise Edition database. There's nothing different about it besides the manner in which the software directories were created, and it's patched identically to a "normal" database.
After creating a new database environment from an RPM installation, it is recommended to apply Release Updates and patches prior to creating any databases; it reduces steps. Creating a database after patching creates a patched database. Patching after database creation requires stopping databases, patching software, starting databases, and running data patches.
As always, update OPatch with the latest version from My Oracle Support. For new software installations, there is no point in backing up the OPatch directory; you can simply overwrite it with the new version as part of building the environment:
From there, it's just a matter of applying the Release Update or patch. For building Docker images, the following was used to process numbered patch directories:
This looks for patches in numeric subdirectories under $PATCH_DIR and loops over them in order. It unzips the patch file and changes ownership, then navigates into the patch subdirectory. There, it looks in the README for the apply method and runs OPatch in silent mode.
One of the sayings we have at Viscosity is our customers "have four aces in their pocket." Over the next 11 days, the talented staff at Viscosity, along with our Oracle ACEs, will address more Oracle Database 18c and 19c new features. Continue to join us next year as we continue our Oracle Database 19c hands-on lab workshops.
Happy Holidays!