一、目的
之前在博文SQL Server数据库最小宕机迁移方案中提到了使用了完全备份+差异备份的功能完成了数据库的转移,但是这个方法在遇到了700多G的数据时显然不适用,所以这篇中我是如何迁移700G的数据库到新的服务器的。
二、分析与设计思路
(一) 环境描述
我们的数据库使用了SQL Server 2005的,部署在Windows Server 2003 x86位操作系统上,有一个表占了这个数据库大部分的空间。
面对上面的情况,我们的数据库压力比较大了,所以我们打算在同一个集群中找另外一台机器,转移这个数据库的数据过去,通过设置新服务器的一些参数来达到优化这个数据库的目的。
(二) 数据分析
在拿到一个数据库的时候,我们应该查看这个数据库相关的信息,在了解了数据库的情况和参数之后再做出初步的评估,比如我们需要知道这个700G的数据库中那些表占用了多少空间,索引占了多少空间(有一个SQL可以直接查看到这些信息),是否做了表分区。
了解参数的时候可以看看服务器硬件信息,比如内存、硬盘、是否做了RAID策略、什么操作系统、数据库的版本、内存的压力、CPU的压力等等信息。了解这些信息是我们决定是否迁移到新的服务器的重要因素。
如果决定了进行数据迁移,那么为了不影响我们的生产的数据库,让生产数据库还能进数据,我们一次要搬多少条记录才是合适的,这个我们也是需要计算的。(搬迁的Job尽量让时间间隔大点,如果前一个Job还没有执行完的话,后一个Job即使到了时间也是不会执行的。)
(三) 设计思路
1、创建一个表。这个表用来保存我们一次需要转移的多少数据的ID值;(这个ID是我们要迁移表的主键,自增字段)。那我们需要一次性迁移多少数据呢?这个我们可以通过计算比如1000条记录有多少M,一次传输对局域网的压力大嘛?最好让ID是一个整千或者整万的整数,这样方便记录和查看。
2、创建一个服务器对象-链接服务器。这样就可以读取到其它服务器上的数据库了,可以进行数据搬迁了(注意这里需要设置链接服务器的帐号和密码)
3、创建一个存储过程。用于读取、控制转移数据,这存储过程需要比较智能一点,它需要解决下面缺陷中提到的几个问题。
4、创建一个Job。这个Job就调用这个存储过程,不过需要尝试多几次调用的频率问题。
三、参考脚本
下面列出一些重点的sql,供参考。
--1.1 创建表
|
--1.2 插入数据
|
--1.3 测试
select * from Temp_MoveManage |