Database Reference
In-Depth Information
databases, or to keep virtual machines apart, such as OLTP and DSS databases.
Reorganization
Did your heart skip a beat at that title? I know mine does every time I hear that word.
Let's review how we designed and implemented our physical database servers with a
trip down Memory Lane, if you will.
We would try and figure out how much of a given resource we would need to run the
current workload, that workload's anticipated growth over the next three to five years,
and then add X% buffer to be safe. Then we went to our favorite server vendor and
asked for the biggest box they had that could run our workload for our five-year
projected requirement. We ordered the box, and when it came in, we were happy... for
about a week because then we found out a bigger, faster, better model was just released!
We unboxed our new hardware, racked it, stacked it, installed the operating system,
installed SQL, and then we were off and running—and, boy, weren't we happy. It was
the best of times... for about a week. Because, sure enough, a project popped up and,
wouldn't you know it, the project required a database and there was nowhere to put it.
Therefore, the database ended up on the database server you just racked and stacked.
Over time, these database servers become populated with “projects,” DBAs shift to a
mentality of “if it fits, put it on.” This is known as “consolidation.” So many times when
we speak to DBAs about the benefits of virtualization, they reply in kind with, “We
already consolidate our databases to get the maximum performance out of our servers.”
True, they are running those boxes to the limit, but are they running them as efficiently
and as effectively as possible? Perhaps the single biggest downside we have seen with
this configuration is security.
Let's dive into what we are talking about concerning security. What we find in the
majority of our conversations with customers is that as these database servers are filling
up, the speed at which the business is requesting database creation does not allow for
proper segmentation. So what ends up happening is that internal, production databases
are now run among third-party databases, test databases, development databases, and so
on.
There are a couple challenges here. With SQL Server patching, the lowest common
denominator is the instance level. So what happens when a third party does not support
the latest SQL Server patch that your information security team is asking you to install to
prevent a serious security risk? Do you patch the server to prevent the risk and satisfy
the information security team, or do you run in an unsupported configuration for this
third-party application? What if this is a customer-facing, revenue-generating
application?
Another item to consider and discuss is compliance. We have had many DBAs tell us
