导读：SQL Server数据迁移的知识之前已经为大家介绍了很多，比如SQL Server数据库迁移方法，接下来就为大家详细介绍SQL Server数据迁移至云端应用技巧，以方便大家在以后的实际工作中做好SQL Server数据库的迁移工作。
微软的SQL Azure并不完全支持SQL Server 2005或SQL Server 2008的所有功能，因此，在数据转移的时候必须十分小心。目前SQL Azure也还没有提供任何管理工具(除了SQL Server Management Studio，当然不能完全靠它的Object Explorer来做转移)做这类的管理作业，微软在Codeplex网站上有一个SQL Azure Migration Wizard的工具，到是十分适合采用(这部分我们稍后会提到)。
将既有的数据库数据转换到SQL Azure上面，或是把SQL Azure上面的数据转下来，这都牵扯到数据的输入和输出。假如我们单单针对将数据输入和输出的作法来看，对天天在处理数据库的行家而言，这并不是甚么新鲜的事了，方法也很多，而传统的大批数据转换的做法也大都能适用，例如：
运用SQL Server提供BCP工具程序(请参考MSDNLibray的BCP Utility)。
用SSIS(SQL integration server service，使用Visual Studio2008)。
运用ODBC and ADO.Net 提供的API 功能。
另外，微软的Sync Framework也是一个好选择。这一点我们会在稍后作说明。
云端解决方法
每次读取一次记录然后再写入一次记录，还不如一次性读入一堆数据放置在云端，然后再以本地的方式做大笔数量的写入。
图1 使用Worker role做Bulk传送
如图1所示，基于这个原理运用Web Role作为用户的接口负责读取上传的数据，并将数据放入Blobs中，然后产生Jobs的工作项。至于Worker Role的部分则一直负责观察Jobs的工作项目，一旦有工作项目进入到Blobs中，就会把数据读出来，再运用BCP的工具程序一次性写入到目标数据库中，完成一个Jobs的工作。
使用Blobs
我们使用Blobs是因为它被设计来储存大量的文字及二进制数据格式。非常简单的读取方式，让我们只要运用REST API就能上传、管理、组织及维护这些数据。Blobs有三种资源，分别是Account、Containers及Blobs，它的架构观念简洁且存取容易，因此很容易被拿来再运用。所谓的拿来再运用并非空穴来风，其实它在设计之初就有这个预先的计划，提供非结构化的二进制的庞大存储器;让它具有不受任何限制的基础，可以被用来储存任何数据或索引。Blobs有二种，Block blob能存储最高200GB的数据，而Page Blob能支持最高1TB的数据，主要用于随机读写用。例如Windows Azure XDrive就是运用Page Blob做出来的一块类似NTFS格式硬盘的仿真装置，相当能够吸引哪些熟悉文件系统的人来使用它。
SQL Azure 的存取方式
SQL Azure采用DB Service的方式，与Amazon Web Services的Simple DB类似，可以只用Database的Service(不过存取的命令就不同了，Simple DB是透过Web REST或SOAP接口，而SQL Azure则是透过OLE DB/ODBC/ADO.NET，并透过T-SQL语法来做存取)。与Google App Engine的存取模式不同，Google App Engine内建的Database不能单独存取，只能透过部署在App Engine上面的Application进行存取。
既然可以进行独立存取，便可运用Microsoft Cloud Computing开发Web Application，那样将会有两种模式：
(1)Web Application部署在Windows Azure，并由SQL Azure提供Database Services。
(2)Web Application部署在自家环境，并由SQL Azure提供Database Services。
然而，不管使用哪一种模式，Web Application都是透过传统SQL Server的1433 Port来存取SQL Azure。
因此，若是Web Application or Developer在防火墙里面对外的联机被管制的话，那么使用上述第一个模式会是比较方便开发。
不管采用哪一种connecting String，简单来说，该services就是listen 在tcp:servername.ctp.database.windows.net:1433这个位置。
上文中介绍到的SQL Server数据迁移至云端应用技巧并不是万能的，可能在有些情况下就不适用，希望大家灵活掌握，灵活运用，为以后的数据库迁移工作带来方便。