Databases Reference
In-Depth Information
Many times a customer will call for assistance with a problem that they will describe simply as: ''Our
SQL Server is running slow.'' Although that may well seem like a good description of the symptom to
their end users, it's not really of much use in starting to performance tune a complex database system.
Sometimes it may be all you have to go on. However, I would hope that after asking yourself a few
questions you can come up with something a bit more descriptive.
Whenever you take a call like that, your immediate response should be to start asking questions. You
should ask the customer to describe what it is that's slow. Are there multiple users on the system? Is it
slow for all of them? Do they all do the same kind of work? What kind of workloads run on the system,
and are there any batch jobs running at any time? These questions are all aimed at digging more infor-
mation from the customer, partly for your benefit so you can better understand what the problem might
be, but they are also aimed at getting the customer to think more about their system and to help them try
and arrive at their own problem statement.
A much more focused problem statement would be something like
''User X has a slow running query. He uses the Y system, which calls A, B, and C stored procedures in
the Foo database. This happens all the time.''
The key elements to a good problem statement are:
Who
❑
What
❑
When
❑
And one final element that's not essential but can be useful would be to outline a successful resolution to
the problem.
WhoIsHavingtheProblem?
Is it just one user reporting the problem? What type of user is it? Does it affect multiple users? Are these
users all of one type (for example, do they only access one set of features of the system), or are they
spread out across many different features? Where are these users? Are they all in the same department,
location, or region? Is their anything else unique about the users reporting the problem?
WhatIstheProblem?
How did the user report the problem? Is it a slowdown that's impacting them, or are they getting
timeouts or deadlocks that are causing loss of functionality? What were they doing when the problem
occurred? What else was going on when the problem occurred?
WhenDidtheProblemOccur?
When did the problem occur? Did this just occur? Has it happened before? Is it consistent or intermittent?
Is it happening now?
WhatIstheResolution?
It is important to know from the beginning what a successful resolution might look like. In many cases
with performance tuning, the goal is very poorly described simply as ''make it go faster''. How much
faster do you want it to go? What is a reasonable amount of time for the query to take? What is an
acceptable amount of time for the user to experience?
Search WWH ::
Custom Search