SAP Basis

SAP ST22でABAPダンプを解析する方法|原因特定から再発防止まで

SAPトランザクションST22でABAPショートダンプを確認し、ランタイムエラー、発生箇所、ユーザー操作、関連ログを整理して原因を特定する実務手順を解説します。

ST22 ABAPダンプのトラブルシューティングフローダンプ発生から関連ログ確認、原因分類、対応完了までの流れを示すST22 ABAPダンプのトラブルシューティングフローダンプ発生から関連ログ確認、原因分類、対応完了までの流れを示すST22で開く同じ時間帯を確認情報を比較対応を決めるABAPショートダンプST22で日時、ユーザー、ク…ダンプ詳細を読むランタイムエラー、分析、…関連記録を照合するSM21、SM37、SM50または…原因を分類すデータ、プログラム、ジョ…対応して監視する対応後に再発と業務影響を…CertPas オリジナル図解
ST22でABAPショートダンプを特定し、詳細確認、関連記録の照合、原因分類、対応後の監視へ進む流れ
目次
  1. ST22でダンプを検索する
  2. ダンプの主要項目を読む
  3. 原因を分類して切り分ける
  4. 再現性と影響範囲を確認する
  5. 運用担当から開発担当へ引き継ぐ
  6. 再発防止と監視を設計する
  7. ST22解析で確認する最終チェック

SAPシステムでプログラムが異常終了すると、ABAPランタイムエラーの情報がショートダンプとして記録されます。ST22は、このダンプを発生日時、ユーザー、実行プログラム、エラー内容、ソースコード位置から調査するためのトランザクションです。画面に表示されたエラーメッセージだけで判断せず、発生条件とシステムログを組み合わせて原因を絞り込みます。

運用担当者は、まず対象システムと発生時刻を確定し、同じ時間帯のダンプを確認します。業務ユーザーからの連絡だけでは情報が不足しやすいため、ユーザー名、画面操作、入力値、対象伝票、再現性も併せて記録します。この記事では、ST22を起点にしたダンプ解析の実務手順を、一次切り分けから開発・インフラ担当への引き継ぎまで整理します。

ST22でダンプを検索する

SAP GUIでST22を実行すると、指定した期間やユーザーに該当するショートダンプを一覧表示できます。最初は発生日時を狭く指定し、対象クライアント、ユーザー、サーバー、プログラム名などの情報で候補を絞ります。大量のダンプがある環境では、直近の発生だけでなく、同じエラーが繰り返されているかも確認します。

一覧では、Runtime Error、発生日時、ユーザー、クライアント、実行プログラムを確認します。同じランタイムエラーが短時間に複数回発生している場合は、個別ユーザーの操作ミスではなく、共通プログラム、インターフェース、ジョブ、データ更新などの問題である可能性があります。

対象行を開いたら、ダンプのヘッダー、エラー分析、発生箇所、ソースコード抜粋、呼び出し履歴、システム環境を順に読みます。画面上の短いメッセージだけでなく、長文の分析情報と変数内容を保存しておくと、担当者間の調査を再開しやすくなります。

ST22の一覧で対象を特定できない場合は、時間帯、ユーザー、アプリケーションサーバーを確認して検索条件を調整します。ダンプが保持期間を超えて削除されている場合は、運用ログ、ジョブログ、アプリケーションログなど別の記録を使って発生状況を再構成します。

ST22解析で集める情報ダンプ項目と原因確認に必要な運用記録の関係を示すST22解析で集める情報ダンプ項目と原因確認に必要な運用記録の関係を示す時系列照合ジョブ照合リソース照合ロック照合ST22ランタイムエラー、ユーザ…SM21発生時刻周辺のシステムイ…SM37ジョブログ、ステップ、バ…SM50 / SM66ワークプロセスとアプリケ…SM12ロックエントリと保持者ま…CertPas オリジナル図解
ABAPダンプ解析でST22とSM21、SM37、SM50またはSM66、SM12を照合する情報源の比較

ダンプの主要項目を読む

ランタイムエラーと例外情報

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はエラー名を確認するだけの画面ではなく、発生条件、処理経路、システム状態を結び付ける調査の起点です。ダンプの詳細と周辺ログを同じ時系列で扱うことで、原因の特定と再発防止を安定した手順にできます。

ブログ一覧へ戻る