本記事では、3つの基礎実験と3つの分析軸を用い、実際の障害事例と組み合わせて、[G]V$OB_ACTIVE_SESSION_HISTORYビューを活用してCPU使用率の急増、I/Oボトルネック、分散実行のブロッキングなどのパフォーマンス問題を迅速に特定する方法を解説します。
ASHの実装原理
ASHはデータベースの自動ビデオレコーダーのようなもので、毎秒、稼働中のすべてのセッション（SQLを実行しているセッションなど）の状態スナップショットを撮影し、これらのスナップショットはGV$OB_ACTIVE_SESSION_HISTORYというシステムビューに格納されます。具体的な実装原理は以下の通りです：
アクティブセッションフィルタリングメカニズム
データベース内で実行されるすべてのタスクを記録し、ユニークな識別子session_idを付与します。これには以下が含まれます：
- ユーザークライアントがデータベースに接続してSQLリクエストを実行する場合。
- 内部RPCの実行。
- ダンプスレッド、Clogスレッド、タイマースレッドなどのバックグラウンドスレッドによるタスクの実行。
アクティブなセッションの状態のみを記録し、アイドル状態のセッションは記録されません。これには以下が含まれます：
- SQLを実行中のセッションはアクティブと見なされます。あるセッションがSleep状態にあり、SQLリクエストを処理していない場合は、アイドル状態と見なされ、記録されません。
- バックグラウンドスレッドがタスクを実行していない場合、または新しいタスクのスケジューリングを待機している場合は、アイドル状態と見なされ、記録されません。
- リソース（ロック、ディスクI/Oなど）を待機中のセッションについて、ASHはその待機イベント（例：db file data read）をマークします。
周期的サンプリングメカニズム
各OBServer内部には専用のASHスレッドがあり、1秒ごとにデータベース内のすべてのアクティブセッションにアクセスし、その状態を記録します。ここで：
GV$OB_ACTIVE_SESSION_HISTORYの各行のデータは、特定の時点におけるアクティブセッションの状態を表します。- あるセッションの作業時間が非常に短い場合（例：1秒未満）、写真撮影時に瞬いた人のように、ASHに捕捉されない可能性があります。このような場合は、負荷を重複させ、クエリの時間範囲を拡大することで、ASHの統計結果をより信頼性の高いものにすることを推奨します。
リングバッファ設計
ASHスナップショットデータは30MBのリングバッファに保存されます。保存データが30MBを超えると、最も古いデータが自動的に上書きされます。V4.2.5 BP3バージョンでは、上書き前のASHデータを自動的にWRにアーカイブする機能が実装されました。しかし、それ以前のバージョンでは、ASH履歴データが失われる可能性があります。最新のASHレコードを保存したい場合は、手動でWRスナップショットをトリガーできます：
CALL DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();このコマンドを実行すると、現在時刻においてまだWRに永続化されていないASHスナップショットデータが10:1の比率で永続化されます。
ASHのゼロベース実験
ASHの時間軸を遡るための3つのゼロベース実験を用意しました。データベースのASHを使ってみて、その魅力をすぐに感じ取れます。
実験1：直近10秒間のデータベース状態を確認する（リアルタイム監視）
データベースが直近10秒間に何をしていたかを確認します：
-- システム内で直近10秒間の稼働状況を確認する
SELECT
sample_time AS 時間, -- マイクロ秒単位のタイムスタンプ
session_id AS セッションID, -- セッションを一意に識別するID
CASE WHEN session_state = 'ON CPU' THEN '作業中' ELSE '待機中' END AS 状態, -- 作業状態：CPUが忙しくしているかリソースを待機中
event AS 待機理由 -- 具体的な待機イベント（ロック、I/Oなど）
FROM v$ob_active_session_history
WHERE sample_time > now() - 10 -- 直近10秒間
AND session_type="FOREGROUND"
ORDER BY sample_time DESC;
結果は次のとおりです：
+----------------------------+------------+-----------+------------------------+
| 時間 | セッションID | 状態 | 待機理由 |
+----------------------------+------------+-----------+------------------------+
| 2025-06-11 20:16:15.307564 | 3221931170 | 待機中 | px loop condition wait |
| 2025-06-11 20:16:14.285204 | 3221928286 | 作業中 | |
| 2025-06-11 20:16:14.285204 | 3221923503 | 待機中 | wait in request queue |
| 2025-06-11 20:16:14.285204 | 3221923627 | 待機中 | db file data read |
| 2025-06-11 20:16:14.285204 | 3221927472 | 待機中 | sync rpc |
| 2025-06-11 20:16:13.262695 | 3221929034 | 作業中 | |
| 2025-06-11 20:16:12.240768 | 3221927472 | 作業中 | |
+----------------------------+------------+-----------+------------------------+
発見：
- セッション3221931170は、PXの実行完了を待機中（px loop condition wait）
- セッション3221923627は、読み込みI/O完了を待機中（db file data read）
- セッション3221927472は、20:16:12時点ではまだ作業中でしたが、2秒後にはRPCの結果返却を待機中（sync rpc）になりました。
実験2：直近10分間で最もアクティブなセッションを統計する（負荷分散）
直近10分間に忙しかったセッションを確認します：
-- 直近10分間で最もアクティブなセッションを統計する
SELECT
session_id AS セッションID,
COUNT(*) AS 働働秒数
FROM v$ob_active_session_history
WHERE sample_time > now() - 600 -- 過去10分間
AND session_type='FOREGROUND'
GROUP BY session_id
ORDER BY 働働秒数 DESC limit 3;
結果は次のとおりです：
+------------+--------------+
| セッションID | 働働秒数 |
+------------+--------------+
| 3221977564 | 283 |
| 3221972645 | 142 |
| 3221916432 | 77 |
+------------+--------------+
セッション3221977564は過去10分間で283秒間アクティブでした。もし過去の期間にこれら3つのセッションしかなかった場合、セッション3221977564がデータベース全体の負荷に貢献する割合は 283 / (283 + 142 +77)= 56% となります。
実験3：過去の高負荷SQLを特定する（パフォーマンス分析）
過去一定期間において最も忙しかったSQLを確認します：
-- 過去の期間内で、実行負荷が最も高かったsql_idを照会する
SELECT
SQL_ID,
COUNT(*) AS 働働秒数
FROM v$ob_active_session_history
WHERE sample_time BETWEEN
'2025-06-11 10:32:08'
AND '2025-06-11 11:32:07' -- 実際に観察したい期間に変更可能
GROUP BY sql_id
ORDER BY 働働秒数 DESC limit 3;
結果は次のとおりです：
+----------------------------------+--------------+
| SQL_ID | 働働秒数 |
+----------------------------------+--------------+
| 1D0BA376E273B9D622641124D8C59264 | 91265 |
| 19AAD9F2FE3CE0023298AB83F7E75775 | 13608 |
| 7BE7497CCCFE8978AD6B92A938D43929 | 13098 |
+----------------------------------+--------------+
過去一定期間で最も負荷の高かったSQLは1D0BA376E273B9D622641124D8C59264で、実行時間は91,265秒でした。
ASH分析法
V$OB_ACTIVE_SESSION_HISTORYビューは、1秒ごとのフルセッションスナップショットを提供し、事前設定なしで直近7日間の運用状態を遡ることができます。以下の3つの次元は、本記事で重点的に分析するコア指標であり、これらが合わさってデータベースの運用状況を描き出します。
- AAS（Average Active Session）：データベースの1秒あたりの平均セッション数であり、データベースの負荷状況を反映しています。AASが高いほど、負荷が大きいことを意味します。
- 待機イベント（Wait Event）：アクティブセッションがロック、ネットワークRPC、I/Oなどのシステムリソースを待機している場合、待機イベント状態に入ります。これに対して、待機イベント状態にないセッションは作業状態（ON_CPU）にあります。
- 実行段階：SQLがデータベース内で実行される際、IN_PARSE、IN_SQL_OPTIMIZE、IN_SQL_EXECUTION、IN_STORAGE_READなど、さまざまな段階を経ます。また、SQLの実行過程では様々なリソースが動員され、IN_RPC_ENCODE、IN_CONNECTION_MRG、IN_SEQUENCE_LOADなど、さまざまな状態に入ることもあります。
ASH分析法により、歴史的な期間におけるデータベース全体の運用状況を復元することができます。これは、単にモニタリング指標が示す特定のデータベースの微視的な側面だけを見るのとは異なります。これがASHと従来のモニタリングとの最大の違いです。
AAS分析
ASHはデータベースシステム内のアクティブセッションのみを記録する特性に基づき、データベースの1秒あたりのアクティブセッション数を統計できます。アクティブセッション数が多いほど、システムは忙しく、負荷が高いことを意味します。指標AASを用いて1秒あたりの平均セッション数を表し、データベースの秒単位の負荷状況を正確に把握します。
AASは次のようにクエリできます：
SELECT
DATE_FORMAT(SAMPLE_TIME, '%Y-%m-%d %H:%i') AS TIME_SLOT,
-- 1分ごとの区間に分割
COUNT(*) / 60 as AAS
-- 1分あたりの平均アクティブセッション数
FROM V$OB_ACTIVE_SESSION_HISTORY
WHERE sample_time BETWEEN
'2025-03-13 10:32:08'
AND '2025-03-13 10:35:07' -- 実際に観察したい時間帯に変更可能
GROUP BY TIME_slot ORDER BY TIME_SLOT;
結果は次のとおりです：
+------------------+------+
| TIME_SLOT | AAS |
+------------------+------+
| 2025-03-13 10:32 | 2 |
| 2025-03-13 10:33 | 13 |
| 2025-03-13 10:34 | 15 |
| 2025-03-13 10:35 | 1 |
+------------------+------+
クエリ期間内の10:33から10:34にかけて、アクティブセッション数が急増しています。これはユーザーSQLの突発的なトラフィックが原因か、または突然スケジュールされたバックグラウンドタスクが過剰なシステムリソースを消費したためかもしれません。具体的にリソースボトルネックが発生したかどうかは、テナント仕様やシステム状態などの要因を総合的に考慮する必要があります。注意点として、V$OB_ACTIVE_SESSION_HISTORYビューはシステムの最新の一定期間の履歴スナップショットデータのみを保持しているため、クエリを実行する前に、ビュー内の履歴データが上書きされていないか確認する必要があります。
以下では、実際の事例を通じて、問題診断とトラブルシューティングにおいてAASがどのように活用されるかを説明します。
事例1：バックグラウンドタスクによるCPU使用率の急増の特定
あるインターネット企業がOceanBaseデータベースを使用しており、テナントの構成は3c12gでした。データベースは午前8時からCPU使用率が異常に上昇し始めました。ユーザーがOCPのアラートを受信した後、8時14分頃にデータベーステナントの構成を6c20gにアップグレードしましたが、テナントのCPU使用率は依然として100%でした。問題は2時間続いた後に解消され、障害発生中、OCPによるとユーザーのQPSには明らかな変化はありませんでした。
ASHビューをクエリすることで、負荷の急変の原因を特定できます。既にOCP上で障害発生時間帯が特定されているため、障害発生時間帯のAASを直接分析できます。
SELECT
SVR_IP,
SVR_PORT,
SESSION_TYPE,
COUNT(*) as AAS
-- アクティブセッションの総時間を時間で割ってAASを求める
FROM V$OB_ACTIVE_SESSION_HISTORY
WHERE sample_time BETWEEN
'2025-03-13 8:00:00'
AND '2025-03-13 10:00:00'
GROUP BY SVR_IP, SVR_PORT, SESSION_TYPE ORDER BY AAS DESC limit 5;
クエリ結果は次のとおりです：
+--------------+----------+--------------+-------+
| SVR_IP | SVR_PORT | SESSION_TYPE | AAS |
+--------------+----------+--------------+-------+
| xx.xx.xx.x6 | 46775 | BACKGROUND | 59633 |
| xx.xx.xx.x6 | 46775 | FOREGROUND | 1324 |
| xx.xx.xx.x5 | 46779 | FOREGROUND | 512 |
| xx.xx.xx.x9 | 46771 | FOREGROUND | 412 |
| xx.xx.xx.x9 | 46771 | BACKGROUND | 403 |
| xx.xx.xx.x5 | 46779 | BACKGROUND | 379 |
+--------------+----------+--------------+-------+
理解しておく必要があるのは、OceanBaseデータベースは分散データベースであり、通常は複数のノードで構成されているため、ASHをクエリする際には、SVR_IPとSVR_PORTを追加することが最適であるということです。これら2つのフィールドは、OBServerノードを一意に識別できます。 SESSION_TYPEはセッションのタイプを示し、FOREGROUND（フォアグラウンド）とBACKGROUND（バックグラウンド）の2種類しかありません。FOREGROUNDセッションは、ユーザーがOceanBaseデータベースと接続を確立することで生成されるセッションであり、ユーザーから送信されたSQLリクエストを実行するために使用されます。BACKGROUNDセッションは、OceanBaseデータベースの内部タスクを実行し、ダンプ、RPC、PXタスクなどが含まれます。 クエリ結果から容易にわかるように、負荷は主にxx.xx.xx.x6:46775ノードに集中しており、そのAAS=59633/(3600 * 2) = 8.28は、テナント仕様の3CPUを大幅に上回っています。拡張後の6CPUでも、バックグラウンドセッションの要求を満たすのは難しいでしょう。 次に、xx.xx.xx.x6:46775ノード上で、具体的にどのバックグラウンドタスクがテナントのCPUをこれほど消費しているのかを調査する必要があります。ASHでは、バックグラウンドセッションの属性を示すフィールドが多数存在しますが、一般的に使用されるのはPROGRAMやGROUP_IDなどです。PROGRAMはセッションの属性を示し、GROUP_IDはセッションがどのリソースグループに属しているかを示します。したがって、以下のSQLを構築します：
SELECT
PROGRAM,
GROUP_ID,
COUNT(*) as CNT
FROM V$OB_ACTIVE_SESSION_HISTORY
WHERE SESSION_TYPE = 'BACKGROUND'
AND SVR_IP = 'xx.xx.xx.x6'
AND SVR_PORT = '46775'
AND sample_time BETWEEN
'2025-03-13 8:00:00'
AND '2025-03-13 10:00:00'
GROUP BY PROGRAM, SESSION_TYPE ORDER BY CNT DESC limit 10;
クエリ結果は次のとおりです：
+-------------------------+----------+-------+
| PROGRAM | GROUP_ID | CNT |
+-------------------------+----------+-------+
| T1002_RPC_REQUEST | 28 | 53278 |
| T1002_LogService | 0 | 2793 |
| T1002_DAG | 0 | 1425 |
| T1002_IOManager | 0 | 1268 |
| T1002_LSRecoveryService | 0 | 438 |
+-------------------------+----------+-------+
クエリの結果、xx.xx.xx.x6:46775ノード上の主要なバックグラウンド負荷はRPC実行に起因しており、そのリソースグループは28であることが判明しました。28リソースグループはOBServer内部タスク専用のリソースグループであり、DBMS_SCHEDULERモジュールに割り当てられています。これにより、障害発生時のデータベースの現場状況を復元しました：何らかの原因でDBMS_SCHEDULERモジュールがxx.xx.xx.x6:46775ノードに大量のRPCリクエストを送信したため、OBServerノードのCPU使用率が急激に上昇しました。その後の調査で、DBMS_SCHEDULERが午前8時にSQL統計情報収集タスクを実行した際、設定ミスによりすべての統計情報収集タスクが同一ノードにスケジュールされ、CPU使用率が急増したことが確認されました。 従来の手法でこの問題を調査するには時間がかかり、監視情報がそれ以上提供されないため、OBServerの実行ログから分析を始め、ログの異常に基づいてDBMS_SCHEDULERモジュールへと徐々に推測していく必要がありました。一方、ASHはDBMS_SCHEDULERモジュール専用の監視設定は備えていませんが、AASの観点とバックグラウンド属性を組み合わせることで、障害原因をスムーズに特定することができました。
待機イベントの分析
データベースの任意のアクティブセッションは、実行過程で待機状態にあるか、ON CPUの作業状態にあるかのどちらかです。待機状態とは、特定のリソースが利用可能になるか、特定の条件が満たされるのを待って実行を続ける状態です。ON CPUの作業状態とは、SQL文の解析、SQL演算子の処理、メモリアクセスの完了を待つなどの処理を指します。OceanBaseデータベースでは、待機イベント（wait event）を使用して、アクティブセッションが待機状態にあることを示します。明らかに、データベースセッションの実行過程で発生した待機イベントとその時間比率を特定することは、データベースチューニングにおいて極めて重要です。
SQLを使用して、特定の期間内のフォアグラウンドセッションの待機イベントの割合を照会できます：
SELECT
SESSION_STATE,
EVENT,
COUNT(*) as CNT
FROM V$OB_ACTIVE_SESSION_HISTORY
WHERE SESSION_TYPE = 'FOREGROUND'
AND SVR_IP = 'xx.xx.xx.x7'
AND SVR_PORT = '2828'
AND sample_time BETWEEN
'2025-06-14 8:15:00'
AND '2025-06-14 10:31:00'
GROUP BY SESSION_STATE, EVENT ORDER BY CNT DESC limit 10;
クエリ結果は次のとおりです：
+---------------+--------------------------------------------------------+--------+
| SESSION_STATE | EVENT | CNT |
+---------------+--------------------------------------------------------+--------+
| WAITING | wait in request queue | 227184 |
| ON CPU | | 76111 |
| WAITING | tx commiting wait | 54866 |
| WAITING | exec inner sql wait | 10292 |
| WAITING | sync rpc | 6602 |
| WAITING | px loop condition wait | 3234 |
| WAITING | db file data read | 395 |
| WAITING | row lock wait | 158 |
| WAITING | default condition wait | 143 |
+---------------+--------------------------------------------------------+--------+
クエリ期間中、テナントキューの積み上がり（wait in request queue）が非常に深刻であり、SQL実行時間に大きな影響を与えていたことがわかります。
事例2：ディスクI/Oボトルネックの特定
ある教育会社で、ある日の午後にデータベースのリクエスト遅延が高まり、顧客から苦情が寄せられました。DBAはOCP監視を通じて、障害発生時のデータディスク読み取り帯域幅がフルになっていることを発見し、遅延が高まった原因はSQLによるディスク読み取りが多すぎるためだと推測しました。しかし、障害発生時のTOP SQLを観察しても、通常の時間帯と何ら変わりがないことがわかり、どのSQLがディスク読み取りトラフィックを引き起こしているのか判断できませんでした。
ASHの待機イベントを照会することで、ディスク読み取りトラフィックがどのSQLに関連しているかを特定できます：
OceanBase(root@oceanbase)>select svr_ip, svr_port, con_id as tenant_id, sql_id, event, count(*) as cnt from GV$OB_ACTIVE_SESSION_HISTORY ash where wait_class in ('SYSTEM_IO', 'USER_IO') and sample_time between "2025-01-29 10:35:45" and "2024-01-29 10:45:47" group by svr_ip, svr_port, tenant_id, sql_id, event order by cnt desc limit 100;
クエリ結果は次のとおりです：
+----------------+----------+-----------+------------------------------------+-----------------------+-------+
| svr_ip | svr_port | tenant_id | sql_id | event | cnt |
+----------------+----------+-----------+------------------------------------+-----------------------+-------+
| xx.xx.xx.xx | 2882 | 1002 | 18AB15790D884E6A4823C892456E8650 | db file data read | 24511 |
| xx.xx.xx.xx | 2882 | 1002 | DBCB5D52A5E14718345165081BC7EAE4 | db file data read | 17859 |
| xx.xx.xx.xx | 2882 | 1002 | 32AB97A0126F566064F84DDDF4936F82 | db file data read | 15463 |
| xx.xx.xx.xx | 2882 | 1002 | 752F9D90CE614E180E965438E4B5A87D | db file data read | 11674 |
| xx.xx.xx.xx | 2882 | 1002 | NULL | palf write | 1581 |
| xx.xx.xx.xx | 2882 | 1002 | NULL | db file compact read | 193 |
+----------------+----------+-----------+------------------------------------+-----------------------+-------+
クエリの結果、4つのSQLが実行過程で大量のI/O関連待機イベントを発生させており、SQL応答時間を大幅に遅らせていることがわかります。
実行フェーズの分析
SQLの実行プロセスは多くのフェーズに分かれており、OceanBaseデータベースV4.2.5 BP3バージョンでは、合計17種類の実行フェーズに分類されています。v$ob_active_session_historyでは17列を用いてこれらの実行フェーズを表現しており、SQLがサンプリング時にそのフェーズにある場合は列の値が'Y'となり、そうでない場合は'N'となります。
- IN_PARSE：システムがSQL文の構文解析を行っています。
- IN_PL_PARSE：システムがPL/SQLコード（ストアドプロシージャや関数など）を解析しています。
- IN_PLAN_CACHE：システムがSQLの実行計画を検索または生成しています。
- IN_SQL_OPTIMIZE：システムがSQLの実行パスを最適化しています。
- IN_SQL_EXECUTION：SQLが実際に実行されています（データへのアクセスや結果の計算など）。
- IN_PX_EXECUTION：システムがマルチスレッド/ノード並列によりSQLを実行しています（並列クエリ）。
- IN_SEQUENCE_LOAD：システムが自動インクリメント列（IDフィールドなど）やシーケンスSEQUENCEに一意の値を生成しています。
- IN_COMMITTING：システムがトランザクションをコミットしています。
- IN_STORAGE_READ：システムがストレージエンジンからデータを読み取っています（テーブルやインデックスなど）。
- IN_STORAGE_WRITE：システムがストレージエンジンにデータを書き込んでいます。
- IN_REMOTE_DAS_EXECUTION：システムがDAS実行エンジンを使用して分散実行を行っています。
- IN_FILTER_ROWS：システムのストレージエンジンがダウンプッシュ演算子（フィルタリングや集計など）の実行を行っています。
- IN_RPC_ENCODE：システムがリクエスト/応答データをエンコードしています。
- IN_RPC_DECODE：システムがリクエスト/応答データをデコードしています。
- IN_CONNECTION_MGR：システムがセッションの作成または閉じる処理を行っています（接続プール管理）。
- IN_PLSQL_COMPILATION：システムがPL/SQLコード（ストアドプロシージャなど）をコンパイルしています。
- IN_PLSQL_EXECUTION：システムがPL/SQLコード（ストアドプロシージャなど）を実行しています。
OceanBaseデータベースでは、待機イベント間には相互包含関係が存在します。例えば、SQL実行フェーズのIN_SQL_EXECUTIONにあるセッションは、ストレージ層にアクセスしている可能性があり、同時にIN_STORAGE_READ/IN_STORAGE_WRITEフェーズにもあることになります。
事例3：分散実行のボトルネックを特定する
あるミドルウェア業務で朝方、ユーザー操作がカクつく現象が発生しました。監視データによると、データベースクラスタ内のxx.xx.xx.x9ノードのCPU使用率が継続的にフル負荷となり、SQL実行の遅延が急激に上昇していました。DBAがプライマリノードの切り替えやノードの再起動を試みた後、CPU使用率は正常に戻りました。 事後の調査で、障害発生中の監査ログ（SQL Audit）が再起動により失われたため、ASH（アクティブセッション履歴）データを用いて障害発生時間帯（10:30 から 10:45）のセッション状態を分析し、以下の重要な発見がありました：
OceanBase(root@oceanbase)>select svr_ip, tenant_id, IN_REMOTE_DAS_EXECUTION, name.name as event, count(*) * 10 as cnt from CDB_WR_ACTIVE_SESSION_HISTORY ash left join v$event_name name on ash.event_no=name.`event#` where sample_time between "2024-11-29 10:30:45" and "2024-11-29 10:45:45" and tenant_id=1002 group by svr_ip, tenant_id, IN_REMOTE_DAS_EXECUTION, event order by cnt desc limit 20;
クエリ結果は以下の通りです：
+---------------+-----------+-------------------------+--------------------------+------+
| svr_ip | tenant_id | IN_REMOTE_DAS_EXECUTION | event | cnt |
+---------------+-----------+-------------------------+--------------------------+------+
| xx.xx.xx.x9 | 1002 | Y | | 48330 |
| xx.xx.xx.x4 | 1002 | N | das wait remote response | 28920 |
| xx.xx.xx.x1 | 1002 | N | das wait remote response | 20050 |
| xx.xx.xx.x9 | 1002 | N | default condition wait | 2460 |
| xx.xx.xx.x4 | 1002 | N | default condition wait | 1450 |
| xx.xx.xx.x1 | 1002 | N | px loop condition wait | 1420 |
| xx.xx.xx.x9 | 1002 | N | px loop condition wait | 1330 |
| xx.xx.xx.x9 | 1002 | N | | 1170 |
| xx.xx.xx.x4 | 1002 | N | | 900 |
| xx.xx.xx.x1 | 1002 | N | default condition wait | 830 |
| xx.xx.xx.x4 | 1002 | N | default condition wait | 570 |
| xx.xx.xx.x4 | 1002 | N | px loop condition wait | 530 |
| xx.xx.xx.x9 | 1002 | Y | | 520 |
+---------------+-----------+-------------------------+--------------------------+------+
重要な発見は以下の通りです：
ノードIP |
主要フェーズ/待機イベント |
セッション数（割合） |
|---|---|---|
| xx.xx.xx.x9 | リモートDASタスク（IN_REMOTE_DAS_EXECUTION） | 48330回（他のノードを大きく上回る） |
| その他のノード | リモート応答待ち（das wait remote response） | 28920回、20050回 |
以下の結論を導き出しました：
問題の根本原因：
- 故障ノード（xx.xx.xx.x9）のCPUがフル負荷となったのは、他のノードからの多数のリモートDASリクエストを同時に処理したためです。
- 他のノード（xx.xx.xx.x4やxx.xx.xx.x1など）は、このノードからの応答を待つために多数のワーカースレッドを占有し、キューが積み上がり、システムの輻輳がさらに悪化しました。
根本的な原因：
SQL関連のディメンション分析を通じて、毎朝実行される2つの定時AP業務SQL（例：バッチデータ同期タスク）がトリガーされ、並行実行時に過剰なCPUリソースを消費し、通常の業務SQLのリソースを圧迫していることが判明しました。