INSERT INTO #fixed_drives EXEC xp_fixeddrives Select @@Servername print '' ; Select rtrim Cast DatabaseName as varchar75 as DatabaseName, Drive, Filename, Cast Size as int A
Trang 14 – Managing data growth
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]( ) 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
Trang 24 – Managing data growth
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
Trang 34 – Managing data growth
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
Trang 4C HAPTER 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."
Trang 55 – DBA as detective
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