Mastering Index Tuning–Day 3

This is a short series of posts on the courses I took with Brent Ozar. I actually completed the courses in the past, but I wrote notes and wanted to revisit the way things went.

This post looks at the Mastering Index Tuning class. Other  posts are:

Day 3

As with Day 2, we begin with reviewing the labs from yesterday. These were harder labs, and Brent spent time looking at how he solved the labs, referencing parts of solutions some people had. This took awhile, with a break in the middle.

As usual, we can ask questions and discuss the solutions in Slack, which Brent keeps an eye on.

We start the lectures with artisanal food, which Brent does enjoy. Hand crafted items from the chef, which felt funny since my car killed something and left an organ of some sort in the bathroom.

The analogy is that there are artisanal indexes, like those on computed columns, indexed views, and filtered indexes. These are items that can help in specific situations, but in general we don’t want to use them.

I like that Brent brings in the experience they’ve had with clients, noting that some of these features don’t work well.

The afternoon lab is fix some really bad reporting procedures with indexes (regular or artisanal) or changing code. I know I can’t always change code in databases, but this gives us a chance to try things. I ended up changing some code, but not much. The lab review after lunch was interesting, as Brent had a strange result with the last proc. Looking forward to seeing his debugging of this later.

The lecture after lunch moves to the end of D.E.A.T.H, heaps. I hate heaps, so this was interesting. Brent agrees with me, you really need a CI on the table. Maybe there are some reasons to not use one in a situation, but most of you need to just add a key.

The last part of the afternoon looks at the impact of CIs and then constraints and FKs. The CI part is interesting. I see lots of people talking about how to decide on this. I tend to lean towards Brent’s view, which he’s presented on and it’s in the class. Take the class if you want to learn (I don’t want to republish here).

For FKs/constraints, the module had lots of discussion. People think about FKs in interesting ways. I’ll have to re-watch this as I got busy in the middle with other stuff and missed some lecture.

The final lab is a big one. Use all the skills from the three days of the class. Restore the db, run a setup that messes up indexes, then fix things. It was a challenge, and I burned about 12 minutes deduping and eliminating indexes, then about 20 coming up with more to add. The creation took quite some time, so I never really got around to tuning, and since this is only part of my day, I had to stop. I do have some real work to do.

The final lab solution goes up the day after, and what Brent came up with was interesting. I liked watching the videos later to see how he approached the issues and solved them. I like that there wasn’t “one” solution, and he talks about how we might solve the lab that would be different than production.

That’s important, and it’s something that I appreciated in this class. I know better, but it’s always good to be reminded that the class is a game, a model of what could happen, but in the real world, these are just tools that might help, but could hurt. Judgment is still needed.

The Aftermath

One thing I like about this class, which I’ve missed in some live classes, is that I can re watch sections of the class later. The class page has a list of all the lectures and labs, with each containing a video. Some might be from my class, some from previous ones. Since this is delivered and recorded in a modular fashion, Brent can update sections over time.

I went back to watch the first Artisanal index module, as I was distracted that morning by something at work. That was a nice benefit.

The Final Word

This was a great class. I haven’t been to a real class across multiple days in awhile, and I think the format of some lecture, a lab (with interactivity), and then a review of the lab, was great.

The lectures were interesting, and I learned a few things. The labs were challenging, designed to force you to work within constraints to tune something. Indexing is often a place where you can make changes and rapidly affect your system. The effects could be good or bad, so you need to be sure you are proceeding in a methodical fashion and also capturing metrics on the changes.

If you’re interested in the class, you can visit the Mastering Index Tuning page to learn more and purchase the class.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Blog and tagged , , , , . Bookmark the permalink.

6 Responses to Mastering Index Tuning–Day 3

  1. Brent Ozar says:

    Wow, glad to hear you liked the course, man! These are so much fun to put on, especially with the labs. It’s fun to see the students talking to each other, proving what they learned, and seeing the different ways they can solve a problem.


    • way0utwest says:

      I agree, and thanks for inviting me to join in. The discussions are fascinating. Much better than many of the live classes I’ve had in the past.


    • Brent Ozar says:

      It was funny how it came about – the first live class I did, I had the students email their homework directly to me, and I’d analyze it. I figured out in the very first class that it wouldn’t scale – I can’t give 30-40 people personalized assessments on complex problems unless I work on them overnight. The “I’m your manager, ask me for permissions in Slack, and look at what the other students are doing” approach worked so much better/faster, and it’s more like real life, to boot.


  2. way0utwest says:

    It’s brilliant. You’ve done a great job putting these together.


  3. rsterbal says:

    I assume you used the Stack Exchange database. Are their other databases that would be interesting to try for a class like this?


  4. way0utwest says:

    Anything with thousands, or really, millions, of rows is good. You want to be able to see how logical reads react to different indexes across a range of queries. I think SO is a little small in terms of schema. You could easily use AdventureWorks, but use one of the “Big” scripts top make it larger.


Comments are closed.