注册 | 登录 忘记密码? 51cto首页 | 博客 | 论坛 | 招聘
热点文章 利用手机和电池实现反地心..
 帮助

Streams技术在Oracle分布式及高可用需求环境中的应用


2006-12-31 10:00:44
 标签:Oracle   [推送到技术圈]

可用的Ha解决方案及其比较   
Data guard
   standby9i中的扩展,9i中改名为data guard,利用standby controlfile和一份初始的物理备份和持续的归档日志进行前滚。在业内已经有很好的口碑和广泛的应用。技术成熟度较高。可以作为一般的灾备手段。
 
   但是作为某些有特殊要求的用户来说,data guard还是有着一定的局限性。首先,必须是同构平台和数据库之间进行部署,这就要求可能需要用户投入和primary server类似的预算,而这种要求对于中小型用户来说是比较苛刻的。另外standby的环境不能保证7×24小时的open,虽然readonly的模式可以保障一段时间的只读访问,但是还是需要间歇性流出一段时间进行数据的前滚操作。
 
 

Advanced Replication

 高级复制(我们主要针对最具代表性的多主体异步模式),是自身的trigger(在生成replication support的时候产生)机制来补捉本地dml产生的RPC(远程过程调用),之后RPC通过job queue来定时的push到远程站点。RPC在没有被传播出去之前是被存储在本地的延世队列中(AQ的一种)。
 
高级复制的机制,适用于联机事务处理的应用。对于事务类型是小而多的情况,高级复制会有很好的性能表现,但是对于批量事务处理将会是高级队列的致命约束。
 
高级队列通常可以在异构平台之间的oracle数据库间进行分布式部署,比如unix服务器和pc server之前,这样的好处就是减少了硬件资源上的投资。但是advanced replication本身的机制约束了应用的可扩展性,我们知道,deffer queue的维护需要大量的系统资源,同时基于trigger本身也会花费很大的资源。这样通常会造成部署advanced replication的应用系统上top 5的等待通常都是enqueue或者dequeue等大量AQ上的维护,同时突发的大事务会导致系统处理不及而挂起。另外advanced replication对于dml的支持只能通过对应的api来实现,这样会增加更多维护难度。
 

RealSync

DSG公司的一款高端Ha产品,利用自身的机制来读取archive log中的数据并通过queue来传递到远程站点,机理类似于logical standby。由于本身的成熟度比较高,通常应用于大型的数据同步场合,比如电信,电子网站,银行等。
 
维护配置稍简单,但是成本非常高。
 
其他硬件级HA
比如 veritasemc,或者letago公司的基于软件和硬件层的数据传递,可以做到完全抛开数据库级的做到更为底层的一致性的数据传输。通常效率也会很高。价格比较昂贵。
 
 
 
综合评估
综合以上几种HAsolution,我们发现,几乎没有哪种现有方案可以完全做到以下几点:
 
1.      成本低
 
2.      支持异构平台
 
3.      环境中的节点可以同时open对外服务
 
4.      能做到整个schema级的同步而且相关的维护不是过于复杂
 
5.      系统本身不会过多的限制应用的可扩展性
 
 
 
于是,oracle推出了streams技术。作为一项新事务,streams还没有完全被大家所真正认识清楚。这里作大致介绍。
STREAM机理
 
 
 
上图描述一个完成的stream数据传输的全过程。
 
 以下说明中需要用到的术语:
 
   LCRLogical change record):
 
1.       LCR是一种描述指定数据库变化的对象。它分成rows LCRsDDL LCRs
 
2.       Row LCRs描述dml作用后产生行级变化的描述;DDL LCRs描述DDL作用后产生对象变化的描述;
 
3.       每个LCRs包含以下信息:
 
Ø       发生变化的源数据库名
 
Ø       具体的DML类型:如insertdeleteupdate
 
Ø        shema name
 
Ø        object name
 
Ø        redo log记录的SCN
 
   RULE(规则)
1.是一种数据库对象,通过它可以使得某种事件发生或者条件满足时可以执行某个动作;
 
2.规则是通过特定的api来创建或管理;
 
3.规则可以定义成不同级别:table leveshema leveldatabase level
 
4.可以把相关的rulegroup到一个rule set中去;
 
Streams的架构如下:
 
 
 
如上,streams大致会分成如下几个步骤:
 
Capture process:由capture进程来执行具体的补捉操作,Streams采用基于logminer的日志抓取技术。大致会进行如下动作:
 
A redo log
 
B 解出每个rule所对应要被capturedmlddl
 
C 格式化相关信息成LCR格式
 
Dstaging:把LCRs放入queue
 
 
 
    capture进程的配置:
 
BEGIN
 
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
 
table_name => ''hr.employees'',
 
streams_type => ''capture'',
 
streams_name => ''strm01_capture'',
 
queue_name => ''strm01_queue'',
 
include_dml => true,
 
include_ddl => true,
 
include_tagged_lcr => false);
 
END;
 
 
    如果需要更高效完成capture,并行是强烈推荐,但是也有很多注意事项,这里不多说。
 
     BEGIN
 
DBMS_CAPTURE_ADM.SET_PARAMETER(
 
capture_name => ''strm01_capture'',
 
parameter => ''parallelism'',
 
value => ''3'');
 
END;
 
 
 
 
 
 Staging process
 
1.Stream使用queue来管理和存储LCRs user messageevents;直到LCRs message被指定签署者吸收才会清除。
 
2.有两种类型的event会存储在stream queue中:LCRsuser message
 
3.用户应用可以使用DBMS_AQ
 
4. staged events可以被吸收也可以被传播
 
 
propagation:
 
1.       使用job queue来传播staged events
 
2.       使用以下两个apicreatedrop一个指定的propagation
 
DBMS_STREAMS_ADM    
 
DBMS_PROPAGATION_ADM
 
 
 
BEGIN
 
Dbms_Streams_Adm.Add_Table_Propagation_Rules(
 
table_name => ''hr.departments'',
 
streams_name => ''strm01_propagation'',
 
source_queue_name => ''strmadmin.strm01_queue'',
 
destination_queue_name => ''strmadmin.strm02_queue@dbs2.net'',
 
include_dml => true,
 
include_ddl => true,
 
include_tagged_lcr => false,
 
source_database => ''dbs1.net'' );
 
END;
 
 
Apply process
 
  一个可选的oracle后台进程,用于dequeue LCRsuser message的。能进行自动的冲突探测,不能解决的冲突被放到异常队列中去。
 
 Apply process过程中会被忽略的DDL语句:
 
CREATE/ALTER/DROP MATERIALIZED VIEW
 
CREATE/ALTER/DROP MATERIALIZED VIEW LOG
 
CREATE/DROP DATABASE LINK
 
CREATE SCHEMA AUTHORIZATION
 
ALTER DATABASE/SESSION/SYSTEM
 
RENAME
 
   这些被忽略的信息都会在ap进程的trc文件中体现出来。
 
   BEGIN
 
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
 
table_name => ''hr.employees'',
 
streams_type => ''apply'',
 
streams_name => ''apply_emp'',
 
queue_name => ''strmadmin.streams_queue'',
 
include_dml => true,
 
include_ddl => false,
 
source_database => ''cpap.net'');
 
END;
 
 
Start apply过程:
 
BEGIN
 
DBMS_APPLY_ADM.SET_PARAMETER(
 
apply_name => ''apply_emp'',
 
parameter => ''disable_on_error'',
 
value => ''n'');
 
END;
 
/
 
BEGIN
 
DBMS_APPLY_ADM.START_APPLY(
 
apply_name => ''apply_emp'');
 
END;
 
 
这样就完成了整个数据传输的过程。
 
 
STREAM的其他优越之处:
Ø     对常见ddl的支持不需要quiesce
 
Ø     摆脱了传统的分布式事务中的两阶段提交(2PC commit),只需要更少的确认就可以完成。极大的减少了网络的冲突。
 
Ø      更小的系统开销,更少的递归调用维护
 
Ø      更加易于扩展配置管理
 
Ø      支持的应用类型更为广阔,可以支持批处理类型的大事务应用。




    文章评论
 
2008-04-09 06:19:12
你对streams 和 DSG比较过么?
各有什么优劣?

2008-04-18 09:53:58
DSG RealSync与ORACLE Streams的比较
共同点
二者都是为oracle数据库提供的数据复制功能,DSG RealSync为第三方为ORACLE提供的复制工具,而Streams是ORACLE数据库提供的复制工具。
二者的目的都是为了将主数据库的数据复制到指定的从数据库上。
不同点
复制延迟时间
DSG RealSync与ORACLE Streams在复制的延迟方面,RealSync要优于oracle streams;使用DSG数据复制工具能够提供较好的数据复制的实时性,既使在业务量较高的情况下,如每秒钟处理1410条记录(更新705条+插入705条),即每秒种处理705笔交易的压力下,其延时也只是在8秒钟左右,数据就能复制到目的数据库。而ORACLE复制提供的实时性较差,在每秒钟处理不到400笔交易的情况下,其延时会达到77秒,并且随着压力的增加,延时会比较明显的增加。
根据DSG RealSync在其他的应用环境中,如果将复制周期设置为1s,其延迟时间平均控制在2s左右。
而延迟的时间指标对于复制系统是至关重要的,其直接关系到灾难发生时丢失的数据量。

对生产系统吞吐能力的影响:
DSG RealSync与ORACLE Streams在对生产系统的影响影响方面相比,RealSync要低于oracle streams;
通过测试对比,使用DSG数据复制工具对系统的处理能力影响较小,源数据库端每秒钟处理的交易数接近于没有使用数据复制时的交易数。而使用ORACLE复制对系统的处理能力影响较大,随着前台压力的增加,源数据库端每秒钟处理的交易数与没有使用数据复制时的交易数有明显的差别,高峰时会相差49%的吞吐量。
对源端CPU占用分析:
使用DSG数据复制工具对主机性能的影响较小,在源数据库端和目标数据库端对主机CPU的占用率基本低于5%。而在相同的数据抽取频率下,使用ORACLE复制对主机性能的影响较大,并且随着前台压力的增加,对CPU的占用率也随之增加。在源数据库端,最高会占用到接近15%的CPU使用率,

支持的数据类型分析
DSG RealSync支持的数据类型除了支持标准的VARCHAR2,CHAR,NUMBER,FLOAT等基本数据类型外,还支持BLOB,CLOB,LONG,LONG RAW,RAW,ROWID等数据类型;
ORACLE Streams复制工具不支持的数据类型包括NCLOB, LONG, LONG RAW, BFILE, ROWID, and UROWID, and user-defined types (including object types, REFs, varrays, and nested tables)
对日志的额外要求:
ORACLE Streams要求打开日志的‘supplemental logging’选项,而该选项的打开,将影响日志的内容,大幅度增加日志数据量。
而DSG RealSync无需要对日志作特殊要求。
支持oracle版本:
oracle streams仅支持oracle 9.2.0.*以后的版本;
而DSG RealSync支持oracle 8i,oracle9i等以后的版本;
技术支持和定制开发响应:
DSG RealSync是由第三方提供的,并且DSG在国内具有核心的研发队伍,根据我们的应用经验,这类应用经常会根据业务的需要提出特殊需求。这时需要有研发能力的支持才能让软件运行得更好。
如在一些应用中,用户提出为了避免逻辑错误而要求延迟复制,当源端出现误操作时,还能从目标端找回误操作之前的数据;如一些用户希望对于指定的有严重破坏能力的DDL语句不复制。这些要求都不是标准复制工具所具备的,但的确对于实际应用很重要的功能。DSG作为国内有研发力量的公司可以满足用户的特殊需求。
而ORACLE Streams作为ORACLE的标准配置,不可能满足用户的特殊需求改变。

 

发表评论

昵   称:
验证码:  点击图片可刷新验证码  博客过2级,无需填写验证码
内   容: