一步一步学Streams(7) 第一部分基础之应用进程(中)

cishenjian8771

墨衍会员 · AI 创作全网分发码龄10年

关注

转载最新推荐文章于 2026-08-03 13:30:56 发布 123 阅读 AI 写同款· GEO 优化 ›

4. 应用DDL修改

4.1. APPLY 进程忽略的DDL语句

　　APPLY 应用不支持下列类型的DDL语句：

ALTER MATERIALIZED VIEW
ALTER MATERIALIZED VIEW LOG
CREATE DATABASE LINK
CREATE SCHEMA AUTHORIZATION
CREATE MATERIALIZED VIEW
CREATE MATERIALIZED VIEW LOG
DROP DATABASE LINK
DROP MATERIALIZED VIEW
DROP MATERIALIZED VIEW LOG
RENAME

　　如果apply进程在应用DDL LCR时发现不支持的操作，会自动忽略该LCR并记录一条信息到apply进程的trace文件。

注意：

Alter objectType objectName rename 语句是能够被apply应用支持的，比如alter table rename之类的。Snapshot是materialized view的同义词，因此snapshot相关的语句也不会被apply应用支持。

4.2. Streams 复制环境中的数据结构

　　数据结构不仅包含数据文件、表空间、回滚段之类物理结构，还有比如表结构等等逻辑结构。捕获的DDL要在目标端完全应用，要么确保源和目标端的结构一致，要么在源端执行sql语句时不要包含目标端没有的对象。

　　比如说，一项对表做修改的DDL要想在目标端成功应用，需要考虑下列诸项因素：

Create table 的存储参数相同
如果指定了回滚段，表空间等项，则该表空间/回滚段必须确实存在于目标端。
如果指定了分区信息，则分区在目标端也必须有效。

　　注意DDL应用时，执行ddl的shcema必须已经存在于目标端数据库。

4.3. 系统产生的对象名称

　　应尽可能避免系统产生的对象名称。因为源端捕获的实际还是ddl语句，这样在目标端应用后，如果是由系统自动生成名称，则源端和目标端名称有可能会不一致，这就有可能导致后续应用的一些问题。

　　比如说源端执行这样的语句：

　　CREATE TABLE tbl (n1 NUMBER NOT NULL);

　　则系统会自动创建一个not null的约束，假设源端名称为定义为sys_000115，目标端应用create table语句时，可能为该约束创建一个非sys_000115的名字(毕竟源端与目标端并非一模一样)，当你再执行删除该约束时：

　　Alter table tbl drop constraint sys_000115;

　　源端可以正确执行，但目标端在应用该语句时就有可能报找不到sys_000115对象的错误，正确的方式，应该是在创建时指定名称，比如：

　　Create table tbl (n1 number constraint ck_tbl_nlnull not null);

4.4. CREATE TABLE AS SELECT 语句的执行

　　应用create table as select语句时，apply进程执行如下两个步骤：

目标端执行CREATE TABLE AS SELECT语句，不过只创建表并不生成数据。如果失败则apply进程返回错误信息，否则继续执行下一步。
插入数据。注意这一步实际插入的记录可能会受到capture/propagation/apply进程的自定义规则影响，实际插入记录有可能与源端不同。

5. 触发器属性

　　你可以通过DBMS_DDL.SET_TRIGGER_FIRING_PROPERTY过程控制DML/DDL触发器的触发，该过程控制触发器是否只触发一次。

　　如果该过程的fire once参数设置为true(默认情况下该参数即是true，你可以通过DBMS_DLL.IS_TRIGGER_FIRE_ONCE函数检查触发器的触发属性设置)，下列情况不会触发触发器。

相关更新由apply进程产生。
执行DBMS_APPLY_ADM.EXECUTE_ERROR/EXECUTE_ALL_ERRORS过程产生的修改。

　　举个例子，Schema：hr中创建触发器update_job_history，当employees表中job_id或department_id被更新时自动插入记录到job_history表，当前streams复制环境如下：

dbs1.net 源端capture进程同时捕获两张表的修改
Propagation 传播修改到目标端dbs2.net
Apply 进程在目标端应用修改
Update_job_history 触发器存在于源端和目标端。

　　如果目标端dbs2.net中update_job_history触发属性不是fire once的话，实际操作如下：

源端dbs1.net中employees.job_id被修改
Update_job_history 被触发，新记录插入到job_history表
源端的capture进程同时捕获到employees和job_history的修改
修改被传播到目标端dbs2.net
目标端应用这两表的修改
目标端应用employees表修改时update_job_history触发器再次被触发，又有记录被插入job_history表

　　由上可知，job_history中实际是产生了重复记录了的，多数情况下我们可能是不希望产生这种状况，如果我们设置update_job_history的触发属性为fire once(或者在创建触发器时指定on schema子句)，则dbs2.net端就不会再被触发了。

6. APPLY 进程支持的数据类型

　　下列数据类型可被apply进程支持：

VARCHAR2
NVARCHAR2
NUMBER
LONG
DATE
BINARY_FLOAT
BINARY_DOUBLE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
RAW
LONG RAW
CHAR
NCHAR
CLOB
NCLOB
BLOB
UROWID

　　不支持的类型有：BFILE, ROWID, and user-defined type (including object types, REFs, varrays, nested tables, and Oracle-supplied types)等。另外，apply进程不支持transparent data加密过的数据，不管加密数据是什么类型。

7. APPLY 进程与受限连接

　　如果以startup restrict模式启动数据库的话，apply进程就不会被启动。如果是以alter system enable restricted session语句将数据库置为restrict模式的话，对于当前正在运行的apply进程不会有影响，但不会再有新的apply进程启动，直到disable restricte。

8. APPLY 进程与RAC

　　RAC 环境下apply进程是与实例绑定的，即各实例管理各自的apply进程，如果某个apply进程因某种原因不可用的话，队列ownership自动转换至集群中其它实例。同时apply进程也会随着队列转移至相应实例。另外，激活状态的apply进程所在实例不可用的话，apply进程会自动在新实例上启动，而未激活状态的apply进程所在实例不可用的话，apply进程在新实例中仍然保持未激活状态。

　　数据字典DBA_QUEUE_TABLES中记录了队列对应的实例信息，另外在RAC环境中，apply coordinator进程，以及其对应的apply reader server和apply servers运行在相同实例上。

提示：

什么是 Reader Server ：并行执行服务，capture进程的一部分，用来读取redolog并定位其范围。

什么是 Apply Servers ：apply进程的一部分，包含一个或多个并行执行服务，用于应用LCRs或发送其至适当的apply handlers。

什么是 Apply Coordinator Process ：做为apply进程的一部分同属oracle后台进程，用于从Reader Server中获取事务并发送给Apply Servers。

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

转载于:http://blog.itpub.net/25088941/viewspace-681885/