事例
Db2のdiag.logで今まで見たことないWarningが出力されていた。どうやらOS上でシステム時刻変更した際に発生するようだ。
「SQLCODE=-101 SQLSTATE=54001」が発生した。 バッチ処理でINSERTを何万回とやってる途中で本エラーとなった。「SQLが長すぎる」というエラーメッセージだが、直前までのINSERTとは値が異なるだけである。 diag.logを確認すると以下のような文言が出ていた。
"Statistics heap size too small to begin with" DIA8328C No memory available in the statistics heap.
原因はSTMTHEAPが不足しているらしい。STMTHEAPはSQLをコンパイルするためのワークスペース。PreparedStatementを使用していなかったのも問題だったようだ。とりあえず設定値を確認してみる。
db2 GET DB CFG FOR ${database_name}
AUTOMATIC設定だが、自動拡張できなかったようだ。以後、select文などを実行してもエラーになるだけだったが、再起動したら直った。
推測だが、メモリを拡張しようとしたときに、裏でメモリを食うような処理をしていると、拡張できないと判定され、以後拡張してくれなのではないかと思う。
PreparedStatement化するかLOADコマンドにしたほうがいいだろう。手っ取り早い対応は実メモリを上げることだと思うが。
突然、DB2コマンドラインプロセッサも立ち上がらなくなり、 A5:SQL Mk-2 やObject BrowserからもDB2へ接続できなくなった。 原因は、コンピュータ名を変更したことだった。 レジストリを変更して対応することができた。
SELECTでロックする?
多重負荷でSELECTしかやってないのに、なぜかロックした。 どうやら、TABLEの作り直しによって、VIEWが無効化していたらしい。 VIEWに対するSELECTで「有効化」にUPDATEされるが、後続もUPDATEしようとしてロック待ちするようだ。
VIEWの状態を調べる。VALIDが'N'になっているものが無効状態。
SELECT * FROM SYSCAT.VIEWS
ビューを有効化する。
CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS('view', '${スキーマ名}', '${ビュー名}')