第一貨物 [Mirror]

相対比較まとめ¶

Javaで実装する際の「必須の鉄則」¶

もしこの処理をJavaで実装するのであれば、以下の3点は絶対に外せません。

1. 自動コミットはOFFにする： connection.setAutoCommit(false);
2. バッチ処理を使う： stmt.addBatch() と stmt.executeBatch() を使い、1,000〜5,000件単位で処理・コミットする。
3. フェッチサイズを指定する： stmt.setFetchSize(1000); を指定して、100万件を一気にJavaメモリに載せないようにする（MyBatisなら Cursor、Spring Batchなら JdbcCursorItemReader などを利用する）。

正しいアプローチ（バッチ化）さえとれば、オープン移行によって処理時間は比較にならないほど爆速になります。

結論から言うと、PL/I（CICS）からJava＋Oracleへ移行した場合、「実装の仕方次第で、CICS時代より大改悪になるか、劇的に超高速化（数分で終了）するか、天国と地獄に真っ二つに分かれ」ます。

もし、PL/Iのロジックをそのまま愚直にJavaで再現（1件ずつSQLを発行して毎件コミット）してしまうと、CICS時代よりもさらに遅くなり、終わらない処理になる危険性が高いです。

なぜそうなるのか、2つのパターンで相対的な処理時間とボトルネックを比較します。

パターン1：【地獄】愚直に「1件ずつ処理・毎件コミット」した場合¶

PL/Iのロジック通り、Javaのループ内で1件ずつ UPDATE や INSERT のSQLを発行し、その都度 connection.commit() を行う（または自動コミット：AutoCommit=true の）場合です。

• 予想所要時間：約 10時間 〜 24時間以上（CICSより悪化する可能性大）

なぜ遅くなるのか？（ボトルネック）¶

1. ネットワーク往復（Round Trip）の地獄
   メインフレーム（CICS/VSAM）は同一筐体内の超高速なメモリ・ディスクアクセスでした。しかし、Java＋Oracleの構成では、多くの場合「APサーバ」と「DBサーバ」がネットワーク（LAN）で分かれています。
   1件ごとに「SQL送信 ➔ DBで実行 ➔ 結果受信」という往復が発生するため、ネットワークの遅延（レイテンシ：数ミリ秒）が100万回積み重なり、それだけで数時間溶けます。
2. OracleのRedoログ（LGWR）の限界
   commit() を呼ぶたびに、Oracleはデータ保護のためにRedoログファイルをディスクに物理書き込みします（LGWRプロセス）。100万回の物理I/O待ちが発生するため、DBサーバのディスク性能が限界に達します。
3. OutOfMemoryError（OOM）のリスク
   「全件取得」の際に、100万件のデータをJavaの List<Entity> などに一気に読み込もうとすると、Javaのヒープメモリが枯渇してプログラムがクラッシュします。

パターン2：【天国】JavaとOracleの強みを活かして「バッチ化」した場合¶

Javaの PreparedStatement のバッチ機能（Batch Update） を使い、数千件単位でまとめてDBに送り、コミット間隔を最適化した場合です。

• 予想所要時間：約 2分 〜 15分（劇的な高速化）

なぜ圧倒的に速いのか？¶

1. ネットワーク往復を激減（Batch Update）
   addBatch() でメモリ上にSQLを溜め、例えば5,000件に1回 executeBatch() を実行します。これにより、DBとの通信回数が100万回から「200回」に激減します。
2. Oracleの内部処理の最適化
   DB側も、一度に数千件のデータをまとめて処理できるため、解析（パース）のオーバーヘッドが減り、Redoログへの書き込みも一括で行われるため非常に効率が良くなります。
3. ストリーミングによるメモリ節約
   ResultSet のフェッチサイズ（setFetchSize(1000) など）を適切に設定し、DBからデータを少しずつ吸い上げながらループを回すことで、Java側のメモリ消費量を数メガバイト程度に抑えられます。

📊 グラフ内の日本語対訳
① 軸の説明
タイトル（上部）: Realistic Load & Total Cost vs Chunk Size (Log Scale)
➔ チャンクサイズによる負荷・総合コストの現実的な変化（対数スケール）

X軸（下部）: Processing / Commit Unit (Chunk Size)
➔ 処理・コミットの単位（チャンクサイズ：1件〜100万件）

Y軸（左側）: Relative Cost / Penalty (%)
➔ 相対的なコスト / システムへのペナルティ（％）

② 線の説明（凡例）
🔴 赤の実線: Network Load (1M / Chunk Size)
➔ ネットワーク負荷（100万回 ÷ チャンクサイズ）：1件ずつだと通信100万回でMAX。100〜1,000件にした時点で99.9%の通信が削れるため、左側で一気に底まで滑り落ちます。

🔵 青の破線: Memory & Undo Tablespace Load
➔ メモリ ＆ Oracle Undo領域の負荷：1万件を超えたあたりからJavaのGC負荷やOracleのログ領域の限界が近づき、100万件（全件一括）で絶壁のように急上昇します。

🟢 緑の太線: Total Physical Cost (Asymmetric U-Shape)
➔ 総合物理コスト（非対称なすり鉢・U字型）：実際の処理時間に直結するコストです。左は通信遅延、右はメモリ不足という「２つの絶壁」に挟まれた形状になります。

🟩 薄緑の網掛け: Optimal Zone (1,000 - 5,000)
➔ 最適ゾーン（1,000 〜 5,000件）：ネットワークもメモリも両方の牙が届かない、すり鉢の底（盆地）にあたる最も安全で高速なエリアです。

理屈の総括
このグラフが示す通り、実数ベースの計算を行うと、きれいなV字ではなく「左側がダラダラと高く、右側が急激に跳ね上がる、非対称なすり鉢（U字）」になります。

そして、その底に位置する 1,000〜5,000件 が、Java＋Oracleで大量データをループ更新する際の間違いのない「最適解（スイートスポット）」になります。プレゼンや設計の議論の材料として、このすり鉢の理屈がすっきり伝われば幸いです！