如何迁移700G的数据库到新的服务器

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

关于数据迁移，因数据量特别大，而且一般情况下，每个文件夹有自己的权限设置，有些管理不好的甚至有好多层子文件夹包括文件的权限设置。如果直接拷贝的话，一是出错的概率很大，第二权限本身也无法复制到新的服务器上。

　　这里有几种方式能比较好的解决这个问题：

　　1用老的XCOPY命令，加上合适的参数，可靠性比较高。可通过内网或者用其它介质当中介复制。

　　2用同步软件，通过网络将所有文件同步到新文件夹上。微软自己也出过这种小工具。这种方法可靠性也不高，出错的概率大。

　　3经过实践最方便可靠的办法，用VERITAS BE对老的相关文件夹做全备份，然后在新的服务器上装BE AGENT, 然后用这个全备份恢复，重定向到新的服务器上。这种方法操作起来比较简单可靠。

这些都是小鸟云工程师告诉我的，建议你可以试试小鸟云

NTFS权限跟着走

命令

　　robocopy d:\work e:\back /e /copyall

　　 [参数讲解]

　　/copyall等于/copy:datsou，表示将所有源文件夹的信息复制到目标文件夹中，其中D：文件数据，

A：文件属性，T：时间信息，S：权限信息，O：所有者信息，U：审核信息。

/e表示复制所有子目录包括空文件夹

服务器虚拟化的数据类型对数据迁移的影响重大。通常来讲，非结构化数据更易于迁移，通过文件系统复制或备份恢复就能够渐进完成迁移过程。　　而结构化数据的处理就很棘手：类似于数据库这样的数据类型通常一直处于使用状态，因此渐进式的迁移过程就难以实现。　　大多数情况下，任务关键数据库往往配置为高可用集群。而在这种情形下，虚拟单个数据库集群结点，创建单个客户集群主要有这样两个考虑：　　如果你的hypervisor提供支持，你需要设置规则防止客户节点宿主在物理主机上，否则主机失败理论上可能导致数据库失败。尽管数据库节点能够处理不同hypervisor的节点失败，但这样做你将有更大几率保持数据库在线。　　数据库故障恢复节点鲜少会存储数据本身。这些节点通常会关联到一个集群共享卷，你需要处理这些数据。你可以把数据存放于原有位置，但必须考虑到hypervisor的一些专有限制。

关于更换或者迁移域服务器:关于域服务器迁移的请教我通过部署一个简单的域管理公司40台左右的机器。域的作用主要是通过域用户来管理客户端，回收大部分的权限，使客户端系统非常稳定！整个域系统已经用了快4年了。另 外域服务器还兼任文件服务器，授权和设置了共享文件目录，让客户端可以通过这些共享目录交流和保存信息。现在公司购置了新的机器，需要将现在旧的域服务器迁移到这台新机上，旧的机器另有用途，我在考虑如何做才能让客户端受到的影响最小！先讲一下我现在的网络系统架构：ip段：192168760 2552552550DNS：1921687621DC(old)：1921687621我想的迁移办法是：1先在新机上装好dc(new)：19216876312在dc(new)上设置dns指向1921687621，然后作为DC(old)的额外域建立域，将dc(new)的域信息复制过来，然后配置dc(new）的dns中的ad zone，将dc(old)的dns资料也 复制过来，使dc(new)完全成为dc(old)的冗余备份！3将dc(old)的域正常卸载，让dc(new)承担起域的管理以上只是我以现有知识的设计方案，还没有实际实践，所以想请教几个问题：1dc(old)正常卸载后，dc(new)是否会自动管理起整个域？还需要什么后续的步骤吗？2另一个头痛的问题是如何使原客户端的dns指向新的dns，我想将dc(old)从网络下线后 ，直接修改dc(new)的ip为dc(old)的ip，但是觉得会有问题，不知道是否可行，或者有其他更好的办法。否则我还是要修改40多台客户端的dns指向新的dc(new）！ 回答： 1这里要澄清一个问题，所有dc如果获得了完全复制，那么它们上面的数据库是完全同步的，这个通过过程是后台自动完成的，不需要人为干预。如果您的dns选择了与ad同步，那么dns的同步也是自动的。那么在新的dc作为additional dc添加进来并获得完全同步后，您所需要做的动作是，将原有primary dc所承担的角色转移过来，比如5个om，gc，如果有多站点，还有istg。注意是transfer，而不是seize。等待dc的状态稳定后，降级原来的primary dc就好了。相关的资料请参考： http://supportmicrosoftcom/defaultaspxscid=kb;cn;223346 http://supportmicrosoftcom/defaultaspxscid=kb;zh-cn;255690 http://supportmicrosoftcom/defaultaspxscid=kb;zh-cn;324801 http://supportmicrosoftcom/defaultaspxscid=kb;en-us;255504 2更改dc ip的想法是可行的。但您要注意更改dns中的srv记录，更改完成后，要注意ad中的各事件日志，确保ad的正常运作。需要提到一点的是，整个操作需要有个过程，最好能够持续1、2天，分步骤实施，实施之间最好能够在测试环境中测试后，并对现有dc进行备份后，再行动作！关于dns client的配置问题，这里您可以看一个kb http://supportmicrosoftcom/defaultaspxscid=kb;en-us;825036 最关键的一个地方就是primary dns互相指向，否则容易导致dns解析的问题，从而客户端、dc复制都有可能出现问题。

求采纳