Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Upgrading/moving datbases frm 2005 to 2008 Expand / Collapse
Author
Message
Posted Sunday, March 10, 2013 11:17 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, July 25, 2014 9:34 AM
Points: 389, Visits: 959
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?
Post #1428996
Posted Sunday, March 10, 2013 11:29 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 3:15 PM
Points: 5,976, Visits: 12,886
run updateusage and sp_updatestats

---------------------------------------------------------------------

Post #1428997
Posted Saturday, March 16, 2013 10:16 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, July 25, 2014 9:34 AM
Points: 389, Visits: 959
ok i would run

Integrity check
dbcc updateusage
sp_updatestats
90 to 100

Is that all?
Post #1431910
Posted Saturday, March 16, 2013 10:44 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 3:15 PM
Points: 5,976, Visits: 12,886
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.


---------------------------------------------------------------------

Post #1431915
Posted Saturday, March 16, 2013 9:04 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, July 25, 2014 9:34 AM
Points: 389, Visits: 959
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?
Post #1431957
Posted Sunday, March 17, 2013 4:14 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 3:15 PM
Points: 5,976, Visits: 12,886
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


---------------------------------------------------------------------

Post #1431969
Posted Sunday, March 17, 2013 6:10 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, July 15, 2014 6:13 AM
Points: 307, Visits: 475
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!
Post #1431974
Posted Sunday, March 17, 2013 11:10 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, July 25, 2014 9:34 AM
Points: 389, Visits: 959
Yes. No Testing is sure way to go down. There would be a battery of testing before the final move.
Post #1432004
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse