〜EXPLAINテーブルの扱いと SQL3201N / SQL0530N の正しい理解〜
本番環境から開発環境へ Db2 のデータを移行する際、EXPORT / IMPORT を使ってテーブルデータをコピーするケースは多いと思います。
しかし、その中でも explain_instance や explain_statement といった EXPLAIN 関連テーブルを移行しようとすると、以下のようなエラーが発生することがあります。
- SQL3201N
- SQL0530N
この記事では、これらのエラーがなぜ発生するのか、無視してよいのか、そもそも EXPLAIN テーブルを移行すべきなのかを、実務目線でわかりやすく解説します。
- 発生したエラーの意味
◆ SQL0530N：外部キー制約違反
SQL0530N は 「外部キーの参照整合性が取れないため INSERT が拒否された」 というエラーです。
EXPLAIN テーブルは内部的に相互参照しているため、
本番環境で生成された EXPLAIN データを開発環境へ持ち込むと 参照整合性が崩れやすく、SQL0530N が発生するのは自然 です。
◆ SQL3201N：IMPORT 時の一般的なエラー
SQL3201N は IMPORT/LOAD 時に
「指定したデータを取り込めない」
という汎用的なエラーです。
EXPLAIN テーブルは Db2 が内部的に利用するワークテーブルであり、構造や内容が環境依存のため、移行時にエラーが出ることは珍しくありません。
- explain_* テーブルは移行すべきか？
◆ 結論：移行しなくてよい（むしろ移行してはいけない場合が多い）
理由は以下の通りです。
- EXPLAIN テーブルは アクセスプラン解析用のワークテーブル
- 本番と開発では データ量・統計情報・インデックス構成が異なるため、アクセスプランも異なる
- 本番の EXPLAIN 結果を開発に持ってきても 意味がない
- バージョン差や構成差で 構造不一致が起きやすい
つまり、EXPLAIN テーブルはデータ移行の対象外 と考えるのが正しい運用です。
- エラーは無視してよいのか？
◆ はい、無視して問題ありません。
EXPLAIN テーブルは移行対象ではないため、
IMPORT 時に SQL3201N や SQL0530N が出ても 実害はありません。
- 代わりに行うべき正しい手順
◆ ① 開発環境で EXPLAIN テーブルを再作成する
Db2 には EXPLAIN テーブルを自動生成するスクリプトが用意されています。
例（Linux/Unix）
db2 -tvf ~/sqllib/misc/EXPLAIN.DDL
これにより、開発環境に その環境に適した EXPLAIN テーブル が作成されます。
◆ ② 開発環境で必要な SQL に対して EXPLAIN を実行する
EXPLAIN PLAN FOR
その後、db2exfmt などでアクセスプランを確認できます。
◆ ③ 統計情報（RUNSTATS）は本番→開発でコピーしない
本番の統計情報を開発に持ち込むと、
実際のデータ量と乖離し、誤ったアクセスプランが生成される ため非推奨です。
開発環境では以下を実行するのが一般的です。
RUNSTATS ON TABLE WITH DISTRIBUTION AND SAMPLED DETAILED INDEXES ALL;
- まとめ：Db2 のデータ移行で覚えておくべきポイント
項目 結論
explain_instance / explain_statement の移行 不要
SQL3201N / SQL0530N の扱い 無視してよい
EXPLAIN テーブルの正しい準備方法 開発環境で再作成する
本番の EXPLAIN 結果を開発へ移行 非推奨
統計情報の移行 非推奨（開発で RUNSTATS 実行）
Db2 のデータ移行では、EXPLAIN テーブルを誤って移行しようとしてエラーに悩むケースが非常に多いです。
しかし、これらはそもそも移行対象ではなく、開発環境で再生成するのが正しい運用です。
WORDPRESS初心者のIT雑記 