Creating custom database binaries in Oracle Cloud Infrastructure

Oracle Cloud Infrastructure (OCI) enables users to run the database in many different ways. Starting with Infrastructure as a Service (IaaS) deployments all the way to Autonomous Database (ADB), you can choose the offering that suits you best based on how much control you want to retain (or give up). While researching Oracle’s Database Cloud Service (DBCS) I noticed a nice feature that you might also find worthwhile: custom software images.

Some Background

Depending on your choice of cloud deployment (IaaS – DBCS/ExaCS – ADB), administrators can be freed from some of the more mundane DBA tasks. The rule is simple: the more the service provider does for you, the less influence you have over how things are done.

Making changes to the database binaries in managed cloud environments is often impossible. In OCI it’s possible to create “custom” binaries, which is what this post is about. I was inspired by a recent post from @MikeDietrichDE about recommended patches on top of 19c. Let’s see if I can create a custom image in OCI using the My Oracle Support (MOS) note as the source.

Be advised that following the steps in this short article will cost you money. Please consult the OCI documentation for details.

Creating a custom set of binaries

I’m using the OCI Command Line Interface (CLI) to create the custom software image. To speed things up I ran the CLI commands from within the cloud shell.

Documentation References

The official documentation has more details about custom software images for DBCS systems if you like to get the full story. The CLI calls are described in a different section of the documentation. Note that I was using CLI version version 2.21.5.

Building the binaries

My goal is to create a custom set of binaries on top of 19.10.0, for example by including patch 123456789 (it obviously doesn’t exist, substitute it with your patch number). I didn’t run the compatibility check deliberately to see what happens. In the real world I strongly advise to test the patch strategy on a VM first to see if it works. The feedback loop is much tighter that way should any problem occur.

The command to create the software image is reasonably straight forward:

$ oci db database-software-image create \
--compartment-id "${CID}" \
--database-version "" \
--display-name "210322: custom 19.10.0 + 123456789" \
--patch-set "" \
--database-software-image-one-offs ' [ "123456789" ] '

Make sure not to forget any of the “.0”. According to the CLI you have to provide the one-off patch as a JSON data structure. It looks like a regular array of strings to me:

$ oci db database-software-image create \
--generate-param-json-input database-software-image-one-off-patches

Once you fire the command off, the prompt returns immediately and emits a JSON response with more details. The most important piece of information concerns the Oracle Cloud ID (OCID) of the new binaries as well as the corresponding work request ID. The actual work of creating the software home continues in the background.

Viewing progress is where the GUI comes in handy: simply navigate to Oracle Databases > Bare Metal, VM and Exadata > Database Software Images and you should see the new image along with its status. Otherwise query the state a few times until the lifecycle changes to “available”:

$ oci db database-software-image list -c "${CID}" \
--query 'data[].{release:"database-version",name:"display-name",state:"lifecycle-state",ru:"patch-set"}' \
--output table
| name                               | release  | ru        | state     |
| 210322: custom 19.10.0 + 123456789 | | | AVAILABLE |

Using the New Binaries

Once the binaries are created, you can specify the new binaries when creating a new database system. Still using Cloud Shell, I can create a database system with the new binaries quite easily:

oci db system launch \
--admin-password "${ADMIN_PWD}" \
--availability-domain "${AD}" \
--compartment-id "${CID}" \
--database-edition "ENTERPRISE_EDITION" \
--db-name DUMMY \
--shape "VM.Standard2.1" \
--ssh-authorized-keys-file /path/to/ \
--subnet-id "${DATABASE_SUBNET_OCID}" \
--database-software-image-id "${CUSTOM_BINARIES_OCID}" \
--db-unique-name DUMMY \
--display-name "custom binaries test" \
--initial-data-storage-size-in-gb 256 \
--pdb-name DUMMYPDB \
--hostname demohost \
--cpu-core-count 1 \
--db-version "" \
--node-count 1

Once the command completes I have a new database home including patch 123456789. When I checked the database home after the system provisioned I noticed that in addition to the one-off patch I requested a few others were present as well. So please make sure you check the exact status using $ORACLE_HOME/OPatch/opatch lspatches after provisioning completed. As with all changes to the underlying infrastructure, ensure rigorous testing ensues to find any potential issues there might be.


Oracle Cloud Infrastructure provides a very convenient way to create “customer-specific” database binary installations. The binaries are a regional resource and can be accessed from any AD in the region. According to the documentation they are stored in Object Storage.