ここではバッチ処理でSQLでは時間がかかっていないけれど、バッチ処理全体として時間がかかっている場合の原因を紹介します。
遅いSQLや実行回数の多いSQLを確認する方法は↓で紹介していますので参考にしてください。
＞＞【SQL】長時間処理や遅いSQLを確認する方法
＞＞【SQL】実行回数の多いSQLを確認する方法
バッチ処理でSQLは遅くないけど、処理に時間がかかる原因
オンライン処理にしろ、バッチ処理にしろ、処理時間が長くなる、遅くなることの原因の多くは、データベースへのアクセスに時間がかかること、つまり、SQLに時間がかかることが最も多いのではないでしょうか。
しかし、まれに、SQLでは時間がかかっていなくても、バッチ処理全体としては時間がかかるケースがありますので、いくつか紹介します。
バッチ/WEBサーバとDBサーバ間の通信時間
比較的多いケースがこちらです。バッチサーバやWEBサーバとDBサーバ間の通信に時間がかかるケースです。例えば、SQLを10回実行するだけなら何ともない場合でも、1つのバッチ処理でSQLを30万回とか50万回とか実行するようなバッチ処理があります。
SQL1回あたりの処理時間は短くても、バッチ処理全体としてはとても時間がかかります。このような場合には、SQLの実行回数を減らし、サーバ間の通信回数を減らし、トータルで処理時間を短縮する必要があります。
当然、アプリケーションの見直しが必要です。。
JAVAのヒープサイズが枯渇
次にJAVAのヒープサイズが枯渇するケースです。特にバッチ処理で見られます。
JAVAのバッチプログラムで大量のデータを扱う場合などに発生します。処理途中で、ジョブに振り分けられたヒープサイズが枯渇し、GC（ガーベージコレクション）が頻発し、処理時間が長時間となります。
このような場合には、メモリに余裕があるのであれば、とりあえず、ジョブに割り当てるヒープサイズを増やしましょう。
ジョブスケジューラのジョブ同時実行数が限界
これも珍しくないけーすです。
バッチ処理を高速化するために、プログラムを並列処理させるという対策をとる人がいます。そうすると、必然的にジョブの同時実行数が増大します。
実はジョブスケジューラには、最大同時実行数などが設けられており、それを超えるとキューイングされ待ち状態になったりします。これによってバッチ処理時間が長時間となることがあります。
これは私見ですが、プログラムレベルの並列化はオススメしません。
過去様々な弊害を見てきましたし、やはり並列化するのであれば、ORACLE機能であるパラレル処理を使って高速化するなど、設計は十分に考えた方が良いと思います。
まとめ
特にバッチ処理のチューニング案件では、SQLが問題となるケースも多いのですが、このようにSQL以外に問題があるケースも度々見受けられます。
SQLが得意で、SQLチューニングだけやっておけば解決できるかというとそうではありません。様々な視点や知識を以てチューニングに臨みましょう。
SQLのチューニング方法は↓で紹介していますので参考にしてください。
＞＞SELECT文のSQLチューニング方法まとめ