Dynamics AX 2012 性能优化之 SQL Server 复制
分析数据滞后
在博文 Dynamics AX 2012 在BI分析中建立数据仓库的必要性 里，Reinhard 阐述了在 AX 的 BI 分析过程中，建立数据仓库的必要性。
数据仓库将分析的工作负载，从事务的工作负载中分离出来，让企业能够整合来自多个数据源的数据。
但是从 AX 数据库中抽取数据到数据仓库的时候，Reinhard 发现耗时非常长。Reinhard 认为主要有三个原因：
- 我们不敢贸然在AX生产环境的数据库层面做优化
- 数据基数大
- 需要新增和更新的数据多
因为数据抽取对正式环境的性能影响非常大，并且耗时长，所以我们只能选择在下班后去执行ETL作业。这样做的缺点也是显而易见的，无论我们的报表跑得多快，但是展示的数据总是滞后的。
SQL Server 复制
有没有什么方案，能够实时地展示数据，又对正式环境的性能影响小呢？这就是 Reinhard 在本文中要说的 SQL Server 复制。
SQL Server 复制 是一项非常成熟的技术，它主要应用在以下几个场景中：
- 负载转移。将数据复制到其他数据库服务器，来减少当前服务器的负载。比如创建只读的报表环境。
- 合并数据。有多个门店，每个门店的数据库服务器都维护着自己的数据。总部需要将所有门店的数据合并到一起。
- 故障转移。
Reinhard 这里的应用场景其实就是负载转移。将所需的数据从生产库发布到只读的复制库中，然后在复制库上执行数据抽取作业，这样就将一部分工作负载，从事务的工作负载中分离出来。
复制的类型
在 复制类型 中，微软介绍了三种复制类型，分别是：
- 事务复制
- 合并复制
- 快照复制
这三种复制都有各自的特点，需要根据自身的实际环境和业务场景来选择，并且要注意复制过程中的表锁。主要考虑因素有：
- 要复制的数据类型，数量，和更新频率
- 订阅服务器上的数据是只读的，还是可以更新的
- 涉及到的计算机的数量和位置
Reinhard 这里简单说说不同复制类型的特点，详细信息还请参考微软官方文档 SQL Server 复制 。
快照复制
特点
- 不跟踪数据更改，每次应用快照都完全覆盖现有数据。
- 过程不一致，结果一致。
适合场景
数据更改量大，但很少更改，允许一定时间的滞后。
资源占用
因为不跟踪数据更改，所以连续开销比事务复制低。但是如果数据集非常大，也需要使用大量资源生成和应用快照。
表锁
整个快照生成过程中都是用[共享锁](https://msdn.microsoft.com/en-us/library/ms175519.aspx#Shared Locks)。
事务复制
特点
- 通过SQL Server事务日志跟踪更改。
- 过程一致，结果一致。
适合场景
- 数据更改频繁，数据复制接近实时。
- 服务器到服务器的环境。
- 提高可扩展性和可用性
- 数据仓库和报表
- 集成多个站点的数据
- 集成异构数据
- 将批处理的负载分离出去
资源占用
连续开销比快照复制高。
表锁
事务复制默认使用并发快照处理，在整个初始化快照生成过程中并不保留共享锁，期间用户可以继续工作。
合并复制
特点
- 通过触发器和源数据表跟踪数据更改。
- 过程不一致。
- 不同站点可以脱机修改同一数据，在合并更新时需要处理冲突。
适合场景
- 不同站点接收数据，然后脱机更改数据，再与发布服务器和其他订阅服务器同步更改。
- 服务器到客户端的环境。
表锁
不使用锁。
其它 SQL Server 高可用性和数据恢复技术
故障转移集群
通过添加相关的硬件，可以使用故障转移集群保证数据中心内的高可用性。
故障转移集群中的所有SQL Server实例，在网络上显示为一个节点。
数据库镜像
数据库镜像是一个软件方案。它有一个主体服务器和一些镜像服务器。
在主体服务器可用的时候，镜像服务器是不能处理读写请求的。
日志传输
日志传输可以将主数据库的事务日志备份，自动发送给多个辅助数据库。
主数据库可用的时候，辅助数据库是不支持写数据。
AlwaysOn高可用性组
在SQL server 2012后，新增了AlwaysOn高可用性组特性。
辅助副本复制的是主体节点的完整数据库，不能选择复制部分数据到辅助节点。它的辅助副本可以用于报表和备份，但是不支持写数据。
总结
从上面的对比中，Reinhard 认为，事务复制更适合我们的应用场景。它能够在企业层构建可扩展、高可用、松耦合的集成生态系统。