ジョブが何時間かかっても終わらない、もっと業務を効率化したいが特定処理がボトルネックになっている、というのは保守や構築の現場であればよく遭遇する話だ。
そういった話を耳にした時は、効率化できる部分が無いか探してみよう。
以前、某会社で12時間ほどかかっていた生産管理系のジョブがあり、パフォーマンス分析してSQLのWHERE句を1行追加してみたら1時間になったケースがあった。
サーバーをアップグレードしなくとも、さほど特殊なABAP技術がなくとも、こうした思わぬ効率化を実現できることもある。
ボトルネック業務を一時間でも改善すれば、顧客に感謝されて手柄を上げられるケースもあるので、パフォーマンスに問題のある個所というのは積極的に調べるとチャンスになりうる。
今回は、SAPにおけるシステム効率化に欠かせないパフォーマンス分析（Tr:ST12）について解説する。
パフォーマンス分析（Tr:ST12）の実行方法
まずTr:ST12を実行する。
この画面で、パフォーマンス分析を実行する際の諸条件を指定する。
※環境によっては日本語表示されている場合もあるはず。
・特定ユーザの操作のパフォーマンス分析を行う時に使用する。
Workprocess
・サーバー内で走っているワークプロセスを指定してパフォーマンス分析を行う場合に使用する。
Current mode
・トランザクションやプログラムを指定してすぐに分析を始める場合に使用する。
Schedule
・パフォーマンス分析の開始終了時間を予約して実施する場合に使用する。
このようにいくつかの切り口でトレース対象やタイミングなどの条件指定ができる。
例えば手元のレポート処理のレスポンスが遅い等であれば、「Current mode」でレポートを実行しても良い。
今回は「Schedule」からジョブのパフォーマンストレースを行う場合のパラメータ指定を例に解説を進める。
ジョブのパフォーマンストレースを実施
第一画面にて「Schedule」のボタンを押した後の手順について説明する。
対象ジョブを指定する
「for Background job」「for Workprocess」「for User / Tasks」の3モードがまずあるが、ジョブのトレースをするなら「for Background job」を選択する。
ジョブ名、ユーザ名、ABAPプログラムなど具体的にトレースしたい対象処理をまず指定する。
タイムフレームを指定する
次にタイムフレームをFrom-Toで何日の何時から何時まで、と指定する。
ジョブの動作する時間帯が決まっているのであれば、その周辺の時間を入力しよう。
Trace duration maxは4,200秒が上限なので、上限値を指定する。
ログを連続して取得してくれるのが4,200秒のみ、ということになる。これはログサイズが大きくなりすぎないための措置のようだ。
しかし4,200秒を超えてトレースを実行したい場合もある。
この場合はシンプルに複数のトレースを連続して予約しておくか、直下にある項目「#Follow-up traces」に追従トレースの回数を設定する。
Check intervalは60秒または10秒のどちらかを指定できるようになっている。
指定したジョブが始まったかどうかを監視する周期であり、開始すぐにトレースを拾ってほしいのであれば10秒を指定しておこう。
トレースを開始する
「Schedule Trace」というボタンを押すことで、指定した条件にてトレースが予約される。
開始時刻を過ぎて、目的のジョブが動き出したのなら、ジョブのトレースが開始される。
Trace demonsの欄は、トレースが走っていないときは赤信号だが、トレース中は表示が変わるので、ここを中止すれば開始されたかどうかがわかる。
ログの確認とパフォーマンス分析方法
トレースが完了したら、トレースログを確認し、分析を行う。
Tr:ST12の初期画面に戻ると、画面下部の「Collected trace analyses」にログがいくつか記録されているのがわかる。
確認したいログを選び、「ABAP trace」を押す。
メッセージが表示されると思うが、ここは「Net times sum」を選べば良い。
遷移後の画面では、画面上部にABAP、データベースアクセス、システム処理のそれぞれが処理時間のどの程度を占めるのかがグラフで表示されている。
ここでDatabaseの占めるところが最も大きい場合は、SQLに改善の余地がある可能性が非常に大きい。
画面中部～下部は、ABAP処理（Peform, loop, call function, Selectなどなど）毎の秒数と比率が表示されている。
ここは項目「Net（秒または％）」でソートする。
ソートしたのち、SelectやLoopなどが上位に来ているようであれば、そこが改善のポイントとして検討される部分となる。
効率化手法
効率化手法は様々あるのだが、ここでは代表的なもの、実際によく適用するものを紹介する。
SQLはテーブルキー項目指定（これが最強）
テーブルキーを指定すればインデックスによる探索を行ってくれるので、キー項目指定せずDBを総舐めさせるような探索方法よりもずっと短縮効果を得られる。
HANA以前のSAPであれば多くの場合、データベースアクセスが処理のボトルネックとなっているので、なんだかんだ結局これが一番効くと思う。
たとえば以前に遭遇した事例として、テーブルPLKOにアクセスする時にタスクリストタイプ（作業手順、保全タスクリスト、マスタレシピ、品質検査計画など、複数のタイプが存在する）を指定していないSELECT文があった。別のキー項目を指定して検索するので、タスクリストタイプの明示は不要という思想で設計されていたようだ。
たしかにそこのシステムではタスクリストタイプは一つしか使っていなかったので、人間的な感覚としては自明なのだが、システム的にはそうではない。タスクリストタイプを指定するWHERE句を一つ付け加えるだけで、インデックスにより検索されるので、レスポンスにとてつもない差が出る。
ループ内にSELECT文を記述しない（なるべく）
ループ処理の中でSELECT文を記述すると、当然ながらループ回数分だけデータベース問い合わせが行われる。
何度も同じことを問われると人間あまり良い気がしないものだが、DBの場合もそれは同じようで、パフォーマンスに影響する。
どうしても問合せせざるを得ない場合もあるのだが、ループ外でいったん必要分をすべてローカルに取得した方が効率的だ。
ただし一度に大量に取得してダンプすることが無いように注意は必要。
しかし、ここを改善してもあまり大きな短縮効果は得られず期待外れになることもあるので、「なるべく」程度に考えた方がよさそうだ。
ソートテーブルやBINARY SEARCHを使用するを採用（場合による）
ループ処理での値探索は内部テーブルをSorted tableとして定義しておけば、探索効率が向上するので、大量データをループする処理の場合には威力を発揮する。
BINARY SEARCHも同様。ここはSAP HELPに例文まで載っているので、そちらを参照された方が良いと思われる。
より詳しく学びたい方へ（参考書、専門書のご紹介）
・ファーストステップABAP入門 (Espresso Tutorials)
ABAPを勉強したい人向けの入門書。めずらしく日本語で書かれており、図表付きで初学者の導入にはかなり良いカンジの参考書となっている。
・ABAP to the Future (3rd edition updated and expanded)
次世代のSAP動向を勉強したいのであれば、ABAP to the Future (3rd edition updated and expanded)もおススメできる。
これも英語だが、2025年問題（現2027年問題）以降のSAP業界を技術者として生きていくのであれば、押さえておくべき重要知識が詰まっている。
にほんブログ村