15Aug 2008 by Grant Fritchey No Comments

More on Table Valued Functions

T-SQL
From the hits in the search results, this is a popular topic. That being so, I'd like to redirect you to another blog that has some more detailed tests available. These tests show more of the shortcomings of multi-statement table valued functions. Gail Shaw is an MVP and a regular at SQL Server Central. She's worth tracking and this post shows why. I want to be clear. I'm not suggesting that you never, ever, use multi-statement table valued functions. There may be places where their use is helpful. I'm saying that using them comes with a very heavy cost, so you better be sure that they are in fact needed in the situation, whatever it is. There was a long discussion and debate over at SQL Server Central recently on…
Read More
13Aug 2008 by Grant Fritchey 18 Comments

View vs. Table Valued Function vs. Multi-Statement Table Valued Function

T-SQL
About five years ago, I was checking an app before it went to production. I hadn't seen the app before then and a junior dba had worked with the developers designing and building the app. It didn't use a single stored procedure or view. Instead, it was built entirely of multi-statement UDF's. These UDF's called other UDF's which joined to UDF's... It was actually a very beautiful design in terms of using the functions more or less like objects within the database. Amazing. It also would not, and could not, perform enough to function, let alone scale. It was a horror because they thought they were done and ready to go to production, but no one had ever tested more than a couple of rows of data in any of…
Read More
08Aug 2008 by Grant Fritchey No Comments

SQLPLAN Glitch

SQL Server, T-SQL
While I was doing some work for Andy Warren (more on this after Sept 1st), I came across an interesting little glitch when saving XML execution plans out as SQLPlan files. It's easy enough to replicate. Just get an XML execution plan from your query: SET STATISTITCS XML ON; SELECT... Click on the link to open the XML plan. Click on the "File" menu and then the "Save As" menu item. It opens the familiar file save window. Click on the "Save as type" drop down and switch to "All Files (*.*)" Save the file with an extension of ".sqlplan." Good. Now you've got an execution plan file that can be opened and viewed as a GUI execution plan. Without closing the XML, try to open this new plan. You…
Read More
06Aug 2008 by Grant Fritchey No Comments

Deadlocks vs. Blocks

SQL Server, T-SQL
It makes me crazy when I interview someone who has five or more years as a DBA, but they don't know the difference between a block and a deadlock. It's a complete showstopper for me. If you don't know this, you're an entry-level DBA, don't talk to me about your years of experience. Sorry, but there it is. Here's someone that's kinder than I am in every way. Not only have they cut people slack on this question, but he's provided a well done answer to the question. For those who may interview with me in the future, go and read this and understand it.
Read More
01Aug 2008 by Grant Fritchey 1 Comment

A Horseless Carriage?

Misc
I've talked before about my concern that I'm manufacturing buggy whips.  Jason Massie over at StatisticsIO has posted a pretty convincing argument that cloud computing could be a horseless carriage coming down the road. Effectively we're still looking Diesel's first engine, but that could mean it's just a matter of time. As Mr. Massie points out, the speed of change in IT is one heck of a lot faster than in other parts of the world. So, when you do finally see that Stanley Steamer roar by, belching smoke and going half the speed of a good horse, don't laugh and point. Someone is spending time & money on that thing and they're not buying your buggy whip. Clouds are just like any other major technological shift (ORM anyone?) that could…
Read More
01Aug 2008 by Grant Fritchey 2 Comments

SQL Server DBA’s Sound-Off

SQL Server
This is a great read about the attitudes and beliefs of quite a few SQL Server DBA's. It's very interesting how certain beliefs and attitudes seem to be common. I was also reassured that my attitude about a certain DBA was accurate... less said the better. These are interesting and informative guys doing the same kind of work that I try to do. If you're trying to, go read it and learn. I read about it on StatisticsIO. Another place with good things to read.
Read More
18Jul 2008 by Grant Fritchey 2 Comments

Virtual Drives

SQL Server
I published an article describing an attempt my company made at using virtual servers as a full-fledged development environment. It didn't work real well. I'm not a systems guy. I know a bit. I pay attention and learn things. I certainly listen to the people around me that are systems experts. When several of them commented on this great assessment of virtual drives, I went and read it. It sounds like some really cool technology only with the ability to really make our lives harder. Like the article says, how often do you check to see if the drive has slowed down?
Read More
15Jul 2008 by Grant Fritchey No Comments

Benefits of a Tear Down & Rebuild in a Database

Tools, Visual Studio
Using the Team Edition of Visual Studio for Databases (VSDB) enables you to build a database out of source control. This means you can treat your database like code, as much as you can. The fact is, because of persistence, a database just isn't code. Because you have to keep all the data previously entered, when you deploy a new version of your database to production, you don't simply get to replace the database like you do with the code. You have to run scripts that alter that which can be altered, but preserve the existing data everywhere. That's just how it is in production. You have to do the work necessary to protect your data. Not so in Development. Development (and QA, Test, Financial Test, Performance Test) is the place…
Read More
09Jul 2008 by Grant Fritchey No Comments

Serious Error

T-SQL
When I wrote the book "Dissecting SQL Server Execution Plans" I knew I was going to get things wrong. Several people have pointed out things over the last couple of months. They've all been in the details. None of them were serious errors of fact. Andy Warren just found a huge one. In the section on Table Hints I detail how to apply an INDEX() hint. It's on page 123 in the electronic version or 124 of the first print version. I state that index number starts at 0 with the clustered index. That's just flat wrong. A clustered index is always 1. A 0 indicates a heap. Other indexes will have values greater than 1. If you were to supply a 0 to the INDEX() hint, as shown in the book, it forces either…
Read More