SAP SM21でシステムログを確認する方法｜エラー調査と運用手順

01SM21で確認できるシステムログ

SAPのSM21は、SAPシステム内で発生したシステムレベルのイベントやエラーを確認するためのトランザクションです。ログオン、更新処理、データベース接続、メッセージサーバーや各種サービスに関係する記録などを、発生時刻とメッセージ内容から追跡できます。アプリケーション画面に表示されたエラーだけでは原因が分からないとき、SM21の記録を時系列で確認すると、障害の発生点を特定しやすくなります。

日常運用では、ユーザーから「処理が失敗した」「画面が応答しない」「突然ログオフされた」と報告された時点でSM21を確認します。障害対応では、ユーザーが操作した時刻、対象サーバー、トランザクション、ユーザーIDを先に記録してから検索すると、関係するメッセージを絞り込めます。

SAP Basis全体の運用手順は、SAP Basisシステム管理の記事と組み合わせて確認すると、ログ監視から事後対応までの流れを整理できます。

02SM21を開いて検索条件を設定する

SAP GUIでSM21を実行すると、システムログの選択画面が表示されます。最初に確認対象の期間を設定します。調査対象が明確な場合は、エラーが発生した前後の数分から数十分に限定します。期間を広くしすぎると、通常のメッセージに埋もれて重要な記録を見落としやすくなります。

代表的な確認項目は次のとおりです。

• 開始日時と終了日時：ユーザーの報告時刻の前後を指定する
• インスタンスまたはサーバー：分散環境では対象ホストを絞り込む
• メッセージの重要度：エラーや警告を優先して確認する
• ユーザーやトランザクションに関係する条件：対象処理を特定できる場合に利用する
• ログの表示範囲：必要に応じてローカルまたはシステム全体の記録を確認する

条件を入力したら実行し、一覧の発生日時、メッセージテキスト、メッセージクラス、メッセージ番号、発生元を確認します。まずエラーだけに限定し、原因が見えない場合に警告や情報メッセージまで範囲を広げる方法が効率的です。

03SM21の一覧からエラーを読み解く

SM21のメッセージは、単独の行だけで判断せず、発生時刻の前後に並ぶ記録と合わせて読みます。たとえば、データベース接続に関する警告の直後に更新処理の失敗が続いていれば、アプリケーション処理そのものよりも接続状態や基盤サービスを優先して調査します。

確認時は、次の情報を一つの記録として残します。

1. エラーが発生した日時とタイムゾーン
2. 対象のSAPシステム、インスタンス、アプリケーションサーバー
3. メッセージクラス、番号、本文
4. 関係するユーザー、トランザクション、ジョブ名
5. 同じ時刻に発生した前後のメッセージ
6. 実施した対処と、その後の再発有無

メッセージ本文にホスト名、ワークプロセス、データベース、ファイル、ユーザーなどが含まれる場合は、その値を省略せずに記録します。検索結果のスクリーンショットだけでなく、テキストとしてメッセージを転記しておくと、担当者間の引き継ぎや再発分析に役立ちます。

04SM21と他の監視トランザクションを使い分ける

SM21はシステム全体のイベントを確認する入口です。ABAPプログラムの実行時エラーや短期ダンプを調べる場合は、ST22でABAPダンプを分析する方法を参照します。SM21にエラーが記録されていても、詳細なABAPダンプの内容はST22側に保存されている場合があります。

処理が遅い、ワークプロセスが占有されている、または処理が待機している場合は、SM50でワークプロセスを監視する方法で実行中の処理、ステータス、実行時間を確認します。SM21の発生時刻とSM50の状態を照合すると、短時間の障害か、継続中のボトルネックかを判断しやすくなります。

バックグラウンド処理の失敗や遅延が疑われる場合は、SM37でバックグラウンドジョブを監視する方法でジョブのステータス、開始時刻、終了時刻、ジョブログを確認します。SM21、ST22、SM50、SM37は同じ時刻軸で確認することが重要です。

05障害発生時のSM21調査手順

障害の連絡を受けたら、次の順序で調査します。

1. 事象の発生時刻を固定する

ユーザーの報告時刻、画面に表示された時刻、ジョブの開始時刻などを突き合わせます。サーバーやユーザーのタイムゾーンが異なる場合は、システムログ上の時刻に合わせて記録します。

2. 対象範囲を限定する

対象のインスタンス、ユーザー、トランザクション、ジョブを確認し、SM21の期間を狭く設定します。分散環境では、最初に事象が発生したアプリケーションサーバーを優先します。

3. エラーの前後を確認する

該当行だけでなく、直前の警告、接続失敗、再起動、更新処理の異常も確認します。原因を示すメッセージが、最初に見つかったエラーより前に記録されていることがあります。

4. 関連トランザクションで裏付ける

ABAPダンプはST22、ワークプロセスはSM50、バックグラウンドジョブはSM37で確認します。複数の画面で発生時刻と対象を一致させ、推測だけで原因を確定しないことが大切です。

5. 対処後に再発を確認する

設定変更、ジョブ再実行、サービス復旧などを実施した後、同じ条件でSM21に新しいエラーが出ていないか確認します。復旧した画面だけで判断せず、一定時間のログを確認して再発の有無を記録します。

06SM21の検索で結果が多い場合の対処

ログが大量に表示される場合は、期間、サーバー、重要度の順に条件を絞ります。ユーザーIDやトランザクションが分かっている場合は、対象処理に関係する情報を手掛かりにします。メッセージ本文の一部だけで検索するより、発生時刻と発生元を組み合わせた方がノイズを減らせます。

同じメッセージが短時間に繰り返されている場合は、件数だけで重大度を判断しません。単一ユーザーの再試行による連続記録と、複数サーバーで同時に発生した記録では、調査の優先順位が異なります。発生範囲、継続時間、業務影響を合わせて判断します。

権限によって表示できるログの範囲が異なる運用では、必要なログを確認できる担当者と連携します。調査に使った選択条件を記録しておくと、別の担当者が同じ範囲を再確認できます。

07SM21の運用監視を安定させる

SM21は障害が起きたときだけ開くのではなく、定期的な監視にも利用します。日次または定期メンテナンスのタイミングで、重大度の高いメッセージ、繰り返し発生する警告、特定サーバーに偏ったエラーを確認します。

運用記録には、確認日時、確認者、対象期間、対象インスタンス、確認結果、対応チケット番号を残します。問題がなかった場合も「対象期間に重大なエラーなし」と記録すると、監視を実施した事実を追跡できます。

ログの確認だけで原因が分からない場合は、SM21のメッセージを起点に、アプリケーションログ、ジョブログ、ABAPダンプ、ワークプロセスの状態を組み合わせます。重要なのは、エラー本文を見てすぐに再起動や再実行を行うのではなく、業務影響と関連記録を確認してから対処することです。

08SM21確認時の実務チェックリスト

• 発生日時をシステムログの時刻で記録した
• 対象インスタンスとサーバーを特定した
• エラーの前後にあるメッセージを確認した
• ユーザー、トランザクション、ジョブとの関係を確認した
• ST22、SM50、SM37で関連情報を照合した
• 対処内容と実施時刻を記録した
• 対処後の再発有無を確認した

SM21は、エラーの本文を読むだけでなく、発生時刻、対象サーバー、関連トランザクションを結び付けて使うことで効果を発揮します。検索条件と調査結果を定型化すると、障害対応の初動が安定し、担当者が交代しても同じ観点で確認できます。