Upgrading/moving datbases frm 2005 to 2008

  • 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?

  • run updateusage and sp_updatestats

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

  • ok i would run

    Integrity check

    dbcc updateusage

    sp_updatestats

    90 to 100

    Is that all?

  • 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.

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

  • 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?

  • 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

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

  • 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!

  • 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