微软sql数据库移到新服务器,迁移 SQL Server 到 Azure SQL 实战

sql Server 2012 的数据库迁移到 Azure sql 上去。主要是因为租用的主机到期,而运营商停止了主机租赁业务,看来向云端的迁移是大势所趋啊!经过一番折腾最终成功迁移,但过程可谓是一波三折。故在此分享这次迁移中碰到的点点滴滴,希望对朋友们有所帮助。

sql 的版本

sql Database 是微软提供的 sql 服务(PaaS)。最新的版本叫 Azure sql Database V12,其实微软还是通过 sql Server 2014 提供的数据库服务:

6c11d7b0f0269c16a640d7927726f840.png

数据库服务器是本地安装的 sql Server 2014,第二个和第三个则是云上的 Azure sql Database。可以很清楚的看到,它们的版本是一样的。

sql Database 提供的数据库和本地安装版本是一样的噢。它们还是有不少差别的,这一点在迁移现有数据库时尤为重要。

sql Database 可以快速的发布新特性,这些从不断更新的 MSDN 文档可见一斑。MS 也强烈建议我们在和 Azure sql Database 打交道时一定要用最新版的工具。笔者在刚开始使用了 sql Server 2014 中的 SSMS (sql Server Management Studio) ,结果连接 Azure sql 后发现显示的信息和 Azure portal 对不上,安装最新版的 SSMS 后问题消失。

数据库一般都是处于正在使用的状态,所以千万不要在真实的库上做各种实验。笔者所有的前期实验都是在通过恢复备份文件创建的测试库上完成的。

sql Server

sql Database 是运行在 Azure sql Server 中的,所以我们要在 Azure 上先把 Azure sql Server 创建好。操作比较简单,直接在 Azure 上添加 sql Server (logical server) 就可以了,请注意选择合适的区域(主要影响访问速度)。

sql Server

sql Server 创建好以后,我们通过 SSMS 测试一下能不能连上。当我们输入了正确的地址和用户信息后却弹出了一个提示框:

a2df52162ca265ea33c276a48280c31f.png

提示我们当前的 IP 不能访问 Azure上的数据库服务器,并且让我以 Azure 账号登录并创建一条防火墙规则。

sql Server。此时我们有两种做法。

登录。然后点击 "OK",此时已经完成了防火墙规则的设置,SSMS 已登录 Azure sql Server。这种方法一般用于开发和测试,只能添加当前客户端所使用的 IP。

方法是登录 Azure portal,进入 Azure sql Server 的配置界面,为防火墙添加规则。同样的,可以添加单个 IP 也可以一次添加一个网段:

5041edf9447787c25acfd61feead7b63.png

sql Server 版本众多,且云上的版本与本地版本也有差异。所以能不能迁移成功主要看能不能找到并解决数据库之间的兼容性问题。

数据库中设置的用户不存在

显示下面的信息:

Error sql71564: Error validating element [xxxx]: The element [xxxx] has been orphaned from its login and cannot be deployed.

数据库中设置的用户名。错误的原因是用户被定义在本地的 sql Server 中,数据库中只有使用用户的信息,把数据库迁移到云上后,就找不到对应用户的定义了。所以需要移除本地用户的信息。不用担心数据库的访问问题,因为完成迁移后你可以使用刚才创建的 Azure sql Server 账号访问数据库。当然你还可以为一个数据库创建独立的访问账号,具体操作请参考 MSDN。

不支持Extended Property

显示下面的信息:

One or more unsupported elements were found in the schema used as part of a data package.

Error sql71564: The element Extended Property: [dbo].[xxxx].[MS_Description] is not supported when used as part of a data package (.bacpac file).

数据库中一张表的名称。不支持 Extended Property!在笔者的数据库中有好几处都用到了这个特性。怎么办?只好一遍又一遍的查看程序。最后发现程序中没有使用这个特性,好像当时只是有人用它做了一些说明。最终的结论是可以移除。

显示下面的信息:

One or more unsupported elements were found in the schema used as part of a data package.

Error sql71564: Table Table: [dbo].[xxxx] does not have a clustered index. Clustered indexes are required for inserting data in this version of sql Server.

数据库中一张表的名称。修改都可能会影响到程序逻辑,怎么办呢?网上的朋友们早就有了比较靠谱的解决方案,就是给表添加一列用来做 clustered index,这样原来表中的列就没有发生变化:

(,)

解决方案,关键是要采用自己的业务能够接受的方式去解决问题。数据库的变更写成一个脚本文件。在正式的迁移中,直接在正式库上执行脚本文件。

sql Server Management Studio) 。下面看看具体的操作步骤。数据库,选择 Tasks 中的"Deploy Database to Microsoft Azure sql Database…"。

6719bf4b246f2b6e728cef0dc4454458.png

sql Server 的连接地址和连接账号:

8966af45a5a8563b104f894b87af699f.png

数据库名称和资源配置:

9ea84c28c11b46ddefe57b4b89b0fde8.png

sql Database settings,MS 把数据库使用的资源划分成了三个不同的类别:Basic,Standard,Premium。每个类别中又划分了不同的收费标准,简单说就是你要使用更多更好的资源就要掏更多的钱。当然也可以反过来说,如果我用的资源不多花一点点钱就够了!文件指定一个存储路径。*.bacpac 文件是迁移过程中生成的中间文件,当兼容性检查通过后,就把数据库中的所有内容都导出到这个文件中。从这个信息我们可以得知,无论采用何种迁移方式,其核心操作都是两步:先从本地数据库生成 *.bacpac 文件,再从*.bacpac 文件恢复一个Azure sql Database。显示配置的详情,再下一步就开始兼容性检查。如果没有兼容性问题,就执行迁移操作。数据库存在一些兼容性问题,所以显示了错误报告并终止了迁移操作:

0dd053d90c6ae72512412ff6bd2e6266.png

链接就能看到详细的报告,前面已经介绍过兼容性问题,直接执行我们处理兼容性问题的脚本文件,然后再试一次!

ef5c5c40bf033bbece53f2914cc39a37.png

错误提示了,其实后台已经开始了迁移过程。比较不爽的是这个过程没有详细的进度提示,只能黑等。我的经验数据是8G的库完成迁移大概是 8-12小时。当然这和你连接 Azure 的带宽有很大的关系…

解决方案也很详尽。所以尽管笔者碰到了很多的问题,但没有卡壳的地方,总算磕磕绊绊的完成了数据库迁移的任务。

总结

如果觉得编程之家网站内容还不错,欢迎将编程之家网站推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值