停止OGG e进程时遭遇长事务分析
日常在进行数据库维护时经常要停止ogg进程，有时会遇到提示当前有一个长时间执行的事务存在的错误，OGG提示可使用 SEND EXTRACT EHXZG001, FORCESTOP命令强制停止进程。然后最后重启该进程需要读取的是20939和12852两个redo日志。
GGSCI (gdlt2hxzgdb02) 21> stop *
Sending STOP request to EXTRACT EHXZG001 ...
There are open, long-running transactions. Before you stop Extract, make the archives containing data for those transactions available for when Extract restarts. To force Extract to stop, use the SEND EXTRACT EHXZG001, FORCESTOP command.
Oldest redo log files necessary to restart Extract are:
Redo Thread 1, Redo Log Sequence Number 20939, SCN 3340.2050804863 (14347241573503), RBA 47790608
Redo Thread 2, Redo Log Sequence Number 12852, SCN 3340.2057322291 (14347248090931), RBA 4788752.
关键点分析：
1.当数据库中一个事务发起时，OGG的e进程将捕捉该事务，进而扫描相关的redo 日志或archive 日志。
2.当数据库中一个事务较长未提交或回滚时，OGG将事务keep在内存中，因此同样保持该事务而不提交或中断。
3.当需要停止OGG e进程时，便会提示事务正在执行。
OGG事务处理延伸分析：
1.OGG的抽取进程会实时捕捉事务，但投递到目标端时，如果该事务未做提交，复制进程是不会将其写入到目标数据库中的，这样避免了不一致性。
2.OGG有个Bounded Recovery机制，会每隔一段时间做一个检查，如果检测到长事务，OGG会将时间段内这个未提交或回滚的长事务从内存中保存到磁盘上，往后每隔一段时间同样做一次检查。以上这个时间段是可以通过参数自定义的 BR BRINTERVAL 2H 。(两个小时)。
3.Bounded Recovery机制在你强制停止抽取进程后重启时，可以不必一整个事务都从数据库的日志中读取，而已在检查点内保存的事务过程可以通过OGG 自己保存的BR文件读取。
4.一个长事务中未受Bounded Recovery检测保存的过程，OGG通过记录检查点去归档中读取。