SQL RNNR

1 DBA's Professional Blog

Tools note

Categories: News, Professional, SSC

Tags: Database Maintenance, SQL Maintenance, SQL Tools

Comments: No Comments

Published on: March 24, 2011

I was asked a few months ago to allow some advertising on my blog. I hadn’t given the idea a whole lot of thought but was reminded again today about the request. For now, I think I will just give the requester a mention and add the tool he wants advertised to the growing list of tools that I have been compiling.

The tool looks like it has some merit and seems like it would be worth the trial. The tool is called DBDefence. You can find more about it here. The purpose of this tool is to help encrypt your databases – outside of the databases and prevent people from prying too far into what they shouldn’t. I haven’t yet tested the tool – but it seems quite interesting.

And since I have a captive audience already, I will add one more tool to the mix. Like DBDefence, this other tool is security focused. In SQL Server there is a bug that allows the savvy to view the unencrypted password of the SQL accounts that have logged in since last service start. One of the passwords that falls into this category is that of the sa account. Sentrigo has a tool that will clear that password from memory so it can no longer be viewed in clear text. The name of the tool is Passwordizer. You can check it out from here.

SQL Server Startup

by Jason Brimhall

Categories: News, Professional, SQLServerPedia Syndication, SSC

Tags: Database Maintenance, Scripts, SQL Internals, SQL Maintenance

Comments: 5 Comments

Published on: March 23, 2011

From time to time I see a question asking how to determine the last time a SQL Server was either restarted or when the last time was that the database was used. For the first question there is a pretty common answer that works for SQL 2000 and up. In answering both questions though, I am going to show you three quick similar scripts that can be used to find this information. The catch is that these queries will not work on SQL 2000. On the flipside, it should give you an idea of what can be done to find out the same info for SQL 2000.

TempDB

Code block

WITH lastDBaccess AS (
	SELECT
		DB_NAME(database_id) AS DatabaseName,
		MAX(COALESCE(last_user_seek,last_user_scan,last_user_lookup)) AS LastRead,
		MAX(last_user_update) AS LastWrite
	FROM sys.dm_db_index_usage_stats
	GROUP BY database_id
)
SELECT CDate.create_date AS ServerStartupDate
	,LA.* FROM lastDBaccess LA
	Cross Apply (SELECT create_date FROM sys.databases
					WHERE name = 'tempdb') CDate
	ORDER BY DatabaseName

A common answer to the question of when was SQL Server last started is to check the Create_Date of the tempdb database. Since tempdb is recreated every time SQL Server is restarted, it is a pretty accurate timestamp of the server start. This query was written to work for SQL 2005 and above, but you can still find the create_date of the tempdb database in SQL 2000 by using a different query.

sys.dm_exec_requests

Code block

WITH lastDBaccess AS (
	SELECT
		DB_NAME(database_id) AS DatabaseName,
		MAX(COALESCE(last_user_seek,last_user_scan,last_user_lookup)) AS LastRead,
		MAX(last_user_update) AS LastWrite
	FROM sys.dm_db_index_usage_stats
	GROUP BY database_id
)
SELECT CDate.start_time AS ServerStartupDate
	,LA.* FROM lastDBaccess LA
	Cross Apply (SELECT start_time FROM sys.dm_exec_requests
					WHERE session_id = 1) CDate
	ORDER BY DatabaseName

In this query we access one of those Dynamic Management views available in SQL 2005 and up. In this case, we look at the first process id similar to what one may have done with sysprocesses in sql 2000. Now is probably a good time to also note something that is happening inside the CTE. Notice the COALESCE that is being used? I am taking the Max from those fields that are associated with read type of activities in a database. This information is being pulled from a DMV called sys.dm_index_usage_stats. This query will get me the most recent activity for reads and writes in each database (notice the group by).

Default Trace

Code block

DECLARE @TraceFile VARCHAR(256)
 
SELECT @TraceFile = CONVERT(VARCHAR(256),VALUE) FROM [FN_TRACE_GETINFO](NULL)
WHERE [property] = 2;
 
;
WITH lastDBaccess AS (
	SELECT
		DB_NAME(database_id) AS DatabaseName,
		MAX(COALESCE(last_user_seek,last_user_scan,last_user_lookup)) AS LastRead,
		MAX(last_user_update) AS LastWrite
	FROM sys.dm_db_index_usage_stats
	GROUP BY database_id
)
SELECT CDate.StartTime AS ServerStartupDate
	,LA.* FROM lastDBaccess LA
	Cross Apply (SELECT StartTime
					FROM [FN_TRACE_GETTABLE](@TraceFile, DEFAULT)
					WHERE EventSequence = 1
						And IsSystem = 1) CDate
	ORDER BY DatabaseName

The last one is to make use of the default trace in SQL 2005, 2008 and 2008 R2. The default trace records the time of certain events that occur in the database and that includes when the database is starting up. To find the server startup time in this case, I am checking the EventSequence and IsSystem fields for a value of 1. As you can see, I also dumped the filepath for the default trace file into a variable and use that in the function to get the data.

When comparing performance of these three options, they pretty much came out even. Each took its turn performing faster – with regards to time. However, the default trace method did return a more expensive execution plan every single time. With how fast these queries run, I’m not real sure that that is very conclusive nor that it would be a heavy concern. These queries are designed more for the occasional run by the DBA rather than to be executed millions of times a day. You decide which will be best for you. I think with the use of the function to get the default trace info, I was mildly surprised that the query performed that well.

Another thing to note is that each of these methods will return a slightly different timestamp. For instance, the tempdb timestamp gives me 3:21:28 and the sys.dm_exec_requests produces a timestamp of 3:21:36 and the tracefile shows a timestamp of 3:21:24. I don’t have any hard foundation for why that is – just speculation that seems to make sense. I will just leave it at that though.

In addition to these methods there is also the option of checking the system event logs to determine the SQL Service startup time. This information should help you when investigating your databases and server and would be something handy to keep in your toolbox.

SQL Resource

by Jason Brimhall

Categories: News, Professional, SQLServerPedia Syndication, SSC

Tags: SQL, SQL Internals, Troubleshooting

Comments: No Comments

Published on: March 22, 2011

By now, I am sure that you are well aware of the Resource Database. Starting with SQL Server 2005, a new system database was made available – the Resource Database. In SQL 2005 you could move the Resource Database – but in 2008 and beyond you cannot. If you plan your install accordingly, your databases should install where you would like them (i.e. the program files directory that is the default installation directory can be changed during setup).

That is all well and good, but what is in this database and how can we take a look into it? I thought about this as I was reading a blog by Thomas LaRock where he discusses system tables and system views. I started thinking about the underpinnings of these views and if we could see them in the resource databse. Taking a peek into the Resource Database is rather trivial. I will show you how to copy that database and attach it as an alternate database.

The first step in taking a peek is to locate the directory where the data and log file for the hidden database are stored. You can find the path by referring back to the SQL 2005 and 2008 links earlier in this post. In my case, the path (I am using SQL 2008 SP2) for me is displayed in the next image.

Take the two highlighted files, copy them and place them into a new directory. I copied and renamed the files – placing the files into my “Data” directory as follows.

As you can see, the database is rather small – and you could probably do this procedure multiple times .

Once you have the files copied to the new locations, you are now ready to attach the database. I am just using the GUI to attach the database – for illustrative purposes. While attaching, I think there is an interesting thing that should stand out.

Now look closely at the image just above – pay attention to the current file path. This is the screen you will see after you browse to your new directory location and choose to add the mdf file for the Resource database. You will see that this file path does not match either of the file paths that I have already shown. Take a closer look:

You can see that the file path references a path for e:\sql10_katmai_t\sql… I find that pretty interesting. I don’t know the reason for that path persisting like that. The file paths shown need to be changed to the appropriate file path where we placed the copied files – as follows.

There is one more thing that I think you should change. This really is a matter of preference and is good housekeeping. Change the name of the database in the Attach As field. I appended _test to the end of the database name. This should make it obvious that this database is NOT the system database.

With these few steps, you now have the resource database attached as a User Database. With that, you now can take a look at the inner makings of some of the system views. Take the following queries for example:

Code block

SELECT * FROM master.dbo.sysdatabases
SELECT * FROM mssqlsystemresource_test.sys.sysdatabases

Both of these queries return exactly the same thing. Both of these queries are only provided as a means of backwards compatibility. You can actually see master.sys.sysdatabases (just like mssqlsystemresource_test.sys.sysdatabases). One thing you can do though is script out that view and see what the source of the data is. Well…with the resource database attached as described, you can now script it out. When you script out the view, make sure you try to script the correct version of it. Just like any user database, you will get a category of system tables and one of system views. The objects under those categories cannot be scripted. The objects, however, are also represented in this database as “user” objects – which can be scripted.

After you script out the object, sys.sysdatabases you will see that the source of the data is the following:

Code block

FROM sys.databases d
	LEFT JOIN sys.master_files$ f

There you have it – this view is predicated on the newer view called sys.databases. As has been said over and over again, it only exists as a backwards compatibility view until Microsoft decides to remove it. Also note that the other part of the foundation for the sysdatabases view is the sys.master_files$ view. You can now see this in the system views collection inside the Resource database that we attached. Unfortunately you can’t script it, but at least you can see the columns that it would return. You also can’t query directly to that view – you have to reach it through the system views.

Dedupe Data CTE

by Jason Brimhall

Categories: News, Professional, SQLBlogs.Net, SQLServerPedia Syndication, SSC

Tags: Scripts, SQL

Comments: 2 Comments

Published on: March 21, 2011

As a DBA working with SQL Server, some data issues arise that need to be fixed. One such data issue is the duplication of data. Duplicate data can happen for a number of reasons. One such reason is the absence of constraints such as Primary Keys.

Luckily, there are ways for the Data Professional to clean up such a quagmire. First, let’s set the stage with a really simple example.

Code block

CREATE TABLE DupeDemo (DemoID INT, SomeInt INT)
 
INSERT INTO DupeDemo
SELECT TOP 10000
        DemoID       = ABS(CHECKSUM(NEWID()))%100+1,
		SomeInt      = ABS(CHECKSUM(NEWID()))%50+1
	FROM Master.dbo.SysColumns t1
CROSS JOIN Master.dbo.SysColumns t2

Here, we are simply creating a table and populating the table with two columns of randomized data. This should give us a significant amount of duplicate data and a good enough test bed to demonstrate how to quickly fix this issue. Due to the random nature of these inserts, we will get a significant range of duplicates for some values and maybe no duplicates at all for other values. (Did that make sense?)

Let’s check our work and see how well we did with the duplicate creation.

Code block

SELECT *
	FROM DupeDemo
	ORDER BY DemoID,SomeInt

Each time I have run this, I have come up with a good test bed. It should work relatively well for you as well. Now, we can work on eliminating those duplicates. To better illustrate that we have dupes and the distribution, let’s have a look at this query.

Code block

SELECT DemoID,SomeInt, COUNT(SomeInt) AS Counted
	FROM DupeDemo
	GROUP BY DemoID,SomeInt
	ORDER BY DemoID,SomeInt

This query will yield results like what we see in the image to the right.

Similarly, I can run a query that would be contained within a CTE and take advantage of the ROW_Number() function to help find where I may have dups.

Code block

WITH dedupe AS (
	SELECT DemoID, SomeInt
		,ROW_NUMBER() OVER (partition BY DemoID,SomeInt ORDER BY Someint) AS Rownum
		FROM DupeDemo
		)
SELECT * FROM dedupe
	WHERE Rownum > 1
		ORDER BY DemoID,SomeInt

Now that we know for certain that we have a large amount of dupes, lets finally work on eliminating them. We can use a query just like the last one and alter it a bit to make it work so we can delete the dups. Under normal circumstances, I would make absolutely certain that the tables to be affected by these deletes were backed up. You can accomplish that by either copying the data in the table into a new table or you can run a database backup.

Code block

WITH dedupe AS (
	SELECT DemoID, SomeInt
		,ROW_NUMBER() OVER (partition BY DemoID,SomeInt ORDER BY Someint) AS Rownum
		FROM DupeDemo
		)
DELETE dedupe
	WHERE Rownum > 1

Really easy script. This will delete all source table records that are dupes. You can validate that by rerunning either of the first two queries used to demonstrate that duplicate data existed. This is illustrated in the following image.

Since SQL 2005, removing bad duplicate data has become substantially easier. This example should help to demonstrate that as well as provide a method to create a repeatable test while learning the technique.

Database Tools Follow-up

by Jason Brimhall

Categories: News, Professional, SSC

Tags: Database Maintenance, SQL, SQL Maintenance, SQL Tools

Comments: No Comments

Published on: March 18, 2011

After posting a database tools list yesterday, I found that there were things that I had forgotten and a couple of things that i hadn’t even considered. In thinking about this, I found myself trying to find a script that I knew I had seen and that I wanted to put on the list.

Trying to find the script got me a bit out of sorts. I knew I could probably find it on my share at work with my scripts (which reminds me that I really need to get a dropbox or put them all on a thumbdrive to keep with me). But, I wasn’t at work and wanted to locate this cool script that I knew was recommended by another prominent person (more about that later). So I pulled out my googlefu.

I tried searching the web for this blog that had the script and tried several combinations of the key words I knew would help me find it. In doing this search, I came across a few blogs that had created a list of tools that database professionals should check out. Here is a short list of the blogs I found.

Aaron Bertrand (Oct 2010) – Aaron references the post by Dave and Mladen
Dave Ballantyne (Oct 2010)
Mladen Prajdic (Nov 2007)
Ami Levin (Feb 2011) – Ami adds a few items to Aaron’s list

All of these lists are great compilations. I also found one more list, but found that it was just a copy of Aaron’s list. This was extremely disappointing. Just reference the list or come up with a list of your own. A SQL Server MVP should never have to copy content from another MVP. It’s not even that the list is the same – it was a copy of the entire post by Aaron. I personally hold MVPs to a higher standard and find it disappointing and aggravating when one is copying content and is esteemed as a person who has contributed much to the community.

None of these lists had what I the item for which I was looking. The item that I wanted was a script that Brent Ozar (blog) had given high compliments to a few months back. It was a script that, he said “a script that’s like my Blitz server takeover script, but even more advanced. Love it!” Too bad I couldn’t remember the person, script or wording he used when I was trying to find the script. Better yet, the page with the reference popped up several times in my searches. Well, needless to say, I pinged the community and Brent on twitter and Brent came through. Here are a few more items to add to the list of tools you should have or try.

60 Minute Blitz Script (Brent Ozar) – check it out. It will be worth your time. If you looked at the other lists you will also see that this script is there and highly recommended.
Diagnostic Information Queries (Glenn Berry) – this was the script I was trying to find. This is the script that Brent has given high praise – give it a look.
sp_whoisactive (Adam Mechanic) – Newest version as of this post is 10.76 and is listed as a beta version.
SSMS ToolsPack (Mladen Prajdic)

So there you have it. Between my two lists and these other great lists – you should have a great toolbox.

«page 23 of 54»

February 2012
M	T	W	T	F	S	S
« Jan
	1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29

Content

Now Reading

Planned books:

Throne of Fire, the by Rick Riordan
Seeds of Rebellion (Beyonders) by Brandon Mull

Current books:

ChiRunning: A Revolutionary Approach to Effortless, Injury-Free Running by Danny Dreyer, Katherine Dreyer
Advanced Marathoning – 2nd Edition by Peter Pfitzinger, Scott Douglas
SQL Server MVP Deep Dives by Nielsen Paul, Delaney Kalen, Machanic Adam, Tripp Kimberly, Randal Paul, Low Greg
A World Without Heroes (Beyonders) by Brandon Mull