Академический Документы
Профессиональный Документы
Культура Документы
Its new, its shiny, and it smells like frozen yogurt. No, its not the blender you got for Christmas. Its SQL 2012 (formerly known as codename Denali). And its 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: Its 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 cant afford to make.
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? Heres a thought: just go run it yourself anyway. That way you know it is getting done.
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.
3
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. Im 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';
Youre 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 cant afford to make when upgrading to SQL 2012. If you havent 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.
Aaron Bertrand : 2 years ago Two I'd like to add to your list, as we discussed on twitter: (1) if you are on x86 hardware, and especially if you are using more than 4GB of RAM today, it might be time to make "move to modern hardware" one of your essential upgrade steps. SQL Server 2012 will no longer support AWE, so this means that no matter what edition you're using and what your boot settings are, SQL Server will only be able to see 4GB of RAM. Obviously this can have quite a dramatic impact on your workload if you're not expecting it. (2) if you are on SQL Server 2000, you will need to upgrade in multiple steps, since a direct upgrade path to SQL Server 2012 will not be supported (regardless if your plan is to upgrade inplace, or side-by-side using backup/restore, log shipping, detach/attach, what have you). You will need to either (a) upgrade the 2000 instance to 2005, 2008 or 2008 R2 or (b) first backup/restore or attach/detach from 2000 to 2005, 2008 or 2008 R2. Only then will you be able to proceed with your normal upgrade/migration plans.