OpenWorld 2017: Docker 101 for Oracle DBAs

My team is looking at changing the way we manage Oracle.  First, we are looking at migrating off of Exadata and onto a different architecture.  But more fundamentally, we are questioning how we deliver database services and how we can drive innovation within the company by changing our processes and/or technologies.

Docker has come up as one such technology.  We have a lot of developers moving toward microcservice architectures and they need a good way to quickly spin up databases for development.  We also need to better standardize our processes across data platforms and improve our ability to scale environments based on a number of factors.  Adeesh Fulay did a great job of showing the state of containers as it pertains to the Oracle database.  The short is that Oracle and LXC are very mature, while Docker is quickly closing.  I am still very interested in seeing how we can leverage Docker containers and orchestration to improve our efficiency with Oracle as well as our other platforms.  My notes are:

Why Containers?

  • Comparison to Shipping Goods
  • Intermodal Shipping Contianer
  • Issue similar with IT
    • App with list of steps to deploy
    • Prone to mistakes
    • Need to solve dependency challenges
    • Also need to make good on promise of virtualization to provide mobility
  • Docker
    • Developer: Build once, Run anywhere
    • Operator: Configure once, Run Anything

Linux Container Overview

  • VM contains app and: Guest OS, libraries, etc.
  • Containers: No OS or Hypervisor
    • Own network interface
    • file system
    • Isolation (security) – linux kernel’s namespaces
    • Isolation(resource usage) – linux kernel’s cgroups
  • Why
    • OS-Based Lightweight Virtualization technology
    • Content & Resource Isolation
    • Better Performance
    • Better Efficiency and smaller footprint
    • Build, Ship, Deploy anywhere
    • Separation of Duties
  • Types
    • Application Containers
      • Docker
        • Requires application to be repackaged and reconfigured to work with Docker image format
      • One container, one app (primary app)
      • patch by replacing containers
      • good for modern applications
    • System Containers
      • Each container runs an entire service stack
      • LXC, OpenVZ, Solaris Zones
        • No need to reconfigure applications
      • Patch in place
      • good for legacy apps
    • Oracle and Docker
    • No RAC on Docker
    • LXC Support

Look Under the Hood

  • LXC is more mature with Oracle
  • Docker Host
    • daemon/engine – manages networking, images, containers, (data) volumes, plugins, orchestration, etc.
    • images
    • Dockerfile
      • Instructions for turning base image into a new docker image
    • containers
      • Like a directory. It is created from an image, and contains everything required to run an app.  Containers like VMs have state and are portable.
      • Containerd: Simple daemon that uses run times to manage
    • Volumes
      • Supports local or shared/distributed
      • Choose between mobility & performance
      • Docker outsourced issue of storage to other vendors
    • Networking
      • Types:
        • None: no external network
        • Host: shard host n/w stack
        • Bridge: NATing, exposing ports, poor performce
        • macvlan: uses host subnet, VLAN, swarm mode
        • Overlay: multi-host VXLAN, swarm mode
        • 3rd Party: OpenvSwitch, Weave, etc..
    • Orchestration
      • kubernetes
      • Mesos
      • Docker Swarm
      • Rancher
      • Nomad
      • ROBIN
  • Docker client
    • docker build
    • docker pull
    • docker run
  • Registry – Public or Private contains pre-build images

Getting Hands Dirty

Containerized Databases

Oracle late to the party but quickly catching up.  Has joined CNCF.  Working with kubernetes.  Using in Oracle cloud.


  • Advantages of VMs without the performance penalty





OpenWorld 2017: Getting the Most out of Oracle Data Guard!

We have been working to roll out Data Guard in our Oracle environment for a few years now.   The issues have not been technical, so much as other priorities getting in the way.  This session grabbed my attention as I was interested to see other use cases (other than HA and DR) that we could solve with Data Guard.  Ludovico Caldara not only put on a great session, but he did an outstanding job of making the materials available prior to the session on his blog.

Because he did such a great job, I won’t bore you with a lot of the details.  But he shows you how to use Data Guard to perform online database migrations, use the standby for reporting, and perform database clones.  It is all really cool stuff that my team could leverage if we finish rolling our Data Guard.


OpenWorld 2017: Best Practices for Getting Started with Oracle Database In-Memory 12c

Kicked off Oracle Open World with a great session on Oracle Database In-Memory.  The speaker (xinghua wei) did a great job of presenting both the technology itself as well as use cases and things to watch out for.  My team has started to look at the future of Exadata inside of our support model.  We have loved the performance we have gotten out of the appliances, but the coordination required to organize patching with Oracle and the hyper consolidation needed to justify the additional costs of running Exadata.

The biggest push back that I get from my team (and customer) is concerns with analytic workloads moving off the Exadata.  While it may not be the solution, Oracle’s In-Memory is one tool we have that could help with those concerns.  In this session I learned some new things that I did not know about In-Memory that will help us to better understand how it might play in our environment.  First, the feature is an extra sku, and a quick search gave $23K per CPU unit as the book price.  While not exactly cheap, it sure beats the heck out buying a whole Exadata.  More notes are included below.  I’m still not sure if this is something that we will use, but it’s nice to have a better understanding of the technology as we look at options other than Exadata.


  • In-Memory stores data in Columnar Format
  • Data exists along with traditional row based tables
  • 20% impact in TPS on row-based table associated with In-memory tables
    • Can be partially mitigated by removal of indexes on the tables that were used to support OLAP workloads
    • Results will vary based on a number of factors: design, workloads, etc.
  • Works with RAC and Data Guard
  • Differentiator vs. SAP HANA, SQL Server, DB2
    • 2 formats in 1 database (row and columnar)
    • 100% application transparency

RDBMs Platforms and Airline Seat Categories

So I just finished a weeklong trip to Northern Italy with the family. This was our first time bringing my children to Italy (My wife and I have been twice before, and I used to live in Italy for 3 years while in High School). I am also late in a process at work of bringing on support for an Highly Available MySQL solution. This effort at work is being performed by a group I lead which is made up of Microsoft SQL Server and Oracle DBAs that was recently formed out of two separate teams. As I was on the plane ride home (and trying hard to stay awake) I began to think of the differences between MySQL and SQL Server and Oracle.

Admittedly, we are not through the implementation phase in our MySQL rollout, but we have spent the past year researching and have engaged partners to help us architect and build out a highly available infrastructure for MySQL. As I sat in Economy Class with my wife and 3 children (the last two international trips my wife and I have taken were business class) I started to think that there is a lot of parallels between the 3 platforms and the 3 classification of travel on most international flights (Economy, Business, and First classes).

First, let me start by upsetting some of my SQL Server DBA brethren and say that Oracle is still the first class option in the RDBMS space. The price also reflects this reality. While the starting point for Oracle and Enterprise Edition of SQL Server are not that far apart, Oracle will get to a whole nother level quickly as you add HA and performance features that are already baked into the Enterprise Edition of SQL Server. But for that extra money you get options that just aren’t available in SQL Server (i.e. RAC and Exadata).

SQL Server fills the business class space in this analogy. Some would like to argue with me on this and talk about the value. But really, with all the recent changes to the Microsoft Licensing model for SQL Server pushing you into buying Software Assurance and putting all the HA options in Enterprise and deprecating Mirroring in Standard Edition I think I can win the argument that while there is still a lot of value, it is much more of a business class value point than an economy class one.

Just as in business class, where you pay a bit more for your ticket but all your drinks are included and the product is a bit more polished, buying SQL Server Enterprise Edition also covers 99% or potential needs and is very polished. I still have concerns about Microsoft’s trajectory for SQL Server and what it will do to the product long term, that is for a different post. So that leaves us with MySQL.

So far, I would say that MySQL is very much the economy class in this situation. First, I don’t see MySQL as being free (as in free beer) as some would argue. The support costs still exist. To be successful you will need to wither invest in training an/or support and this has a cost. Second, MySQL has matured to the point where it will get you to the same place as Oracle and SQL Server. In fact, I can make a good argument that MySQL (with Galera) provides a level of protection and performance that is not available in the other two if architected and used correctly. But, just as you have to work to sneak the extra drinks and snacks in economy class, there is far more work in architecting, building, and supporting these highly available environments in MySQL.

MySQL however provides you much more control over your costs. You can choose how much to invest in external vs. internal support. Companies like Facebook and Google pay to have experience on staff able to not only support MySQL but to also modify the code base. Most companies do not need this level of in house experience. Especially with so many companies now providing support for MySQL. For most all that is needed is a trained DBA and access to support from one of these vendors.

Well, that was my great revelation on the flight back from Europe. Now time to go try to sneak some champagne from Business class.