SAP Basis

SAP SM50でワークプロセスを監視する方法|SM66との使い分けと停止対応

SAP GUIのSM50でワークプロセスの状態を確認し、長時間処理、PRIV、待機、停止などの異常を切り分ける実務手順を解説します。SM66との違い、停止前の確認、関連トランザクションも整理します。

SM50とSM66の監視範囲インスタンス単位とシステム全体の監視を使い分ける基準を示すSM50とSM66の監視範囲インスタンス単位とシステム全体の監視を使い分ける基準を示す対象サーバーを特定プロセスを詳細調査SM50接続先アプリケーションサ…SM66アプリケーションサーバー…詳細調査プロセス情報をジョブ、ロ…CertPas オリジナル図解
SM50のインスタンス監視とSM66のシステム全体監視を比較し、詳細調査へ進む流れ
目次
  1. SM50で確認できる情報
  2. SM50とSM66の使い分け
  3. ワークプロセスの状態を読む
  4. 長時間処理の調査手順
  5. ワークプロセスを停止する前の確認
  6. SM50から行う運用操作
  7. SM50で改善しない場合の切り分け
  8. 監視結果を記録する方法
  9. SM50監視の実務ポイント

SAPのアプリケーションサーバーで処理遅延やユーザー操作の停滞が発生したときは、まずSM50でワークプロセスの実行状況を確認します。SM50は接続したアプリケーションサーバーのプロセスを表示し、処理の種類、状態、実行時間、ユーザー、プログラムなどを追跡するための基本的な監視画面です。

システム全体の運用状況を確認するときは、SAP Basisのシステム管理も併せて参照してください。SM50の情報だけで原因を断定せず、ジョブ、システムログ、ABAPダンプなど周辺情報と照合することが重要です。

SM50で確認できる情報

SM50を実行すると、接続先インスタンスに割り当てられたワークプロセスの一覧を確認できます。画面では、プロセス番号、ワークプロセスの種類、状態、実行時間、ユーザー、クライアント、実行中のABAPプログラムや処理内容を確認します。表示項目の名称や配置は、SAP GUIのテーマや画面設定によって見え方が異なる場合があります。

主に確認する情報は次のとおりです。

  • プロセスタイプ:Dialog、Background、Update、Spool、Enqueueなど
  • 状態:処理中、待機、保留などの現在の状態
  • 実行時間:処理開始から経過した時間
  • ユーザーとクライアント:処理を開始した利用者とクライアント番号
  • プログラムと処理内容:実行中のABAP処理やデータベース処理の手掛かり
  • テーブルやロックに関する情報:処理が待機している場合の追加確認材料

状態だけで異常と判断せず、処理時間、業務上の想定、同じ状態のプロセス数を組み合わせて見ます。通常のオンライン処理でも、データ量や更新処理の内容によって実行時間が長くなることがあります。

長時間ワークプロセスの切り分け検知から証跡収集、影響を抑えた対応までの手順を示す長時間ワークプロセスの切り分け検知から証跡収集、影響を抑えた対応までの手順を示す観察継続する場合原因と影響を把握承認済みの対応回復した場合SM50で検知プロセス番号、種類、状態、…更新して比較状態と経過時間の変化を確…関連情報を照必要に応じてSM37、SM21…業務影響を評安全に停止または再実行で…対応して確認承認された操作を行い、プ…CertPas オリジナル図解
SAPワークプロセスの長時間処理を、SM50で検知し、更新、関連情報の照合、影響評価、対応後確認へ進める切り分けフロー

SM50とSM66の使い分け

SM50は現在接続しているアプリケーションサーバーのワークプロセスを確認する画面です。一方、SM66は複数のアプリケーションサーバーを横断して、システム全体のワークプロセスを確認するために使います。

1台のアプリケーションサーバーで負荷や停止を調べる場合はSM50を使います。特定サーバーに偏った処理、ローカルなプロセス枯渇、特定インスタンス上の長時間処理を確認しやすい点が特徴です。

ユーザーから「システム全体が遅い」と報告された場合は、最初にSM66で全体の分布を確認し、問題が集中しているサーバーへ移動してSM50で詳細を確認します。SM66で複数サーバーに同じ状態が見える場合は、共通のデータベース処理、ロック、ジョブ、外部連携などを調べます。

ワークプロセスの状態を読む

SM50の状態は、処理が動いているかどうかだけでなく、処理がどこで時間を使っているかを考える材料になります。次の観点で、同一プロセスの状態を一定時間追跡します。

Runningまたは処理中

CPU処理やデータベース処理を実行している状態です。実行時間が短い処理が入れ替わっているだけなら、通常の稼働である可能性があります。同じプログラムが長時間実行され、利用者の操作遅延やワークプロセス不足を伴う場合は、選択条件、データ量、SQL、ロック、外部接続を調べます。

Waitingまたは待機

ワークプロセスが次の要求を待っている状態です。待機プロセスが多いこと自体は、直ちに障害を示すものではありません。利用可能なプロセス数、処理要求の到着状況、ダイアログ応答時間と合わせて判断します。

PRIV

ABAP処理がロールインされた状態で、ワークプロセスが長時間占有されている場合に確認対象となります。複数のプロセスがPRIVになっているときは、メモリ消費、処理の大きさ、ユーザー操作、バッチ処理の集中を調べます。業務影響を確認せずにプロセスを終了すると、未完了処理やロックの後処理が必要になるため、停止操作は慎重に行います。

Holdまたは保留

処理が保留され、通常の処理進行を妨げている可能性があります。対象のユーザー、プログラム、処理時間を記録し、同じプログラムや同じ業務処理が繰り返し保留になっていないか確認します。

長時間処理の調査手順

長時間処理を見つけたら、まずSM50の一覧から対象のプロセス番号、ユーザー、クライアント、プログラム、開始時刻または経過時間を記録します。画面を更新し、処理時間が継続的に増えているか、状態が変化しているかを確認します。

次に、処理の種類を切り分けます。オンライン処理なら利用者に実行内容を確認し、バックグラウンド処理ならSM37でジョブの実行状況、ジョブログ、開始条件を確認します。ジョブ起因の負荷を調べるときは、SAPバックグラウンドジョブ監視(SM37)を参照してください。

エラー終了やABAPランタイムエラーが疑われる場合は、ST22で該当時刻、ユーザー、プログラムのダンプを確認します。障害の発生時刻を基準に、SAP ABAPダンプ分析(ST22)とSM21のシステムログを照合すると、プロセス終了や通信障害などの関連イベントを追跡できます。

処理がデータ更新や排他制御を伴う場合は、SM12でロックエントリを確認します。ロックの所有者、作成時刻、対象テーブルやキーを確認したうえで、業務担当者に影響を確認します。SAPロックエントリ管理(SM12)では、ロック確認時の基本的な見方を整理しています。

ワークプロセスを停止する前の確認

SM50からプロセスを終了する操作は、対象処理を中断させる運用操作です。実行前に、次の情報を記録します。

  • 対象インスタンス、プロセス番号、プロセスタイプ
  • ユーザー、クライアント、プログラム、処理内容
  • 処理開始時刻、経過時間、現在の状態
  • 関連するジョブ番号、ロック、ダンプ、システムログ
  • 業務担当者が処理を再実行できるかどうか

オンライン処理を終了すると、利用者側のトランザクションがエラーになることがあります。更新処理では、データベースのコミット状況や業務データの整合性を確認し、必要に応じて再処理手順を準備します。バックグラウンド処理では、ジョブをプロセス終了だけでなくSM37側でも確認し、再実行や後続ジョブへの影響を判断します。

SM50で終了操作を行う前に、対象プロセスが本当に停止すべき状態かを確認します。単に実行時間が長いという理由だけで終了せず、CPU、データベース、ロック、外部システム応答のどこで待っているかを切り分けます。

SM50から行う運用操作

SM50では、対象ワークプロセスを選択して詳細情報を開き、処理内容やトレース情報を確認できます。権限とシステム運用ルールに応じて、プロセスのトレース、セッションの終了、ワークプロセスの終了などを使い分けます。

トレースを有効にする場合は、対象を限定し、取得時間を短く設定します。長時間または多数のプロセスに対してトレースを有効にすると、追加のI/Oやログ量が発生し、調査対象以外の処理にも影響する可能性があります。取得したトレースは、対象時刻、プロセス番号、ユーザー、プログラムと紐付けて保管します。

セッション終了とワークプロセス終了は影響範囲が異なります。セッション終了は利用者の処理を止める操作、ワークプロセス終了はプロセスを解放するためのより強い操作として扱い、段階的に判断します。実行後は、SM50でプロセスが解放されたこと、SM66で全体の負荷が変化したこと、利用者やジョブにエラーが出ていないことを確認します。

SM50で改善しない場合の切り分け

SM50でワークプロセスが空いていても、応答が遅い場合があります。その場合は、処理の待ち先を別の観点から調べます。

  • データベース処理の待機やSQL実行時間
  • SM12に残るロックエントリ
  • SM37の大量ジョブやジョブの同時実行
  • SM21のシステムログに記録されたエラー
  • ST22のABAPダンプ
  • RFC、外部ファイル、プリンターなど外部リソースへの待機
  • 特定アプリケーションサーバーへのログオン集中

SM50のワークプロセスがすべて使用中の場合は、ダイアログ、バックグラウンド、更新などの種類ごとに偏りを見ます。バックグラウンド処理がオンライン処理を圧迫している場合は、ジョブの実行時間帯や同時実行数を運用側で調整します。更新処理が滞留している場合は、更新要求、ロック、データベース応答を関連付けて確認します。

システムログを時刻で照合するときは、SAPシステムログ監視(SM21)を利用します。SM50はリアルタイムのプロセス確認に強く、SM21、SM37、ST22、SM12は原因と影響を時系列で結び付けるために役立ちます。

監視結果を記録する方法

障害対応では、SM50の画面を見た時点だけでなく、数分間の変化を記録します。少なくとも取得時刻、対象インスタンス、プロセス番号、状態、ユーザー、プログラム、経過時間、関連ジョブやロックを残します。

同じプロセスを再確認するときは、取得時刻をそろえ、状態と経過時間の変化を比較します。SM66で全体像を確認した場合は、問題が特定インスタンスに集中していたか、複数インスタンスで同時に発生していたかも記録します。

対応後は、プロセス数、ダイアログ応答、ジョブの進行、ロックの解放、エラーの再発を確認します。終了操作だけで症状が消えた場合でも、原因が解消したとは限りません。再発防止のため、対象プログラム、データ量、実行時間帯、同時実行条件を運用記録に残します。

SM50監視の実務ポイント

SM50は、アプリケーションサーバー単位のワークプロセスを即時に確認するための入口です。SM66で全体を見てからSM50で対象を深掘りし、SM37、SM21、ST22、SM12でジョブ、ログ、ダンプ、ロックを照合すると、停止操作に頼らない切り分けができます。

長時間処理は、処理時間だけでなく状態、プロセスタイプ、ユーザー、プログラム、業務影響を組み合わせて判断します。終了が必要な場合は、記録、影響確認、関係者との合意、実行後の確認までを一連の手順として扱います。

ブログ一覧へ戻る