如何把 SQL Server 数据库迁移到到 Azure SQL ？
Windowsazure的SQLAzure和SQLServer拥有不同的体系结构，可以说是两个不同的产品。SQLAzure不完全支持或者尚不支持SQLServer的某些功能，这使得我们不能像平常一样使用bak文件还原的方式迁移数据库，也不能使用数据导入导出向导。很多SQLServer的特性在SQLAzure中不被支持。
那我们怎样才能将现有数据库迁移到SQLAzure上呢？
一、“将数据库部署到SQLAzure”向导
二、使用DAC迁移数据库架构
三、使用SQLAzureMW完美实施数据库迁移
1.选择分析并迁移/数据库
2.选择源数据库，以本地数据库school为例
3.选择要生成的数据库对象
4.打开高级选项，确保“生成表/数据”一项选择的是“表结构和数据”
5.检查将要生成脚本的数据库对象
6.脚本生成成功
7.链接目标数据库，我这里以SQLAzure上的SchoolAzure为例
8.点击下一步，执行脚本
9.打开SSMS查看结果，可以看到表、数据、主外键关系、约束、视图、存储过程都在。迁移成功！
AzureSQL的版本
AzureSQLDatabase是微软提供的SQL服务(PaaS)。最新的版本叫AzureSQLDatabaseV12，其实微软还是通过SQLServer2014来提供数据库服务：
上图中第一个数据库服务器是本地安装的SQLServer2014，第二个和第三个则是云上的AzureSQLDatabase。我们可以很清楚的看到，它们的版本是一样的。
但是可不要以为AzureSQLDatabase提供的数据库和本地安装版本是一样的噢。它们还是有不少差别的，这一点在迁移现有数据库时尤为重要。
由于提供的是在线的服务，所以AzureSQLDatabase可以快速的发布新特性，这些从不断更新的MSDN文档可见一斑。MS也强烈建议我们在和AzureSQLDatabase打交道时一定要用最新版的工具。笔者在刚开始使用了SQLServer2014中的SSMS(SQLServerManagementStudio)，结果连接AzureSQL后发现显示的信息和Azureportal对不上，安装最新版的SSMS后问题消失。
下面进入正题，看看迁移的过程中都需要什么样的工具，如何操作以及需要注意的事项。在此特别强调，旧数据库一般都是处于正在使用的状态，所以千万不要在真实的库上做各种实验。笔者所有的前期实验都是在通过恢复备份文件创建的测试库上完成的。
迁移要点分析
在云端创建AzureSQLServer
AzureSQLDatabase是运行在AzureSQLServer中的，所以我们要在Azure上先把AzureSQLServer创建好。操作过程比较简单，直接在Azure上添加SQLServer(logicalserver)就可以了，请注意选择合适的区域(这会影响访问速度)。
允许从本地访问AzureSQLServer
AzureSQLServer创建好以后，我们通过SSMS测试一下连接情况。当我们输入了正确的地址和用户信息后却弹出了一个提示框：
它提示我们，当前的IP不能访问Azure上的数据库服务器，并且让我以Azure账号登录并创建一条防火墙规则。
其实这是Azure提供的一个安全措施，它让你显式的指定哪些IP地址或者IP网段可以访问AzureSQLServer。
此时我们有两种解决方法：
1.点击对话框中的”Signin”，用Azure账户登录；然后点击”OK”，此时已经完成了防火墙规则的设置，SSMS已登录AzureSQLServer。这种方法一般用于开发和测试，只能添加当前客户端所使用的IP。
2.更加通用的方法是登录Azureportal，进入AzureSQLServer的配置界面，为防火墙添加规则。同样的，可以添加单个IP也可以一次添加一个网段：
兼容性处理
由于MSSQLServer版本众多，且云上的版本与本地版本也有差异，所以能不能迁移成功，主要看能不能找到并解决数据库之间的兼容性问题。
下面将详细的介绍笔者碰到的兼容性问题。
兼容性处理详情
数据库中设置的用户不存在
兼容性检查的报告显示下面的信息：
#p#分页标题#e#
其中的xxxx是数据库中设置的用户名。
这个错误的原因是用户被定义在本地的SQLServer中，数据库中一旦使用用户的信息，把数据库迁移到云上后，就找不到对应用户的定义了，所以就需要移除本地用户的信息。
不用担心数据库的访问问题，因为完成迁移后，你可以使用刚才创建的AzureSQLServer账号访问数据库。当然你也可以为一个数据库创建独立的访问账号，具体操作请参考MSDN。
不支持ExtendedProperty
兼容性检查的报告显示下面的信息：
其中的xxxx是数据库中一张表的名称。
这下可麻烦了，不支持ExtendedProperty！在笔者的数据库中有好几处都用到了这个特性。怎么办？只好一遍又一遍的查看程序。最后发现程序中没有使用这个特性，好像当时只是有人用它做了一些说明。还好，最终的结论是可以移除的。
创建clusteredindex
兼容性检查的报告显示下面的信息：
其中的xxxx是数据库中一张表的名称。
需要给表创建clusteredindex，这可不是一件小事情，因为任何对表的修改都可能会影响到程序逻辑，怎么办呢？网上的朋友们早就有了比较靠谱的解决方案，就是给表添加一列用来做clusteredindex，这样原来表中的列就没有发生变化：
其他
还有一些点，主要是和业务相关的，就不在此赘述。个人感觉绝大多数的问题在网上都有不同的解决方案，关键是要采用自己的业务能够接受的方式去解决问题。
接下来把所有对数据库的变更写成一个脚本文件，在正式的迁移中，直接在正式库上执行脚本文件。
迁移过程
MS提供了不同的工具进行兼容性检查、迁移等工作。我们这里统统使用SSMS(SQLServerManagementStudio)。
下面看看具体的操作步骤。
在SSMS中右键需要迁移的数据库，选择Tasks中的”DeployDatabasetoMicrosoftAzureSQLDatabase…”。
在打开的向导中点击“next”进入“DeploymentSettings”界面。
首先需要设置AzureSQLServer的连接地址和连接账号：
接下来设置迁移后的数据库名称和资源配置：
#p#分页标题#e#
注意AzureSQLDatabasesettings，MS把数据库使用的资源划分成了三个不同的类别：BASIC,Standard,Premium。每个类别中又划分了不同的收费标准，简单说就是你要使用更多更好的资源就要付更多的钱。当然也可以反过来说，如果我用的资源不多，付一点点钱就够了！
我们发现上图中的最后一行要求我们为*.bacpac文件指定一个存储路径。*.bacpac文件是迁移过程中生成的中间文件，当兼容性检查通过后，就把数据库中的所有内容都导出到这个文件中。从这个信息我们可以得知，无论采用何种迁移方式，其核心操作都是两步：先从本地数据库生成*.bacpac文件，再从*.bacpac文件恢复一个AzureSQLDatabase。
单击“Next”显示配置的详情，再下一步就开始兼容性检查。如果没有兼容性问题，就执行迁移操作。
我的数据库存在一些兼容性问题，所以显示了错误报告并终止了迁移操作：
点击“Result”列中的链接就能看到详细的报告，前面已经介绍过兼容性问题，直接执行我们处理兼容性问题的脚本文件，然后再试一次！
这次的执行已经没有错误提示了，其实后台已经开始了迁移过程。比较不方便的是这个过程没有详细的进度提示，只能耐心等待。我的经验数据是8G的库完成迁移大概是8-12小时。当然这和你连接Azure的带宽有很大的关系…
小编结语：
数据库一旦迁移到Azure上，以后的备份和还原工作就简单得多了，直接在WindowsAzure管理门户上导出.bacpac包，即可进行备份或迁移至本地。
更多内容尽在课课家教育！
