ASH（Active Session History）は、OceanBaseデータベースにおいてアクティブセッションの履歴情報を記録するためのコアとなる診断ツールであり、DBAがパフォーマンスボトルネックや障害の根本原因を迅速に特定するのに役立ちます。
調査の複雑さに基づき、ASHで解決できる問題は以下の2つのカテゴリに分類されます：
第1のカテゴリの問題：ASHに含まれる特定のメトリクス信号により、調査の方向性を明確にすることができます。例：CPUリソースの異常な使用、I/Oリソースの異常な使用、特定の待機イベントによるボトルネック、セッションレベルのリソース消費などです。
第2のカテゴリの問題：ASHの複数の次元情報を組み合わせ、発散的な方法論を用いて再構築・統合する必要があります。この種の問題はASHユーザーに対して高い要求をします。
上記の問題分類に基づき、ASHは以下のシナリオにおいて従来の監視よりも顕著な利点があります：
リアルタイム動的問題診断：SQL応答時間が急激に上昇したり、システムリソースがボトルネックに達したりした場合、従来の監視ではデータベースのすべてのアクティブセッションを観察することができませんが、ASHは細かい粒度の情報をリアルタイムでキャプチャできます。
分散システムのクロスノード問題：OceanBaseデータベースのSQL実行パスは通常、複数のOBServerノードにまたがります。ASHは
trace_idやsql_idなどの情報を通じて複数ノードの実行情報を関連付け、エンドツーエンドのトレースを実現できます。SQL実行段階別診断：ASHはSQL演算子レベルの実行状況を観察でき、待機イベントや実行段階などの情報と組み合わせることで、plan_monitorなどの手段では得られない情報を提供します。
リソース競合と競争分析：複数のセッションが同一のリソース（ロック、キャッシュなど）を争奪したり、あるセッションが過剰なCPUを占有したりする場合、ASHはリアルタイムのアクティブセッション追跡と待機イベントの関連付けにより、精密な調査を行うことができます。
セッションレベルの問題調査：単一のセッションが長時間異常、ブロック、または長トランザクションなどのシナリオに対して、直接session_idをフィルタリングしてその履歴的な挙動を分析できます。これはprocesslistよりも包括的な診断情報を提供します。
バックグラウンドタスクのオーバーヘッド分析：ASHモデルでは、バックグラウンドタスクはバックグラウンドセッションと見なされ、
Program、Module、Actionフィールドで属性をマークし、待機イベントなどの次元でバックグラウンドタスクの実行オーバーヘッドを細かく分析します。コールドスタートと初期化問題：セッションが頻繁に接続を確立してから切断したり、SQL解析や計画生成が遅延したりするシナリオは、通常、従来の監視の死角となります。
共通のトラブルシューティングの考え方
ステップ１：パフォーマンス問題の現れ方を確認する
以下の方法で確認できます：
システムのQPS低下、RT上昇、CPU負荷異常、またはI/O待ち時間の急増などの現象を観察します。
OCP監視、Linuxシステムツール（tsar/iostat）などの外部手段による相互検証を行います。
ステップ2：ASHレポートを取得する
現在のシナリオに対する初期分析に基づいて、対応するASHレポートを取得します。
初めてASHレポートを取得する際は、いずれのパラメータも制限せず、時間範囲のみを入力してクラスタ全体のレポートを生成し、全体的な状況を把握することを推奨します。その後、初期分析の結果に基づき、特定のテナント、ノード、SQL_IDなどについて、より詳細なレポートを生成します。HTMLレポートは読みやすさとインタラクティブ性に優れているため、優先的に使用することを推奨します。
基礎レポート（クラスタ全体）を生成します。
少なくとも、レポート開始時刻と終了時刻の2つのパラメータを入力する必要があります。
例えば、
sysテナントで、以下のコマンドを実行してクラスタ全体のASHレポートを取得します。obclient(root@sys)[oceanbase]> CALL DBMS_WORKLOAD_REPOSITORY.ASH_REPORT('2025-09-23 17:14:00', '2025-09-30 18:14:00',report_type=>'html') \G特定のSQL_IDに関連する実行レコードのASHレポートのみを取得します。
特定のSQL_IDが
1CA21C86CCF10D8635BF62C17BEA7128であると仮定し、sysテナントで、以下のコマンドを実行してASHレポートを取得します。obclient(root@sys)[oceanbase]> CALL DBMS_WORKLOAD_REPOSITORY.ASH_REPORT('2025-09-23 17:14:00', '2025-09-30 18:14:00', sql_id=>'1CA21C86CCF10D8635BF62C17BEA7128',report_type=>'html') \G特定のOBServerノードのASHレポートを取得します。
特定のOBServerノードのIPが
192.168.0.1であると仮定し、sysテナントで、以下のコマンドを実行してASHレポートを取得します。obclient(root@sys)[oceanbase]> CALL DBMS_WORKLOAD_REPOSITORY.ASH_REPORT('2025-09-23 17:14:00', '2025-09-30 18:14:00', svr_ip=>'192.168.0.1', svr_port=>'2828',report_type=>'html') \G
ステップ3：レポートの解読と問題の特定
- 初期の特定。
すべてのリソース消費（CPU、I/O、ロックなど）は最終的に待機イベントとして表れ、ASHはサンプリングメカニズムを用いてこれらのイベントを記録します。以下のレポートモジュールに注目してください：
Top Foreground DB Time：フォアグラウンドセッションの主要な時間消費イベントを特定します。
Top Blocking Sessions：ブロッキングソースを迅速に特定します。
Top IO Events：I/Oの発生源（ログ書き込み、ユーザーSQL、バックグラウンドタスク）を区別します。
典型的なシナリオの識別：
行ロックによるブロッキング：
row lock waitイベントの割合が顕著です。CPUボトルネック：バックグラウンドタスク、並列実行、再試行イベントなどを総合的に判断する必要があります。
I/Oボトルネック：
palf write、DAG関連の待機イベント、またはSQL関連のディスク読み取りが発生します。
- 初期に特定したシナリオに基づいて、詳細な特定を行います。
- ブロッキングソースの特定。ロック待機シナリオに適用されます。
現在のASHにおいて、待機イベント `row lock wait` の割合が顕著な場合、以下の方法でさらに問題を特定します。
1. トップのブロッキングセッションを取得します。
例：
```shell
obclient(root@sys)[oceanbase]> SELECT blocking_session_id, count(1) AS cnt FROM oceanbase.GV$OB_ACTIVE_SESSION_HISTORY
WHERE sample_time BETWEEN '2025-09-23 17:14:00' AND '2025-09-30 18:14:00'
AND event = 'row lock wait'
GROUP BY blocking_session_id
ORDER BY cnt desc;
```
クエリ結果に基づいて：
* 特定の `blocking_session_id` が圧倒的多数を占める場合、長時間トランザクションやロックを保持し続ける低速クエリが存在することを意味します。
* 複数の `blocking_session_id` が近い割合を占める場合、並行ホットスポットが存在することを示しており、単一行レコードの高頻度更新、ホットパーティションへの集中アクセス、大規模アカウントと小規模アカウントのデータ分布の不均衡などの問題が考えられます。
2. ロックを保持するトランザクションIDを取得します。
前のステップで取得したブロッキングセッションID（`blocking_session_id`）に基づいて、ロックを保持するトランザクションIDを取得します。例：
```shell
obclient(root@sys)[oceanbase]> SELECT tx_id, count(1) as cnt FROM oceanbase.GV$OB_ACTIVE_SESSION_HISTORY
WHERE sample_time BETWEEN '2025-09-23 17:14:00' AND '2025-09-30 18:14:00'
AND blocking_session_id = xxxx
GROUP BY tx_id
ORDER BY cnt desc;
```
3. ロックを保持するSQL_IDを取得します。
前のステップで取得したトランザクションID（`tx_id`）に基づいて、ロックを保持するSQL_IDを取得します。例：
```shell
obclient(root@sys)[oceanbase]> SELECT * FROM oceanbase.GV$OB_SQL_AUDIT
WHERE tx_id = xxx
ORDER BY request_time desc\G
```
上記の段階的なクエリにより、具体的なブロッキングセッション、トランザクション、SQL文まで正確に特定できます。
- リソースホットスポットの特定。CPU/I/O不均衡シナリオに適用されます。
データベースのCPU問題とI/O問題が顕著な場合、以下の手順で調査を進めることができます。
* ルーティングの正確性：ビュー `GV$OB_SQL_AUDIT` の `partition_hit` 列を確認し、ODPルーティングが均等かどうかを確認します。
* データ分布：ASH内の `tablet_id` アクセス頻度を分析し、ホットパーティションを特定します。
* Leader分布：テナントのLeaderノードはより多くの内部RPC/Inner SQLを処理するため、ASHのバックグラウンド負荷を確認する必要があります。
* 並列実行：ASHレポートにPXタスクが多数表示される場合、SQL次元と関連付けて並列度を調整する必要があります。
* バックグラウンドタスク：`Program` がDAG関連の待機イベントである場合、通常はダンプマージによるI/OまたはCPU消費を示しています。
詳細な調査操作については、[CPU使用率不均衡問題の調査](200.cpu-usage-imbalance-troubleshooting.md)および[IOボトルネック問題の調査](300.io-bottleneck-troubleshooting.md)を参照してください。
解決策
行ロックによるブロッキングについては、以下の方法を試すことができます：
ロックを保持する業務ロジックを最適化し、トランザクションの持続時間を短縮します。
ホットスポット行の分割またはアプリケーション層でのレート制限を行います。
ASH ReportのTop Blocking Sessionsで継続的に監視するなどします。
CPU使用率の偏りについては、以下の方法を試すことができます：
ODPルーティングルールを修正し、トラフィックの均等化を確保します。
パーティショニング戦略を調整し、ホットスポットTabletを分散させます。
PX並列度パラメータを最適化します。
再試行イベントが多いSQLに対して業務上の改修を行います。
I/Oボトルネックについては、以下の方法を試すことができます：
ディスク読み取りが多いSQLの実行計画を最適化します。
ダンプ・マージのトリガー時期を調整します。
I/Oリソースを拡張するか、より高性能なストレージ媒体を採用します。