The Pros and Cons of Database Virtualisation

Thursday, 2 April 2020 by Ben Blomberg

Businesses have been steadily increasing the virtualisation of desktop applications, servers, and storage, so it should be no surprise that virtualising databases offers some undeniable advantages. In addition to less physical hardware, savings in energy, and simplifying the management of databases, virtualisation proves particularly well for very resource hungry applications, such as CRM or ERP systems. Benefits include:

  • Live migration: Virtual databases can be migrated from one physical server to another without interrupting operation.
  • Flexible and cost effective: Dynamic and automated deployment of new system instances and resources when needed.
  • Agile database development: Using different virtual machines (VM’s) with different database systems or versions enable the development or testing as part of the trial-and-error principle of agile software development. Different system stands can be adjusted, changed or deleted without much trouble, without the risk of impairing "finished" databases under certain circumstances.
  • Improved availability: By separating the VM’s from each other, the overall system can continue to run smoothly without sacrificing performance when problems occur with one VM.

Despite these advantages, if the application was carried out too quickly and without sufficient planning, it can also lead to significant issues.  There are several things to consider when implementing database virtualisation:

  • Hardware: Databases generally require a lot of resources, whether in a real or virtualised system. Virtualised database systems based on Microsoft SQL Server, as well Oracle and others, need sufficient processing power. If this is not provided by the VM, it may cause significant performance degradation.
  • Licenses: In some cases, such as in older Oracle databases, the previous database licenses cannot be transferred 1:1 to a virtualised system since the charges refer to the “potential” performance of the system and not what is actually used.  Therefore, it is important before a transition to size the environment and consider how many instances and processors will be used in order to get a comparison between the cost of a physically existing database server or its virtual counterparts.
  • Expertise: Databases by nature are complex, and that fact is not changed by virtualisation.  The new technology comes with an additional layer which adds complexity for database administrators (DBA’s). If there is no differentiation between virtualisation administrators and DBA’s, then the employee has to gain profound knowledge of database virtualisation in addition to their normal “know-how.”
  • Accountability: Many database administrators have no real access to the depths of the virtualisation layer, as this will be managed by IT administrators. When issues with a virtual database occur, either by an anomaly in the VM or virtual system, it often results in long delays in resolving the problem

Virtualisation is certainly not the “answer” to managing the ever-increasing volume of data. In some cases, the old saying “If it ain’t broke, don’t fix it” may apply here.  But if you find yourself on the investing end of virtualisation, considerations like organisational system and performance requirements, up-front investment costs, ongoing maintenance costs, and required internal resources all have to be assessed.  Integrating a solid plan early on will make managing your virtual environment much easier to manage and scale.