July 17, 2009 at 12:08 am
hi,
we are moving our production databases to another machine(server). what should i take care(from the sqlserver side)?
thanx,
🙂
July 17, 2009 at 2:02 am
Things should be ok depending on how you are doing this
- Backup/Restore?
- Detach on SRV1 and attach on SRV2.
Once restore you make need to fix the logins using sp_change_users_login.
User exists on new server:
EXEC sp_change_users_login 'Auto_Fix', 'user'
Create user:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
July 17, 2009 at 7:07 am
Just be utterly paranoid. Take a backup before the move. Take a new backup after the move from the new server. Keep both on the side for a few days, just in case.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 17, 2009 at 7:14 am
dba-vb (7/17/2009)
we are moving our production databases to another machine(server). what should i take care(from the sqlserver side)?
Do it twice, a test run then a go-live one.
During the test run document every single step, takes notes and timing -that would help during go-live run.
Don't do your go-live until business tests and approves the test run migration.
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.July 17, 2009 at 7:21 am
Oh, and run a consistency check before the migration and after the migration. Paranoia...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
July 17, 2009 at 7:27 am
Grant Fritchey (7/17/2009)
Just be utterly paranoid.
Paranoid is what keeps databases available, recoverable and performing beyond SLA 😉
_____________________________________
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at Amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply