哪些情况OGG抽取进程需要旧的归档日志呢：
抽取进程abend或stop了一段时间，再次启动自然需要这段时间内的所有归档日志。比如重启了OS或数据库，但忘了启动ogg；长假期间抽取进程abend了无人知晓。
数据库存在迟迟未提交的长事务，时间长了事务的redo信息可能刷到了归档文件中，后面事务提交时抽取进程要扫描这些归档。比如开发人员通过plsqldeveloper修改了表数据，忘了提交；数据库（BI/DW）存在运行比较久的事务或job。
OGG bug导致抽取进程需要一个非常旧的归档
————————————————
抽取进程如何找归档
------For classic Extract
OGG优先到数据库默认归档路径查找归档（SELECT THREAD#,SEQUENCE#,FIRST_TIME ,name FROM v$archived_log）。也可以通过参数指定归档查找路径：
TRANLOGOPTIONS ALTARCHIVELOGDEST PRIMARY INSTANCE oraXPAD1 /gg/sarch1, ALTARCHIVELOGDEST INSTANCE oraXPAD2 /gg/sarch2
加PRIMARY的话就是优先从ALTARCHIVELOGDEST参数路径下是查找。
------For Integrated Extract
Integrated Extract原理是由于stream+logminer去抽取数据，每一个抽取进程运行时都有对应的logminer进程在工作，基本是OGG由于数据库字典信息寻找归档所在路径。
如果想指定归档路径，可以使用以下参数（OGG 12.3起）
TRANLOGOPTIONS INTEGRATEDPARAMS (_LOGMINER_ALTARCHIVEDLOGDEST path-string)
TRANLOGOPTIONS INTEGRATEDPARAMS (_LOGMINER_ALTARCHIVEDLOGFORMAT format-string)
————————————————
如何防止归档被删除
OGG 11.1开始可以通过将经典抽取进程注册到数据库，可以防止rman删除ogg所需的归档。步骤如下：
1、停止抽取进程
2、执行以下注册命令：
GGSCI> dblogin userid <username>, password <password>
GGSCI> register extract <Extract-name>, LOGRETENTION
3、确认抽取进程参数中没有配置TRANLOGOPTIONS LOGRETENTION DISABLED
4、启动抽取进程
5、检查抽取进程是否已注册成功
SELECT capture_name, status, captured_scn, applied_scn, capture_type,REQUIRED_CHECKPOINT_SCN,SOURCE_RESETLOGS_SCN from dba_capture;
The extract would show up in dba_capture and status would be disabled (if classic & using logretention) and enabled (if IE). The rman integration is default in IE.
————————————————
参照MOS文件Oracle "Capture" and the RMAN-08137 WARNING (文档 ID 1581365.1)的说明：
■The required SCN is determined by first querying V$DATABASE.MIN_REQUIRED_CAPTURE_CHANGE#.
■If MIN_REQUIRED_CAPTURE_CHANGE# is null, then DBA_CAPTURE.REQUIRED_CHECKPOINT_SCN is queried. RMAN will then compare V$ARCHIVED_LOG.NEXT_CHANGE# to the required SCN it found.
■ If there are no records in DBA_CAPTURE, then the database does not have any Capture processes defined.
■ If there are no records in DBA_CAPTURE, and MIN_REQUIRED_CAPTURE_CHANGE# is null, but RMAN is still reporting this particular RMAN-08137 warning, then the problem is with the Standby Database setup, because there is no Oracle Capture.
抽取进程所需的归档同时受V$DATABASE.MIN_REQUIRED_CAPTURE_CHANGE#和DBA_CAPTURE.REQUIRED_CHECKPOINT_SCN影响。
21:23:43 sys@ORCL11G > select to_char(MIN_REQUIRED_CAPTURE_CHANGE#,'999999999999999') from v$database;
TO_CHAR(MIN_REQU
----------------
4993855
Elapsed: 00:00:00.01
21:23:56 sys@ORCL11G > select name, thread#, sequence#, status, first_time, next_time,
21:24:27 2 first_change#, next_change#
21:24:27 3 from v$archived_log
21:24:27 4 where (select MIN_REQUIRED_CAPTURE_CHANGE# from v$database) between first_change# and next_change#;
NAME THREAD# SEQUENCE# STATUS FIRST_TIME NEXT_TIME FIRST_CHANGE# NEXT_CHANGE#
-------------------------------------- -------- ----------- ---------- ------------------- ------------------- -------------------- --------------------
/u01/arch/orcl11g/1_582_991987504.dbf 1 582 A 2017-04-09 20:22:27 2017-04-09 21:10:58 4990649 4993929
V$DATABASE.MIN_REQUIRED_CAPTURE_CHANGE#是由于抽取进程去负责更新的，默认是每6小时一次。可以通过参数TRANLOGOPTIONS INTEGRATEDPARAMS(_CKPT_RETENTION_CHECK_FREQ XXX)去指定。
通过重启下抽取进程也可以触发
————————————————
如何减少对归档的依赖
使用Integrated Extract 或者classic Extract +LOGRETENTION，可以防止归档被rman误删除。但是如果数据库有未提交的长事务，还是不得不保留这些归档。
从OGG 11.1开始OGG提供了BR特性，将超过BR周期（4小时）未提交的事务抽取出来缓存到内存和磁盘中。
抽取进程工作时会执行：
抽取进程在redo遇到事务开始时，它开始缓存该事务所有数据到内存中，即使它不是我们要抽取的表，因为该事务的未来操作可能包含要捕获的表数据。
当抽取进程遇到事务提交时，它将整个事务的内存缓存写到trail文件，并从内存中清除它。
当抽取进程遇到事务回滚时，它将从内存中丢弃整个事务。
如果抽取进程在遇到事务的提交或回滚前停止，则当抽取进程启动后要重新提取所有未完成事务信息，必须恢复缓存的信息。
抽取进程启动时会执行：
如果在Extract停止时没有打开的事务，则恢复将从当前提取读取检查点。这是正常恢复。
如果有未完成的事务，并且事务的起点在时间上非常接近到Extract停止的时间为止，Extract通过重新读取redo /归档日志开始恢复。这需要抽取进程对在停止前已经写入trail或丢弃的事务的做重复工作， 但鉴于只有少量数据要处理, 这也是可以接受的
如果有一个或多个事务符合long-running open事务，Extract会从 Bounded Recovery 恢复。
如果事务超过一个Bounded Recovery interval未提交，则会被认为是long-running open事务。由BR参数的BRINTERVAL选项指定（默认4小时），每4小时做一次BR检查点，默认保存在OGG安装目录的BR目录下（由于BRDIR指定）
在每个检查点的时间点上，OGG会检查长事务，并将超过4小时的长事务的状态和数据写入到磁盘（如果没有达到4小时，则此事务不会被BR写入）。
BR的工作原理（简单画个图）：
在br checkpoit n 时，假设有t(27)、t(45)、t(801)、t(950)、t(1024) 五个未提交事务，超过4小时的t(27)、t(45)会被br checkpoit n缓存到磁盘
在br checkpoit n+1时，假设t(27)、t(950)、t(1024) 三个事务提交了， t(45)还是未提交，又发生新的变化，会被br checkpoit n+1再次缓存到磁盘，再删除br checkpoit n时的缓存文件，如果t(45)没有变化是不会更新缓存文件的。 t(801)是最旧的未提交事务，正常会在br checkpoit n+1做缓存，但如果此时抽取进程停止或崩溃，则t(801)最多需要8个小时的日志来恢复。
因此extract运行时一般需要的归档日志不超过8个小时（极限情况）。当然如果extract停掉后，便无法再自动缓存长事件，需要的归档日志就会依赖于停机时间变长。
BR checkpoit默认就是4小时一次，并保存在OGG_HOME的BR目录下。可以参数手动指定，注意brdir不能使用"temp" or "tmp"字样。
BR , BRDIR /ogg/oggbrdir,BRINTERVAL 20M
还可以通过手工执行BR检查点，减少恢复所需要使用的归档个数。
SEND EXTRACT XXX BR BRCHECKPOINT IMMEDIATE
————————————————