RAC構成でOracle GoldenGateを使う
DB間のリアルタイムデータ同期を実現するGoldenGateをRACで使用する時に、とあるリスクが生じる。
GoldenGateではソースDBとターゲットDB間でトレイルと呼ばれる、データ変更情報が書き込まれた証跡ファイルをやり取りするわけだが、ソース側DBがRAC構成（active-active）になっている場合、REDOログ・アーカイブログがインスタンスごとに存在していることで特殊な状況に陥ることがある。
インスタンスが一つの場合、SCN（System Change Number）順に行儀良くREDOログに入っていき、GoldenGateは順番通りに読み込んでくれる。
それがRAC構成だと、インスタンスごとに投入されるので、GoldenGateが読み込む順番がちぐはぐになる可能性がある
つまり、
GoldenGate（というかCaptureプロセス）がトレイルに書き出すため
のようなこと（後からより古い更新履歴を読み込んでしまう）が起こりうる
エラーメッセージとしては以下のような感じ
（読み込んだSCNが既に読み込んだSCNより古いぞ、と言っている）
encountered commit SCN<n.xxx> that is not greater than the highest SCN already processed
ちなみにこれ完全に防ぐ手立てはないらしく、REDOログからトレイルに書き出す時間に余裕（待機時間）を持たせることで、起こりにくくすることはできる。
threadoptions MAXCOMMITPROPAGATIONDELAY xxxxx IOLATENCY xxxxx
MAXCOMMITPROPAGATIONDELAY ・・・
oracleがREDOに書き込みを行った時間とGG（Capture）がREDO を読み込む時間のラグを許容する時間を設定できる
IOLATENCY ・・・
I/Oに関する許容する遅延時間を設定できる
上記二つを合わせた時間分、CaptureがREDOを読み込みに行くのを待機する。
そうすることで、なるべくCaptureプロセスは順序通りにREDOを読み込み・トレイルに出力することが可能になるので事象が起こりにくくすることが可能になる。
ただ、あくまで起こりにくくするだけでRAC構成、かつ両系が稼働系の場合は発生しうる事象になるため、本当に回避したい場合はDBの稼働系・待機系を明示的にして運用するしかなさそうだ。
