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 复制。

快照复制

特点

不跟踪数据更改，每次应用快照都完全覆盖现有数据。
过程不一致，结果一致。

适合场景

数据更改量大，但很少更改，允许一定时间的滞后。

资源占用

因为不跟踪数据更改，所以连续开销比事务复制低。但是如果数据集非常大，也需要使用大量资源生成和应用快照。

表锁

整个快照生成过程中都是用共享锁。

事务复制

特点

通过SQL Server事务日志跟踪更改。
过程一致，结果一致。

适合场景

数据更改频繁，数据复制接近实时。
服务器到服务器的环境。
提高可扩展性和可用性
数据仓库和报表
集成多个站点的数据
集成异构数据
将批处理的负载分离出去

资源占用

连续开销比快照复制高。

表锁

事务复制默认使用并发快照处理，在整个初始化快照生成过程中并不保留共享锁，期间用户可以继续工作。

合并复制

特点

通过触发器和源数据表跟踪数据更改。
过程不一致。
不同站点可以脱机修改同一数据，在合并更新时需要处理冲突。

适合场景

不同站点接收数据，然后脱机更改数据，再与发布服务器和其他订阅服务器同步更改。
服务器到客户端的环境。

表锁

不使用锁。

其它 SQL Server 高可用性和数据恢复技术

故障转移集群

通过添加相关的硬件，可以使用故障转移集群保证数据中心内的高可用性。

故障转移集群中的所有SQL Server实例，在网络上显示为一个节点。

数据库镜像

数据库镜像是一个软件方案。它有一个主体服务器和一些镜像服务器。

在主体服务器可用的时候，镜像服务器是不能处理读写请求的。

日志传输

日志传输可以将主数据库的事务日志备份，自动发送给多个辅助数据库。

主数据库可用的时候，辅助数据库是不支持写数据。

AlwaysOn高可用性组

在SQL server 2012后，新增了AlwaysOn高可用性组特性。

辅助副本复制的是主体节点的完整数据库，不能选择复制部分数据到辅助节点。它的辅助副本可以用于报表和备份，但是不支持写数据。

总结

从上面的对比中，Reinhard 认为，事务复制更适合我们的应用场景。它能够在企业层构建可扩展、高可用、松耦合的集成生态系统。