この記事ではSharePlexプロセスが Stopped - disk is full を理由に停止している場合の確認点・対処方針を説明します。
VARDIRの空きが枯渇することによるプロセスの停止・再開は以下のパラメータに依存します。
SharePlex 11.4 - リファレンス・ガイド : Systemパラメーター
SP_SYS_VAR_FULL
| 説明 | このパラメーターは、SharePlex変数データディレクトリがインストールされているディスクの使用可能な領域のしきい値を設定します。 これにより、キューが使用可能なディスク容量を超えないようにできます。Capture、Read、Importで処理中の操作によって、使用可能なディスク容量がこのパラメーターに設定された値を下回ると、プロセスが停止します。使用可能なディスク容量がSP_SYS_VAR_OKパラメーターで設定されたしきい値に達すると、処理が再開されます。 |
| デフォルト | 30 (MB) |
| 有効な値の範囲 | SP_SYS_VAR_OKの値より大きい任意の正の整数 （MB） |
| 有効になるタイミング | 即時 |
SP_SYS_VAR_OK
| 説明 | このパラメーターは、SP_SYS_VAR_FULLの値に達したために停止したCapture、Read 、またはImportの処理を再開できる使用可能なディスク容量を設定します。 |
| デフォルト | 50 (MB) |
| 有効な値の範囲 | 任意の正の整数 (MB) |
| 有効になるタイミング | 即時 |
SharePlexのCapture（ソース側）, Read（ソース側）および Import（ターゲット側）プロセスは
VARDIRのパス( SP_SYS_VARDIRが指定するパス )のあるボリュームの空きの枯渇※を検知すると停止します。
この時、ソースおよびターゲットでsp_ctrl status結果から停止したプロセスと 停止理由として'Stopped - disk is full' を確認できます。
※ 空きがSP_SYS_VAR_FULL（デフォルト30MB ）を下回る場合。
sp_ctrl> status
SharePlexはソースデータベースの変更を読み取り以下のフローでキューメッセージをターゲットのデータベースへ投入する事で複製を行います。
ソース:
Capture(データベースから変更を読みだしてメッセージとしてCaptureキューに書き込む)
↓
[Captureキュー]
↓
Reader（メッセージ加工してExportキューに書き込む）
↓
[Exportキュー]
↓
Export （ターゲットへ転送）
||
ノード間
||
ターゲット:
Import (メッセージ受信してPostキューに書き込む)
↓
[Postキュー]
↓
Post （ターゲットDBへ投入(post)する）
この内、Capture/Reader/Import は次（下方向）のキューにデータを送りソースおよびターゲット自身のローカルのキュー（VARDIR内のデータ）を増加させる働きをします。
方や、ExportおよびPostは上流から来たメッセージを次の宛先へ送り、ローカルのキューから削除する役割を担います。
キューメッセージをローカルのキューから削除できない状況（ExportがターゲットのImportに送信できない、PostがデータベースへSQLを投入できない）が続いて、ローカルの空き容量が一定値を下回った場合、SharePlexはデータ破損を防ぐためにローカルでデータを増加させうるプロセスCapture/Reader/Importを 'Stopped - disk is full' として停止します。（ソースとターゲットでそれぞれで評価される）
容量の問題が解消して空きが一定以上※※ に回復すれば停止したプロセスは自動的に再開します。
※※ SP_SYS_VAR_OK（デフォルト50MB ）以上の空き
発生パターンにはいくつかのシナリオが考えられます。
◆ シナリオ1: ソースがターゲットと接続できない
SharePlexソースがターゲットImportへのデータ送信手段できない場合、ソースで生成されるキューメッセージはVARDIRに蓄積されてディスクフルになる可能性があります。
・ターゲットとのネットワーク接続が出来ない状況
・ターゲットSharePlexの停止等
sp_ctrlコマンド
status
qstatus
lstatus
ログ
VARDIR/log/内のログ
◆ シナリオ2: Post（ターゲット）が処理を進められない
Postが何らかの理由で停止した状態で処理をしなくなれば、ターゲットのPostキューにはImportが受信したデータが蓄積し続けてディスクフルになる可能性があります。
sp_ctrlコマンド
status
qstatus
lstatus
ログ
VARDIR/log/内のログ
このシナリオの1つのケースとしては、DDL実行がターゲットで失敗してPostが停止したままの場合です。
DDL失敗の付近のログでは ターゲットの event_log および Postログ(*opo*log) に[SP-OPO01002] Post process stopped due to DDL error と以下のようなメッセージが記録されます。
-----------
<ADVICE>
While Post is stopped, fix the problem so that this error does not occur again. Then, manually execute the correct DDL on the target and restart Post.
(Note: On restart, Post will skip the original DDL that caused the error.)
To configure Post to continue processing after it receives a DDL error, set the SP_OPO_STOP_ON_DDL_ERR parameter to 0 before starting Post.
See for additional advice and support.
-----------
SP-OPO01002日本語訳
<ADVICE> Postが停止された間に問題を修正してエラーが再発しないようにします。そのあとでターゲット上で手動で適切なDDLを実行してPostを再起動します。
（メモ: Postの再起動時、Postはエラーの原因となったDDLをスキップします）
Postがエラーを受けた後でも処理を継続する設定にするには、Postを再起動する前に SP_OPO_STOP_ON_DDL_ERR パラメータを0に設定します。
-----------
SP_OPO_STOP_ON_DDL_ERRの変更設定が適切かどうかはサポートでは判断いたしかねます。
事象発生時のDDLの失敗がどのような状況で生じるのかを検討して対処してください。
参考記事DDL 文でエラーが発生した際にPostプロセスを停止しないようにできますか？ (4325491)
対処有無にかかわらず、このエラーで失敗したDDLのメッセージは次のPost起動時には無視されて次の処理に進みます（スキップされる）。
失敗したのが必要ないDDLの場合、start post をしてしまえばそのまま後続の処理へ進めます。
◆ シナリオ3: シナリオ2に起因してシナリオ1が発生する
副次的ですがシナリオ2の状況（Importプロセスが停止）では接続元であるソース側のExportプロセスがImportとの接続が途切れてExportプロセスがIdleになります。（シナリオ1）
このまま放置するとソースでのCapture/Readが停止することにつながります。
◆ シナリオ4:
SharePlexとは関係なくOSやその他アプリケーションのファイルがVARDIRディレクトリのあるボリュームを圧迫してしまっている
圧迫の原因を取り除いてください。（この場合 SharePlexでは対処できません。）
【対処方針】
ステップ1- ソース、ターゲットそれぞれで*status系の(status,qstatus,lstatus)コマンドを見てどこで止まっているか、バックログメッセージの大きなキューを確認します。
ステップ2- 次に、VARDIRのパスが所属するボリューム（ファイルシステム）を調べて シナリオ4（SharePlex起因以外のファイルシステムフル）の可能性を除外してください。
ステップ3- ネットワーク接続性の問題であればネットワークの問題を解消してください（Firewall設定なども含む）
ステップ4- ターゲットでPostがエラー停止(due to error)している場合、そのpostの再起動を試みて状況が改善するか確認します。
・ターゲットでのqstatus結果からどのキューでバックログが蓄積しているか確認します。（Backlogの数やAgeが大きい）
・event_log および Postログ(*opo*log) から何時ごろどのような処理で失敗して停止したかを確認します。
・DDL失敗で停止しており、後続の処理にとって影響があれば、postのログなどから確認して手動でDDL実行の対処を行います。
・失敗したDDLが後続の処理にとって重要ではない、あるいは 手動で対処済みであれば、Postを起動します
sp_ctrl> start post [queue Postキュー名]
（Postキューの名前はターゲットでのqstatusやlstatusから確認できます。）
sp_ctrl> status
sp_ctrl> qstatus
sp_ctrl> lstatus
ステップ5 - post 再開後、 lstatus結果にてプロセス起動状態（PIDが変わらない）、qstatus結果からバックログが捌けている（数が増減する、Ageが小さくなる）状況が確認できるならば、次第に空きが回復すると考えられます。しばらく様子を見てください。
sp_ctrlコマンド
status
qstatus
lstatus
ログ
VARDIR/log/内のログ
再度Postが停止したりPostのPIDが頻繁に変わったりするようならevent_logおよび*opo*log ログから調査します。
各フェーズでの確認コマンドも含めて情報収集してください。
ターゲットDB側の問題でSharePlexが処理が出来ない状況では、（場合にもよりますが）基本的にターゲットDB側の問題を解消してください。
