July 30, 2012 at 2:48 pm
Plan to upgrade (side by side) v. 2000 to 2008 R2 and set compatibility level to 90 (not 100) - all application work done by vendor who has agreed to support this initiative.
Use backup & restore to new W.2008 server.
Any issues with this ? Or experiences to share ? Appreciate any feedback.
TIA
🙂
July 30, 2012 at 3:02 pm
Why 90 and not 100? The biggest issues you face are going from 2000 to anything. If you are going to go through the trouble of identifying what is different between 2000 and 2005, why not just do it for what you paid for?
Jared
CE - Microsoft
July 30, 2012 at 3:20 pm
SQLKnowItAll (7/30/2012)
Why 90 and not 100? The biggest issues you face are going from 2000 to anything. If you are going to go through the trouble of identifying what is different between 2000 and 2005, why not just do it for what you paid for?
Agreed
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 1, 2012 at 8:17 am
TX - agree just that 90 is the min. comp level for future upgrade to 2012. If our vendors can do it why not ?
Any experiences to share here or pointers for what to look out for from the trenches ?
TIA
🙂
August 1, 2012 at 11:37 am
BEFORE you move off of SQL 2000 run these against the databases. If there are any errors do NOT backup/restore to SQL2008, fix the errors first.
DBCC CheckCatalog
go
DBCC CHECKALLOC
go
After you backup/restore to SQL2008 run the DBCC UPDATEUSAGE(0, N'dbo.tablenamehere') on ALL tables in the database.
Then rebuild ALL indexes on ALL tables so the optimizer will see all of the indexes in the SQL2008 optimizer. Once that is done run a DBCC CHECK DB on the database to make sure there is no corruption at all, then do a db backup so you have a good SQL2008 Recovery point before you open it up to testing and customers.
August 1, 2012 at 9:32 pm
2000 would use Torn_page_detection to check IO level corruption. Better change it to Checksum.
August 3, 2012 at 9:59 am
Much appreciate the advice. Keep it coming folks !
🙂
August 3, 2012 at 10:17 am
dbasql79 (8/1/2012)
2000 would use Torn_page_detection to check IO level corruption. Better change it to Checksum.
+1
Do this before rebuilding the indexes - IIRC, checksums are only written when the data/index page is updated.
Rebuilding the indexes should ensure checksums are created for all your data.
I'd recommend setting Compressed Backups as the default & switch on 'Optimise for Ad Hoc Workloads' option, but they're not really upgrade considerations 🙂
Have you run the Upgrade Advisor to check your SQL is compat-90 valid? Or is that the application vendor's problem?
Cheers
August 3, 2012 at 10:25 am
Definitely use the upgrade advisor. Watch out for older scripts that check system tables as many of them have changed.
I assume you are doing a test upgrade, but please make sure this is done on another machine. Upgrades in place are tricky, and can leave you stuck. Make sure you have good backups (2 copies) and enough time to reinstall SQL 2K if something goes awry.
August 3, 2012 at 12:50 pm
Have generated Upgrade Adv. reports for 2008 and sent off to the vendors.
Backup restore is the approach from current win. 2003 to 2008 server.
Any 32 bit to 64 bit stuff I need to care about during this process ?
🙂
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply