最近有个维护的项目须要把 SQL Server 2012 的数据库迁移到 Azure SQL 上去,迁移过程可谓一波三折,故在此分享此次迁移中碰到的点点滴滴,但愿对朋友们有所帮助。html
Azure SQL Database 是微软提供的 SQL 服务(PaaS)。最新的版本叫 Azure SQL Database V12,其实微软仍是经过 SQL Server 2014 来提供数据库服务:数据库
上图中第一个数据库服务器是本地安装的 SQL Server 2014,第二个和第三个则是云上的 Azure SQL Database。咱们能够很清楚的看到,它们的版本是同样的。安全
可是可不要觉得 Azure SQL Database 提供的数据库和本地安装版本是同样的噢。它们仍是有很多差异的,这一点在迁移现有数据库时尤其重要。服务器
因为提供的是在线的服务,因此 Azure SQL Database 能够快速的发布新特性,这些从不断更新的 MSDN 文档可见一斑。MS也强烈建议咱们在和 Azure SQL Database 打交道时必定要用最新版的工具。笔者在刚开始使用了 SQL Server 2014 中的 SSMS (SQL Server Management Studio) ,结果链接 Azure SQL 后发现显示的信息和 Azure portal 对不上,安装最新版的 SSMS 后问题消失。网络
下面进入正题,看看迁移的过程当中都须要什么样的工具,如何操做以及须要注意的事项。在此特别强调,旧数据库通常都是处于正在使用的状态,因此千万不要在真实的库上作各类实验。笔者全部的前期实验都是在经过恢复备份文件建立的测试库上完成的。工具
Azure SQL Database 是运行在 Azure SQL Server 中的,因此咱们要在 Azure 上先把 Azure SQL Server 建立好。操做过程比较简单,直接在 Azure 上添加 SQL Server (logical server) 就能够了,请注意选择合适的区域(这会影响访问速度)。post
Azure SQL Server 建立好之后,咱们经过 SSMS 测试一下链接状况。当咱们输入了正确的地址和用户信息后却弹出了一个提示框:学习
它提示咱们,当前的IP不能访问 Azure 上的数据库服务器,而且让我以 Azure 帐号登陆并建立一条防火墙规则。测试
其实这是 Azure 提供的一个安全措施,它让你显式的指定哪些IP地址或者IP网段能够访问 Azure SQL Server。ui
此时咱们有两种解决方法:
1.点击对话框中的 ”Sign in”,用 Azure 帐户登陆;而后点击 ”OK”,此时已经完成了防火墙规则的设置,SSMS 已登陆 Azure SQL Server。这种方法通常用于开发和测试,只能添加当前客户端所使用的IP。
2.更加通用的方法是登陆 Azure portal,进入 Azure SQL Server 的配置界面,为防火墙添加规则。一样的,能够添加单个IP也能够一次添加一个网段:
因为 MS SQL Server 版本众多,且云上的版本与本地版本也有差别,因此能不能迁移成功,主要看能不能找到并解决数据库之间的兼容性问题。
下面将详细的介绍笔者碰到的兼容性问题。
兼容性检查的报告显示下面的信息:
Error SQL71564: Error validating element [xxxx]: The element [xxxx] has been orphaned from its login and cannot be deployed.
其中的xxxx是数据库中设置的用户名。
这个错误的缘由是用户被定义在本地的 SQL Server 中,数据库中一旦使用用户的信息,把数据库迁移到云上后,就找不到对应用户的定义了,因此就须要移除本地用户的信息。
不用担忧数据库的访问问题,由于完成迁移后,你可使用刚才建立的 Azure SQL Server 帐号访问数据库。固然你也能够为一个数据库建立独立的访问帐号,具体操做请参考 MSDN。
兼容性检查的报告显示下面的信息:
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).
其中的xxxx是数据库中一张表的名称。
这下可麻烦了,不支持 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.
其中的xxxx是数据库中一张表的名称。
须要给表建立 clustered index,这可不是一件小事情,由于任何对表的修改均可能会影响到程序逻辑,怎么办呢?网上的朋友们早就有了比较靠谱的解决方案,就是给表添加一列用来作 clustered index,这样原来表中的列就没有发生变化:
ALTER TABLE [xxxx] ADD RowId int NOT NULL IDENTITY (1, 1) PRIMARY KEY CLUSTERED GO
还有一些点,主要是和业务相关的,就不在此赘述。我的感受绝大多数的问题在网上都有不一样的解决方案,关键是要采用本身的业务可以接受的方式去解决问题。
接下来把全部对数据库的变动写成一个脚本文件,在正式的迁移中,直接在正式库上执行脚本文件。
MS提供了不一样的工具进行兼容性检查、迁移等工做。咱们这里通通使用 SSMS (SQL Server Management Studio) 。
下面看看具体的操做步骤。
在 SSMS 中右键须要迁移的数据库,选择 Tasks 中的 ”Deploy Database to Microsoft Azure SQL Database…”。
在打开的向导中点击 “next” 进入 “Deployment Settings” 界面。
首先须要设置Azure SQL Server的链接地址和链接帐号:
接下来设置迁移后的数据库名称和资源配置:
注意 Azure SQL Database settings,MS把数据库使用的资源划分红了三个不一样的类别:Basic, Standard, Premium。每一个类别中又划分了不一样的收费标准,简单说就是你要使用更多更好的资源就要付更多的钱。固然也能够反过来讲,若是我用的资源很少,付一点点钱就够了!
咱们发现上图中的最后一行要求咱们为 *.bacpac 文件指定一个存储路径。*.bacpac 文件是迁移过程当中生成的中间文件,当兼容性检查经过后,就把数据库中的全部内容都导出到这个文件中。从这个信息咱们能够得知,不管采用何种迁移方式,其核心操做都是两步:先从本地数据库生成 *.bacpac 文件,再从*.bacpac 文件恢复一个 Azure SQL Database。
单击 “Next” 显示配置的详情,再下一步就开始兼容性检查。若是没有兼容性问题,就执行迁移操做。
个人数据库存在一些兼容性问题,因此显示了错误报告并终止了迁移操做:
点击 “Result” 列中的连接就能看到详细的报告,前面已经介绍过兼容性问题,直接执行咱们处理兼容性问题的脚本文件,而后再试一次!
此次的执行已经没有错误提示了,其实后台已经开始了迁移过程。比较不方便的是这个过程没有详细的进度提示,只能耐心等待。个人经验数据是8G的库完成迁移大概是8-12小时。固然这和你链接 Azure 的带宽有很大的关系…
因为整个迁移过程涉及的方方面面实在太多,本文只是概要式的介绍笔者认为迁移过程当中的要点和本身碰到的问题。整体感受是MS提供的工具还算比较完善,网络上的各类已知问题解决方案也很详尽。因此尽管笔者碰到了不少的问题,但没有卡住的地方,总算磕磕绊绊的完成了数据库迁移的任务。
相关阅读:
Azure Blob Storage 基本用法 -- Azure Storage 之 Blob
Azure Queue Storage 基本用法 -- Azure Storage 之 Queue