SAP Basis
SAP ST22でABAPダンプを解析する方法|原因特定から再発防止まで
SAPトランザクションST22でABAPショートダンプを確認し、ランタイムエラー、発生箇所、ユーザー操作、関連ログを整理して原因を特定する実務手順を解説します。
SAPシステムでプログラムが異常終了すると、ABAPランタイムエラーの情報がショートダンプとして記録されます。ST22は、このダンプを発生日時、ユーザー、実行プログラム、エラー内容、ソースコード位置から調査するためのトランザクションです。画面に表示されたエラーメッセージだけで判断せず、発生条件とシステムログを組み合わせて原因を絞り込みます。
運用担当者は、まず対象システムと発生時刻を確定し、同じ時間帯のダンプを確認します。業務ユーザーからの連絡だけでは情報が不足しやすいため、ユーザー名、画面操作、入力値、対象伝票、再現性も併せて記録します。この記事では、ST22を起点にしたダンプ解析の実務手順を、一次切り分けから開発・インフラ担当への引き継ぎまで整理します。
ST22でダンプを検索する
SAP GUIでST22を実行すると、指定した期間やユーザーに該当するショートダンプを一覧表示できます。最初は発生日時を狭く指定し、対象クライアント、ユーザー、サーバー、プログラム名などの情報で候補を絞ります。大量のダンプがある環境では、直近の発生だけでなく、同じエラーが繰り返されているかも確認します。
一覧では、Runtime Error、発生日時、ユーザー、クライアント、実行プログラムを確認します。同じランタイムエラーが短時間に複数回発生している場合は、個別ユーザーの操作ミスではなく、共通プログラム、インターフェース、ジョブ、データ更新などの問題である可能性があります。
対象行を開いたら、ダンプのヘッダー、エラー分析、発生箇所、ソースコード抜粋、呼び出し履歴、システム環境を順に読みます。画面上の短いメッセージだけでなく、長文の分析情報と変数内容を保存しておくと、担当者間の調査を再開しやすくなります。
ST22の一覧で対象を特定できない場合は、時間帯、ユーザー、アプリケーションサーバーを確認して検索条件を調整します。ダンプが保持期間を超えて削除されている場合は、運用ログ、ジョブログ、アプリケーションログなど別の記録を使って発生状況を再構成します。
ダンプの主要項目を読む
ランタイムエラーと例外情報
Runtime Errorは、ABAP処理が実行を継続できなくなった分類を示します。例外が捕捉されなかったケース、無効なデータ操作、権限や更新処理に関する失敗、メモリやリソースの不足など、複数の原因が同じ業務画面から発生することがあります。エラー名は検索語として有用ですが、名前だけで根本原因を確定しません。
エラー分析には、処理が停止した理由と、システムが提示した追加情報が記載されます。ここでは、対象の内部テーブル、データ型、オブジェクト、データベース操作、呼び出し先の情報を確認します。メッセージに値やキーが含まれる場合は、個人情報や業務上の機密情報を取り扱う社内ルールに従って共有範囲を決めます。
発生箇所と呼び出し履歴
発生箇所には、プログラム、インクルード、行番号、処理ブロックなどが表示されます。行番号は停止地点を示す重要な手掛かりですが、そこが必ずしも欠陥を作り込んだ場所とは限りません。呼び出し履歴を上方向にたどり、どのトランザクション、クラス、関数、バッチ処理から到達したかを確認します。
カスタムネームスペースのプログラムで発生している場合は、開発担当へプログラム名、インクルード名、行番号、呼び出し履歴、入力条件を渡します。標準プログラムで発生している場合は、修正を直接行わず、適用済み修正、関連ノート、サポートパッケージ、拡張実装、データ不整合を確認する流れにします。
ユーザー、トランザクション、ジョブ
ダンプのユーザー名と実行時刻を、利用者から聞き取った操作時刻と照合します。オンライン操作ならトランザクション、画面、選択条件、入力値を記録し、バックグラウンド処理ならジョブ名、ステップ、バリアント、実行サーバーを確認します。
ジョブ起因のダンプは、SAPバックグラウンドジョブ監視(SM37)でジョブログと実行履歴を照合します。ジョブの前段処理が失敗して空データを渡した場合や、特定のバリアントだけで異常値を処理した場合は、ST22のダンプ単体では判断しにくいためです。
原因を分類して切り分ける
データと入力値に起因するケース
特定の伝票、得意先、品目、会社コード、期間だけで発生する場合は、入力値やマスターデータ、カスタマイズの組み合わせを確認します。再現テストでは、本番データをそのまま複製するのではなく、必要な項目をマスキングした検証データを使用します。
同じ操作を別ユーザーや別伝票で試し、発生条件を比較します。特定レコードだけで再現するならデータ依存の可能性が高く、すべてのレコードで再現するならプログラム、設定、インターフェース、権限など共通要因を優先して調査します。
プログラムと拡張に起因するケース
カスタム開発、ユーザーEXIT、BAdI、拡張実装、修正済み標準コードが関係する場合は、ST22の停止行だけでなく、直前に渡された値と処理分岐を確認します。最近の移送、プログラム変更、ジョブバリアント変更が発生時刻の前後にないか、変更履歴と照合します。
開発担当への依頼には、発生日時、クライアント、ユーザー、プログラム、ランタイムエラー、停止行、呼び出し元、再現手順、対象データ、直前の変更を含めます。ダンプのスクリーンショットだけでは調査に必要な情報が不足するため、ST22から取得した詳細情報を安全な方法で共有します。
リソースとシステム状態に起因するケース
メモリ不足、データベース接続、更新処理、ロック、アプリケーションサーバーの負荷が関係する場合は、同時刻のシステム状態を調べます。システム全体のイベントはSAPシステムログ(SM21)で確認し、ワークプロセスの状態や長時間処理はSAPワークプロセス監視(SM50)で確認します。
ロック待ちや更新遅延が疑われる場合は、対象オブジェクトとロック保持者を確認します。業務処理を止める目的でロックを一律削除すると、更新の整合性を損なうことがあるため、保持者のセッション、処理の進行状況、業務担当者の確認を踏まえて対応します。ロックの確認にはSAPロックエントリ管理(SM12)を使用します。
再現性と影響範囲を確認する
原因調査では、「一度だけ発生した」のか、「同じ条件で再現する」のかを分けて記録します。再現しない場合でも、発生時刻、負荷、ジョブの並行実行、外部システムからの呼び出し、データ状態を残します。再現する場合は、検証環境で最小限の入力条件に絞り込みます。
影響範囲は、単一ユーザー、特定の業務処理、特定の会社コードや期間、全ユーザー、全アプリケーションサーバーのように段階化して整理します。業務停止が広範囲に及ぶ場合は、原因調査と並行して関係者へ状況、暫定対応、次回報告時刻を伝えます。
ダンプ件数の増加を監視する場合は、発生時間帯とランタイムエラーの種類を定期的に集計します。同一エラーを削除して件数を見えなくするのではなく、元のダンプを保存し、調査用の記録と対応履歴を残します。
運用担当から開発担当へ引き継ぐ
引き継ぎ資料には、次の項目を含めます。
- 発生日時とタイムゾーン
- システム、クライアント、アプリケーションサーバー
- ユーザー、トランザクション、ジョブ名、ステップ
- Runtime Error、例外クラス、メッセージ
- プログラム、インクルード、行番号、呼び出し履歴
- 入力条件、対象伝票、再現手順
- 同時刻のシステムログ、ジョブログ、ワークプロセス状況
- 直前の移送、設定変更、マスターデータ変更
- 業務影響、暫定対応、恒久対応の担当者
標準機能、カスタム開発、インターフェース、ジョブ、権限、データのどの領域を調査済みかも明記します。未確認の項目を「問題なし」と書かず、確認日時と確認方法を記録すると、重複調査を避けられます。
再発防止と監視を設計する
恒久対応では、プログラム修正だけでなく、異常データの入力防止、エラーハンドリング、ジョブの前提条件確認、監視通知、運用手順の見直しを組み合わせます。修正を本番へ反映する前に、正常系、異常系、境界値、並行実行、権限差異を検証します。
対応後は、同じ入力条件で再現しないこと、関連する別処理へ影響がないこと、ジョブが予定どおり完了することを確認します。ST22の新規ダンプ件数、SM21の関連メッセージ、ジョブログ、業務結果を一定期間追跡し、再発がないことを確認してからインシデントを完了します。
SAPシステムの運用全体を整理する場合は、SAP Basisシステム管理の実務ガイドも参照してください。ST22だけで完結しない監視、ジョブ、ロック、変更管理とのつながりを把握できます。
ST22解析で確認する最終チェック
- 対象のダンプを正しい日時とユーザーで特定した
- Runtime Error、例外、メッセージを記録した
- プログラム、インクルード、行番号、呼び出し履歴を確認した
- 入力値、対象データ、トランザクションまたはジョブを確認した
- SM21、SM37、SM50またはSM66、SM12の情報を照合した
- 再現性と影響範囲を分類した
- 直前の移送、設定変更、データ変更を確認した
- 暫定対応と恒久対応の責任者を決めた
- 対応後の監視期間と完了条件を定義した
ST22はエラー名を確認するだけの画面ではなく、発生条件、処理経路、システム状態を結び付ける調査の起点です。ダンプの詳細と周辺ログを同じ時系列で扱うことで、原因の特定と再発防止を安定した手順にできます。