マテリアライズドビューの異常診断

OceanBaseデータベースのマテリアライズドビュー（Materialized View、MV）は、増分更新の遅延やカクつきにより、データとベーステーブルが同期しなくなる可能性があります。

本記事では、診断プロセスと主要なシステムビューを提供し、異常の迅速な特定と解決を支援します。

異常シナリオとモニタリング指標

異常シナリオ

マテリアライズドビューの増分更新は、以下の理由により遅延または停止する可能性があります：

• データ量の急増：ベーステーブルの更新量が予想を大幅に上回る場合。
• リフレッシュタスクのブロック：SQL実行性能の問題やリソース競合。
• スケジュールタスクの失敗：例えば、DBMS_SCHEDULER のスケジューリング異常。

主要なモニタリング指標

システムビュー DBA_MVIEWS の以下のフィールドを使用して、MVデータの状態を監視します：

• data_sync_delay：マテリアライズドビューのデータ同期遅延。単位は秒です。

  アラート条件のトリガー：data_sync_delay が業務で設定されたしきい値を超えた場合、直ちに診断する必要があります。

• data_sync_scn：マテリアライズドビューのデータポイント。

  説明

  OceanBaseデータベースV4.3.5では、システムビューDBA_MVIEWSはV4.3.5 BP2バージョンからdata_sync_delayとdata_sync_scnフィールドが導入されました。

マテリアライズドビュー関連のシステムビュー

マテリアライズドビューの異常診断プロセス

ステップ1：アラートの対象となるMVがネストされたマテリアライズドビューであるかどうかを判断する

• ネストされたマテリアライズドビューである場合、依存関係に沿って問題が発生した最も下層のMVを特定し、それをターゲットMVとします。その後、ステップ2へ進みます。

• ネストされたマテリアライズドビューでない場合、そのMVがターゲットMVとなります。その後、ステップ2へ進みます。

サンプルクエリ：

SELECT * FROM oceanbase.DBA_MVIEW_DEPS;

ステップ2：現在、ターゲットMVのリフレッシュタスクが存在するかどうかを確認する

1. 実行中のタスクを照会します。

   サンプルクエリ：

   指定されたMVの実行タスクを検索します。

   SELECT * FROM oceanbase.DBA_MVIEW_RUNNING_JOBS
   WHERE table_name LIKE '%MVIEW%';
   

2. 状態を判断します：

   • リフレッシュタスクが存在する場合、今回のMVリフレッシュに時間がかかりすぎて完了しないため、data_sync_scnが適時に更新されず、具体的な原因を特定する必要があります。その後、ステップ4へ進みます。

   • リフレッシュタスクが存在しない場合、プログラムのBUGが発生している可能性があります。その後、ステップ3へ進みます。

ステップ3：タスクのスケジューリング障害のトラブルシューティングを行う

DBMS_SCHEDULERのスケジューリングに失敗した場合（例えば、連続16回の失敗後にタスクがキャンセルされた場合）：

1. スケジューリング履歴を確認し、問題を特定します。

   サンプルクエリ：

   SELECT * FROM oceanbase.DBA_SCHEDULER_JOBS;
   

   DBA_SCHEDULER_JOB_RUN_DETAILSに5019の失敗記録が16回存在するかどうかを照会できます。参照文は以下のとおりです：

   SELECT OWNER, JOB_NAME, count(*) > 16 FROM oceanbase.DBA_SCHEDULER_JOB_RUN_DETAILS WHERE CODE = '-5019';
   

2. バージョンアップグレード：既知のBugによって問題が引き起こされている場合は、最新バージョンにアップグレードして修正します。

ステップ4：ベーステーブルに過去の平均を上回る更新操作が発生したかどうかを判断する

1. 変更データ量が大幅に増加した場合、リフレッシュ時間もそれに応じて長くなり、この場合MVデータの遅延は予想通りである可能性があります。変更量の増加が業務上の偶発的なジッターである場合は、誤報を避けるためにdata_sync_delayのしきい値を適切に引き上げることができます。変更量が引き続き増加する場合は、マテリアライズドビューのリフレッシュサイクルの調整、マテリアライズドビューのリフレッシュ並列度の引き上げ、マシンリソースの追加などの方法で問題を解決する必要があります。

2. 変更データ量に明らかな増加がなく、リフレッシュ時間の増加が予想に反している場合：

   1. 今回のリフレッシュ操作が終了した場合、または以前のリフレッシュタスクに類似の動作があった場合は、DBA_MVREF_STATSなどのビューを照会して終了したタスクの情報を分析します。その後、ステップ5へ進みます。
   2. ビューから情報が提供されない場合は、技術サポートに連絡してさらに調査することができます。その後、ステップ6へ進みます。

ステップ5：リアルタイムカクつきタスクの診断

1. フレッシュ時間が異常に長いマテリアライズドビューの、直近数回分のフレッシュ状況の概要を照会します。

   SELECT *
   FROM oceanbase.DBA_MVREF_RUN_STATS run_stats, oceanbase.DBA_MVREF_STATS stats
   WHERE run_stats.refresh_id = stats.refresh_id
   AND run_stats.MVIEWS LIKE '%mv1%'
   ORDER BY run_stats.start_time DESC
   LIMIT 10;
   

   以下の情報に特に注意してください：

   フィールド	意味	説明
   REFRESH_ID	今回のリフレッシュ操作の識別子。
   ELAPSED_TIME	今回のリフレッシュ操作にかかった総時間（単位：秒）。
   REFRESH_METHOD	リフレッシュ方式。	リフレッシュ方法が正しいか、誤って完全リフレッシュが行われていないかを確認する。
   PARALLELISM	リフレッシュの並列度。	並列度が小さすぎないかを確認する。
   LOG_PURGE_TIME	今回のリフレッシュでMLOGのクリーンアップに費やした時間。	Purgeに多くの時間が費やされていないかを確認する。
   INITIAL_NUM_ROWS	このマテリアライズドビューのリフレッシュ前の行数。
   FINAL_NUM_ROWS	このマテリアライズドビューのリフレッシュ後の行数。	行数の変化が大きすぎないかを確認する。

2. 上記の結果から、異常なフレッシュ操作の REFRESH_ID を見つけ出し、さらにその詳細を確認します。

   SELECT *
   FROM oceanbase.DBA_MVREF_CHANGE_STATS
   WHERE refresh_id = xxx;
   

   oceanbase.DBA_MVREF_CHANGE_STATS ビューを照会することで、ベーステーブルのデータ変更状況を確認します。新規挿入、更新、削除された行数が以前より増加している場合、フレッシュ時間が長くなるのは予想通りです。マテリアライズドビュー関連のベーステーブルのデータ変更状況を照会する際、以下の情報に特に注意してください：

   フィールド	意味
   REFRESH_ID	今回のリフレッシュ操作の識別子。
   TBL_NAME	ベーステーブルの名前。
   NUM_ROWS_INS	ベーステーブルにおいて、前回のリフレッシュ以降に新規挿入された行数。
   NUM_ROWS_UPD	ベーステーブルにおいて、前回のリフレッシュ以降に変更された行数。
   NUM_ROWS_DEL	ベーステーブルにおいて、前回のリフレッシュ以降に削除された行数。
   NUM_ROWS	今回のリフレッシュ時のベーステーブルの総行数。

解決策と最適化の提案

• データ量が急増する場合：

  • リフレッシュの並列度を向上させます。
  • 大規模なベーステーブルを分割するか、MVアーキテクチャを最適化します。

• SQLパフォーマンスに関する問題：

  • ベーステーブルのインデックスまたはMVのクエリステートメントを最適化します。
  • パーティションテーブルを使用して、増分データ処理を高速化します。

• リソース不足：

  サーバーリソース(CPU、メモリ)を増やすか、タスクスケジューリングの時間枠を調整します。

関連ドキュメント

マテリアライズドビューのリフレッシュに関する詳細は、マテリアライズドビューのリフレッシュ(MySQLモード)またはマテリアライズドビューのリフレッシュ(Oracleモード)を参照してください。