据我所知，将现有数据库迁移到 SQL Azure 的关键点是：
- 表必须包含集群
指数。这是强制性的。
- 架构和数据迁移应该是
通过数据同步、批量复制来完成，
或 SQL Azure 迁移
向导，但不使用 SSMS 中的恢复选项。
- .NET 代码应该处理
与以下相关的暂时情况
SQL Azure。
- 登录名的创建位于
master 数据库。
- 某些 TSQL 功能可能不可用
支持。
我想这就是全部，对吗？在开始迁移之前我是否遗漏了任何其他考虑因素？
亲切的问候。
As far as I know the key points to migrate an existing database to SQL Azure are:
- Tables has to contain a clustered
index. This is mandatory.
- Schema and data migration should be
done through data sync, bulk copy,
or the SQL Azure migration
wizard, but not with the restore option in SSMS.
- The .NET code should handle the
transient conditions related with
SQL Azure.
- The creation of logins is in the
master database.
- Some TSQL features may be not
supported.
And I think that's all, am I right? Am I missing any other consideration before starting a migration?
Kind regards.
发布评论
评论（3）
更新 2015-08-06
其他注意事项：
不支持以下功能：
Update 2015-08-06
Additional considerations:
The following features are NOT supported:
我会添加带宽注意事项（针对初始人口和持续带宽）。这有成本和性能的考虑。
另一个潜在的考虑因素是任何长时间运行的进程或大型事务可能会受到 SQL Azure 相当神秘的限制技术的影响。
I'd add in bandwidth considerations (for initial population and on-going bandwidth). This has cost and performance considerations.
Another potential consideration is any long running processes or large transactions that could be subject to SQL Azure's rather cryptic throttling techniques.
另一个需要指出的关键领域是 SQL 作业。由于 SQL 代理未运行，因此不支持 SQL 作业。
迁移这些作业的一种方法是进行重构，以便工作角色可以启动这些任务。作业的内容可能会移至存储过程中以减少重新架构。然后，可以将辅助角色设计为在适当的时间唤醒并运行并启动存储过程。
Another key area to point out are SQL Jobs. Since SQL Agent is not running, SQL Jobs are not supported.
One way to migrate these jobs are to refactor so that a worker role can kick off these tasks. The content of the job might be moved into a stored procedure to reduce re-architecture. The worker role could then be designed to wake up and run at the appropriate time and kick off the stored procedure.