Core Elements to run Oracle Databases in Docker Containers

Back in August 2015, while still working at Oracle, I came across this blog post which describes the steps of setting up an Oracle database to run in Docker containers.

This was a very useful post not just because it had all the steps that I could follow and setup my first Docker container but even way back in ’15 I could see the huge forthcoming value in containers as a lightweight virtualization alternative to run Oracle databases.

It’s almost two years later, are you running enterprise scale Oracle databases in Docker? Didn’t think so.

Today I see a number of blogs on the topic “How to setup the Oracle database and get going on Docker?”. Maria Colgan blogged about provisioning her first Docker-based database here and Steven Feuerstein also blogged on the same topic. It is nice to see so many bright minds warming up to the idea of running Oracle databases in a container.

In fact, Oracle has also recently certified its database in single instance configuration on Docker [2216342.1] and maintains a github repo with sample dockerfiles to build either an 11g or a 12c database.

However, these blogs talk about provisioning the database but, in reality, running a database at enterprise scale is much more than just setting it up. Provisioning a database for running any application is just the beginning of the journey. What about other lifecycle tasks?

In fact, there are several questions that are needed to be answered before the Oracle databases will see any serious adoption with Docker containers.

The core elements are:

  • Storage
  • QoS
  • Data Sharing
  • Availability

Storage: How do I configure storage for the Oracle database running in a Docker container?

In my opinion, this is probably the most important question when considering running an Oracle database using Docker. Running a database in a container actually provides the unique opportunity to decouple the compute from the storage.

You probably know that without decoupling, if the database ends up reading and writing data on the local disks of the server, any failure of that server will make the database unavailable.Furthermore,t is very important to ensure that storage for your database is configured in such a way that if the container or the host machine dies, it can be seamlessly repointed to a new container that is spun up in lieu of the failed instance in another host and thus prevents any data loss.

SAN and NAS devices that typically provide the backend storage for Oracle databases are neither aware of containers nor have the smarts to automatically repaint to a new container.

This transition from SAN or NAS to a container aware storage subsystem is key to the containerization of databases.

QoS: How do I consolidate without worrying about noisy neighbors?

One of the key virtues of virtualization is the ability to share the system resources across many applications. While traditional VM based virtualization has seen some adoption in Dev and Test systems, the inability to ensure predictable performance has forced enterprises to use bare metal servers for production databases.

Running databases in Docker will allow organizations to achieve even better consolidation density but without proper QoS on I/O, there is little chance that mission critical databases will be running in a container.

Data Sharing: How do I share data across environments?

I am often asked this or a slight variation of this question – “Will I be able to share data across Dev and Test environments if I run my application database using Docker?” The answer is Yes, if you plan and configure your storage correctly.

I am often asked this or a slight variation of this question – “Will I be able to share data across Dev and Test environments if I run my application database using Docker?” The answer is Yes, if you plan and configure your storage correctly.While all Oracle command line tools like RMAN or

While all Oracle command line tools like RMAN or datapump that support the database ecosystem are expected to work, there has been no announcement regarding Oracle Enterprise Manager support for Docker-based databases so far. Hence do not expect the Oracle Cloud management pack or other 3rd party tools to work for cloning right away.Cloning needs careful considerations and using a container aware storage that will ease out the task of copying and cloning data across different environments.

Availability: Can I ensure application availability across machine failures?

As I mentioned above, handling failover or relocation (read as managed failover) of the database instance by moving the container from one host to another is a very important requirement for running databases in general. Today a similar capability exists in RAC One but it requires a dedicated and often an idle machine for instance failover. Not to mention the extra license cost.

Containers are agile and can be moved around from one host to another with some networking work for very little application outage. A container orchestration utility that can automatically detect container failure and spin off a new container re-attaching the storage can be a great solution for setting up a single instance Oracle database with built-in HA.

We (Robin Systems) think Docker is a great alternative to traditional virtualization when running Oracle databases and built a platform that is purpose-built to run databases using containers.

Around Oracle in 80 seconds

Here is a sneak peak of some of the features of the ROBIN Hyper-Converged Kubernetes Platform and how it makes lifecycle management of Oracle databases ridiculously simple.


Author Deba Chatterjee, Director Products

More posts by Deba Chatterjee, Director Products