DevOps and the DBA: The Ghost in the Machine

An integral part of a DBAs job is monitoring – monitoring databases, resource usage, jobs and access.

Where most people may experience bad dreams about arriving at work and forgetting their pants, Database Administrators, (DBAs) nightmares revolve around showing up at work and being informed that there is a major outage on a production system or other high impact situation and being completely unaware.

Monitoring, along with alerting, is a big part of what makes us good at our jobs. The ability to alert on warning level issues before they become serious and resolving them makes for a better work environment for everyone.

DBAs understand the power of monitoring and depend on their own suite of monitoring scripts and infrastructure monitoring tools like Enterprise Manager, Solarwinds or SelectStar. This is just taking monitoring a step forward and incorporating the full development to deployment cycle into monitoring. The production DBA was often responsible for failures in releases and if this care of release management is broadened to DevOps, these failures are lessened. This goal should resonate in value with any database administrator. Increasingly, there has been a movement towards DataOps, which is a similar discipline to DevOps, but focused on the data tier. I will cover this topic in my next blog.


An integral part of a DBAs job is monitoring – monitoring databases, resource usage, jobs and access. Most DBAs become quite proficient at ensuring they know what’s going on before the business does. Knowing what is happening and addressing it before it becomes an issue is what keeps us employed.

Monitoring changes a bit with DevOps. It’s less about a simple tier and moves to the entire infrastructure. A need to monitor application, host, database and availability between each is essential. As these different tiers rarely come from one vendor and many may even be proprietary, there are requirements to monitor using multiple tools, scripts and interfaces.

Two of the main products for monitoring, recognized in the DevOps community are New Relic and AppDynamics. Monitoring can be as simple as a suite of scripts that report the health and status of processes and orchestration, notifying if there is any failure. This choice normally has a scaling limit and at some point, a more robust solution is required or gaps are felt in the monitoring process or failure at certain tiers. More enterprise solutions, such as New Relic and AppDynamics and enhanced by logging suites like Splunk and Sumo Logic.

Founded by Lew Cirne, New Relic (your eyes aren’t deceiving you, the company name is an anagram of Lew’s name), is a Software as a Service, (SaaS) monitoring and analytics tool that offers incredible insight into multi-tier environments.

Fig. 1:

Often partnered with database and infrastructure monitoring tools, such as Enterprise Manager, (Oracle) SolarWinds and Nagios, New Relic is able to monitor then able to assist in monitoring the entire stack.

I first fell in love with Oracle’s Enterprise Manager, (EM to DBAs), after my peer explained how much he loved my monitoring scripts, but confessed he didn’t want to be troubleshooting them at 3am. This was a clear signal that I needed a graphical user interface, (GUI) to ease the management of scripts I’d so carefully coded. After I became knowledgeable of the product, I found it wasn’t just a DBA tool, but a full infrastructure tool, which is what all of these products strive to be. The challenge for DevOps is that the industry is such a wide open field, and there are significant choices to fulfill monitoring depending on the tools your environment. It’s also common to require more than one monitoring product to create a complete monitoring solution.

This decision will be based on:

  1. Level of product, both requiring monitoring and the monitoring tool: Free, Freemium, Open Source or Enterprise
  2. Platforms involved
  3. Coding languages used
  4. Expertise level of team members

AppDynamics, like New Relic, is a newer company, (both founded in 2008) and monitors the application stack and provides analysis of performance changes. As with New Relic, it relies on other monitoring tools to grant a full view of the entire stack, but does offer some database tier monitoring.

Fig. 2:

The DBA is less likely to care about the application stack, but as the database is in the center of everything and guilty until proven innocent, we really should become more aware of these monitoring tools outside of the ones provided by the database engine manufacturers.

Competitive Push

With that said, some of the top relational database providers are enhancing their own monitoring tools to monitor more than just the database. Oracle’s Enterprise Manager, (and subsequently its SaaS product, Oracle Management Cloud, aka OMC) provides valuable insight into database monitoring and alerting, along with OMC’s Application Performance Monitor providing integrated insight into the application tier. They’ve also added Log Analytics to provide log mining insight similar to Splunk, which as discussed earlier on, is another DevOps favorite.

Slowly, but surely, the database industry of tools are coming around to supporting DevOps, recognizing the value, along with the important part the database plays into the pipeline of the development cycle. In no other area will you notice how much until you view the recent enhancements to what was once database monitoring.