ストアドプロシージャ中心のバッチはどう移すか

「バッチ処理の実体はぜんぶDBの中のストアドです」——国産の基幹システムでは非常によくある構成です。朗報から言うと、この構成は意外に移行しやすい。ただし2つの条件があり、それを外すと難易度が跳ね上がります。

01朗報：同一エンジンなら、ストアドはそのまま動く

OracleからRDS for Oracle、SQL ServerからRDS for SQL Serverのように同一エンジンでRDSに移すなら、ストアドプロシージャはダンプと一緒に移行されてそのまま動きます。ロジックの書き換えは原則不要。バッチの移行対象は「ストアドを起動する側」（ジョブスケジューラやシェル）だけになり、シェルバッチの作法の範囲で片付きます。

02罠：OSに手を伸ばしているストアド

例外は、DBの外＝OS側に手を伸ばしている処理です。OracleのUTL_FILEによる任意ディレクトリへのファイル出力（RDS for OracleではDATA_PUMP_DIR等のマネージド・ディレクトリに限定され、それ以外の任意パスへの出力は不可）、SQL Serverのxp_cmdshell（OSコマンド実行）、DBサーバ上のローカルディレクトリへのエクスポート——マネージドのRDSではOS層に自由に触れないため、ここが移行の改修ポイントになります。

• ファイル出力 → S3への出力に置き換え（RDS for OracleはS3連携機能あり）、または呼び出し側のEC2で受けてS3へ
• OSコマンド実行 → 処理自体を呼び出し側（EC2／Lambda）に移す
• DBリンクでの他DB直結 → ネットワーク経路とセキュリティグループの再設計

03難易度が跳ね上がる分岐：エンジン変更

Oracle→PostgreSQL（Aurora）のようなエンジン変更を伴う場合、話は別次元になります。ストアドの方言（PL/SQL→PL/pgSQL）は変換ツール（AWS SCT）である程度自動化できますが、変換率は書き方に大きく依存し、残りは人手の書き換え＋全ロジックの再テストです。ライセンス費削減のリターンは大きいものの、「移行のついで」にやる規模ではありません。まず同一エンジンで移行し、エンジン変更は独立プロジェクトとして切り出すのが定石です。

04性能の見どころ

ストアドバッチの性能はストレージI/OとDBインスタンスで決まります。RDSのストレージにもgp3/io2の選定がそのまま当てはまり、夜間バッチの実行時間はインスタンスクラスとIOPSでチューニングします。オンプレ比の性能検証は、本番同等データでのバッチ1周の実測を移行判定の条件に入れてください。

05まとめ：移行順序

• ① OS依存機能の棚卸し（改修対象の確定）
• ② 同一エンジンでRDSへ移行（ストアドは無改修、起動側だけ整備）
• ③ 性能実測→インスタンス・ストレージ調整
• ④ エンジン変更（やるなら）は別プロジェクトとして計画