如果您有钱，可以通过复杂的设置进行操作，并且不介意同步两阶段提交...您可以实现ASE/SRS HA/DR解决方案（又名同步代表；又名流媒体） 代表）。 "当然，这远远超出了您想要的目标（即，您必须等待辅助数据库上的txn完成，然后在主数据库中将其标记为"完成"。

---------

下一个想法是通过调整repagent和SRS配置来增强repagent/SRS的连接性和吞吐量。 Repagent配置将包括"优先级"（设置为0？），"重试超时"（设置为1？），"扫描超时"（设置为1？）。 SRS配置...您可能需要选择SRS/ASO选项，以允许使用一些与性能相关的较新配置。 当然，请与硬件/网络人员合作，以确保您从repagent到repserver的网络跳距最短/最快。

---------

当然，如果您有一个批处理过程在短时间内吐出数以十万计的DML命令，而那些更重要的txns在执行后滞留在pdb中，那么上述所有内容都不重要 计划外的交换机。

在这种情况下，您可能不得不忍受这样的事实：如果发生计划外的切换（活动），您将丢失一些交易。

但是，您可能要考虑的是您是否可以将交易分为几类，例如，必须不惜一切代价进行复制，真的很想确保这些 得到复制但不是世界的尽头，如果他们不这样做，那么可以很容易地将它们恢复到新的主数据库中。 如果可以这样做，则可能需要查看多路径复制，其主要目标是通过自己的路径路由"高优先级"事务（因此，它们不会被大量txn计数维护和批量处理所阻止/保留） 操作。

当然，多路径表示也需要SRS/ASO选项，但设置起来容易得多，并且不会遭受同步两阶段提交的性能开销（又名ASE/SRS HA/DR始终在线 ，同步代表。）

是的，对于我正在寻找的而言，ASE/SRS HA/DR解决方案过于繁琐/昂贵。 我只想从主ASE服务器同步到repserver中安全存储它的第一点（但不一定要通过repserver中的所有步骤进行同步）

我的理解是，有一天，rep_agents将开始使用与SRS HA/DR实现相关的新通信协议，但是即使您不使用SRS HA/DR，也会使用新的通信协议。 也许到那时，会出现一些新的销售代表代理选项。

无论如何，感谢您的详尽撰写。

回答我自己的问题....

你能

• 在主数据库中打开事务。
• 在该事务中执行一百万个DML命令（或1个影响一百万行的DML命令）
• 保持交易公开
• 在单独的连接上，在该主数据库中运行rs_ticket
• 一旦rs_ticket命令将其转到复制数据库（显示在rs_ticket_history中），并在第一个连接中提交事务？

我运行了一个快速测试，它看起来像rs_ticket命令导致第一个连接中的打开事务日志条目被写入repserver，即使在commit commit命令得到获取之前它们并没有应用于复制数据库。 复制。

同意Mark。

RepAgent只是按时间顺序将事务日志记录（已提交或未提交）发送到稳定队列，以优化数据传输。

在复制端"应用"这些命令的时间到了，并且只遵守提交顺序。

因此rs_ticket或复制的用户表中任何其他已提交的单行提交的插入/更新将在"大打开事务"仍等待提交/回滚之前应用于复制端。

您可以编写串联事务，在该事务中rs_ticket或等效的单行提交的插入/更新可以首先到达复制，并检查在Replicate上可以在主数据库上提交应用程序事务。

请注意，这仍然是异步操作，并受复制延迟的影响。

我们使用类似的机制来切换DSS报告应用程序，该应用程序基于每分钟复制的时间戳行并以合理的延迟到达，从而将连接从REPLICATE转换为PRIMARY。

HTH

Avinash

SAP/Sybase Warm Standby复制是异步机制。

因此，活动（主）和备用（复制）之间通过复制服务器之间的连接松散。

因此，如果切换突然发生，总是有可能在主动端丢失一些事务。

要最大限度地减少受控交换机中的交易损失，您可以

-首先在活动侧断开所有用户连接（没有新的DML进入），

-具有跨发送最后一个事务的机制（或rs_ticket）（所有TXN已从活动状态变为待机状态）

-验证最后一个TXN到达（待机匹配处于活动状态），

，然后进行活动的待机开关。

HTH

Avinash

回复：要使受控交换机中的交易损失最小化，您可以...

是的，我了解，但是我的问题是关于不受控制的开关。