The Operational Cost of Many Databases
When most enterprises calculate the total cost of managing their databases, they take into account only
license and maintenance fees, hardware costs, and depreciation. They tend to overlook the staff cost, yet
multiple total cost of ownership (TCO) studies conducted by IDC have found that more than 60% of the
average cost of running a database over any given five-year period is represented by staff cost.
Most enterprises have fixed staffing budgets and so must make do with what they have. Thus that staff
resource is spent largely on activities such as remapping data to storage, reindexing databases,
repartitioning databases, unloading and reloading databases, and applying and testing patches and
software upgrades. While these are necessary activities in any database environment, it is also the case
that as the number of databases increases, the staff time required to manage them increases on a linear
scale as DBAs perform the same tasks over and over on each database instance. This is because the
databases are all separate and cannot share key resources. Such sharing would enable the
management of some aspects of database operation on a collective basis rather than an individual basis.
The Software Configuration Nightmare
As the number of databases increases, so does the maintenance effort. In addition, when enterprises
apply upgrades that may impact applications, those application maintenance activities must be
coordinated with the specific databases they use, so there is a careful maintenance scheduling effort
involved. The complexity of that effort is multiplied by the number of applications and databases involved.
Also, because application changes require the creation of a development or test database, copied in
whole or in part from production, and because systems resources are not unlimited, the creation of
development and test databases must be scheduled for the resources involved. Thus even application
developments that could be done in parallel and have no interdependency often are queued up like
cars waiting at the traffic volume control light to enter a California freeway.
Databases Locked onto Servers
Because databases are assigned to fixed servers without the practical option of reassignment, those
servers must be configured for the maximum demand that the database might apply. So, for example,
if one has a set of accounting databases that run very hot during the week or two
after
a quarter- or
year-end close, but not so much the rest of the time; another set of databases for sales that run very
hot for a week or two
before
the end of the quarter or end of the year to capture last-minutes sales; and
another set of databases used for analytics involved in periodic marketing campaigns that run very hot
only
during
those campaigns, there is no convenient way for those databases to pool resources so that
those that need them can get them at times when others are lightly loaded. Instead, all those database
servers are provisioned for peak loads and run at, say, 20–30% capacity the rest of the time.
Ineffective Methods for Consolidation and Dynamic Provisioning
To deal with these problems, users have attempted various ways of consolidating multiple databases
onto a single server or clustered servers. These attempts include running multiple database instances
on one server as discrete processes, consolidating schemas onto a single database instance, and
using a hypervisor technology to run each database instance in its own virtual machine. Each
approach is accompanied by daunting problems.
©2013 IDC #243944 4