问题标签 [transactional-replication]

我能够使用 SSMS 配置事务复制并且它工作正常。但我想使用脚本对其进行配置，以便从我的 c#/vb 应用程序中使用它。

有没有办法做到这一点？

我们在使用 SQL Server 进行横向扩展时遇到问题。这主要是因为几个原因：1）数据结构设计不佳，2）繁重的工作和业务/处理逻辑都是在 T-SQL 中完成的。我们聘请了一位来自 Redmond 的 Microsoft SQL 人员验证了这一点，该人员在我们的服务器上执行分析。我们实际上是通过不断增加命令超时来解决问题，这很荒谬，而且不是一个好的长期解决方案。从那以后，我们制定了以下策略和一系列阶段：

第 1 阶段：将硬件/软件放在问题上以止血。

这包括一些不同的东西，比如缓存服务器，但我想在这里问每个人的具体内容与在新 SQL 服务器上实现双向事务复制有关。我们有两个想要实现它的用例：

1. 我们正在考虑在这个新的 SQL“处理框”上运行长时间运行（和表/行锁定）的 SELECT，并将它们放入缓存层并让 UI 从缓存中读取它们。这些 SELECT 生成报告并在网络上返回结果。

2. 大多数业务逻辑都在 SQL 中。我们对执行处理逻辑的 SELECT、INSERT、UPDATE 和 DELETE有一些长时间运行的查询。最终结果实际上只是处理完成后的一堆 INSERT、UPDATE 和 DELETE（大量游标）。想法是平衡这两个服务器之间的负载。

我有一些疑问：

1. 这些是双向事务复制的好用例吗？

2. 我需要确保这个解决方案能够“正常工作”，而不必担心冲突。在这个解决方案中哪里会出现冲突？我已经阅读了一些关于重置身份种子的增量以防止冲突的文章，这是有道理的，但是它如何处理更新/删除或其他可能发生冲突的地方？

3. 我可能会遇到哪些其他问题，我们需要注意什么？

4. 这个问题有更好的解决方案吗？

第 2 阶段：将逻辑重写到 .NET 中，并优化 SQL 存储过程以仅执行基于集合的操作，因为它也应该如此。

这显然需要一段时间，这就是为什么我们想看看是否可以采取一些初步措施来阻止用户所经历的痛苦。

谢谢。

在此页面上，Microsoft 声明：

本主题介绍 SQL Server 2012 中仍然可用的已弃用复制功能。这些功能计划在 SQL Server 的未来版本中删除。不推荐使用的功能不应在新应用程序中使用。

可更新订阅，包括即时更新和使用快照和事务发布的排队更新。

我们建议您改用对等事务复制。

在这个页面上，微软甚至教你如何启用可更新订阅。

启用更新订阅

在新建发布向导的发布类型页面上，选择 具有可更新订阅的事务性发布。

但是，我只是在 SQL Server 2012 的发布类型页面上找不到具有可更新订阅的复制类型事务发布，请参见下图：

任何人都可以确认，我们是否在 SQL Server 2012 中具有此功能？

谢谢！

我正在使用 SQL Server 2008 并进行了事务复制设置。我需要能够在发布者上执行复制前脚本，然后在订阅者上执行复制后脚本。事务复制可以做到这一点吗？

我在这里找到了另一篇文章，但是这里的 post 脚本只有在 snapsnot 交付给订阅者时才会执行。

我在第三方数据库中有一个非常大的、非分区的、事务复制的表，我对其进行管理但无法更改。

虽然我不能更改发布者，但我想在订阅者上对这个表进行分区。我发现了很多与保留已在发布者上以这种方式设置的表的分区有关的文档，但我没有看到与此相关的任何内容。

我不太关心这样做的机制，而是关心可能会咬我的长期后果。

有没有人成功地做到了这一点，或者我会在 3 个月后恨自己吗？

我们正在使用事务复制。我有名为 D1 的发布者数据库和名为 D2 的订阅者数据库。D1 正在 DR 环境中传送日志。我们在发布者 (D1) 上启用了“与备份同步”选项。现在我的数据已经备份，但由于某种原因它没有发送到分发服务器，D1 崩溃了。我们正在恢复不同服务器上的备份数据库并再次设置发布和订阅。

那么，任何尚未进入分发数据库的数据现在都将被复制还是不复制？

如果我们删除发布并删除 D1 数据库并使用“保留复制设置”从 DR 环境中恢复它，尽管发布已经存在，但它不会复制数据..

我到处搜索，但找不到答案。我知道 LocalDB 不能成为合并复制的订阅者。但是事务复制呢？

我已经尝试使用 SQL Server Management Studio 和 RMO 编程来创建对具有事务复制类型的发布的拉取订阅，但它一直告诉我“此 SQL 服务器实例上未安装复制”。在安装过程中，我或用户无法选择复制功能。并且重新安装 LocalDB 不会有任何帮助。

我知道可以使用同步框架来完成这项工作，但这对我来说是新事物，而且我已经在我之前的软件版本中将 LocalDB 部署到客户端计算机，所以我更喜欢在我知道之前坚持使用复制方法确保 LocalDB 不支持任何形式的复制。

总结我的问题：如何在 LocalDB 实例上创建请求订阅以订阅事务复制？

顺便说一句，LocalDB 使用 Windows 8 SDK 附带的引导程序部署到客户端计算机，如果您安装了一个，可以在此目录中找到：{C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A \Bootstrapper\Packages\SqlLocalDB2012}

如果我没有说清楚，我很乐意提供更多信息。提前致谢！

The comment column of distributor.dbo.MSdistribution_history contains comments such as

The state value translates to

Is the comment telling me that the reader thread is waiting for the writer thread but has read 1948689 cmds since the last stats entry. Or is it telling me that the reader thread is waiting for the writer thread and the writer thread has written 1948689 cmds since the last stats entry?

我知道您可以在 AS400 机器上创建对 SQL Server 机器的订阅。我的问题是，如果您在某些 AS400 表上没有活动期刊，您可以进行复制吗？

我们有一个将数据存储在 SQL Server 数据库中的应用程序。（目前我们支持 SQL Server 2005 及更高版本）。我们的数据库有 400 多张表。数据库的结构并不理想。最大的问题是我们有很多以 GUID (NEWID()) 作为主集群键的表。当我问我们的主要数据库架构师“为什么？”时，他说：“这是因为复制”。我们的数据库应该支持事务复制。最初，所有主键都是 INT IDENTITY(1,1) CLUSTERED。但后来当涉及到复制支持时，这个字段被 UNIQUEIDENTIFIER DEFAULT NEWID() 取代。他说“否则处理复制将是一场噩梦”。当时 SQL 7/2000 不支持 NEWSEQUENTIALID()。所以现在我们有具有以下结构的表：

所有的表实际上都有很多字段（最多 35 个）和最多 15 个非聚集索引。

我知道一个非连续的 GUID——比如它的值在客户端生成（使用 .NET）或由 NEWID() SQL 函数生成（比如我们的例子）是一个非常糟糕的选择作为聚集索引两个原因：

1. 碎片化
2. 尺寸

我也知道一个好的集群关键是它是：

1. 独特的，
2. 狭窄，
3. 静止的，
4. 不断增加，
5. 不可为空，
6. 和固定宽度

有关这背后原因的更多详细信息，请查看以下精彩视频：http ://technet.microsoft.com/en-us/sqlserver/gg508879.aspx 。

所以，INT IDENTITY 确实是最好的选择。BIGINT IDENTITY 也很好，但通常具有 2+ 十亿行的 INT 对于绝大多数表来说应该足够了。

当我们的客户开始遭受碎片化的困扰时，我们决定将主键设为非集群。结果，这些表仍然没有聚集索引。换句话说，这些表变成了 HEAPS。我个人不喜欢这个解决方案，因为我确信堆表不是一个好的数据库设计的一部分。请查看此 SQL Server 最佳实践文章：http ://technet.microsoft.com/en-us/library/cc917672.aspx 。

目前我们考虑两种方案来改进数据库结构：

第一个选项是将 DEFAULT NEWID() 替换为 DEFAULT NEWSEQUENTIALID() 用于主集群键：

第二个选项是将 INT IDENTITY 列添加到每个表并使其成为 CLUSTERED UNIQUE 索引，使主键不聚集。所以 Table1 看起来像：

Table1_PID 将用于复制，（这就是我们将其保留为 PK 的原因），而 Table1_ID 根本不会被复制。

长话短说，在我们运行基准测试以查看哪种方法更好之后，我们发现两种解决方案都不好：

第一种方法（Table1_GUID）揭示了以下缺点：虽然顺序 GUID 肯定比常规随机 GUID 好很多，但它们仍然比 INT 大四倍（16 对 4 字节），这是我们案例中的一个因素，因为我们有我们的表中有很多行（最多 6000 万行），以及这些表上的很多非聚集索引（最多 15 个）。集群键被添加到每个非聚集索引中，因此显着增加了 16 字节与 4 字节大小的负面影响。更多字节意味着磁盘和 SQL Server RAM 中的页面更多，因此更多的磁盘 I/O 和更多的 SQL Server 工作。

更准确地说，在我向每个表插入 2500 万行真实数据，然后在每个表上创建 15 个非聚集索引后，我看到表使用的空间存在很大差异：

此外，测试表明插入 Table1_GUID 比插入 Table1_INT 慢一点。

第二种方法（Table1_INT）显示，在大多数查询（SELECT）中，在 Table1_INT.Table1_PID = Table2_INT.Table1_PID 执行计划上连接两个表变得更糟，因为出现了额外的 Key Lookup 运算符。

现在的问题是：我相信我们的问题应该有更好的解决方案。如果您能向我推荐一些东西或向我指出一个好的资源，我将不胜感激。先感谢您。

更新：

让我举一个 SELECT 语句的示例，其中出现了附加的 Key Lookup 运算符：

并创建其他两个表进行比较：

现在运行以下选择语句并查看执行计划以进行比较：