Five Trouble Spots When Moving
Databases to VMware
Guide for IT Managers
By Confio Software
Confio Software
4772 Walnut Street, Suite 100
Boulder, CO 80301
A White Paper by Confio Software, now part of the SolarWinds family
Production databases are among the last big software components to make the move to virtualization.
While other critical applications have been successfully transitioned to virtual servers in past five years,
IT management has been slow to transition production Oracle, SQL Server, and Sybase instances to
virtual servers. Even though the cost advantage of moving to VMware is quite compelling, there are
some very real risks associated with transitioning the production databases – namely the potential for
performance and availability impact on critical applications. However, now that Oracle and Microsoft
support customers hosting their software on VMware, the race is on to achieve the same cost savings
and flexibility benefits with virtualized databases that other applications have reached.
Now IT Managers are asking themselves if their teams are prepared to implement a successful database
migration to VMware. They want to know about the issues and how their organizations can best
respond to the challenge.
What risks?
VMware changed the rules about what server resources were required to keep a database responding
predictably, making it much more difficult for DBAs to see the interaction between the database and the
underlying server resources. Predictable performance and availability of databases are critical to
supporting the entire application stack.
Five trouble spots for VMware initiatives
Here are five scenarios unique to the virtual environment that merit particular attention for the
manager focused on a successful VMware initiative:
Inaccurate metrics –database server metrics on virtual servers are inaccurate
Dynamic resource allocation–shifting resources impact database performance
No control over host resources–other VMs on the host server affect resource allocation
Limited DBA Visibility – DBAs typically don’t have access to vCenter
Mutual Ignorance–vCenter is not aware of databases, and databases don’t know they’ve been
Inaccurate metrics
Using traditional database monitoring and performance tools, the status of server health metrics such as
CPU, memory, and storage are inaccurate on a VMware hosted servers. For example, if a virtual
machine is allocated 8GB of RAM, but has a 4 GB memory limit, what is the memory utilization for that
O/S if it's currently using 3.8GB? The O/S will report the memory utilization as 3.8 / 8 or 47.5%.
However, since there is a VM limit in place, the real utilization is 3.8 / 4 or 95%. The distinction has a
huge impact on database performance. This is one potential problem you will encounter if you use O/S
metrics for monitoring performance and availability.
Five Trouble Spots When Moving Databases to VMware
© 2011 Confio Software
A White Paper by Confio Software, now part of the SolarWinds family
Figure 1. Database Server Metrics Are Misleading
Dynamic resource allocation
VMware dynamically moves resources between VMs and moves VMs between different physical host
servers. What does the DBA see when a CPU is removed, memory is re-allocated, or the virtual server
changes to a new host? Nothing. A virtue of VMware is complete transparency for the application. But
when the application is a resource sensitive database, and the DBA team has years of experience
optimizing their instances to match available resources, hiding the underlying resources leaves the DBA
unable to perform their tasks and maintain performance levels. Without visibility to dynamic VM
changes, the DBA and the database are vulnerable.
Figure 2. Changing Resources Are Only Visible through vCenter
No control over host resources
When hosting databases on a physical server, changes occurring elsewhere do not affect the database
server. On a virtual platform, however, changes to allocated resources or new application loads on
other virtual machines sharing the same host server can significantly affect the response of a VM.
Without awareness of the other VMs and the systems they host, the DBA cannot understand the causes
or accurately respond to stresses on their own VM.
Limited DBA visibility
VMware Administrators use VMware vCenter, but because of security concerns and the expertise
required, they severely restrict access to vCenter. (This is no different than DBAs controlling access and
privileges in their database environment.) In surveys of organizational cooperation between different IT
infrastructure groups, fewer than 20% of DBAs reported having even limited visibility or experience with
vCenter and monitoring of VMware status. As a result, the DBAs responsible for database performance
and availability on VMware have no visibility to virtual server or host status, changes, and resources. No
Five Trouble Spots When Moving Databases to VMware
© 2011 Confio Software
A White Paper by Confio Software, now part of the SolarWinds family
tools or infrastructure typically exist to promote sharing of the most basic system status and change
notifications. While the Director of IT may want cross departmental cooperation, typical tools are
designed to prevent it.
Figure 3. The vCenter Client and Server Are Not Accessible to DBA Team
Mutual ignorance
DBAs have specialized tools and scripts for database monitoring, but these tools they are not aware that
the server is virtual, not physical. These tools, scripts and processes were all built for a physical
environment. And according to VMware, an operating system or application cannot tell the difference
between a virtual machine and a physical machine. And as explained above, the VMware administration
group cannot share their views and tools with the DBA counterparts. How can a DBA team be held
responsible for high availability systems without having accurate visibility to the servers they are hosted
Reduce risk with visibility
70% of application performance problems occur at the database level. And because databases have
such stringent performance requirements and are so sensitive to configuration changes, databases are
the most recent converts to VMware. Recommended configurations from VMware for Oracle, for
example, list multiple changes to database configuration and VMware settings required to optimize
availability. Moving databases without making them virtualization aware puts the entire VMware
initiative at risk. Be prepared to make the move. Give the DBA team the visibility needed to ensure
their success on the virtual servers.
Five Trouble Spots When Moving Databases to VMware
© 2011 Confio Software
A White Paper by Confio Software, now part of the SolarWinds family
Arm DBAs to be VMware sware
SolarWinds Database Performance Analyzer (DPA) VM Option is a specialized tool designed to give DBA
teams the visibility into the virtual layer required to successful manage databases in a VMware
environment. DPA VM Option helps DBAs maintain performance and availability when deploying
production databases on VMware. Because DPA VM Option combines essential database response
monitoring with non-intrusive VMware visibility, it gives IT management a way to reduce risk and ensure
the success of VMware initiatives.
Management deploys DPA VM Option for their DBA teams to help;
Reduce the risk of VMware projects
Speed the successful transition to VMware platforms and achievement of associated
cost savings
Enable teams to adapt to challenges of the VMware virtualized datacenter
DPA VM Option is agentless, with no software installed on production databases, virtual servers, or
About Confio Software
Confio Software, now a part of the SolarWinds family, builds award-winning database performance
analysis tools for DBAs and developers. SolarWinds Database Performance Analyzer (formerly Confio
Ignite) improves the productivity and efficiency of IT organizations. By resolving problems faster,
speeding development cycles, and squeezing more performance out of expensive database systems,
Database Performance Analyzer makes DBA and development teams more productive and valuable to
the organization. Customers worldwide use our products to improve database performance on Oracle,
SQL Server, Sybase and DB2 on physical and virtual machines.
For more information, please visit:
Five Trouble Spots When Moving Databases to VMware
© 2011 Confio Software
Download PDF
Similar pages