Db2 IMPORT vs INGEST：リソース特性と運用戦略の徹底比較
Db2における大量データ投入ユーティリティの選定は、単なる「処理速度」の比較だけでは不十分です。システムのボトルネックが CPU にあるのか、あるいは メモリ（バッファ・プール） にあるのかによって、最適な手法は180度変わります。本稿では、インフラSEが設計・運用時に考慮すべき、リソース消費の内部メカニズムと監視の要点を徹底解説します。
1. IMPORT のアーキテクチャ：メモリ資源の占有
IMPORT は内部的に INSERT ステートメント を1行ずつ発行するエージェントとして動作します。この挙動がリソースに与える影響を理解する必要があります。
- バッファ・プールへの圧力: 投入データはすべてバッファ・プールを経由します。大規模実行では既存のキャッシュデータが追い出され、他業務のヒット率が低下する「キャッシュ汚染」のリスクがあります。
- ログ消費: 各行の挿入がログに記録されるため、
COMMITCOUNTの設定が不適切だと、アクティブ・ログが満杯（SQL0964C）になり異常終了します。
-- メモリ負荷とログ消費を考慮した標準的な IMPORT 例
db2 "IMPORT FROM data.csv OF DEL COMMITCOUNT 5000 INSERT INTO MY_TABLE"
2. INGEST のアーキテクチャ：CPU 資源の並列活用
INGEST は「クライアント・サイド」で動作するパイプライン・マルチスレッド方式を採用しています。
- マルチスレッドによる CPU 消費: データの読み込み、フォーマット変換、書き込みを別々のスレッドで並列処理します。このスレッド間同期とデータ加工処理により、サーバーおよびクライアント双方の CPU リソースを激しく消費します。
- 高い可用性: アプリケーション・レベルのロックを最小限に抑える設計のため、オンライン業務を継続しながらバックグラウンドで高速投入する運用に適しています。
-- 並列処理を活かした INGEST 実行例
db2 "INGEST FROM FILE data.csv FORMAT DELIMITED INSERT INTO MY_TABLE"
3. リソース特性比較表（インフラSE視点）
| 比較項目 | IMPORT (メモリ負荷型) | INGEST (CPU負荷型) |
|---|---|---|
| 主に使用する資源 | メモリ（バッファ・プール） | CPU（マルチスレッド） |
| 処理単位 | シングルスレッド（逐次 INSERT） | マルチスレッド（並列ストリーム） |
| ログ消費傾向 | 逐次書き込み（制御しやすい） | 高スループット（急増に注意） |
| 他業務への影響 | キャッシュ追い出しによる遅延 | CPU 競合による計算資源の枯渇 |
4. 実行中の正確な監視方法
INGEST は専用の管理コマンドで進捗を確認します。
[実行中のジョブ一覧を確認]
db2 INGEST LIST
[詳細な進捗統計を表示]
db2 INGEST GET STATS FOR ID [ジョブID]
監視の重要ポイント:
NumRowsPreparedと NumRowsInsertedの乖離をチェックします。この差が大きい場合は、書き込み処理が CPU 不足や I/O 待ちでボトルネックになっていると判断できます。
5. リソース負荷を制御する運用パラメーター
■ INGEST の CPU 負荷を抑制する
書き込みスレッド（フラッシャー）数を制限し、CPU スパイクを抑えます。
-- 書き込みスレッドを 2 つに絞り、他業務への影響を抑える
db2 "INGEST FROM FILE data.csv FORMAT DELIMITED SET num_flushers 2 INSERT INTO MY_TABLE"
■ IMPORT のログ溢れを防止する
コミット頻度を上げ、ログの保持時間を短縮します。
db2 "IMPORT FROM data.csv OF DEL COMMITCOUNT 1000 INSERT INTO MY_TABLE"
まとめ：インフラ運用の判断基準
- CPU に余裕がある場合: INGEST を選択し、マルチスレッドの恩恵を最大化。
- メモリに余裕がある場合: IMPORT を選択。ただしバッファ・プールのヒット率低下に注意。
- リソースが逼迫している場合: INGEST で
num_flushersを制限し、低速ながら確実に投入する。
