If your DBA is still adding Windows logins to your database servers then they are doing it wrong.

Using logins (versus Windows groups) is an inefficient method that hasn’t been considered a favorable practice for almost ten years. Oh…sure…it works. I won’t argue that point. But if you are administering hundreds of database servers and you are using logins instead of groups then you are making your environment more complex than it needs to be. When shops exploded with exponential growth in the past decade Microsoft recognized this by publishing guidelines around security best practices that reflect the preference for using groups. Here’s one from 2005 that states simply at the top:

“Because it is inefficient to maintain user accounts directly, assigning permissions on a user basis should be the exception.”

Exception. As in “not the norm”. And say what you want about SQL 2000, but even they knew that using groups was the way to a simpler life.

Here are three reasons why you should be using Windows groups.

Audit compliance

Since those best practices guidelines were published there has been an ever tightening of a grip on systems with regards to security and audits. Most companies that have to be in compliance with government legislation of some type will prefer to use Windows groups to access there database servers. Why? Three words: separation of duties.

The DBA should not be the person that is adding or removing individuals from groups within Active Directory. Those actions should be handled by a security team, and only after being given an approval by the IT custodian (or manager) responsible for the application (also, not the DBA). In other words, security in your company should have two parts. One part is handled by the DBA who, working with the database developers, creates the necessary roles, schemas, and Windows group logins on the database instance. The other part is the security team who controls the people added (or removed) from the Active Directory group(s) so that the users can access the applications as needed.

That is the separation: the DBA doesn’t control the users in the groups, just the structure the groups are allowed to access. Likewise the security team has no say in how the structure inside the database instance is built, they just fulfill the requests for access after the IT custodian has approved.

Reduce your administrative overhead

Besides the likely compliance issues you will face, if you are adding in Windows logins by hand your actions will not be able to scale to hundreds of instances. I’m certain that someone will leave a comment telling me that Powershell can get the job done with just a few lines of code. This would be where I remind people that automation is a wonderful way to make mistakes faster than ever before.

Let’s consider the case of a developer who needs different levels of access for development, test, QA, and production servers. That would mean you need to keep four copies of your scripts for each environment, and server, and person. That is a lot of scripts to maintain and troubleshoot. I can’t even imagine trying to add or modify those scripts as needed.

Even with just a handful of servers the idea of trying to maintain the correct permissions on a per-user level is more overhead than I would want. Every time a new person joins the company I would need to recreate all the permissions necessary for that person to access the databases they need. And the minute a person gets an ‘access denied’ error message returned it would be in my lap to figure out what was missed.

I can’t imagine why anyone would prefer to spend their time making things more difficult than they need to be. With Windows groups your could have all the permissions, roles, and groups defined in advance and then the security team (remember them?) could add and remove users as needed.

Less mess to clean up afterwards

One area I see customers and clients struggle with centers around the removal of logins after a person has left the company or even changed jobs within the company. When there is no defined removal process the end result is a glut of logins defined on an instance of SQL Server and most DBAs have no idea who should stay or who should go.

When companies have a defined access process that is tied to Windows groups it helps to avoid the issue of having logins lingering around for months and possibly years. We’re talking about one step versus hundreds of steps. Which would you prefer?

If you think not having separation of duties would make an auditor have cause for concern just sit across from the table and look them in the eye and say “those logins have been there for years, we rarely go back to remove them, we wouldn’t know which ones are no longer valid”. Good times.

Exceptions are not the rule

There are always going to be exceptions to using Windows groups. And for those exceptions you will have the extra overhead, you will need a defined cleanup process, and you will likely need to file for an audit exception. But they are exceptions, not the rule. Exceptions always introduce complexity into your environment. Unless you enjoy having an environment more complex than necessary, unless you enjoy having failed audits, you should start using Windows groups as your standard.

If you only have a handful of servers, and your shop doesn’t need to comply with audit guidelines, then you can get away with continuing to use Windows logins versus groups. But at some point you will cross a threshold where the overhead for maintaining your environment outweighs the usefulness. And it is then, at the precise moment, when you will look back and say “crap, I should have listened.”

You’ll thank me then. And you’re welcome.

Wanted to do a quick follow-up from my post earlier this week. If you recall, I mentioned how the Books Online entry for managing the suspect_pages table inside of the MSDB database was slightly misleading. I decided to use this as an opportunity to show you how easy it is to submit feedback to Microsoft about their products by using Microsoft Connect.

I’m not sure how well know Connect is for most people. I know that I am often asked the question “how do you provide feedback to Microsoft” and I usually answer “I email them”. That doesn’t work for most people who don’t have access to my email contacts (and this, despite my using Facebook, Twitter, Foursquare, and Instagram) so that’s when I say to use Connect and most folks stare at me and wonder why they need Kinect and Xbox in order to submit a simple request.

You don’t. Yes, I know the names are the same. But they are spelled differently. One of them makes you more hip than the other. I’ll let you decide which is which.

Anyway, here is the video, in all it’s glory. Watch me type into a text box.

Yep, it was that easy. I would urge you to use Connect early and often, especially with SQL 2012 coming any day now.

Notice they don't list "facts" anywhere?

Last year I wrote a book review about The Cult of the Amateur: How Today’s Internet is Killing Our Culture. The short of it is this: there is a shortage of fact checkers. And no, having facts checked by a community of users (AKA: Wikipedia) doesn’t work because those are the same amateurs that are running all the blogs that are passing around Miss Information like she was a bong in a room full of Libertarians. I once had a person tell me that they trust a Wikipedia entry on transaction logs more than a blog post from some guy named Paul Randal (blog | @PaulRandal), and I couldn’t believe what I heard. That’s like saying your teacher in high school knew more about The Great Gatsby than F. Scott Fitzgerald because she participated in a book club a few years ago.

The other day I found an interesting article on an Oracle blog. Yes, I read Oracle blogs, mostly for the humor. The article was comparing Oracle 11g to SQL Server 2008R2. You need to register if you want to access or download the PDF…or you can save yourself the hassle of giving Oracle your contact information and download it for yourself right now.

Go ahead and read it. I can wait.

That PDF is pure comedic gold. At least I am hoping that they were looking for something funny to be produced. If they meant for this to be a serious comparison then they fell short of the mark. If I had submitted research like this as part of my work in graduate school I would have been asked to leave the program. And to be fair not all of their statements are lies. We all know that SQL 2008 won’t run on Linux, for example. And therefore the cost of SQL Server is more than just SQL itself. But instead of sticking to the facts they decided to pick up that bong and get to testing.

Let’s look at some of the highlights. I present for your enjoyment Table 6:

I know what you are thinking. You are thinking “how the hell does it take 17 steps to create a table inside of SSMS”? That’s a great question. Let me help you understand it a bit more by showing you Task 6:

There, I hope that clears things up for you. What’s that? You dare to question the Oracle? I’m guessing you have many of the same questions that I have, such as:

• How does “Expand database – comptst, right click tables, select New Table” count as zero steps?
• Why did zero steps for Oracle take one second to complete?
• Why don’t they tell me the tables they are trying to create? Why not show me the DDL?
• Why are we comparing the GUI tools for two different platforms? That’s like comparing apples to oranges to pears to a bottle of wine and saying “wow, things sure taste different”.
• I thought Oracle DBAs didn’t use the GUI? So where did they find people to perform these tasks?
• What is the O/S in use for each of these tests?
• Doesn’t Oracle use nHibernate to generate all their statements? (OK, that’s not fair…to anyone)

To be fair, I understand that we are talking about marketing here. That is part of the problem for me. When people see this they say “that’s just marketing, which is always full of lies”. Well, I am in marketing, and I wouldn’t ever allow something like this to be published. But the truth is that other people don’t have the same moral compass as I do. Marketing materials such as this cast a bad light on all of us.

Competitive analysis documents are wonderful things for people to digest when they need to make a decision. But documents such as this have little in the way of actual facts. It makes me wonder who their target market is, because most DBAs I know have half a brain and would see right through something like this. My guess is this is meant for people with less than half a brain.

Don’t believe me about the half a brain part? May I submit to evidence Table 13:

Yes, that’s right. Oracle backups take less time, especially when you schedule them to be run later and don’t record the amount of time they take to run as part of your “facts” and also don’t tell me about the hardware and network configurations used in your testing. But hey, why bother with such details at this point?

I could go on dissecting this document, one sentence at a time, but I would rather you judge for yourself at this point. Also, don’t think Oracle only does this against SQL Server. No, they like to go after IBM and DB2 as well.

Enjoy the laugh today.

You never see the termites, you only see the damage they have done. And by then it is often too late.

Same with corruption inside of your database. Often time most folks have no idea there is any issue until it is too late.

Wouldn’t it be nice if there was a quick and easy way to determine if your database was corrupted?

Turns out there are some quick and easy tools for SQL Server but they are buried so deep inside you are likely to never even know they exist. Just like termites under your doorstep, or unicorn bacon.

These tools are the policies that ship with SQL Server, but are not installed by default. They are on your servers right now, doing nothing, except waiting for you to discover them. The one I am going to show you today is named ’Database Page Status’. It relies on a couple of things. First, that your databases have the page verify set to CHECKSUM. Second, that a corruption has happened and an entry has been written to the suspect_pages table.

I made a video to show you how entries get written to the suspect_pages table, how they get removed (or how Microsoft believes they get removed), and how to find those hidden policies.

If you aren’t the type that enjoys using policies then you could use a different method such as Powershell in order to check all of your instances for corruption. The key is to build your process to check the msdb..suspect_pages table.

But you should do something. Before it is too late.

If you are planning on attending TechEd this year then you will have a chance to see myself and Denny Cherry (blog | @mrdenny) deliver a precon seminar. The title is “Microsoft SQL Server Performance Tuning and Optimization” and we are very excited to have this opportunity. And apparently Microsoft is excited to have us as well, because they are also sending the two of us to Amsterdam to do a repeat performance two weeks later for TechEd Europe.

Denny and I have been working on the precon now for a couple of weeks. It’s tough since we both have full time jobs and live on opposite ends of the country, but we manage to meet at least once a week over Skype to discuss the session. Here are just a few of the performance tuning items we are planning to discuss:

• Table Partitioning
• Filtered Indexes
• Columnstore

In addition to those items, we are also going to discuss how you can implement AlwaysOn read only replicas to help scale your system for performance as well as walk you through some general troubleshooting techniques with regarding to execution plans.

The last registration update had our precon in the lead for attendees, in both countries. We’d like to keep that trend going.

Go and get yourself registered for Orlando, Amsterdam, or both!

Your office should look like this.

Every great DBA I know is both driven AND lazy. They are driven to be as efficient as possible, so they can do less work. It’s a wonderful pair of personality traits to have as a DBA.

The unfortunate part is that the more driven they are, the more efficient and lazier they get, which often results in their boss looking at them and saying “why am I paying you to just sit around?”. This results in many DBAs being dragged into administering other applications (like Sharepoint) because, hey, they run on databases too, right?  With you were sitting there looking like you weren’t doing anything it just made sense to give you extra work.

I have listed seven items below that I believe are universal for anyone that has the letters “DBA” in their job description. Some DBAs need to be a part-time SAN admin, or VM admin, or know all about security, or Active Directory, or .NET. It differs from one shop to another. Whether it is day one or one hundred in your career as a DBA you need a guide that helps you stay focused on your core duties. That’s what I have created here. It is the Minimalist Guide to Database Administration, and my goal is to make sure that no matter what your level of efficiency and laziness you are able to focus on the bare essentials (the minimum) necessary to be a rockstar DBA.

1. Backups

It’s simple, really: get them done.

There really isn’t a lot to say here, but as a DBA your number one job is to ensure that you can recover data. You cannot recover data without having configured your database backups to happen. And while it is surprisingly easy to configure database backups and yet a shocking number of people never bother. You can use custom scripts or maintenance plans to get the job done, just make sure you are getting them done. Grant Fritchey has an excellent article over at Simple-Talk that I would recommend you read.

In order to keep with the minimalist theme I am going to tell you to use backup compression (depends on your version). You can enable this at the instance level or as an option included within the backup command. This will help keep disk space to a minimum. Also, you need to talk with your business users to find out how often you need to do full backups, differential, and transaction log backups as well. My default choices were weekly full backups, nightly differential backups, and hourly transaction log backups. This was a good place to start and I could adjust as needed.

2. Only Be Alerted When Necessary

I’ve never been one to want to be alerted just for the sake of being alerted. It makes no sense to me to be paged at 11PM just to know that something successfully happened. I expect success, and would prefer to only be told about when something has failed. As far as failures go, I only want to be told about them when it is something for me to fix.

When I only had a handful of servers under my care I had alerts for all sorts of things. I was even alerted to when a session had been blocked for more than five minutes. Sounds good, right? Sure, except then I would call the end user to inform them of the situation and ask them what they wanted me to do and I would usually get told “I dunno”. Well, OK then. If you don’t want, or know, what action I should take when you have such blocking, then why would I continue to want to alert myself about this activity?

I wouldn’t. Neither should you. Only be alerted to the things you can take action upon immediately. Knowing your server CPU utilization is at 80% might sound like a nice thing, but tell me exactly what actions do you plan to take as a result? Now…tell me what actions you will take if you had over a dozen servers at the same time reporting more than 80% CPU utilization?

At some point your reach is greater than all your available hands. Split out your alerts into those that are informational versus those that are actionable. If they are not actionable then at some point you will simply turn a deaf ear to all alerts. That is not going to be good for anyone.

3. Automate

If you haven’t been automating any of your processes, get started. As you get more and more servers shoved your way you will find that automation will be your BFF. In my case I dove into Systems Center Operations Manager (OpsMgr) as a way to automate a lot of the things I needed done. Once OpsMgr recognized that an instance of SQL was running on a server it would simply execute all the scripts I needed done for me. I could use OpsMgr for just about anything I dreamed up, including having it alert me if I had not taken a backup recently.

There are many other ways to automate your systems, including the use of Powershell, Central Management Servers and policy-based management, and even old-school SQLCMD. Use whatever works best for you, but use something and get your stuff automated. Don’t wait until you have too many servers to manage before you start automating your processes. If you have more than one server under your care you should be automating things right now.

4. A DBA Has Got to Have Standards

You want to have a standard build and configuration for your database servers. It makes troubleshooting much easier when you know that each server is essentially similar to all the others. The fewer of those servers classified as “one offs”, the better it is for you and ultimately for your end users that need you to solve problems quickly.

Some of the things you want to have standard would include (but not limited to) the following:

• data and logs on separate disks
• authentication mode (pick one and use it everywhere, consistency is key)
• version level/patching
• naming standards

5. Only Install What You Need

Another way to reduce your surface area of administration and troubleshooting is to only install the minimum services needed for your database servers. This has an added benefit of also

Get used to these screens.

reducing the surface area for an attacker, something your security folks would appreciate. A great way to get this done for SQL 2012 is to utilize Server Core.

What Server Core does for you is it allows for you to have a “low-maintenance” environment. What that essentially means is that your server isn’t running any unnecessary software, including a GUI for you to use. That’s right, when you go Core you end up doing everything from a command line. It’s as if Microsoft looked at everyone and said “You like the Linux? Fine, here you go, enjoy!”

As a DBA (for any platform), this makes perfect sense for you as it reduces the number of things you need to be an expert in and examine while troubleshooting. Don’t install unnecessary services and you won’t have to worry about them interfering with your database engine.

6. Restores

I told you that your number one job is to recover data, right? And you are doing your backups, right? OK, quick question for you: how do you know you can restore those backups? Is there a way for you to verify that your backup can be restored?

Yes, there is, it is called a restore.

That’s right. The only way to truly know if your backup can be restored is to actually perform a restore. This may not be practical for you, doing restores of thousands of databases each day in order to verify that they are valid. That’s why I wrote a post on how to get the job done in an efficient, minimalist style. Turns out you may not need to do all of them after all, but you certainly do need to be testing some of them.

7. Moment of zen

Any time you hear about “minimalist” it is usually accompanied with the word “zen”. There’s something to be said for that with regards to being a DBA.

Don’t panic.

That’s right, stay calm. Breathe deep. You don’t know everything. You will constantly be learning on the job. Never panic, no matter what. When everyone about you is losing their composure they will need someone to be a steady influence. Let that be you.

In your career as a DBA you are going to be subjected to a lot of stress by others. Don’t let their negative energy become your burden.

It will serve you well to remember that life is an experience, and there is much for everyone to learn.

Also, stabbing people with a paper clip in the neck just annoys them more.

Those are my seven bare essentials for any DBA, my “minimalist” guide. What would be in your guide? What tips and tricks have you learned to help yourself scale as a DBA, to be able to take on more and more responsibilities as you get more and more efficient? Start writing down your own guide and compare your list to mine. Did I capture the essentials? Did I include something that shouldn’t be there? Leave a comment.

You could be here!

Do you enjoy working with SQL Server? Do you enjoy relaxing in wine country? Would you like to work with SQL server AND relax in wine country at the same time?

I know I would. And so would Denny Cherry. In fact, Denny liked the idea so much he decided to create SQL Excursions, a series of events where people can get together to learn about SQL in a relaxing manner. And I was honored that Denny asked me to be the first guest presenter with him for the very first SQL Excursion coming up in Napa, CA from May 17-19.

Check out the agenda for the event. If you want I can summarize it for you here: #SQLWINNING

Performance Tuning Made Easy - This will be similar to the half-day session offered at PASS that had 250 people in the room and another 100 that were turned away. If you were one of those 100, you will want to attend as I plan on taking a deeper dive into how to help you be more effective in your current role, something I cannot do when speaking to hundreds of people at once.

Storage Configuration and Tuning - Denny Cherry is one of the top experts in the world when it comes to storage configuration and tuning and a Microsoft Certified Master in SQL Server. Come listen to him teach you some tips and tricks with regards to storage, which will lead nicely into…

Virtualization and SQL Server - …Denny and I sharing our experiences with SQL Server running in a virtualized environment. We expect to not only show you some examples of VMWare and Hyper-V, but we are also planning on having you put your hands on the products as well. We want you to leave Napa feeling comfortable navigating your way through a virtual environment.

SQL Server Indexing Top Down - Denny will walk you through indexing and SQL Server, discussing strategies for how you can tune queries using proper indexing and how to conduct proper index maintenance.

How Table Partitioning Works to Save You Money - Denny has been helping clients for years save money with some very simple partitioning techniques. Denny will help you understand how to get this done for your shop as well.

Hands On Troubleshooting - This will be similar to the series of “Choose Your Own Adventure” talks that I have been participating in recently. We will walk you through real scenarios where you will need to troubleshoot using native tools only. This shared learning experience will provide you a solid base for how to troubleshoot the vast majority of performance issues in your own shop.

OK, now comes the important part: go here to register. Don’t forget we will have wine tastings, wonderful weather, great food, and an opportunity to network and build relationships with your peers that will serve you well going forward.

I can’t wait to see you there!

This tiny guy runs everything you do!

Ever try to troubleshoot something that doesn’t really exist?

I think this virtualization thing is here to stay, I really do, but the trouble I see people having with virtualization is that they don’t know where the bottleneck truly lies. There are so many layers involved that most standard troubleshooting techniques fall short. Just think for a minute about being a SQL Server DBA in a virtual world: you administer a piece of software, running on a guest O/S, that is running on a host, that is connected to a datastore that may or may not be shared with “noisy neighbors”.

Knowing all that, when an end-user comes to you and says “this query is running slow”, where do you begin to look?

I always start with the virtual layers. I’d rather spend 5 minutes ruling out the virtual layer as a bottleneck before I try to tune a query. It makes no sense to spend time trying to make a query run faster if the bottleneck is at the host level, for example. That’s wasted time, and I *hate* wasting time.

One example I see often these days has to do with CPU pressure. In my experience most database servers are not CPU bound. (I said “most” and “my experience”.) Usually a database server has a lot of extra CPU cycles to spare. But that is not always the case in the virtual world. So when I come across a database instance that is showing CPU pressure I like to ask a very general question: Is it internal pressure, or external?

One of my favorite metrics to examine when researching potential CPU pressure is called signal waits. You can read more about signal waits at this blog post by a member of the SQLCAT team. The default threshold I like to set is 25%, meaning once I see I have about 25% of my sessions simply waiting for an available CPU I am likely to believe that the CPU pressure is internal to the instance. Of course more factors come into play before I would define 25% to be a problem, such as volume of sessions, length of time for each session to execute, etc.

But what about a guest O/S that is also waiting for an available CPU from the host? Imagine that your sessions are waiting for the SQLOS to give you an available CPU, and the SQLOS itself is waiting for an available CPU from the host? Wouldn’t it be nice if there was a metric for you to know if the issue is at the guest layer, and not internal to SQL?

Well as luck would have it such a metric does exist: CPU ready time. This is simply a metric that tells you the percentage of time that your guest was ready to run, but could not get scheduled.

Together the signal waits and CPU ready time help to give you a more complete picture of what is happening to your database instance. Unfortunately, you can’t get at all of this information easily from within vSphere. Here’s a quick overview of what you would need to do in vSphere to research CPU pressure:

1. Open vSphere, then go to the correct host, then to the guest that you are interested in monitoring.
2. On the Performance tab add in the counters you want (but no more than two!)
3. See real-time information (too bad if your issue was last week and you don’t have details any longer)
4. Ascertain if the issue is local to guest by going back to the host and looking at Performance tab
5. Add in the counters for the host Performance tab view (but no more than two!)
6. See real-time information (too bad if the issue was last week and you don’t have details any longer)
7. Throw up your hands when you realize that you still don’t know if the pressure is internal or external to SQL running on that guest, on that host
8. Take your hands and slap yourself when you realize you can’t tie anything back to specific SQL statements

Sounds rather time consuming, right? Especially if you still won’t have any idea about a root cause or what specific actions to take after spending all that time investigating the issue. If you want to see it for yourself I made a video to show you some of the challenges that vSphere has when it comes to displaying all of the metrics necessary for you to make an informed decision.

The short of it is that vSphere is never going to give you a complete view (including SQL statements or even number of sessions running) in one screen. But IgniteVM will do that for you, saving you time, and ultimately money as well, money that can then be used to buy more bacon related products for your home or office (don’t forget Valentine’s Day is right around the corner).

Not only is virtualization here to stay, but tools like IgniteVM will be here as well to help administrators quickly find the root cause for performance bottlenecks.

Want to chat more about monitoring your virtual database servers? Then contact me and I would be happy to set up some time to talk. Also, Confio has regular product demos: go register for the next one here.

I’m normally not one to advocate the use of the Database Engine Tuning Advisor (DETA), a tool available inside of Microsoft SQL Server. (To be fair, I’m not a fan of the SQL Tuning Advisor from Oracle, either.) But I recently came across a little nugget of information that I wanted to share with you regarding an improvement in the DETA for SQL2012. You may not know it from clicking on that link, so I’ll spell it out for you here:

“To tune a database by using the plan cache”

And suddenly I am interested in using the DETA again. This makes things so much easier for me as an end-user. I no longer need to configure the DETA to run at a specific time. I can simply point-and-click and instantly have a handful of recommendations to evaluate.

Of course taking action on the recommendations without doing any analysis is not a recommended course of action. But the idea that I can use the plan cache is something I am eager to try.

Here’s hoping I won’t be disappointed…again.

Trust me, I'm a DBA

“Signs point to yes.” – Magic 8-Ball prophecy

You have probably heard this line at one point, the one that says “the best DBAs are the ones you never see or hear?” I used to think that was a result of some sketchy personal hygiene choices and later on understood it to mean that if everything is running smoothly then there isn’t a need to see your DBA. It’s kinda like how you never see your plumber. Oh sure, you could call him (or her) and chat, have them over for drinks or dinner one night, but you never bother talking to them until your toilet backs up and there’s crap everywhere. That’s how most DBAs are treated as well, we don’t get called until after the crap is on the floor.

Unlike your plumber most DBAs are performing regular work on your databases. Much of this work will go unnoticed. The reason for that is simple: you’ll freak out if you knew what we were doing. And if you ask us about something we are likely to tell you half-truths because (1) we don’t want you to freak out and (2) you never understand us when we talk to you anyway.

Here’s my list of things that I am willing to bet your DBA hasn’t always been truthful about.

1. Your database server is still on physical hardware

Probably the number one misconception that end users have these days centers around the use of virtualization. People fear change, and when they are told that their servers are about to be virtualized they freak out. And for the handful of users that don’t freak out immediately their reaction is just delayed until the moment that something goes wrong and then they blame the fact that the server is on virtual hardware. What’s that? The bank didn’t send the files last night, so the import never started? It must be due to the fact that we were virtualized, because before then nothing like this ever happened.

Wrong. Bad things happened before you were virtual, too. It’s just that you don’t remember. So we don’t bother telling you about the switch. No, we wait until it leaks out months later, just so we can say things like “look, it’s been on a VM for six months and you never once complained about performance, so don’t try blaming virtualization for your issues now.”

2. Everything is fine, nothing to see here

Chances are everything is not fine. In fact, chances are the data center is on fire and your server melted last night (good thing they were virtualized so we could failover immediately to a different data center without you knowing) but we aren’t going to say a word to you about it. And why not?

Is it getting warm in here?

Because the minute most users hear about something having gone wrong they like to blame EVERYTHING on whatever went wrong. Take this example:

Me: “Hi Craig, just want you to know that last night at 11PM the differential backup failed. We’re not sure why yet, but we re-ran them at 11:30PM and those worked. So, if you ever need something from Monday night and ask for the 11PM backup and you’re told that we only have one for 11:30, you don’t need to panic.”

Craig: “The backups failed?”

Me: “Yes, but we re-ran them right away, so we have a good one, just from 11:30PM, and not 11PM”

Craig: “OK then, that explains why those reports at midnight didn’t work.”

Me: “No, it doesn’t, the backups have no bearing on those reports. It’s two different servers. Your report server melted in the fire. That’s why they didn’t run. This is a different server, and a different time. There is no relation between the two.”

Craig: “But the reports use data from that server. Chances are the data they retrieved caused the fire.”

Me: “Is it too early to start drinking? I guess not, because clearly you have already.”

That’s why we don’t tell you anything. It’s because no matter what happens you will latch onto it and start blaming it for anything else no matter how unrelated or crazy. You’ll send emails to managers stating “facts” that are just not true, creating more chaos and confusion than if we had said nothing at all.

So we don’t say anything. No matter how big or small of an event.

3. It’s the network

Your DBA is likely the best looking and smartest person in your IT department. But that doesn’t mean that they are omnipotent. From time to time they are not going to have an immediate answer for you no matter how long you stand in their cube tapping your feet and reminding them how much money is being lost for each passing minute that they haven’t solved whatever imaginary problem you are having.

You should have seen it BEFORE we consolidated.

It’s during times like these that the most seasoned of DBAs will reach into for the modern-day equivalent of a “get out of jail free” card by turning their heads, looking deep into your eyes and saying those magical words:

“Looks like it could be a problem with the network.”

This one line is pure gold. It buys any DBA the time they need to investigate the real problem as most folks will walk out of the cube once they believe the DBA is on the trail and closer to finding a solution. And once those people leave you alone to focus on the issue you are likely to be able to find a solution.

And don’t worry about blaming the network. The network admins don’t mind, because they just blame management for not buying the right hardware the first time around. And then management tells the end users they will need to live with the bad performance until the network issues are worked out. It’s the circle of life in IT, and it works.

4. Of course your server is dedicated

Not likely, no it is not. Not only does your database server also run all sorts of other things like anti-virus software and software for taking server tape backups, but chances are it is running other services like SSAS or SSIS. And let’s not forget all those vendors that insist their application be installed on the same server as the database “for performance reasons” which I always found amusing every time we found the performance bottleneck to be the application itself. Good times.

And let’s not forget the price of all that hardware and software. As much as I enjoy having my overall CPU utilization to be less than ten percent if the guys who write the checks find out that we are wasting ninety percent of our capacity then there is a good chance we won’t ever be able to buy anything new and then you’ll have to hear your DBA say things like “this is why we can’t have nice things” each time you ask if your server is dedicated. So, just don’t bother. Your server is a resource and is likely being used by others. Get used to the idea.

5. Yes I gave you the permissions you asked for

Not only do vendors like to insist that their applications are installed on the same server as the database, but they also insist on having full administrative rights. Why are such rights necessary? Quite often, they aren’t, but vendors ask for it because they can. Any good DBA will ask for a list of actions that are needed so that they can grant the permissions necessary for those actions. I once had a vendor tell me they needed full system administrative rights for the database instance AND the O/S because they “had to create tables and stuff”.

DBAs, especially the good ones, know this isn’t true. And so we give you the permissions that you need. Quite often that is different from the permissions that you asked for. And honestly we’re too tired to explain to you the difference because you usually don’t care to understand it anyway.

There you go, five things your DBA has probably been less than truthful with you about. That doesn’t make us bad people. In fact, it makes us more like an adult…say a parent…someone who knows the difference between “want” and “need” and has to make the hard choices that others don’t want to make.