SQLServerCentral Editorial



The Weekly Update for Dec 17, 2007

Some quick hits on the news of the week from the perspective of a DBA.


There were quite a few blogs this week on various aspects of T-SQL. A number caught my eye and I thought were worth reading, so be sure to check out the blog list this week.


Part 2 of Dennis Gobo's series on interviewing went up this week and it was interesting. If you read SQLServerCentral.com regularly, you know that I'm big on managing your career and finding the right job for you.

Dennis has some good thoughts and while I'm not sure I complete agree with his posts or style, he does give good advice that wouldn't hurt you to follow.

Where NOT to use the CLR

I know Paul, though I haven't talked to him about this post. It's very interesting to hear a few notes from someone that's working on a high transaction system. In this case 35tps. Now I've seen a 10k tps and it was smoking, so I can't imagine 35ktps. For those of you confused, tps is transactions per second. So think about 35,000 transactions per second in your database?

Paul wrote some tips based on his experience and the one I was most interested in was #5. Apparently he wrote a CLR function to parse a string inside a stored procedure. It's probably something many of us have wanted to have before, it parses out a comma delimited string into parameters for use by the proc.

And it was slow.

In Paul's words, "painfully sloooooo" and so they had to find another way to process the data.

Now I've been skeptical of the CLR and how well it would process data inside a server. Especially when most people I know that write programs aren't top-notch programmers that have time to optimize functions to be as quick as possible.

And I was told repeatedly by people at Microsoft that my fears were unfounded and the CLR would work great. Apparently not.

While I believe Paul has an extreme case, this isn't exactly the evidence that I want to see in a subsystem that I might have to use. So a word to the wise, if you use CLR functions, data types, or anything else you've written with .NET languages, stress test it well to be sure it will work well beyond what you need. Finding out it's a bottleneck later on could be a huge problem.

Steve Jones

Creative Commons License

This work is licensed under a

Creative Commons Attribution-Noncommercial 3.0 United States License.

Steve's Pick of the Week

Real Data in App Testing Poses Real Risks - I know you know this, but re-read it. Don't expose real data in test environments, even internal only ones.

The Voice of the DBA Podcasts


The podcast feeds are now available on the Podshow network at voiceofthedba.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

The RSS Feed:

or now on iTunes!

Today's podcast features music by Incompetech. Kevin Macleod has some great compositions in all genres of music. Check him out at www.incompetech.com.

I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.


You rated this post out of 5. Change rating




You rated this post out of 5. Change rating