{"id":1472,"date":"2020-08-04T23:26:32","date_gmt":"2020-08-04T21:26:32","guid":{"rendered":"https:\/\/blog.sqlora.com\/en\/?p=1472"},"modified":"2020-08-04T23:31:47","modified_gmt":"2020-08-04T21:31:47","slug":"upgrading-a-19c-database-on-docker","status":"publish","type":"post","link":"https:\/\/blog.sqlora.com\/en\/upgrading-a-19c-database-on-docker\/","title":{"rendered":"Upgrading a 19c database on docker"},"content":{"rendered":"\n

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? <\/p>\n\n\n\n\n\n\n\n

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<\/a> is on 19.5.0, Oracle’s pre-built Developer VM<\/a> has 19.3 installed, autonomous databases in OCI free tier<\/a> are also on 19.5. So at the end I had to upgrade my docker DB.<\/p>\n\n\n\n

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!<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Official docker images on Github<\/a> provides an explanation of how to do it<\/a>. 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.<\/p>\n\n\n\n

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

\"\"<\/figure>\n\n\n\n

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<\/strong> including subfolders and files and name it 19.3.0<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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

\"\"<\/figure>\n\n\n\n

For Standrad Edition just do the same change in Dockerfile.se2<\/strong><\/p>\n\n\n\n

Download the patch ZIP-file and save it under patches\\001<\/strong>. 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<\/strong>. I decided to apply the latest RU 19.8.0, so i downloaded and saved two files: p31281355_190000_Linux-x86-64.zi<\/em><\/strong>p<\/strong><\/em> and p6880880_190000_Linux-x86-64.zip<\/em><\/strong> (Opatch)<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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

\n.\/buildPatchedDockerImage.sh -v 19.3.0 -e Patch\n<\/pre><\/div>\n\n\n
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:<\/p>\n\n\n
\n...\nJar Action: Destination File "\/opt\/oracle\/product\/19c\/dbhome_1\/assistants\/dbua\/jlib\/dbua.jar" does not exists or is not writeable\n'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'\nJar Action: Destination File "\/opt\/oracle\/product\/19c\/dbhome_1\/assistants\/dbua\/jlib\/dbua.jar" does not exists or is not writeable\n'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'\n\n\u001b[91mUtilSession failed: \nPrerequisite check "CheckApplicable" failed.\n\u001b[0mLog file location: \/opt\/oracle\/product\/19c\/dbhome_1\/cfgtoollogs\/opatch\/opatch2020-07-27_20-02-43PM_1.log\n\nOPatch failed with error code 73\nRemoving intermediate container 595216bc5332\nThere was an error building the image.\n\n<\/pre><\/div>\n\n\n
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<\/strong> some files are being removed:<\/p>\n\n\n
\n  # Remove not needed components\n    # APEX\n    rm -rf $ORACLE_HOME\/apex &amp;&amp; \\\n    # ORDS\n    rm -rf $ORACLE_HOME\/ords &amp;&amp; \\\n    # SQL Developer\n    rm -rf $ORACLE_HOME\/sqldeveloper &amp;&amp; \\\n...\n<\/pre><\/div>\n\n\n
This problem is described here: https:\/\/github.com\/oracle\/docker-images\/issues\/1187 <\/a>. And it seems to be addressed in one of the latest commits<\/a>. Before building the base 19.3 image, you can now set the argument SLIMMING in the Dockerfile to control the removal of files :<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
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.<\/p>\n\n\n\n
After that we can run a new container using the newly created image oracle\/database:19.3.0-ee-Patch<\/code>, for example as follows (of course the name of the container, post mappings, password and volumes will be yours):<\/p>\n\n\n
\ndocker run -d --name db198 -p 1543:1521 -p 5633:5500 \\\n-e ORACLE_PWD=mysecurepassword \\\n-v \/docker\/ora198:\/opt\/oracle\/oradata \\\noracle\/database:19.3.0-ee-Patch  \n\n<\/pre><\/div>\n\n\n
Connecting to the new database shows the patch was successfully installed<\/p>\n\n\n
\nSQL> select description, status\n  2  from DBA_REGISTRY_SQLPATCH;\n\nDESCRIPTION                                             STATUS \n----------------------------------------------------- ---------------\nDatabase Release Update : 19.8.0.0.200714 (31281355)    SUCCESS \n<\/pre><\/div>\n\n\n
<\/p>\n\n\n\n
Now I’m ready to do some tests with SQL macros again! But it’s a topic for the next post.<\/p>\n\n\n