Recently, there is a maintenance project that needs to migrate the database of SQL Server 2012 to Azure SQL. The migration process can be described as twists and turns, so I will share the bits and pieces of this migration, hoping to help friends.
Article source: Grape City Product Technology Community
Version of Azure SQL
Azure SQL Database is a SQL-as-a-Service (PaaS) provided by Microsoft. The latest version is called Azure SQL Database V12. In fact, Microsoft still provides database services through SQL Server 2014:
The first database server in the image above is a local installation of SQL Server 2014, and the second and third are Azure SQL Database on the cloud. We can clearly see that their versions are the same.
But don't provide the same database as the locally installed version for Azure SQL Database. There are still quite a few differences, which is especially important when migrating an existing database.
Because it provides an online service, Azure SQL Database can release new features quickly, which is evident from the constantly updated MSDN documentation. MS also strongly recommends that we must use the latest version of the tool when dealing with Azure SQL Database. The author just started using SSMS (SQL Server Management Studio) in SQL Server 2014. After connecting to Azure SQL, I found that the displayed information did not match the Azure portal. After installing the latest version of SSMS, the problem disappeared.
Let's go to the topic and see what tools are needed in the migration process, how to operate and what to pay attention to. It is especially emphasized here that the old database is generally in the state of being used, so do not do various experiments on the real library. All of the author's previous experiments were done on a test library created by restoring backup files.
Migration point analysis
Create Azure SQL Server in the cloud
Azure SQL Database runs in Azure SQL Server, so we need to create Azure SQL Server on Azure first. The operation process is relatively simple, you can directly add SQL Server (logical server) on Azure, please pay attention to selecting the appropriate region (this will affect the access speed).
Allow on-premises access to Azure SQL Server
After the Azure SQL Server is created, let's test the connection through SSMS. When we entered the correct address and user information, a prompt box popped up:
It prompted us that the current IP cannot access the database server on Azure, and asked me to log in with the Azure account and create a firewall rule.
In fact, this is a security measure provided by Azure, which allows you to explicitly specify which IP addresses or IP network segments can access Azure SQL Server.
At this point we have two solutions:
1. Click "Sign in" in the dialog box to log in with your Azure account; then click "OK", the firewall rule setting has been completed, and SSMS has logged in to Azure SQL Server. This method is generally used for development and testing, and only the IP used by the current client can be added.
2. A more general method is to log in to the Azure portal, enter the configuration interface of Azure SQL Server, and add rules for the firewall. Similarly, you can add a single IP or a network segment at a time:
Compatibility Handling
Since there are many versions of MS SQL Server, and the version on the cloud is different from the local version, whether the migration can be successful depends on whether the compatibility between databases can be found and solved.
The following will introduce in detail the compatibility problems I encountered.
Compatibility Handling Details
The user set in the database does not exist
The Compatibility Check report shows the following information:
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提供的工具还算比较完善，网络上的各种已知问题解决方案也很详尽。所以尽管笔者碰到了很多的问题，但没有卡住的地方，总算磕磕绊绊的完成了数据库迁移的任务。