streamconceptsadministration读书笔记

目录1流复制概念原理11.1流概述11.2流的用处21.3在数据库中捕获消息21.4安排消息进队列21.5传播消息21.6消化消息21.7捕获进程概述：21.8消息分段传递和传播31.9消息显式入队和出队41.10应用进程简述51.11消息客户端概述61.12自动冲突检测及解决61.13规则概述61.14基于规则的转变71.15流标签概述81.16流环境的管理工具81.16.1DBMS_STREAMS_ADM包81.16.2DBMS_CAPTURE_ADM 包91.16.3DBMS_PROPAGATION_ADM包91.16.4DBMS_APPLY_ADM包91.16.5DBMS_RULE_ADM 包92流捕获进程92.1LCRS(逻辑改变记录)92.1.1LOW LCRs102.1.2DDL LCRs102.2捕获进程规则112.3在流中实例化数据库对象112.4本地捕获112.4.1源数据库执行所有变化捕获112.5SCN值和捕获进程的关系122.5.1“捕获SCN”和“应用SCN”122.5.2First SCN和开始SCN122.5.3开始SCN的设定优先于实例化132.6捕获进程架构132.6.1捕获进程元件132.6.2捕获进程的状态142.6.3捕获进程的检查点143流的分段传递和传播223.1介绍消息的分段传递和传播223.2在ANYDATA队列中捕获用户塞进队消息233.3队列之间消息传播233.3.1传播规则233.3.2队列之间的传播243.3.3确保消息递交243.3.4二进制文件传播253.4消息客户端253.5ANYDATA 队列和用户消息263.6缓存消息和流客户端263.6.1缓存消息和捕获进程273.6.2缓存消息和传播273.6.3缓存消息和应用进程273.6.4缓存消息和消息客户端273.7Commit-Time队列273.7.1什么时候使用Commit-Time队列283.7.2怎样使用Commit-Time队列工作303.8流分段运输和传播的架构313.8.1流缓冲池313.8.2缓存队列323.8.3传播任务323.8.4事务和非事务队列343.8.5传播流数据字典344流的应用进程354.1应用进程简介354.2应用进程规则354.3应用进程处理消息354.3.1使用应用进程处理捕获的或用户塞进的消息354.3.2应用消息的处理选择364.4应用进程架构374.4.1应用进程元件384.4.2应用进程的创建394.4.3应用进程的流数据字典404.4.4应用进程参数404.4.5数据库重启后，应用进程保持上次的状态424.4.6错误队列42 页脚 1 流复制概念原理1.1 流概述Oracle 流能够共享信息。Oracle流每个单元的共享信息来自于消息，我们可以在流中共享这些消息。流可以在同一个数据库或不同数据库之间传播信息。”流路由”指定信息到达特定的目的地。流比起传统的在不同数据库之间捕获、管理、共享消息的解决方案，有着更强大的功能和灵活性。流提供的功能可用于分布式企业程序、数据仓库和高可用性解决方案。我们可以在同一时刻使用oracle流的所有功能。我们可以使用流的新功能而不会严重影响数据库的性能。使用Oracle流，我们可以控制流里的信息，流的流向，流进入目标数据库时，消息怎样运作，中止流。通过配置流，可以满足我们的特殊需求。基于我们的特殊情况，流可以在数据库里自动捕获、传播和管理DML、DDL消息。我们可以把用户定义的消息放入流中，流可以自动把信息传播到其它数据库或应用程序。当消息到达目的数据库时，流可以根据我们的设定应用它们。1.2 流的用处数据复制消息队列事件管理和通知数据仓库装载数据保护当数据库升级和维护时，保证它的可用性1.3 在数据库中捕获消息一个捕获进程可以捕获数据库事件，例如改变表、shemas或整个数据库的事件。这些改变被记录在redo log,捕获进程从redo log捕获这些改变，并且格式化这些改变进消息，这种消息被称为逻辑改变记录(LCR)。捕获进程使用规则(rule)去决定具体捕获哪些改变。 一个捕获进程可以在源数据库本地捕获改变或在下游数据库远程捕获改变。然后捕获进程把捕获的改变做成LCRS，打包进一个队列，进行排队。有时称捕获进程捕获消息为隐式捕获。 用户和程序也可以手动把消息入队列。这种消息被称为“用户排队消息”用户和程序手动排消息进队列有时也被称为显示捕获。1.4 安排消息进队列存储在队列中的消息有捕获消息或用户排队消息。一个捕获进程安排消息进anydata队列。1.5 传播消息流可以在同一个数据库或不同数据库的队列之间传播消息。规则决定哪些消息被传播。1.6 消化消息一条消息从队列中出来后就被消化。一个应用进程把消息隐式出对。用户、程序或消息客户端可以把消息显式出对。消化消息的数据库被称为目标数据库。规则决定消息怎么被应用进程出对和处理。一个应用进程可以直接应用消息于数据库对象，或把消息传递给pl/sql子程序进行处理。1.7 捕获进程概述：oracle数据库的改变被记录在redo log里，用于当用户误操作或介质出问题时恢复。捕获进程时oracle的后台进程，用于扫描数据库的redo log,捕获dml ddl改变操作。捕获进程把这些改变格式化成LCRS(逻辑改变记录),然后把它们塞进队列中。LCRS分两种:row LCRS和DDL LCRS。 row LCRS包含DML改变信息，DDL LCRS包含DDL改变信息。规则决定哪些改变被捕获。我们可以配置本地捕获或在下游数据库配置远程捕获。本地捕获进程在源数据库运行，并且从本地源数据库redo log捕获改变。远程捕获分两种：1） 实时下游捕获源数据库log writer 进程发送在线redo log到下游数据库。下游数据库把源数据库redo log储存成standby redo log, 捕获进程就从standby redo log种捕获改变。2） archived-log下游捕获把archived redo log 从源数据库复制到下游数据库，捕获进程从这些log中捕获改变。1.8 消息分段传递和传播流用队列来分段传递消息来达到传播和消费消息的目的。可以在同一个数据库或不同数据库之间通过队列传播消息。队列之间传递消息，可以一对多，多对一，多对多。1.9 消息显式入队和出队用户程序可以把消息显式的排入队列中。用户程序格式化这些用户进队消息成LCRS或用户消息。应用进程、消息客户端、或用户程序可以消化这些消息。显式入队的消息可以传播到另一个队列或从同一个队列出队。当消息在队列之间传播，消息可以显式排进源队列，然后被消息客户端或用户程序在目标队列显式弄出队。这些消息可以被应用进程处理。1.10 应用进程简述应用进程是oracle后台进程，它用于从队列中取出消息，然后把消息直接应用到数据库对象上，或者把消息当作参数传递给存储过程。存储过程被应用处理调用，应用处理包括消息处理、DML处理、DDL处理、错误处理。一般应用进程用于处理本地数据库，当它也可配置成处理远程非oracle数据库。规则决定哪些消息被应用进程出队。1.11 消息客户端概述消息客户端被应用程序和用户调用，用于消化用户塞入队列的消息。规则决定哪些用户塞入队列的消息被消息客户端出队。这些被用户塞入队列的消息可能是LCRS，也可能是用户消息。1.12 自动冲突检测及解决在复制环境直接应用LCRS时，应用进程自动侦测冲突。当冲突发生时，我们需要一个机制确保冲突依据某种规则解决。流提供了好几种默认冲突解决处理的handlers。如果我们有特殊情况，可以自己建立解决冲突的handlers。1.13 规则概述流使我们可以控制共享哪部分信息。在流上使用规则，可以使我们加上条件过滤信息。流包含后面这些组件：n 规则条件包含一个或更多表达式、条件和返回的布尔值。n 评估块定义外部数据满足规则的条件。n 活动块。我们可以把规则集成进规则集。在流中，规则集可以是肯定也可以是否定。例如，后面的规则条件指定流中的数据方案名必须是hr，表名必须是departments:dml.get_object_owner() = HR AND :dml.get_object_name() = DEPARTMENTS在流环境中，带着上面条件的规则可以以下面几种方法来使用:n 如果规则是肯定规则集，用于捕获进程，则它是指定捕获进程捕获hr。departments表的DML改变。如果是否定规则集，则它是指定捕获进程忽略hr.departments表的DML改变。n 如果规则是肯定规则集，用于传播，则它是指定传播包传播数据去hr.departments表。如果是否定规则集，则它是指定传播包忽略传播数据去hr.departments表。n 如果规则是肯定规则集，用于应用进程，则它是指定应用数据于hr.departments表，如果是否定规则集，则它是指定应用进程忽略应用数据于hr.departments表。n 如果规则是肯定规则集，用于消息客户端，则它是指定消息客户端出队数据去hr.departments表，如果是否定规则集，则它是指定应用进程忽略出队数据去hr.departments表。流执行任务基于规则。这些任务包括使用捕获进程捕获消息，使用传播包捕获消息，使用应用进程应用消息，使用消息客户端出队消息。1.14 基于规则的转变基于规则的转变是指任何肯定的规则集的消息改变。有两种基于规则的转变：宣告和定制。n 宣告的基于规则的转变包含很多种转变情况，包括重命名方案，重命名表名，加列，重命名列名，删掉列。流在地执行宣告的基于规则的转变，不需要调用PL/SQL。n 定制的基于规则的转变需要用户定义PL/SQL函数去执行转变。流调用PL/SQL函数去执行这些转变。定制的基于规则的转变可以修改捕获消息或用户塞入队列的消息。这些消息是LCRS或用户消息。例如，定制的基于规则的转变可以改变LCR中列的数据类型。 实现定制的基于规则的转变，可以使用DBMS_STREAMS_ADM.SET_RULE_TRANSFORM_FUNCTION。这个函数可以把输入的消息的列转换成其它的数据类型。例如，输入的对象是包含数据类型的列的LCR,它可以把类型转换成varchar2类型，返回。定制的基于规则的转变可能发生在下列时间点：l 捕获进程捕获到消息进队时，基于规则的转变把消息格式化成适合目的数据库样式。l 传播消息的时候，基于规则的转变有利于把消息传送到远方的特殊站点。l 应用进程或消息客户端把消息出队时，基于规则的转变把消息格式化成适合目的数据库样式。 1.15 流标签概述在redo log中，每一个redo项都有一个标签和它对应。标签的数据类型是RAW。默认的标签值是NULL,在redo项空标签不占用空间。标签的最大值是2000字节。在流中，规则可以根据标签值来控制流客户端的行为。例如，标签可以用于判断一个LCR里的改变是本身数据库还是别的数据库的改变。因此避免循环改变。标签也可以用于为LCR指定目标数据库。标签也可以用于追踪LCR。我们可以在会话和应用进程中指定特殊的流标签。这些标签将成为LCRs的一部分，被捕获进程捕获。标签一般用于流复制，但只要有必要，我们也可用于追踪数据库改变和LCRs。1.16 流环境的管理工具oracle提供了几款工具用于配置、管理、监控流环境。1.16.1 DBMS_STREAMS_ADM包DBMS_STREAMS_ADM包用于增加或删除捕获进程、传播、应用进程的规则。这个包也用于控制哪些消息被传播，哪些消息出队。这个包包含创建队列和流数据字典的存储过程。这个包也包含用于配置和维护流复制环境的存储过程。它提供一种简单的方法创建流环境。1.16.2 DBMS_CAPTURE_ADM 包DBMS_CAPTURE_ADM用于启动、停止和配置捕获进程。1.16.3 DBMS_PROPAGATION_ADM包DBMS_PROPAGATION_ADM包用于配置从源队列到目标队列的传播。1.16.4 DBMS_APPLY_ADM包DBMS_APPLY_ADM包用于启动、停止和配置应用进程。这个包提供存储过程用于配置应用处理器；这个包提供子程序用于配置冲突检测、解决和错误处理。1.16.5 DBMS_RULE_ADM 包DBMS_RULE_ADM包用于创建和管理规则、规则集。2 流捕获进程2.1 LCRS(逻辑改变记录)捕获进程格式化从redo log中捕获的改变进LCRs。一条LCR是一个特殊格式的描述数据库改变的消息。捕获进程捕获两种LCRs: row LCRs 和DDL LCRs。捕获LCR后，捕获进程把包含LCR的消息塞进队列中。2.1.1 LOW LCRs每个LOW LCR被封装成LCR$_ROW_RECORD对象类型，包含下列属性:n source_database_name: 记录发生改变的源数据库名n command_type:DML操作类型，如insert,update,delete,lob erase,lob write,or lob trimn tag: 记录标签，用于追踪LCR。n transaction_id:标识DML属于哪个事务n old_values:DML改变前的列值n new_values:DML改变后的列值2.1.2 DDL LCRsDDL LCR 描述DDL改变。DDL语句改变数据库结构。例如，DDL可以创建、改变或删除数据库对象每个DDL LCR包含下列信息：n source_database_name: 记录发生改变的源数据库名n command_type:DML操作类型，如insert,update,delete,lob erase,lob write,or lob trimn object_owner: DDL语句作用对象的属主n object_name: DDL语句作用对象的名称n object_type: DDL语句作用对象的类型n ddl_text:DDL语句文本n logon_user:运行DDL语句的登入用户。n tag: 记录标签，用于追踪LCR。n tag: 记录标签，用于追踪LCR。n transaction_id:标识DDL属于哪个事务n scn:发生改变时写入redo log的scn2.2 捕获进程规则捕获进程基于我们定义的规则捕获或忽略改变。我们可以把规则放入肯定或否定规则集中。如果规则位于肯定规则集中，捕获进程就会捕获相应改变，否则，忽略。2.3 在流中实例化数据库对象1）在源数据库准备实例化的对象2）如果这个对象在目标不存在，可以用exp/imp或rman创建，如有则不必。3）设定实例化scn,实例化scn指定目标数据库的应用进程只应用源数据库特定scn之后发生的改变。有时候13步可以自动完成。我们可以使用exp/imp复制对象到目标数据库，这样实例化scn将被自动设好。只要应用进程出队捕获的消息，就需要实例化，即使应用进程只是发送LCRS到应用handler,而不执行它们。2.4 本地捕获本地捕获意味着捕获进程运行在源数据库。2.4.1 源数据库执行所有变化捕获如果我们配置了本地捕获，源数据库将会执行下列动作：n DBMS_CAPTURE_ADM.BUILD存储过程抽取数据n 源数据库的补充日志放了一些附加信息到redo log里。应用进程需要这些信息。n 数据库第一次启动捕获进程时，Oracle用从redo log提取的数据字典信息创建LogMiner 数据字典，n 捕获进程使用LogMiner扫描redo log捕获改变。n 规则引擎衡量基于规则的改变。n 如果在数据库之间共享捕获改变，传播包就会把改变传播到目的数据库。n 捕获进程把满足规则的改变塞进队列。2.5 SCN值和捕获进程的关系scn值对于捕获进程很重要。你可以查询DBA_CAPTURE得到scn的值。2.5.1 “捕获SCN”和“应用SCN”捕获SCN是捕获进程最近从redo log扫描到的改变相对应的SCN。应用scn是最近应用进程出队的消息对应的SCN。所有低于应用scn的消息都已经被应用进程出队。应用scn对于捕获进程相当于低水位线SCN对于应用进程一样。2.5.2 First SCN和开始SCN2.5.2.1 First SCNFirst SCN是捕获进程可以扫描的redo log中最小scn。如果你在捕获进程创建时指定了first scn,那么数据库必须可以访问比这更高的scn重作数据。DBMS_CAPTURE_ADM.BUILD存储过程抽取原数据库数据字典数据到redo log里。我们可以在redo log中建立同这个数据字典相应的first scn。捕获进程建立时的first scn可以设定为下列查询返回的任意值：COLUMN FIRST_CHANGE# HEADING First SCN FORMAT 999999999COLUMN NAME HEADING Log File Name FORMAT A50SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOGWHERE DICTIONARY_BEGIN = YES;NAME列的值是包含scn适合作first scn 的redo log的名字，这些redo log文件必须可以被捕获进程访问。如果这个查询返回多个值，则DBMS_CAPTURE_ADM.BUILD存储过程已经在源数据库运行多次。有时候，DBMS_CAPTURE_ADM.BUILD存储过程会在捕获进程创建时自动运行。2.5.2.2 开始SCN开始scn是捕获进程开始捕获改变对应的scn。我们可以指定不同于first snc的开始scn。当捕获进程正常工作的时候不需要改变开始SCN。当目标数据库发生点恢复时需要重设捕获进程的开始SCN。这样，捕获进程才能捕获源数据库点恢复后发生的改变。2.5.2.3 开始SCN必须大于或等于first SCN当你创建或改变捕获进程时指定开始scn,那么必须指定大于或等于捕获进程first scn的scn。捕获进程总是扫描大于first scan的 redo log。即使redo log 里的scn小于开始scn。如果你指定了过大的开始scn，捕获进程就会漏掉一些改变了的数据。我们要避免扫描开始scn之前的redo log,因为它会浪费时间。oracle推荐尽可能最小化开始scn和first scn之间的差距，这样可以加快初始化捕获进程的时间。2.5.3 开始SCN的设定优先于实例化如果我们想捕获数据库对象的改变并且用应用进程应用这些改变。只有数据库对象实例化以后发生的改变才会被应用。因此，如果我们的开始scn高于数据库对象实例化时的scn。则任何我们捕获的先于开始scn的改变都不能被应用。这个限制对于创建捕获进程时机很重要。如果数据库对象没有先于捕获进程创建好。则应用进程不能应用捕获的先于捕获进程创建时间的改变。有时候，数据库对象先于捕获进程创建好。例如，我们想在源数据库创建一个新的捕获进程，很多数据库对象早于这个捕获进程就已经建立好。我们想用新的捕获进程捕获这些数据库对象的改变。则应用这些改变的应用进程必须满足下面这些条件：n 数据库对象必须在捕获进程之前实例化n 新捕获进程的开始scn必须早于数据库对象实例化之前的scnn 开始scn对应的redo logs一定要可用。2.6 捕获进程架构捕获进程时oracle后台的可选进程，它的名字格式如cXXX，XXX是捕获进程号。可用的捕获进程名可以从c000-c999。捕获进程通过LOGMINER的底层结构从redo log获取改变。流自动配置LOGMINER。我们可以create、alert、start、stop和drop捕获进程。我们也可以定义捕获那些改变的捕获进程规则。2.6.1 捕获进程元件捕获进程由下列元件组成n 一个读服务，用于读redo logn 一个或多个preparer 服务。preparer服务预先过滤redo log中的改变。n 一个builder服务，builder服务合并从prepareer服务来的记录。这些redo log要么被“不完全评估器”评估为真，要么“不完全评估器”给出“没确定的”结论。builder服务会保留这些记录的SCN顺序，并把合并的redo 记录集发送给捕获进程。n 捕获进程会格式化改变进LCR。如果LCR是“没确定”，捕获进程会把它发送给规则引擎进行“完全评估”。捕获进程然后接收LCR“完全评估”后的结果。接着捕获进程把满足“肯定规则集”的LCR塞进队列中，丢弃满足“否定规则集”和不满足“肯定规则集”的LCR。每一个reader服务、preparer服务和builder 服务都是并行执行的服务。2.6.2 捕获进程的状态捕获进程的状态描述捕获进程正在做什么。我们可以通过查看v$streams_capture视图的state列查看捕获进程的状态。捕获进程有下列状态：n INITIALIZING-开始n WAITING FOR DICTIONARY REDO等待包含关系first scn的字典的redo log 文件被加进捕获进程会话。直到所有包含字典的redo log文件被加，捕获进程才可以开始扫描redo log文件。n CAPTURING CHANGES-扫描redo log。n CREATING LCR-把改变格式化成LCR。n ENQUEUING MESSAGE-把满足规则的LCR塞进捕获队列。n PAUSED FOR FLOW CONTROL-不能够塞LCR进队列。可能由于传播或应用进程消化消息慢过捕获进程创建消息。当传播包或应用进程远远落后或不可用时，它可以提醒，减少遗漏捕获的信息。2.6.3 捕获进程的检查点检查点通知捕获进程的当前状态。这个状态保存在数据库的数据字典中。2.6.3.1 需要检查点SCN捕获进程需要的redo数据的最低检查点相应的SCN是需要检查点SCN。包含需要检查点SCN的redo log文件必须队捕获进程可用。如果捕获进程重启或停止，那么它启动的时候将从需要检查点SCN对应的SCN开始扫描redo log。数据库不正常停止的时候，需要检查点SCN对于恢复来说很重要。如果重设了捕获进程的first scn，那么它的设定值必须小于或等于需要检查点SCN。我们可以通过查询DBA_CAPTURE视图的REQUIRED_CHECKPOINT_SCN列得到需要检查点的值。2.6.3.2 最大检查点SCN捕获进程的最后检查点记录对应的SCN 是最大检查点SCN。如果你创建了一个捕获进程从源数据库捕获改变，并且同一个数据库还有老捕获进程存在，那么老的捕获进程的最大检查点SCN可以帮助我们决定新的捕获进程是否需要创建新的LogMiner 数据字典或者共享已经存在的LogMiner数据字典。我们可以通过查询DBA_CAPTURE视图的MAX_CHECKPOINT_SCN列来查看最大检查点SCN。2.6.3.3 检查点保留时间(Checkpoint Retention Time)检查点保留时间是捕获进程自动清除检查点之前保留它们的时间天数。捕获进程会周期性的计算检查点时间，如果过期，捕获进程会自动清除这个检查点。只要捕获进程重设了first scn，捕获进程就从LogMiner数据字典中清除早于新的first scn的archived redo log文件的信息。信息清除后，archived redo log仍然留在硬盘，但捕获进程不再需要这些文件。DBA_REGISTERED_ARCHIVED_LOG视图PURGEABLE列显式为YES的archived redo log 就表示不需要这些文件了。清除这些文件不影响捕获进程。用DBMS_CAPTURE_ADM包创建捕获进程的时候，我们可以指定检查点保留时间。我们也可以用DBMS_CAPTURE_ADM包的ALTER_CAPTURE存储过程改变检查点保留时间。2.6.3.4 捕获进程的创建我们可以使用DBMS_STREAMS_ADM包或者DBMS_CAPTURE_ADM包创建捕获进程。使用DBMS_STREAMS_ADM包创建捕获进程比较简单，因为它会自动配置很多选项。当我们使用DBMS_STREAMS_ADM包时，规则集会被自动创建，规则会自动加入规则集中。DBMS_CAPTURE_ADM包创建捕获进程，使用上更加灵活，我么可以给捕获进程配置一个或多个规则集。我们可以使用DBMS_STREAMS_ADM包或DBMS_RULE_ADM包增加规则到规则集中。当我们使用DBMS_STREAMS_ADM包的存储过程创建捕获进程时，捕获进程捕获的对象会自动实例化。当我们使用DBMS_CAPTURE_ADM包的CREATE_CAPTURE存储过程创建捕获进程时，我们要自己手动实例化捕获进程捕获的数据库对象。我们可以使用下列的DBMS_CAPTURE_ADM包的存储过程实例化对象。n PREPARE_TABLE_INSTANTIATION准备实例化单一表n PREPARE_SCHEMA_INSTANTIATION准备实例化方案下的所有对象并且在将来把所有对象加到方案中。n PREPARE_GLOBAL_INSTANTIATION准备实例化所有数据库中的对象，并且在将来把所有对象加到数据库中。2.6.3.4.1 捕获进程的LogMiner数据字典捕获进程需要一个同主数据字典分开来的数据字典。这个数据字典被称为LogMiner数据字典。一个源数据库可以有超过一个LogMiner数据字典。如果一个源数据库有多个捕获进程，那么捕获进程之间可以共享LogMiner数据字典，也可以每个捕获进程拥有一个它自己的数据字典。如果LogMiner数据字典不存在，那么捕获进程就在进程启动时自己从redo log中取出有用的信息组织起来。DBMS_CAPTURE_ADM.BUILD存储过程从redo log中抽取数据字典信息。这个存储过程在捕获进程启动之前必须至少运行一次。我们可以在redo log中多次执行建立数据字典信息。运行BUILD存储过程时从redo log抽取多少信息依赖于数据库中有多少数据库对象。BUILD存储过程会产生大量的redo数据，所以我们要减少BUILD的使用次数。没必要时就不要运行它。一般情况下，我们建立捕获进程时调用的DBMS_STREAMS_ADM或DBMS_CAPTURE_ADM包里的存储过程会帮我们自动建立LogMiner数据字典。捕获进程之所以需要LogMiner数据字典是因为捕获的改变里面非常可能没有相关的数据对象信息。而且这些改变可能已经发生了几个小时。考虑下发生了下面的情况：1） 捕获进程捕获某个表的改变。2） 数据库管理员停止了捕获进程。3） 用户继续修改表。4） 几个小时后，捕获进程重新启动。在这种情况下，为了保证数据的连续性，捕获进程必须开始捕获它停止之后发生的改变。但redo log包含raw数据。redo log里的raw数据没有数据库对象名和列名。它使用对象号和列号。因此捕获进程必须参考数据字典来完善信息。因为LogMiner数据字典会发生重组，所以会花费一些时间捕获这些改变。具体要花费多少时间依赖于数据库里的数据对象数量。我们可以通过查询V$STREAMS_CAPTURE动态视图的STATE列来观察数据字典重建进展。2.6.3.4.1.1 举例说明为什么需要LogMiner数据字典假设有这样一个情况：我们配置了一个捕获进程去捕获表T1的改变，表T1有列A和B,接着在下面3个时间点发生了下面的改变。时间点1：插入数据A=7,B=15到表A时间点2：增加列C到表A时间点3：删除列B.这样的话主数据字典就有着和LogMiner数据字典不同的信息如果捕获进程使用主数据字典，在时间点3捕获了时间点1的插入。那么它会把B列的值15插入到C列中。这就发生错误了。但如果使用LogMiner数据字典就可以避免这个错误。因为LogMiner数据字典在时间点1记下了表T1有A、B两个列。所以捕获的改变将是把15插入列B。2.6.3.4.1.2 同一数据库多个捕获进程如果同一数据库有多个捕获进程这些捕获进程可以共享LogMiner数据字典也可以使用自己的LogMiner数据字典。建立新的捕获进程时是否建立LogMiner数据字典，取决于运行CREATE_CAPTURE创建捕获进程时first_scn参数设为何值。n 如果first_scn参数设为空，那么新建立的捕获进程将与老的捕获进程共享LogMiner数据字典。n 如果first_scn参数设为非空，那么新的捕获进程将使用新的LogMiner数据字典。如果存在多个LogMiner数据字典，而且first_scn参数设为NULL，那么新建立的捕获进程会自动使用已经存在的LogMiner数据字典。我们应该使用新的 LogMiner数据字典呢还是共享已经存在的LogMiner数据字典呢?如果使用老的LogMiner数据字典，那么新的捕获进程必须从最大检查点SCN对应的日志开始进行扫描，尽管新的捕获进程并不会捕获这些先于first scn的改变。如果开始scn远大于最大检查点scn，那么新的捕获进程将扫描大量的redo数据。n 如果有一个或多个最大检查点SCN值大于开始SCN，而开始SCN远大于first scn，建议使用已经存在的LogMiner数据字典n 如果没有最大检查点SCN值大于开始SCN，而开始SCN与first scn差距很小，建议使用已经存在的LogMiner数据字典n 如果没有最大检查点SCN值大于开始SCN，而开始SCN与first scn差距很大，建议新建LogMiner数据字典。建立新的LogMiner数据字典会花费一些时间。但是捕获进程会指定first scn和开始scn同样的值，避免扫描大量的redo数据。2.6.3.4.2 捕获进程创建时开始scn和first scn的指定当我们用DBMS_CAPTURE_ADM包的CREATE_CAPTUE存储过程创建捕获进程时，我们可以指定first scn和开始scn。first scn是捕获进程捕获的redo log中的最低scn。first scn可以通过建立数据字典或查询V$ARCHIVED_LOG动态视图。开始scn是捕获进程开始捕获改变相对应的scn。开始scn必须大于或等于first scn。捕获进程从first scn或已经存在的捕获进程的检查点开始扫描redo 数据，即使开始scn远高于first scn或捕获进程的检查点。这种情况下，捕获进程不捕获开始scn之间的改变。oracle建议first scn和开始scn之间尽可能小，减少捕获进程扫描的数据。2.6.3.4.2.1 非空的first SCN和空的开始SCN我们新的捕获进程时指定了参数first_scn，那么新的开始scn将会被自动设定为first scn。并且捕获进程不会捕获这个scn之前的任何改变。当捕获进程第一次运行时，它会用redo log里的数据字典信息建立LogMiner 数据字典。DBMS_CAPTURE_ADM包的build存储过程必须在源数据库至少运行一次，如果没有运行，当捕获进程启动时，将会发生错误。2.6.3.4.2.2 非空的first SCN和非空的开始SCN如果指定的开始scn参数大于或等于first scn参数。那么新的捕获进程将被建立，而新的LogMiner 会话将从fist scn开始。这种情况下，新的捕获进程不捕获开始SCN之前的改变。如果开始scn的值低于first scn，将会产生一个错误。DBMS_CAPTURE_ADM包的BUILD存储过程不会自动运行。在源数据库这个存储过程至少被调用一次，指定的first_scn必须是以前创建的可用的redo log中的scn值。当新捕获进程第一次启动时，它会从重作日志中抽取数据字典信息创建LogMiner数据字典。如果DBMS_CAPTURE_ADM包的BUILD存储过程在源数据库没有至少运行过一次，那么就会产生错误。2.6.3.4.2.3 捕获进程的空的First SCN和非空的开始SCN新的捕获进程会在下列两种情况创建LogMiner数据字典：n 源数据库没有存在的捕获进程，指定的给start_scn参数的值大于或等于当前SCN。n 源数据库有捕获进程，但捕获进程都仍没有产生检查点，指定的给start_scn参数的值大于或等于当前SCN。以上两种情况，捕获进程创建时都会运行DBMS_CAPTURE_ADM包的BUILD存储过程。新的捕获进程用redo log中的数据字典信息去创建LogMiner数据字典。first scn回合数据字典建立时的scn一致。如果源数据库存在的本地捕获进程已经产生过检查点，那么新的捕获进程会和老捕获进程共享LogMiner数据字典。这种情况下，捕获进程的first scn小于或等于指定的开始scn.如果源数据库没有老捕获进程或者老捕获进程没有产生检查点，而指定的开始scn小于当前数据库的scn，那么一个错误将会产生。2.6.3.5 新的First SCN和清空LogMiner数据字典视图信息当我们为已经存在的捕获进程重设first scn的值时，oracle会自动清除新first SCN之前的LogMiner数据字典信息。如果开始SCN也被清除了，那么oracle会自动重设开始scn等于first scn。如果开始scn高于first scn，那么开始scn保持不变。2.6.3.6 流数据字典传播和应用进程使用流数据字典跟踪源数据库数据对象。只要数据库对象在源数据库已经准备好实例化，流数据字典就会被发布。捕获进程扫面redo log,利用里面的数据库对象信息发布流数据字典。流数据字典保存在源数据库中。当我们准备实例化一个数据库对象时，我们会告诉流，传播和应用需要的那些数据库对象信息。任何数据库传播和应用这些改变都需要源数据库改变发生时的流数据字典。当数据库对象实例化准备好后，当捕获进程处理作用与数据库对象的DDL语句时，本地数据字典会被更新。例如，一个包含DDL语句的部消息被捕获进程捕获。然后被放进队列中。传播然后把这个部消息传播到目标数据库的目标队列。流数据字典时多版本的。如果一个数据库有多个传播和应用进程，则所有这些都使用同样的流数据字典。一个源数据库只能有一个流数据字典。2.6.3.7 捕获进程的参数在创建完捕获进程后，及在捕获进程第一次启动之前，捕获进程处于停止状态，这是为了使我们可以设定捕获进程参数。捕获进程参数控制着捕获进程的运行方式。如，参数time_list指定了捕获进程自动运行使的停止间隔。2.6.3.7.1 Capture Process ParallelismCapture Process Parallelism 参数控制着准备服务器的数量。准备服务器负责格式或redo log里的改变成LCRs格式。每一个读服务器、准备服务器、和建立服务器都是并行运行的执行服务。准备服务器的数量等于Capture Process Parallelism 参数。所以Capture Process Parallelism 参数设为5，那么捕获进程将有7个并行执行服务一个读服务器，5个准备服务器和一个建立服务器。2.6.3.7.2 自动重启捕获进程我们可以配置当到达一定时间自动停止捕获进程。The time_list捕获进程参数指定捕获进程运行时间。message_limit参数指定捕获进程可以同时捕获的消息数。disable_on_limit参数控制当捕获进程到达限制时是否停止或重启。如果我们设定disable_on_limit参数为Y,则捕获进程到达极限时它不会停止；反之，设为n,则它会停止捕获进程，并自动重启。当捕获进程重启时，它开始捕获从上次停止以来的改变。重启捕获进程会获得一个新的会话 ID,并行执行服务也会得到一个新的会话ID。然而，捕获进程(cnnn)还是同样。2.6.3.8 捕获进程规则运算捕获进程依靠它的肯定和否定规则集评估它在redo log里发现的改变。捕获进程首先依靠否定规则集。如果一个改变属于否定规则集，则改变被丢弃。但如果没有规则在否定规则集设为true,则所有改变满足否定规则集。但一个改变满足否定规则集，则接着进入肯定规则集运算。如果在肯定规则集没有规则设为true，则所有改变都被丢弃。一个捕获进程会完成下列步骤去捕获改变：1、 发现在redo log中的改变；2、 执行redo log中的预先过滤。在这个步骤执行中，捕获进程会在基本级别评估规则集中的规则，放置那些在redo log中发现的改变进两个类别：一个是将来转换成LCRs的改变和另一个将来不转换成LCRs的转变。预先过滤分两步处理。首先过滤方案名，对象名，命令类型。第二步过滤tag值和列值预先过滤是使用不完全信息的安全优化。这步之后将进行相关的处理n 一个捕获进程把转变转化成LCR，如果转变符合捕获进程的规则集设定。n 捕获进程不转化改变成LCR,如果改变不满足捕获进程集。n 考虑不确定的情况，规则运算将指行下列步骤： 如果捕获进程没有足够的信息判断改变是否满足规则集，这种情况下，需要进一步运算。3、 把满足或可能满足规则集的改变转变成LCRs。4、 执行LCR过滤。这步捕获进程会评估每一个LCR里的信息，把LCRs分成两类：应该进队的LCRs和应该被丢弃的LCRs。5、 丢弃那些不进对的LCRs。6、 把剩余的捕获信息塞进队列中。例如，假设后面的规则是定义为捕获进程的肯定规则集：捕获hr.employees表department_d等于50 的改变。没有其它规则集被定义。parallelism参数被设为1。一条update语句更改了hr.employees表50行数据。捕获进程将执行下列一系列针对每行改变的动作：1、 在redo log里发现UPDATE语句的下一个改变结果。2、 判断是否是针对hr.employees表及必须被捕获的改变。如果不是忽略改变3、 捕获改变，并且把他们转换成LCR.4、 把department_id等于50的LCR过滤出来5、 把LCR塞进队列中，丢弃不符合条件的LCR。2.6.3.9 数据库重启后保持上次捕获进程的状态但数据库重启后捕获进程维持一定的状态。例如，如果当数据库停止的时候捕获进程是启动的，那么捕获进程会在数据库启动时自动起来。类似的，如果当数据库停止时捕获进程是停止或放弃的，那么但数据库启动时捕获进程仍然保持停止或放弃的状态。3 流的分段传递和传播3.1 介绍消息的分段传递和传播流使用队列来分段传递消息。一种ANYDATA类型的队列可以分段传递所有类型的消息。同时它被称为ANYDATA队列。一种type类型的队列可以储存特殊类型的消息。流客户端总是使用ANYDATA队列。在流中，两种类型的消息可以被封装进ANYDATA对象并且塞进ANYDATA队列中：逻辑改变记录(LCRS)和用户消息。LCR时包含数据库对象改变信息的对象。用户消息时被用户程序建立的用户定义的消息。这两种类型的消息都可以用于信息共享。在消息环境中，ANYDATA队列和TYPED队列都可以用于分段传递特殊类型的消息。publishing程序可以把消息塞进队列中。subscribing程序可以把这些消息出队。分段传递的消息可以被消化或传播。分段传递的消息可以被应用进程、消息客户端、用户程序消化。应用进程隐式的出队队列。但是消息客户端和用户程序时显式地出队队列。如果你配置了流传播用于传播或发送，即使消息被消化了，它仍然可以留在队列中。队列中的消息可以在同一或不同数据库之间传播。传播出消息来的队列叫源队列，接受消息的队列叫目标队列。在源和目标队列之间可以一对多，多对一，多对多。我们可以创建、修改和删除传播。我们也可以定义传播哪些规则的传播规则集。源队列的属主时传播消息的用户，这个用户必须有足够的权限去传播消息。如果目的队列在远程数据库，那么源队列必须可以使用数据库裂解，目标队列的用户一定要有进队的权限。3.2 在ANYDATA队列中捕获用户塞进队消息消息可以用两种方法进入ANYDATA队列中：n 捕获进程可以把捕获的改变塞进队列n 用户程序也可以把用户消息打包成一个ANYDATA类型的对象。这些用户消息可以包含LCRS或其它类型的消息。任何被用户或应用程序显示进队的消息称为用户塞进队消息。被用户存储过程塞进队列的消息称为用户塞进队消息。每一个捕获消息都包含LCR，但用户塞进队列的消息可能有也可能没有LCR。传播捕获消息或用户塞进队消息塞进目标队列。消息从ANYDATA队列出队有两种方法：n 一个应用进程出队一个捕获或用户塞进队消息。如果消息包括LCR，那么应用进程可以直接应用他或调用一个用户指定存储过程处理它。如果消息不包含LCR,那么应用进程可以调用用户指定存储过程（称为消息处理器）去处理它。另外捕获的被应用进程出队然后被DBMS_APPLY_ADM包中的SET_ENQUEUE_DESTINATION进队的消息被称为用户塞进队消息。n 一个用户应用程序显式地出对一个用户出队消息并且处理他们。用户应用程序可能也可能不使用流消息客户端。捕获的消息不能用用户程序出队。捕获的消息必须用应用进程出队。然而，如果一个用户存储过程被应用进程显式地调用进队消息，则这个消息是用户塞进队消息，可以被显式出队。即使这个消息原先是一个捕获消息。出队的消息可能源于同一个数据库，也可能是不同数据库。3.3 队列之间消息传播你可以使用流配置两个队列之间的消息传播，这两个队列可以位于不同的数据库，流使用工作队列去传播消息。一个传播总是在源队列和目标队列之间。尽管传播总是在两个队列之间。但也可以一个队列参与到多个传播中。既是，一个源队列可以传播消息到多个目标队列，也可以一个目标队列接收多个源队列。一个传播可以传播所有源队列的消息到目标队列，或者传播可以传播消息的子集。单一传播可以传播捕获消息和用户塞进队消息。你可以使用规则去控制哪些源队列的消息传播去目的队列，哪些消息被丢弃。依赖于你打算怎样安装你的流环境，你需要配置你的环境，避免形成循环改变，在一个封闭的回圈里。我们可以使用流 tags去避免“改变循环回圈”3.3.1 传播规则一个传播传播消息或丢弃消息是根据我们定义的规则，对于LCRs，就是一个规则指定的数据库对象和变化的类型被评估为真。我们可以放置这些规则进否定或肯定规则集中。如果一个消息符合某条规则，而规则是在肯定规则集中，那么传播器将传播那个改变。如果一个消息符合某条规则，而规则是在否定规则集中，那么传播器将丢弃那个改变。如果一个改变即在否定规则集中，又在肯定规则集中，那么否定规则集总是优先考虑。我们可以在下列级别设定LCRs的传播规则集：n 表级规则定义传播或丢弃DML或DDL改变的特定表的记录改变的结果。n 方案级规则定义传播或丢弃DML或DDL改变的特定方案的数据库对象的记录改变结果。n 一个global级别的规则定义传播或丢弃所有DML或DDL改变的在源队列中的所有的记录改变结果。3.3.2 队列之间的传播一个传播可以是队列到队列之间，也可以是队列到数据库。一个队列到队列的传播器总是有它自己独享的传播job从源队列到目标队列之间传播消息。因为每一个传播job有它自己的传播调度计划，所以每一个队列之间的传播器的工作调度可以分开管理。即使同一个数据库有多个队列传播器调度，我们可以启动、停止或设定调度计划于每个单独的队列间的传播器。一个数据库可以用于多个队列传播器。数据库名必须同全局数据库名一样。一个队列到数据库的传播器和其它队列到数据库的源自同一数据队列的传播器共享传播任务。因此，这些传播共享同言道传播任务调度，任何传播调度的改变都会影响所有源自同一数据库队列的队列到数据库的传播器。如果有目标队列服务，那么队列到队列的传播器会连接到目标队列服务。当多个传播器用单一数据库时，每个队列到队列的连接描述会自动改变，传播消息到正确的目标队列。相反，如果目标队列所在的RAC数据库出问题了，队列到数据库的传播需要我们重新调整数据库。3.3.3 确保消息递交一个用户塞进队消息进入了目标队列并且被commit后才算是正确传播到了目标队列中。一个捕获消息只有下列动作都完成了才算是正确传播：n 消息已经被所有相关的应用进程处理。n 消息已经成功传给所有相关目标队列当消息在两个ANYDATA队列之间成功传播后，目标队列会回复一个“成功传播”的消息。如果源队列配置成传播消息给多个目标队列，那么消息仍然留在源队列直到每个目标队列都发送了确认消息给源队列。当每个目标队列都会服了成功传播的消息，那么所有源队列所在的数据库本地消费者已经消化了这些消息，源队列可以删掉消息了。这个确认系统确保消息总是从源队列到目标队列，但是，有些配置，源队列的成长大于理想大小。当源队列变大时，它会使用更多的存更多的磁盘空间。有两情况，源队列会变大：n 由于网络原因，消息不能从源队列到目标队列，则消息保存在源队列直到目标队列可以使用。这种情况可能导致源队列变得非常大。所以我们应该规律性的监控我们的队列，早点发现问题。n 假设一个源队列传播捕获的消息到多个目标队列，一个或多个目标数据库的回复很慢。这种情况下，由于慢数据库积压了大量的消息，源队列也会变大。这种环境下，考虑创建更多的捕获进程捕获源数据库的改变。让一个源队列对应慢目标数据库，一个对应快目标