Applying the first RU (Release Update) for Oracle Database 126.96.36.199 on Docker environment
There is great post on Applying the first RU for Oracle Database 188.8.131.52 written by my friend Mike.
But this post is about on how to apply this important patch on Docker environment using official Oracle Docker images.
First, some time DBAs have fear on applying patches for two important thing:
- What happen if something goes wrong, how to rollback this process quickly on production
- Which is my downtime, also apply on production systems where minutes means money
Well, on Docker environment this two points are quickly answered:
- You could rollback the patch on binaries by simply stop your Docker container started with the RU image and go back using the official image, remember that on Docker environment bin/libs are part of the layered file-system where your container start and it acts like an SVN branch, if you want to go back with the changes made on the binary files modified by a patch you can rollback this change stopping your container and starting again using the previous used image.
- The downtime as I will show below is only the time involving by shutdown your database, and starting it again with the new image, the time for patching your binaries are NOT part of your downtime, when the database startup for the first time with a new patched image there is only a fixed time of datapatch utility which is called once.
Let see in action, first check that you have the two Oracle Database Release 2 images ready at your local repository:
If you have a running container with the official R2 base image oracle/database:184.108.40.206-ee, the start script may be look like:
note that your datafiles reside outside the container as usual to survive the stop/start/rm container life-cycle which obviously make sense for an production database.
Now I will patch this database with first RU patchset, for doing that a run command will point to the image patched with 26123830 patchset, here an screenshot:
here the process for applying a patch:
database downtime is about:
- 0m4.869s (docker rm -f demo)
- 0m8.503s (docker run with new image, ./run-demo-patch.sh file)
- 1m20s (time taken by SQL Patching tool starting time 12:43:06, ending time 12:44:26)
Not bad for my modest laptop.
But what are under the hood on the new patched imaged with the RDBMS RU included?
First there is an official script provided by Oracle to apply generic patches to the official image, here the link at GitHub, but this script doesn’t take into account the post-processing task during first startup time, so I decided to provide mine using this Dockerfile and modified startDB.sh script.
Here the explanation of Dockerfile, first the Docker image tagged oracle/database:220.127.116.11-ee-26123830 is built on top of oracle/database:18.104.22.168-ee.
next we have to put a downloaded patch zip file in this directory and is referenced with the line:
then the Docker script file continues with Mike’s suggestions and leaves a similar entry point for this container as in the official Dockerfile.ee script.
Finally startDB.sh script was modified to have a hook which control if the post apply stage of the patch was applied or not, here the logic:
For building a new image with the patch applied on binary/libs file is simple as calling docker with:
docker build -t “oracle/database:22.214.171.124-ee-26123830” .
Note that the process described above could be executed by an experimented DBA or a DevOps operator, and the process of stopping a production database and starting again with the patch installed could be executed by a novel DBA or any other operator.