本番環境では、DDLの実行時間が長く、実行プロセスが不透明であることがよく見られます。この問題を解決するため、OceanBaseデータベースV4.1ではDDLのリアルタイム実行進捗監視機能が導入され、DDL実行進捗情報がGV$SESSION_LONGOPSビューに表示されるようになりました。詳細については、GV$SESSION_LONGOPSを参照してください。
本記事では、DDL実行プロセスの監視方法と一般的な問題の診断方法について説明します。本記事では、インデックス作成、主キー追加、列削除という3つの典型的なシナリオを通じてGV$SESSION_LONGOPSの監視機能を説明します。インデックス作成は単独のDDLタスクであり、主キー追加は親子関係を持つDDLタスクであり、列削除も同様に親子関係を持ちますが、ソート以外の方法でデータ補完を行います。
監視プロセスでは、2つのセッションを作成する必要があります。1つはDDL操作を実行するために、もう1つはGV$SESSION_LONGOPSビューを照会するために使用します。どちらのセッションも通常のテナントアカウントでシステムにログインします。
次のステートメントを使用してGV$SESSION_LONGOPSビューのフィールドを確認できます：
SELECT * FROM oceanbase.gv$session_longops\G
インデックス作成の監視
インデックス作成操作は、主にインデックスデータの補完段階で時間がかかります。特定の環境下では、インデックス作成プロセスが同時実行トランザクションの影響を受ける可能性があります。以下では、トランザクション終了待機段階とデータ補完段階の進捗状況の監視について説明します。
トランザクション終了待機段階
*************************** 1. row ***************************
SID: -1
TRACE_ID: YE5186458A15C-0005EF63AE10FBBB-0-0
OPNAME: create index
TARGET: __idx_500005_i1
SVR_IP: xxx.xx.xxx.xx
SVR_PORT: 58648
START_TIME: 2022-12-09
ELAPSED_SECONDS: 7
TIME_REMAINING: 0
LAST_UPDATE_TIME: 2022-12-09
MESSAGE: TENANT_ID: 1004, TASK_ID: 2, STATUS: WAIT TRANS END, PENDING_TX_ID: 76
トランザクション終了待機段階では、MESSAGEフィールドにWAIT TRANS ENDのステータスが表示され、最初の未終了トランザクションのID（例：PENDING_TX_ID: 76）も表示されます。詳細なトランザクション情報は、__all_virtual_trans_statテーブルの対応するtrans_idを照会することで取得できます。
トランザクション補完段階
*************************** 1. row ***************************
SID: -1
TRACE_ID: YE5186458A15C-0005EF60F182F228-0-0
OPNAME: create index
TARGET: __idx_500008_i1
SVR_IP: xxx.xx.xxx.xx
SVR_PORT: 58648
START_TIME: 2022-12-09
ELAPSED_SECONDS: 38
TIME_REMAINING: 0
LAST_UPDATE_TIME: 2022-12-09
MESSAGE: TENANT_ID: 1004, TASK_ID: 6, STATUS: REPLICA BUILD, ROW_SCANNED: 10000000, ROW_SORTED: 19771966, ROW_INSERTED: 0
データ補完段階では、MESSAGEフィールドに以下の重要な情報が含まれます：
- TENANT_ID: テナント識別子
- TASK_ID: DDLタスク識別子
- STATUS: 現在の実行ステータス。
REPLICA BUILDはデータ補完段階にあることを示します - ROW_SCANNED: プライマリテーブルのデータ行数
- ROWSORTED: ソート処理された行数
- ROW_INSERTED: インデックステーブルに書き込まれた行数
ソート処理には複数回のマージ操作が含まれる場合があるため、ROW_SORTED値は通常ROW_SCANNEDおよびROW_INSERTEDよりも大きくなります。
カラムストアバージョンの特性
カラムストアバージョンが導入された後、データ補完の監視に変更が生じました。システムはカラムストアテーブルと行ストアテーブルを区別し、カラムストアバージョン以前のテーブルおよび行と列の混合ストアテーブルはすべて行ストアテーブルと見なされます。
データ補完プロセスの違い：
- 行ストアテーブル：データは一時ファイルに書き込まれた後、直接マクロブロックに書き込まれます
- カラムストアテーブル：データは一時ファイルに書き込まれた後、さらにカラムストアSSテーブルに書き込まれます。総行数はcolumn_group_cnt * row_countです
データ補完段階のMESSAGE情報の例：
- 行ストアテーブル：
TENANT_ID: 1004, TASK_ID: 4514, STATUS: REPLICA BUILD, ROW_SCANNED: 779, ROW_SORTED: 0, ROW_INSERTED: 0 - カラムストアテーブル：
TENANT_ID: 1004, TASK_ID: 6064, STATUS: REPLICA BUILD, ROW_SCANNED: 100000, ROW_SORTED: 200000, ROW_INSERTED_TMP_FILE: 100000, ROW_INSERTED_SSTABLE: 500000 out of 500000 done
主キーの追加の監視
主キーの追加操作はインデックス構築とは異なり、主キーを追加するデータ補完段階で、GV$SESSION_LONGOPS に2つのレコードが表示されます。1つのレコードは主表上のインデックス補完を示し、もう1つのレコードは主表自体の変更を示します。各フィールドの意味はインデックス構築プロセスと同様です。
*************************** 1. row ***************************
SID: -1
TRACE_ID: YE5186458A15C-0005EF60F182F22F-0-0
OPNAME: create index
TARGET: __idx_500030_i1
SVR_IP: xxx.xx.xxx.xx
SVR_PORT: 58648
START_TIME: 2022-12-09
ELAPSED_SECONDS: 6
TIME_REMAINING: 0
LAST_UPDATE_TIME: 2022-12-09
MESSAGE: TENANT_ID: 1004, TASK_ID: 8, STATUS: REPLICA BUILD, ROW_SCANNED: 5518389, ROW_SORTED: 0, ROW_INSERTED: 0
*************************** 2. row ***************************
SID: -1
TRACE_ID: YE5186458A15C-0005EF60F182F22F-0-0
OPNAME: add primary key
TARGET: t1
SVR_IP: xxx.xx.xxx.xx
SVR_PORT: 58648
START_TIME: 2022-12-09
ELAPSED_SECONDS: 63
TIME_REMAINING: 0
LAST_UPDATE_TIME: 2022-12-09
MESSAGE: TENANT_ID: 1004, TASK_ID: 7, STATUS: COPY DEPENDENT OBJECTS, CHILD TASK IDS: [ 8 ]
列の削除を監視する
*************************** 1. row ***************************
SID: -1
TRACE_ID: YE5186458A15C-0005EF60F182F240-0-0
OPNAME: drop column
TARGET: t1
SVR_IP: xxx.xx.xxx.xx
SVR_PORT: 58648
START_TIME: 2022-12-09
ELAPSED_SECONDS: 26
TIME_REMAINING: 0
LAST_UPDATE_TIME: 2022-12-09
MESSAGE: TENANT_ID: 1004, TASK_ID: 13, STATUS: COPY DEPENDENT OBJECTS, CHILD TASK IDS: [ 14 ]
*************************** 2. row ***************************
SID: -1
TRACE_ID: YE5186458A15C-0005EF60F182F240-0-0
OPNAME: create index
TARGET: __idx_500076_i1
SVR_IP: xxx.xx.xxx.xx
SVR_PORT: 58648
START_TIME: 2022-12-09
ELAPSED_SECONDS: 8
TIME_REMAINING: 0
LAST_UPDATE_TIME: 2022-12-09
MESSAGE: TENANT_ID: 1004, TASK_ID: 14, STATUS: REPLICA BUILD, ROW_SCANNED: 10000000, ROW_SORTED: 213098, ROW_INSERTED: 0
列の削除操作におけるデータ補完はソート段階には関与しないため、MESSAGE フィールドには ROW_SCANNED と ROW_INSERTED の情報のみが含まれます。同様の操作には、中間位置に非生成列を追加することも含まれます。