Database Reference
In-Depth Information
database while in use to another physical server so that you do not have to work off
hours to patch the physical server, and the stakeholders do not have to experience
database downtime as this happens.
Service Level Agreements (SLA) and the DBA
Let's face it: As DBAs, we are all about meeting and exceeding the service-level
commitments we made to the organization, no matter how unreasonable they are. It's one
of the major reasons we do the critical updates off hours when everyone else is
sleeping, or during a holiday when everyone else is celebrating. Given the expectation
of the Internet being available and accessible 24 hours a day, seven days a week,
finding time to take a system down is no easy task. Here is a dialogue I had recently
with a client that illustrates this point very nicely—and is a common occurrence.
The company in question specialized in medical equipment monitoring—ensuring that
the medical equipment is running continuously and properly. As you can imagine, it is
vital for this company to be able to perform its job without interruption; lives literally
depend on it. The company was having severe performance problems on one of its most
critical SQL Server databases, which was at the heart of this monitoring system. To
help alleviate the performance problems, we put basic procedures in place, such as
index reorganizations, to keep the SQL Server database running optimally.
As we were troubleshooting the physical environment, database configuration, and
application, one of the key things we identified was that the BIOS setting on the physical
hardware needed to be changed. The physical server as it was configured prevented the
SQL Server database from accessing more than 50% of the available CPU. This was
causing severe performance problems. Each time we approached the client to find a
time to reboot the physical server so the new BIOS settings could take effect, we got
“not now” as the answer. The client understood that this new BIOS setting would enable
SQL Server to access 100% of the available CPU, thus alleviating the performance
problems. No matter how many times we asked the client, there was never a good time
to take the system down for a few minutes. This reply happens all too often.
I finally met with the client and we had a heart-to-heart conversation. I explained to
them that based on how their system was configured, they would always experience
performance problems with the database until this BIOS adjustment was made. The
client was then willing to work with us for a time to take the server down. Yet, this
situation points to a bigger issue concerning the expectations of “management”
concerning the availability of the database and the physical infrastructure's ability to
support the business requirements for the system. In this case, the physical infrastructure
was
not
capable of supporting 24/7 access with little or no downtime. I call this the
“No-Win SLA.” This is when management has an expectation of zero downtime, yet the
combination of the database, application, and physical infrastructure was not architected
