Db2「SQL0289N 表スペースに新しいページを割り当てられません」の原因を切り分ける

一括ロードや大きめのINSERTの途中で処理が止まり、次のエラーが返ることがあります。

SQL0289N  Unable to allocate new pages in table space "USERSPACE1".  SQLSTATE=57011

SQL0289N は割り当て先の空きが尽きた状態です。メッセージには理由コードが付いていて、これで原因の大枠が決まります。自動ストレージ＋自動リサイズが既定の環境では、表スペースの設定ではなくその下のファイルシステムが満杯というケースが増えています。この記事ではまず見る値と、理由コードからの逆引きをまとめます。

まず見る（結論）

最初にやるのは「表スペースが満杯なのか、ディスクが満杯なのか」を分けることです。コンテナが載っているファイルシステムの空きを見ます。

SELECT VARCHAR(TBSP_NAME,18) AS TBSP, CONTAINER_TYPE,
       FS_TOTAL_SIZE, FS_USED_SIZE
  FROM TABLE(MON_GET_CONTAINER(NULL,-2)) AS T;

FS_USED_SIZE が FS_TOTAL_SIZE に張り付いていれば、原因はディスク側（理由コード10）です。空きがあるなら表スペース側の設定を見ます。自動リサイズが有効か、最大サイズはいくつかを一度に確認できます。

SELECT VARCHAR(TBSP_NAME,18) AS NAME, TBSP_TYPE,
       TBSP_TOTAL_PAGES, TBSP_USED_PAGES, TBSP_FREE_PAGES,
       TBSP_AUTO_RESIZE_ENABLED AS AUTORESIZE,
       TBSP_MAX_SIZE            AS MAX_SIZE
  FROM TABLE(MON_GET_TABLESPACE(NULL,-2)) AS T
 ORDER BY TBSP_USED_PAGES DESC;

AUTORESIZE=1 かつ MAX_SIZE=-1（上限なし）なら、表スペース側で止まる理由はありません。ほぼディスク側が原因です。

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

理由コード2・8は表スペースの設定の問題、10はディスクの問題です。ここを取り違えると、コンテナを足しても直らないという状況になります。

監視のアラートも、自動リサイズ環境では表スペース使用率ではなくファイルシステム使用率に張るほうが実態に合います。

もう1点、実機で確認した注意です。SYSCAT.TABLESPACES に MAXSIZE 列はありません（SQL0206N になります）。自動リサイズの最大サイズを見るときは MON_GET_TABLESPACE の TBSP_MAX_SIZE を使います。

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

理由コード別の抜け方、ADMIN_GET_STORAGE_PATHS でのストレージパス確認、溢れる前に気づくための監視クエリまで含めた詳しい解説は、Zennのフル記事にまとめています。

関連: SQL0964C トランザクションログがいっぱいです ／ Db2 リカバリー履歴ファイルとアーカイブログ削除

容量で止まらないための表スペース・ストレージグループの設計と、監視をどこに張るかを、本書 第2章「インスタンス・DB構成パラメーターの選定基準」で「なぜその値にするのか」から解説しています。