执行此操作有几种方法，具体取决于a）您执行动作的速度如何，b）是否始终需要后备解决方案，c）是否需要保持相同的精确度 ASE数据服务器名称，d）如果要引入新的repserver实例（或使用当前的repserver），e）如果要升级到新的RS版本，f）如果要升级到新的ASE版本，以及 g）DBA执行操作的能力。

假定没有新的ASE/RS升级和数据服务器名称的更改是可接受的，假设新的数据服务器名称为PDB2和RDS2，并且假定PDB1为 当前的活动/主数据服务器，一个的想法是：

------------------------ ------------------

从PDB1到RDS2的设置复制：

1a-为每个数据库创建第二个MSA/订阅 从PDB1到RDS2

1b-对从PDB1到RDS2的每个数据库执行正常的dump-n-load/resync操作

1c-（重新）配置 重新将RDS2数据库中的repagents（例如，指向正确的RS实例以用于将来复制到PDB2）

1d-此时，您应该将PDB1主动复制到RDS2（验证 rs_tickets ，数据从PDB1到RDS2）

--------------

从PDB1到PDB2的设置复制：

2a-为从PDB1到PDB2的每个数据库创建第三个MSA/订阅

2b-为从PDB1到PDB2的每个数据库执行正常的dump-n-load/resync操作

2c-（重新）配置PDB2数据库中的repagents（例如，指向正确的RS实例以供将来复制到RDS2）

2d-此时，您应该正在从PDB1主动复制到 PDB2（验证 rs_tickets 并且数据正在从PDB1流到PDB2）

--------------

指出您当前的活动/主数据库（PDB1）正在复制到3x组辅助数据库（RDS1，RDS2，PDB2）。

注意：如果使用相同的RS实例，则需要确保它们 C

--------------

配置/测试从PDB2到RDS2的复制：

3a-为每个数据库（从PDB2到RDS2）创建一个新的MSA/repdef/订阅

3b-验证复制是否正常，例如，从每个主数据库发送一个 rs_ticket （PDB2。），并确保它显示在相应的复制数据库（RDS2。）

--------------

< p>配置/测试从RDS2到PDB2的复制：

4a-为每个数据库（从RDS2到PDB2）创建一个新的MSA/repdef/订阅

4b-验证复制是否正常 例如，从每个主数据库（RDS2。）发送 rs_ticket 并确保其显示在相应的复制数据库（PDB2。）

中- ------------

这时，应该在新的ASE实例（PDB2，RDS2）之间启动MSA复制并使其处于活动状态。

注意： 假设所有repagents（旧的和新的）都已配置为忽略（默认设置）维护 服务交易； 最终结果是，应该在PDB2和RDS2之间复制的唯一内容是 rs_ticket （从PDB2或RDS2发送）

---------- ---

一旦确认所有新的复制设置均正常运行，并且您准备关闭旧的ASE实例...

5a-从以下位置执行切换 PDB1（当前的活动/主数据服务器）到RDS2（或PDB2，具体取决于您的交换机处理方式）

5b-此时，您已脱离PDB1，应该在新ASE上启动并运行 实例

注意：由于此特定计划未设置从新ASE数据库复制回旧ASE数据库的复制，因此您将无法回退到旧ASE数据库（而不会丢失新生成的用户数据） ）。 这种功能（可以将旧ASE数据库的后备功能合并到混合功能中，但需要进行更多设置-即从RDS2到PDB1以及从PDB2到RDS1设置MSA/repdef/subscription）

--------------

这时，旧的ASE实例（PDB1和RDS1）仍是复制的一部分，但它们没有被复制到soooo中，旧的ASE实例 可以在此时从复制中删除。

此计划有很多变体，具体取决于您的时间表，需求和舒适度（例如，一次关闭一个旧的ASE实例；维护/重复使用ASE实例名称；同时执行ASE和/或RS升级；等等）。

XPDL已经完成并在新服务器上进行了测试。 但这将是一个新复制，因此尚未复制。

但是我认为我们过去曾发生过由于某些原因而导致加载失败的情况
现在，在执行转储时，主数据库将出现停机时间。 但是转储完成后，系统将立即恢复正常运行，在此期间，将存在带有转储标记的转储订阅。

我只想知道如果加载将执行哪些步骤？ 失败，并且不可能立即在主数据库上重做转储。 我可以假设手动清除队列中的复制数据？

我可以确认以下解决方案有效。
这是我们跨平台同步新ASE服务器的方式 使用转储标记进行转储和加载。

Luc Bienvenue 2019年12月5日，上午01:29

基本上，我们要采用的方法是使PDB2与PDB1中的转储标记同步，但是我们正在执行XPDL。

首先，我们使用转储标记定义订阅，然后进行停机以进行转储。

因此，在PDB1上，我们停止rep agent将DB置于单用户中，运行flush stats，执行转储，删除单用户并启动rep agent。

这时，Rep Agent选取转储标记并将其发送到rep服务器，并且订阅变为有效，并且PDS2的DSI会因转储标记而挂起。

现在我们有了转储，应用程序将重新联机，所有新事务将在与PDS2的DSI连接的出站队列中等待

我们将转储复制过来，加载并使其联机。 进行reidex等（对于XPDL，DB对于sp_post_xpload太大）

我们将跨平台转储加载到新服务器没有任何问题。 他们都是静态的，负载也很好。

第2部分将设置MSA/repdef/sub，以便它可以复制到PDS1和RDS1。
当我们恢复连接时，出站队列将清除，PDS2将与PDS1同步。 现在，如果需要，我们可以使用旧PDS1的后备选项。

最后一部分将是切换到新系统，因此PDS2成为新的主要系统。 PDS1和RDS1成为复制品。然后，我们将RDS2与PDS2中的转储标记同步，并将MSA/repdef/sub设置为PDS2。 因此，RDS2将仅复制到PDS2，但此时仍将保留复制。

稍等片刻，当我们看到新的主PDS2很好时，我们可以删除旧PDS1和RDS1的订阅，并获得包含PDS2和RDS2的最终MSA。