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

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 に16回の5019エラー記録があるかどうかを照会できます。参照ステートメントは以下のとおりです：

   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モード)を参照してください。