Database Reference
In-Depth Information
assume two of them are nonproduction and one of them is production—you would want
to implement the many techniques we have talked about in this chapter for the mission-
critical database, but not for the non-mission-critical databases. That is not be possible
if they are all hosted on a single VM.
You have greater ability to fine-tune how resources are allocated to a particular virtual
machine. Another consideration is your ability to deal with a failed host or critical time
for the business. Let's say you're an online retailer, and it's Cyber Monday, the busiest
day of the year. You could, on that particular day, power down all non-critical virtual
machines, thus freeing up resources needed for mission-critical virtual machines.
Having more virtual machines offers a number of benefits:
Better resource isolation
Better security management
Better patch management
Better performance
Thinking Differently in the Shared-Resource World
In a virtualized environment, we keep talking about how it's a shared-resource
environment. This is something that takes getting used to for the typical database
administrator. Traditionally, the database would sit on a physical server whose
resources were 100% dedicated to only that production database.
Every few years, when its time for a new server, the DBA would be asked to help
determine the specifications for the new server. During that process, the DBA would go
through an exercise to determine the new server configuration needed. During this
exercise, the DBA would always pad the request. If 64GB of RAM were needed, the
DBA would ask for 128GB of RAM. If four CPUs were needed, the DBA would ask for
eight CPUs. Any good DBA would pad his request for as much as he thought he could
convince management to buy. This was done for the DBA's self-preservation.
Whichever server was purchased was going to have to last the DBA until a new server
was purchased. No matter what was purchased by management, it was just a matter of
time before it was not enough and the DBA would be spending a lot of time he did not
have doing performance tuning to stretch the limited resources.
In this shared-resource world, where your database is virtualized, you have to learn to
ask for just the amount of resources you really need. If you ask for too much, you are
wasting resources and also potentially preventing other virtual machines from having
access to the resources they may need.
When your database sits on a physical server, your ability to add resources dynamically
does not exist. That is not the case when your database is virtualized. You now have the
ability to dynamically hot-add memory.
