Table 架构对事务复制性能的影响

Table schema affect on transactional replication performance

我们已经在 WAN 上实施了事务复制(推送模型),并且有时会在特定 table 的批量更新期间看到速度变慢(即我们看到大量 'commands not replicated' 对于那个特定的 table)。有问题的 table 的格式为

CREATE TABLE [Table](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [FrequentlyUpdated_0] [float] NULL,
    [FrequentlyUpdated_1] [float] NULL,
    [FrequentlyUpdated_2] [float] NULL,
    [RarelyUpdated_0] [varbinary](max) NULL,
    [RarelyUpdated_1] [varbinary](max) NULL,
    [RarelyUpdated_2] [varbinary](max) NULL
)

其中 RarelyUpdated_n 列可以包含相对于 FrequentlyUpdated_n 列相当大的数据(例如 20 MB)。现在的问题是,如果我们将有问题的 table 分成两个不同的 table 是否会提高性能,如下所示

CREATE TABLE [FrequentlyUpdatedTable](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [FrequentlyUpdated_0] [float] NULL,
    [FrequentlyUpdated_1] [float] NULL,
    [FrequentlyUpdated_2] [float] NULL
)

CREATE TABLE [RarelyUpdatedTable](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [RarelyUpdated_0] [varbinary](max) NULL,
    [RarelyUpdated_1] [varbinary](max) NULL,
    [RarelyUpdated_2] [varbinary](max) NULL
)

或者换句话说:性能取决于行数据大小还是仅取决于更新数据的大小?

PS。设置中涉及的所有服务器负载都不重,因此我怀疑性能问题与 I/O.

有关

Does performance depend on row data size or just the size of the updated data?

事务复制通过读取事务 log.when 读取该日志来工作,它将尝试过滤掉标记为复制的文章记录,并将这些记录以 INS/DEL/UPD 命令形式发送给分发者

将 table 分成两个 table 以减少将传输到分发服务器的数据大小无济于事,因为当您更新时,SQL 不会传输整个行,但仅更改为 UPD 命令的部分

您必须先解决复制拓扑中的瓶颈问题,才能对瓶颈有更多的了解。

有很多方法可以识别瓶颈..

1.Tracer 代币: 可以插入tracer tokens监控流量

2.After 确定延迟,您可以通过记录他们的操作来排除个别代理的故障

How to enable replication agents for logging to output files in SQL Server

3.finally ,你也可以调整 settings.Say 例如,如果你已经确定日志 reader 在一个命令中分组了几个事务并且你想改变它来测试和改进 latency.You 也可以在此处调整设置

Enhance Transactional Replication Performance