PASS Summit Birds of a Feather Lunch

October 13, 2010 at 11:18 am (PASS, SQLServerPedia Syndication) (, , , )

The absolute biggest part of the PASS Summit is the one thing that most people don’t take advantage of, networking. And no, I don’t mean glad-handing everyone you meet, remembering all their names (although that is a good skill to have) and saying over & over again “Rush Chairman, damn glad to meet you.” I mean taking advantage of the fact that you can talk to people that have already solved the problem that you’re facing at work, or just might have some insight into that issue, or maybe you can give them insight into a problem they’re facing. I’m mean, talking to people.

Yeah, I know, we’re all geeks, and worse than that, data geeks. That means we like to sit in dark little caves & grumble about our fellow man having WAY too much access to the data we’ve been sworn to protect. I’m with you. But, you’ve made the decision to go the PASS Summit. You’re there. All over the place are your fellow data geeks. And look at that, some of them are talking to each other. You can too. In fact, you should.

So, how do you break the ice? Here’s a suggestion. When you go to lunch on Tuesday, look for the Birds of a Feather tables. Each one will have a different topic, hosted by someone who knows at least a little about that topic, or is just really excited about discussing that topic. Sit down (you don’t need permission, it’s implied), introduce yourself and dive into the topic. Ask questions. Answer questions. At least say hi before you sit there and listen. You’re in. You’ve just made the leap. Welcome to networking. Now, find out where the party is for Tuesday night and you can do some more.

I’ll be hosting a table on the topic “T-SQL Tuning & Optimization.” If you’re interested in that topic, please, sit down & talk. Oh, I might be a minute or two late. I’m presenting right before lunch. Save me a chair, just in case.

Permalink Leave a Comment

SQL Saturday New England: The New Date

October 12, 2010 at 3:00 pm (PASS, SQLServerPedia Syndication) (, )

The real world can get in the way of important things like SQL Saturday. In the case of SQL Saturday New England, the original date was the same time as the Boston Marathon. Unfortunately, that means that Boston’s somewhat limited hotel space will be tweaked. Rather than try to compete with that, we moved the date. Please mark it as April 2nd, 2011.

Permalink 1 Comment

SQL Saturday New England: The Date

October 5, 2010 at 10:17 am (Uncategorized) (, )

Mark your calendars. Make your travel arrangements. Plan on being in the Boston area on April 2nd, 2011. Three of the local SQL Server users groups will be hosting a SQL Saturday event on that date. I’ll be blogging (a lot) with more details as they become available.

UPDATE: Fixed the date.

Permalink 1 Comment

SQL Saturday in New England

October 4, 2010 at 9:41 am (PASS, SQLServerPedia Syndication) (, , , , , )

Adam Machanic (blog|twitter) has put on a SQL Saturday/Data camp event in New England for the last two years. I’ve helped him both years. It’s been very successful. In January we had over 300 attendees, making it one of the larger SQL Saturday events. But, with a single exception (thank you Tim Ford (blog|twitter)), we’ve only had local speakers. Mind you, we’re somewhat lucky with speakers here in New England and have several MVPs and others who are truly excellent when presenting.

I’m taking over from Adam to lead the effort for this year, and due to my schedule we’re moving the event to the spring sometime. We were thinking about maybe making it the the weekend before SQL Rally. But, I’ve got a question for all of you who present at SQL Saturday events. Will you show up? Will you be more, or less, likely to come if it’s near SQL Rally. Will you be likely to come, period, full stop? While I strongly believe Adam has put on a magnificent show for two years running, for some reason we just haven’t received the community lovin’ that the other SQL Saturday events have had. Since I’m the one in charge (although Adam is still pitching in, and I’m getting help from the magnificent Mike Walsh (blog|twitter)), I’d like to make it as good a show as Adam has, so I need the other great presenters to show up, in addition to our fantastic local talent.

Comments, suggestions, questions, feedback?

PS: I hate asking questions like this on the blog, but I’m trying to collect some information so I can make a decision. Feedback is a gift, so if you want skip buying me a present for Yule this year, post a comment.

Permalink 11 Comments

How to Tell if Execution Plans are Reused

October 4, 2010 at 8:00 am (SQL Server 2005, SQL Server 2008, SQLServerPedia Syndication, TSQL) (, , , , , )

I try to watch the search phrases that point people to the blog because sometimes, you get a sense of what problems people are running into. The latest question or phrase I’ve seen a lot lately is along the lines of “how do you know if an execution plan is being reused.”

Since compiling an execution plan can be an extremely expensive operation, it’s worth your time to understand how well a given plan is getting reused. If you’ve seen me present, I’ll frequently talk about the application that had a query with an 86 table join. Recompiles on that thing were frequent and extremely costly. The only good news was, they were recompiles. If we weren’t getting plan reuse it would have been an even worse system than it was.

There are a number of ways you can see if a plan is being reused. One of the easiest is to hit the DMOs that look into the plan cache. You can look at either sys.dm_exec_procedure_stats or sys.dm_exec_query_stats. These DMOs are somewhat different and somewhat the same. Actually, they sort of cross each other. For sys.dm_exec_procedure_stats, you get aggregate information about stored procedures. For sys.dm_exec_query_stats you get aggregate information about queries, which, may be run within stored procedures. So either or both could be useful depending on what you’re attempting to measure. However, both return a very useful counter, execution_count. Quite simply, that tells you that the plan, whether for the statement or the procedure, is being reused. To get maximum gain out using either of these, you’ll want to combine them with other DMOs. Something along these lines can show you the plans for procedures that have been running against a system, ordered by the number of times they’ve been reused:

SELECT deps.execution_count ,
OBJECT_NAME(deps.object_id, deps.database_id) 'Procedure' ,
deqp.query_plan
FROM sys.dm_exec_procedure_stats AS deps
CROSS APPLY sys.dm_exec_query_plan(deps.plan_handle) AS deqp
ORDER BY deps.execution_count DESC

The only thing wrong with using the DMO like this is that you can only see what’s currently in cache. This means no history, depending on how volatile the cache is on your system.

Another way to tell if a plan is being reused, is to set up a server side trace and capture the event for the SP:CacheMiss or SP:CacheHit. This is pretty straight forward. If the query was not in, it generates a miss event. If it was there, it generates a hit. But, this has to be running in order for you to know if you had a hit or a miss. The good news is, if it’s running, you’ve got historical information since this captures the event as it occurs.

You can also catch recompile events using SQL:StmtRecompile. Yes, you can get SP:Recompile if you’re only ever dealing with procedures, but if you’ve got any kind of ad-hoc querying going on in the system or triggers, you’ll miss recompile events. Basically, because recompiles are at the statement level starting in 2005, BOL recommends only using SQL:StmtRcompile.

That’s pretty much it. Using these methods in the appropriate place will let you know if the plan is being reused or not.

Permalink 1 Comment

Parameter Name Size And Performance

September 27, 2010 at 8:00 am (SQL Server 2005, SQL Server 2008, SQLServerPedia Syndication, TSQL) (, , , , , )

I saw an odd statement the other day, “The size of the name of the parameter does not affect performance.” My first thought was, “Well, duh!” But then, I had one of those, “Ah, but are you sure” thoughts. And you know what, I wasn’t sure.

If size of the parameter name did affect performance, I figured, the one sure place where that would be evident is in the size of the execution plan. Right? I mean, if there was an impact on memory, and hence on performance, that’s probably where you’d see evidence of it. I wrote two queries:

 DECLARE @ThisIsAVeryVeryLongParameterNameThatIsTrulyRidiculousButItIllustratesThePointThatParameterLengthDoesNotAffectPerformance int
SET @ThisIsAVeryVeryLongParameterNameThatIsTrulyRidiculousButItIllustratesThePointThatParameterLengthDoesNotAffectPerformance = 572
SELECT soh.SalesOrderID
,sod.SalesOrderDetailID
FROM Sales.SalesOrderHeader AS soh
JOIN Sales.SalesOrderDetail AS sod
ON soh.SalesOrderID = sod.SalesOrderID
WHERE soh.SalesOrderID = @ThisIsAVeryVeryLongParameterNameThatIsTrulyRidiculousButItIllustratesThePointThatParameterLengthDoesNotAffectPerformance

DECLARE @v int
SET @v = 572
SELECT soh.SalesOrderID
,sod.SalesOrderDetailID
FROM Sales.SalesOrderHeader AS soh
JOIN Sales.SalesOrderDetail AS sod
ON soh.SalesOrderID = sod.SalesOrderID
WHERE soh.SalesOrderID = @v 

If you run this against AdventureWorks2008R2 you’ll get two distinct, but identical, execution plans:

You can see that they look identical, but how do I know they’re distinct? If you run this query:

 SELECT deqs.creation_time,
deqs.query_hash,
deqs.query_plan_hash
FROM sys.dm_exec_query_stats AS deqs
CROSS APPLY sys.dm_exec_query_plan(deqs.plan_handle) AS deqp
CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE dest.text LIKE '%SELECT soh.SalesOrderID%' 

You’ll get this back as a result:

creation_time                               query_hash                                 query_plan_hash
2010-09-23 18:18:09.347      0x8D0FB9D524B8DD4D       0x13707445560737BA
2010-09-23 18:18:16.223       0x8D0FB9D524B8DD4D       0x13707445560737BA

Two distinct queries, but with identical hash values, so the plans generated are nearly the same, but clearly different, due to the fact that they were built with different parameters, including the monster name. So, how to see if there is a difference in the plan generated that could affect performance? How about the execution plan properties. First, the property sheet for the SELECT operator for the query with the long parameter name:

Of particular note is the Cache Plan Size. Let’s compare it to the same property sheet for the small parameter name:

If you compare the two, you’ll see that they’re the same. In fact, if you look at almost all the values, you’ll see that the Compile CPU, Compile Memory, and Compile Time are all identical. Based on all this information, I have to conclude that no, the size of the name of the parameter doesn’t affect performance, positively or negatively. But why?

I’m actually not 100% sure, but based on some things I know, here’s what I think. The Algebrizer within the Query Optimizer breaks down all the objects referred to within a query plan. It assigns them all values and identifiers for that plan, part of getting the information together to feed the plan into the mathematical part of the Optimizer. I’ll bet it just assigns values to parameters that are the same type of value, if not the same exact value, and that value is the same size from one execution plan to the next.

This means that you don’t save memory by assigning parameters @a, @b, @c when in fact you mean @ReferenceCount, @MaxRetries, @BeginDate. Do I think you should put in parameters of the silly length I put in before? No, of course, not, because it makes the TSQL code less clear. But, so does putting in equally silly, short, parameter names.

Don’t make your TSQL code hard to read. It doesn’t help performance.

Permalink 3 Comments

SQL Saturday 46 (#sqlsat46) Recap

September 20, 2010 at 9:48 am (PASS, SQLServerPedia Syndication) (, , )

I was privileged to be able to attend and present at SQL Saturday 46 in Raleigh, NC, this last weekend. It was a great collection of people presenting some amazing stuff. I want to say, right off, I think this is the best SQL Saturday event I’ve been to. I say that despite the fact that I’ve helped put on a SQL Saturday. I also say that despite the fact that my sample size on SQL Saturday’s is fairly low. I’ve only been to three (including the one I put on).

You have to understand, the people who put on #sqlsat46, the Triangle SQL Server Users Group, did an absolutely outstanding job. They had clearly done the early work of getting sponsorships and organizing. This weekend, all that early work was on evidence. They had speaker shirts AND they had volunteer shirts. You could always tell who to talk to when you had questions. There was excellent signage, including signs on every door for all the sessions that were taken down as sessions finished, so you could tell which sessions were coming up and didn’t have to try to figure out what time it was or anything. The speaker dinner was at an EXCELLENT restaraunt called The Pit in downtown Raleigh. Sandra, the amazingly hard working volunteer responsible for the speakers did an simply wonderful job of making sure we had everything we needed to get our presentations off without a hitch. On top of that, she was really funny and fun to hang out with. There was a shuttle to get the speakers from our hotels to the speakers dinner & back. The food was excellent at breakfast & lunch and there was plenty of it. They even had an afternoon snack. They gave away a ton of excellent prizes. It was just a very well run event and a real pleasure to take part in it.

I can offer up but one criticism, and it’s pretty minor. The facilities were a little bit weak. First off, they were rather confusing to get around in and at one point Tom Larock (blog|twitter) and I got locked into a hallway that we couldn’t get out of. A little pounding on a door got someone’s attention and we were rescued (before I had to kill & eat Tom). The rooms that most of the sessions were in had an orientation such that entering or leaving the room required you to walk right in front of the speaker, so it was hard to show up late or leave early without being very disruptive. But, that’s it. Other than those two, minor, weaknesses, the facilities were nice, clean, well appointed, comfortable… you get the point.

As to people… Wow! Is the best thing I can say. I went to excellent sessions, one each by Andrew Kelly (blog|twitter) and Aaron Nelson (blog|twitter). I got to talk to and hang out with Andy Leonard (blog|twitter), Tom Larock, Allen White (blog|twitter), Tim Chapman (blog|twitter), Kevin Boles (twitter), Geoff Hiten (blog|twitter), Jessica Moss (blog|twitter), Eric Humphrey(blog|twitter)… yeah, look at that list. I’m not dropping names, I’m just in awe of who I got to talk to and I’m not listing everyone that was there. These guys at Triangle SQL pulled together an amazing group of people to present. The networking opportunities were just excellent. I got to meet a lot of new people too. Special shout out to Eli Weinstock-Herman (blog|twitter) who I met for the first time, ever, and had a great conversation with at the after party (along with Allen and a bunch of other guys).

I presented two things. A session on Red Gate’s excellent new piece of software, SQL Source Control. The room was full, the people were engaged and I had a great time. I hope everyone enjoyed the presentation. I also presented a preview of one of my presentations for the 2010 PASS Summit. Unfortunately I had spent most of my rehearsal time getting ready for 24 Hours of PASS, so I didn’t rehearse adequately for this session. I just didn’t do as good a job as I’m capable of. I’ll work on it some more and get it polished up for the Summit. But it was well received, so hopefully people got some good from it. That’s sure the goal.

To sum up, great people, great place, great opportunity. Thank you, very much to Jimmy, Brent, Sandra and all the rest of the magnificent people at Triangle SQL who put this show on. You guys should be damned proud of a job well done.

Permalink 2 Comments

Links From Twitter

September 7, 2010 at 12:34 pm (Misc) (, , , )

Normally, I try to stick to posting technical info or community stuff on the blog, but there were a couple of links from Twitter today that are too good not to share.

First, an interesting take from Tom LaRock on the issue around the lack of quality DBA’s. He suggests that it’s actually a lack of quality managers. Go read it & comment there.

Second, this is Not Safe For Work (NSFW). Please, please please understand that before you click on this link. It’s a hilarious discussion about NoSql. Put on headphones & give it a listen.

Back to your regularly scheduled blog posts…

Permalink 1 Comment

Recursive Hiearchies in Reporting Services

September 3, 2010 at 8:44 am (SQL Server 2008, SQLServerPedia Syndication, Uncategorized) (, , , )

I am not a Reporting Services guru and nor do I play one on TV. I am however forced to be all things Microsoft Data where I work. So I frequently find myself stretching way beyond my abilities. I just had to get a report running that feeds from a web service and has a recursive hiearchy with customized aggregation on multiple fields with drill down to a different set of details. Yeah, through the internet I can see the SSRS monsters rolling their eyes at the ease of this task. But for us mere mortals it was work. Since I spent so much time learning how to do it, I thought I’d share.

XML as a Source

First, because we have a very paranoid (and appropriately so) group of PeopleSoft administrators, I couldn’t get direct access to the Oracle database. Instead, they provided me with a web service. Easy enough to consume, but it comes back as XML. Good news is Reporting Services can consume XML through a URL. Bad news is that it has a sort of proprietary XQuery language that is extremely obtuse (or I find it so, but then I’ve had trouble with SQL Server’s XQuery as well).

Setting up the Data Source is extremely simple. When you select XML from the Type dialogue, it’s going to ask you for a Connection String. Supply the URL. Done.

The work comes when you need to set up the DataSet. When you set the Data Source the Query Type will change to Text. No options. And you’ll be looking at a big blank box of nothing. My initial XML data set was this stacked hiearchy that had nested departments, accurately portraying the structure of the data. To query this XML you can do one of two things, set up the XML path as described in this excellent Microsoft white paper or allow SSRS to parse the XML for you. I tried working through the path, but I kept excluding parts of the structure. Basically I needed a method to recursively union the data within XML and, frankly, that was too hard. So I tried the automatic route. What’s the query look like for the automatic route?

*

That was tough. But, the same problem occurred. According to the white paper referenced above, letting SSRS figure out how to parse the XML means it will walk through and identify the first repeating group within the XML and that will be the structure it uses for the rest of the data. So, in my example, I have Departments and Personnel. The Personnel are inside the Department and Departments are inside Departments which have other Personnel… etc. It looks something like this:

<?xml version="1.0"?>
<ROOT_SEGMENT>
<REPORT_TITLE>Monster Hunters Status</REPORT_TITLE>
<SUMMARY>
<DEPTID>997</DEPTID>
<PARENT_DEPTID></PARENT_DEPTID>
<DETAIL>
<EMPLID>000001</EMPLID>
<NAME>Shackleford, Julie</NAME>
<TERMINATED>N</TERMINATED>
<RETIRED>N</RETIRED>
</DETAIL>
<DETAIL>
<EMPLID>000002</EMPLID>
<NAME>Jones, Trip</NAME>
<TERMINATED>Y</TERMINATED>
<RETIRED>N</RETIRED>
</DETAIL>
<SUMMARY>
<DEPTID>998</DEPTID>
<PARENT_DEPTID>997</PARENT_DEPTID>
<DETAIL>
<EMPLID>000003</EMPLID>
<NAME>Pitt, Owen</NAME>
<TERMINATED>N</TERMINATED>
<RETIRED>N</RETIRED>
</DETAIL>
<DETAIL>
<EMPLID>000003</EMPLID>
<NAME>Newcastle, Holly</NAME>
<TERMINATED>N</TERMINATED>
<RETIRED>N</RETIRED>
</DETAIL>
<SUMMARY>
<DEPTID>342</DEPTID>
<PARENT_DEPTID>998</PARENT_DEPTID>
<DETAIL>
<EMPLID>000022</EMPLID>
<NAME>Harbinger, Earl</NAME>
<TERMINATED>Y</TERMINATED>
<RETIRED>Y</RETIRED>
</DETAIL>
</SUMMARY>
</SUMMARY>
</SUMMARY>
</ROOT_SEGMENT>

Problem is, the first repeating group didn’t include the nesting. That was a deviation, so it didn’t read in the same way. What I had to do, in order to use the automated parsing, was flatten the structure, moving the SUMMARY areas outside of each other. With the new structure, the query returned all the data. Now the trick was to get the department hiearchy into the report

Recursive Hiearchies

Thankfully, after a bit of searching, I found this in the documentation on SSRS. It shows exactly what I needed, the, incredibly simple, method for creating a recursive hiearchy. The only trick was to have the Parent field stored with the child records. You can see that in the XML above, but the original didn’t have it. Once that modification was in place, it was simple. Follow the directions. In my case, DEPTID became the grouping field. To support other functions I also changed the name of the group so it could be referenced in functions.

Once it was created, simply going into the Advanced tab in the Row Groups property window and setting PARENT_DEPTID as the recursive parent was all that was needed.

Way too easy. But, how to get the drill down and the aggregates?

Drill Down & Aggregates

 With that in place, the query will return hiearchical data, grouping on the DEPTID and keeping the parent child relationships in order. To establish drill down, it’s just a matter of going into the Row Group properties for the Department group again. In the Visibility tab, you set the visibility to Hide and check “Display can be toggled by this report item:”

Once that’s done, the recursive groups are only displayed as the little plus signs expand and contract the groups. It works great. You can even get fancy and add an indent function as shown in this bit of the documentation. But, how to do get the totals to display recursively? Not tricky at all. In fact, pretty easy. Since the data coming out has a set of flags that I have to check for positive or negative values, I have to use a expression to check them anyway. Something like this:

=Sum(CInt(IIf(Fields!HIRE_FLG.Value.Equals("Y"),1,0))

Luckily, built right into the function is a method to make it work recursively, so that you get totals of the children displayed with the parent. All that’s necessary is to supply the group, which I named earlier, Department, and tell it to total this stuff in a recursive manner, like this: 

=Sum(CInt(IIf(Fields!Terminated.Value.Equals("Y"),1,0)),"Department",Recursive)

Put one of these with the appropriate field and you have a nice neat report.

Conclusion

To finish up, none of this is rocket science. It’s just a question of knowing where to go and how to put it all together. Being a newb when it comes to Reporting Services, I spent a lot of time struggling. Now, you won’t have to.

Permalink 5 Comments

Upcoming Presentations: #24HOP & #SQLSAT46

August 30, 2010 at 8:53 am (PASS) (, , , , )

Blogging has been a bit quiet of late. That’s because I’ve been spending a lot my spare time getting ready for presentations that I have to give. Two of them are in about two weeks.

First, and this one is going to be a big deal, is 24 Hours of Pass: Summit Preview. At the PASS Summit this year I have two spotlight sessions, both on tricks and tools for tuning queries, one on using execution plans and the other on using DMVs. Since the 24HOP presentation is supposed to be a lead-in to the PASS presentations, I decided that before you started tuning queries, you need to know which queries to tune. The presentation is titled: Identifying Costly Queries. I understand there are already nearly 2000 people registered. Let’s see if we can break LiveMeeting on September 15th. And please, try to break LiveMeeting for all the other sessions too. 24HOP this year is spanning two days, plus another four hours, so it’s really 28 Hours of PASS. There are going to be some fantastic sessions by great presenters.

Second, and I’m very excited about this one too, I’m travelling for the first time (not counting driving the car) to a SQL Saturday event. Red Gate, wonderful people that they are, have sponsored my trip to SQL Saturday #46 in Raleigh, NC, on the 18th of September. I’ll be doing an initial run through of my PASS Summit session on using execution plans to tune queries. If you can’t make the Summit this year, but you can make it to Raleigh, this is your chance to see this session. Check out the schedule for this SQL Saturday. It’s going to be a huge deal. I see a whole bunch of MVP’s and authors who are going to be giving you their best stuff. I’ll also be doing a lunch time session on some Red Gate tools (have to pay for the trip). The software they released in the spring is SQL Source Control. It’s a pretty amazing bit of programming that works within SQL Server Management Studio to get your database into source control (and if you’re not using source control with your databases, time to start).

Between getting these, and other, presentations together, working on books (tech edited one, working on chapters on another, getting ready to rewrite the Execution Plans book), actually spending time with my family, oh, and going to work (note, I didn’t say working), my blog posts have suffered a bit. I’ll get back on the stick very soon. Hopefully before Tom updates his blog listings.

If you attend any of the in-person events  where I’ll this fall (and I’m going to four, SQL Saturday #46, New England Code Camp #14, PASS Summit, SQL Saturday #59), please look me up. Say hello. These events are all about networking and building community. The people that go and present expect you to stop them in the hall and talk to them. That’s what this community stuff is all about. Meeting people and making connections.

Permalink 4 Comments

« Previous page · Next page »