Google+
LinkedIn
Instagram
GitHub

A Day in the Life of Brent Ozar: July 17, 2018 #SQLCareer

Blog Posts
8 Comments

Steve Jones asked data professionals to cover four days in our lives, so here goes the first post: what I did on Tuesday, July 17th, 2018. Nothing special about this day, just the day that Steve prodded me to take part, heh. My days are radically different, so I’m glad he said to do this four times – otherwise I’d feel guilty about just posting this one without more explanation. (I’ll do this again for July 18th because it’ll look totally different, but then hold off for a few days before posting another.)

4:07AM – I wake up without an alarm and do a round of emails before I hop in the shower. (I looked at the first email-sent time to figure out when this happened, hahaha.) I answer a few client and personal emails – things that are easy to tackle from the phone. After a shower, I walk to my nearest coffee shop, grab a big cup, and come back to my home office to work.

4:45-6:45 – Learning. Read the blogs from overnight – in addition to the 362 SQL Server blogs I subscribe to (OPML – Feedly), I also read HackerNews and a lot of non-technical stuff. I tend to bookmark the very best (or most interesting) stuff on my Pinboard feed, and some of those end up in our Monday newsletters. Microsoft published a couple of cumulative updates, so I post them on SQLServerUpdates.com.

(As I mentioned in my interview with Kenneth Fisher, I try to reserve the pre-7AM time for learning. Today it was reading, but sometimes it’s opening up SSMS and trying to understand something that has been stumping me for a while, or learning how PostgreSQL execution plans work, or whatever.)

6:45-7:00 – Breakfast. A fresh pot of coffee and Stonyfield yogurt. Michael Weston, look out.

7:00-9:00 – T-SQL coding. I need to do design work on SQL ConstantCare®’s new index functionality, so to get in the frame of mind, I design & code an sp_BlitzIndex change I’ve been wanting to make for a while. In building the script for Erik to test the changes, I also update my Mastering Index Tuning class demos about the problems with heaps.

So are the hours of my day

9:00-10:00 – Communication time. I answer a few mentoring emails from SQL ConstantCare® clients. I break some bad news to an upcoming client: they hired us for performance tuning, but while analyzing their data for that engagement, Erik found out they have database corruption across multiple AG replicas. In more enjoyable news, I answer a DBA.se question that happens to pop up in our company Slack room. (We get notifications for new SQL Server questions, so if they look fun, we jump in. That one involved SQL Server on a forklift, so yes, I was intrigued.)

10:00-10:30 – Break. Walk around, make coffee, read blogs. I see my first Minerva Blue Porsche 911 and  then wipe the drool off my keyboard and monitor. The audio of it driving around is wonderful.

10:30-12:00 – SQL ConstantCare® design. We’ve got a new version of ConstantCare.exe that collects index and query metrics, then tells you what index and query changes to make in order to get better performance. Started designing the business logic for modifying SQL Server’s missing index recommendations and building better ones. While designing it, I review the past sp_BlitzIndex data for several clients, thinking about how I would have built rules to handle their index recommendations. I store my thoughts in a Github issue.

12:00-12:30 – Client call. I’m doing a 3-day SQL Critical Care® with a company next week, but looking at their DMV data, the cause of their really nasty RESOURCE_SEMAPHORE issue was immediately obvious. We talked through it so they could start researching the source of those queries before our engagement.

12:30-1:30 – Lunch. Erika & I headed out to Falafel & Grill. When you work at home, it’s nice to get out and enjoy some fresh air.

1:30-2:00 – Order taking. A few sales prospects emailed in about arranging future work, so I coordinated dates & contracts. I hesitate calling this sales because I don’t do a lot of salesing, just responding and going, “Yep, that’s a good fit, here’s a contract with our next available dates.” The vast majority of our work involves urgent performance emergencies, so we’re usually only booked about 2-3 weeks in advance – really short for a consulting firm. As a result, I’m totally at peace with only having 2-3 weeks of work on the books at any given time. In the past, our August drop-offs scared the hell out of me, but now at least I know to expect it somewhere in here. That’s why I’m doing the foundational design work for SQL ConstantCare®’s next set of recommendation rules now – so if Erik & Tara aren’t billable for a couple/few weeks in August, they can still be productive working on the rule design & execution.

2:00-3:15 – Design continues. Thinking about how I want to deliver index recommendations, I decide that we need to start including a text file attachment in the SQL ConstantCare® emails. I spend more time in sp_BlitzIndex and Github.

3:15-4:00 – T-SQL R&D teamwork. Erik’s working on a new training class module about parallelism, and he’s got a query that exhibits great demo-friendly behavior. I run a few tests with it on the Stack Overflow database and use sp_BlitzFirst to check wait stats, and we have a fun discussion about CXCONSUMER behavior, and how it might not be that harmless after all. We’re seeing some really odd, unexpected stuff on 2017, and I would love to dig deeper by trying earlier versions. (Later, looking at our Slack channel, I can see that he kept going, and I’m looking forward to seeing what he found.)

At the same time, Tara’s examining the data for her client tomorrow, and she spots a T-SQL anti-pattern in their queries. We all talk about a possible fix in Slack, and she starts working on a demo for their findings.

(At this point, you’ll notice that we’ve done prep work for clients ahead of their engagements – that’s because Richie wrote an app for us that sends us the results of diagnostic queries like sp_Blitz, sp_BlitzIndex, sp_BlitzCache, query plans, etc. That way, when we meet face-to-face with the clients, we’re already well-equipped to discuss the problems they’re facing. Steve asked us to write these blog posts so you could see what tools & techniques we use in our day jobs, and while you can’t get that app, you can get the exact same scripts we use every single day.)

Normally I would end my day here – I try to quit work around 4PM – but today is unusual in that it keeps going:

4:00-5:45 – Drive out to the burbs. I live in downtown Chicago, and traffic going out to the burbs is legendarily bad. It takes me 95 minutes to go 20 miles. There are only 2 reasons I head away from downtown: to go to the airport, or to speak at the…

5:30-8:15 – Chicago Suburban SQL Server user group. I was the first speaker to open the new group, and I present there one last time before moving to San Diego in a couple of weeks. Dinner was pizza at the user group.

8:15-8:45 – Drive home. Atypically long day for me – if it wasn’t for the user group, I’d have been done at 4PM. See you tomorrow!

Read the Comments

WordPress 4.9.6 GDPR Compliance Demo Videos

Blog Posts
No Comments

In Tuesday’s upcoming WordPress 4.9.6, there are a couple of new features to help with GDPR compliance.

First, you can create a privacy policy page:

Second, you can export a user’s data and erase it:

The current schedule is for 4.9.6 to go out this Tuesday, May 15th. If you’d like to take part in the discussion about these features, here are a few useful links:

Read the Comments
Brent Ozar Unlimited, early 2016 at Cliff Lede in Napa

How the Company-Startup Thing Worked Out For Me, Year 6

Blog Posts
14 Comments

It’s time for my annual update on the wild ride. A brief recap of what’s happened so far:

When last we met, finishing up year five, I was excited because we’d finally assembled a profitable product fulfilled by a fun, knowledgable team, sold by a super-savvy salesperson. It was time to hit the gas and really start scaling the consulting business.

Brent Ozar Unlimited, early 2016 at Cliff Lede in Napa

Brent Ozar Unlimited, early 2016 at Cliff Lede in Napa

We hit the gas –
and nothing happened.

It seems obvious now in retrospect, but emergency rooms can’t drum up more business by themselves.

Once you scale up large enough to handle the incoming emergencies, you’re kinda done. Even a great salesperson couldn’t go out and find new emergencies for us to handle, at least not without violating some kind of laws. We realized that our widespread reputation & marketing efforts meant that people already called us when they had expensive emergencies – new leads weren’t the problem.

Oh, sure, we could have lowered our billable rates – we were effectively $300/hour – and started to handle non-emergencies. Our clients would have loved to be able to pay, say, $150/hour and have us tackle larger ongoing projects – just as they’d love to have a trauma surgeon take care of their sore throat.

But we weren’t cheap amateurs.

We had a team of trauma surgeons – top-notch people who got 6 weeks paid vacation per year, 10 federal holidays, health insurance, training, home office funds, time to tackle fun projects, and a swank annual retreat. If we wanted to lower our prices, we would need to lower our benefits, lower our staffing quality, and/or make our staff work longer hours on crappy projects. Those just weren’t interesting options to me. I didn’t wanna build that kind of company. (Nothing against those who do – gotta pay the bills – but I wanted to continue to build the best company to work for.)

Without enough business coming in to keep all the trauma surgeons busy, the consulting employee side of the business started losing about $5k per week. When we hit our normal summer slump, it got worse, and I didn’t see any signs of being able to turn that around. Jessica (our sales pro) and I had tried everything we could think of to bring in more emergency room business, and it just didn’t work.

If I continued to try to make that dream happen, I ran the risk of running the business completely out of money.

I couldn’t care less about me personally running out of money – if the business doesn’t work, I can just throw in the towel, go back to being a full time DBA, and I’ll be fine. But I absolutely, positively couldn’t run the business out of money and run the risk of the employees, Jeremiah, and Kendra not getting paid. I’ve worked for companies that skipped paychecks, and I’ve always sworn I would never let that happen to my own employees.

So in July, it was time to hit the brakes.

I had to lay off 3 of my best friends to save the rest. Letting go of Angie, Doug, and Jessica was tough because they were perfect employees. I couldn’t have asked for better teammates and friends. It’s really hard to tell people, “This has nothing to do with you, and is solely due to my inability to make this new business model work.”

I told the team members, then I posted a blog about what’d happened. Being transparent about it made the whole thing much easier because we got a lot of support from the community. My #1 mission was helping my friends find great jobs fast, and of course they did.

I wanted to make sure the remaining team members knew exactly where we stood as a company, so in team meetings, I shared the P&L statements with ’em. I didn’t want them losing sleep over how the company was doing. We’d taken corrective action early enough that we were still okay financially.

Erik, Richie, and Tara made it clear that they’d do whatever it took to make sure the company stayed on positive ground. They were a huge help getting through some tough times.

I re-calculated my personal & business goals.

The 2016 business was like a stool with 4 legs – 3 of which were losing money:

  • Training – which had always been the strongest leg of the stool, a profitable business that funded everything else (but that meant I was teaching classes without getting paid for it)
  • Consulting – which we’d been trying to grow, but were losing money in the process.
  • Online Services – we hired Richie to build stuff, and I knew that stuff would take a long term investment and vision. This leg of the stool wouldn’t make money until at least 2018-2019, and I was fine with that.
  • Community – no incoming revenue here, just giving back in the form of webcasts, blogging, scripts, and podcasts, with the hope that folks will remember us when they need SQL Server help. This leg of the stool would never be profitable, but spending money & time here was just something that mattered a lot to me.

I needed to reprioritize to get back to 2 profitable legs of the stool (training AND consulting) – still not stable by any means, but a little more doable than 1 profitable leg. I didn’t want to close the consulting altogether – it was perfectly profitable with just 2 trauma surgeons – and I definitely didn’t want to close the services leg. We had enough incoming work to keep Erik & Tara comfortably busy at good billable rates.

(Yes, that means 2 stable legs out of 4: community & online services would still lose money for the near future. There would still be one hell of a lot of risk. That’s life when you start a company – the more reward you want, the more risks you have to be comfortable taking. Either take less risks, or get more comfortable managing risk.)

I did some soul-searching to figure out what I needed to let go of, and what I needed to embrace.

One of my last classes in 2017, San Diego

Training changes:

  • I tried teaching live 3-4-day classes online – I love teaching, but in-person classes are expensive and the travel sucks. I ran experiments to see if I could run the same classes online, and they worked. They worked so well that in Year 7, I gave up in-person classes altogether to spend more time with my wife Erika, and my dog Ernie. (When Ernie was later diagnosed with cancer and given about six months to live, I was so grateful that I’d cleared out my schedule.)
  • I changed our online training to a subscription model – aiming to further tune my passive income. (This didn’t work as well as I’d like, but I spent less time running experiments on that as the live online training did so well, and I focused on that instead.)

Community changes:

  • I open sourced sp_Blitz and friends – I’ve always admired the open source community, and figured it was time to start an MIT-licensed open source project in the SQL Server space.
  • I started GroupBy.org – I wanted to figure out how I could bring an open source mindset to the database training community. Open source works because ideas and execution succeed on their own merits, with less hidden politics. I figured I could make that work in online events, too.
  • I turned in my Microsoft MVP award – there are a very limited number of spots, and a lot of people who want to enjoy the experience. I’d been blessed to have it for several years, had a lot of fun, but I felt that someone else would probably get more value out of it than I was getting. I slipped out the side door quietly.

(Briefly) My Audi RS6

Personal changes:

  • We downsized, moving from a gorgeous downtown penthouse into a much smaller mid-rise, and cut some planned vacations.
  • I sold my beloved Audi RS6 after only a short ownership. That taught me a lot, though: I couldn’t justify a $300/mo parking spot for a car I drove so rarely that the battery was dead whenever I went to go have some fun. I resolved not to buy another fun car until I either retired, or had to start driving back into an office for work again. I really, really miss that car, but I still wouldn’t drive it more than once every couple of months.

Overall, the changes worked. We were smaller, but we were profitable and I had way less stress again.

The business turned around in fall 2016
and I could invest again.

We signed some really fun clients – the public highlight being a series of projects with Google. I was really proud of the work we did, and we kept increasing the quality of our consulting and our open source scripts.

Black Friday 2016

Black Friday 2016

In November 2016, during our Black Friday sales, I made more in one month than I’d ever made in a year as a DBA. That made me feel a lot better, although I still wasn’t able to take all of that money off the table – it kept getting plowed back into building a future leg of the business, services.

Time for a quick history lesson of my scripts/tools/services:

Version 1, late 2000s: My Blitz script was a big long script (think Glenn Berry’s diagnostic scripts) that told you all kinds of things about your SQL Server. The idea was that you’d highlight each query, run it, and then interpret the results.

One of the queries was a database mail test, and the comment said, “Make sure to change the below email address to be yours so you know if email is working.”

You can guess what happened: I got test emails every day.

I could tell by the server names & metadata that database professionals all over the world at big companies and small were all just banging F5 on the entire Blitz script, and hoping that it would somehow tell them what was wrong with their servers. They just wanted a simple answer.

Version 2, 2011: With that lesson learned, I built sp_Blitz: a stored procedure that you could just run, and it would give you a prioritized list of what was wrong with your server. That became massively popular.

Version 3, 2013: Jeremiah built a Windows app that would run sp_Blitz and give you a PDF report. We ended up abandoning it because the support was painful, and we couldn’t get it into the Windows Store easily. But something strange happened here too: we kept getting requests for it, and requests for updates. At least once a month, I got emails from people asking when we would update it. That never left my mind.

I had a vision of something a lot bigger that I wanted to build, but first, I wanted a proof of concept of the architecture I was dying to use.

First, Richie built PasteThePlan.

In Year 6, Richie built & launched PasteThePlan, a page where users could copy/paste in execution plans, get a shareable link, and post those plans on Q&A sites. PasteThePlan represented the first publicly visible fruit of Richie’s labor.

PasteThePlan let us dip our toes into serverless application design. I wanted to build something in serverless that didn’t represent a mission-critical app: if it went down, or if somebody lost some of their data, life would go on. We used AWS Lambda because it was the most complete product when we started work in mid-2016.

By the end of 2016, I was a huge, huge fan of serverless. @Cloud_Opinion sometimes writes parody, but their Feb 2017 article on the upcoming SaaSocalypse rang really true for me. I believed that with the right product, the right architect (and Richie definitely was), and easy scalability in the form of serverless design, I could start a really meaningful application with a very low capital cost of entry.

Next, he started work on SQL ConstantCare®.

There’s a lot of people out there that don’t really want a monitoring tool. Monitoring tools have dashboards that devolve into a constant @Swear_Trek alarm, and continuously send out non-actionable alert emails. PAGE LIFE EXPECTANCY IS LOW! DISK QUEUE LENGTH IS HIGH!

A lot – not all, but a lot – of admins don’t want dials and charts. They just want to know what to do.

So I wanted to build something that:

  • Polled your SQL Servers and gathered data you were comfortable sharing
  • Sent that data up to our servers in the cloud
  • Let us run analytics to generate recommendations – no artificial intelligence, just plain ol’ real intelligence
  • Later, sent you just one email with a prioritized list of actions to take (and if you don’t need to do anything urgent, tell you that, and let you get on with your job)

Richie busted his hump on that for the second half of Year 6. It didn’t end up launching for quite a while, but you can hop over to my SQL ConstantCare® posts on BrentOzar.com to see how that launch is going.

Alaska with Dad, Aug 2016

Year 6 was a big turning point for me personally.

I like writing these posts with a good year of distance between me and what happened. It helps me look back with a lot more perspective and think about what were the most important moments.

The biggest moment by far was coming to the realization that I personally didn’t have the talent to build the 10-15-employee consulting division that I wanted to build.

At the moment it hit me, I put at the top of my to-do list, “I am overcommitted and under-equipped.” It’s still there right now:

What I see when I try to add a new task for myself

That’s proven to be the most valuable realization of year 6, if not my entire adult life. I still want to accomplish a bajillion things, but I’m no Elon Musk, nor do I have that level of work ethic. I love taking several vacations a year with my friends and family. I have to balance the tasks I add against the time I have. Focus means saying no.

<sigh>

I don’t like saying no. I like saying sure, I can do that, why yes, I’d love to tackle that problem, indeed, yes, that looks like a possible mission.

It’s a lesson I keep learning, and it’s timed perfectly with the emptying-out of my blog post queue here. I started this site to say things that didn’t feel like a good fit at the company blog, and for the last several years, I’ve published a post here every week.

This week marks the end of that streak.

I still have a ton of things I love writing about, but I’m juggling my focus a little. On my last personal career-planning retreat, I realized that while I love doing this, I need to take some of this time and allocate it to something else. I’ll still do my annual updates in this series, and I’ll keep my Epic Life Quest up to date. I’m just going to try to discipline myself into not writing here for the rest of 2018, and rebalance that time elsewhere.

Read the Comments

Engagement Startup Costs: You Don’t Hire Consultants to Load Dishes

Blog Posts
8 Comments

“Whaddya mean you won’t do ___?”

It’s a question I get every now and then from a prospective client. Most folks see our marketing, see that our consulting services page only has one thing on it, and understand that we’re very specialized.

But every now and then, someone contacts us after seeing our pages in their Google results over and over again, and they figure we’re up for anything. They say something along the lines of, “I just need you to look at this one query and fix it.”

And sometimes – not often, but usually when the prospect has been struggling to find someone willing to take the gig – the conversation becomes a little insulting, along the lines of:

“Whaddya mean you won’t fix one query for me? I thought you guys were experts. Are you telling me you don’t know how to do something that basic?”

Here’s the deal.

Our dishwasher

I load my own dishwasher. Erika does the cooking (when we’re not at a restaurant), and I load the dishwasher. I somehow find it relaxing – I’d rather load the dishwasher right now than walk past the sink and see dirty dishes in it. I like the task. It’s kinda zen-like, just me and the dishes.

But no, you can’t pay me to load yours. You can’t call me over to your house to load the dishwasher. Even if you happened to live near me, I’m not putting on shoes, a jacket, and dealing with the security of getting into your house – all just for a 5-minute task.

The startup costs of that engagement are just too high.

Now, if I happened to already be at your house – like if we were hanging out after you threw an excellent dinner party – then sure, you’d find me loading the dishwasher. Payment would be simply out of the question – it’d just be something you’d find me doing absentmindedly.

If you have what you think is a small task, then post it.

If all you need is a very small task that’s self-contained and well-defined, go to:

I help out at all three sites too – because there, the startup costs are extremely low. I can jump in there between calls, whenever I see something that looks interesting, and help out in seconds. When the questioner has put the right work in to define their question, I find it peaceful, zen-like, transferring knowledge from one person to another like moving dishes from the sink to the dishwasher.

But often, in the process of trying to write a clear, simple, well-defined question, the asker discovers that it’s not as simple as they thought. They start saying things like, “Well, to explain it, I need to talk about a few other things, bring in context, and get you security access, and must be kept private,” then that’s not really a simple question, is it?

That’s where consulting engagements come in. Those requirements have a startup cost, and it’s not 15 minutes and $50.

Read the Comments

Databases Eight Years from Today, 2018 Edition #TSQL2sday

Blog Posts
11 Comments

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.

<= 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.)

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:

Read the Comments

The Road to PASS, Week 5: Submitting Your Abstract

Blog Posts
No Comments

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 GroupBy.org, 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 brento@brentozar.com, or in the #PresentingOrSpeaking channel of SQLslack.com.

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 brento@brentozar.com, or in the #PresentingOrSpeaking channel of SQLslack.com.

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 brento@brentozar.com, or in the #PresentingOrSpeaking channel of SQLslack.com.

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
3 Comments

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 slides, whether 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 brento@brentozar.com, or in the #PresentingOrSpeaking channel of SQLslack.com.

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

Read on in Week 2: The Recap Slides

Read the Comments
Menu