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 . 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. 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. 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