I’m neither an Oracle DBA, nor am I a Docker expert. How on earth did I get here to write this post? Well, I’m still an Oracle Developer and as you may have noticed, I was recently focused on SQL macros. It is a new feature of Oracle Database 20c, but obviously so awesome that it was backported to 19.6.0. Of course I asked myself, how can I start testing SQL macros in 19c?

For testing, blogging and so on I switched to using an Oracle DB on docker a while ago. Until now I was running a container with a 19.3 database. Before doing an upgrade I looked for other free options, also in terms of effort and skills needed, but without success: livesql.oracle.com is on 19.5.0, Oracle’s pre-built Developer VM has 19.3 installed, autonomous databases in OCI free tier are also on 19.5. So at the end I had to upgrade my docker DB.

As I mentioned, it’s not a typical day-to-day task for me and because it was a little bit tricky, I decided to write it up in this post. It’s more like a note for myself or maybe for you, if you are in a similar situation and have similar skills. On the other hand, if you are experienced in this topic, your comments are welcome! Feel free to point out better ways!

First of all, let’s clarify: we are not going to upgrade the database in existing container. Docker best practice is to create a new image instead.

Official docker images on Github provides an explanation of how to do it. Either you have already built and used a base image (oracle/database:19.3.0-ee in my example) or you have to build one first and then create a patched version of it. I had to rebuild my image anyway and I will show why.

So let’s start. If you’ve cloned the repository, the relevant path will be under \docker-images-master\OracleDatabase\SingleInstance\samples\applypatch. There you’ll find the structure like this:

Seems like nobody’s been concerned with newer releases lately. But it is pretty easy to fix. Create a copy of the folder 12.2.0.1 including subfolders and files and name it 19.3.0

Now we have to do a minor change to Dockerfile. If you’re working with Enterprise Edition, open Dockerfile.ee and change the name of the base image at line 21 and also in comments above:

For Standrad Edition just do the same change in Dockerfile.se2

Download the patch ZIP-file and save it under patches\001. If you have several patches to apply, you can create subfolder 002, 003 and so on and save further patch files in these folders. Patches often require the newer version of OPatch. Download the latest Version and save it under patches. I decided to apply the latest RU 19.8.0, so i downloaded and saved two files: p31281355_190000_Linux-x86-64.zip and p6880880_190000_Linux-x86-64.zip (Opatch)

We are ready to build the image now. Go into \docker-images-master\OracleDatabase\SingleInstance\samples\applypatch and run the command to build:

./buildPatchedDockerImage.sh -v 19.3.0 -e Patch

This can take a minute, so you can grab a cup of coffee. However, inspecting a log you will find that the build was not successful. Particularly, you’ll see a couple of errors at the end of the log file, something like this:

...
Jar Action: Destination File "/opt/oracle/product/19c/dbhome_1/assistants/dbua/jlib/dbua.jar" does not exists or is not writeable
'oracle.assistants.server, 19.0.0.0.0': Cannot update file '/opt/oracle/product/19c/dbhome_1/assistants/dbua/jlib/dbua.jar' with '/oracle/assistants/dbua/action/SummaryAction$2.class'
Jar Action: Destination File "/opt/oracle/product/19c/dbhome_1/assistants/dbua/jlib/dbua.jar" does not exists or is not writeable
'oracle.assistants.server, 19.0.0.0.0': Cannot update file '/opt/oracle/product/19c/dbhome_1/assistants/dbua/jlib/dbua.jar' with '/oracle/assistants/dbua/backend/BackupDatabase$DBInstanceInfo.class'

UtilSession failed: 
Prerequisite check "CheckApplicable" failed.
Log file location: /opt/oracle/product/19c/dbhome_1/cfgtoollogs/opatch/opatch2020-07-27_20-02-43PM_1.log

OPatch failed with error code 73
Removing intermediate container 595216bc5332
There was an error building the image.

It’s because OPatch tries to update those non-existent files. But why are these files not there? The answer is simple: they were intentionally removed while building the base image! As you can see at the end of installDBBinaries.sh some files are being removed:

  # Remove not needed components
    # APEX
    rm -rf $ORACLE_HOME/apex && \
    # ORDS
    rm -rf $ORACLE_HOME/ords && \
    # SQL Developer
    rm -rf $ORACLE_HOME/sqldeveloper && \
...

This problem is described here: https://github.com/oracle/docker-images/issues/1187 . And it seems to be addressed in one of the latest commits. Before building the base 19.3 image, you can now set the argument SLIMMING in the Dockerfile to control the removal of files :

Now we can rebuild the base image keeping all files and repeat the creation of the patched version. The patch succeeds without problems this time.

After that we can run a new container using the newly created image oracle/database:19.3.0-ee-Patch, for example as follows (of course the name of the container, post mappings, password and volumes will be yours):

docker run -d --name db198 -p 1543:1521 -p 5633:5500 \
-e ORACLE_PWD=mysecurepassword \
-v /docker/ora198:/opt/oracle/oradata \
oracle/database:19.3.0-ee-Patch  

Connecting to the new database shows the patch was successfully installed

SQL> select description, status
  2  from DBA_REGISTRY_SQLPATCH;

DESCRIPTION                                             STATUS 
----------------------------------------------------- ---------------
Database Release Update : 19.8.0.0.200714 (31281355)    SUCCESS 

Now I’m ready to do some tests with SQL macros again! But it’s a topic for the next post.

Related Posts

• Oracle 20c: SQL Macros
• SQL macros in Oracle 19c