- 1. SQL0668N 理由コード "1"
- 2. SQL0668N 理由コード "3"
- 3. SQL0668N 理由コード "7"
- 4. SQL0952N SQLSTATE=57014
- 5. SQL1477N
- 6. SQL1116N
- 7. SQL1655C
- 8. SQL20054N 理由コード "23"
- 9. SQL0901N 理由コード "1117"
- 10. SQL1035N SQLSTATE=57019
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
|
