RealSync同步复制容灾解决方案的特点
推荐方案从满足用户需求为基本出发点，可以充分满足关键行业数据容灾的需求，并且还能够对系统的优化部署提供更大的支持。
1.1.1 主备系统数据库处于双活状态
关键业务要求在复制链路中的各个数据库都处在活动状态，其中容灾数据库承担了数据容灾备份，在任何一个生产数据库发生灾难时需要及时提供业务的接管和及时的数据恢复，同时，灾备数据库一直处于open状态，可以对灾备数据库进行实时访问，系统保持生产中心和灾备中心的数据库处于双激活状态；
推荐解决方案采用了DSG RealSync实现生产数据库源系统到容灾系统的复制工作。可以从技术上保障目标数据库在线可用，容灾数据库的数据实时可读取，复制过程和数据读取不产生矛盾。RealSync的复制延迟很小，从容灾数据库读取到的数据是实时最新数据，不需要为了读取到最新数据而进行一些切换工作。
1.1.2 以数据保护为中心，侧重于保护业务数据安全
灾难备份的目标有两个，一是保护数据的完整性，尽量减少业务数据丢失，最好没有业务数据丢失，从而减少业务风险。二是快速恢复数据，使业务系统停顿时间最短。数据是业务系统的生命线，因此在制定灾难备份策略时应侧重于保护业务数据安全，将确保数据安全作为灾难备份的首要目标。
推荐解决方案采用了RealSync进行数据库复制，不存在在极端情况下（如掉电、站点失败）灾备数据库无法访问的风险。目标数据库一直处于OPEN状态过程实际上是对数据风险的有效控制。
1.1.3 数据延迟
DSG解决方案提供用户在
1.1.4 数据损失
推荐解决方案在一般性灾难发生时一般不存在数据丢失。这些一般灾难包括数据库失败、操作系统失败等等。对于一些极端的情况下，掉电、站点失败时，DSG RealSync也作了大量测试不会出现数据丢失（但从理论上讲这些极端情况无法100%避免数据丢失，因为这种情况可能造成了系统的严重破坏）。
网络失败：网络恢复时继续复制，没有数据损失
数据库关闭：数据库恢复时从断点继续复制，没有数据损失
操作系统重起：重新启动复制软件，从断点处继续复制，没有数据损失
掉电：DSG RealSync也作了大量测试不会出现数据丢失（但从理论上讲这些极端情况无法100%避免数据丢失，因为这种情况可能造成了系统的严重破坏）。不过对于重要的生产系统一般通过UPS预防断电情况,发生概率非常小.
站点失败：由于目标系统在线可用，不存在任何数据风险。但对于还没来得及传输到目标系统的数据可能出现丢失。
1.2.1 对源系统性能的影响
DSG RealSync通过Oracle日志获得数据的变化信息，它独特的技术优势使得它对源系统的资源占用很小。在生产系统中，实际对源系统的影响和源系统复制事物的多少，事物的处理方式有关。在复制数据量正常的OLTP系统中，正常状态下对CPU资源的占用为5个百分点，对内存资源的占用为几
1.2.2 对网络资源的使用
推荐方案所需网络带宽有限，能够在有限传输带宽上保证复制工作不延迟。
因为RealSync复制操作只是读取操作系统的日志文件，同时通过TCP/IP方式而不是采用中间件方式传输只发生改变的数据也使网络负载降至最低。RealSync只将日志的三分之一的内容通过网络进行传输。实际每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3 .
例如用户峰值每小时生成的日志量为
实际峰值期间每小时传输的数据量=每小时日志文件切换的数量*日志文件的大小*1/3=720/3=
考虑20%的传输开销，所需要的带宽为240*1.2/3600=80KB/S,系统对传输带宽的要求为640kbps。
1.2.3 数据延迟
RealSync是一种异步准实时的复制技术，其数据延迟非常小。数据延迟的周期可以设置，在生产系统中，数据延迟和源系统复制事物的多少，事物的处理方式有关，以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中，数据延迟一般在几秒钟。
对于关键行业，DSG能够做到在
1.2.4 对主中心的影响
当容灾中心暂停或传输异常中断导致复制停止时，RealSync会将数据库的变化内容存储在源系统或目标系统的队列中，当系统恢复后，RealSync会自动识别复制环境，自动从断点处开始复制工作。在上述过程中，主中心的业务不受任何影响。数据的一致性不会破坏。
当复制环境停止的情况下，需要在源系统和目标系统上存储的空间和业务系统每天峰值的日志数有关。例如用户峰值每小时生成的日志量为
容错期间需要处理的日志量=每小时日志文件切换的数量*日志文件的大小*1/3＊24=
在网络中断情况下，考虑数据暂时存放在源系统24小时所需要的存储空间。按照50%的存储开销计算，所需要的空间为5.76*1.5=
1.2.5 复制环境的健壮性
推荐解决方案具备足够的健壮性。源系统和目标系统的任何故障都不会影响到复制环境。在以下故障发生时，RealSync故障处理方法如下：
源系统主机故障：源系统主机故障修复后，当Oracle数据库和操作系统重新启动后，RealSync自动重试连接数据库，并从断点继续进行复制工作。
数据库故障：当源系统数据库故障修复后，当Oracle数据库重新启动后，可以从断点继续进行复制工作。
复制软件故障：复制软件在源系统有三个进程，目标系统有两个进程。当复制软件的进程遇到问题时，可以自动重起相关进程。
网络故障：当网络恢复后可以自动从断点进行复制工作。
目标系统的主机故障：数据存储在目标系统队列中，当目标系统主机故障修复后，从断点继续进行复制工作。
数据库故障：数据存储在目标系统队列中，当目标系统数据库修复后，从断点继续进行复制工作。
1.2.6 事物的完整性和可用性
RealSync是一个数据库级的软件解决方案，其复制的基本单位就是一个事务(Transaction)，RealSync在从oracle log中读取到交易数据后，根据交易的关系，将属于一个事务的所以操作组合在一起，以一个基本单位发送给目标端，目标端在执行时也严格按照交易进行，因此严格保证了交易的完整性。
对于事务与事务之间的顺序，RealSync严格按照ORACLE 的SCN标记进行排序。确保事务之间的先后秩序。
1.3.1 开放性
推荐解决方案采用开放系统环境，和存储设备、硬件设备、操作系统、Oracle数据库版本无关。由于采用了RealSync的复制解决方案，源数据库和目标数据库可以运行在不同类型的操作系统和Oracle数据库的不同版本上。同时，也能够支持不同类型的存储环境。
1.3.2 对源系统的修改工作
推荐解决方案对源系统不进行复杂的配置修改工作。RealSync建立复制环境所需要工作量少。不需要对硬件、软件、磁盘卷的划分进行任何额外的操作。减少了建立冗灾环境对系统结构和应用所作的修改工作。使用RealSync，不需要在实施的过程中和系统整合时对空间进行从新划分，极大地降低了工作量。
1.4.1 对系统扩容的影响
由于采用了RealSync的复制解决方案，对今后的扩容没有任何影响。使用RealSync，源数据库和目标数据库可以运行在不同类型的操作系统和同一Oracle数据库的不同版本上。同时，也能够支持不同类型的磁盘阵列。这不仅能够满足目前异构环境，还能适应未来的扩展需求。随着业务量规模的不断扩大，在硬件升级时，新旧硬件产品可以随意调换，不受限制。
1.4.2 业务扩展的影响
推荐解决方案对未来容灾功能扩展没有任何影响。未来需要将其他业务系统进行容灾时，可以非常方便地将需要容灾的系统纳入容灾框架。
1.4.3 对双机集群的支持
对于源系统，RealSync解决方案提供对双机集群的支持。因为RealSync的所有可执行文件和队列都存储在文件系统中，当primary出现问题后，可以在passive 机器上启动RealSync并继续进行复制工作。
对于目标系统，RealSync提供灵活的方式进行复制。目标系统可以配置或不配置成集群方式。RealSync也能够将所有数据源都复制到一个目标系统。这时容灾系统作为数据源，同样也支持集群方式。
2 DSG-RealSync产品工作原理
当应用系统在Data Source端向数据库进行任何操作时时，这些信息都将在Redo Log中保存，RealSync Agent通过对实时获取的Log日志进行分析，获得本次操作的交易指令和交易数据，然后将这些交易指令和交易数据经过格式转化生成DXF数据格式，并实时通过网络传送到Data Target系统。
Data Target系统的RealSync Agent接收数据库包，经过校验码检查，确认正确的数据库包后，调用Oracle函数按照交易的先后顺序在Data Target系统中执行该交易。
RealSync对数据的抓取是通过安装在Data Source端的Agent模块定时分析Oracle Redo Log来获取Data Source端的交易类型及数据的。
RealSync Agent在判断Data Source端的Oracle系统是否有新的交易产生时是通过定期检查Oracle Controle file中记录的当前SCN号来判断的，这样避免每次检都通过读取log文件来判断否有新的交易产生时造成的系统影响。
在Controle file中确认有新的交易产生时，可以同时获得当前的Redo Log 组，以及最新日志在日志文件的最新位置。
RealSync Agent模块根据这些信息将上次抓取时记录的日志位置与本次读取的最新位置之间的Log读取并加以分析。然后将这些数据保存在Online Log Cache文件中，等待下一步作交易合成处理。
 RealSync的优势：与其他类似日志复制产品相比，RealSync对日志进行分析，得到交易信息再进行传送；而其他类似产品不对日志作分析，传送全部日志，然后在目标端通过日志作Recover， 这样一来，不仅传送数据量大，而且目标端数据库不能打开。
Oracle数据库的所有更改都记录在日志中，其中记录了对数据库中的每一个变化。
当我们候需要需要了解数据库中所作的交易时，一个最有效实用而又低成本的方法就是分析Oracle数据库的日志文件。
RealSync Agent中集成了DSG的优秀日志分析功能，该功能完全不同于oracle提供的Logminer日志分析工具，在性能和功能上都大大提高，主要体现在系统性能的优化上，大幅度提高日志分析的速度，使得对于高并发业务系统的复制成为可能。按照RealSync的日志分析设计目标，每秒能够分析的日志量达到
RealSync通过对日志的分析，得到该数据库中的每个SQL指令，并将这些SQL指令生成DXF（DSG Extend Format）格式的表达方式。
DXF格式是DSG公司的专有技术，该技术是DSG公司用来表达SQL指令的方式，该数据格式能够通过DSG的专有转换算法能够直接转换为ORACL的内部数据表达格式，从而在分析和转载时需要最小的转化，提高分析和装载速度，减少资源占用、丰富能够表达的各种数据类型。
2.3 交易合成（Synthesize）
通过ORACLE REDO LOG分析的交易指令存在如下的几个特点：
（1）这些指令是交叉出现的，属于一个交易（Transaction）的多条SQL指令是非连续存储的，多个交易的SQL之间是相互穿插的；
（2）Redo log中记录了所有的commit的交易以及没有commit的交易；
所以，为了提高系统的可控制性、保证逻辑完整性、避免数据丢失，最好将复制的最小单位为一个交易（Transaction），而不是以单个SQL指令为复制单位，这样在Data Target端的交易装载更加容易控制。
同时，对于复制的数据而言，只有那些Commit的数据对于Data Target端系统是有意义的，而对于那些Rollback的数据无需复制到Data target系统上。
所以RealSync在复制过程中不是复制每个SQL语句，而是对抓取的数据进行交易整合后以交易（Transaction）为单位进行复制，同时只复制COMMIT的交易。
如上图所示，在Online Log Cache文件中，包括Commit的交易，没有Commit的交易和Rollback的交易。交易合成模块首先按照交易序号对SOL语句进行划分，每个交易包含多条SOL语句。然后，以交易为单位进行处理，将已经Commit的交易，传至传输处理模块；将未提交的交易保存在本地，一旦通过日志得知保存的未提交交易已提交，立即将该交易发送到传输处理模块；对Rollback的交易作丢弃处理。
RealSync的优势：RealSync是以交易为单位进行传输的，而不是以SOL语句为单位进行传输的，更容易保证数据的一致性和完整性。
RealSync技术为了保证数据传输的安全、可靠，在传输处理上作了特殊的处理与支持:
（1） 数据在传输之前首先存入Data Source端的Cache，传输进程（Export Process）从Cache中读取交易数据封装为TCP/IP数据包传送给Data target端的Import进程。
如上图所示，负责传输的进程（Export Process）从本地队列中按照先进先出的原则抓取需要传输的交易，将交易数据封装成一个数据包后通过TCP/IP协议传递给对端系统。在封装的数据包的包头部分描述了包的大小。
对端系统在接受到传来的数据包后，首先根据包头描述的包大小进行传输的合法性检查，判断是否传输完整。
在传统的复制技术中，常用的数据装载方式是采用Oracle 的SQL接口，通过Insert、Update、Delete等SQL语句实现数据的装载。这种方式在通用性上很好，但关键在于性能问题非常突出。
SQL语句的执行需要经过parse、plan、格式转换等过程，造成大量的系统开销。尤其是update和Delte操作的大量Where子句操作需要进行复杂的查询定位任务，从而导致装载性能低下，对处理能力的要求比生产系统的还高。
DSG RealSync在设计之初就定位于电信级大数据量系统的应用，因此在装载性能上进行了大幅度的改善，使得装载端的性能和处理能力需求降至最低。
在其中DSG RealSync采用了两个关键的技术提高了装载速度：
（1）采用DXF数据格式的装载；
（2）采用Rowid mapping的方式实现快速定位；
2.5.1 用DXF数据格式的装载：
DXF（DSG Extend Format）格式是DSG公司的专有技术，该技术是DSG公司用来表达SQL指令的方式，该数据格式能够通过DSG的专有转换算法能够直接转换为ORACL的内部数据表达格式，从而在分析和转载时需要最小的转化，提高分析和装载速度，减少资源占用、丰富sql语句的表达方式。
Oracle数据库系统在设计上提供了4个层次的接口，其中包括User层，SQL层，Transformation层和I/O层。其结构为：
在这四层当中，当采用SQL接口进行数据装载时，调用的是User层，
而DSG RealSync通过DXF数据格式装载时，调用I/O层直接将数据通过Oracle的最底层函数写入系统中，所以DSG RealSync在装载层上有一定优势；
2.5.2 Row mapping实现快速定位
对于交易中的操作，存在着大量的Where子句操作，在采用标准SQL语句执行这些操作时，系统需要首先定位目标记录所在的数据文件的位置信息，这将带来大量的索引查询开销，当并发执行数千条指令时，系统的开销将变得非常庞大。
DSG RealSync工具不采用该方式实现装载数据的定位，而是通过ROW Mapping的方式实现记录的快速定位：
当RealSync从源端Log文件中读取交易数据时，将获得该交易对应记录的所在位置，用rowid表示为rowid_ds；
当该交易在目标端装载时，系统不翻译为Where子句，而是去通过保存在目标端的row mapping表获得对应目标端该记录的所在位置rowid，记录为rowid_dt。
从而在目标端装载时通过rowid能够直接定位于该数据需要写入的位置。避免了大量的索引查找时间。
每条记录的row mapping信息是在该记录执行insert操作、sql loader或首次批量同步时建立起来的。
RealSync的优势：DSG扩展格式DXF(DSG Extend Format)是RealSync产品的一个核心技术，是一种最高效率表示ORACLE记录的数据格式，该格式只需要经过最小的转换过程就能够装载到ORACLE数据库中，并且装载效率非常高。
n 无需标准SQL语句执行的复杂过程
n 加快装载速度
n 对于Update，Delete等带Where子句的交易，可以大幅度提高装载速度 本文出自 51CTO.COM技术博客 |
gulibin
博客统计信息
热门文章
最新评论
友情链接
