Need some assistance for running Oracle Database on dockers

[kybrix]

I am bit new to dockers for Oracle DB and have few questions:

1)For the Quarterly patches /one-off patches, do I need to apply them using Opatch apply similar to on-prem dbs , eg copying files internally and then do an Opatch apply there? or

Do I need to apply the patch on the base image, create a new image and then run the docker container??

2) When i create a new image from the base image after applying patches, what is the recommended process for the data?? a) Will I have to export/import the data every time or b) Do I have to use unplug/plug pdb feature of the DB container c) or is there a way to use the existing db files rather than creating a new DB every time when you run a new image??

3) Has anyone seen any issues with larger DBs having many blobs running on dockers??

4) How can I use Kubernetes for the docker orchestration for Oracle db??

5) Also regarding licenses on dockers?? Does it tie with the docker or the infra on which the docker is running?

Thanks in advance for your time and support

[oraclesean]

1. Ideally, you should build patches into a new image rather than apply them to an existing container. There's information on this here: https://github.com/oracle/docker-images/tree/main/OracleDatabase/SingleInstance/extensions/patching.

2. This is a different mindset/approach than you'll find in a legacy environment, and the best way to handle patching and data is anticipating it when you create the initial container for your database by setting a data volume (option c):

   docker run -d --name my_db \
   ...
      -e ORACLE_SID=MYDB \
      -e ORACLE_PDB=MTPDB \
   ...
      --volume /path/to/data:/opt/oracle/oradata \
      oracle/db:19.3.0-EE

   This saves the database's data and configurations under the host's /path/to/data directory. Then, when you're ready to patch, create a new image (let's call it "oracle/db:19.19.0-EE") and replace the container:

   # Stop the existing container:
   docker stop my_db
   # Remove the existing container:
   docker rm my_db
   # "Recreate" the container using the new image and the same volume:
   docker run -d --name my_db \
   ...
      -e ORACLE_SID=MYDB \
      -e ORACLE_PDB=MTPDB \
   ...
      --volume /path/to/data:/opt/oracle/oradata \
      oracle/db:19.19.0-EE

   After startup, run the post-patching steps:

   docker exec -it my_db bash -c "/u01/app/oracle/product/19c/dbhome_1/OPatch/datapatch"

3. No, none that I've encountered.

4. There's information on K8s deployment here: https://github.com/oracle/docker-images/blob/main/OracleDatabase/SingleInstance/samples/kubernetes/README.md

5. I suggest directing licensing questions to your Oracle sales team, who can offer the most current and accurate answers. 😄 Hope this helps!

[kybrix]

Thanks it was really helpful.

for the volume-related question, will it work for the new container image or can I use the plug/unplug option there??

Another silly question: There is no option to download the container images from Oracle except docker pull command. Then how can I place the db images at the above folder location for patching

[oraclesean]

for the volume-related question, will it work for the new container image or can I use the plug/unplug option there??

You can still unplug/plug as before. A free sample chapter from my book is available here: https://oraclesean.com/blog/oracle-on-docker-is-now-available. It goes into more depth on volumes and persistence and might be helpful for you.

Another silly question: There is no option to download the container images from Oracle except docker pull command. Then how can I place the db images at the above folder location for patching

Not silly at all, but I want to be sure I'm following your question. Are you asking how to get the data and configuration files out of an existing Docker container, started without a volume, and into a directory where you can then start a new container database using a patched Docker image? If so, your options include:

• expdp/impdp the data/schemas to a dump file, or unplug/plug the PDB(s) to a directory inside the container. Then, use docker cp to get the file(s) out of the container and onto the local filesystem.
• Alternately, you can use docker cp to copy everything from /opt/oracle/oradata to the host. Unfortunately, the docker cp command doesn't accept wildcards (last I checked). Be sure to include hidden files (eg ls -la) else a new container won't properly recognize the database when started.
• If you mapped a port to the original container, you could use SQL Developer to extract the data to a location on the host.
• Create a new database container and connect the old/new containers over a Docker network. Then, follow traditional migration methods (expdp, autoupgrade, unplug/plug, SQL Developer) to move data between.
• Use docker commit against the existing container to save it as a tar archive. Then, extract the contents of the /opt/oracle/oradata directory to the host filesystem and docker run the patched database image against those files.

Does that help? Please let me know if you have questions about any of the above, and forgive me if this isn't what you were asking.

[kybrix]

Thanks Sean for the information.

My question was on the database image download. For creating my own image with patches, I would need to download binaries.

So do i need to download normal db binaries from edelivery and then put it in the Singleinstance folder or do i need to download it from the container portal (https://container-registry.oracle.com/)??

In case from container repository from oracle then there is no option to get a zip file from there. I can only pull images from the Oracle container repository via dockers and not a zip file.

Sorry for lame questions :-)

[oraclesean]

Ah, I understand now! Thanks for clarifying!

Correct—patched images aren't available in the container registry. You need to download the installation file from the Oracle Database download page and place it into the ./dockerfiles/[version] directory.

You can also get these from the eDelivery site; however, the file names will differ. The dbInstall.sh script expects the name and checksum of the installation file to match those from the database downloads page, not eDelivery, so you may need to be creative and either update the script or rename the file.

Patches are only available from My Oracle Support (MOS): https://support.oracle.com. You'll place those files into the patches subdirectory.

And questions like yours are great—they help those who develop and maintain repositories understand the real-world needs and challenges people encounter, leading to improved code and documentation. What you asked yesterday prompted me to think of all the ways of getting data "out" of a volume-less container, something I probably wouldn't have considered otherwise, and I'll develop it into a blog post.

[kybrix]

Thanks a lot that makes sense. I will try different ways and see..

I found a way to copy image out of the docker into zip file. So will try that as well.

[kybrix]

so i have already downloaded 19.3.0 from edelivery . Where is the dbInstall.sh located as I am not find any in the cloned repository??

[oraclesean]

Sorry, it's installDBBinaries.sh under the version directory.

[kybrix]

thanks..

One last question

What is the difference between

1) Applying the opatch when DB is already running on docker. Like the container is running and we can then apply patch normally as we do on VMs by copying it inside the location where docker can access and then apply it . or 2) By creating a new image using BuildContainerImageUtility and then applying the patch

[oraclesean]

Building an image creates a filesystem. Running a container creates a union filesystem that mounts the image in a "lower layer" and an empty "upper layer" for the container. Think of it as taking the tic-tac-toe board and placing a clear plastic sheet over the top: https://youtu.be/I-n2ZXMKGJw. The board is the image; the gameplay goes on the plastic sheet.

Changing files in the container "blocks" any view of the original copy. With the game/plastic sheet example, your eye interprets the view. In a union filesystem, the host has to calculate the difference. After making lots of changes in a container, it can get costly and can add to the container's size.

Patching in a container adds/changes dozens/hundreds of files to the ORACLE_HOME, but it isn't replacing them (as it would in a "traditional" database installation), inflating container size.

Patching as part of the build produces a "clean" image with just the end result.