最近有个维护的项目需要把 SQL Server 2012 的数据库迁移到 Azure SQL 上去。主要是因为租用的主机到期，而运营商停止了主机租赁业务，看来向云端的迁移是大势所趋啊！经过一番折腾最终成功迁移，但过程可谓是一波三折。故在此分享这次迁移中碰到的点点滴滴，希望对朋友们有所帮助。
Azure SQL 的版本
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 后问题消失。
下面进入正题，让我们把一个8G大小的陈年老库一步步的迁移到云上。看这过程中都需要什么样的工具，如何操作以及需要注意的事项。在此特别强调，旧数据库一般都是处于正在使用的状态，所以千万不要在真实的库上做各种实验。笔者所有的前期实验都是在通过恢复备份文件创建的测试库上完成的。
迁移要点分析
在云端创建Azure SQL Server
Azure SQL Database 是运行在 Azure SQL Server 中的，所以我们要在 Azure 上先把 Azure SQL Server 创建好。操作比较简单，直接在 Azure 上添加 SQL Server (logical server) 就可以了，请注意选择合适的区域(主要影响访问速度)。
允许从本地访问 Azure SQL Server
Azure SQL Server 创建好以后，我们通过 SSMS 测试一下能不能连上。当我们输入了正确的地址和用户信息后却弹出了一个提示框：
它提示我们当前的 IP 不能访问 Azure上的数据库服务器，并且让我以 Azure 账号登录并创建一条防火墙规则。
其实这是 Azure 提供的一个安全措施，它让你显式的指定都哪些IP地址或者IP网段可以访问 Azure SQL Server。此时我们有两种做法。
- 点击对话框中的 "Sign in"，用Azure账户登录。然后点击 "OK"，此时已经完成了防火墙规则的设置，SSMS 已登录 Azure SQL Server。这种方法一般用于开发和测试，只能添加当前客户端所使用的 IP。
- 更加通用的方法是登录 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。
不支持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).
其中的 xxxx 是数据库中一张表的名称。
这下可要了命了，不支持 Extended Property！在笔者的数据库中有好几处都用到了这个特性。怎么办？只好一遍又一遍的查看程序。最后发现程序中没有使用这个特性，好像当时只是有人用它做了一些说明。最终的结论是可以移除。
创建 clustered index
兼容性检查的报告显示下面的信息：
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 提供的工具还算比较完善，网络上的各种已知问题解决方案也很详尽。所以尽管笔者碰到了很多的问题，但没有卡壳的地方，总算磕磕绊绊的完成了数据库迁移的任务。