，即子表复制过程。对于Secondary数据分片，只需要通过从Primary拷贝数据来增加副本；对于Primary，首先需要从另外两个副本中选择一个Secondary作为新的Primary，接着执行和Secondary数据分片Reconfiguration一样的过程。另外，这里需要进行优先级的控制，比如某个数据分片只有一个副本，需要优先复制；某个数据分片的Primary不可服务，需要优先执行从剩余的副本中选择Secondary切换为Primary的过程。当然，这里还需要配置一些策略，比如只有两个副本的状态持续多长时间开始复制第三个副本，SQL Azure目前配置为两小时。
3, 负载均衡
新的数据节点加入或者发现某个节点负载过高时，总控节点启动负载均衡过程。数据节点负载影响因素包括：读写个数，磁盘/内存/CPU/IO使用量等。这里需要注意的是，新机器加入时需要控制子表迁移的节奏，否则大量的子表同时迁移到新加入的机器导致系统整体性能反而变慢。
SQL Azure由于可以控制每个逻辑SQL Azure实例，即每个子表的大小，因此，为了简便起见，可以不实现子表分裂，很大程度上简化了系统。
4, 事务
SQL Azure支持数据库事务，数据库事务相关的SQL语句都会记录BEGIN TRANSACTION，ROLLBACK TRANSACTION和COMMIT TRANSACTION相关的操作日志。在SQL Azure中，只需要将这些操作日志同步到其它副本即可，由于同一时刻同一个数据分片最多有一个Primary提供写服务，不涉及分布式事务。SQL Azure系统支持的事务级别为READ_COMMITTED。
5, 多租户干扰
云计算系统中多租用的操作相互干扰，因此需要限制每个SQL Azure逻辑实例使用的系统资源：
1, 系统操作系统资源限制，比如CPU和内存。超过限制时回复客户端要求10s后重试；
2, SQL Azure逻辑数据库容量限制。每个逻辑数据库都预先设置了最大的容量，超过限制时拒绝更新请求，但允许删除操作；
3, SQL Server物理数据库数据大小限制。超过该限制时返回客户端系统错误，此时需要人工介入。
与SQL Server的差别
1, 不支持的操作：Microsoft Azure作为一个针对企业级应用的平台，尽管尝试支持尽量多的SQL特性，仍然有一些特性无法支持。比如USE操作：SQL Server可以通过USE切换数据库，不过在SQL Azure不支持，这时因为不同的逻辑数据库可能位于不同的物理机器。具体可以参考SQL Azure vs. SQL Server。
2, 观念转变：对于开发人员，需要用分布式系统的思维开发程序，比如一个连接除了成功，失败还有第三种不确定状态：云端没有返回操作结果，操作是否成功我们无从得知，又如，天下没有像SQL这么好的免费午餐；对于DBA同学，数据库的日常维护，比如升级，数据备份等工作都移交给了微软，可能会有更多的精力关注业务系统架构。