事务性复制问题

Question

我有一个问题，我正在管理两个SQL服务器。

1. 是主服务器(Publisher +分发服务器)
2. 客户端服务器(订阅服务器)

客户基本上是由从我们那里购买数据的客户拥有的。

两台服务器都使用事务复制相互复制。

只将单个数据库的选定表从主服务器复制到客户端服务器。

基本上有几个问题我想讨论。

问题1：

当我添加或删除任何数据表并获取复制快照时，所有数据库都从客户端消失，然后在20-30分钟内重新构建(我只有有限的访问权限，所以不要获取日志)。

问题2：

当我重新初始化订阅时，完成它需要花费大量时间，并且在监视中显示了部分应用的表脚本。

问题3：

Publisher to Distributor显示出较高的命令和事务计数，但实际上在分发服务器上订阅者命令和事务计数超过100‘S，比publisher部分低一倍。

问题4：

发布服务器与分发服务器之间的延迟非常高(约为5+分钟)(Server-1)，并跳转到7分钟，然后自动减少，停留在一些秒内，但平均时间非常高。分发服务器-订阅者延迟似乎很好。

问题5：

主数据库的日志大小增加并占据3.5GB左右的空间(通常为3GB，空闲空间为80-87% )，数据文件大小是否也会增加，现在为4 GB+ (通常为3.3-3.5GB)

Answer 1

首先，您可以为每个监视服务器事务复制的‘ss文章设置金丝雀表和其他事务复制的详细监视。本文中最简单的步骤金丝雀表被描述为：

很容易构建自己的系统来跟踪每个发布的复制延迟。以下是最简单版本的成分：

• 向每个发布添加名为dbo.Canary_PubName的表
• dbo.Canary_PubName只有一行，其中包含一个datetime列。
• 发布服务器上的Server代理作业每分钟将日期时间更新为当前时间戳
• 订阅服务器上的Server代理作业每分钟检查一次dbo.Canary_PubName，并提醒当前时间与时间戳之间的差异是否大于N分钟

然后查看正在复制的表上发生的活动。听起来，大多数问题都与非常高的活动有关--日志大小从仅使用13-20%的3GB移动到3.5GB (这意味着所有3GB都已使用)是大型事务的指示器，这可能会使您的复制带宽饱和。

另外，如果它们在重新初始化时需要20-30分钟来复制，这是它们的大小和您的免费带宽的组合。

因此，一般的解决办法是：

• 增加带宽
• 减少数据量
  • 使用尽可能最小的基于整数的键，只需使用说明复制查找表，而不是在表中包含说明。
    • 在可能的情况下，然后是TINYINT，然后是SMALLINT，然后是INT，然后是BIGINT。

- Replicate indexed views instead of actual tables (publisher = indexed view, subscriber = table) - send over only the required columns, and only the required rows.
- Don't use NCHAR/NVARCHAR unless you need to - use CHAR/VARCHAR when you know you only have, or perhaps even should have, no UCS-2 "Unicode" data.  
    - Use CHAR when the average size of data is within 2 bytes of the maximum field size, since VARCHAR has a 2 byte overhead to store length

• 减少复制数据上的事务数
  • 不管发生了什么，都会导致复制表上的所有活动，分析一下。需要吗？是否可以重写以减少复制的数据量？
    • 不要超过一次地触摸同一行，例如，代替INSERT、UPDATE，只对最后一个表只进行一次插入--在此之前，可能在#temp表中工作吗？以此类推。

- If they don't absolutely need up to the minute data on any given table, then don't replicate your the core tables that get all this activity.  
    - For each non-realtime-required table, create reporting tables on the publisher that get updated only every so often (once a week, once a day, once an hour, whatever), and replicate those.
    - And make sure to carefully use only the UPDATEs, INSERTs, and DELETEs that are required - the goal is to minimize replication load.
    - Don't use MERGE; it has too many issues.

• 将表拆分成多个发布，所以每次必须添加或删除每个表时，都不会对每个表进行快照和重新初始化。
  • 也就是说，如果在发布C中添加/删除/更改项目，则需要重新初始化和快照该发布，但出版物A、B、D、E和F不受此影响。
    • 因此，它移动的数据更少，这反过来又需要更少的时间。
    • 订阅者保留对所有其他出版物中所有文章的访问权限。
    • 因此，按照功能用法将它们分开；如果大多数时候都同时使用表A、E和G，而C和D不涉及大多数这些查询，那么这是一个自然的分离，会使您的客户更快乐；至少在重新初始化任何一个集合时，至少有一些函数会继续畅通无阻。

• 增加带宽