11May 2010 by Grant Fritchey 10 Comments

Recompiles and Constant Learning

T-SQL
When faced with a procedure that looks like this: CREATE PROCEDURE dbo.TestProc (@TestValue INT) AS BEGIN IF @TestValue = 1 BEGIN SELECT * FROM Sales.SalesOrderHeader AS soh JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID WHERE soh.SalesOrderID = @TestValue END ELSE BEGIN SELECT * FROM Production.Product AS p JOIN Production.ProductDocument AS pd ON p.ProductID = pd.ProductID WHERE p.ProductID = @TestValue END END I used to suggest creating a wrapper procedure in order to avoid the recompiles that occur when the different paths through the IF statement are taken by the optimizer. I mentioned that recently on a post over at SQL Server Central. Gail Shaw (blog | twitter) asked me why I thought there would be a recompile. She said that the optimizer took the query as a whole and…
Read More
18Mar 2010 by Grant Fritchey 5 Comments

Undocumented Virtual Column: %%lockres%

SQL Server, T-SQL
One of my development teams needed a mechanism for identifying the value of a key that was part of a lock (don't ask). I'd never tried doing that before. Obviously if you hit the DMV sys.dm_tran_locks you can see the hash of the key in the resource_description column. But how to pull the value back. After some research, I first found this excellent article by the late, great, Ken Henderson (I really wish he was still around). The article outlined, among other things, the use of an undocumented "virtual" column called %%lockres%%. Some more searching then uncovered this great article by James Rowland-Jones, AKA Claypole. He described how, in a very high volume system, he used %%lockres%% to identify the source of a deadlock as the internal mechanisms that SQL Server uses to manage locks, the hash…
Read More
25Jan 2010 by Grant Fritchey 3 Comments

A Call to Arms

SQL Server, T-SQL
Phil Factor's most recent guest editorial over at SQL Server Central has, to a degree, pointed out that the emporer's spiffy new outfit... well, it's not exactly there. That's why he looks so nekkid. But seriously, the very idea of naming objects inside of the database with Hungarian-style notation really should end. Phil's right. There's absolutely no reason why you should name a unique index ixuTableName when UniqueTableName or TableNameUnique would do the job just as well and not be nearly as obscure. I confess to using this type of naming convention all the time, but I'm realizing that I don't need it and it's largely just habit. There are possible exceptions, for instance you want to group all lookup tables in your database so you name them lkTableName, but…
Read More
21Jan 2010 by Grant Fritchey 2 Comments

PowerShell Script for Creating Indexes

PowerShell, SQL Server, T-SQL
I needed to create an identical index on a bunch of tables within one of my projects (yes, I know this is problematic on multiple levels and I'm working on that too). Rather than sitting around typing this up, I decided to use PowerShell to do the work for me. I'm still very much learning how to do things in PowerShell so this took me almost as long as it would have to type them up, but now I know more than I did. Having gone through the pain of trying to find a good example on the web that did exactly what I wanted (they're out there, just hard to find), I decided I'd add this one in so the next person had at least one more source of…
Read More
13Jan 2010 by Grant Fritchey 6 Comments

Connections Sessions Evals

SQL Server, T-SQL
I've kind of been embarassed to post these despite the fact that I received them a couple of weeks ago. Overall, I'd say they're very good, and I'm quite proud of them, but one comment still has me upset. Anyway, here we go: DMV's For Performance Tuning (same session as PASS): 7 responses Q1. Speaker's knowledge of topic Your average score for this session: 4.0 Highest score (all SQL speakers for this question): 4.0 Mean average score (all SQL speakers for this question): 3.74 Lowest score (all SQL speakers for this question): 3.0 Q2. Speaker's presentation skills Your average score for this session: 3.86 Highest score (all SQL speakers for this question): 4.0 Mean average score (all SQL speakers for this question): 3.47 Lowest score (all SQL speakers for this…
Read More
12Jan 2010 by Grant Fritchey 4 Comments

TSQL Tuesday #2

SQL Server, T-SQL
I've wracked my brain for some bit of puzzle that I could present as part of TSQL Tuesday #2 and I finally came up with a bit of something. When you're looking at an execution plan for a query, you know that this represents SQL Servers best attempt at a good execution plan. But, it may not represent the best possible plan. Or, it could be the only possible plan. The puzzle is, how do you know what you're looking at? Is this a trivial plan, meaning it's the only possible execution method for the query? Is this plan fully optimized, or did the optimizer go through it's prescribed cycles and simply take the best plan it had generated up to that point? These questions can be answered directly from information…
Read More
29Dec 2009 by Grant Fritchey 6 Comments

The Other Server

SQL Server, T-SQL
I had a fun support call I need to share. A developer called up to tell me that a particular dev instance was offline. He informed me that the server SQL08\DEV01 (the names have been changed to protect the innocent) server was completely inaccessible. I knew that multiple development teams would shortly be calling and that I'd better get on this issue most riki-tik. I quickly typed the connection string into Management Studio and watched in confusion as the server instance popped up on my screen. It was fine. I did a number of checks, looking for active connections, recent connections, errors in the log, indications of a recent reboot... Nothing. I called the developer back and told him that the server was fine. He called me again in two…
Read More
23Dec 2009 by Grant Fritchey 1 Comment

A Lack of Excitement

PASS, PowerShell, SQL Server, T-SQL, Tools
I usually use all the problems, crashes, and issues that I run into at work as grist for my mill, aka, material to blog about. But lately, we haven't been crashing & burning much <knock wood, turn three times, throw salt over my left shoulder, spit>. But it was suggested that may be I should mention why that is. The fact of the matter is that I've been spending a lot more time working on methods for monitoring our systems so that we avoid more of the stupid stuff, full disks, failed backups, long running agent jobs, etc.. I've blogged before about our use of Microsoft's Operations Manager for monitoring our servers and how we've built custom rules and monitors to keep an eye on things. I've also mentioned how…
Read More
08Dec 2009 by Grant Fritchey 4 Comments

T-SQL Tuesday #1: Date/Time Tricks

SQL Server, T-SQL
I'm going to try out Adam Machanic's idea for a blog party. The topic this month are Date/Time tricks. Instead of supplying a trick for Date/Time, I'm going to caution you about the tricks that you use. Let's take a simple issue. You want to pull back data from a table, let's use the Production.TransactionHistoryArchive in AdventureWorks2008, for a given month of data. Before we run the query, let's create an index on the table: CREATE INDEX ixTest ON Production.TransactionHistoryArchive (TransactionDate) The query itself is pretty simple. This is one mechanism that will retrieve the data for the month of July in 2003: SELECT tha.TransactionID FROM Production.TransactionHistoryArchive AS tha WHERE DATEPART(yy,tha.TransactionDate) = 2003 AND DATEPART(mm,tha.TransactionDate) = 7 In theory you should be able to use the index that was created earlier,…
Read More
01Dec 2009 by Grant Fritchey 4 Comments

How do -You- use SQL Server

nHibernate, SQL Server, T-SQL, Tools, Visual Studio
I've been tagged by a misplaced yankee, uh, New Englander, whatever. The question is, how do I/we use SQL Server where I work. That's a tough one. It would make a much shorter, and easier, blog post to describe the things we don't use it for. However, keeping with the spirit of these tags, I'll try to lay out it. For those that don't know, I work for a rather large insurance company. This means that we have lots and lots of databases, but not much data. We also are cheap. That means we'll run an app into the ground rather than spend the money & time to replace it. We have apps still running from the 70's and 80's propped up by ancient men with pocket protectors, spit, bailing wire…
Read More