停止OGG e进程时遭遇长事务分析

日常在进行数据库维护时经常要停止ogg进程，有时会遇到提示当前有一个长时间执行的事务存在的错误，OGG提示可使用 SEND EXTRACT

日常在进行数据库维护时经常要停止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进程时，便会提示事务正在执行。

措施：
措施1：使用 SEND EXTRACT EHXZG001, FORCESTOP命令强制停止进程，但是，你必须保证重启时包含该事务的日志文件存在并可用，意思就是说ogg进程重启时会再次恢复捕捉该事务，当此时发现相应的日志文件不存在了，，于是OGG便会报错，一般提示找不到归档等，其实强制停止个人建议不在万不得已情况下还是不要做。有一篇文章阐述了过程并做了总结：
措施2：不在OGG层面操作，直接从源端数据库进行回滚或提交，这样虽然需要等待一定时间但相对比较保险。

OGG事务处理延伸分析：
1.OGG的抽取进程会实时捕捉事务，但投递到目标端时，如果该事务未做提交，复制进程是不会将其写入到目标数据库中的，这样避免了不一致性。
2.OGG有个Bounded Recovery机制，会每隔一段时间做一个检查，如果检测到长事务，OGG会将时间段内这个未提交或回滚的长事务从内存中保存到磁盘上，往后每隔一段时间同样做一次检查。以上这个时间段是可以通过参数自定义的 BR BRINTERVAL 2H 。(两个小时)。
3.Bounded Recovery机制在你强制停止抽取进程后重启时，可以不必一整个事务都从数据库的日志中读取，而已在检查点内保存的事务过程可以通过OGG 自己保存的BR文件读取。
4.一个长事务中未受Bounded Recovery检测保存的过程，OGG通过记录检查点去归档中读取。