Shareplex Vs DataGuard

数据复制产品对比分析SharePlex for Oracle Vs Oracle 9i DataGuard商业风险及数据复制在企业信息化不断加快的今天，业务运营对IT系统的依赖程度也日益增加。

保持企业应用的高可用性，对企业的生存和经营具有重要的意义。

IT高可用性面临多种挑战；在数据库层次上，如何通过数据复制，对生产数据库的数据进行备份、恢复和灾难发生时的快速接管，成为企业最重要的课题。

Quest Software的SharePlex for Oracle通过数据库逻辑层的复制技术，可以方便地实现Oracle数据库的容灾保护，具有对源系统资源占用少，对网络资源占用少，支持异构环境和不同的复制拓扑，保持事物一致性的特点。

在异构环境、异地容灾、备份系统存在查询访问需求的环境中具有很大优势。

数据复制是目前最流行的高可用解决方案，不同厂商提供的方案在实现机制和方式上各不相同。

从复制速度和数据安全考虑，分为同步复制和异步复制；从复制机制考虑，存在逻辑复制和物理复制。

SharePlex复制机制Oracle利用redo log记录数据库中的数据变化。

源数据库发生变化后，会写入到redo log中。

SharePlex 通过自身的捕捉进程，持续不断地监控redo log，提取需要复制的内容，将其存入专用的队列文件中，等待复制。

读取日志的活动完全在数据库外发生，不占用Oracle所分配的资源。

必要时，SharePlex进程可以自动跳过不需要复制的事务，对日志中的下一记录进行处理。

队列文件同样独立于Oracle引擎，在专用的内存区域存储，以保证最佳系统性能，减少系统开销。

复制过程中，SharePlex从队列中读取待复制内容，加上寻址信息，通过TCP/IP 协议传输到目标系统的内存区，由目标服务器上的SharePlex 提交进程以生成SQL语句的方式提交。

SharePlex的复制进程运行于操作系统级，不占用Oracle SGA区的内存，也不需要Oracle引擎对其进行管理。

队列文件和相关内存区也与系统为数据库所分配的资源无关。

因此，复制队列和内存区中的复制事务增加或减少时，不会导致额外的数据库活动。

SharePlex复制原理Oracle Data Guard复制机制Data Guard 中包含两种不同的复制提交技术，一种称为Data Guard Redo Apply，另一种是Data Guard SQL Apply；前一种方式被称为Oracle Dataguard Physical Standby，直接通过Redo Log的恢复，完成复制内容的提交，实现数据复制，目标服务器在复制时不可查询；第二种方式被称为Oracle Dataguard Logical Standby，通过在目标系统中生成SQL语句进行数据提交，复制过程中目标数据库可用于查询和生成报表。

Data Guard Redo Apply的复制技术Redo Apply和SQL Apply在源数据库服务器端采用了相同的技术，都是将整个Redo Log的内容，直接传输给目标服务器的RFS（Remote File Server）进程，并由其写入目标服务器的Archived Redo Log日志。

目标服务器对Archived Redo Log进行恢复处理，实现从源数据库到目标数据库的复制。

Oracle Data Guard SQL Apply在原理上与SharePlex比较类似，都是通过分析数据库日志，捕捉源数据库中的变化，复制到目标数据库后，以生成SQL 语句的形式提交复制内容，完成复制过程。

不同的是，Data Guard在目标服务器端分析数据库日志文件并还原成SQL语句，追加到目标数据库。

这种方式看起来对源服务器影响较小，但是因为需要传输整个归档的日志文件，会产生较大的网络流量，对带宽的要求较高；另外，该方式无法实现双向复制，数据集中。

Data Guard SQL Apply中基于日志的复制技术对比分析SharePlex的复制过程发生在Oracle数据库之外，在操作系统和文件级完成，而Oracle的复制过程则由Oracle数据库内部的进程完成，这是一种非常重要的区别，也是导致Data Guard性能问题的主要原因。

另外，SharePlex复制时，首先在源数据库服务器一端分析日志文件，确定哪些东西需要复制，哪些不需要复制，然后才对日志中需要复制的部分加以提交。

与此不同，Data Guard 会将整个日志文件提交到目标服务器，由目标服务器的特定Oracle进程分析和处理需要提交的复制，再以生成SQL语句的方式提交。

这种方式会产生较大的网络流量和较长的延时，不仅实时性较差，带宽需求也很高。

1．Data Guard Redo ApplyData Guard Redo Apply不可能同时做到数据复制和可读性。

其主要存在的问题如下：✧数据延迟，需要通过Arch进程将归档日志传输到目标系统，存在很多数据延迟，一般来说至少延迟一个归档日志的数据。

虽然可以通过LGWR进程向源系统和目标系统同步写的方式解决同步问题，但是源系统的性能会受到很大影响，这种方式几乎无法使用。

✧网络资源占用，需要将主系统所有的日志文件传输到远程数据库，网络开销极大。

✧目标数据库的可访问性，目标数据库可以Recovery状态和Read-Access 状态进行切换，但不能同时进行数据复制和访问操作；并且将目标系统库切换为Read-Access状态后，无法保证与源系统数据库的同步。

✧目标系统的可用性，主数据库失败时，不能确认目标系统是否100%可用。

要保证系统目标系统可用，必须保证所有的Archive 文件正确归档、传输并加载到目标数据库中。

需要对这些操作随时进行检查。

✧可管理性，对数据库维护人员和DBA的要求非常高。

✧实施环境要求，对实施环境要求较高，源系统和目标系统必须使用相同的硬件和操作系统。

使用相同的数据库版本。

且源系统数据库必须处于归档状态。

2．Data Guard SQL Apply由于Data Guard Redo Apply的局限性。

Oracle 9.2中推出了Data Guard SQL Apply方式。

这种方式可以同时做到数据复制和可读性。

但是由于使用了Oracle内部的机制（Oracle Net），实现这个功能的代价也非常大，其存在的主要问题如下：✧技术成熟性，产品用户少，相关文档较少，技术不成熟。

✧数据延迟，需要通过Arch进程将归档日志传输到目标系统，存在很多数据延迟，一般来说至少延迟一个归档日志的数据。

虽然可以通过LGWR进程向源系统和目标系统同步写的方式解决同步问题，但是源系统的性能会受到很大影响，这种方式几乎无法使用。

✧网络资源占用，需要将主系统所有的日志文件传输到远程数据库，并且使用Oracle内部的机制（Oracle Net）实现，网络开销极大；并且大量的日志文件间断性的传输会导致网络的堵塞。

✧复制场景，只支持单向复制、数据分发，不能做到双向复制、数据集中。

✧支持的数据类型和SQL，不支持部分数据类型，不支持部分SQL语句✧可管理性，对数据库维护人员和DBA的要求非常高。

✧实施环境要求，对实施环境要求非常高，只支持Oracle 9.2以上版本，源系统和目标系统必须使用相同的硬件和操作系统。

使用相同的数据库版本。

且源系统数据库必须处于归档状态。

SharePlex优势与Data Guard 相比，SharePlex for Oracle具有以下优势：✧支持异构环境。

源数据库和目标数据库可以运行在不同类型的操作系统和同一Oracle数据库的不同版本上。

同时，也能够支持不同类型的磁盘阵列（包括SAN）。

这不仅能够满足目前系统现状，还能适应未来的扩展需求。

系统建设是可以选择多种产品参与竞标，大大降低硬件投资，随着公司规模的不断扩大，在硬件升级时，新旧硬件产品可以随意调换，不受限制。

✧目标数据可访问。

SharePlex独特的实现机制使用户可以对目标系统进行查询操作，因此，可以作为报表查询、统计分析等系统的数据源，减轻源系统的压力，使投资变为可用，而不是单存的冷备闲置。

目标数据可访问能够提高容灾系统的投资回报，增加容灾系统的利用价值。

同时，目标数据的在线使用实际上是对数据的一个长期在线使用，保障数据的准确性，从而避免容灾系统长期冷备，数据错误而无人发现的情况，能够确保复制数据在灾难发生时被有效接管，进行数据恢复。

✧保证事务的一致性。

和其它解决方案不同，SharePlex是一个数据库级的软件解决方案，能够保证每个数据库事务在主备机器之间的一致性。

不会出现硬件方案导致复制数据库不能打开的问题。

✧建立复制环境所需要工作量少。

SharePlex不需要对硬件、软件、磁盘卷的划分进行任何额外的操作。

减少了建立复制环境对系统结构和应用所作的修改工作。

✧不影响源系统性能。

SharePlex for Oracle作为一个独立于数据库和应用的软件解决方案，不会影响源系统的运行。

它独特的技术优势使得它对源系统的资源占用很小，对网络资源占用很少。

从技术上保障了主中心业务系统的性能和高可用性不会因为容灾中心的建立而受到很大的影响。

✧灵活性和扩展性强。

SharePlex for Oracle提供多种配置方案，包括单向复制、双向复制、数据集中、数据分布等等。

可以很好地满足系统的扩充性需求，充分保护投资。