[Db2] Java アプリケーションなどで SQL0805N (-805) エラーが返る (IM-10-00V)

SQL0805N は必要なパッケージがシステム・カタログに見つからなかったため、ステートメントを完了できないエラーを示します。
どのパッケージが要求されていたかによって対処方法が異なります。まずはエラーメッセージの情報を確認します。

1. ユーザーによって作成されたパッケージ (スキーマ名が NULLID や SYSIBMADM ではない) でエラーの場合、そのパッケージをバインドしてください。
2. Db2 のシステム・パッケージ (スキーマ名が NULLID や SYSIBMADM) でエラーの場合、よくある原因として以下 2 つのケースがあります。

ケース1: パッケージ名がSYSL[HY]xyyの場合
[エラー出力例]

• SQL0805N Package "SYSLH21E" not found.
  com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -805, SQLSTATE: 51002, SQLERRMC: DB2PROD.NULLID.SYSLH21E.5359534C564C3031;DISTSERV;04
  DB2 SQL error: SQLCODE: -805, SQLSTATE: 51002, SQLERRMC: NULLID.SYSLH21E

  注: CLI ベースのアプリケーションの場合、先に CLI レイヤーで定義されたハンドルの上限に達するため、同じ原因のエラーが CLI0129E (HY014) として報告されることがあります。

[原因]
アプリケーションでステートメント・ハンドルが不足した場合に出力されます。
CLI アプリケーションが利用可能なステートメント・ハンドルの数は、アプリケーションで定義されたラージ・パッケージの数に依存し、全体のシステム・リソースにより制限されます。
※ Data Server Driver for JDBC and SQLJ (JCC ドライバー) は CLI アプリケーションではありませんが、ステートメントを管理する際に CLI パッケージを利用します。

CLI パッケージをデフォルトオプションでバインドした状態では、分離レベルとカーソル属性ごとに 3 つのスモール・パッケージと 3 つのラージ・パッケージが作成されます。
各スモール・パッケージでは 1 つの接続につき最大で 64 のステートメント・ハンドルが許可され、各ラージ・パッケージでは 1 つの接続につき最大で 384 のステートメント・ハンドルが許可されています。
このため、1 つの接続がデフォルトで使用できるステートメント・ハンドルの数は、(3 * 64) + (3 * 384) = 1344 です。
ただし、位置指定更新用に各パッケージで 3 つのセクションが予約されているため、1326 を超えるハンドルを割り当てた時点で SQL0805N が返る可能性があります。

[対処方法]
多くの場合、ユーザー・アプリケーションでハンドル・リークを起こしていることが原因です。以下の順にご確認ください。
a） ステートメント・ハンドルのクローズを確認

アプリケーションの意図していない状態でエラーが発生する場合は、SQLを実行したステートメントがクローズされていない可能性があります。
例えば Java アプリケーションの場合には、Statement オブジェクト または PreparedStatement オブジェクトを使用し終えた後に close されているかを確認します。また、.NET アプリケーションの場合は Command オブジェクトが close (C#) や dispose (VB.NET) で適切に破棄されていることを確認します。
リソースの枯渇を防ぐため、それらのオブジェクトはクローズしてください。

<ステートメント・ハンドルのリークが発生する典型的な Java のコード例>
以下のようなソースコードの実装箇所がある場合、for ループの中に pStmt.close(); がないため、最後のステートメントハンドルしか解放されません。

• PreparedStatement pStmt = null;
  for (int i=1; i<=1400; i++) {
          pStmt = conn.prepareStatement("insert into T1 values (current timestamp)");
          pStmt.execute();
  }
  pStmt.close();

以下のように修正してハンドルリークを解消できます。

• PreparedStatement pStmt = null;
  for (int i=1; i<=1400; i++) {
      pStmt = conn.prepareStatement("insert into T1 values (current timestamp)");
      pStmt.execute();
      pStmt.close()
  }

また、例外やエラーが発生すると、ステートメントをクローズする通常のコードを通らないことがあるので、例外/エラーの場合もステートメントがクローズされるように配慮してください。
リークの例で示されるように、ステートメント・ハンドルのリークは Db2 サーバーからは判別できません。この例を Db2 サーバーから見ると単一のステートメントを繰り返し実行しているだけに見えるからです。
リークの原因調査が必要な場合、アプリケーション側で JDBC トレースなどを採取する必要があります。

b） 数千のステートメントをキャッシュする要件がある場合

リークを解消するためにアプリケーションの修正をすぐに実施できない場合、もしくはステートメント・ハンドルを正しくクローズしてもデフォルトのパッケージ数では不足する要件がある場合、新たに CLI パッケージをバインドして上限を引き上げられます。
ただし、数千ものステートメントをキャッシュすると、サーバー側でパッケージ・キャッシュやアプリケーション・ヒープに追加のリソースが必要になる可能性があります。

<実行例>
デフォルトのパッケージ数で不足する場合は、以下コマンドで追加の CLI パッケージをバインドします。

1. サーバーにログインし、sqllib/bnd ディレクトリーに移動します。
2. データベース管理者でデータベースに接続し、以下のコマンドを実行します。

   ​​db2 CONNECT TO <dbname>
   db2 BIND @db2cli.lst BLOCKING ALL GRANT PUBLIC CLIPKG 4

また、Db2 CLI/ODBC 初期設定ファイル (db2cli.ini) の CLI/ODBC 構成キーワード CLIPKG 値をバインドされた数と同じ値に設定してください。

1. クライアントコンピュータにクライアントインスタンス・オーナーでログインします。
2. Db2 コマンド行プロセッサーで以下のコマンドを実行します。

   db2 update cli cfg for section <dbname> using CLIPKG 4

追加パッケージのバインドについては以下のマニュアル・ページもご参照ください。
CLIPkg CLI/ODBC 構成キーワード
BIND コマンド

ケース2: パッケージ名がSQL***の場合
[エラー出力例]

• SQL0805N Package "SQLUFH13" not found.

[原因]
データベースの作成またはアップグレード時、またはフィックスパックのサーバーへの適用時に、データベース・ユーティリティーと DB2 CLI バインド・ファイルのバインディングは自動的に行われます。
何らかの操作によりパッケージがドロップされてしまっていたことが考えられます。
また、クライアントにフィックスパックを適用した場合や、クライアントをアップグレードした場合、古いレベルのクライアントを追加した場合などは、クライアントに含まれるパッケージを明示的に接続先データベースへバインドする必要があります。(サーバーと異なるバージョンまたはフィックスパックのクライアントは、データベースにバインドされていないパッケージを要求する可能性があるためです。)

[対処方法]
データベース・ユーティリティーと Db2 CLI バインド・ファイル (db2clist.bnd または db2cli.lst など)、db2schema.bnd バインド・ファイルを手動で再度バインドしてください。バインド・オプションに ACTION ADD を指定しているため、データベースにすでにバインドされているパッケージには影響を与えません。

なお、db2schema および db2cli, db2ubind はバインド・ファイルの場所が異なります。
db2schema はサーバー側、db2cli, db2ubind はクライアント側でバインドする必要があります。

[実行例]
サーバー

1.  サーバーにログインし、sqllib/bnd ディレクトリーに移動します。
2. データベース管理者でデータベースに接続し、以下のコマンドを実行します。

   db2 CONNECT TO <dbname>
   db2 BIND db2schema.bnd BLOCKING ALL GRANT PUBLIC SQLERROR CONTINUE
   db2 BIND @db2ubind.lst BLOCKING ALL GRANT PUBLIC ACTION ADD
   db2 BIND @db2cli.lst BLOCKING ALL GRANT PUBLIC ACTION ADD

   注: db2ubind.lst および db2cli.lst はサーバーコンピュータで実行されるローカルクライアントのためにバインドします。

クライアント

1. クライアントにログインし、sqllib/bnd ディレクトリーに移動します。
2. データベース管理者でデータベースに接続し、バインドを実行します。

   db2 connect to <dbname> user <username> using <password>
   db2 BIND @db2ubind.lst BLOCKING ALL GRANT PUBLIC ACTION ADD SQLERROR CONTINUE
   db2 BIND @db2cli.lst BLOCKING ALL GRANT PUBLIC ACTION ADD SQLERROR CONTINUE

   注: 各データベースに対して、フィックスパック・レベルが異なる各クライアントからバインドする必要があります。注: クライアントとサーバーのバージョンが異なる場合、クライアントのパッケージが参照するオブジェクトがサーバーに無いなどの理由で、バインドのエラーは予期されています。このエラーは問題ではないので SQLERROR CONTINUE オプションを付与してバインド可能なものをバインドしてください。
   注: クライアントの種類が多い場合や、クライアントが遠隔地に存在するなどの理由で、各レベルのクライアントにログインしてクライアントのパッケージをバインドする作業が困難な場合、以下の Technote がらクライアントのバージョンと一致したパッケージをサーバーにダウンロードして、サーバーでバインド作業を実施できます。
   Download bind files for Db2 11.5, 11.1, and 10.5 fix packs
   パッケージ名についてはマニュアルの以下のページを参照してください。
   Db2 CLI のバインド・ファイルおよびパッケージ名

運用上の考慮点
ケース1: 対処方法の b）では、より多くの CLI パッケージをバインドすれば上限は引き上げられますが、サーバー上にも不要なリソースを確保することになります。このため、必要に応じて妥当性を再度検証することを推奨します。

ケース2 でシステム・パッケージを正しくバインドしなかった場合、SQL0805N だけでなく SQL0551N や SQL0552N が返ることがあります。
バインドを行っていない状態でパッケージを呼び出し、暗黙的なバインド要求が成功した場合はエラーが返りませんが、暗黙的なバインド要求を行ったユーザーと別のユーザーが同じパッケージを呼び出すと SQL0551N になります。
また、BIND 特権を持っておらず、暗黙手的なバインド要求が失敗した場合は SQL0552N が返ります。
特に暗黙的なバインド要求が成功してしまっているケースでは、予期しない EXECUTE 特権がパッケージに付与されているため、問題を修正するために ACTION ADD でなく ACTION REPLACE で明示的にシステム・パッケージを BIND する必要があります。

関連情報
パスポート・アドバンテージによく寄せられる質問
DB2 v11.5 Bind File and Package Name List
SQL0805N - Package NULLID.SYSLH21E was not found.
フィックスパックのインストール後のバインド・ファイルのバインディング

お問合せ先
技術的な内容に関して、パスポート・アドバンテージの契約のもと Db2 テクニカル・サポートへお問い合わせください。
Db2 テクニカル・サポート