最近有几位客户要求我解释针对Oracle的SnapSync和LogSync操作的详细信息，以及这些操作如何影响TimeFlow和VDB资源调配操作，并就物理待机、块更改跟踪和无日志记录操作等方面的影响提供一些见解。由于Delphix使用标准的oracleapi，Delphix如何捕获初始数据库备份和随后的数据库更改的语义与传统的RMAN备份方法的工作方式相似（但不完全相同）。在RMAN看来，Delphix软件虚拟设备是通过使用RMAP API作为磁带设备的。由于Delphix提供对数据库的连续数据保护，所以Delphix合成这些数据以呈现时间流的方式是完全不同的。源数据库与Delphix之间的连接Delphix使用一组称为Delphix toolkit的shell脚本管理源数据库主机和Delphix软件虚拟设备（SVA）之间的数据传输和通信，该脚本反过来使用RMAN和RMAN API。当您添加环境或推送时，此工具箱会被推送到源数据库的主机"环境刷新"按钮。RMAN是源数据库和Delphix之间的通信机制。但是，Delphix SVA本身没有Oracle堆栈的任何部分。Delphix依赖SnapSync和LogSync操作从数据库收集数据，工具箱包含在源数据库主机上为这些操作所做的工作。对于数据收集和数据传输，SnapSync和LogSync使用RMAN和OJDBC标准Oracle API。此外，对于这些RMAN操作，键参数和/或元数据变量是Oracle用于在数据库级别定义其事务顺序的指针，该指针称为Oracle系统更改号（SCN）。所有SnapSync和LogSync操作都将SCN元数据附加到发送到Delphix SVA的数据库或日志文件。我们稍后再看为什么这很重要。链接到源数据库时的数据收集当您第一次链接到源数据库或添加数据源时，Delphix toolkit将调用RMAN API进行完整备份操作，并通过此API收集数据块并将其传输到Delphix SVA。由于此操作是在源数据库处于活动状态时执行的，因此实际上是在执行Oracle所称的"不一致"备份。实际上，这意味着数据库数据在备份过程中会发生变化。要使其"一致"，您还必须收集备份过程中发生的所有更改的记录。对于Oracle，这些是日志文件（存档或联机重做日志）。因此，在完全备份结束时，工具箱还将查找并发送在您开始备份到您开始备份期间记录更改的所有日志已完成不一致的备份。这一点的一个重要后果是，尽管您在SCN#X开始备份，但它只在SCN#（X+N）处变得一致，其中N表示在完成备份操作所需的时间内提交的SCN。因此，快照SCN，这将是第一个出现在您的Delphix时间流卡上的SCN将是SCN#（X+N）。针对该源数据库为后续SnapSyncs收集数据大多数甲骨文公司都熟悉增量备份的概念，本质上，增量备份是一种部分备份，它包含了一些完整备份基线与当前备份之间的所有变化；它必须始终与完全备份配对才能实现时间点还原。虽然增量备份包含的块比完全备份少，但这并不意味着创建它时需要检查的块更少。（在BCT中，我们将对此进行检查）。当您执行SnapSync时，Delphix toolkit调用RMAN API进行增量备份操作，通过此API收集数据块并将其传输到Delphix SVA。请注意，它始终是增量备份操作。通过Delphix连续数据保护和Delphix执行的综合，您可以在增量备份的代价。所以，再也不需要回去进行完整备份了。为了数据库的一致性，增量备份过程中收集的部分或全部日志将由toolkit识别或收集并传输到Delphix。如果LogSync已打开，则Delphix已经在收集日志，因此，保持一致性所需的日志已经在运送中，工具箱只能识别它们，如果LogSync关闭，那么作为SnapSync操作的一部分，最后会传输几个日志，以确保增量备份的一致性。对源数据库使用LogSync进行数据收集Delphix在Oracle数据库上利用日志传送进行LogSync。Oracle Redo存在于联机重做日志或归档日志中。实际上，这些日志收集对数据库的可重放更改。Delphix LogSync执行应用于源的更改数据的近实时收集，并因此更新Delphix时间流。此操作通常比源数据库晚几秒到几分钟。Delphix TimeFlow for Oracle databases在SnapSync之前推出，一旦SnapSync操作完成，Delphix继续收集日志，并将SCN范围上的端点标记移动到每次接收和处理日志时收集的最后一个SCN。SCN范围上的端点标记是可以配置一致数据库副本的最新点。此更新是连续数据的可见标志Delphix提供的保护。为源数据库一起操作SnapSync和LogSync一旦LogSync开始运行，它将继续运行，即使请求了SnapSync操作。例如，假设我做了一个源数据库的初始链接，该链接在凌晨3:45完成，并且启用了日志同步。Delphix时间流将从凌晨3:45开始，持续到下一个SnapSync操作完成。如果在上午7:00请求了第二个SnapSync，并在上午7:30完成，则与3:45 am卡关联的时间流将继续到7:30 am卡上快照SCN之前的SCN，然后以下SCN将作为快照SCN出现在7:30 am卡上。配置虚拟数据库对时间流的影响由于Delphix对最终用户是透明的，虚拟数据库遵循与任何其他数据库相同的语义。因此，当您使用Delphix配置数据库时，您可以预期与使用Oracle执行相同的结果。虚拟数据库配置通常包括重置日志操作。一旦发生重置日志操作，即使VDB的内容与源数据库中的某个点相同，它是另一个数据库的化身。BCT和物理备用执行增量备份的最大优点是需要通过网络存储和移动的数据更少。对于Oracle，需要检查多少块才能生成备份的问题是使用Oracle的块更改跟踪（BCT）功能的一个功能。简单地说，BCT对发生更改的所有块都保留一个非常小的日志，因此当调用RMAN时，只会获取那些更改的块。因此，检查数据库增量更改的成本将成为数据库更改的函数，而不是数据库大小的函数，这有着明显的好处。但是，如果关闭了BCT，即使是标准的Oracle RMAN增量备份也会强制读取100%的数据库。另一个轻微的变化与Oracle 10g中的物理备用数据库有关。不幸的是，即使在主10g数据库使用BCT的情况下，Oracle 10g物理备用数据库也不能有效地使用BCT，因此完全和增量备份将强制100%读取数据库。无记录操作客户希望执行大负载操作的情况非常常见，但是在NOLOGGING操作中这样做，以避免生成不需要的大量redo。任何NOLOGGING操作都会故意避免创建redo，从而在任何RMAN备份中造成潜在的不一致性。由于Delphix遵循相同的语义，Delphix内部也存在这种可能性。对执行大型无日志记录操作有严格要求的客户通常会（1）启动SnapSync，（2）关闭存档日志模式，（3）执行其注销操作，（4）重新打开存档日志模式，以及（5）启动另一个SnapSync。这种方法将TimeFlow与对两个完整备份（一个在操作之前，一个在操作之后）执行相同的操作，可以最大限度地减少任何可恢复性问题。从Delphix服务器上的增量合成full最后，我们转向从增量备份合成完整备份的概念。当RMAN向Delphix SVA发送与SnapSync相关的块和日志时，Delphix会将SnapSync合成为完全备份的等价物。因此，即使我们支付了获取和运送增量备份的低成本，我们得到了一个可恢复性的好处，即准备好一个完整的备份以备调配。而且，由于Delphix只需几秒钟的时间就可以完成调配，所以这一好处是非常巨大的。