By Darryl Smith — Chief Oracle Architect for EMC IT
In this blog (the third in a series on virtualizing Oracle), I will describe the best practices that EMC IT developed as we virtualized our most mission critical and highly transactional databases. You can find the earlier blogs here: [Running Oracle on Virtual Infrastructure Really Pays Off, Best Practices for Virtualizing Your Oracle Database]
There are two trains of thought when you talk to people about virtualization. From the infrastructure point of view, it is all about getting more efficiency out of the physical infrastructure layer. On one hand you can try to go extreme with this approach, but it will come at the expense of incurring higher administrative costs required to constantly troubleshoot performance and functionality issues. The other point of view is mainly about reserving all of the resources of the underlying servers, just in case the application needs it. Fortunately, with VMware vSphere you can have both, by using a more balanced approach.
I promised, in my earlier posts, that I would publish the secret sauce to achieving both great performance and high efficiency when virtualizing Oracle databases – so here it is. I have broken it up into four categories: memory, networking, CPU and storage (vSphere datastores). I will actually save the datastore best practices for the next and last post in this series, due to their complexity.
Let us jump in feet first into ‘database as a service’. So what do we mean by this ? We have three database platforms that we can provide ‘slices’ of to our business users. Oracle and SQL Server have been the traditional platforms we have built upon and Greenplum is something we have adopted quickly and which lends itself to ‘database as a service’ very well.
How have we done this ? Tier, Consolidate, Virtualize
Of course, this has been a journey on its own merit. We started off by looking at the database tiering models required based on business criticality, required availability and I/O profiles. At EMC, we separate the mission criticalapplications and databases (as in revenue impacting and/or customer facing, typically with stringent RTO/RPO and data loss constraints) from the business critical applications and databases (impacting subprocesses vs enterprise processes).
To gain efficiencies of scale, we decided to consolidate mission-critical Oracle and business critical into 3 and 8 node Oracle grid architecture (and along the way reduced the number of Oracle versions from 9 down to 1). We also consolidated and virtualized a number of production and non-production databases for the business critical side. This consolidation and virtualization exercise resulted in the reduction of databases and database servers from 50+ to single digits. This has provided the basic technology foundation for implementing database as a service on the Oracle platform. The current environment provides us a mechanism by which a large environment can be sliced to service different needs at different points of time, with standardized and published service levels and predictable scalability and performance.