本記事では、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初心者向け実験
初心者の方でもすぐに体験できるよう、3つの実験を用意しました。データベースのASHタイムラインを遡ってみて、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ループ条件待機）
- セッション3221923627は、読み取りI/O完了を待機中（DBファイルデータ読み取り）
- セッション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 ビューは、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つのフィールドは、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 |
+----------------+----------+-----------+------------------------------------+-----------------------+-------+
ご覧のように、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データベースでは、待機イベント間には相互に含まれる関係が存在します。例えば、IN_SQL_EXECUTIONのSQL実行フェーズにあるセッションは、ストレージ層にアクセスしている可能性があり、同時にIN_STORAGE_READ/IN_STORAGE_WRITEのフェーズにもあることになります。
事例3：分散実行のボトルネックを特定する
あるミドルウェアサービスで朝にユーザー操作のカクつきが発生しました。監視データによると、データベースクラスタ内のノード xx.xx.xx.x9 のCPU使用率が継続的にフル負荷状態にあり、SQL実行の遅延が急激に上昇していました。DBAがプライマリノードの切り替えとノードの再起動を試みた後、CPU使用率は正常に戻りました。 事後の調査では、障害発生中の監査ログ（SQL Audit）が再起動により失われていたため、ASH（Activity 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) | 48,330回 (他のノードを大きく上回る) |
| その他のノード | リモート応答待ち (das wait remote response) | 28,920回、20,050回 |
以下の結論を導き出しました：
問題の根本原因：
- 障害ノード（xx.xx.xx.x9）のCPUがフル負荷になったのは、同時に多数のリモートDASリクエスト（他ノードからのもの）を処理していたためです。
- 他のノード（例：xx.xx.xx.x4やxx.xx.xx.x1）は、このノードからの応答を待つために多数のワーカースレッドを占有し、キューが積み上がってシステムの輻輳がさらに悪化しました。
根本的な原因：
SQLの関連性分析を通じて、朝に2つの定期的に実行されるAP業務SQL（例：バッチデータ同期タスク）がトリガーされ、並行実行時に過剰なCPUリソースを消費し、通常の業務SQLのリソースを圧迫したことが判明しました。