Databases Eight Years from Today, 2018 Edition #TSQL2sday

Blog Posts

Almost exactly five years ago today, back in March of 2013, I wrote a post called Databases Five Years from Today. In it, I predicted:

  • You’d still be supporting 2005 and 2008 – while the number of 7% of servers are still 2005 and 2008 might seem small, it means that on average, every shop with 14 servers still has one of these boat anchors. (The folks at Quest recently told me the number of 2000 servers is still big too, but their monitoring app just stopped supporting 2000, so that was that.) I give myself a point on that.
  • There’d be no widespread adoption of Hekaton, columnstore indexes, or AGs – and I’d concur here. I don’t have solid numbers to back these up, but I bet less than 1 in 5 production servers has any of these 3 features. I give myself a point here.
  • We wouldn’t see massive widespread migrations to Azure SQL DB – but I was careful to point out that I was only talking about existing apps, whereas new development would likely start in non-SQL-Server places. I know Azure SQL DB gets a lot of press, but as of March 2018, the prediction date, the widespread migrations aren’t happening. The painful implementation of cross-database queries alone made it a non-starter. I give myself a point here too.

3 for 3, that’s pretty good – especially given how far out on the lonely island I felt when making those predictions. But you know what’s interesting? Fast forward just one or two more years, and my accuracy would probably drop by a lot. Predicting more than five years out is really hard. Surely nobody could get that right.

The 100th T-SQL Tuesday says, “Predict 100 months out.”

Adam Machanic asked us to look out 100 months, or about 8 years. To give you some idea, here’s a sampling of my blog posts from 8 years ago:

  • MCM Prep Week: Interview with Joe Sack – I was just starting to go through the MCM program, and Joe was running it. Today, I run a consulting company, and Joe designs adaptive query processing, and we’ve also both changed employers at least twice since that post.
  • SQL Azure FAQ – the product was just launching. Since the post, it’s gone through more name changes than Joe & I have had jobs. It grew in ways you would expect (max database size is up to 4TB), and had some odd head fakes along the way (remember Federations?)
  • SQL Server Magazine Bankruptcy – I’m old enough to remember a time when this was a physical print magazine that you could hold in your hands.

So with that in mind, some of these predictions are going to seem a little wacko, but I’m aiming way far out. Let’s go from safest to riskiest bets.

In 2023, DBAs will still be a thing.

The safest bet in this post – this seems so incredibly obvious to me, but there’s still “thought leaders” out there saying the opposite, so I have to put this down in writing.

There’s a chance we’ll be called Database Reliability Engineers, but the core parts of the job – designing, building, securing, and scaling data storage – are still going to be a lucrative career in 2023. In fact, it’s going to be even bigger because…

The data safety business will look like the car safety business.

Car manufacturers struggle with safety regulations: every country insists on having their own slightly different standards. For example, over in Europe, you can get adaptive headlights that automatically point out things you should be seeing, and dim specific areas of the light so oncoming drivers aren’t blinded.

Last minute add-on to the deployment

In the US? Nope – a 1968 law prohibits them.

Turn signals in the US: amber. In the EU: clear. Fog lights in the back of the car? Required in the EU, never seen in the US.

But car makers have to build vehicles that are sold everywhere, and countries refuse to agree on what’s “safe.” Manufacturers end up with fleets of lawyers, designers, and engineers to build all kinds of differences to meet where a particular car is sold.

We don’t have that luxury in the database business: the same web site code base has to service customers everywhere, and meet different regulations based not on where the customer is surfing from – but a combination of their location and what country issued their passport.

This is gonna suck, bad, and governments simply aren’t going to suddenly start cooperating on a single data standard that works for everyone. That’s not how governments work.

Update 2018/09/23: California passed their own act, which doesn’t line up with the GDPR. There’s no United States standard yet.

<= 5% of SQL Servers will run on Linux.

(To be clear, I’m talking about Windows as their primary OS. Yes, a lot of SQL Servers run in virtual environments inside VMware, so it’s SQL-in-Windows-in-Linux, but that doesn’t count as running SQL Server on Linux. I’m also not talking about Azure SQL DB – I wouldn’t be surprised at all if Microsoft switched that over to Linux in the 8-year time span.)

Where’d I get the number from? Well, today in 2018, 72% of installs are from the last 8 years, SQL 2012/2014/2016/2017. That means 8 years from now, maybe 72% of installs will be SQL Server 2017 or newer – and 2017 is required for Linux support. Realistically, the only Linux install range would be 0-72%.

Even if 1 in 10 new SQL Server 2017s were installed on Linux, that’d still only be 7% of the install base. This prediction is way safer than it looks. (I almost said 1%, but I think there’s a decent chance that truly large shops – like shops with over 1,000 instances – will use Linux, and even small adoptions there have a big difference in the numbers.)

Your developers will have several projects built with serverless architectures.

Right now, when I talk to data professionals about serverless architecture, I can almost hear them tuning out. I understand – until you’ve used it, it just seems so farfetched. But going from our experience on PasteThePlan and SQL ConstantCare®, it’s utterly phenomenal.

But serverless is going to mean way more to you in 8 years than Docker containers, SQL Server on Linux, graph databases, or Hadoop. Your developers are going to be all about building apps in function-as-a-service platforms, and they’re going to wonder why databases are so far behind.

Your default new database will be in a cloud PaaS.

Five years ago, when someone asked for a new SQL Server database, you might have created it either on a shared physical server, or a shared (or rarely dedicated) VM.

Today, you probably default to creating a new database on an existing virtual machine. Most of those virtual machines live on-premises, but there’s a significant percentage that live as VMs in Azure VMs, Amazon EC2, and Google Compute Engine. You wouldn’t dream of deploying a new physical server by default.

Today, you likely wouldn’t respond with, “Sure, I’ve created you an Azure SQL DB. Here’s how you connect.” For SQL Server, your only two PaaS options today are Microsoft Azure SQL DB and Amazon RDS SQL Server. Microsoft’s on the cusp of releasing a 3rd option, Azure SQL DB Managed Instances. Their marketing site says it’s in public preview, but it’s not – you can sign up, but they don’t have enough staff to support new users.

By 2026, I think the next shift will already be over and done – just as we switched from physical boxes to VMs, we’re going to shift – but not to VMs in the cloud. In 2026, I bet your default new database will be in a Platform-as-a-Service option. It might be Azure SQL DB Managed Instances, or something else entirely.

Which brings me to the next prediction…

2 big clouds will offer an MSSQL-compatible serverless database.

Amazon’s got a head start on this in preview now: Amazon Aurora Serverless is an on-demand, auto-on, auto-scale, auto-off database server with MySQL compatibility. You don’t pay for instances, availability zones, or regions – you just pay for the queries you run, per hour that you’re making database queries.

If you haven’t seen Aurora yet, the intro video does a great job of explaining why businesses hate databases:

I’m predicting a couple of very big leaps here:

  • Google and/or Microsoft are going to follow suit on Aurora Serverless’s pricing, and
  • Amazon and/or Google are going to offer their own Platform as a Service implementation of Microsoft SQL Server (like Azure SQL DB, but different) – or Microsoft is going to license it to them, or who knows, even open source some part of MSSQL that enables this to happen

Either of these bets is risky on the 8-year horizon, but I’m going out on a leap and making both. I’m going to hedge my bets a little though:

  • They may not be compatible with the latest version of SQL Server – for example, if it came out today, I think it’d get serious adoption even with just SQL 2012 compatibility. (That’d be 61% of the market, remember, and old apps are often on autopilot with low performance requirements, great fit for a serverless database.)
  • They may not get any quick adoption – it takes years for a service like this to catch on. (Azure SQL DB is a great example – it’s 8 years old now.)

Update 2019/05/06: Azure SQL DB Serverless is out.

Microsoft will fix the “String or binary data would be truncated” error.

This is the riskiest prediction out of all of ’em.

Oh I know what you’re thinking: it’s been the top-voted user request for over a decade, and as soon as Microsoft dumped Connect and switched to a new user feedback system, this request immediately bulleted to the top of the list again, getting almost 3x more votes than the #2 issue!

And yes, someone from Microsoft recently commented on it:

Much better than passive-aggressively looking at it

All I can say is:

Update 2019/03/20: this error is fixed in SQL Server 2016 SP2 and SQL Server 2017 with trace flag 460.

Read the Comments

The Road to PASS, Week 5: Submitting Your Abstract

In this month’s Road to PASS series, I’m challenging you to submit an abstract for the PASS Summit:

My Week 4 homework results

I posted my abstracts on, then linked to them on social media: Facebook, LinkedIn, and Twitter. I got most of the feedback from LinkedIn! I find that interesting because I don’t really think of LinkedIn as a discussion platform, but it really worked well here.

Most of the feedback I got involved suggestions to cover more material – you should add this, that, etc. That’s totally normal – but you gotta be careful about what you add. In a 75-minute session, it’s so easy to scope creep your way to 80, 90, 100, 240 minutes. I’ve got so many things I want to teach, but I have to figure out how I can teach the very most valuable things in the limited time that I have.

The feedback of “you should cover this” is still really valuable because if I’m not going to cover something deeply, I may need to mention that in the abstract. For example, in my final How Often Should You Run Backups and CHECKDB abstract (only visible after you’ve signed up for the Summit Call for Speakers), I added a line:

We’ll briefly touch on how log shipping, Availability Groups, and SAN snapshots affect maintenance scheduling, too.

I did that because I wanted to set expectations that these things were only going to be mentioned in a slide or two – they weren’t the focus of the session (even though they easily could have been.) Focus is about saying no.

When in doubt, I’d rather under-sell the detail on an abstract. When I’m submitting a new abstract, I don’t have the presentation already written. I might not be able to cover everything I wanna cover in the time that I have. (This was a major theme in the homework sent in by readers – a lot of you wanted to cover 8 hours of material in 75 minutes. That’s awesome, but it’s also a recipe for being onstage and saying, “I’m sorry, but I have to skip this part because I’m running out of time.“)

Now, let’s submit it to PASS.

Presenting Erik Darling…Presenting

You’ve put a ton of work to get the technical details right. You’ve clarified the perfect attendee, you understand what you’re going to teach them, and you’ve distilled the abstract down as short as practical. Don’t second guess it now – just take the plunge.

Submit the abstracts to the 2018 PASS Summit Call for Speakers. Don’t overthink the categories, tracks, or levels – they’re something we all struggle with, and the Program Committee has been known to shuffle abstracts around when they disagree with you. The important parts are the title and abstract, and those are the parts you’ve worked so hard to nail down.

It’s going to be really tempting to look at other peoples’ abstracts to figure out if someone else is teaching the same topic – don’t. You’ve put a lot of work into crafting your abstract. Don’t worry about what other people are doing. Play your game, and if you’ve done a great job at this, the rest will take care of itself.

Most of our abstracts won’t make the cut.

It’s just simple math: there are way more abstract submissions than sessions. Every year, most of my abstracts get turned down, too. I’m never mad about my abstracts that get turned down because it’s a great problem to have – our community is teeming with volunteer speakers. That’s awesome.

And all it takes is one of yours to get accepted. You don’t need all of them. You just need one. And the more work that you’ve put into each of your abstracts, the better odds they have.

Good luck. I hope one of yours makes the cut!

Read the Comments

The Road to PASS, Week 4: Gathering Feedback

Blog Posts
No Comments

In this month’s Road to PASS series, I’m challenging you to submit an abstract for the PASS Summit. Week 1 challenged you to write a few pain points you’ve solved this year, week 2’s homework was to write the session’s recap slide, and week 3 had you writing the abstract’s technical details.

Now, I need to get feedback on my abstracts – so I’ve posted them on GroupBy:

Eagle-eyed readers will notice that I tweaked the titles on a couple of ’em. I’ve noticed that if I walk away from an abstract for a week, do my (fake) day job and live my life, and then come back, I have an easier time with themes and titles. I wanna get the technical bones out first, make sure I’m totally happy with that, and I can always add in more catchy stuff later.

You’ll also notice that I don’t have much catchy or upbeat language in there yet. I’m still letting the technical parts of the material settle in. Did I hit the right points? Is there anything I’m missing that I should cover? Is there anything I can take out so that I can do better justice to less material?

I’ll tweet links to those posts a couple/few times through the week and stay on top of the comments that come in. It’s natural to feel like you need to defend the material – after all, it’s your newborn – but take comments seriously. It’s so much better to get constructive criticism BEFORE you submit to PASS rather than have someone explain to you later, “Here’s why it never could have made the cut.”

Now, how about yours?

Your homework for this Sunday, March 4th, is the technical detail of your abstract(s). The public posting & feedback-gathering isn’t due until Sunday, March 11th, but I’m blogging a little ahead of you in the process so you can see what’s coming.

If you commit to doing the process with me, I’ll commit to reviewing your work throughout. You can either turn it in via email to, or in the #PresentingOrSpeaking channel of

Read on in Week 5: Submitting Your Abstract

Read the Comments

The Road to PASS, Week 3: The Abstract’s Technical Details

Blog Posts
No Comments

In this month’s Road to PASS series, I’m challenging you to submit an abstract for the PASS Summit. Week 1 challenged you to write a few pain points you’ve solved this year, and week 2’s homework was to write the session’s recap slide.

This week, let’s write the technical part of the abstract. It’s tempting to start with a catchy theme or title, but hold off on that – your abstract needs good bones first, and we can always dress the skeleton in different clothes later. Let’s think about the basics first.

Given your recap slide from last week:

  • What did the attendee already know when they walked in?
  • What new things did you teach them during the session?
  • How will they know they need to attend this session?
  • Who should not attend this session, and is there a way we can filter them out in the abstract?

The process will be a little more intuitive after reading through what I’m working on:

How often should you take backups and run CHECKDB?

Here was the recap slide from last week:

  • Understand what scenarios would cause you to do what kinds of restores
  • Get the RPO/RTO HA/DR worksheet
  • Fill out the current state columns with sp_BlitzBackups
  • Use my management tips to get real RPO/RTO goals from the stakeholders
  • When the jobs are too slow, use my time-saving tricks for backups and CHECKDB
  • Trend database size & backup times to understand when you need to recalculate

With that in mind, here’s my target attendee profile:

Deb the DBA is the only database administrator in her shop, and she’s not even really comfortable with the job title – she feels like an impostor. She’s been to a Microsoft DBA certification training class where she was taught the differences between full, differential, and log backups, but the class didn’t really tie anything to real world recovery needs. Today, she does a full backup on every server once a day, and log backups every hour – because it seemed like the right thing to do. She’s never had a talk with the business about RPO and RTO, but that one time when she did lose production and she had to restore it, the business was pretty happy with her ability to get it down to just an hour of data loss. She’s wondering how it’s done in bigger shops.

That profile led me to write this abstract:

You’ve been taking SQL Server full and log backups for a couple of years now, and you’ve even done a few successful restores when your butt was on the line. But now that you’ve decided to become a professional database administrator, you’re wondering what kinds of restoration problems you’re going to run into in the future. Are there patterns and practices that a Senior DBA would have taught you – if you were lucky enough to work alongside one?

I want to help. I’m Brent Ozar, and I’ve worked with a lot of shops whose nightly maintenance tasks spiraled out of control. From long backups to corrupt restores to dropped tables, you’ll learn the kinds of server emergencies that have brought DBAs to their knees. I’ll show you how to prevent emergencies before they strike.

I’m not really in love with that abstract yet. I think it brings the right audience members in, and excludes the right ones (folks who’ve never learned from another DBA.) It just doesn’t grab me and shake me. That’s okay – I’ll add in a fun theme later. First, I just need to let that sit for a week and figure out whether the bones work well.

What to do when SQL Server is unusually slow

Here’s my recap slide:

When your SQL Server is unusually slow, step through these in order:

  • sp_WhoIsActive @get_locks = 1, @get_plans = 1
  • sp_BlitzFirst @ExpertMode = 1
  • sp_BlitzCache @ExpertMode = 1, @SortOrder = ‘all’

With that in mind, I’m going to skip the attendee profile and jump straight into the abstract:

“Is something going on with the SQL Server right now?” You hear those words, and your heart starts to race a little faster. You try to connect to the SQL Server, and it responds, but you can tell it’s a little slow. You open up Activity Monitor, look at recent expensive queries, and maybe open up the Windows event logs to see if anything’s happened recently.

There’s gotta be a better way, right?

Good news – there is, and you’re about to learn how the pros do it. In one all-demo session, you’ll watch Brent Ozar use sp_WhoIsActive, sp_BlitzFirst, and sp_BlitzCache to solve several common emergencies. You’ll walk away with a written checklist to solve typical performance emergencies.

With that abstract, I don’t bother defining whether someone is a DBA, developer, sysadmin, or manager. I’m not concerned with their job title. Instead, I focus on them having to do the specific task in the opening paragraph. If it rings a bell, then they’re the right person for the session. They don’t need to know T-SQL or DMVs.

I’m also not defining their level or seniority because the 3rd paragraph tells them exactly what they’re going to learn. At first, it feels kinda odd for the abstract to give away the punch line, but that’s exactly the point. If someone’s already comfortable with sp_WhoIsActive, sp_BlitzFirst, and sp_BlitzCache, I don’t want them in the session. If I hid the tool names, someone who already knows those 3 tools might think I’m going to teach them a new trick. Here, that’s not an issue.

Analyzing parallelism

My recap slide said I’m going to break out parallelism by what parts of the SQL Server startup, login, and query execution process influence parallelism, and how to see the effects afterward. I’ve added a little more details to it here:

  • Server startup: Cost Threshold, MAXDOP, core count, NUMA nodes
  • Login: Resource Governor
  • Database picked: MAXDOP
  • Query plan built: query hints, parallelism inhibitors, types of tasks that benefit from parallelism
  • Single query in progress & aftermath: live plan, actual (completed) plan, parallelism operators, thread stats, DMVs that show DOP, XE
  • Multiple execution aftermath: parallelism operators in estimated plans, DMVs that show DOP

I’ve been thinking a lot about this, and I think I need to visualize it for them on a two-sided sheet of paper. One side will show how SQL Server decides whether a task will go parallel, and the other side will show how to see the effects of it when doing diagnostics.

The target attendee profile:

Tom the Tuner lives in queries and query plans. He knows he can fiddle with MAXDOP at the server level, and he knows that scalar UDFs are bad for parallelism. He works with a dozen developers who all write C# code that queries SQL Server, and when the query doesn’t go fast enough, they bring it to Tom. He really enjoys performance tuning, and spends 4-16 hours per week reading query plans and tweaking queries. He’s read blog posts from Adam Machanic, Erik Darling, and Paul White, but he wants something a little simpler to crystallize what’s going on with parallelism. He has a background in development, and he’s never managed servers. He’s been to a few PASS Summits.

Of the 4 abstracts though, this is one I don’t think I can write until I sketch out the first draft of the visualization. I’ve gone through a couple iterations in my mind, and when I get back home after SQLBits, I’m going to try a few sketches out to see what works. Depending on how complex things get, I may end up just focusing on one side of the piece of paper: either the factors that influence parallelism, OR how to see the effects of it when doing diagnostics. I’ll probably give them both sides – but given the time in a 75-minute session, I’m thinking I might only be able to explain one side.

This is also the kind of session where I might even write the slides for both sides of the paper, and even publish the deck with both sides, but the abstract might only cover the side I think is most important. That way, if I end up finishing WAY early, I could cover both sets of slides. That’d be a hell of a tough challenge though.

Demystifying cardinality estimates

The recap slide for this on:

Look at the driver operator (top right) first, and:

  • Can SQL Server quickly understand your T-SQL?
  • Are you asking for something that’s already stored on disk?
  • Are there statistics about the data you’re asking for?
  • Is the data stored in a way that makes subsequent operations easier?
  • Now move through the plan’s operators, repeating those questions

The more YES’s you have, the better SQL Server’s estimates will be.

So the perfect attendee profile is Tom the Tuner – but long before he got his current role. It’s targeted at Tom back when he was a C# developer, and he only spent about 1-2 days per week in SQL – the rest in Visual Studio. He’s massively interested in databases, and he loves learning, but he doesn’t even know what he doesn’t know yet about SQL Server. When he sees a bad query plan, he’s still in the mentality of OPTION (RECOMPILE) and updating statistics.

So for an abstract, let’s start with:

You’ve been writing T-SQL queries for a few years now, and when you have performance issues, you’ve been updating stats and using OPTION (RECOMPILE). It’s served you well, but every now and then, you hit a problem you can’t solve. Your data’s been growing larger, your queries are taking longer to run, and you’re starting to wonder: how can I start getting better query plans?

The secret is often comparing the query plan’s estimated number of rows to actual number of rows. If they’re different, it’s up to you – not the SQL Server engine – to figure out why the guesses are wrong. To improve ’em, you can change your T-SQL, the way the data’s structured, or how SQL Server thinks about the data.

This session won’t fix every query – but it’ll give you a starting point to understand what you’re looking at, and where to go next as you learn about the Cardinality Estimator.

I love the first paragraph and the last one. I’m not wild about the middle one yet.

Now, how about yours?

Your homework for this Sunday, February 25th, is your recap slides. The technical parts of your abstract aren’t due until Sunday, March 4, but I’m blogging a little ahead of you in the process so you can see what’s coming.

If you commit to doing the process with me, I’ll commit to reviewing your work throughout. You can either turn it in via email to, or in the #PresentingOrSpeaking channel of

Read on in Week 4: Gathering Feedback on Your Abstracts

Read the Comments

The Road to PASS, Week 2: The Recap Slides

Blog Posts
No Comments

This year, I’m working with you to get you to the PASS Summit stage. Last week, we talked about your first homework: a list of a few pains you’ve relieved over the last year.

This week, you need to write the recap slide for each of those pains. Think about the end of the session: when the attendee walks out, what are the most crucial takeaways you want on their mind? What do you want them saying, “Thank God I went to that session, because now I know that ____. When I get back to the office, I can’t wait to ____.”

Let’s tackle my pain point topics.

How often should you take backups and run CHECKDB

The recap slide for this one should cover:

  • Understand what scenarios would cause you to do what kinds of restores
  • Get the RPO/RTO HA/DR worksheet
  • Fill out the current state columns with sp_BlitzBackups
  • Use my management tips to get real RPO/RTO goals from the stakeholders
  • When the jobs are too slow, use my time-saving tricks for backups and CHECKDB
  • Trend database size & backup times to understand when you need to recalculate

I think those are the most important things I can teach ’em in 75 minutes. That list of bullet points tells me a lot: the session level, what they already need to know coming in, what kinds of attendees should attend, which kind shouldn’t attend, and more.

For time budgeting, I’m guessing I wanna spend 10-20 minutes on each of those.

What to do when SQL Server is unusually slow

I’ve done this one a lot, and in the past, the recap slide has been a list of tools. For the new session, I want it to be a T-SQL file with the commands filled in – and they’re so short that it’s easy to just use a screenshot of the commands:

When your SQL Server is unusually slow, step through these in order:

  • sp_WhoIsActive @get_locks = 1, @get_plans = 1
  • sp_BlitzFirst @ExpertMode = 1
  • sp_BlitzCache @ExpertMode = 1, @SortOrder = ‘all’

This looks like a short list, but the way I teach this is to use a series of server emergencies to troubleshoot live, so it ends up taking ~20-25 minutes per scenario.

Analyzing parallelism

I’ve been thinking a lot about this one over the last week, and it feels like I need to tell the story in terms of time. Your server starts up, certain things are set in place that affect how queries are handled. Then someone logs in, and they inherit settings from their RG workload group. Then they use a database, and they inherit that database’s MAXDOP. As they start a query, their query contents change it yet again.

So the recap slide might look like this:

  • Server startup: Cost Threshold, MAXDOP, core count
  • Login: Resource Governor
  • Database picked: MAXDOP
  • Query starts: query hints, parallelism inhibitors
  • Single query in progress & aftermath: live plan, actual (completed) plan, parallelism operators, thread stats, DMVs that show DOP, XE
  • Multiple execution aftermath: parallelism operators in estimated plans, DMVs that show DOP

Looking at that list of 6 bullet points, holy cow – it’s not going to be possible to explain how all those things work in 75 minutes. That means I’ve either gotta reduce the scope, or I’ve gotta set the stage as, “I’m not going to teach you how all these things work, but I’m going to give you a mental toolkit you can use to investigate parallelism challenges.”

It’s kinda funny – when I wrote my list of 4 topics, this was the one I liked the least because I thought I’d have the toughest time making it interesting. Now, I like it a lot.

Demystifying cardinality estimates

This one’s more about a thought process – getting people to read an execution plan, correlate the plan operators with the T-SQL they passed in, and then think about how easy (or hard) it is for SQL Server to guess how many rows will come out of each operator. So for this one, I’m thinking the recap slide is better as a series of questions:

Look at the driver operator (top right) first, and:

  • Can SQL Server quickly understand your T-SQL?
  • Are you asking for something that’s already stored on disk?
  • Are there statistics about the data you’re asking for?
  • Is the data stored in a way that makes subsequent operations easier?
  • Now move through the plan’s operators, repeating those questions

The more YES’s you have, the better SQL Server’s estimates will be.

Now, where are your pain points at?

You’ve seen me pick pain points, and sketch out a possible recap slide for each one. Your homework for this Sunday, February 18th, is just the first one: your list of pain points.

If you commit to doing the process with me, I’ll commit to reviewing your work throughout. You can either turn it in via email to, or in the #PresentingOrSpeaking channel of

Read on in Week 3: The Abstract’s Technical Details

Read the Comments

The Road to Your First PASS Summit Session, Week 1: The Pains

Blog Posts

Ladies and gentlemen, I’m sorry, but you picked the wrong room for sleep

The PASS Summit is like the Super Bowl of the SQL Server community, only with less head injuries and more of a chance of you getting up onstage.

Every year, people just like you submit sessions, and believe it or not, some of them get accepted. You get free entry to the conference, a seriously cool entry on your resume, and an itchy polyester shirt that fits horribly, but you’re gonna wear it anyway because you’ll be so doggone proud of your achievement.

Let’s do this. I want to help – and seriously, everybody up on stage wants to help you get up there, too. Go read my 2010 post Rock Stars, Normal People, and You.

Yeah. All that is still true.

Here’s how the schedule works.

The Call for Speakers will be open February 28-March 21, so here’s what our timeline needs to look like – and yes, dear reader, I’m gonna be doing this in public this year too:

  • Feb 12-18: Pick 1-3 pains you’ve relieved. Look back at your project folders, meeting schedules, and really big email chains from the last year. Think about a few problems you had at work. They’re not gonna seem hard to you now, but that’s why you’re the perfect person to present them. On Sunday night, February 18th, you owe me the 1-3 pains you relieved.
  • Feb 19-25: Write a recap slide. For each pain, write a recap slide with 5-6 bullet points. These are the things you want the attendee to walk out of the session understanding.
  • Feb 26-March 4: Write the purely technical body of the abstract. It’s tempting to start with the title and the humorous theme, but set that aside for a second. Given what you want to teach for the recap slide, who’s the target audience? What do they already know? Think just about the bones of the session. The catchy theme will come later, but it’s gonna have good bones first.
  • March 5-11: Gather feedback. The single toughest part of the Summit abstract submission process is that you get no second chances. This means you absolutely have to get feedback from other people before you hit the submit button. Post your session as an abstract at GroupBy – you don’t actually have to present it if you don’t want to – just use it as a framework to let other people leave comments and questions. Then, ask your own questions about the abstract.
  • March 12-18: Write the title and then, then submit. By now, you’ve got a really good feel for the technical part of the abstract and you can start to add some humor or a catchy title. You’ll even have several good (and not-so-good) ideas for those from other community members and speakers. Do a final cleanup pass. You’ll submit it and skid in sideways just before the deadline.

It might sound counterintuitive, but there’s a lot you don’t have to think about before your presentation is actually accepted, like whether you’ll use handouts or slideswhether you need demos, or how you’re gonna rehearse. We’ll cover those later.

I’m doing it too. Here’s my first week’s homework.

I’m going to be doing this process too. I wanna set an example, and that means I need to turn in my homework one week early so you can see how I’m doing it.

Our homework for Feb 12-18 is to pick a few pains we’ve relieved. Looking back at 2017, here’s the stuff I’m most interested in sharing:

  1. How often should you take backups and run CHECKDB – I know, you probably think that sounds really dumb, but here’s the deal: I regularly interview “senior” DBA candidates who give really, really, spectacularly bad answers to that question.
  2. What to do when SQL Server is unusually slow – consistently a top request from training class students & clients. I have a checklist where I work through sp_WhoIsActive, sp_BlitzFirst, sp_BlitzCache, etc, showing how to interpret the results. I’ve been honing this session for a couple of years, but I need a new abstract for it.
  3. Analyzing parallelism – this sounds incredibly un-sexy, but clients & training students often get fuzzy looks when the concepts of CXPACKET, Cost Threshold for Parallelism, MAXDOP, CXCONSUMER, etc. It’s made more challenging by the fact that most monitoring & troubleshooting tools don’t show you which queries are currently hamstrung by this stuff, or give you good numbers for settings. I don’t have a good session to tell this story yet, either.
  4. Demystifying cardinality estimates – quite the range of levels here, right? When I’m working with folks on query tuning problems, they often point at a part of the query plan and go, “Why the hell is it estimating 1.30753816 rows?!?” In 75 minutes, I can’t explain how the whole query plan is built from scratch, but I bet I could give people a good roadmap that picks up where How to Think Like the Engine stops.

So there’s my first round of homework. Whew.

Your homework is due by next (not this) Sunday, February 18th. If you commit to doing the process with me, I’ll commit to reviewing your work throughout. You can either turn it in via email to, or in the #PresentingOrSpeaking channel of

Let’s get you an itchy, ill-fitting shirt.

Read on in Week 2: The Recap Slides

Read the Comments

Thoughts on Visiting the Porsche Factory

Blog Posts

Fantastic sculpture outside the Porsche factory in Stuttgart

Erika and I took a short vacation in Germany last week to check off a few items on her bucket list and my Epic Life Quest. I drove a Mercedes E-class on the Autobahn, visited the Porsche Museum, and toured their factory in Stuttgart.

The Porsche museum was lovely, and it really crystallized to me that I’m a Porsche guy. I’ve admired so many of their cars through my life. I wouldn’t really bother blogging about that though – it’s a museum, it’s got cars, they’re cool – but the factory tour was spectacular. Thing is, the factory tour doesn’t allow cell phones or photographs, so the photos in here are all from the museum.

There were less BIG robots than I expected.

When I was in middle school way back in the 1980s, I visited the Corvette factory in Bowling Green, Kentucky. Back then, I remember seeing a couple of big robots moving car parts around. The vast majority of the assembly line consisted of people, but there were definitely a couple of robots.

Walking into the Porsche factory in 2018, I expected that the vast majority of the production line would consist of robots. I was wrong. The humans-to-big-robots ratio still looked a whole lot like the 1980s Corvette factory. There were a few stations with large robots doing things like applying glue to windshields or doing compression tests on engines, but they were dwarfed by the number of human beings.

Me and the Pig

The tour guide said, “Everybody here is a highly trained mechanic, and it doesn’t make sense to have highly trained mechanics putting glue on windshields or screw in a dozen screws. The robots do the repetitive, monotonous stuff that don’t require trained humans.” And that made perfect sense.

But there were way more SMALL robots.

The engine assembly line looks simple – it’s a conveyor-belt-style line where engines continuously move along from one station to the next. It’s just a big long line of engines.

And at a glance, you’d probably think all the engines are the same, but they’re not. Our tour guide explained that every country’s emissions and regulations requirements mean that they’re all different, with ever-so-slightly different parts lists.

Each engine (and I don’t mean each engine design, I mean each physical engine that goes into each car) has its own dedicated parts rack. If you order a 911, you get your own parts rack. Computers build a list of the specific parts required for your 911’s engine, based on the options you chose and the country where you live. Your parts rack contains all the parts you need.

My new favorite Porsche, a spectacularly so-ugly-it’s-cute 909 hillclimb special

A robot – really, a self-driving cart – picks up the parts rack, takes it down to the assembly line, and that parts rack rides alongside the assembly line as your engine is delivered. The factory workers don’t have to think about which parts are required – they just put the right parts in the right places. If there are any parts left over on the rack at the end of assembly, something went wrong. This makes so much more sense than technicians grabbing parts out of a bin.

I fell in love with those robots that move parts racks around from one place to another. They’re not glamorous, they’re not smart, they just follow lines and magnets in the floor, shuffling parts around to make life easier for humans. As they move around, they even call elevators all by themselves!

The tour guide called them “my autonomous colleagues.” I loved that.

I couldn’t find videos of the Porsche robots online, but they’re very similar to Amazon’s Kiva robots, except much bigger:

That big-vs-small robots thing reminded me so much of what we data professionals are dealing with today. We’re not getting replaced by robots – we’re just getting new autonomous colleagues that help take care of the parts of the job we were never really all that good at.

911 #57, the earliest known remaining 911

There was an odd gender division.

On the factory floor, Erika nudged me and whispered, “There’s no women.” And she was right – we didn’t see a single female (other than, uh, her.)

I whispered back, “I bet when we get to the saddlery, it’s 100% women.” The saddlery is where Porsche crafts the leather for the seats, dashboard, air vents, etc.

And sure enough, it was.

But the instant we stepped out of the saddlery and back onto the factory floor where the gorgeous leather was applied to interior parts, boom, back to the sausage fest.

I was totally surprised by that, much like I was surprised that there’s still smoking areas indoors in the factory, and there’s beer dispensers because you can drink on the job. I’m still mentally absorbing some of that. (Not absorbing the beer, I mean absorbing what I saw.) I get that Porsche has a reputation for old-school hand-crafted quality, but there’s just a few things there I can’t quite wrap my head around yet.

I don’t want an old Porsche anymore.

The first Turbo, given to Louise Piëch for her 70th birthday

In the museum, I saw so many beautiful examples of past machines that stirred my soul.

But on the factory tour, watching the ruthless approach to quality, safety, and technology…you know what? I really want a piece of that.

Old cars are…old. They weren’t all that high quality when they went through the assembly line to begin with, even on a good day. Sure, they’re gorgeous, and they bring back great memories of posters on my wall, but those times have passed. Today’s machinery is so much more advanced, faster, quieter, and safer.

Well, I should qualify that: I don’t want an old 911 as a daily driver. Yes, I really used to want one – it’s not like I do all that much driving, so I thought I’d be completely fine with it. But not anymore – I want a new one just for the reliability and safety.

I still want an old 911 – but not until I have plenty of garage space and free time. I don’t wanna drive it on the highway during rush hour to a doctor’s appointment, for example. I would only wanna drive it on a canyon run on a weekend when I’ve got no traffic and nothin’ but time.

Read the Comments

I’m Proud of Our Guest Instructor Partnerships.

Blog Posts
No Comments

When I first started kicking around the idea of letting guest instructors run classes at, I did a brain dump of how I wanted to do business, and shared it with the guest instructors. It’s working out pretty well, so I’m sharing the more interesting parts here for those of you who like reading the behind-the-scenes type stuff.

In here, BOU means Brent Ozar Unlimited, and “you” means the instructor.

You exclusively own your material. The speaker owns the intellectual property (IP, aka slides/scripts/materials), and BOU doesn’t get any rights to it. Longer term, if we do the recorded version for student replay, then BOU would need the rights to let students play it from our site, but it would be restricted only to people who paid you (or who you gave access to, like your clients). BOU won’t have the rights to let someone see the recordings without your approval. You shouldn’t have to worry about me selling the class recordings as part of our online subscriptions.

You can use any training app or template. You can use PowerPoint, Keynote, whatever, in any slide deck template you choose. Use the tools you love, in the same look/feel that you use at user groups and clients. Don’t waste a moment on converting templates.

BOU doesn’t have veto rights over your material. Your material can link to your site, and anybody else’s (I’m not worried about promoting our competitors, and I link to other peoples’ stuff in our own training material.) There’s no requirements to link to resources on our site or host handouts on our site or anything like that.

We won’t record your classes unless you want to for your own use. If you do want to record with GoToWebinar so that you can give it out to clients (or sell it or whatever), that’s totally fine though. To me, those recordings are then your IP just like your slide decks and demos. They don’t cost BOU anything for you to have ‘em.

There’s no exclusivity requirement for the online classes. If you want to present the same material for somebody else (Pluralsight, YouTube, your own site, whatever) that’s fine. Yes, there’s a risk that having the material at Pluralsight (or elsewhere) reduces the possible revenue for an online class, but that’s just one of the tough things about being an instructor. You get to make those decisions based on what’s right for you.

Revenue sharing is 50/50. You get half of the top line revenue (sales, not profit), and BOU gets half. I want to be transparent about what BOU’s costs are, because from a financial perspective, they’re low:

Lights, camera, action

  • GoToWebinar is $500/mo (but you could do a 25-person class with the much cheaper GoToMeeting at like $50/mo)
  • Credit card processing with Stripe is about 3%
  • Sales tax filing internationally – accounting work, but it’s not really any additional work for us since we have to do it anyway for our other online stuff
  • A BOU team member being on the call – we’ll be online during the class, but with our audio & camera off. That way, if you need something or if we run into technical problems, we can assist. We’ll just be working on other stuff.
  • If you choose to do cloud VM labs for the students, we’ll also pay for that hosting cost out of our 50% (because we recognize that building quality labs is harder for you)

The big non-financial cost to BOU is marketing: building up the ~100K person email list, and then marketing the classes to our list, the site, social media, etc.

Sales taxes are our responsibility. The site calculates sales taxes based on the buyer’s location (which is surprisingly hard for international students), and those are all added above the sales price. I’ll figure out how to get you WooCommerce access – either to the admin panel, or just getting copied on the class emails as the sales come in. I just mention taxes to be totally clear that you get 50% of the class revenue, not the sales tax part. 😀

We (BOU) have the right to do public discounting. We want to put butts in seats, so we’ll do things like a limited time launch discount, plus referral coupons through various marketing outlets (blogs, email newsletters, refer a friend, etc.) We won’t discount the class below 50%.

You have the right to do private coupons. If you want to give access to friends, customers, prospects, etc, you’ll have the ability to set up coupons that discount your class all the way down to zero. You just can’t share those publicly. (We want to be able to manage the discount process to maximize students & revenue.) It’s completely okay if you put people in the class for free – it doesn’t cost us anything when you do that, and we don’t see it as lost revenue.

When I wrote that stuff out and shared it with the presenters, I was basically thinking, “If I was 2010 Brent, who was doing some presentations for online training companies, what would Brent have really needed, but not known to ask for? How could I help 2010 Brent build up his training inventory and his online presence in a way that everybody wins?”

That’s what I came up with, and I’m really happy how it’s worked out.

Read the Comments

Ernie Ozar, 2003-2018

Blog Posts

Our rescued mini Schnauzer mix, Ernie, passed away last night.

She was diagnosed with cancer last year, but she was blessed with a great quality of life right up til the end.


On car trips, she brought her big bed with her

Sunning herself in the afternoons on the couch

She was so patient, letting us put her in all kinds of photo poses

Wonderful traveler. Just liked to sit and people watch.

In what we called her condo – her under-seat airplane bag, en route to the airport

She was a surprisingly good driver

We got to watch her gray with age

Waiting for Santa

Coming back from the hair salon, evidently en route to the prairie

No judging

“Please speak to my agent”

Dressed up for Halloween back before she went gray

She’s now Urnie. (We’ve been laughing about that joke for quite some time now. We are terrible people.)

Read the Comments

Epic Life Quest: Level 10 Achieved.

Blog Posts
1 Comment

Life’s little moments of success can pass us by so easily. If we don’t track the things we’re proud of, we lose track of how far we’ve come. Steve Kamb’s Epic Quest of Awesome inspired me to build my own Epic Life Quest. I keep track of achievements, and after five significant ones, I level up.

In the last level, I focused a lot on passive income: building training that I could sell, and then getting that educational material out to as many people as possible. That paid off in this level because the passive income gave me more time to focus on other areas of the business – and some fun.

Here’s what I accomplished in this level:

Jeremy Clarkson’s old digs on the Isle of Man

  • Visit Poland. When I saw @AaronBertrand‘s photographs of his Poland trip, I decided I had to go. SQLDay 2017 in Wroclaw was great! Completed May 2017.
  • Half-point: Ride in the upper deck of a 747. I don’t count this as a full experience point, but I’ve always wanted to do it, and I wanted to mark the achievement here so I could remember it when I looked back. I usually fly United, and they don’t use 747s, so I had to take a Lufthansa FRA-MCO flight to do it. Completed May 2017.
  • Visit the Isle of Man. Famous stateside for the bonkers TT motorcycle race which produces terrifying crashes and kills riders every year, this beautiful island was way, way, way more beautiful than I’d expected. I rode most of the race course (in a taxi, not a bike), and I’m totally going back. If, heaven forbid, Erika passes away before I do, I’m moving here. It had that much of an effect on me. Completed September 2017.
  • Set the PASS Summit pre-con attendance record. The Microsoft SQL Server industry holds a big annual conference in Seattle, and I’ve helped teach pre-con classes there before. My Expert Performance Tuning pre-con with Erik Darling broke the sales record more than a month before the event, and PASS couldn’t fit any more seats in. Completed October 2017.
  • Half-point: Get code into a Microsoft product. When Microsoft announced SQL Operations Studio, their new open-source cross-platform SSMS-type tool, the execution plans looked awfully familiar. Turns out one of the open source projects they’re using is HTML-Query-Plan, an open source project that Brent Ozar Unlimited sponsors – because we use it for PasteThePlan! So awesome – because that means we might actually be able to get the PasteThePlan icons in there as a theme, heh heh heh…
  • So close, yet so far

    Sell $500K of training in one month. Our Black Friday sale has done really well over time, and this year I want to see if I can cross that big round number. Update: so close, yet so far: our Black Friday sales hit $439K. That’s more than double our prior record, but not the big round number goal I was aiming for, so no Epic Life Quest points here.

  • Sell out 2 pre-cons at the same conference. When our SQLBits 2018 pre-con sold out, Erik suggested something I’d never heard of before in our industry: why not run the exact same pre-con again a second day? It’s kinda like how musicians will add a second date when that one sells out. The Bits crew agreed, and we sold that one out too! Completed January 2018.

My achievements will slow down a little in Q1 due to a vacation trip to Germany, SQLBits in London, and several online training classes. I’ll make some more progress in Q2, but then our Chicago lease is up at the end of May, and we’re looking (again) at moving to San Diego. These winter storms make that decision a whole lot easier.

Read the Comments