Eagle-eyed readers may have noticed a subtle change to our site, swag, and PowerPoint templates over the last few months. Here’s the evolution as seen in our company coffee mugs:
Far left, the one with the heart, is the current one, but the transition is a funny story.
Our marketing firm, Pixelspoke, first designed the logo on the far right when they came up with the Brent Ozar Unlimited™ brand. Their market research said that our customers believed we were “loving commando nurses” – people who parachuted into dangerous territory, guns blazing, and saved people from danger while truly caring about their needs. (Those three words still make me giggle.) Anyway, we loved the logo, and we sent it off to our lawyers for trademarking.
And with a red cross in the middle of the logo, you can guess how that went.
We picked the only logo that is protected by the Geneva Convention. Whoops.
For round two, the designers came up with the middle logo – a white cross in a red circle. This got around the Geneva Convention issues, but between the Swiss flag and Swiss Army knives, our lawyers figured this wasn’t a very good idea either.
We were deeply in love with the pocket, so we went back to Pixelspoke’s talented folks and came up with round 3 – the red heart in the pocket. It manages to convey both medical stuff and our caring nature. We’d originally had another logo in the running with a heart in it, but we had really polarizing opinions about it. The heart does seem a little cheesy, so people either love it or hate it. After we thought about it for a while, we decided we kinda liked the polarizing aspect – after all, we’re kinda polarizing too.
It’ll take us forever to get through all of the little spots around the web where we’ve got the old logo, so if you spot one, let us know. It’s like a treasure hunt, except…the opposite.
If you want one of our mugs, you have two options – either become an employee, or buy one for $17.95 on Zazzle. We’ve got the sales set to the cheapest price possible, and we’re certainly not going into the coffee mug business. I just mention that here because people are going to ask how to get ‘em, and no, we’re not giving them away for free. (Except to employees!) Rather than giving away free coffee mugs, we give away free SQL Server training. Enjoy!
When we started building our classes for next year, we started by following our own advice. We wrote detailed attendee biographies defining exactly who should attend, what pains they were facing, and how they would use the training to solve the pains when they got back to the office.
We’re Guilty of Profiling
We got really detailed with the attendee bios – how many years they’d been working with SQL Server, what topics they were comfortable with, what topics they hadn’t even seen yet, what kinds of user group sessions they’ve attended, and more. Then we boiled down the attendee profile to a single sentence for each class:
How to Be a Senior DBA Class – You’re a DBA who is ready to advance to the next level in your career but aren’t sure how to fully master your environment and drive the right architectural changes.
SQL Server Performance Troubleshooting Class – You’re a developer who needs to speed up a database server that you don’t fully understand.
I love this kind of profiling. For example, with the DBA class, we want the attendee to read the sentence and go, “Wow, that’s me – I’m a DBA and I don’t feel like I’m driving the architecture changes we need. In fact, I think the entire company is the one driving me, dictating what we’re doing, and I don’t agree with the direction we’re taking. How can I turn things around so that I’m the master of our database strategy?” So many DBAs feel like they’re constantly behind the 8-ball, being reactive instead of proactive, and they’re not happy about it.
With the performance troubleshooting class, we want the reader to say, “Whoa, that’s me – if I don’t get this app running faster, nobody else is going to do it for me, and I don’t even know where to start. I’ve tried adding indexes, I’ve tried adding NOLOCK, and I know how to run Profiler traces, but it doesn’t feel like we’re making real, significant progress.” Most of the developers I work with aren’t suffering from a lack of information – they’ve got an overwhelming flood of information, and they’re not sure which parts to believe and which parts to prioritize.
Then We Thought About Our Clients
We went back through our client findings from our SQL Critical Care™ sessions, and we categorized them into three piles:
- Shops with a loner DBA totally qualified to become a senior DBA, but just didn’t have any in-house mentoring
- Shops with developers who were facing performance issues, but couldn’t justify a full time DBA (and many of these happened to be software vendors or software-as-a-service companies)
- Shops where neither applied
The last day of our SQL Critical Care™ sessions is a set of customized training modules that cover how to get fast relief for their SQL Server’s pain points. We looked at the most common pain points for each of these categories, and then built the module list for our public training:
How to Be a Senior DBA Modules
Here’s some of the modules we picked, and why:
Architecture Design for RPO/RTO – most solo-DBA shops don’t have enough variety to really get exposed to all of the different HA/DR options. We talk about the real-world pros and cons of each method so you can get a sanity check about whether you should build a cluster, use log shipping, or jump into AlwaysOn AGs.
The Secret Meaning of Performance Counters – you don’t have enough time to gather every metric and read the tea leaves to figure out what it means. We feel your pain; we have to rapidly performance tune slow SQL Servers too, and we’ll share our favorite counters and shortcuts.
What Every Senior DBA Must Know About Failover Clustering – this is the single most common high availability feature that we end up recommending to clients. It had a horrendous reputation years ago due to complexity and shakiness, but it’s better these days – as long as you follow some important rules.
Pushing Boundaries: Stories from the Field – You can learn real-world solutions from some of the crazy outlier clients we’ve got. We’re talking thousands of databases per server, tens of terabytes in a single data file, and over 100k batch requests per second, and yet there’s tips that can help you with your “normal” servers.
SQL Server Performance Troubleshooting Modules
How to Think Like the Engine – yes, you can buy a video version of this class for $29, but we still use a condensed 45-minute version of it to kick off our troubleshooting class because it’s so important to get you into the frame of mind of SQL Server’s internals. We’re going to be talking about indexes, wait stats, sargability, and other related concepts throughout the following 3 days, so we’ve gotta get you started off right.
Why NOLOCK Isn’t Enough – you’ve already peppered all your queries with NOLOCK, but you’re still facing performance problems. Picking the right isolation level can make all the difference, but you need to know how to plan for it and test it.
X-Ray Glasses for SQL Server Indexes – did you pick the right clustering key? If you didn’t, how is it impacting performance? There’s a lot of advice out there about whether you should swap out GUIDs as your clustering key, and we’ll show you how to get the right answer for your app.
Developer’s Guide to Dangerous Queries – when you’re looking at T-SQL and a query plan, how can you tell if it’s harmless or horrific? It’s not enough to just look at estimated costs, either. You’ll learn how to spot the queries that are really giving the SQL Server engine fits, and how to reshape them.
Data-Driven Index Changes – after you’ve changed indexes, how can you numerically prove that things have gotten better? How do you know when to stop? We’ll give you tools to document it quickly.
The Result: Our 2014 Class Lineup
We spent hours planning out the modules, setting how much time we needed per module, putting them together around break schedules, and making sure they flowed together well. I’m really surprised by how much work this takes to do it right!
We went live with our training class pages, and then recently updated ‘em to make it more clear how the scheduling works. Go check it out now and let us know what you think of the updated pages.
SQL Server learning materials seem to live at two extremes. Blog posts are short and to the point, but they don’t cover material in depth. Books are long and detailed, but to quote a famous philosopher, ain’t nobody got time for that.
Enter two resources that have been out for quite a while. They aim to cover subjects from start to finish, but in a way that you can digest in an hour.
Microsoft Books Online (Yes, Books Online!)
Microsoft Books Online earned a terrible reputation for being the last place you’d ever want to look for help. Look up the sys.databases view, for example, and you get gems like this:
No context, no hyperlinks to more details for a particular setting. These aren’t even new settings – they’ve been out for years. Since at least SQL 2000, there’s been a Books Online page for ANSI NULLS that they could have linked to.
However, when you weren’t looking, Books Online went to finishing school. It’s now chock full of great explanations of concepts. When you’re looking to implement a feature, check out these explanations:
Books Online still tends to focus on features rather than tasks. For example, if you need to find out why your server is slow, heaven help you if your only resource is Books Online.
SQL Server Central Stairways
SSC’s Stairways series covers topics start to finish with 5-15 tutorials from one or two authors. I love the consistency on these – you can settle in with one author and really dig into a topic with a logical flow. Think of it as an interactive book chapter, often with lots of demos you can run to illustrate concepts.
They’ve added stairways for T-SQL, indexes, transaction logs, PowerShell, replication, SSRS, and other good foundational topics. The existing stairways keep getting better as the authors add more posts.
Because why not?
Starting at midnight Eastern time (5AM GMT) on Friday, November 29th, we’ll post a new sale every four hours from our @BrentOzarULTD Twitter account. To give you an idea of what kinds of deals to expect, here’s the first one:
At midnight, all of our in-person training courses will have exactly two tickets available for just $495. First come, first serve.
No trampling, people. Stay safe out there. Good luck!
Midnight Deal Update: Congratulations to Anne Hills, David Yard, Jeff Willett, Kiran Makkapati, Mark Parfrey, Oleg Bulay, Sam Bryant, and Sam Sparks for getting in on $495 training class tickets. Several of ‘em even bought two so that they could attend back-to-back classes in the same city – nice move, because those tickets went quick!
4AM Deal Update: Congratulations to Brian Han, Brian Moore, John Crawshaw, Manoj Badamikar, and Tae Jin Kim. We posted a 50% off coupon good for any online video course, but only for the first 5 takers, and they were the quickest on the draw.
8AM Deal Update: Coupon code BlackFriday200off was good for $200 off our in-person training classes until noon Eastern. Congrats to the buyers!
Noon Deal Update: Coupon code BlackFridayFree29 got Andre Ranieri, Brian Han, Brian Hendrickson, Eric Klovning, Javier Castrillon, Lily Chiu, Manoj Badamikar, Mark Wilkinson, and Unai Garcia Herguedas a free $29 credit in our training videos.
4PM Deal Update: For just one hour, if you register for the 2-day How to Be a Senior DBA class at regular price ($1,395), you get our 3-day SQL Server Performance Troubleshooting class in that same city for free. That means for $1,395, you get a full week of training class goodness! Register for the city you want, and after we’ve received your payment confirmation, we’ll send you registration information to sign up for the 3-day class for free. This is a manual process that won’t show anything special during your 2-day class registration process. You must register between 4PM and 5PM Eastern (GMT -5) today to be eligible for this deal, and travel/hotel/expenses are still your responsibility. Read about the classes, or register for the 2-day class in San Diego (Feb), Chicago (May), or Philly (Sept).
5PM Final Deal Update: We got such a good response to our Black Friday deals that we’re launching the last one now and leaving it up for the rest of the day. Until midnight Eastern time today, all our in-person training classes are half off. Enjoy!
Thanks for spending Black Friday with us. See you in San Diego, Chicago, and Philadelphia. Enjoy the holiday weekend, and thanks for having fun with us on Black Friday.
Our Hierarchy of Database Needs training email plan has been a lot of fun. Thousands of SQL Server professionals have signed up to get an email in their in-box every Wednesday for 6 months. It’s like a part-time college course – the one you should have been given when you first got shuffled into this DBA job thingy.
Now, we’ve taken some of the content and turned it into a free 38-page PDF ebook.
It starts at the base of Ozar’s Hierarchy of Database Needs, covering backups, security, and then moves up to capacity planning and performance.
It’s not meant to be doctoral-level – this is just the intro course that we all wish we’d have gotten before management started screaming at us about why the database is so slow. And expensive. And unpredictable.
It’s like a prerequisite of things we want to make sure people know before they move up to our training classes.
Let us know what you think, and enjoy!
Back in 2009 (wow, seems like only yesterday!), I wrote about designing a recovery strategy for Stack Overflow. Back then, I wrote:
With these answers in mind, Stack Overflow’s decisions not to do transaction log backups, offsite log shipping, database mirroring, and so on make good business sense. Us geeks in the crowd may not like it, and we might demand the latest and greatest in backup & recovery technology, but at the same time we want Stack Overflow to remain free. As their volunteer DBA, I’d love to do 24×7 log shipping or database mirroring to a secondary server at another colo facility – but I wouldn’t be willing to pay out of my own pocket for expenses like that.
Today, the situation is totally different. They’re in the top 50 web networks, 4.4 million users, a job posting network, dozens of crazy smart employees, and I’m not even close to a volunteer DBA for them anymore. (Heck, we’ve even paid to advertise on Stack Exchange.) I hop into the company chat rooms now and then, and I swing by the offices whenever I’m in New York, but these guys don’t need me. I jump in whenever I can for fun, because it really is fun working with engineers this sharp.
That means this time, I’m blogging about designing Stack’s recovery strategy more as an outsider’s perspective. I know you folks like reading real-life case studies, and Stack’s pretty open about their infrastructure, so this will be fun for all.
What Changed? Downtime became more expensive.
If you’ve looked at the Stack Exchange team page, you’ll notice dozens of people with the word “sales” in their job title. Stack now sells ads on the Q&A sites, plus sells job postings to companies on Careers.StackOverflow.com.
There’s real money going through the network now, and downtime starts to cost more money. If the sites are down, people may go back to Google, get their answers from another site <shudder>, and there goes some ad revenue.
This meant that at least a few databases – for ads and careers – we needed to do full recovery mode in SQL Server, and start doing transaction log backups. This didn’t start across-the-board – it started only with the most high-value databases.
As the company grew, the relative cost of standby SQL Servers in a different location started to drop. Downtime seemed more expensive, and interestingly, the actual price of the standby SQL Servers started to drop. As Stack Exchange added more systems administrators, it wasn’t really much extra work for these guys to manage a few extra database servers in other locations. And as long as we’ve got extra database servers somewhere else, kept up to date with the most recent data, we might as well put ‘em to use.
What else Changed? We Scaled Out.
Stack Exchange’s API lets the public run queries against the databases in real time (and starting with API v2.1, they can even write). For a demo of how it works (but not using the live database), try out Data.StackExchange.com. For example, here’s the most recent 10 questions from Stack Overflow:
Yes, Virginia, that’s really an Execution Plan tab at the bottom with the actual plan from your query:
Like many of Stack Exchange’s tools, Data Explorer is completely open source, so you can install this same tool in your own environment if you’d like to let internal power users query your databases without having to install SQL Server Management Studio or a reporting tool.
Enter SQL Server 2012′s AlwaysOn Availability Groups
SQL Server 2012′s AlwaysOn Availability Groups allow for multiple replicas to serve 2 purposes at Stack Exchange: easier failover to remote data centers with minimal data loss, and read-only capabilities out of those remote data centers.
I’m a huge fan of AlwaysOn AGs, but they’re like the opposite of “the easy button.” Sure, you can offload read-only queries, backups, and DBCCs to secondary replicas, but you also have to introduce a lot of new dependencies like clustering, Windows Active Directory, heartbeats, and quorums. After Stack and a few of my other clients went live with the early 2012 versions, I started jokingly calling it OftenOn – the high availability functionality ended up being a source of a lot of downtime.
Stack worked with Microsoft for months to troubleshoot sporadic outages, resulting in this Windows 2008R2 hotfix and some other fun discoveries. After a lot of challenges, Stack (and most of my other AG clients) ended up moving to Windows Server 2012 for their SQL clusters because so many of the clustering problems were fixed with rewritten clustering code.
The big gotcha, though, was that if any replica loses its network connectivity to any of the other replicas, all of the involved databases will drop offline. This is not a bug – this is the desired result.
Well, this was Microsoft’s desired result. It sure wasn’t anybody else’s, ha ha ho ho, and thankfully those nice folks at Microsoft decided the behavior would be different in SQL Server 2014. Now, if a node loses connectivity, its AG-involved databases continue to stay online.
Stack Exchange’s Upgrade to SQL Server 2014
As Nick Craver writes in his post about running SQL Server 2014 in production at Stack, this advantage was absolutely killer for Stack’s uptime goals. The Stack developers have done a killer job at coding the sites – if they detect that the SQL Server databases are in read-only mode, all of the involved sites fail into a read-only mode too, along with a nice polite banner informing the reader that they can’t make any changes right now.
The Stack engineers, God bless ‘em, are so dedicated to making IT better that they’re not just willing to document their infrastructure to help others, plus build open source tools to help people, but they’re even willing to put their production web site in the hands of preview code. So earlier in November, Nick Craver and Steven Murawski did a rolling upgrade of their production clusters to SQL Server 2014.
Each cluster involves 3 nodes. Take the StackOverflow cluster:
- NY-SQL01 – the primary replica handling all incoming write connections. Sits in Manhattan.
- NY-SQL02 – the asynchronous secondary replica sitting next to it in the same cage. NY-SQL01 copies transaction log data off to this server gradually in the background. In the event of a localized failure on NY-SQL01, the admins can manually fail over to NY-SQL02 with some data loss.
- OR-SQL01 – the asynchronous secondary replica sitting in Oregon. NY-SQL01 also copies data here in the background, but due to the vagaries of wide area networks, it can be farther behind than NY-SQL02. To leverage extra hardware in Oregon, Data Explorer can be hosted in Oregon’s web servers using this read-only capacity.
All three were running SQL Server 2012 on Windows Server 2012. Unfortunately, with Windows clustering, we can’t upgrade any of the nodes in-place to a new version of Windows (2012 R2), so if we wanted to deploy that, we’d have to tear down some of the existing nodes temporarily. That was a lot of work for relatively little gain. There wasn’t a need for new hardware, either – the database servers typically run under 10% CPU, and they can cache everything they need in memory.
Since we could keep the same OS, the SQL Server 2014 upgrade process looked like this:
- Upgrade one of the readable replicas (in our case, NY-SQL02) to SQL 2014. From this point forward, replication stops to the other nodes. They can’t apply data from a newer SQL Server version, so they’ll just kinda freeze in limbo. We could still fail back to those, but we would lose all data changes made from this point forward.
- Test the apps in read-only against the newly upgraded replica.
- Test the apps in writeable mode against the newly upgraded replica.
- Make a go/no-go decision. If no-go, fail back to the original replica (NY-SQL01) and send the upgraded replica to detention. If go, start upgrading the other readable replicas. As they come online with SQL Server 2014, the AlwaysOn AG replication will catch them back up.
- Optionally, fail back to NY-SQL01 as a primary.
- Monitor the servers and the plan cache looking for queries getting unexpectedly poor execution plans. (Remnant of our SQL 2008 upgrade, and subsequent full text search problems.)
The upgrade went really smoothly, barring one technical issue involving a combination of the installer and Windows Core. The installer assumes that a particular feature will be installed (whether you need it or not), and that feature requires the full Windows GUI, so it fails on Windows Core. The “fix” was to tell the installer to skip feature compatibility checks.
I was online purely for comic relief. I think I made the sum total of one technical contribution during the entire call, and I left shortly after the go/no-go decision. Nick and Steven are top notch admins. Having said that, I wouldn’t recommend this DO-IT-LIVE! upgrade approach for most companies.
Should You Follow Suit with SQL 2014?
The Stack Exchange team is very in tune with what’s happening in their SQL Server environment. They know exactly which queries are the top 20 resource users, what those execution plans look like, and when a new query pops up to the top of the list. If SQL Server suddenly produces different query plans for a frequent query, these guys know how to work around it. They have great relationships with the dev teams, instant access to source code, and easy, automatic deployments to production to fix query problems.
I’m thankful that there’s cutting-edge shops out there like Stack Exchange that dedicate so much talent to managing their database stack and give so much back to the community (and to Microsoft). They’re helping make sure SQL 2014 is a solid product when it eventually hits RTM, and hopefully they’ll iron out any surprise bugs before folks like you deploy it in production.
If you believe your shop has what it takes to run SQL 2014 in production, you can join Microsoft’s early-access programs to get access to more frequent builds, extra support contacts, and community experts to help with the deployments. Contact a Microsoft MCM or MVP to get started.
In Michigan where I grew up, we pull the boats out of the water at the beginning of the fall. It’s a bit of a sad time, realizing we’re done having fun on the water, and the seasons are about to change.
To prepare a boat for a few months of storage, we drain some fluids, replace others, give it a good cleaning, do some basic maintenance, and put on a tight waterproof cover.
Databases need winterizing too. I bet you’ve got an application that’s no longer used, but you still have to keep the data online just in case. Or maybe you’ve got archived sales data that we still read, but we don’t modify anymore.
Here’s how to winterize a database:
Rebuild all of the indexes with 100% fill factor. Sometimes we set lower fill factors to prevent page split problems during heavy concurrency, but when a database is going into its winter, we don’t need to worry as much about that. By setting fill factor to 100% and rebuilding the indexes, we get everything packed in tightly. This means denser data – less free space, faster reads off disk.
Update statistics with fullscan. In case we don’t rebuild the indexes, we still probably need to update our statistics. I’d recommend fullscan here because we get a great picture of the data, and then we never have to update stats again on a frozen database.
Create a read-only database login using an Active Directory group. This way, if you need to add additional users to the database for read-only permissions, you can simply add them to the Active Directory group. We don’t have to write to the database in order to pull this off – which comes in important for the next step.
Make the database read-only. Let’s be really confident that the data’s not going to change underneath us. This can also get us a modest performance gain from avoiding locking, and it’ll save me time if I’ve got an inefficient index rebuild script that keeps trying to rebuild indexes even when data isn’t changing.
Do a complete DBCC CHECKDB. We want to know that we’ve got a good, clean copy of all of the database pages.
Test the full backups. Restore it somewhere else, and know that we’ve got a really good backup that can actually be restored. Once I’m confident in that, I may even consider no longer backing up this database – especially if it’s over a terabyte – as long as I know I’ll always have that backup available in multiple places.
At the end of a database’s life, winterizing it gives me one less database to worry about. I know it’s good, I know I’ve got a backup, and I can spend my time focusing on databases that are much more volatile.
Psst – keep this secret. Microsoft is putting on SQL Server training at their offices in downtown Chicago this month, and it was originally supposed to be invite-only for customers. They’ve upped capacity in the room, though, so now I can sneak you in.
Microsoft’s Patrick LeBlanc and I will be talking about high availability, disaster recovery, database design, and performance tuning all day on Thursday, November 21st.
Register here. The title says “education data” but trust me, it’s applicable to everybody, not just colleges and schools.
There’s also two more days of free sessions – one on Azure, Big Data and What’s Next, plus one on the Business Intelligence Platform and Power BI. I’m not presenting on those, but hey, if you’re looking to get out of work for a day, this is as good an excuse as any.
But register fast – seating is really limited. (And free!)
These four things are important if you want to join us in Cabo:
1. Demonstrate curiosity about the technology you use.
Don’t focus on the specific technology you think we want – follow your dreams. If you use a technology on a daily basis to get your job done, be curious about how it works. Read books and blogs. Ask questions. Debate the answers. Get involved in the places where that technology is discussed.
One of the many things I love about working with Jeremiah, Kendra, and Jes is that they want to run experiments to verify their ideas. It’s not enough for them to read an answer – they want to see it in action. When a user group attendee asks a question we haven’t heard before, we all leap to the keyboards trying to figure it out for ourselves, and then we want to blog about it afterwards.
2. Share what you’ve learned by delivering remarkable training.
When someone walks out of one of your user group presentations or gets to the end of a blog post, they should be talking about what a great job you did.
As a presenter myself, I used to think this meant uncovering an undocumented or obscure feature that nobody else knew and blowing them away with my encyclopedia of knowledge. That’s not it at all – you can be remarkable on a 100-level topic.
Don’t think “It’s all been done” – because you haven’t brought your own unique and entertaining voice to the topic. Doug’s SQL Server Murder Mystery presentation was a great example of bringing very common material to life in a fun, addictive way that gets audience members talking.
3. Have a fun yet mature personality both online and offline.
On one extreme, the market for the written instruction manual is already taken by Books Online.
On the other extreme, there’s Sandro on Project Runway.
Consultants have to find a balance between the two by bringing their personality to their work, but not turning the workplace into a bad drama-laden talk show where people are screaming about politics and religion and OH MY GOD, THE SAN ADMIN IS TRYING TO RUIN MY LIFE!
During Doug’s PASS Summit presentation this year, he had a make-it-work moment when someone asked him a question and SSRS didn’t work the way he expected it to. He froze for a second, then thought through the problem, explained it, and got the audience to laugh about it. In that one moment, he showed that he was calm under pressure, and even better, calm enough to make the right joke.
4. Keep growing.
Years ago, I blogged about a couple of my own presenting mistakes. At TechEd 2010, for example, I made a political joke that didn’t fly with all of the attendees, and I reacted poorly when someone pushed me hard on a question. I watched the videos of my work, tweaked my delivery, and kept growing as a presenter and as a person. I was open to criticism, and I still am, and you’ve gotta be too. It’s not enough to just respond to comments, but you’ve also gotta be able to read between the lines and figure out what I need to do to succeed.
These tips aren’t just for becoming employee #3 at Brent Ozar Unlimited. (After all, we had a handful of applicants who met these qualifications.) Follow these tips, and you’ll always be employee #1 at your current job, and you’ll have a line of people ready to hire you.
You can see the full video on SQLcruise.com, where Doug had entered a contest for a free cruise a couple of years ago. Of course he was picked as one of the winners, because I was in stitches as soon as I saw the viking horns moving through the cubicles.
When I met him in person on the cruise, he lived up to expectations by being witty, smart, humble, and just genuinely fun to be around. I enjoyed being around him, and I wished I could hang out with him more often.
Fast forward to last month, when he answered our call for SQL Server people looking for a good time. We got a ton of good responses that we were really excited about, and this week we’ll blog about the hiring, interviewing, and tech screening process. Doug was definitely one of those people where we all said “Wow!” out loud when we saw his name on the email.
We didn’t even have to look at the email contents to know Doug’s contributions to the community. I’d been particularly excited about his recent presentation idea, SQL Server Murder Mystery Hour: Dead Reports Don’t Talk. He turned the session into a fun, interactive experience.
When we *did* look at his email’s contents, Doug blew us away again with a video about his community contributions:
He knew we did a lot of video work, and he wanted to show that he understood how we work. Jeremiah, Kendra, and I are so passionate about making databases easier – and more fun. Just like Jes (our Employee #1), Doug really gets that.
We’re so excited to have Doug join our team.