Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 41
  • Last Modified:

SQL 2005 to 2012 Migration Question

All,

I have done a number of migrations in the past but mostly same versions, I am looking into a project that will require I migrate 16 database servers from single instance (Physical Server) 2005 into a single virtual server running named instances and using SQL 2012.

I need to migrate the db's including the system db's which hold the log in's and permissions.  Is there a best practice or step by step procedure I can follow to accomplish this?

And before anyone is concerned about iOPS this is a SSD Array all DB certified SSDs :)

Thanks!
0
smyers051972
Asked:
smyers051972
  • 10
  • 3
  • 2
1 Solution
 
ZberteocCommented:
You can't migrate the system databases and you should never think of that. If you have to migrate the jobs and logins by scripting them out on source and execute the scripts on destination.

Migrate jobs with transfer job tasks. In MS under Management node right click on Maintenance Plans > New Maintenance Plan > in the Tools panel on the left grab the Transfer Jobs task and drag it to the designer panel and then go into its properties to setup the job migrations:
http://technet.microsoft.com/en-us/library/ms137568.aspx

for logins scripting:

http://support.microsoft.com/kb/918992
0
 
smyers051972Author Commented:
How about all the DB Permissions?
0
 
ZberteocCommented:
You do this:

1. Script logins on 2005 server and then run the script on SQL 2012
2. Backup databases on 2005 and restore on 2012
3. Synchronize the logins with the databse users with:
USE database
GO

-- lists the orphaned users in the database
EXEC sp_change_users_login 'REPORT'
GO

Open in new window

all the users reported above you will fix with:
-- fixes one user - login orphan probloem: 
-- EXEC sp_change_users_login 'UPDATE_ONE', 'db_user', 'login'
EXEC sp_change_users_login 'UPDATE_ONE', 'user', 'login'

Open in new window

only SQL users will be reported and need this fix; details about user-login sync here: http://technet.microsoft.com/en-us/library/ms174378.aspx

3. Migrate the jobs.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
smyers051972Author Commented:
perfect ill try this Sunday and report back! Thanks! I assume this will be the same after adding the named instances as well?
0
 
ZberteocCommented:
Correct.
0
 
Jim P.Commented:
Here is one that you may want to see about doing is building you own maintenance plans that runs from a query window. That way when you have to move or add another SQL Server, you can just use the script to create the new jobs.

The sp_helprevlogin as ZB noted above is the best way to move logins. I also add a job
to any SQL Server and automatically run it every 8 hours and dump it to disk to be backed up.  That way if the SQL Server instance crashes, I can just re-install the SQL Server from scratch. Restore the databases and then use the scripts to recreate the jobs and logins.

Another suggestion that will make DB moves easier in the future. If you have access to the DNS system create a CName record that is like DBName that points to the ServerName or IP. Even if the DB is a named instance such as ServerName1\InstanceNm have it point at the DBName\InstanceNm. The reason for this is that if the clients  are using DBName\InstanceNm and the original server should crash for some reason, all you have to do is restore the DB to ServerName2\InstanceNm and then change the DNS record and not touch the clients. It will also allow you to move a single DB at a time instead of having to do all five at one time and touching every client.

Just some tips that I have picked up over the years.
0
 
smyers051972Author Commented:
@Zberteoc:

I Ran the first part of the script on the 2005 server and get an error that it could not locate the stored procedure.

Here is what you said to run:
USE database (Assumed MASTER DB)
GO

-- lists the orphaned users in the database
EXEC sp_change_users_login 'REPORT'
GO
0
 
smyers051972Author Commented:
I also found this article but it mentions moving sql 2005 -> 2005.

http://www.techrepublic.com/blog/how-do-i/how-do-i-transfer-logins-from-one-sql-server-2005-instance-to-another/#.

I also learned that we are using 2008 as the destination not 2012 as originally thought out.
0
 
smyers051972Author Commented:
ok so I am importing the db everything there going well when I export the users on the old server and import the domain users i.e. domain\user seem to not be found?
0
 
Jim P.Commented:
Is the new SQL Server in the domain?

What userid are you using to run the SQL Server services? If it isn't a domain user id it can't really query the AD easily.
0
 
smyers051972Author Commented:
New server, its in the domain but you know what I am running them all as local service accounts... maybe this needs to change lol
0
 
smyers051972Author Commented:
This is still open as a project sorry for it not being closed yet.
0
 
smyers051972Author Commented:
This is still an open project
0
 
smyers051972Author Commented:
Project was put on hold 2 weeks ago but will be resuming shortly.
0
 
smyers051972Author Commented:
Good answer
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 10
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now