ORACLE 11G stream概念（6）

5.5.2Propagation进程
它将LCRs组装并发送到多个不同目标库的队列中，它通常并不在目标库中存在。如果采用downstream capture模式，那么不需要传播进程。
5.5.3 Apply进程
在dest db中，从队列中获取LCRs，并将LCRs直接应用到目标库中，或者将LCRs交给apply handler。
启动apply进程时会同时启动3个进程，下面是告警日志的典型内容：

Thu Jan 14 02:06:46 2010 Streams APPLY AP01 for ORA02_WCH1_APPLY_IN started with pid=60, OS id=2672 Thu Jan 14 02:06:46 2010 Streams Apply Reader for ORA02_WCH1_APPLY_IN started AS01 with pid=61 OS id=2675 Thu Jan 14 02:06:46 2010 Streams Apply Server for ORA02_WCH1_APPLY_IN started AS02 with pid=62 OS id=2677 Thu Jan 14 02:07:02 2010 Propagation Receiver (CCA) for Streams Capture ORA01_CAPTURE and Apply ORA02_WCH1_APPLY_IN with pid=50, OS id=12599 started.

关闭apply进程时，这3个进程的关闭顺序正好相反，各自的含义：APPLY (APxx =>AP00,AP01,…APZZ)、APPLY reader and execution servers (ASxx=>AS01,AS02…)。
第六节 性能
6.1Streams性能说明
Oracle官方公布的数据是，每妙可以处理1.5万到2万个LCR（每行数据的一次变动形成一个LCR）。
对于短事务，local capture和downstream real-time模式的时间延迟都很小，在秒级；对于持续执行多个长事务（这里，当一个事务执行时间超过90秒的就认为是长事务）的场景，无论哪种配置，时间延迟都比较大。
对于实时性要求高的环境中，一般建议日志量在4M/S（在ATAE上，使用ASM管理数据文件的环境）以内的，并且短事务居多的场景，可以使用streams进行数据同步。
对于实时性要求不高的环境，可以不受此约束，但是如果较长时间内持续执行多个长事务，那么两个DB上的差异会越来越大，此时如果source db故障，就会出现dest db上丢数据的现象（与source db相比，缺失了一段时间的数据）
Streams是一种低成本的数据同步技术，仅适用于实时性要求高＋事务量较小的环境，或者事务量大＋实时性要求不高的场景。
各个产品在使用streams时，需要进行压力测试，以确定CPU、内存、磁盘IO的性能，以及同步的时延性。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10129726/viewspace-706744/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10129726/viewspace-706744/