Db2「SQL0668N 操作は許可されません」を理由コードで切り分ける ― LOAD後・ALTER後に表が触れないとき

一括ロードや ALTER TABLE のあと、その表に触ろうとすると次のエラーで弾かれることがあります。SELECT すら通らないことがあります。

SQL0668N  Operation not allowed for reason code "3" on table "MYSCHEMA.SALES".  SQLSTATE=57007

SQL0668N は表が壊れたのではなく、一時的に制限状態に入っているだけです。ただし理由コードごとに抜け方がまったく違います。「ログ保留だから REORG」と決め打ちすると、実体が LOAD の失敗だった場合は一生抜けられません。この記事では理由コードから正しい対処へ一直線で進むための逆引きをまとめます。

まず見る（結論）

メッセージの理由コードを読みます。これで表の状態が一意に決まります。裏を取りたいときは SYSCAT.TABLES の3列を見ます。

SELECT VARCHAR(TABNAME,20) AS TAB,
       STATUS,                       -- N=通常 / C=check pending / X=inoperative
       ACCESS_MODE,                  -- F=全アクセス可 / N=不可 / R=読取のみ
       SUBSTR(CONST_CHECKED,1,8) AS CONST_CHECKED
  FROM SYSCAT.TABLES
 WHERE TABSCHEMA = 'MYSCHEMA' AND TYPE = 'T';

制限のない表は STATUS='N' / ACCESS_MODE='F' / CONST_CHECKED が全て Y です。LOAD 絡みが疑わしいときは LOAD QUERY が確実です。

db2 "LOAD QUERY TABLE MYSCHEMA.SALES"

Load pending / Load in progress / Normal のどれかが返ります。

症状 → 原因 → 対処（逆引き）

理由コード3は REORG でも SET INTEGRITY でも抜けられません。LOAD の後始末が必要です。逆に理由コード1・4に REORG を打っても解決しません。

SET INTEGRITY を流すときは順序にも注意します。親表を通しても、依存するMQTや従属表が保留のまま残ることがあります。保留中の表は SYSCAT.TABLES の STATUS='C' で一覧できるので、親から子の順に流します。

それでも切り分からないとき（実機ログつきの詳解）

理由コード別の抜け方、例外表を使った SET INTEGRITY の通し方、実機での状態確認ログまで含めた詳しい解説は、Zennのフル記事にまとめています。

関連: Db2 IMPORT vs INGEST ／ TRUNCATE 時の参照制約に注意

LOAD失敗の後始末や制限状態からの復帰のような、マニュアルを引いても手順の順序までは分からない場面を、本書 第12章「現場の難題・解決集」に実例で集めました。