March 10, 2013 at 11:17 am
After moving databases from 2005 to 2008, do we need to do run any queries (like update usage which we do in 200o to 2005).
I will change frm 90 to 100 after necessary precautions. aything else i am missing?
March 10, 2013 at 11:29 am
run updateusage and sp_updatestats
---------------------------------------------------------------------
March 16, 2013 at 10:16 am
ok i would run
Integrity check
dbcc updateusage
sp_updatestats
90 to 100
Is that all?
March 16, 2013 at 10:44 am
if it is a side by side upgrade check the database owner is still what you want.
other than that thats all that is required as part of the process, I presume as the database was already 2005 page_verify is set to checksum and backups and reindexes will follow in the fullness of time.
---------------------------------------------------------------------
March 16, 2013 at 9:04 pm
A silly question if u may say. for 2005 to 2008 upgrade, should i run 2008 upgrade advisor on the 2005 server?
Does the advisor has to be downloaded (only way?) or is it already there in the installation disc?
March 17, 2013 at 4:14 am
balasach82 (3/16/2013)
A silly question if u may say. for 2005 to 2008 upgrade, should i run 2008 upgrade advisor on the 2005 server?
Always best to.
Does the advisor has to be downloaded (only way?) or is it already there in the installation disc?
you need to download it
---------------------------------------------------------------------
March 17, 2013 at 6:10 am
This may be a silly statement, but your question suggests you aren't testing the migration before you put it into production. If that is the case then you could be making a mistake and not using some of the newer T-SQL to its fullest advantage. My steps would be the following:
1. Import the existing production database into a SQL Server 2008R2 using detach/attach or a full restoration but retain the compatibility level of 90 to begin with
2. Update statistics and usage
3. Check to make sure the database does exactly what it is supposed to do
4. Examine query statements to see if they can be optimised to take advantage of T-SQL enhancements. For me, the MERGE statement proved one of the most significiant improvements
5. Backup the test database in compatibility level 90
6. Promote the test database to compatibility level 100 and test thoroughly
7. Once successful, move the database to the production environment.
The most important thing to remember is do not perform this test migration just once but rather as often as your allocated time allows. The statement that make most sense here is this:
"The amateur practices until he gets it right. The professional practices until he doesn't get it wrong."
This means you really have to practice as often as you can. Use your documentation that you produce at each test phase practice and amend if required, accordingly.
DO NOT use luck as the means to see if the migration is going to be successful!
March 17, 2013 at 11:10 am
Yes. No Testing is sure way to go down. There would be a battery of testing before the final move.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply