April 25, 2005 at 10:57 am
due to performance issues (high CPU%), we are migrating to a new Server. I currenltly have 13 DB's plus system DB's (Master, model, msdb) on old box. In order to move to new box, here is my plan:
1- kick everyone out of the pool
2- do a few row counts on Master and coupla DB's for a "before" count
3- backup (full) all DB's
4- migrate b/up data accross network to new RAID
5- restore sys DB's (Master first)
6- restore other DB's
7- row counts from #2 for comparison "after" count
Am I missing anything? my user/login info should be OK since I will restore Master, yes?
April 25, 2005 at 2:51 pm
April 26, 2005 at 3:54 am
That link says it all really!
(i) Be careful with collations. We've had tempdb problems with migrated dbs when the Server and db collations differ. (SQL_Latin1_General_CP1_CI_AS vs Latin1_General_CI_AS). This may happen if you are migrating from SQL 7 to SQL 2000 or even from a SQL 2000 box upgraded from 7 to a vanilla 2000 install. tempdb will retain the original collation even though you have restored the system dbs.
(ii) The restore of master should take care of Windows groups & Windows users but.....I would not be too surprised if you end up dropping and recreating these.
(iii) You'll have to do a nasty fix on msdb..sysjobs to get SQL Server Agent jobs to work. It's safer to script them out.
UPDATE sysjobs SET originating_server = '{new server}'
Good luck!
April 26, 2005 at 3:58 am
Also, the SQL Enterprise Manager 'Generate SQL Script' tool is damn good! I would definitely use this even if you only use the generated scripts as backup (e.g. to drop & recreated logins & usernames).
April 26, 2005 at 6:03 am
yep, the link to MS Support just about covers it.
I would have missed the orphaned user bit, even though we went over that in 2072 class a month ago.
Thanx All!
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply