导读：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数据迁移至云端应用技巧并不是***的，可能在有些情况下就不适用，希望大家灵活掌握，灵活运用，为以后的数据库迁移工作带来方便。
【编辑推荐】
