sql azure感受1(数据导入)

开始用SQL AZURE,如何把本地数据库导入到SQL AZURE中呢?

本地数据库是SQL 2008 R2 ,SQL AZURE看介绍应该也是

1,导入导出,很慢,而且出错

2,使用SQLAZUREMW,http://sqlazuremw.codeplex.com/ 速度明显快多了,简单,没有错误

具体介绍

摘自:http://msdn.microsoft.com/zh-cn/magazine/ff872379.aspx

使用 SQLAzureMW

George 创建了 SQLAzureMW 来帮助我们的客户完成 SQL 数据库迁移过程。图 6 显示了运行中的 SQLAzureMW。

图 6 使用 SQLAzureMW

SQLAzureMW 分析 SQL Server 数据库是否存在与 SQL Azure 的兼容性问题。它还允许您将数据库对象和数据从源数据库迁移到 SQL Azure。

通过使用 SQLAzureMW，数据库开发人员可以了解在将其数据库迁移到 SQL Azure 时将需要执行多少工作。如果 SQLAzureMW 标记出与 SQL Server 2000 或 2005 数据库的许多兼容性问题，我们建议首先将您的数据库升级到 SQL Server 2008，然后再迁移到 SQL Azure。已有很多文献说明迁移到 SQL Server 2008 的过程，您可以利用大量的指导和专业意见。有关迁移到 SQL Server 2008 的更多信息，请参见 SQL Server 2008 升级技术参考指南 (microsoft.com/­downloads/details.aspx?FamilyID=66d3e6f5-6902-4fdd-af75-9975aea5bea7)。在 MSDN SQL Server 开发人员中心 (msdn.microsoft.com/sqlserver) 也提供了丰富的资源。

请注意，如果您没有 SQL Server 2008 R2，则您可以继续升级过程，而并不会因此受到影响。只需下载 SQL Server 2008 R2 Express Edition，并执行并行升级过程即可。

还有其他一些较好的资源可以帮助数据库开发人员了解 SQL Server 与 SQL Azure 之间的区别，比如哪些部分兼容和哪些部分不兼容，以及一般指导原则和限制等，这些资源包括msdn.microsoft.com/library/ee336281 处提供的 Transact-SQL 参考（SQL Azure 数据库）以及 msdn.microsoft.com/library/ee336245 处介绍的一般指导原则和限制。

无论您是决定首先升级到 SQL Server 2008 还是直接从 SQL Server 2000 或 2005 进行迁移，您都需要使用合适的方式来分析数据库的兼容性问题并生成与 SQL Azure 兼容的 SQL。这就是 SQLAzureMW 的真正用武之地。SQLAzureMW 不仅能分析数据库，在您想检查动态 SQL 的兼容性问题时，它还会分析 SQL Profiler 跟踪文件。

在迁移实验中，只需要极少修改，或根本无需修改，我们就能够将所有 SQL 数据库（SQL Server 2000 和 SQL Server 2005）迁移到 SQL Azure。剩余的两个需要解决的问题是身份验证和 SQL Azure 资源限制。

身份验证问题是由于 SQL Azure 仅支持 SQL 身份验证而不支持 Windows 身份验证所致。以我们的一个客户为例，这个客户必须修改连接字符串以反映用户名和密码而不是可信连接。例如，我们一开始看到了如下内容：

<add key="ConStr"   value="server=DbSvr;database=CRMDB;Trusted_Connection=yes" />We simply changed the connection string to something like this:<add key="ConStr"   value="Server=avl6qnn22s.database.windows.net;Database=CRMDB;User ID=WebSvrAdmin@avl6qnn22s;Password=password;Trusted_Connection=False;" />To get more information on connecting to SQL Azure using ADO.NET, see msdn.microsoft.com/library/ee336243.

资源限制

对于一些应用程序而言，解决 SQL Azure 资源限制需要执行的工作略多一些。有些应用程序采取仅当需要时且尽可能拖延到最后时刻才连接到 SQL 数据库这样的最佳实践，这些应用程序可以快速高效地执行所有事务并尽快释放连接，因此 SQL Azure 限制就不成为问题。相反，有些应用程序在启动时就建立与 SQL 数据库的连接，并在程序的整个生存期内或长时间持有连接，这些应用程序必须进行修改以实现重试逻辑，或进行重构以采取最佳实践并且不占用资源。

我们经常遇到一种误解，就是认为 SQL Azure 仅当连接空闲五分钟后才会断开连接。SQL Azure 在确定何时断开应用程序连接时要考虑几个因素，包括过度的资源占用、长时间运行的查询、长时间运行的单一事务以及空闲连接。

SQL Azure 团队将继续调整资源限制参数，但实际效果是应用程序必须在其自身中构建重试逻辑，因为 SQL Azure 将强制超过其资源利用参数的任何应用程序断开连接。

一般来说，如果 SQL Azure 对连接做出限制，它会提供特定的错误消息。有关错误的完整列表，请参见msdn.microsoft.com/library/ff394106。

如果您有大量小事务，则应使用以下模式：

1. 使用连接池。连接池管理器将为您把连接保持为打开状态，并且打开和关闭连接对应用程序性能的影响将很小或根本无影响。
2. 尽可能缩短连接持续时间。打开连接，执行您的事务，关闭连接。
3. 对整个数据库活动使用 try-catch 模式。
4. 如果合适，捕获异常并重试事务。
5. 记录您的故障和异常，以帮助解决问题。确保获取 UTC 时间戳（或提供时间和时区）、连接上下文 ID 和异常编号。

SQLAzureMW 就是必须处理 SQL Azure 中的资源限制的一个典型应用程序。如前所述，SQLAzureMW 可以将内部部署 SQL 数据库迁移到 SQL Azure。如果您要迁移包含超过 1,000 个表、1,500 个存储过程和成百万行数据的数据库，则根据实际需要上载的数据量，花费的时间很可能要超过五个小时。

在这种情况下，SQLAzureMW 可以对 SQL Azure 以及要通过 BCP 迁移的数据执行超过 2,500 条的 TSQL 语句。在一条语句（或一个事务）中执行超过 2,500 条 TSQL 语句很可能会超出 SQL Azure 资源限制参数，从而导致连接终止。

SQLAzureMW 就是针对此问题的解决方案，它将事务分成较小的块，并一直运行，直至 SQL Azure 终止连接。SQLAzureMW 在遇到连接错误时，将与 SQL Azure 重新建立新连接，并接着最后一条成功的命令继续执行处理。同样，当使用 BCP 将数据上载到 SQL Azure 时，SQLAzureMW 将数据分块成较小的部分，并使用重试逻辑算出连接被关闭之前最后一条成功上载的记录。然后，它让 BCP 重新启动包含下一组记录的数据的上载。