IOUG Survey
Last year, Dell EMC sponsored the 2020 IOUG Database Priorities Survey. One of the questions was, “What leading factors do you weigh when selecting infrastructure for your Oracle environment?”

The number 1 factor respondents mentioned, was “Cost”. This confirms my own experiences when talking to our customers. High cost is often the main decision factor, followed closely by performance (#2) and a number of other factors, most of which I tend to categorize under the umbrella term “IT Operations”. As you may know from reading some of my other blogposts, I am passionate about achieving maximum efficiency for business applications – which is also the reason for choosing the name of this blog (Dirty Cache) since 2011.

Being an Oracle specialist, my primary focus is on Oracle database and applications – although one could apply the same principles on other technology stacks.

In the past, I have written several posts about this topic, most of them still relevant after many years. But the time has come to unveil a complete strategy of achieving the highest possible cost efficiency – within realistic boundaries – on which I have been working for several years now.

So first, let me define our mission statement:

Mission statement

  1. Work together with our customers to achieve the maximum achievable return on investment (ROI) out of an Oracle infrastructure, without any compromise on performance or other service level objectives (SLOs)
  2. Protect our customers from database license compliance problems and minimize related financial risk
  3. Simplify and/or automate IT operations on database applications where possible (such as managing scale, disaster recovery, high or even extreme availability, backup/restore, replication, etc.)

Introducing Maximum Efficiency Architecture

In order to achieve the goals stated above, I started working on an architectural description of what such an environment should look like. The name I gave this methodology is “Maximum Efficiency Architecture” (MEA). It is not a finished project, and it may never be. See this more as a new paradigm rather than a complete ready-to-go design or product that you can download or buy, deploy and forget about.


Maximum Efficiency Architecture is defined (in a database context) as:

A service platform to run multiple relational databases in the most cost-efficient way possible, within required business and operational service levels and requirements.

MEA is built upon the cloud computing paradigm.

Key characteristics of Maximum Efficiency Architecture:

  • Total isolation between services/workloads (databases, database instances) and infrastructure hardware
  • Dynamic data mobility (workloads must be able to move freely between infrastructure resources without interruption)
  • Lean and mean (only deploy hardware and software that is absolutely needed and/or provides business benefits that outweigh the cost)
  • Replace aging hardware when it makes sense. This may be sooner or later than when the hardware is depreciated
  • Rock Solid Infrastructure (think of high availability, scalability, reliability, performance, data integrity, security, disaster tolerance)
  • Avoids vendor or technology lock-in wherever possible
  • Use of best-of-breed, commercial off-the-shelf products where possible. Avoid specialized, single purpose hardware
  • Use of commonly accepted, standardized building blocks, components and best practices that most other customers are also using. Avoid obscure, exotic pieces of (software) technology that few others use
  • Provide a foundation for “database-as-a-service” service models


Maximum Efficiency Architecture could be applied to many types of IT services but, as mentioned, my focus is Oracle and so we limit the scope to Oracle database (for now). There is a trend in IT to move to other, often Open Source, database platforms such as PostgreSQL – which we fully endorse but is out of scope (for the time being).

Although it makes sense to also look at other tiers such as applications, middleware, or end-user clients, we don’t want scope creep. The database is usually where most of the CPU, memory and IO resources are required, where things may seem complicated but also where usually the most efficiency gain is possible.

What “Maximum Efficiency Architecture” is not:

  • A product

MEA is not a product. We don’t have a line item you can order and install that magically improves your efficiency and lowers TCO. MEA is an architecture and methodology we want to achieve together with our customers. This means it will only work if all parties involved are committed to the results, not just the infrastructure vendor (Dell). We will demand this commitment before we start, otherwise all our efforts will be futile.

  • A finished, ready to go methodology

We have come a long way, but MEA is still work in progress. When rolling this out at many customers, there were issues that had to be resolved, both technical and operational. Technology is not perfect and sometimes we need smart solutions to work around specific problems or product limitations. But it has been done before and with major success.

  • A project with a deadline

A project or program is certainly part of MEA, but when the project is finished, it’s not when everyone can go back to business as usual. MEA is a paradigm shift in how to operate and manage databases and needs to be part of day to day operations going forward, to make sure the efficiency gains are not a one-off, but a consistent part of the IT culture, and the responsibility of many, including DBAs, IT management, purchasers, IT partners and, last but not least, vendors like Dell.

In the next series of posts, we will explore this in more detail.

We will discuss the current state, how we define KPIs and metrics, how we measure and calculate the actual efficiency of existing landscapes, what a future state should look like and why, what sizing rules we can or must apply, how we eliminate costly components with better or more cost-effective alternatives, how we deal with special cases, licensing, if we should consider (public) cloud alternatives, and finally, how we measure our actual achievements after the initial roll-out has been completed.

Stay tuned.

This post first appeared on Dirty Cache by Bart Sjerps. Copyright © 2011 – 2021. All rights reserved. Not to be reproduced for commercial purposes without written permission.


Reducing Oracle TCO: Maximum Efficiency Architecture
Tagged on:                         

Leave a Reply