In the first part of our article on database virtualisation, we concerned ourselves with its pros and cons. In this second part, we are going to deal with the question of whether this technology should be implemented and what to watch out for. But first of all: what can actually happen if a virtual database disappears? The following, very real case from our data recovery lab, which clearly demonstrates such a situation:
When something actually goes wrong: a bank without a database!
Database virtualisation, like anything, doesn’t always run smoothly and considering its complex nature, there might be difficult challenges in data restoration in the event of a failure. We experienced this when an internationally recognised bank came to us for help.
The bank’s full customer and transaction virtual database was lost. The reason? After maintenance was performed, the VMware ESX server with three LUNs (Logical Unit Numbers) refused to work at all and could no longer be booted. The emergency cluster system also failed to work due to the replication link having not been previously disconnected. The database recovery turned out to be much more difficult than anyone had imagined at first. The server’s VMFS file system was heavily damaged and had to be reconstructed in several individual steps. Only after this was completed could the affected SQL databases be copied and thus a functioning new customer and transaction database be created.
So, what now? Database virtualisation: yes or no?
It is a fallacy to believe that you can cope with the growing volume of data only by virtualising databases. This is absolutely not true. Therefore, you shouldn’t virtualise any databases that are already working at almost full capacity in the real world. Before virtualising, you should first analyse the actual daily load behaviour and based on this, the required hardware resources. Only then can you really make sure that server consolidation doesn’t lead to a dramatic drop in performance because you are saving too much in hardware.
In addition, deciding whether virtualisation is actually convenient largely depends on the manner in which databases are implemented and used. It isn’t always true that the database server, regardless of whether SQL or Oracle, is really only utilised to a certain extent. The frequently mentioned figure of around 30 percent “wasted” utilisation is just for reference and it also applies to those database servers running only a few instances.
However, when it comes to one or more continuously addressed databases in the fields of business intelligence, data mining, online transactions or ERP/CRM, the whole affair should be looked at from quite a different perspective. In these cases it is quite possible that the database server already is undergoing almost full utilisation of its physical resources, i.e. processor, hard drives, SSDs, etc.
Whoever believes that non-existing resources can be conjured almost from nothingness by virtualising a database is much mistaken. Quite to the contrary: even with virtualisation of a database, only the existing hardware can be utilised more efficiently. And whoever chooses to ignore this, not only risks business-critical databases disappearing into virtual Nirvana in case of failure, but often also puts the entire company at risk, because in the end, availability, scalability and speed of a database system should be ensured at all times due to their critical importance for the business.
If something goes wrong there are very few companies able to recover their virtual servers and virtualised databases. Therefore, it is of the utmost importance to have a detailed emergency plan in stock for such eventualities. However, as many system failures and data loss situations are extremely complex and can hardly be solved by the employees themselves, it is advisable to avail yourself of a competent data recovery service when creating an emergency plan. Employing leading data recovery specialists such as Kroll Ontrack, who have already successfully solved many complex data recovery cases of disappeared virtual databases, is often the safest way to get your business-critical data back up and running quickly.
Image credit: Windorias / pixelio.de