SQL数据迁移问题(数据库迁移的两种方法)

首先，暂停SQL2000数据库，将MDF和LDF文件备份。

这些文件复制到新机器，尝试直接附加，如果两个SQL版本一致，就这个方法最直接。但如果失败，尝试下面几个方法。

一般来说，不同SQL版本迁移数据，推荐使用两种方法进行转换：

1·使用数据库备份还原，在2000中备份成bak文件，到新系统中还原，这个方法的成功率比直接附加大的多，但如果数据库中存在特殊性不兼容的结构，此方法也可能失败，这时候使用第二种方法；

2·在2000中对数据库导出完整脚本（sql文件），在新系统中创建一个空库，执行该脚本。并使用DTS导入数据。

Oracle数据库之间的迁移么？这个很简单的，通过一个DBLink，将源数据库映射到目标库上，然后通过SQL语句将数据全部拷贝到目标库就行了。

如果是不同数据库之间，则需要将数据和表结构导出到SQL语句中，在目标库重建。另外，使用数据仓库，可以实现将不同数据源的数据整合。

需要注意的是：

1、 想好迁移上云后想达到的效果

即通过使用云数据库希望达到的目的，比如降低成本，更高的灵活性，更大的可扩展性，还是更高的可靠性。用户需要根据迁移目的来选择合适的服务类型。如果只是简单的随大流将服务迁移到云上，很可能导致未来的问题。

2、 选择有完善服务支持的云服务商

包括服务商的 SLA 承诺和数据安全承诺。很多情况下，将应用迁移到云数据库涉及数据迁移，应用适配等，云服务商有完善的支持服务，可以在遇到困难时起到事半功倍的效果。如果云服务商具备足够的经验，通常可以给出场景性的完整方案，对于提高迁移的成功率有直接的帮助。

3、 充分的迁移规划

1）维护和数据管理计划。IT人员提前了解公司所需的数据需求，选择合适的数据库引擎类型、付费方式；熟悉云数据库引擎提供的管理工具，基于预期的云数据管理需求，做好主动解决问题的准备。

2）账户控制计划。云数据库服务商一般都会提供丰富的账户控制能力，包括授权和再授权、审计，基于预先确定的安全设置，授权访问设置，审计计划，然后会发现云数据库服务真的是一个非常高效简洁的工具。

3）迁移和回退计划。一般来说，一个完备的迁移计划和演练， 有助于在事先发现迁移过程中可能遇到的问题， 制定有针对性的计划；万一迁移失败，回退计划可以保证业务在本地继续执行，从而减少迁移过程的压力，并保证业务的完整性。

4、 从容易的服务开始

云计算的环境和本地数据库存在一定的差异，考虑到业务的连续性，初次使用公有云数据库时，可以从简单的服务开始，如测试验证数据库、辅组性的资源索引数据库、新开发业务数据库等，通过这些服务先熟悉云数据库的基本特征和特性，评估其性能和可用性相关内容，管理工具的成熟度。比如，有些服务商的云数据库存在不同时段的性能波动，则可能不是好的选择。

方法一：

将\Microsoft SQL Server\MSSQL\DATA文件夹中的syntt_datamdf和syntt_logldf文件复制到安装有数据库服务器的机器的文件夹中（可以是本机的\Microsoft SQL Server\MSSQL\DATA\文件夹），然后进入企业管理器。右键点击逗数据库地，在浮动菜单中选择逗所有任务地中的逗附加数据库地。

在随后的提示页面中选择刚才复制过来的MDF文件，如果想指定数据库的所有者，在逗指定数据库所有者地选择框中选择你认为合适的用户。如果想修改数据库的名字，可在逗附加为地框中输入新的数据库名字（对本数据库，不建议这么做，因为这样的话，整个程序中所有涉及数据库连接的代码都要随之修改，那将是不必要的劳动）。

在进行完上述的工作之后，直接点击逗确定地就可进行数据的SQL Server 数据转移转移。

方法二：

（方法一）是针对数据库中没有本数据库的服务器，如果数据库中已经建有与该数据库名称相同的数据库，则直接按照备份数据库的恢复 *** 作就可完成数据的SQL Server 数据转移转移。

方法如下所述：

这种方法首先要在本机上建立一个备份文件，具体 *** 作介绍如下：

1、 在企业管理器中打开服务器组以及指定的服务器。然后右键点击需要备份的数据库在这里是syntt，在浮动菜单中选择逗所有任务地菜单下的逗备份数据库地，打开数据备份对话框。

2、 选择逗常规地选项卡，在名称对话框中输入本分集合名称，在逗描述地文本框中输入备份集描述文本信息。在逗备份地组下选择备份 *** 作类型，共有以下几种：

数据库—完全：完整备份数据库。

数据库—差异：增量备份数据库。

事务日志：事务日志备份。

文件和文件组：数据库文件和文件组备份。

在逗目的地组中指定备份设备或者备份文件名称，选择逗添加地按钮添加备份设备或者文件；逗删除地按钮用来删除备份设备和备份文件；选择逗内容地按钮，则可查看已经存储在备份设备或文件中的备份信息。

在逗重写地组中有两种选项：

追加到媒体：选择该选项，表示需要保存备份设备或文件中以前的备份数据。

重写现有媒体：要求本次被分数据覆盖以前的备份数据，从而节省存储空间。

在逗调度地组中，安排数据备份的时间。用来指定数据库备份在将来的某个时间执行

3、 逗选项地选项卡，设置数据库备份 *** 作选项。其中的内容主要有以下几项：

完成后验证备份：要求在备份结束时对备份数据进行校验。

备份后d出磁带：只对磁带备份设备有效，他要求在备份结束时自动卸带。

删除事务日志中不活动的条目：要求在事务日志备份结束时删除事务日志中的已经完成的事务日志条目。

检查媒体集名称和备份集到期时间：要求在备份前检查介质集名称和原备份集中备份SQL Server 数据转移的有效期，以防止意外重写破坏原来的备份数据。

备份集到期时间：设置备份集的有效期。

初始化并标识媒体：只对磁带设备有效。选择该选项后，SQL Server在备份时将Microsoft定义的磁带格式信息写入介质的开始部分。此时，可以在逗媒体集名称地和逗媒体集描述地文本框中定义介质集名称和介质描述信息。

4、 在进行完上述的 *** 作之后，剩下的任务就是点击逗确定地，使系统开始进行数据库的备份 *** 作。

到目前为止，我们已经有了一个数据库的备份文件，剩下的任务就是怎么将这个文件还原至另外的数据库服务器中了。

1、因为使用企业管理器进行数据库的恢复只能是在本机进行，所以在进行数据还原之前，必须将刚才所作的备份文件复制到本机，然后在本机选择逗syntt地数据库，右键点击它，在显示出来的浮动菜单中选择逗所有任务地下的逗还原数据库地。

2、在还原数据库对话框中，在逗常规地选项卡中的选择逗从设备地的数据恢复方法，通过逗选择设备地按钮选择刚才复制过来的文件。

逗常规地选项卡与逗选项地选项卡中的具体内容如下所示：

逗常规地选项卡：

数据库恢复方法：包括逗数据库地、逗文件组或文件地、逗从设备地三种恢复方式。

逗数据库地方式：选择该项时，从逗显示数据库备份地列表中选择需要显示的指定数据库备份集合，从逗要还原的第一个备份地列表框中选择首先使用哪一个备份集恢复数据库；逗文件组或文件地：选择它时，数据库恢复部件列出指定数据库备份集合中备份的数据库文件或文件组，管理员可从这些备份文件中选择恢复那个数据库文件或文件组；逗从设备地：选择它时，管理员选择恢复数据库或其日志所使用的备份设备，之后再从该备份设备中选择使用哪一次备份中的数据恢复数据库或其日志。

3、点击逗确定地，完成恢复 *** 作。

非原创

基础架构

AWS分布在全球12个区域里

每个区域对应着一个地理位置，里面含有多个Availability

Zones(可用区)。这些区域设置在北美，南美，欧洲，中东，非洲，亚太区。

每个AZ实质上是单个数据中心，尽管它们可由多个数据中心构建。

每个AZ有着独立的供电系统和互联网连接。

不同AZ之间以低延迟网络进行连接，这种快速网络可消除物理位置带来的速度影响。

每个区域含有至少两个AZ，共计32个AZs。

借助AZ可创建高可用性的程序架构。

AWS在全球还分布有53个偏远区域(Edge locations)

偏远区域的使用对象是CloudFront，这是Amazon的内容分发网络(CDN)和DNS服务器。

偏远区域的存在使得全球用户都可以享用低延迟网络而不论他们身在何处。建立区块服务(Block Services)

Amazon透过AWS创建了大量高可用和高容错的服务，具体的服务清单可点击这里查看。

缴纳一定的费用，你就可以在个人的应用中使用这些服务而不必为高可用性而忧心。

部分服务位于一个AZ中：CloudFront, Route 53, S3, DynamoDB, Elastic Load

Balancing, EFS, Lambda, SQS, SNS, SES, SWF。

即使是使用单个AZ的服务，其高可用架构也是足够强大的。

1个用户

在这个时候，开发者=用户。你的架构看起来是这样的：

运行单个实例，如t2micro。你可以为你的服务器选择不同的CPU，内存，存储设备和网络环境。

该服务器承载了全部web任务，如：web应用，数据库，管理器等。

使用AmazonRoute 53进行DNS管理。

为该实例附加一个Elastic IP地址。

那么随着用户数的增加，我们需要如何进行升级改造，直至能为千万用户提供优质的服务呢？强调文字

优化策略

采用多主机模式

尝试使用Amazon数据库服务，如Amazon RDS(关系数据库)，Amazon DynamoDB(NoSQL数据库)，Amazon Redshift。

逐步从SQL数据库转为NoSQL数据库，特别是数据量超过5TB，你的应用对低延迟敏感的时候。

使用Elastic Load Balancer(d性负载均衡器)，它可以对主机进行健康检测以确保网络的通畅，同时可以帮助实现网络的扩展。

垂直升级

需要更强的实例类型，例如c48xlarge或者m32xlarge。

停止使用当前的服务器，换用功能更强大的机器，如：244GB RAM，40核CPU。

某些Amazon服务提供了Provisined IOPS选项以便用户自行配置变更，这样一来用户可以使用类似DynamoDB的扩展服务。

类似上面的做法就叫做垂直升级。但其有个缺点，就是一旦机器出错，你的网站也会停止运作了。所以要尽量避免单个实例的做法。

自动扩展

如果你一直在为峰值负载而努力，如黑色星期五，那么其实是在浪费金钱。更好的解决方案

列表内容

是按需分配，这就是Auto Scaling(自动扩展)，在计算机群组中实现自动化的大小变更。

你可以为你的容量池定义最大值和最小值。

CloudWatch是一个管理服务，已内置到所有的Amazon应用中。

CloudWatch事件会触发扩展。

触发事件可以是CPU占用率，时间延迟，网速等等。

你也可以向CloudWatch导入自定义基线，按照你的意愿来触发扩展。

架构分解

使用SOA/微服务，使你的服务层组件化。

这样做的好处是单独的服务可以独立地进行扩展，从而大大增加了灵活性和可用性。

SOA是Amazon提供的重要架构组件。

避免重复劳动

把精力投入到能使你的业务与众不同的事情上。

Amazon提供了很多高容错的服务。例如，排队(SQS服务)，邮件，转码，搜索，数据库，监控等等。所以类似的服务都不必再次编写了。

用户数>千万+

当用户达到千万级别的时候，你考虑的策略应该是这样的：

多AZs模式

在不同层之间执行ELB(d性负载平衡)。除了web层，在应用层，数据层等层里也需要进行ELB。

能够自动扩展

使用面向服务的架构

缓存架构内和外的数据

使用Amazon S3和CloudFront。S3用于存储静态数据，如js，CSS，图像等，具有足够的扩展性。CloudFront可对数据进行缓存。

使用Amazon SES来进行邮件发送。

使用CloudWatch进行监控。

对数据写入执行如下的策略：

联结 – 根据功能划分不同的数据库。

分表 – 把一个数据集分解到多个主机上。

把部分功能放到其他类型的数据库上（NoSQL,graph等）。

不断优化你的应用和整个架构堆栈，针对瓶颈进行分析并找出解决方法。

以上就是关于SQL数据迁移问题(数据库迁移的两种方法)全部的内容，包括:SQL数据迁移问题(数据库迁移的两种方法)、数据库迁移、将数据库迁移到云数据库需要注意什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！