You need to poop. Maybe not right now, but in general, you need to breathe, eat, drink, sleep, and poop. If you can’t do any of those things, then the rest of your needs will take a back seat until you can accomplish the basics.
Psychology professor Abraham Maslow designed Maslow’s Hierarchy of Needs to illustrate how us meatbags prioritize our daily tasks. It’s usually visualized with a pyramid:
As a presenter, I find this pyramid really useful because I can’t do a good job of presenting if I’m thirsty or if I need to hit el baño. I’ve learned that before I start teaching database stuff, I need to hit the bathroom, grab a Clif Bar, and down a bottle of water. No, I don’t have sex before I present. (Maybe that’s why Paul and Kim do such a good job presenting – hmmm.)
I hereby propose Ozar’s Hierarchy of Database Needs:
Backups: You can’t lose more data than the business is comfortable losing.
Note that I didn’t say you can’t lose data. You can, and you will, because safeguarding data is expensive. Not all data is created equal, and businesses are comfortable losing certain kinds of data.
For example, I’ve worked with businesses that chose not to back up their development servers at all because they believed source code control was their first line of defense for developers. They regularly refreshed development servers once a week from production. If they lost a development server halfway through the week, everyone’s work was checked into source code control anyway, and the server could be rebuilt from scratch fairly quickly.
At the other extreme, I’ve worked with DBAs who knew full well their mission-critical databases weren’t well-protected from disaster.
The real problem isn’t backups – it’s communication.
Being a truly exceptional DBA means that your manager, plus every level all the way up the chain, is comfortable with your (in)ability to restore every system in the shop. Your managers have a list in writing of all the company’s systems, a high-level overview of how frequently they’re backed up, how frequently the restores are tested, and how long a restore will take. If you haven’t written a list like that, stop and do it now. It’ll only take a few minutes, and it’ll pay off dramatically. This list will cover your ass, and this list will get you the hardware you need to do the right kinds of backups.
This list will also free you from trying to be a perfectionist. The business doesn’t need transaction log backups every 60 seconds on every server. Learn to match up your job duties with the company’s financial needs so you can focus on what really matters.
Security: Know who has access to the data.
This gets a little tricky with Active Directory groups because the Windows team can add & remove group members without the DBA knowing.
My favorite visual communication method for this is a grid of servers & databases down the left side, and a set of columns for permissions across the top:
The first time I present managers with this information, I dumb this grid down because it’s an overwhelming amount of information for readers to digest. I want them to get the big picture: “We need to reduce the number of people who can get the DBA fired.” After the first round of cleaning house, I add columns for the database backup and the physical database files, both of which are a serious security risk. If someone can take a SAN snapshot of an unencrypted database, they can waltz right out the door with a copy of it.
Note that I didn’t say, “You have to control who has access to the data.” Just as the business needs to decide the value of data, the business also needs to make security decisions. Police don’t make the law – they just enforce it. Likewise, the DBA needs to serve and protect the data.
Capacity: Know when you’re going to run out of space.
Every database in your datacenter is growing. All of them. They’re not all going to drain your storage dry tomorrow, but every single database has an expiration date when they’re going to run out of space. In consolidated environments with dozens, hundreds, or thousands of databases on the same server, this gets a lot harder to predict.
To make matters worse, growth rates aren’t stable. All it takes is one leftover BEGIN TRAN statement in someone’s SQL Server Management Studio and your transaction log files can grow out of control overnight. The most out-of-the-box fix I’ve ever heard for this was Dave Stein‘s excellent suggestion to leave a 10GB backup file on your log file drive, and to leave explicit instructions with your sysadmins. When the alerts come in that the log file drive is running out of space, delete that 10GB file and start taking emergency actions. No, it’s not the most enterprise-oriented solution, and yes you should work towards something better, but this is a good start for small businesses.
Before you build your own scripts to alert you when the SQL Servers run low on drive space, step back for a moment and ask who else in the company needs this same solution. Odds are your team needs it for the file servers, backup servers, mail servers, even the web and app servers. Rather than reinventing the wheel, suggest that the entire team adopt a simple monitoring system.
Performance: Know your current bottlenecks and how to fix ‘em.
Once the basic infrastructure issues are addressed, you can finally start turning your focus toward real performance tuning. Glenn Berry’s DMV queries are my favorite place to send new performance tuners who want to learn more about what’s holding their server back. SQL Server is constantly tracking what it’s waiting on, and Glenn’s queries use the wait stats DMVs to pry that information out.
If you even recognize the term “wait stats,” you’re already a long way up the hierarchy. Most database professionals are still using tools like Perfmon to check CPU percentages and looking at Average Disk Queue Length for drive issues.
I didn’t say you had to fix the bottlenecks – I just said you need to know how to fix them. The actual process of fixing them is a business decision: the business has to be willing to spend the money and time to make their server go faster. Your responsibility is just to have the answer when the business asks, “Why is the server slow, and how can we make it faster?”
Futureproofing: Preventing availability, security, and performance issues.
When the groundwork is taken care of, you can start looking forward and reacting to tomorrow’s problems instead of today’s. It’s hard as hell to get here, but wow, the view is fantastic from the top of the pyramid. When your phone isn’t constantly ringing, you’ve got the time to:
- Plan upgrades and offer budget options to the business
- Review T-SQL code before it goes live
- Learn and grow your skills
- Train your coworkers and give back to the community
These are the most fulfilling parts of the database professional’s career. Not only do they make you feel better, they pay benefits forward. For example, when you’ve got time to learn automation, you can write scripts to save yourself even more time – thereby giving you even more learning time! When you can offer budget options for the business to make an old, unreliable server go away, you’re more likely to make it happen. By writing training presentations for coworkers and communities, you force yourself to learn more details.
Peace of mind: knowing where every database is at on the pyramid.
No, that’s not a line on the pyramid because what the database needs is separate from what you need. See, I used to blame myself if every server wasn’t at the very top of this pyramid. I got frustrated if I knew how to fix it but I couldn’t get the time/money/permission to make it happen. After a few years of using the Getting Things Done philosophy at work, I came to terms with the fact that I’ll always have more work than I can handle. My job is to do the things the business values most, and I just won’t have the time and resources to address everything on every server.
Your job isn’t to bring every database to the top of the pyramid. Your job is to do what you can with the time you have, in the order the business wants things done. Make a spreadsheet list of your servers (not databases yet – let’s start easy) and add columns for each level of the pyramid – Backups, Security, Capacity, Performance, Future-Proofing. Today, you probably have servers where you focus on performance, but you’re not even sure if the backups are good. It’s time to fix that.
And if you actually made the list, then enter the Red Gate Exceptional DBA contest. You deserve it, because you’re the kind of DBA who cares.








I shall never divulge our pre-show warm-up routine details…
This is awesome Brent, The biggest value here is the pyramid, the ordering of priorities. In practice, it’s not obvious:
So if we ignored all database needs and measured priority based on which ignored need produces a call to the DBA first. The priorities would be different. (i.e. chances are performance will suck before running out of space). But of course that ignores the importance of each need.
Good job Brent!
Very nice article, Brent! I enjoyed how systematic the pyramid is: if you’re missing something from the bottom, any work above that level could be wasted time if something were to go awry.
brent, love the use of Maslow’s pyramid!
it’s so simple and yet so informative. if your interested i also used it in an unsql post on the topic of dba needs: http://www.sqlmashup.com/un-sql-friday-show-some-love-0
thanks for the great post.
Maybe I’m picking nits, but I might put security before backups. Data can be recovered with great effort even if backups are lost, but once the data leaks out, there’s no putting that back.
Great post – really brings things into perspective.
Now off to go list all my servers and whatnot.. so easy to get caught up in immediate
I just love you started a post with “you need to poop”
I will definitely use the part about security.
Also, Dave Stein’s 10GB fix has already saved me twice.
Will read again!
“This list will also free you from trying to be a perfectionist.”
What an eye-opener that line is!
To paraphrase Seth Godin:
“Anything beyond good enough is…a waste of time.”
Great article Brent, as usual. Thanks for the shout out. When I told you that I placed a “DeleteThisFileForSpace” file on the T-Log volume, I actually thought I’d get chastised for it.
Excellent article and thanks for the information. Definitely helps remind me where the priorities need to be. You should turn your diagram into a nice poster with bit of info for each level. I’d put it on my wall! I’m sure there are several companies that would love to get there name added to that poster.
Thanks, everybody! Ooo, wow, David, that’s a great idea. I’ll play around with doing a poster of it.
PLEASE PLEASE have huge letters at the top: “YOU NEED TO POOP”
Definitely my favorite opening sentence for a blog post, by far.
when you’ve got time to learn automation, you can write scripts to save yourself even more time – thereby giving you even more learning time!
This is what i am doing.
Very nice hierarchy.
Brent I think you are always thinking about others.Thats why you have been written(help) like this.
Is it right?
I like the pyramid. I can see myself pointing to this post repeatedly.
Cheers
Tim…
Great article. Lots of common sense clearly articulated.
For me the “hell yeah!” moment was the last paragraph. I think a lot of people would be happier in their jobs if they pinned this phrase above their monitors and referred to it more often: ” Your job is to do what you can with the time you have, in the order the business wants things done. “.
If one is at all passionate about what one does, then it’s natural to try and perfect it. It’s very easy to get frustrated observing all of the things being done ‘wrong’, try to fix all of them and thus fix none of them well.
I like your emphasis throughout the article on giving the business the information, explaining the implications, and acting on their prioritisation of it.
Of course, that doesn’t work if they say “all of it, and now” ;-/
Excellent post. I hope to see this pyramid at DBA’s desk.
haha, the most interesting opening I’ve read in months.
Two great reminders in this post -
1 – The importance of “first things first” when it comes to being a DBA. When I blogged about, and later presented about what DBAs should focus on FIRST, this is just what I had in mind but you presented it in such an awesome way. I love the hierarchy and I may reference it the next time I give that “As a DBA, Where Do I Start?!” chat. I also like the useful information you gave for each level.
2 – Blogging/SEO tip – Pay close attention to that opening line because that is how so many auto-tweeters/ping programs/etc. get the content to send out that tweet or announcement about the post. Great opening to get us clicking, sir
Excellent article. I think engineering school often teaches the skills to solve problems, but not the skills to prioritize which problems need to be solved. This requires communication, as you say, but it also requires some template for prioritization, such as Maslow’s pyramid provides. I’m a developer / dba with a background in philosophy, so I’ll be thinking about other templates!
[...] quick look at a server and have a pretty good idea of what’s going on. She’s mastered Ozar’s Hierarchy of Needs, and now she’s teaching her junior DBAs how to do the same. All her servers are [...]