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.

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.

I hear it all the time. It’s a familiar refrain. Most of the time it is innocent enough, and understandable. But there are times when hearing those words are like hearing the screech of fingernails on a chalkboard:

“We can’t change the code.”

There you are, listening to someone complain to you about the database server, and wanting you to fix the problem. You examine the situation and can see an easy code change that would improve performance immediately only to be told “no code changes allowed”. Your heart sinks. You get frustrated that they won’t make any code changes. The user gets frustrated that you don’t have any other options to offer. You ask about changing a stored procedure, or rewriting a view definition, or helping to redesign a few tables from the ‘database’ that is nothing more than an Excel spreadsheet. “No”, “no”, and “no” you are told, along with “stop blaming the code, you always blame the code!”

You are at an impasse. You wish you had a handy list of things to try.

And now you do.

Here are six ways you can improve database performance without changing code, listed in no particular order. They have different levels of difficulty but they all have something in common: no code changes necessary. And your end user will be happy that you can provide them some options.

1. Utilize a proper indexing strategy

I know I said “no code changes”, but indexes are more of a schema change than a code change. And unless you have code that utilizes index hints, you shouldn’t have to worry too much about needing to change code to avoid using an index.

There are more than a handful of blogs out there that talk about missing or unused indexes. I will point you to the MSDN article on how to find missing indexes, as that is likely to be the most useful for you. I will also give you this caveat: adding indexes is not always the right thing to do! You need to be aware of all the activity hitting the underlying table. If you decide to create an index to improve a specific query run monthly to generate a report, you could be doing a disservice to the hourly DUIs (Deletes, Updates, Inserts) that are happening. Be aware of the overall usage before you just start adding indexes for performance.

As for eliminating unused indexes, I would caution you there to make certain you know that the index is truly not being used. If you have been looking at index usage for the past week and find a few hundred that haven’t been touched, don’t go around dropping them because they could very well be used on a monthly basis. Again, know the system and workloads a bit before making these changes. One thing you are likely to be able to do right away is to remove duplicate indexes.

A proper indexing strategy would involve the periodic investigation into finding indexes that are missing, that are duplicates, and are unused.

2. Add memory

Everything SQL Server does *has* to go through memory. Every query you run *has* to read/write pages from/to memory. So why not make certain you have enough memory on your server in order to store as many pages as possible? No, I can’t think of any reason either.

Here’s a link to MSDN that will get you started on memory architecture and proper memory configurations for SQL Server. I’ve seen cases where people have purchased extra memory but failed to configure SQL Server to take advantage of it properly. Don’t be one of them, spend a few minutes to read up on things and make certain you have an idea about what you are doing.

If your server memory settings are already configured properly for SQL then consider purchasing more. Usually swapping in new memory is an easy enough process, and in some cases can be done on the fly without the need to restart the server.

3. Check your Windows Power Plan Settings

Were you aware that your CPUs may be only operating at half of their designed speeds? Well, you are now. Of course this means you need to decide what is more important: the perception of being ‘green’ or not having your users standing in your cube complaining about bad performance. Sure, the idea regarding Windows Power Plans is a good one. I won’t argue that. But for database servers it can be a real detriment to performance. If your company has a policy of enabling the power plans by default, you should have them revisit that policy for the database servers. The amount of power savings you get is often not offset by the performance loss.

You can find a copy of CPU-Z for download here.

4. Optimize your tempdb for performance

This one is often overlooked as most folks wait around for a problem with tempdb performance before thinking about how best to optimize it for performance right from the start. This SQLCAT link mentions this as well, and there is info over at MSDN that you should review before making changes. And yes, you should consider moving tempdb to it’s own dedicated set of drives.

In fact, I would tell you that the placing of data files, log files, backup files, and tempdb onto separate disks should be a part of any standard database server build. I emphasize the ‘should’ because for some odd reason I still see shops where this is not true. If that is the case for you, and you need to boost performance, then roll up your sleeves and get started on the work that should have been done from the onset. Speaking of which…

5. Using distinct disks for data files, log files, and database backups

Stop putting everything you have onto one drive. It’s typically a bad thing to do for performance, and an even worse thing to do in terms of disaster recovery. And don’t think that putting six disks into a RAID5 array and then assigning three logical partitions is going to solve your performance (or possible disaster) issues, either. Drives fail, that’s what they all do eventually. And when they do you won’t want to have all your eggs in that basket.

Here’s a list of goodness from SQLCAT regarding best practices for SQL Server storage. Chances are you will find a handful of things on that list that will help with your performance.

6. Get faster disks, like really fast disks

As long as we are talking about disk configurations I might as well mention that you could upgrade to use solid-state disks (SSDs). They’re fast, and getting cheaper with each passing day. So if you are planning on monkeying around with your disks anyway, now would be a good time to see if purchasing some SSDs would make sense for your shop.

Just don’t forget to put your data files, log files, and database backups on separate drives. We’ve talked about this already, remember? Disasters happen, that’s why they are called disasters. Don’t by one big mack-daddy SSD and toss everything on there because you have performance to spare. And if you decide to do that anyway, get a head start on updating your resume now as well.

And there you go, six options for improving database performance without changing code. Look, I never said they were going to be easy, or cheap, or fast…just that you had some options.

Saw this review today and wanted to share it with everyone here:

http://www.mikefal.net/2012/01/03/dba-survivor-learning-how-to-rock-out-with-databases/

I’m touched that Mike would take the time to write such a wonderful (and unsolicited) review of “that little book” I wrote almost two years ago now. I’d like for you to read his entire review, but I am going to share his last paragraph with you here:

“Now many folks probably think this is just a book for the junior DBA, for someone who’s just getting started, but I know this book has value for data professionals of all levels. This book is not a detailed guide or roadmap for solving specific problems, but a series of highway sign posts to get people headed in the right direction. Maybe you are a fresh DBA, looking to get in to the industry or just survive your first week on the job. Or maybe you’re like me, a career DBA who is looking to refocus my career and looking for that “big picture view”. No matter how you got here, DBA Survivor is an excellent starting point for the rest of your database career.”

The holiday shopping season may be over, but my book would still make an excellent gift at any time of the year (yes, that *is* my opinion, thankyouverymuch).

Thanks Mike, next time I see you the bacon is on me!

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.

I’m starting to think these folks had a little too much fun putting these clips together.

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.