最近我们网站新增了一台数据库服务器，需要将现有的主要数据库迁移到新服务器上。
现有的这台数据库服务器装的是SQL2005。考虑到SQL2008已经出来很久了，想必已经比较成熟，功能又比2005强，据说2005是个过渡产品，趁现在是台全新的服务器，索性安装SQL 2008，不然以后再升级可能更麻烦。
2008肯定可以兼容2005，问题是，我们除了这台主数据库，还有好几台辅助用的数据库，它们全都是2005，并且要使用主数据库的部分数据。现在主数据库升级为2008，其他的还能正常使用吗？
花了一些时间进行测试，发现2005和2008可以协同使用。除了用2005的SQL Server Management Studio去连2008不行以外，其他并没有什么问题，程序没问题，链接服务器（2005连2008）也没有什么问题。
现在是怎么个迁移法？
我想到的有两种方案：第一是备份数据库，然后在新服务器还原；第二是停掉数据库，直接拷贝数据文件到新服务器，然后在新服务器附加。
因为数据库文件太多太大了，备份还原显然不现实，耗时太长。第二种主要是附加的时候，原先各种数据文件放得很乱，没有什么章法，可能附加的时候要稍为改一下路径。
无论是备份还原还是附加数据库，都有个问题，就是原先的数据库用户怎么办？比如权限、密码等等。我们的权限甚至细分到每个表的每个字段，如果手动重新建一遍，即使没有遗漏也会累死。
用脚本搞定：
1、 脚本一，建立登录名
CREATE LOGIN [ 登录名 ] WITH PASSWORD = N' 密码 ' , DEFAULT_DATABASE = [ 默认数据库 ], DEFAULT_LANGUAGE = [ 简体中文 ], CHECK_EXPIRATION = OFF , CHECK_POLICY = OFF
GO
用SQL Server Management Studio创建的这个脚本，里面的密码加了密，结果跑到目标服务器运行之后，用原先的密码登录根本不行。也不知道怎么处理，所以要手动将脚本这里的密码改成明文。
另外，用SQL Server Management Studio创建的脚本，后面还有一句：
ALTER LOGIN [ 登录名 ] DISABLE
会自动将该登录帐号设为禁用！不知道是何居心！所以这句也要去掉。
2、 脚本二，将数据库用户映射到登录名
主要语句是
EXEC sp_change_users_login 'update_one' , [ 数据库用户名 ],[ 登录名 ];
因为我们数据库用户比较多，所以写了个游标
use [myDb]
go
DECLARE curT CURSOR FOR SELECT Name FROM sysusers WHERE Name LIKE 'myUser%' ;
DECLARE @User VARCHAR ( 50);
OPEN curT ;
FETCH NEXT FROM curT INTO @User ;
WHILE @@FETCH_STATUS = 0
BEGIN
EXEC sp_change_users_login 'update_one' , @User , @User ;
FETCH NEXT FROM curT INTO @User ;
END
CLOSE curT ;
DEALLOCATE curT ;
更新全过程：
1、 机器买回来，装操作系统，装SQL2008
2、 机器送到机房，上架
3、 挑一个良辰吉日，夜半无人，停掉网站，停掉主数据库
4、 拷贝数据库文件到新服务器
5、 在新服务器附加数据库文件
6、 依次运行脚本1、2
7、 开网站，OK
后记
切换成功以后，我陆续在一些辅助数据库服务器上升级SQL2005到SQL2008。第一台，数据量不大，访问很少，升级成功，没什么问题；第二台，因为访问量非常大，结果失败，整个数据库引擎和实例都没有了！提示什么文件或卷标名错误！只好卸载所有的SQL,然后直接装SQL2008，幸好数据库文件还在，没出什么乱子。
另外，将SQL2005升级到SQL2008，数据库是停止工作的，我后来才发现，不是什么在线。
再有就是作业的迁移。从老数据库中生成作业脚本，粘贴到新数据库中运行。有些不成功，提示：
不能将值 NULL 插入列 'owner_sid'，表 'msdb.dbo.sysjobs'；列不允许有 Null 值。INSERT 失败。
这是因为作业的所有者不同所致。比如，老数据库中作业的所有者，在新数据库中不存在，就会出现这种错误。换成sa一般都可以。
注：安装SQL2008的时候，需要先安装.NET FrameWork 3.5。我们机器全都装了3.5,上面的SQL2005能访问2008,不知道是不是跟这个有关系。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/leftfist/archive/2010/01/20/5217816.aspx
