Q&A with Klaus Aschenbrenner
Practical SQL Server Performance Troubleshooting
Q: If your pre-con had a theme song, what would it be and why?
A: Easy! "Rock Me Amadeus" from Falco ;-) Why? Falco was the only musician from Austria who led the US Billboard, topping it with this song for 3 weeks. And I'm the first person from Austria doing a pre-con at PASS Summit. I can't sing as good as Falco, though, and you don't want that fact confirmed during my pre-con.
Q: What excites you most about troubleshooting performance problems?
A: Every day is a new, unique challenge. When I'm working with clients to troubleshoot their performance problems, you will always see a new facet of SQL Server, and you will always learn something new. No problem is the same as the previous ones. It's a constant learning experience, and that's great.
Q: Where does your workshop take attendees beyond what you might cover in a 60- or 75-minute session?
A: Doing regular sessions is like a Quickie - a SQL Server Quickie, of course! (See http://www.youtube.com/user/SQLpassion for an example.) You have to pack as much information as possible into your timeslot, and there is little time for demos or experiments. Every minute is planned accordingly. But talking a whole day about SQL Server is something different. You can go into much more detail, show how things react and behave under various conditions, and experiment.
In my pre-con, I'm taking a completely new approach. Instead of just showing loosely coupled SQL Server performance problems, I'm going through an end-to-end troubleshooting scenario. We’ll start with a basic OLTP TPC-E benchmark workload, establishing our initial baseline. And then throughout the day, I’ll show various performance problems inside SQL Server, how SQL Server is sometimes lying to you, and how you can fix all of those nasty problems. It will be a really fun and challenging day – for the attendees and me!
Q: What's the most surprising statement attendees might hear you say during the pre-con?
A: Indexing, indexing, indexing… it’s all about indexing in SQL Server! I see this every day in my various customer engagements. Almost every performance problem inside SQL Server has its root cause in bad indexing. And you will also see this fact in my pre-con. SQL Server often shows you various (sometimes strange) symptoms, but in nearly every case, the root cause is a bad indexing strategy in your database.
Q: What's the biggest myth in performance tuning that you'd like to debunk?
A: That you can eliminate parallelism issues by simply setting SQL Server’s MAXDOP option to 1. There is always a root cause, and you have to resolve that root cause. Parallelism and the CXPACKET wait type are just symptoms – nothing more!
Q: What still trips you up in your adventures with optimizing SQL Server?
A: My journey with SQL Server was pretty accurately described in 1966 on TV:
"SQL Server: The final frontier.
These are the voyages of the starship SQL Server Enterprise Edition.
Its never-ending mission:
To explore strange new problems,
To seek out new performance optimizations and troubleshooting techniques,
To boldly go where no query has gone before."
Q: If attendees could start putting into practice just one thing after your pre-con, what would you want that to be?
A: Establish a baseline! So many people are coming to me complaining about their poorly performing SQL Servers. But they can't tell me how bad their performance is because they haven’t established an initial baseline. When they try to make performance improvements, it's just a guessing game, because they have no baseline against which to compare their probable improvements. So establishing a baseline is the most important starting point when you're doing SQL Server performance troubleshooting.
Check out our other Q&As with PASS Summit 2012 pre-con speakers.