SQL Server Tacklebox- P25 pot

4 – Managing data growth
120

IF EXISTS ( SELECT name
FROM tempdb sysobjects
Where name like '#fixed_drives%' )
If So Drop it
DROP TABLE #fixed_drives
Recreate it
CREATE TABLE #fixed_drives
(
[Drive] [char](1) COLLATE SQL_Latin1_General_CP1_CI_AS
NOT NULL,
[MBFree] [decimal] NOT NULL
)
ON [PRIMARY]
Insert rows from sp_MSForEachDB into temp table
INSERT INTO #HoldforEachDB_size
EXEC sp_MSforeachdb 'Select ''?'' as DatabaseName, Case
When [?] sysfiles.size * 8 / 1024 = 0 Then 1 Else
[?] sysfiles.size * 8 / 1024 End
AS size,[?] sysfiles.name,
[?] sysfiles.filename From [?] sysfiles'
Select all rows from temp table (the temp table will auto
delete when the connection is gone.

INSERT INTO #fixed_drives
EXEC xp_fixeddrives


Select @@Servername

print '' ;
Select rtrim(Cast(DatabaseName as varchar(75))) as
DatabaseName,
Drive,
Filename,
Cast(Size as int) AS Size,
Cast(MBFree as varchar(10)) as MB_Free
from #HoldforEachDB_size
INNER JOIN #fixed_drives ON
LEFT(#HoldforEachDB_size.Filename, 1) = #fixed_drives.Drive
GROUP BY DatabaseName,
Drive,
MBFree,
Filename,
Cast(Size as int)
ORDER BY Drive,
Size Desc
print '' ;
Select Drive as [Total Data Space Used |],
Cast(Sum(Size) as varchar(10)) as [Total Size],
Cast(MBFree as varchar(10)) as MB_Free
from #HoldforEachDB_size
4 – Managing data growth
121
INNER JOIN #fixed_drives ON
LEFT(#HoldforEachDB_size.Filename, 1) = #fixed_drives.Drive
Group by Drive,
MBFree
print '' ;
Select count(Distinct rtrim(Cast(DatabaseName as

varchar(75)))) as Database_Count
from #HoldforEachDB_size
Listing 4.5: Size query.
Example results of the Size query are shown in Figure 4.26.

Figure 4.26: Output of Size query.
You can see that the
All_Books_Ever_Read database has 6.4G of allocated space
on the C: drive. Since my sample databases reside only on the C: drive, all
allocation is for this drive. However, if I were to have my log files on E: and
TempDB on F:, for example, then query output would show the breakdown for
each drive that actually stores any database file. You can see there is 61G free on
the C: drive and of that 11G consists of database files.
4 – Managing data growth
122
Summary
In this chapter, I have explored some of the scenarios where disk space is
consumed by processes, in many cases because of incorrect configurations for
recovery models, data growth for large objects and queries that overtax TempDB
resources. Many of these scenarios can be avoided with proper planning.
However, it can be expected that, at some point, there will arise a situation that
requires the DBA team to jump in and rescue the SQL Server.
When this happens, and it happens quite frequently, DBAs need to have an
arsenal of troubleshooting tools at their disposal. In the next chapter I am going to
introduce some of the tools and techniques that I have used to quickly
troubleshoot common problems that crop up for DBAs.
Hey, there was no monster at the end of this chapter after all. Surely it will be in
the next chapter.

123
CHAPTER 5: DBA AS DETECTIVE
If you consider it fun to find and fix SQL Server problems then I can say without
fear of contradiction that this chapter is going to come at you in a clown suit.
I always feel better at the end of the day if I've been able to isolate a problem and
offer a fix. Being a SQL Server DBA, overseeing terabytes of critical business data,
can be both highly stressful and highly rewarding. Frightening? Yes, like a horror
movie with suspect code lurking in every shadow. Fulfilling? Absolutely, when you
discover that you are only one temp table or sub-query away from being the day's
hero or heroine.
This chapter is all about sleuthing in SQL Server, peeling back layer after layer of
data until you've uncovered the bare metal of the problem. It can be both fun and
painstaking. Words like "Deadlock" and "Victim" are common, so we must tread
with care through this twilight world. And, if worse comes to worse, we may have
to "Kill" something. These murderous tendencies in a DBA make many, mainly
developers, fearful to approach us. They creep up to our cubicle and tempt us
with their feigned courtesy; "Can you please kill me?" they ask expectantly.
"Absolutely" is our reply.
System tables versus DMVs
Before I start troubleshooting, it is important to note that the steps that I take as a
DBA, at this point in my career, are ones that allow for querying across multiple
versions of SQL Server: 2000, 2005 and 2008. While I certainly can appreciate the
utility of the Dynamic Management Views (DMVs) in SQL 2005 and 2008, there
are many companies in the real world that still use SQL 2000. As much as I would
love to say that all of the servers that I manage are SQL 2005, that is just not the
case. The reason that companies may be slow to upgrade are many-fold, although
cost and third party application support are the two primary reasons.
However, the system tables that I use here will be deprecated in a few years, and I
surely will as well. For this reason, I would strongly recommend that anyone who
works primarily with SQL Server 2005 and higher should use the DMVs. With

slight modification, the queries I present here can utilize DMVs in lieu of system
tables or system stored procedures.
For additional information on mapping Distributed Management Views to system
tables in 2000, 2005 and 2008, please see Books Online topic "Mapping System
Tables to System Views."
5 – DBA as detective
124
Tracking down database performance issues
You are a DBA sitting at your cubicle, or if you are fortunate, your corner office
with wrap around tinted windows overlooking a flowing brook with squirrels and
hibiscus, the rustling of nothing special blowing through your perfectly set A/C
vent … OK, your cubicle … and your phone rings. It is from the Help Desk and
they are asking you to take a look at application Z, because User X called and said
Department Y's screens are all (W)hite and they are "frozen", presumably not
because of the efficient A/C vent.
One of the users has received a timeout issue related to S.Q.L., which is why you
are being called. I do not know about you, but when you have more than 100
applications that tie to the SQL Servers in your infrastructure, you do not always
know what server/database combination are linked from the frontend to the
backend. So you have to do some upfront interrogation:
"What SQL Server are they connecting to?" you ask.
"I am not really sure, let me find out," Help Desk says. Pause. "They do not know
what that is."
"OK, what is the application?"
"Oh, um, it is Accounts_Receivable_Generation1.4."
"That is server 'G' you say confidently." Some DBA, long before you arrived,
decided it would be fun to name all servers on letters of the alphabet, one letter at
a time. "G" in this case is, of course, the intuitive name for where the A.R.G
application must reside because it is an accounts receivable application and "G"
stands for "Gold", from the DBA's favorite online game. After jotting down a

note to change that server name in the next maintenance weekend, you tell the
Help Desk that you will look into the matter and get right back with them. You
are on.
What follows is an example of how I track down and resolve such issues, often
misdiagnosed as "database performance" issues.
Using sp_who2
The first troubleshooting tool in every DBA's tackle box is the tried-and-true
stored procedure,
sp_who2. Granted there is Activity Monitor, which is also quite
handy, but I have found that there are two things wrong with Activity Monitor.
Firstly, when the server is heavily burdened with locks or temporary tables,
Activity Monitor often cannot be launched, and you generally receive an error
message to this effect. Secondly, Activity Monitor for SQL Server 2008 is radically