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.

I'm hoping they have enough wine to go with all that cheese.

The announcements came out yesterday and I can now tell the world that I will be presenting at TechEd this year. Denny Cherry (blog | @mrdenny) and I will be doing a precon seminar at TechEd in Orlando in June. 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.

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

I’m making a list of all the things I want to see and do in Amsterdam while there, and I’m putting Van Halen at the top of the list followed by eating a raw herring while wearing wooden shoes and sitting under a windmill.

Look, everyone makes mistakes. It’s true. But not all of us have the chance to make mistakes that end up costing millions of dollars in hardware and production support costs.

Any one of the following five mistakes listed below will add additional costs to your company. It’s guaranteed. The costs could be hardware related (extra disk space, network bandwidth), which tend to add up quickly. The costs are also support related (bad performance, database re-design, report creation, etc.), and they add up very quickly.

Want to save your company some money, some headaches for your end-users, and ensure data quality all at the same time? Then avoid these five database design mistakes.

1. Going BIG, just in case

I often see data types being chosen as if they don’t matter. But the truth is they do matter. If you know that the only possible values for a certain column are between 0 and 100,000 then you don’t need to slap a BIGINT data type for that column when a INT would do just fine. Why does this matter? The BIGINT data type requires 8 bytes of storage, and the INT requires only 4 bytes of storage. That means for each row of data you could be wasting 4 bytes. Doesn’t sound like much, right?

OK then, let’s consider that your table has two million rows. Multiply those rows by 4 bytes and you have 8 million bytes, or roughly 7.8MB of wasted space. I know it doesn’t sound like a lot, does it? Well, it adds up, and quickly. I’ve only shown you an example for just one column, but what about those NCHAR(2000) columns that are storing mostly first and last names? How much extra overhead for those? How about your date columns? Do you have a need for calendar dates prior to the year 1900, or after the year  2079? Then SMALLDATETIME is likely to work just fine for you.Oh, and let’s not forget that these columns can be indexed, and those indexes will also be unnecessarily wider as well.

Choosing the right data type matters, for all sorts of reasons. Take the time and make an effort to get it right at the start.

2. Expecting a DBMS feature to mean the same across all systems

Bigger companies tend to have a variety of systems, all of which need to exchange data. It is quite common to see familiar terms in use by those systems. For example, you are likely to see the use of the term TIMESTAMP. You simply cannot assume that the format of TIMESTAMP will be the same between systems. If you do you are likely to have issues at some point. If you are lucky the issues will manifest themselves early. If you are unlucky the issue will lay dormant until the worst possible time for your system to come to a grinding halt.

What's the worst that can happen?

I chose TIMESTAMP as my example here because it is one of my favorite misnomers inside of SQL Server. Why? Because TIMESTAMP has nothing to do with date or time. And I love this hidden gem inside the BOL:

The Transact-SQL timestamp data type is different from the timestamp data type defined in the ISO standard.

So that means other systems that do adhere to the ISO standard of what it means to be a TIMESTAMP are going to return something vastly different. Take Oracle, for example, and how they define a TIMESTAMP value. Even DB2 has some subtle differences as well. The lesson here is that when you are working with disparate systems, do not assume that familiar terminologies will work in exactly the same way.

3. Expecting database-generated identifiers to be sequential

Being able to insert data into a database in sequential order has many benefits, and most database designers will look to implement some type of mechanism to ensure that such sequences are used. However, many of those mechanisms will leave “gaps” from time to time, and these gaps lead to confusion as people except to see {1, 2, 3, 4, 5…} and not something like {1, 2, 4, 5, 6…}. As soon as a gap is found people send out a search party, looking for the missing data. I know I’ve lost hours trying to track down “bugs” in systems where people thought rows of data were missing, only to realize that the integrity of the data was fine but the method for generating the sequence was not.

Now, for reasons I can’t explain, people just love GUIDs in database designs. One of the (many) issues with GUIDs is that they are not sequential by default. This will lead to decreased performance, often in a very short amount of time. For a great explanation of this in detail, check out this post by Kimberly Tripp at SQL Skills. The part you want to pay attention to is here:

“But, a GUID that is not sequential…can be a horribly bad choice - primarily because of the fragmentation that it creates in the base table but also because of its size. It’s unnecessarily wide…”

Yeah, that *is* what she said.

4. Not examining your foreign keys (FKs) as part of your indexing strategy

I am assuming, of course, that you even have foreign keys defined. I’ve seen *many* databases that have little to no primary keys, foreign keys, or even any indexes defined. No, I don’t know who would do such a thing either. But they’re out there, and sooner or later you will find them, too.

Assuming you have FKs defined then you should be evaluating to see if it would make sense to add indexes to match those FK definitions. In some case, it will. In other cases, it won’t. But you should make certain that this type of review is part of your overall design process.

5. Applying surrogate key without having the original business key as an alternate

Back to those folks who love the GUIDs for a moment. If you are using a surrogate key (and, ideally, one that is sequential) in your database design you should not forget that the data in your table should also have an alternate key based upon the business logic that was used to necessitate the creation of the table in the first place.

Many database designers tend to focus on the surrogate key only, and forget all about the other columns. And this is bad for your data quality, as it would allow for duplicate values to creep into your business layer if you do not put a unique constraint/index on that alternate key. Nobody wants that, trust me.

And there you have it. Avoid these five database design mistakes and save your company money, headaches, and ensure data quality all at the same time.

It’s new, it’s shiny, and it smells like frozen yogurt.

No, it’s not the blender you got for Christmas. It’s SQL 2012 (formerly known as codename ‘Denali’). And it’s here. And you want to use it, you know you do.

As much as you would like to believe that migrating to SQL 2012 is as easy as doing a backup and a restore, the reality is that you need to take some extra steps before letting your end users run amok in SQL 2012 goodness. The last thing you want is for one of them to get in there and report back things like:

“It’s slower than SQL 2008″, or

“When will your team be able to support SQL 2012?”

Nobody wants that to happen to you. Here are the seven mistakes you can’t afford to make.

1. Failing to use the SQL 2012 Upgrade Advisor

The SQL 2012 Upgrade Advisor (UA) is just that: an advisor. It doesn’t fix everything, it merely advises you on what actions you should take when upgrading to SQL 2012. The actions the UA recommends will come in two forms: those actions to be done prior to a migration, and those actions to be completed post-migration. The UA is really good at finding what I call the “stub-your-big-toe” things that need fixing prior to a migration. But it is not foolproof, it will not identify every last detail. You will need to play the role of an actual DBA when migrating to a new version.

2. Not reviewing the “breaking changes” section in the Books Online

Did you know that Microsoft publishes a list of breaking changes for each version of SQL Server? Well, you do now. You should review them to the point that they are familiar to you. You don’t have to memorize them all, just be familiar with them so that if something odd happens you can think to yourself “…hey, is this odd behavior listed in the breaking changes section of the BOL”? I would like to believe that the UA will alert you to many of these breaking changes but the truth is the UA is not as dynamic as the BOL. That means the BOL may have an entry or two that doesn’t make it into the UA checklist, and that is why you should review this section.

3. Skipping the “behavioral changes” section in the Books Online

Similar to the breaking changes, the behavioral changes are changes that could still affect you in an adverse way. They are definitely worth reviewing, and they are also things that the UA is likely to never report back to you about because they aren’t things that *will* break, but merely things that *could* break.

4. Forgetting to execute DBCC CHECKDB WITH DATA_PURITY

One of your post-migration or upgrade tasks should be to run the following statement:

DBCC CHECKDB WITH DATA_PURITY;

This statement will check your data for values that are no longer valid for the column datatype. For databases created prior to SQL 2005 (and you *know* they are still out there), this step is rather important to take. For databases created in SQL 2005 and later, the DATA_PURITY check is supposed to be done automatically with a regular CHECKDB.

But what about a database that was created in SQL 2000, migrated (poorly) to a SQL 2008 instance, and left in the SQL 2000 (80) backward compatibility mode? What about that little feller? Do you want to assume that the DATA_PURITY check has been getting done? Here’s a thought: just go run it yourself anyway. That way you know it is getting done.

5. Ignoring the execute DBCC UPDATEUSAGE command

While not as critical as the DATA_PURITY command noted previously, this one still has a place in any migration or upgrade process:

DBCC UPDATEUSAGE(db_name);

This command will help fix any page count inaccuracies that are resulting in the sp_spaceused stored procedure returning wrong results. And much like the DATA_PURITY check, this command is also recommended for databases that were created prior to SQL 2005. For databases created in SQL 2005 and later, you should only run this command if you feel you are getting inaccurate results from sp_spaceused, and you should note that for very large tables this command could take a long time to execute.

6. Not updating statistics

This one is not to be skipped and is simply a MUST for any migration or upgrade checklist:

USE db_name;
GO
EXEC sp_updatestats;

This command will update the statistics for all the tables in your database. It issues the UPDATE STATISTICS command, which warrants mentioning because you *may* want to use that command with the FULLSCAN option. I’m the type of person that would rather be safe than sorry and therefore would end up running something like this:

USE db_name;
GO
EXEC sp_MSforeachtable @command1='UPDATE STATISTICS ? WITH FULLSCAN';

Bottom line here: don’t forget to update the statistics.

7. Failing to refresh your views using sp_refreshview

Believe it or not, every now and then someone will build a view that spans into another database on the same instance. And, in what may be a complete surprise to many, sometimes these views will go across a linked server as well. The point here is that your view may not be contained in just your database. In what could be the most dramatic twist of all, sometimes these views are created using a SELECT * syntax.

I know, I know…what are the odds that you could have such code in your shop? But it happens. And when you have bad code on top of views that go to other databases (or views of views of views of whatever else some sadistic person built) you are going to want to use sp_refreshview to refresh those views.

So, if you are migrating a database in your environment to a new server then it would be a good idea to refresh your views using sp_refreshview. Most of the time it won’t do anything for you, much like any movie with Stephen Baldwin. But there is that one chance where it will dramatically improve performance and your customer will be happy as a result. It’s like flossing: it doesn’t take much effort, and the end result is usually worth that little effort.

And with the Holiday Season upon us, I leave you with a Christmas Bonus: an eighth mistake you can’t afford to make:

BONUS: Forgetting to take backups

You’re a DBA. Backups are in your DNA. You should have taken one prior to the start of any migration, and you had better take one right before you turn that database over to your end users. Also, you should save any output from the seven items listed above, as it could prove helpful should something go awry later.

There you have it, the mistakes you can’t afford to make when upgrading to SQL 2012. If you haven’t started building up your SQL 2012 migration or upgrade checklist yet, now is the time, and get these seven items included. They will save you pain, I promise.

It’s the end of the year and already I am seeing the usual blog posts that either reflect on the year that was, or are pondering the year to come. I thought about writing another post covering all of the things that didn’t happen to me this past year but since I’ve already done that before I figured I needed to do something different. So I decided on this post instead. You’re welcome.

Here are the 12 things you should stop doing in 2012.

1. Using antiquated technology

The line in the sand for me would be the ages of my children. If your software was written before they were born, I don’t want to be using it. But that measuring stick won’t work forever, so a better one is to make certain you are only at most one full version behind. If you are still running SQL2000 or Oracle9i, you are more than one version behind, and you should really stop. It’s time to move on. Seriously.

2. Responding immediately to every email

Stop doing that. Trust me on this, your response to that email can wait. Don’t believe me? Try an experiment. For one month do not reply immediately to your emails. At the end of the month add up the number of emails you received, and the number of emails that required an immediate response. I’m willing to bet that the number is quite low, much lower than you realize. And once you realize just how few emails require an immediate reply, you’ll never look at email in the same way again.

3. Over-thinking everything

Some things in your life require analysis and thought, no question. But you don’t need to spend 30 minutes ordering coffee at Starbucks. Lots of things in your life are like that coffee, you should be able to just make a decision and move on. But for whatever reason we tend to analyze lots of decisions in our lives that don’t really need any extra analysis.

4. Doing unproductive work

Start tracking your daily tasks and see which ones are the most productive. Chances are you have a few tasks that don’t align with your highest level of goals. If you want to become the world’s best widget-maker then you need to focus on tasks that help you achieve that goal, and spend less time on tasks that don’t help you get there.

5. Pretending that work-life balance exists

It doesn’t. Sorry to be the bearer of bad news, but the idea of work-life balance is a myth perpetuated by HR departments that are trying to recruit you. This is especially true the higher up the corporate ladder you find yourself. And yes, that means if you are self-employed, you are essentially your own CEO, and you don’t just work at home but you also live at work. So stop pretending that any such work-life balance exists, it doesn’t. What you really have is work-life management, and we all know how hard it is to find a good manager these days.

6. Multitasking every possible moment of the day

Would it hurt you to focus on the task at hand for once? You don’t always have to be doing three things at once. Like texting and driving, for example. Remember I told you how that email can wait? Yeah, that is especially true if you are driving. Try living in the moment a few times a day and you may be surprised to see the quality of your output rising as a result of your increased focus on one specific task.

7. Trying to keep up with the Kardashians

…or watching Jersey Shore, or those shows about “real” housewives. If we all just stop watching, there is a chance the shows may disappear altogether. That’s the world I’d like to leave for my children: a world free from crappy reality TV, and reality TV “stars”.

8. Stop arguing with people on the internet

It’s just not worth it, even when they are wrong, and even when they attack you. The internet is a big place, and it is full of opinions. Let people express their opinion. It’s OK. If you really feel the need to inject yourself into a conversation, don’t do it. You won’t win. You can’t win. It’s the internet, and every time you try to get the last word in about something, or try to demean someone because you feel you have been wronged, all it does is make you look a little more foolish than if you had written nothing at all.

9. Resisting the Cloud

Look people, stop making excuses for why you can’t move to the Cloud. It’s here, and people are using it already. That means they are learning lessons about Cloud technology. They are learning what works best for them, and they are ahead of you by doing so. How much longer do you want to wait at the starting line while everyone passes you by? Get in the game now. Find something that you can deploy to the Cloud and put the learning curve behind you, and do it quickly. Otherwise you are going to find your skills are out of date, and quickly.

10. Comparing yourself to others

You’ll never be as good as that other person. It’s true. You will only ever become second-best, because you will always feel they are better than you anyway. It’s a losing effort, so don’t bother. Instead, find out what one or two things you like most about them and see if you can adapt those things to fit your personality or lifestyle. At the end of the day you have to be yourself, but it’s OK if you get some influence and inspiration from others. Just don’t try to be an exact replica because that’s just creepy.

11. Thinking that you need to go it alone

I see this a lot. In fact, I lived it. I thought I was all alone in my role as a DBA. But I wasn’t, because I had a network of colleagues out there willing to help. You don’t need to do anything alone in life, you can always find someone willing to help. Even misery loves company. And whether you are a DBA or the CEO of your company, you don’t have to work in a vacuum, there is a network of your peers willing to lend you a hand. It’s OK to ask for help, to admit that you may have been able to do something better. If your end goal for life is to have “I did it myself” on your tombstone then you should expect a lot of lonely Holiday dinners.

12. Reading blog posts titled “12 Things in 2012″

They’re a waste of your time. Go kiss your children goodnight and read them a story instead.

I figure that eliminating the above items will save me a lot of time in 2012. I have no idea what I will do with the extra time yet, but I’m sure I will think of something before the Mayans attack in late December.

Late last week, while I was traveling to the Confio world headquarters, I received a direct message on Twitter that simply pointed me to this link that I want you to go and read right now:

Done? Good.

Here comes the important part: action. I want you to do three things:

1. Write a #SQLFamily story. It doesn’t have to be a blog post. It doesn’t have to be long. It just has to be.
2. Send your submission to sqlfamilysubmission@live.com. If you posted to a blog, send a link to that blog post.
3. There is no third thing, you are done already, see how easy this is?

It’s a very easy way for you to help make a difference for someone else.

Go. Write. Now.

It seems that everywhere I turn these days I am either reading or hearing about how the new SQL2012 licensing changes are the worst thing since Windows Vista, and possibly since Microsoft Bob.

Well I am here to tell you that things could always be worse. How so? Check out this blog post regarding Oracle and their costs:

http://smarterquestions.org/2011/12/oracle-imposes-oppressive-maintenance-costs-on-sun-hardware-clients/

So, your three takeaways from that article are this:

1. Oracle
2. Oppressive
3. Costs

The more I get to see of Oracle’s licensing and how they nickle and dime you for everything reminds me of how airlines operate, or even Hootsuite.

I’m happy with how Microsoft is doing their licensing, but that’s also because I don’t run a data center and have to buy licenses, or Software Assurance, or, well…anything. But I am also aware that in about ten years none of this will matter because it will be all-Azure, all the time.

Get used to the changes people, there’s still more of them to come.

And be thankful you aren’t writing multiple checks to Larry Ellison every few weeks.

It’s Thanksgiving week here in the USA. I have two things I want to mention.

First, last Wednesday I did a product demo for Confio Software, you can read more details about that inside my post title Help Me To Feed Others. We raised close to $1,000 for Community Food Share, which will help to feed many families this week. I could not be happier to know that I played a part in making that happen. Thank you for attending and helping us last week.

Second, after hearing that Congress has declared pizza to be a vegetable, it struck me that as a DBA we need our own “food plate“. Why would we need this? Simple:

Many people have no idea what a DBA does for daily work.

Sadly, most new DBAs also have no idea what they are supposed to be doing, and no mentor to help them along the way. This is especially true in Microsoft shops, where the installation and use of SQL Server is so easy that many forget the fact that you need someone to administer what has been installed.

So, I decided to borrow the “food plate” idea and apply it for DBAs.

Everything is there, really. Backups should be the biggest part of your plate, followed by maintenance. Monitoring and tuning come next, and you should have a side plate of training as well. I hope this clears up everything. What’s that? You need more details? OK then, how about this…

Backups

The number one responsibility for any DBA is the ability to recover. If you cannot recover you should find a different career. And that word (“recover”) can mean a lot of different things. It could be your ability to recover as the result of a large scale disaster. It could be your ability to recover the piece of data that was updated inside of one row, in one table, in one database, in some obscure instance of SQL hundreds of miles away. And it could also be everything in between those two events.

And you can’t do any of that without having backups in place, having them running in a consistent manner, the ability to check that they are running, and even testing that they are valid by doing some periodic restores.

Backups: It’s what’s for DBA dinner.

Maintenance

This part of your plate is for things like the rebuild/reorganizing of indexes, or the updating of statistics. Essentially, anything that helps to maintain the current performance levels for your end users are what I consider to be “maintenance”. However there is also administrative maintenance, such as the removal of logins that are no longer used, or running DBCC CHECKDB.

Monitoring

This part of your plate is for the items you want to be alerted and take action upon. For example, running low on disk space, or seeing a spike in CPU utilization, or having one of your SQL Agent jobs fail. As a DBA we are keen to collect all sorts of details about our instances and databases because we never know which particular piece of data is going to help us diagnose and resolve an issue. But you should only collect the pieces of information that help you to take action. If you try to monitor everything possible then you may find that the biggest performance impact on your system is yourself!

Tuning

This part of your plate is when you roll up your sleeves and make adjustments to your instances in some way. Tuning could be the rewriting of T-SQL statements, it could be adding memory to a server, or even the partitioning of data to align with tiered storage. In essence, anything that goes beyond the traditional maintenance tasks is what I would consider to be tuning.

Training

This is the little side plate to everything else that you do. Think of it like having a few strips of bacon with your meal. You need to be constantly keeping up to date with the latest trends in technology. Most of this training is a lot of self-help, but you can also attend events such as SQL Saturdays or the PASS Summit. Just make certain that you reinforce whatever you have been taught by taking the time to lay your hands on the product or piece of functionality.

Happy Thanksgiving.