1. SQL0668N 理由コード "1"
テーブルにアクセスしようとしたら (SELECT なんですが)
SQL0668N 理由コード "1" のため、表 "テーブル名" に対する操作は許可されません。
というエラーが表示されてアクセスできませんでした。
sql で (Windows系であれば clpplus を起動)
SET INTEGRITY FOR テーブル名 IMMEDIATE CHECKED;
とやるとアクセスできるようになるようです。
2. SQL0668N 理由コード "3"
前項と同じ状況で、理由コードが "3" のときは、データベースのリストアの直後であったり、テーブルのデータをロードしている途中に処理を中止したり、データベースを停止したりすると発生する状態です。
ロードペンディングという状態になっています。
もし、ロード途中で停止したようなときは、ロードの処理を完了する必要があります。
ロードペンディング状態のテーブルは、データベースに「CONNECT」して、以下の「SQL」で調べることができます。
db2 "SELECT VARCHAR(TABSCHEMA,30) TABSCHEMA,VARCHAR(TABNAME,30) TABNAME, LOAD_STATUS, NO_LOAD_RESTART FROM SYSIBMADM.ADMINTABINFO WHERE LOAD_STATUS <> 'NULL'"
結果は以下のような形式で表示されます。
TABSCHEMA TABNAME LOAD_STATUS NO_LOAD_RESTART
------------------------------ ------------------------------ ------------ ---------------
スキーマ名 テーブル名 PENDING N
リストアやロードが完了している状態であれば、データベースに「CONNECT」して
db2 ROLLFORWARD DB データベース名 TO END OF LOGS AND STOP
で完了させてやれば、アクセスできるようになります。
3. SQL0668N 理由コード "7"
テーブルにアクセスしようとしたら
SQL0668N 理由コード "7" のため、表 "テーブル名" に対する操作は許可されません。
というエラーが表示されてアクセスできないときがあります。
この現象は、たいてい対象のテーブルに対して「ALTER TABLE」等で変更をかけた後に発生します。
「sql」で (「Windows」系であれば「clpplus」を起動)
REORG TABLE テーブル名 INDEX インデックス名;
を行うと解消します。
4. SQL0952N SQLSTATE=57014
「割り込みにより、処理が取り消されました」って書いています。
大概、「SELECT」で、データが大量にあるために、データ取得がタイムアウトエラーになっております。
クライアント側で、タイムアウト時間を調整できるのであれば、できるだけ長い時間に調整します。
5. SQL1477N
テーブルにアクセスしようとしたら
SQL1477N 表 "テーブル名" で、表スペース "テーブルスペース番号" 内のオブジェクト "オブジェクト番号" にはアクセスできません。
というエラーが表示されてアクセスできませんでした。
「巨人 IBM」のサイトで、あれこれ能書きを垂れていますが、どうららテーブルをドロップして作成しなおすしかなさそうです。
もし、同一のテーブル構成を持っている他のデータベースが存在するならば「テーブルをコピーする」の手順でどうぞ。
6. SQL1116N
「Windows」の「DB2」サーバで「DB2 コマンドウィンドウ - 管理者」から「db2 connect」しよううとするとエラーになりました。
C:¥ db2 connect to データベース名
SQL1116N データベース "データベース名" は BACKUP PENDING 状態になっているため。そのデータベースへの接続、またはそのデータベースのアクティブ化は失敗しました。 SQLSTATE=57019
これは、一度、データベースのバックアップをとると解消します。
データベースのバックアップについては「バックアップ・リストア」を参照してください。
7. SQL1655C
テーブルにアクセスしようとすると
SQL1655C ディスク上のデータ・アクセス・エラーのために、操作を完了できませんでした。
これが一番、始末が悪い状態です。
「巨人 IBM」のサイトを読んでも、ちっとも要領を得ません。
ものすごく運が良ければ、アクセス対象のテーブルを全件「DELETE」して、バックアップからインポートするだけで回復します。
次に運が良ければ、アクセス対象のテーブルをいったん「DROP」して、「CREATE」しなおしてバックアップからインポートすると回復します。
上記の方法で駄目な場合は、データベース全体を「DROP」して再構築する必要があります。
(このケースが非常に多いのですがね。なんてこった！ まあ試験用に「VMWare」上の試用版「Windows Server 2008R2」で試用版の「DB2」を動作させているのでどこにも文句も言えないし、そもそもそういう環境に問題があるのだといわれたらぐぅの音も出ないんですがね)
8. SQL20054N 理由コード "23"
スクリプトを作成して流していたらば
SQL20054N 表 "テーブル名" が無効な状態にあるため、操作できません。 理由コード = "23"
これ、スクリプトの方は
ALTER TABLE テーブル名 DROP COLUMN 列名;
を羅列してるだけなんですけどね。
調べてみると
「REORG」の推奨対象となる「ALTER」の実行回数が最大数に達しています。 「REORG」の推奨対象となる操作は最大 3 回まで許可されています。それに達したら 「REORG」を実行して、現在のスキーマと一致するよう表の行を更新しなければなりません。
とのこと。
ちょこちょこ 「REORG」を挟まなければ (3行に1回？) ならないようです。
よくわからないのは
ALTER TABLE テーブル名 ADD COLUMN 列名 ...;
の方は、数十行、一気に実行してもエラーにならないんですよね。首尾一貫しない「DB」ですこと。
9. SQL0901N 理由コード "1117"
バックアップ時に発生しました（2020年2月10日）。
C:\Program Files\IBM\SQLLIB\BIN>db2 BACKUP DATABASE データベース名 TO G:\DB2\フォルダ名 COMPRESS
SQL0901N データベース・システム・エラーのために SQL
ステートメントまたはコマンドが失敗しました。 (理由 "1117") SQLSTATE=58004
なんだか、久々だわ。
「巨人 IBM」さんのサイトに「[DB2 LUW] 静的 SQL が SQL0901N で失敗し、後続のほとんどの SQL も SQL0901N で失敗する (IM-10-00E)」（リンク切れになりました）てな記事がありました。
まぁ、こういうとこの説明は、ほとんどわけのわからない説明でしかないんですけどね。
書いてある理由もあてにならんというか、おぬしの提供しているバックアップコマンドを利用しているだけなんだぞってことなんですけど。
「パッケージ・キャッシュに残った不正なセクション・エントリーをクリアするために、データベースを非活動化/再活動化してください。」って書いてあるので、「db2stop」「db2start」を実行しても再度発生しました。
もうひとつ、「『PCKCACHESZ』を増やす」って書いてあるんで、やってみますか。
DB2 UPDATE DB CFG FOR <DATABASE> USING PCKCACHESZ <値(単位 4KB ページ)>
って書いてあるんですけど。
「巨人 IBM」も馬鹿ですねぇ。
先に、その調べ方も載せておくのが常道でしょ。
パラメータを調べるのは、別のページにも載せていますが、ここにも載せます（これが常道）。
db2 CONNECT TO データベース名
db2 GET DATABASE CONFIGURATION
db2 DISCONNECT データベース名
で、
パッケージ・キャッシュ・サイズ (4KB) (PCKCACHESZ) = AUTOMATIC(21459)
ということがわかりました。
およそ 1.5 倍ということで「32768」にしてみますか。
DB2 UPDATE DB CFG FOR <DATABASE> USING PCKCACHESZ 32768
これで、もう一度、やってみます。
10. SQL1035N SQLSTATE=57019
前項の問題が解決しないうちに・・・。
C:\Program Files\IBM\SQLLIB\BIN>db2 BACKUP DATABASE データベース名 TO G:\DB2\フォルダ名 COMPRESS
SQL1035N 要求されたモードでは指定されたデータベースに接続できないため、操作が失敗しました。 SQLSTATE=57019
え～ん。なんだこれ？
「データベースに接続していないにも関わらず、BACKUP DATABASE コマンドが SQL1035N で失敗する原因 - Forums - IBM Support」に、回答らしきものがありました。
エラーの原因としてデータベースが非活動化されていない可能性がございます。
データベースが ACTIVATE DATABASE コマンドにて明示的に活動化されている場合、TERMINATE コマンド や FORCE APPLICATION コマンドにて接続を切断しても、データベースは非活動化されません。
データベースが活動化されているかどうかは以下のコマンドにてご確認いただけます。
とあって、コマンドが書いてありますので、実行してみます。
C:\Program Files\IBM\SQLLIB\BIN>db2 list active databases
アクティブ・データベース
データベース名 = <DATABASE>
現在のアプリケーション接続 = 2
データベース・パス = D:\DB2\NODE0000\SQL00001\MEMBER0000\
あら、接続している人がいるということね・・・。
で、はたと気づく、自分自身が接続しているのであった（← 馬鹿）。
切断して、実行したら、この現象は出ませんでした。
コピペできるように、プロンプトなしで、コマンドだけ、切り出しておきます。
db2 list active databases
11. SQL0289N SQLSTATE=57011
プログラムから、テーブルへ「INSERT」しようとしたらこんなえらーが出ちゃいました。
メッセージが
[57011] [IBM][DB2/NT64] SQL0289N 表スペース "XXXX" の新規ページを割り振れません。
てな感じであります。
これは、厄介なことになりそうです。
詳細は、以降のページに記述しますので「目次」よりご参照ください。
12. SQL1144N sqlcode: "-964"
テーブルのプライマリキーを変更しようとして、「clpplus」で下記の「SQL」を流していたときのことです。
ALTER TABLE テーブル名 DROP PRIMARY KEY;
ALTER TABLE テーブル名 ADD CONSTRAINT キー名 PRIMARY KEY (カラム１, カラム２, カラム３);
まぁ、いささか大きいテーブルでしたが、２行目は時間がかかりますわな。
時間がかかったあげくに。
行 xx の近くでエラー:
SQL1144N 現行トランザクションは、索引の作成が失敗したためにロールバックされました。原因 sqlcode: "-964"。関連付けれたトークン:
""。
てなことになりました。
調べてみると。
SQL1144N 現行トランザクションは、索引の作成が失敗したためにロールバックされました。原因 sqlcode: sqlcode。
説明
同じトランザクションで、最後に残った表の索引がドロップされ、 同じ表について新しい索引が作成されました。 この索引の作成は、エラー sqlcode で失敗したか、または ROLLBACK TO SAVEPOINT ステートメントによりロールバックされました (sqlcode=0)。 最後に残った表の索引の索引ドロップがまだコミットされていない場合、 索引作成のロールバックは、正常に完了できません。 このいずれの場合も、 トランザクション全体がロールバックされます。 索引は、ALTER TABLE ステートメントの ユニーク・キーまたは主キーの制約をドロップまたは追加しても、 作成またはドロップできる点に留意してください。
Exception: DB2 SQL error: SQLCODE: -964, SQLSTATE: 57011, SQLERRMC: null のトラブルシューティング
最終更新: 2021-03-04
データベースの更新操作時に、次のようなエラーが発生する場合があります。Exception: DB2 SQL error: SQLCODE: -964, SQLSTATE: 57011, SQLERRMC: null。このエラーは、トランザクション・ログ・スペース不足、またはアクティブなトランザクション数の一時的な増加などが原因で発生する場合があります。
また、「トランザクションログがフル」ですわ。
結局、いったんテーブルのデータをエクスポートして、プライマリキー・テーブルもろとも削除して、あたらしいキー構成で作成して、データをインポートするしかないようです。
そもそも、大きいテーブルだからこうなったわけで、エクスポート・インポートにも気の遠くなるような時間がかかるわけです。
つらいわぁ。
