16Oct 2012 by Grant Fritchey 6 Comments

RML Utilities and SQL Server 2012

T-SQL
I'm working through some code that I haven't touched recently and I'm running it for the first time on a SQL Server 2012 server. The code is a way to load information into the RML utilities and I started hitting errors. First, I hit an error that my server couldn't be connected to, but thanks to Erin Stellato (blog|twitter), I was able to quickly fix that. Then I hit this: Number of processors: 2 Active proc mask: 0x00000003 Architecture: 9 Page size: 4096 Highest node: 0 Package mask: 0x00000001 Processor(s): 0x00000001 Function units: Separated Package mask: 0x00000002 Processor(s): 0x00000002 Function units: Separated Processors: 0x00000003 assigned to Numa node: 0 -Ic:\performancetuning\rml.trc -oc:\bu -SDOJO\RANDORI Using language id (LCID): 1024 [English_United States.1252] for character formatting with NLS: 0x00060101 and Defined: 0x00060101 Attempting to…
Read More
28Aug 2012 by Grant Fritchey 34 Comments

Please, Call Me Richard

Professional Development, T-SQL
I presented a session at the SQL Saturday event in Oklahoma City last weekend. The event itself was pretty good. The organizers put everything together pretty well and the venue was quite nice. Plus, since I grew up in Oklahoma (Tulsa), it was a chance to go home. The event was good, but my presentation went a little downhill. The name of the session is "Top Tips for Better Stored Procedure Performance." I should rename it to just say "T-SQL Query Performance" because it's not focused on stored procedures, but on queries. The presentation is 1/3 talking about how you write your queries, naming syntax, formatting, etc. The second 2/3 is all about common mistakes made in writing T-SQL such as using NO_LOCK everywhere, nesting views, joining and nesting multi-statement…
Read More
21May 2012 by Grant Fritchey 11 Comments

Is Dynamic T-SQL a Good Design Pattern?

T-SQL
In a recent discussion it was suggested to me that not only is dynamic T-SQL useful for things like catch-all queries or some really hard to solve problems involving variable table lists, but is, in fact, a perfectly acceptable design pattern for all queries against a database. Note, in this case, we’re not talking about an ORM tool which takes control of the system through parameterized queries, but rather an intentional choice to build nothing but dynamic T-SQL directly on the system. To me, this was immediately problematic. I absolutely agree, you’re going to have dynamic T-SQL for some of those odd-ball catch-all search queries. But to simply expand that out to include all your queries is nuts. There really is a reason that stored procedures exist, and it’s not…
Read More
30Apr 2012 by Grant Fritchey No Comments

Changing DB_CHAIN Can Clear the Plan Cache

T-SQL
If you make changes to the settings of a database, it can cause the procedure cache to be cleared. Microsoft has documented changes that cause this for all procs within a database (scroll down to just above the examples). But guess what, if you change the DB_CHAINING option, it clears the cache too. Here’s a sample script to show it in action. ALTER DATABASE Testing SET DB_CHAINING OFF; GO CREATE PROCEDURE x AS SELECT * FROM test.dbo.A AS a2; GO CREATE PROCEDURE y AS SELECT * FROM dbo.Table_1 AS t; GO EXEC dbo.x; EXEC dbo.y; SELECT deqs.creation_time FROM sys.dm_exec_query_stats AS deqs CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest WHERE dest.text LIKE 'CREATE PROCEDURE x%' OR dest.text LIKE 'CREATE PROCEDURE y%'; ALTER DATABASE Testing SET DB_CHAINING ON; SELECT deqs.creation_time FROM sys.dm_exec_query_stats AS deqs…
Read More
02Dec 2010 by Grant Fritchey No Comments

SQL Spackle

SQL Server, T-SQL, Tools
I previously mentioned how SQL Server Central was listing ideas for articles, primarily for short, quick, pointed articles that they were terming SQL Spackle. Spackle is a term in the US that represents the filler you put into dry-wall to smooth it out or fix small holes, so SQL Spackle is meant to fix small gaps in knowledge or documentation. My first SQL Spackle article was published today. I kind of forgot it was coming. I wrote a quick and pointed outline of how to set up and schedule a server-side trace. This is something I've always advocated, and now I can point to a bit of spackle to fill in the gaps for those who don't know how to get it done.
Read More
02Nov 2010 by Grant Fritchey 12 Comments

TSQL Tuesday: Why Are DBA Skills Necessary

Misc
  Quote: "Database stuff, all this programming stuff, is easy. Anyone can do it. That's why everyone in the company has sa privileges." For nine months, I worked in an environment where everyone, from developers to QA to the sales people to the receptionist, had SA privileges. You know what? DBA skills are necessary. I speak from the point of view of someone that has had to recover a server after a salse person helpfully "cleaned up the temporary stuff on the server" by dropping tempdb, causing a late deployment for a client. I speak from the point of view of the guy who kept a window open on his desk with the database restore script ready to run, all day long, because of "accidents" that stopped development until I could get the…
Read More
09Sep 2009 by Grant Fritchey 8 Comments

Spools in Execution Plans

SQL Server, T-SQL
I got the question the other day, when are you likely to see a spool in an execution plan? Easy, whenever SQL Server needs to walk through the data multiple times, usually in JOIN operations... Yeah, well, once again, my flip answers are not quite the entire story. Spool operations are temporary storage of the data for later reuse in a query plan. There are two types of spool operations, eager spool and lazy spool. A spool is basically a temporary table created within the execution of the query that is used when it's likely that data will be needed again, and again during the execution of the query. This is not an explicit #temp temporary table, but a work table for operations within the processing necessary for a given query's…
Read More
24Apr 2009 by Grant Fritchey 15 Comments

Unpacking the View

SQL Server, T-SQL
A view is simply a query that behaves something like a table. Most people know this. Most people also know that a view is simply a mask on top of what might be a very complex query. It all seems really simple. You call the view inside a simple query, the view runs the underlying complex query. Most people might not know that when a view is called and it gets sent to the optimizer, the optimizer unpacks the view and binds the component parts of the query necessary to create an execution plan that will return the data requested. What I didn't know until recently was that the optimizer is VERY smart. Not only does it unpack the query of the view, but it will change the query that…
Read More