本記事では、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タイムラインを開いて、ASHの魅力をすぐに感じられるよう、3つのゼロベース実験を用意しました。
実験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は、読み取りIO完了を待機しています（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で、91265秒実行されました。
ASH分析法
V$OB_ACTIVE_SESSION_HISTORYビューは、秒単位のフルセッションスナップショットを提供し、事前の設定なしで過去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秒あたりの平均セッション数を示し、データベースの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使用率は依然としてフルになっていました。この問題は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つのフィールドは、1つの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作業状態であり、例えば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 |
+----------------+----------+-----------+------------------------------------+-----------------------+-------+
この結果から、実行中に大量のI/O関連待機イベントが発生している4つのSQLがあり、これにより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データベースでは、待機イベント間には相互に含まれる関係が存在します。例えば、IN_SQL_EXECUTIONのSQL実行段階にあるセッションは、ストレージ層にアクセスしている可能性があり、同時にIN_STORAGE_READ/IN_STORAGE_WRITEの段階にも存在することになります。
ケース3：分散実行のボトルネックを特定する
あるミッドウェアサービスで、朝方ユーザー操作がカクつく現象が発生しました。モニタリングによると、データベースクラスタ内のxx.xx.xx.x9ノードのCPU使用率が継続的にフルロード状態となり、SQL実行の遅延が急激に上昇していました。DBAはプライマリノードの切り替えやノードの再起動を試した後、CPU使用率が正常に戻りました。 事後の調査により、障害時の監査ログ（SQL Audit）が再起動によって失われたことが判明しました。そのため、ASH（Active Session History）データを用いて障害発生時間帯（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のリソースを圧迫したことが明らかになりました。