数据库数据如何跨服务器迁移

开始菜单--->程序,打开SQL Server Management Studio(即我们的SQL 2005)

连接服务器后,找到我们需要迁移的数据,右键点击属性

在数据库属性里面,点击文件,可查看数据库文件和数据库日志文件的存放路径

确定没有任何其它用户连接到此数据库后,点击该数据库-->任务-->分离

我们可以看到分离以后,刚刚那个数据库,已经不在此列表

进入刚刚我们第3步属性里面看到的数据库文件路径如下图把我们的ZNLCRMmdf数据库文件和ZNLCRM_LogLdf数据库日志文件拷贝到另外一台服务器

在另外台服务器上打开SQL数据库与第1步一样点击数据库--->附加

在附加数据库里面,点击添加,如下图所示

找到刚刚拷贝过来的ZNLCRMmdf文件选中该文件,依次点击确定(注意日志文件会自动一起加载过来)

然后我们就可以看到,一个完整的数据库就直接被迁移过来如下图

客户由于以下原因可能会要进行OA的迁移

1) 项目实施阶段，通过某项测试，把通过测试的机器的OA环境搬迁到另一台机上

2) OA应用服务器硬件升级或故障，为了不影响OA正常使用，需要搬迁

3) OA应用做双机互备，双机热备等

此OA应用服务迁移如果涉及OA数据库的变动，请参考『迁移OA数据库』。

1 相同操作系统间迁移，如从一台windows2003系统机器迁移到另一台windows2003系统机器

直接把$OA_HOME目录拷贝到另一台机器相同路径下（如果拷贝到另一台机器的路径不相同，方法请参考跨操作系统迁移，来修改路径参数）；

2跨操作系统迁移（如从windows操作系统迁移到linux）或者在同一台机器下不同路径下迁移

将$OA_HOME目录压缩成tar格式，然后上传到目录机器上，解压到需要的路径下

请检查以下这些文件，将路径修改成实际的路径：

1．$OA_HOME/TomcatX/conf/serverxml文件Context path="/oa" docBase=" E:/OA/firstframe/webapp"中docBase的值

或者$OA_HOME/ApusicX/config/serverxml文件application name="oa" base =" E:/OA/firstframe/webapp "中base的值

2．$OA_HOME/firstframe/bin/set-server-envbat(非windows环境：$OA_HOME/firstframe/bin/initsh)文件中OA_HOME，JAVA_HOME，JRE_HOME等参数的路径值

3．$OA_HOME/firstframe/resources/firstframeproperties文件中constantmain_storage_dir的值（OA公文处理表单等文件的存放目录路径）

注意：由windows操作系统迁移至其他操作系统，要将数据库中各模块附件中路径的反斜杠全部改成正斜杠，脚本如下：

--oracle脚本:update archive2_attach set serverfile=replace(serverfile,'

','/');update archives_attach set serverfile=replace(serverfile,'

','/');update books_info set serverfile=replace(serverfile,'

','/');update bulletins_attach set serverfile=replace(serverfile,'

','/');update calendar_attach set serverfile=replace(serverfile,'

','/');update docex_fileattach set serverfile=replace(serverfile,'

','/');update fileman set serverfile=replace(serverfile,'

','/');update forum_attachment set serverfile=replace(serverfile,'

','/');update knowledge_attach set serverfile=replace(serverfile,'

','/');update meeting_attach set serverfile=replace(serverfile,'

','/');update messages_attach set serverfile=replace(serverfile,'

','/');update news_attach set serverfile=replace(serverfile,'

','/');update workflow_fileattach set serverfile=replace(serverfile,'

','/');update workflow_signature set serverfile=replace(serverfile,'

','/');update workflow_wordtemplate set serverfile=replace(serverfile,'

','/');update workflow_websign set serverfile=replace(serverfile,'

','/');commit;

--mssql脚本:update archive2_attach set serverfile=replace(serverfile,'

','/')update archives_attach set serverfile=replace(serverfile,'

','/')update books_info set serverfile=replace(serverfile,'

','/')update bulletins_attach set serverfile=replace(serverfile,'

','/')update calendar_attach set serverfile=replace(serverfile,'

','/')update docex_fileattach set serverfile=replace(serverfile,'

','/')update fileman set serverfile=replace(serverfile,'

','/')update forum_attachment set serverfile=replace(serverfile,'

','/')update knowledge_attach set serverfile=replace(serverfile,'

','/')update meeting_attach set serverfile=replace(serverfile,'

','/')update messages_attach set serverfile=replace(serverfile,'

','/')update news_attach set serverfile=replace(serverfile,'

','/')update workflow_fileattach set serverfile=replace(serverfile,'

','/')update workflow_signature set serverfile=replace(serverfile,'

','/')update workflow_wordtemplate set serverfile=replace(serverfile,'

','/')update workflow_websign set serverfile=replace(serverfile,'

','/')go

因为中间件缓存中保存了原来路径参数，影响OA使用，所以在启动OA服务之前请清删除OA缓存文件，$OA_HOME/ApusicX/deploy或$OA_HOME/TomcatX/work/Catalina/localhost目录下的所有文件夹，启动OA服务后重新申请license，如中间件是apusic，还需要重新申请apusic的license，请联系实施人员申请。

   迁移MySQL数据库通常只需要几个简单的步骤，但是由于您要转移的数据量可能比较庞大，因此一般耗时也会比较长。

    下面的步骤将指导您如何从旧的服务器上导出MySQL数据库，对它进行安全加固；然后将其复制并导入到新的服务器上，以保证数据的完整。

    将MySQL数据库导出至转储文件（dump file）

    Oracle提供了一个名为mysqldump的工具，允许您轻松地将数据库结构和其数据导出到一个SQL的转储文件。您可以使用如下的命令：

    1mysqldump -u root -p --opt [database name] > [database name]sql 

    不过，请注意如下几点：

    我们可以使用--single-transaction的标志，以避免数据库在导出数据的过程中被锁死。这样能够在将数据导出到转储文件的同时，您仍可继续在旧的数据库上更新数据。不过请注意，那些在导出进程已经开始之后被更新的数据，是不会被导入转储文件之中的。

    在运行该命令之前，请务必将[database name]替换成您的实际数据库名称。

    请输入您自己的用户名和相对应的密码，并确保该用户具有备份数据库所需的权限。

    安全加固备份文件

    在大多数情况下，数据是一家企业的最重要的资产。因此，我们不希望数据库的各种备份被暴露在不受保护的服务器上，因为这样有可能会造成错误地泄露，甚至会出现被黑客窃取等更为糟糕的状况。

    因此，通常您可以尝试的做法是：压缩、加密文件，然后删除原文件。在Linux操作系统上，请使用以下的命令对已压缩文件进行加密：

    1zip --encrypt dumpzip dbsql 

    在压缩开始之前，系统将提示您输入密码。

    传输备份文件

    至此，我们已经获得了一个加密的转储文件。下面让我们通过网络使用SCP命令，将其传输到新的服务器上：

    1scp /path/to/source-file user@host：/path/to/destination-folder/ 

    将MySQL转储导入新服务器

    通过上面一步，我们已将备份文件传到了新的服务器上，下面让我们来进行解密和提取：

    1unzip -P your-password dumpzip 

    为了存储空间和安全方面的原因，一旦文件导入成功，请记得删除其对应的转储文件。

    您可以使用以下的命令来导入文件：

    1mysql -u root -p newdatabase < /path/to/newdatabasesql 

    在新服务器上验证导入的数据

    现在我们在新服务器上已经导入了数据库，那么我们就需要一种方法来验证数据的真实存在，并确保没有任何遗漏。

    我建议您同时在旧的和新的数据库上运行如下查询，并将获得的结果进行对比。

    该查询会在所有的表里计算行数，以显示出新、旧数据库中的数据量。

    1SELECT   

    2TABLE_NAME,   

    3TABLE_ROWS  

    4FROM   

    `

    5information_schema``tables`  

    6WHERE   

    `

    7table_schema` = 'YOUR_DB_NAME'； 

    此外，我建议您检查各个表中数字列的MIN和MAX记录，以确保数据本身是有效的，而不仅仅是看数据的总量（虽然这是查询所唯一能够读出的值）。另一种可供测试的选择是将数据库从新的服务器导出为SQL转储文件，并将其与旧服务器的SQL转储文件做比较。

    此外，在应用程序被迁移之前，我建议您先将一个应用程序的实例重定向到新的数据库上，以确认一切运行正常。

    另一种导出和导入的选项

    我们之所以把该选项放在最后，是因为我们的确不建议您去使用它。

    该方法实现起来非常的容易，因为它仅使用一个命令，便能一次性将转储文件导出、传输、并将其数据导入到新的数据库之中。

    而它的不足之处在于，一旦其网络链接断掉，您就需要重新启动它了。

    因此，我们认为它并不值得被推荐，尤其是在大型数据库中，可能会非常不适用。

    当然，如果您非要尝试一下的话，可以使用如下的命令：

    1mysqldump -u root -pPassword --all-databases | ssh user@new_hosthostcom 'cat - | mysql -u root -pPassword' 

    重要提示

    请确保在新旧两处，安装有相同官方发行版本的MySQL服务器。否则，你需要按照MySQL网站上的升级说明来进行统一（请参见（https：//devmysqlcom/doc/refman/57/en/upgradinghtml）。

    请确保您在旧的服务器上拥有足够的空间来保存转储文件和压缩文件（应该有db_size×2的空间）。

    请确保您在新的服务器上拥有足够的空间来保存加密的和解密的转储文件、并能导入数据库（应该有db_size×3的空间）。

    如果您曾经考虑过只是将datadir从一个数据库转移到另一个的话，我建议您最好不要这样做。否则，您会搞乱数据库的内部结构，而且会给将来可能的问题埋下隐患。

    在新的服务器配置中，请不要忘了配置诸如innodb_log_file_size这样的重要标志。因为如果忘记了根据新服务器的规格而更新配置的话，很可能会导致严重的性能问题。

    在许多情况下，一般升级到新的数据库服务器的初衷是为了提高查询性能。而如果此类升级没有达到预期的改善，那么您就应该考虑去优化SQL查询，而不仅仅是升级硬件那么简单了

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

近日苹果发出通知，自2月28日起，苹果公司将把iCloud（中国）服务器切换到国内进行运营，主要影响国家设置为“中国”的Apple ID所有用户。

不少网友反馈，陆续接到了iPhone发出的系统级通知，苹果表示，iCloud中国将转向云上贵州进行运营，在提升云端服务的速度和可靠性的基础上，更好的遵守中国法规。

资料迁移国内不光是遵守中国法规，对用户的安全性也是一大提升，之前iCloud的所有数据都存储在国外服务器，虽然苹果公司拥有很强的安全团队，但这些数据对国家而言还是不可控的。

这次迁移把数据放到国内，由我们自己进行保护，也防止国外政府购买苹果数据的可能性。

安全性这个事情在大部分用户那里还是不太重视的，只要不出事就是无视的状态，所以提升最明显的就是速度的体验。

之前云端服务器在国外，中国到国外的线路本身就有瓶颈，晚高峰期时运营商骨干网拥塞比较严重，国际线路拥塞问题更是堪忧，所以国内用户使用国外资源简直是痛苦。

相比国外服务器，国内的云端iCloud优势非常明显，全国重点城市部署节点，可以很好的提升全国用户的使用体验，也保证了可用性。

当然，苹果一贯的作风就是给用户提供足够的选项，并不是强制迁移国内，如果对国内公司不信任，不想继续使用也很简单，可以直接停用iCloud功能，这样的话，所有的苹果产品向服务器同步的数据都将清楚，不会有任何保留。

首先，打开服务器上已经安装好的SQL Server 2005 服务器，并且用本地Windows身份登录。

2

打开SQL Server服务器以后，点击数据库--选择附加

3

打开附加数据库界面后，点击右小角的添加

4

打开电脑上，之前备份好的完成数据库文件，然后点击确认。

5

数据库文件和其数据库日志文件，就一并加载过来了，点击确认就可以了。

6

展开数据库，就可以了看到我

们刚刚附加过来的完整数据库了，现在就可以

使用

这个数据库。

要看什么数据，比如文件存储服务器，可以买2块万兆光纤网卡，直接复制，或者用软件复制，速度很快就搞定

如果带数据库，不建议直接复制，容易出问题，

数据库通过使用数据库的软件备份，比如用友，金蝶的数据库，然后复制备份数据到新服务器，原则上，以数据，从小到大开始

如果数据库实在太大，可以给使用该数据库软件的公司联系，看能不能做数据库和软件分离，单独的一台服务器只做数据库，只存放数据库数据，不负载其他软件，或者做类似分布式存储，多台服务器存储数据库数据，不集中在某一台服务器