event_logに以下のエラーメッセージが出力されています。
event_log:
Error 2022-02-04 17:28:26.236544 5644 844224256 Capture: [SP-OCT01001] Unable to find archivelog with sequence#: SEQNO (thread: THREAD# ). SharePlex was unable to locate the redo/archive log for sequence SEQNO in the database location or under the directory defined by SP_OCT_ARCH_LOC parameter. Restore this archivelog to archive location if missing or set the file's location using SP_OCT_ARCH_LOC. Make sure it is not compressed then restart capture. See 'http://advice.shareplex.com/SP-OCT01001' for additional advice and support. (capturing from o.DataSrc) [module oct]Info 2022-02-04 17:28:26.238907 1474 1825675104 Capture exited with code=1, pid = 5644 (capturing from o.DataSrc )
sp_ctrl> statusBrief Status for srchostProcess State PID Running Since--------------- ------------------------------ -------- --------------------Cop Running 1474 04-Feb-22 16:30:48Capture Stopped: missing archive logRead Running 3763 04-Feb-22 16:55:55Export Running 1476 04-Feb-22 16:30:48Cmd & Ctrl Running 5652 04-Feb-22 17:28:20
REDO ログがラップして、かつCapture がアーカイブログを見つけられないために発生しています。
ocap ログ（VARDIR/log/*_ocap*.log )には 以下のように出力されています。
REDOログがラップしてしまった後でCapture プロセスは Oracle のアーカイブログからレコードを探します。
SELECT ACTID,SEQNO,SCN FROM SPLEX.shareplex_actid; (SPLEXにはセットアップしたSharePlexのDBユーザーに置き換えてください)
どの番号のアーカイブログから必要となるかは 以下のリンク先ドキュメントをご参考ください。
上の情報を元に必要なアーカイブログファイルを探してください。（具体的なファイル名やパスは案内しておりません）日本語説明: Oracle アーカイブログのリストア方法
(v8.6日本語管理者ガイドより)
SharePlex を有効にしてキャプチャおよび複製を再開するためにアーカイブログをリストアする場合は、次の手順を使用して、必要なアーカイブログを特定します。
- そこから処理を再開するために Capture が必要とするシーケンス番号を判断します。Capture はログラップが発生したときに停止して、それが必要な REDO ログのシーケンス番号があるメッセージを Event Log (event_log)に印字します。この番号は、次の例で示されているように、SHAREPLEX_ACTID テーブルをクエリして、SEQNO 列を調べることでも見つけることができます。
SQL> select * from splex.shareplex_actid;
ACTID SEQNO OFFSET AB_FLAG QUE_SEQ_NO_1 QUE_SEQ_NO_2 COMMAND
----- ------ -------- -------- ------------- -------------- ------------
14 114 9757200 0 672101000 0- Oracle の V$LOG_HISTORY テーブルをクエリして、そのシーケンス番号がアーカイブされたときを見つけて、その時点から先のログをソースシステムにコピーします。
SQL> select * from V$LOG_HISTORY;
RECID STAMP THREAD# SEQUENCE# FIRST_CHANGE# FIRST_TIM NEXT_CHANGE#
----- ------ -------- -------- ------------- --------------
111 402941650 1 111 2729501 14-JUL-00 2729548
112 402941737 1 112 2729548 14-JUL-00 2729633
113 402941930 1 113 2729633 14-JUL-00 2781791
114 402942019 1 114 2781791 14-JUL-00 2836155
115 402942106 1 115 2836155 14-JUL-00 2890539
...
アーカイブログが元の場所に配置、あるいは元の場所から移動されている場合は SP_OCT_ARCH_LOC パラメータにて、アーカイブログが存在するディレクトリの完全パス名を設定の上、改善するかどうかをお試しください。
これらの作業はソース側で実施します。
パラメータを設定
sp_ctrl> set param SP_OCT_ARCH_LOC /disk1/log;/disk2/log
Windows システムで P:\splocalloc\arc\の下にアーカイブログを配置する例:
sp_ctrl> set param SP_OCT_ARCH_LOC P:\\splocalloc\\arc
または
sp_ctrl> set param SP_OCT_ARCH_LOC P:/splocalloc/arc
起動します。
sp_ctrl> start capture
典型的なシナリオとしてはConfigが有効なまま ソースの CaptureプロセスまたはSharePlexインスタンスを停止した後も、Oracleが動作を継続しアーカイブログを（バックアップなどで）既定の出力先から移動してしまった後でSharePlexの複製が再開したような場合です。
探していたアーカイブログファイルが失われている場合（完全に無い）、同期を継続できませんので、SharePlexについては ora_cleansp をソースとターゲットで実行の上、再アクティベート および再同期を実施いただけますようお願いいたします。
同様に対処してください。
1. ソースでcop停止
2. ターゲットでcop停止
3. ソースで ora_cleansp を実施
4. ターゲットでora_cleansp 実施
5. ソースでcop起動
6. ターゲットでcop起動
7. ソースでconfigを再アクティベート （3.ソースでora_cleansp にて有効だったコンフィグが無効化されています）
8. ソースで必要なテーブルをrepair
Oracle側でアーカイブログモードが有効でなかった場合、SharePlex は読み取るべきアーカイブログがログラップにより消失したデータを複製はしません。Captureの動作としてはアーカイブログの読み込みをスキップして継続します。
