Click here for a video of the 2009 Hotsos Symposium.
Will you be there next year?
Saturday, May 23, 2009
Thursday, May 14, 2009
BBQ in Phoenix AZ
Ahhh... a great lunch at the BBQ Company here in Phoenix AZ. I got a 1/3 rack of ribs for lunch with some sweet beans and a corn medley. Excellent sauce, and the corn medley was particularly good. The only bummer about this place is that it's only open for lunch. This is now added to the list of places to get to while in Phoenix.
OK, now back to some SQL optimization... How many LIOs is that thing doing?!?!
OK, now back to some SQL optimization... How many LIOs is that thing doing?!?!
Wednesday, May 13, 2009
Breakfast at Matt's
One of my other favorite foods is Breakfast Food and in particular Waffles. Matt's Big Breakfast has the best Waffles I've ever had. And the other food there is excellent as well. I try to get to Matt's at least once each time I'm in the Phoenix/Tempe area in Arizona. This morning was the day for this week and my waffle was excellent as always!!
They open at 06:30 and the best thing to do is to be there at opening if you want a seat. There aren't many and they go fast!
They open at 06:30 and the best thing to do is to be there at opening if you want a seat. There aren't many and they go fast!
Tuesday, May 12, 2009
The SQL runs fast but....
For the most part I don't think any one would get to excited about dealing with a SQL statement that runs in .3 seconds. Most of us are worried about the statements that run for hours and we tend to focus on them. Which is not necessarily a bad thing. But how many statements on your system fit into this category I'm about to describe?
This statement on a per execution runs in .336 seconds, and does 1,627 Logical IOs. It's a pretty simple 3 way table join. All the predicates are simple equality ones that are ANDed together. The kicker is that this statement was called 5,935 times in a 40 minute window for a total of 9,658,869 LIOs and 275,527 Physical IOs and didn't return any rows. For this 40 minute trace this statement consumed 69% of the total response time and nearly all the PIOs via Sequential Read events. All this to get back nothing.
Maybe the statement can be optimized to do less work, but the real question is why do this at all? Is there a way to avoid running this statement at all?
It's easy to see why no one would have even looked at this SQL in the conventional tuning type engagement. It's fast, the LIOs per execution aren't necessarily bad either given that the tables involved are rather large. Looking at it from a per execution basis, there isn't much reason to get excited. But when looked at with in the context of a running application, it's easy to see that this statement is doing a lot of work for nothing.
This statement on a per execution runs in .336 seconds, and does 1,627 Logical IOs. It's a pretty simple 3 way table join. All the predicates are simple equality ones that are ANDed together. The kicker is that this statement was called 5,935 times in a 40 minute window for a total of 9,658,869 LIOs and 275,527 Physical IOs and didn't return any rows. For this 40 minute trace this statement consumed 69% of the total response time and nearly all the PIOs via Sequential Read events. All this to get back nothing.
Maybe the statement can be optimized to do less work, but the real question is why do this at all? Is there a way to avoid running this statement at all?
It's easy to see why no one would have even looked at this SQL in the conventional tuning type engagement. It's fast, the LIOs per execution aren't necessarily bad either given that the tables involved are rather large. Looking at it from a per execution basis, there isn't much reason to get excited. But when looked at with in the context of a running application, it's easy to see that this statement is doing a lot of work for nothing.
Saturday, May 2, 2009
Use the Force!
I was out this morning and saw this group at a local comic book store. I just couldn't resist getting a picture with them. They didn't have any BBQ...
Subscribe to:
Posts (Atom)