Skip navigation

There’s no fighting progress. Decades ago database administrators managed and controlled everything – the OS, network, storage and database. Times have changed and DBAs have had to evolve (i.e. accept) well established principles of economics, namely specialization. Thus we have network administrators, storage administrators, virtualization administrators and database administrators. While it’s rarely very comforting to “give-up control”, DBAs have done so – even if begrudgingly. So now we have “the cloud”.

 

Once more things are evolving and DBAs have to again embrace a new way of doing things. And as with each and every evolutionary step, fighting the inevitable is a losing battle. The planets have aligned, the gods have spoken, the train has left the station, or whatever saying you prefer – we all will be deploying more and more cloud databases going forward. So just go with the flow. Better yet, embrace and “ride the wave”. So unless you’re really close to retirement and basically don’t care – you will need to “have your head in the clouds”.

 

But just as with every other evolutionary step where DBAs were worried about job security – the cloud does not eliminate the need for database administrators. It merely requires them to focus on other key aspects of managing a database. So while something critical like backup and recovery may be simply a questionnaire during cloud database instantiation, the DBA still has to know what choices to make and why. So in short, DBAs will be required to focus more on what vs. how. Moreover since everything in the cloud has a monthly cost – DBA’s will need to pay strict attention to capacity planning for storage and all other chargeable resources (e.g. CPU) in order to better assist management with controlling cloud costs. And as we all know “money talks”. So the DBA is just as important as ever.

I have written a book about Optimizing Oracle on VMware, plus have published papers and given presentations regarding the same. These basically all espouse essentially the same fundamental belief – that database virtualization is here to stay, and is rapidly moving towards mainstream (if not there already).

 

But a couple legitimate questions or concerns are always brought up (and they are good questions). I’m going to address the three that I hear most often, because I believe having the answers to just these will knock down 80+% of all the roadblocks to virtualizing your databases.

 

  1. Oracle does not support VMware. Not true. Roughly speaking – a little over a year ago their position was not to support any VM technology. Then about a year ago, once they got their own VM solution (OVM) - they supported that, but really not others. Then shortly after that, they opened up and now support non-OVM solutions such as VMware. But there is one very simple and reasonable caveat - Oracle support retains the right to ask the customer during troubleshooting efforts to at some point to re-host to non-VM in order to eliminate that possible point of contention. That’s more than fair. Plus with the Oracle acquisitions of Sun (who already had several VM technology offerings, including Virtual Box and Solaris Containers) and Virtual Iron – Oracle has truly become a virtual powerhouse in the VM arena (pun intended). So it’s in there best interest to support and propagate virtualization of everything – including databases.
  2. VM overhead is too debilitating for databases. Not true. Servers and memory are dirt cheap these days. And while storage costs have come down, the larger sizes of databases these days has grown to often eliminate savings. So today’s database servers have plenty of bandwidth to host more than one thing. And for those DBA’s overly concerned about the maybe roughly 10-15% overhead, CPU’s and memory are so cheap that factoring this cost into your cumulative or aggregate server needs is really not that big an issue – really. Often the direct power savings as well as the indirect power savings (e.g. lower cooling needs) can more than compensate for the minor increase in sizing calculations.
  3. Databases are too special or critical to virtualize. OK – BUT, DBA’s freely accepted virtualized storage for databases almost a decade ago. Gone are the days of going into the server room and pointing to your database’s disks. And since IO is the “Achilles Heal” or weakest link in terms of performance for any database, thus we’ve already virtualized the most important performance aspect. Thus it seems a little odd to debate or argue about virtualizing the remaining aspects, which generally impact database performance much less than the IO. So we’re just taking the next logical step in a progression we started a long time ago.

With these two issues put to rest, hopefully you and your management will more quickly embrace what’s inevitable – virtualization of database servers. Because none of us like swimming upstream. http://community.idera.com/emoticons/emotion-5.gif

I thought I’d write a quick blog this time and ask/think about what’s your favorite version of Oracle. Of course the proper answer is probably whatever version is mainstream right now – so maybe 11g R2. But what if you could enter Mr. Peabody’s “Way Back” time machine and once again live in any time you so desired. Then what version of Oracle would that be?

 

Now don’t laugh but one thought that came to mind was Oracle 6.0.36. It ran on DOS (with extended memory support), offered most of the essential database core features – and offered this cool option called PL/SQL. Just kidding – Oracle 6.0.36 was simply on my list since it was the first version one could run at home for learning purposes that did not require going out and buying a SPARC 20 workstation.

 

A genuine contender though would have to be Oracle 8.1.7. This version had many of the things most people routinely needed and yet was not over-bloated. What I mean is that it took just a little space to install and a little memory for the SGA and that’s it – so it fit real nice on a notebook, even an average one. So once again the winning hand was that ability to run the full blown Oracle database on minimal resources for both learning and experimentation.

 

I surely don’t mean any disrespect to either Oracle 11g or 12c – but it’s hard to forget such a memorable version as 8.1.7. Nonetheless these days we really must standardize 11g or 12c in order to have current technological minimums and amazing, must-have new features like multi-tenant (pluggable databases), in-memory column store tables, advanced compression and numerous other remarkable new features.

 

Finally special thanks to Oracle for offering the Oracle Express database. For many these smaller kin to the full database often offer an excellent minimal footprint, acceptable memory use and in most cases fully automatic installation and basic maintenance.