DB2 データベースへのデータ・アクセスの問題

この項目では、DB2® データベースにアクセスする際のトラブルシューティングのヒントを提供しています。

DB2 データベースへのアクセス時に、どのような問題が発生しましたか?

データベースとの接続中に Kerberos ログイン・エラーが発生する

以下のシナリオのリストを使用している場合は、データベースとの接続試行中に Kerberos ログイン・エラーが発生します。
  1. Enterprise JavaBeans (EJB) 3.0 Bean 内の注入ステートメントが属性レベルにある。
  2. persistence.xml ファイルによって、接続先のデータベースに関するメタデータ情報がコールアウトされない。
  3. データ・ソースのコンポーネント管理別名が無効である。
  4. データベースが、Kerberos のような 1 回限りのセキュリティー・メカニズム (例えば、ユーザー ID とパスワードを用いる標準的なメカニズム以外のメカニズム) を使用するようセットアップされている。

Java Persistence API (JPA) の persistence.xml ファイルは、EJB 3.0 Bean の注入中にメタデータを検索するためにデータベースに接続しようとします。接続を行うために、Java™ 2 コネクター (J2C) がセキュリティー・コンテキストにサブジェクトを要求します。このシナリオでは、情報をセキュリティー・コンテキストに挿入するために呼び出されるセキュリティー・コラボレーション API が呼び出されなかったため、サブジェクトは GSSCredential を含まないまま戻されます。

この呼び出しは EJB コンテナーで行われる必要がありましたが、セキュリティー API が、存在していない完全構成済みの Bean を要求しているため、EJB コンテナーによってコラボレーション API が呼び出されませんでした。また、EJB 3.0 仕様では、Bean の構成を、定義済みのセキュリティー・コンテキスト内で行ってはいけないことが明示的に規定されています。 セキュリティー API の設計と、このような EJB 3.0 仕様の指示により、EJB コンテナーではセキュリティー・コラボレーション API が呼び出されませんでした。セキュリティー・コンテキストはサブジェクトをセットアップすることを認識しなかったため、GSSCredential が存在しませんでした。

GSSCredential が存在しないと、Relational Resource Adapter (RRA) の実装で間違ったコード・パスが使用されます。この実装は、DB2 に GSSCredential を使用して接続するよう指示する代わりに、コンポーネント管理別名に関連付けられている ID を使用します。その結果、コンポーネント管理別名は、Kerberos に認識されない ID となるように構成されるため、DB2 ドライバーがこの ID をデータベースに中継したときにエラーが発生しました。

このエラーの例を次のコードで示します。
Caused by: javax.security.auth.login.FailedLoginException: Login error: com.ibm.security.krb5.KrbException, status code: 6
		message: Client not found in Kerberos database
		at com.ibm.security.jgss.i18n.I18NException.throwFailedLoginException(I18NException.java:25)
		at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:733)
		at com.ibm.security.auth.module.Krb5LoginModule.c(Krb5LoginModule.java:610)
		at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:433)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
		at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
		at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
		at java.lang.reflect.Method.invoke(Method.java:599)
		at javax.security.auth.login.LoginContext.invoke(LoginContext.java:795)
		at javax.security.auth.login.LoginContext.access$000(LoginContext.java:209)
		at javax.security.auth.login.LoginContext$4.run(LoginContext.java:709)
		at java.security.AccessController.doPrivileged(AccessController.java:251)
		at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:706)
		at javax.security.auth.login.LoginContext.login(LoginContext.java:603)
		at com.ibm.db2.jcc.a.ud.a(ud.java:25)
このエラーを回避するには、以下の推奨事項に従ってください。
  • 注入ステートメントが「クラス・レベル」にあることを確認します。

    これにより、Bean の作成時に注入が行われなくなります。 パーシスタンス・コンテキスト項目は引き続き Java Naming and Directory Interface (JNDI) に保管されますが、これらの項目は Bean オブジェクトのローカル変数には配置されません。Bean メソッドは JNDI のこれらのパーシスタンス・コンテキスト項目を検索します。この時点では、EJB コンテナーによってセキュリティー・コラボレーション API が呼び出されているため、この Bean は正しいセキュリティー・コンテキストで実行されます。

  • persistence.xml ファイルでデータベースのメタデータ情報がコールアウトされるようにします。

    必要なデータベースのメタデータ情報が persistence.xml ファイルによってコールアウトされる場合でも、JPA では、その情報を取り出すためにデータベースに接続する必要はありません。つまり、Bean メソッドへのアクセスが行われるまでは、接続は行われません。このステップにより、セキュリティー・コンテキストが正しくセットアップされ、接続が正常に機能します。

  • データ・ソースのコンポーネント管理別名を検査します。

    JPA がメタデータを収集するためにデータベースに接続しようとした場合、セキュリティー・コンテキストが構成されていないため、ドライバーは、データ・ソースに設定されているコンポーネント管理別名を再度使用します。コンポーネント管理別名が検査されるようにすると、接続は成功します。

  • データベース・セキュリティーに 1 回限りのセキュリティー・メカニズムを使用しないでください。

    Kerberos などの 1 回限りのセキュリティー・メカニズムを使用する場合、この項目は該当しません。データベースが標準的なユーザー ID とパスワードによる認証を受け入れるよう構成されていない場合は、この問題は発生しません。この問題は、システムが特殊なセキュリティー構成を必要とする場合にのみ発生します。

SQL0567N "DB2ADMIN" は無効な許可 ID です。SQLSTATE=42602

DB2 Universal Database™ (UDB) にアクセスしようとしてこのエラーが発生した場合は、 以下のようにします。
  1. 管理コンソール内のデータ・ソース・プロパティー・ページに入力されているユーザー名およびパスワードが正しいことを確認します。
  2. ユーザー ID およびパスワードの前後または途中にブランク文字が含まれていないことを確認します。

SQL0805N Package package-name was not found

この例外の原因としては、以下のことが考えられます。
DB2 Universal Database (UDB) 上でこの問題を訂正するには、 問題のデータベースに接続中に db2cmd インターフェースを使用して、次のように一回限りの手順を実行します。
  1. DB2 bind @db2ubind.lst blocking all grant public
  2. DB2 bind @db2cli.lst blocking all grant public

db2ubind.lst ファイルおよび db2cli.lst ファイルは 、DB2 インストール・ルートの bnd ディレクトリーにあります。 このディレクトリーからコマンドを実行します。

SQL0805N パッケージ「NULLID.SQLLC300」が見つかりません。SQLSTATE=51002

このエラーが発生する理由としては、次のようなものが考えられます。
  • 基礎となっているデータベースが除去され、再作成されました。
  • DB2 がアップグレードされましたが、そのパッケージが正しく再バインドされていません。

この問題を解決するには、bnd ディレクトリーにある db2cli.lst スクリプトを実行して、DB2 パッケージを再バインドします。 例: db2>@db2cli.lst

SQL30082N 接続確立の試行が、セキュリティー上の理由 「17」(UNSUPPORTED FUNCTION) により失敗しました SQLSTATE=08001

このエラーは、クライアントから指定されたセキュリティーのメカニズムが、このサーバーには有効でない場合に発生することがあります。いくつかの典型的な例を以下に示します。
  • クライアントが、パスワード変更機能に対応していないサーバーに、 新規パスワードの値を送信しました。
  • クライアントが、パスワード暗号化に対応していないサーバーに、 SERVER_ENCRYPT 認証情報を送信しました。
  • クライアントが、ユーザー ID のみによる認証に対応していないサー バーに、ユーザー ID (パスワードは送信しない) を送信しました。
  • クライアントが認証タイプの指定を行わず、サーバーがサポート対象 のタイプに応答しません。これは、クライアントが選択できない複数のタイプを戻すサーバーを含む場合があります。

この問題を解決するには、クライアントおよびサーバーが同じセキュリティー・メカニズムを使用しているかどうかを確認します。 例えば、これがユーザーのデータ・ソース上のエラーである場合、ユーザー ID とパスワードまたは認証別名の割り当てを行ったかどうかを確認します。

Java で ErrorCode -99,999、SQLState 58004 の SQLException が発生

WAS40 タイプのデータ・ソースを使用した際の、 ErrorCode -99,999 および SQLState 58004 の SQLException で、Java™ の "StaleConnectionException: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0119E Unexpected system failure. SQLSTATE=58004"

XA モード (2 フェーズ・コミット) で実行中に、 予期しないシステム障害が頻繁に発生します。 以下のような原因が考えられます。
  • 無効なユーザー名またはパスワードが入力された。
  • データベース名が間違っている。
  • なんらかの DB2 パッケージが破損している。
ユーザー名またはパスワードの問題があるかどうかを判別するには 、db2diag.log ファイルを参照して、実際のエラー・メッセージおよび SQL コードを表示してください。 SQLCODE -1403 を含む次のようなメッセージでは、無効なユーザー ID またはパスワードが示されます。
2002-07-26-14.19.32.762905   Instance:db2inst1   Node:000
PID:9086(java)   Appid:*LOCAL.db2inst1.020726191932
XA DTP Support  sqlxa_open   Probe:101
DIA4701E Database "POLICY2" could not be opened for distributed transaction processing.
String Title: XA Interface SQLCA  PID:9086 Node:000
SQLCODE = -1403
以下の方法で、これらの問題を解決します。
  1. ユーザー名とパスワードを訂正します。GUI でデータ・ソースのパスワードを指定する場合は 、Bean で指定するユーザー名とパスワードが正しいことを確認してください。 Bean で指定するユーザー名とパスワードは、 データ・ソースの作成時に指定されたものを上書きします。
  2. 正確なデータベース名を使用する。
  3. 以下のようにして、パッケージ (bnd ディレクトリーにある) を再バインドする。
    db2connect to dbname
    c:¥SQLLIB¥bnd>DB2 bind @db2ubind.lst blocking all grant public
    c:¥SQLLIB¥bnd>DB2 bind @db2cli.lst blocking all grant public
  4. ¥WebSphere¥AppServer¥properties¥wsj2cdpm.properties ファイルのユーザー ID とパスワードが正しいことを確認します。

エラー・メッセージ java.lang.reflect.InvocationTargetException: com.ibm.ws.exception.WsException: DSRA0023E

DB2 データベースにアクセスしようとすると、 エラー・メッセージ「java.lang.reflect.InvocationTargetException: com.ibm.ws.exception.WsException: DSRA0023E: DataSource 実装クラス "COM.ibm.db2.jdbc.DB2XADataSource" を検出できません。」が表示される

この例外の理由の 1 つとして、ユーザーが JDBC 2.0 データ・ソースを使用しようとしているものの、DB2 が JDBC 2.0 対応ではないことが考えられます。 この状況は、DB2 の新規インストールで頻繁に発生します。 これは、DB2 が同じ物理ファイル名を使用して JDBC 1.X と 2.0 に別々のドライバーを提供しているためです。デフォルトでは、JDBC 1.X ドライバーがクラスパス上に配置されています。

この問題を確認するには、以下を行います。
  • Windows システム上で、DB2 インストール・ルートにある java12 ディレクトリー内の inuse ファイルを探します。このファイルがない場合は、JDBC 1.x ドライバーが使用されています。
  • AIX® または Linux などのオペレーティング・システム上で、データ・ソースのクラスパスを確認します。 クラスパスが java12 ディレクトリー内の db2java.zip ファイルを指していない場合は 、JDBC 1.x ドライバーが使用されています。
以下の方法でこの問題を解決します。
  • Windows システムで、DB2 を停止します。DB2 インストール・ルートの java12 ディレクトリーから 、usejdbc2.bat ファイルを実行します。 コマンド行からこのファイルを実行して、正常に完了することを確認してください。
  • AIX または Linux などのオペレーティング・システム上で、DB2 インストール・ルート の java12 ディレクトリーにある db2java.zip ファイルを指すように、データ・ソースのクラスパスを変更します。

CLI0119E システム・エラー

DB2 Universal Database (UDB) データ・ソースにアクセスしようとしてこのエラーが発生した場合は、以下のようにします。
CLI0119E System error.  SQLSTATE=58004 -  DSRA8100 : Unable to get a XAconnection or DSRA0011E: Exception: COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] CLI0119E  Unexpected system failure. SQLSTATE=5800
  1. 管理コンソール内のデータ・ソース・プロパティー・ページで、データ・ソースに正しいデータベース名が指定されていることを確認します。
  2. カスタム・プロパティー・ページで、ユーザー名とパスワードのカスタム・プロパティーを確認します。 これらが正しいことを確認してください。
  3. ユーザー ID およびパスワードの前後または途中にブランク文字が含まれていないことを確認します。
  4. WAS.policy ファイルが、アプリケーション用に存在することを確認します (例えば、D:¥WebSphere¥AppServer¥installedApps¥markSection.ear¥META-INF¥was.policy)
  5. 基礎となる SQL エラー用の例外リスト全体を表示し、DBM ベンダーのメッセージ解説でそれを調べてください。

Red Hat Linux 上で DB2 の実行中にこのエラーが生じた場合は、max queues system wide パラメーターに指定されている値が低すぎるために、 DB2 が、トランザクションの完了に必要なリソース を獲得するときにそのサポートができないことを示します。この問題が生じると、例外 J2CA0046E および DSRA0010E に続いて、 例外 DSRA8100E が出されることがあります。

この問題を解決するには 、/proc/sys/kernal/msgmni ファイルを編集して 、max queues system wide パラメーターの値が 128 より大きい値にしてください。

COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N

この問題の原因はおそらく、 アプリケーションに起因する DB2 のデッドロックであり、 特に DB2 データ・ソースへアクセスするときに以下のようなエラーが表示された場合、これに該当します。
ERROR CODE: -911
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N
The current transaction has been rolled back because of a deadlock or timeout.
Reason code "2".  SQLSTATE=40001
問題を診断するには、以下のようにします。
  1. 以下の DB2 コマンドを実行します。
    1. db2 update monitor switches using LOCK ON
    2. db2 get snapshot for LOCKS on dbName >
    ここで、directory_name¥lock_snapshot.log には DB2 ロック情報が含まれます。
  2. db2 update monitor switches using LOCK OFF を実行して、モニターのロックをオフにします。
デッドロックがあるかどうかを確認するには、以下のようにします。
  1. ロック待機状況のアプリケーション・ハンドルを探してから、 ロックを保留しているエージェントの ID を探して、そのエージェントの ID を確認します。
  2. そのハンドルに移動し、そのハンドルがロック待機状況を持っているか、 およびそのハンドルに対するロックを保留するエージェントの ID を持っているかを確認します。 それが以前のものと同じエージェント ID である場合は、 循環ロック (デッドロック) であることが分かります。
この問題を解決するには、以下のようにします。
  1. アプリケーションを検査し、並行アクセスが必要でない場合は、制限の少ない分離レベルを使用します。
  2. accessIntent 値を変更して分離レベルを下げる場合は、注意して行います。 これを変更すると、データ保全性の問題が生じることがあります。
  3. DB2/UDB バージョン 7.2 以前のリリースの場合、Bean メソッド上で定義される accessIntent が極めて限定的である (例えば PessimisticUpdate など) 場合は、不要なデッドロックを排除するために DB2 コマンド行ウィンドウから DB2_RR_TO_RS フラグを設定することができます。DB@_RR_TO_RS を設定すると、以下のような 2 つの影響を与えます。
    • 選択した分離レベルが RR である場合、これは効果的に RS へとダウングレードされます。
    • 別の分離レベルを選択し、DB2_RR_TO_RS 設定をオンにすると、 スキャンは、削除済みでコミットされていない行は、スキャン対象であってもスキップします。 スキップ動作は、RR、読み取り固定 (RS)、およびカーソル固定 (CS) 分離レベルに影響を与えます。

    例えば、 トランザクション A が column1=10 の行を削除し、トランザクション B が column1>8 かつ column1<12 にスキャンを行うというシナリオがあるとします。 DB2_RR_TO_RS をオフにした場合、トランザクション B はトランザクション A がコミットまたはロールバックするまで待機します。 トランザクション A がロールバックすると、column1=10 の行は、トランザクション B の照会の結果セットに組み込まれます。 DB2_RR_TO_RS をオンにした場合、 トランザクション B はトランザクション A がコミットまたはロールバックするまで待機しません。 トランザクション B は、削除された行を含まない照会結果を即時に受け取ります。 DB2_RR_TO_RS を設定すると、ロック動作が効果的に変更され、 デッドロックが回避されます。

"COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource" がデータ・ソース ("[data-source-name]") に見つからない

このエラーは、メッセージ「DSRA8040I: DataSource への接続に失敗しました。」で表示されます。

このエラーは通常、DB2 JDBC Driver のクラスパスは 正しく ${DB2_JDBC_DRIVER_PATH}/db2java.zip に設定されているが、 環境変数 DB2_JDBC_DRIVER_PATH が設定されていない場合に生じます。

このエラーは、DB2 バージョン 7.1 または 7.2 を使用している場合、および usejdbc2 をまだ稼働していない場合に起こる場合があります。指定のパスは正しいにもかかわらず、このエラーが表示される場合は、問題が考えられます。

この問題を確認するには、以下を行います。
  1. 「WebSphere 変数の管理」ページに移動します。
  2. 環境」を選択して、 変数 DB2_JDBC_DRIVER_PATH のエントリーがないことを確認してください。

この問題を解決するには、 変数 DB2_JDBC_DRIVER_PATH の値を db2java.zip ファイルを含んでいるディレクトリー・パスに設定して、追加します。

[z/OS]

フィールドの 1 つにある 255 文字を超えるエンティティーについてパブリッシュまたは照会が行われようとしたときに、エラー 10500 (E_Fatal) が戻る

このエラーは通常、フィールドの 1 つにある 255 文字を超えるエンティティーについてパブリッシュまたは照会が行われようとしたときに起こります。 英語以外の文字が使用されている場合はあまりはっきりしません。255 文字が表示される前に本当の限界に達するからです。

この問題に対処するには、z/OS® で DB2 バージョン 7 を使う際の制限として受け入れるようにします。 255 文字の制限を越えないでください。

java.sql.SQLException: Failure in loading T2 native library db2jcct2 DSRA0010E: SQL State = null, Error Code = -99,999

「ロードに失敗しました (Failure in loading)」というメッセージは、以下のいずれかの問題があることを示しています。
  • DB2 のインストール後にマシンがリブートされなかった。エラーの発生したマシンをリブートし、やり直してください。
  • 構成済みのデータ・ソースとは異なるスコープを使用するデータベース操作が実行された。例えば、ttestConnection コマンドは、サーバー・レベルにあるデータ・ソースに対してはノード・レベルで実行されます。db2profile スクリプトを入手してマシンに配置し、DB2 のネイティブ・ライブラリーへのポインターが環境に含まれるようにします。db2profile スクリプトは、DB2 ユーザー ID のルート・ディレクトリーにあります。testConnection コマンドについて詳しくは、『テスト接続サービス』を参照してください。
  • WebSphere Application Server を稼働しているユーザーに対して、DB2 コンテキストが正常にセットアップされていません。db2profile スクリプトを入手してマシンに配置し、DB2 のネイティブ・ライブラリーへのポインターが環境に含まれるようにします。

データ・ソースの実装タイプが XA である場合に、データベースにロック競合例外が発生する

注: ロック競合例外は、 さまざまな要因により発生する場合がありますので、ロック競合問題が起こ りうる原因を除去する方針として、以下の説明および推奨される対応を 考慮してください。
症状 問題 説明 推奨される対応
ご使用のアプリケーションが実装タイプ XA のデータ・ソース経由でアクセスする DB2 データベースで、ロック競合例外が発生します。 ご使用のアプリケーションは、終了 (e) 状態にある XA トラン ザクションによりロックされているデータベース・レコードにアクセスしよ うとしていますが、トランザクション・マネージャーで準備済みにはできま せん。 終了するが、準備できない DB2 への XA トランザクションは、終了 (e) 状態になります。未確定なものは考慮されないため、トランザクション・マネージャーは、このトランザクションをリカバリーすることはできません。 DB2 はそのトランザクションを、未確定トランザクションのリストに戻しません。

DB2 はまた、トランザクションを即時にロールバックせず、データベースへのすべての接続が解除されるまで待機します。 この待機の間、トランザクションはデータベースのロック状態を保持し続けます。アプリケーション・サーバーがロールバックを 許可するデータベースからのすべての接続を切断するわけではない場合は、終了したトランザクションは、 同じデータベース・レコードをロックしたままの状態を維持します。 ご使用のアプリケーションが、これらのロックされたレコードにアクセス しようとすると、DB2 でロック競合例外が発生します。

DB2 バージョン 8.2 には、サンプル・アプリケーションが同梱されています。 このサンプル・アプリケーションは、定義済み DB2 サーバーに接続し、使用可能な DB2 API を使用して、これらの特定の終了済みトランザクションのリストを取得します。 アプリケーションでは、アプリケーションがこれらのトランザクションをロールバックするまでに経過する時間を指定できる構成設定が提供されます。 DB2 バージョン 8.2 の sqllib/samples/db2xamon.c ディレクトリーにあるサンプル・アプリケーションを見つけて、実行してください。

混合リリース・セルで DB2 Universal Datasource の使用を試みると、例外「DSRA8050W: 指定された DataStoreHelper クラスを検出できません」が発生する

このエラーは通常、 WebSphere Application Server バージョン 6.0 以降を旧バージョンと併用して使用し、DB2 Universal Datasource を旧バージョンで作成しようとした場合に発生します。

これは、DB2 Universal Datasource が、バージョン 5 およびそれ以前のバージョンで使用できないにもかかわらず、バージョン 6 の管理コンソールが作成を許可することが原因で発生する場合があります。

この問題を修正するには、バージョン 6.0 以降でデータ・ソースを作成します。

WebSphere Application Server もインストールされている Windows マシン上の DB2 にアクセスしようとして、エラー「'SYSTEM' は無効な許可 ID です」が発生

WebSphere Application Server もインストールされている Windows マシン上の DB2 にアクセスしようとしたときに、エラー「'SYSTEM' は無効な許可 ID です」というメッセージを受け取りました。

表 1. エラー・メッセージの説明と解決方法. 問題を解決するための 2 つのオプションがあります。
症状 問題 説明 推奨される対応
バックエンドとして DB2 を使用している Windows インストール上の WebSphere Application Server の場合、JVM ログ内に以下の例外が示されます。
java.sql.SQLException: [IBM][CLI 
Driver] SQL0567N "SYSTEM" is 
not a valid authorization ID.  
SQLSTATE=42602 DSRA0010E: SQL State = 42602, Error Code = -567
  at COM.ibm.db2.jdbc.app.
SQLExceptionGenerator.
throw_SQLException
  (Unknown Source)
  at COM.ibm.db2.jdbc.app.
SQLExceptionGenerator.
check_return_code
  (Unknown Source)
  at COM.ibm.db2.jdbc.app.
DB2Connection.connect
  (Unknown Source)
  at COM.ibm.db2.jdbc.app.
DB2Connection.<init>
  (Unknown Source)
  at COM.ibm.db2.jdbc.app.
DB2ReusableConnection.<init>
  (Unknown Source)
  at COM.ibm.db2.jdbc.
DB2PooledConnection.
getConnection  (Unknown Source)
  at com.ibm.ws.rsadapter.spi.WSRdbDataSource.getConnection(WSRdbDataSource.java:1035)
  at com.ibm.ws.rsadapter.spi.WSManagedConnectionFactoryImpl.createManagedConnection(WSManagedConnectionFactoryImpl.java:937)
  at com.ibm.ejs.j2c.
poolmanager.FreePool.
createManagedConnectionWithMC
Wrapper(FreePool.java:1502)
この例外は、WebSphere Application Server が DB2 サーバーのクライアントである構成の場合に発生します。 根本的な問題は、アプリケーションがユーザー ID およびパスワードを提供せずに DB2 に接続しようとしたときに、 Windows 上の WebSphere Application Server と、DB2 の間に発生する権限の競合です。 DB2 クライアントと DB2 データベースが同じマシン上で実行されているときは、DB2 はクライアントがユーザー ID およびパスワードなしで接続することを許可します。接続はクライアント・プロセスを所有するユーザーのクレデンシャルの下で行われます。この場合はアプリケーション・サーバー JVM です。 ただし、WebSphere Application Server が Windows サービスとして実行されていて、「ログオン (Log on as)」オプションが「ローカル システム アカウント」に設定されている場合は、アプリケーション・サーバー JVM は、SYSTEM と呼ばれる特定の Windows ユーザーのサブコンポーネントとしてカテゴリー化されています。 このユーザーは DB2 に接続することを許可されていないので、先に示した例外という結果になります。 以下の 2 つのオプションがあります。
  • WebSphere Application Server サービスを、「This account」の「Log on as」オプションを使用するように変更し、DB2 と接続するためのアクセス権を持つアカウントを提供します。または
  • コンテナー管理、またはコンポーネント管理の認証を使用して、DB2 接続上のクレデンシャルを提供するように、アプリケーション・サーバーを構成します。

1 フェーズ・トランザクション・ロールバック後の DB2 Universal JDBC Driver タイプ 4 での XA 準備呼び出しにおける XAException: XAER_NOTA

症状

DB2 v8.2 で使用可能な DB2 Universal JDBC Driver タイプ 4 XA を使用しているアプリケーションの場合、接続が失敗し、XAER_NOTA XAException エラーが発生する可能性があります。 以下のコード・ブロックは、この例外の例です。

J2CA0027E: An exception occurred while invoking prepare on an
 XA Resource Adapter from dataSource jdbc/SDOSVT, within
 transaction ID {XidImpl: formatId(57415344), gtrid_length(36), bqual_length(54),
  data(000000ff5191398200000001000000296cac5c42fe3c6838631cbaafc8b5a9253b846544
  000000ff5191398200000001000000296cac5c42fe3c6838631cbaafc8b5a9253b8465440000000
  10000000000000000000000000002)}:
javax.transaction.xa.XAException: XAER_NOTA
at com.ibm.db2.jcc.a.xb.a(xb.java:1682)
at com.ibm.db2.jcc.a.xb.a(xb.java:841)
at com.ibm.db2.jcc.a.xb.prepare(xb.java:812)
at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.prepare(WSRdbXaResourceImpl.java:837)
...

問題

AutoCommit が false に設定されたローカル・トランザクションなどの単一フェーズ・トランザクションで、 DB2 Universal JDBC Driver タイプ 4 XA 接続が使用されており、その単一フェーズ・トランザクションがロールバックされた場合、prepare 呼び出し上での、2 フェーズ・トランザクションにおける次の接続の使用は失敗します。

DB2 Universal JDBC Driver タイプ 4 XA サポートの問題により、 XA の prepare 呼び出しが失敗します。 この問題は、単一フェーズ・トランザクションがコミット済みである場合、および DB2 Universal JDBC Driver をタイプ 2 モードで使用している場合は発生しません。

解決策

DB2 バージョン 8.2 フィックスパック 1 にアップグレードします。これは、バージョン 8.1 フィックスパック 8 と同じです。これらのリリースで使用可能な Universal JDBC Driver XA により、前述のタイプ 4 モードでの問題が解決されます。

JDBC ドライバーのファイル・バージョンの非互換性により、アプリケーション・クライアントで java.rmi.MarshalException が記録される

症状

アプリケーション・クライアントを含むアプリケーションで、アプリケーション・サーバーのクライアント・ログ・ファイルに以下のエラー・メッセージが表示されます。

java.rmi.MarshalException: CORBA MARSHAL 0x4942f89a No; nested exception is:
org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Mismatched serialization
UIDs : Source (Rep.
IDRMI:com.ibm.db2.jcc.c.SqlException:63EEE52211DCD763:82CE0C0DA2B0A000)
 = 82CE0C0DA2B0A000 whereas Target (Rep. ID RMI:com.ibm.db2.jcc.c.SqlException:63EEE52211DCD763:91C6171BC645E41B)
= 91C6171BC645E41B  vmcid: 0x4942f000  minor code: 2202  completed: No 

問題

アプリケーション・クライアント・マシンおよびご使用のアプリケーション・サーバー上の db2jcc.jar ファイルが、相互に互換性のないバージョンの DB2 のものか、データ・ストアとして機能するバージョンの DB2 と互換性がありません。

解決策

アプリケーション・クライアント・マシン、ご使用のアプリケーション・サーバー、およびご使用の DB2 サーバー上の db2jcc.jar ファイルを確認します。 クライアント・マシンおよびアプリケーション・サーバー上では、 DB2 サーバーと互換性のある同じバージョンのファイルをインストールします。

データベース障害によって、DB2 Universal Driver タイプ 4 を使用するアプリケーションで問題になる -99999 例外が引き起こされる

症状

DB2 Universal Driver タイプ 4 を使用して DB2 Network Server へのアクセスを試み、データベースが障害を起こした場合、データベース・サーバーがすべての JDBC getConnection 要求に対して 汎用 -99999 例外を出します。以下のコードの抜粋で例が示されているこの例外は、アプリケーションで予期しない振る舞いを引き起こす可能性があります。

java.sql.SQLException: IO Exception opening socket to
		server bs8.rchland.ibm.com on port 1527.
The DB2 Server may be down.DSRA0010E: SQL State = null,
		Error Code = -99,999DSRA0010E: SQL State = null,
Error Code = -99,999
at com.ibm.db2.jcc.b.a.<init>(a.java:125)
at com.ibm.db2.jcc.b.b.a(b.java:1011)
at com.ibm.db2.jcc.c.l.<init>(l.java:197)
at com.ibm.db2.jcc.b.b.<init>(b.java:258)
at com.ibm.db2.jcc.DB2PooledConnection.
	<init>(DB2PooledConnection.java:44)
at com.ibm.db2.jcc.DB2ConnectionPoolDataSource.getPooledConnectionX
		(DB2ConnectionPoolDataSource.java:80)
at com.ibm.db2.jcc.DB2ConnectionPoolDataSource.getPooledConnection
		(DB2ConnectionPoolDataSource.java:45)
at com.ibm.ws.rsadapter.DSConfigurationHelper$1.run
		(DSConfigurationHelper.java:945)

問題

DB2 Universal Driver の一部のバージョンでタイプ 4 モードで実行中に、データベース障害に対して、WebSphere Application Server が失効した接続例外にマップできる特定のエラー・コードではなく、汎用例外が発生します。この問題は、DB2 8.1 フィックスパック 6 または 7、および DB2 8.2 に関連付けられたバージョンのドライバーで発生します。

解決策

DB2 バージョン 8.2 フィックスパック 1 にアップグレードします。これは、バージョン 8.1 フィックスパック 8 と同じです。前述のシナリオでの有効なエラー・コードが用意されています。 WebSphere Application Server は、このエラー・コードを予想通りに StaleConnectionException にマップします。

DB2 Universal JDBC Driver を使用している場合に Linux 上の DB2 にアクセスできない

症状

Linux 環境の WebSphere Application Server で、DB2 Universal JDBC Driver を使用して Linux 上の DB2 にアクセスするアプリケーションが、データベースに接続できない可能性があります。データベース・サーバーが、アプリケーション・サーバーのエラー・ログに以下の例外を出すことがあります。
  • java.security.AccessControlException: Access denied
     (java.lang.RuntimePermission accessClassInPackage.sun.io)
  • 64 ビット Linux を実行している場合:
    com.ibm.db2.jcc.b.SqlException: Failure in loading T2 native library db2jcct2

問題

Linux 上の DB2 で Universal JDBC Driver を使用するように構成するプロセスが完了しません。

解決策

  • Linux プラットフォーム用の Java™ SDK 1.4.2 のセットアップ要件を満たしていることを確認します。
  • Linux 上の Java アプリケーションをビルドするための開発環境を、DB2 JDBC サポートを使用して構成します。 詳しくは、DB2 のアプリケーション開発に関するトピックを参照してください。
  • DB2 を Linux/IA64 プラットフォーム上で実行していて、DB2 v8.1 フィックスパック 7A を使用している場合は、欠落している libdb.so.3 ライブラリーについて報告している、IA64 上の DB2 UDB バージョン 8 フィックスパック 7a for Linux に関する技術情報で説明されている追加のステップを実行します。このステップは、フィックスパック 7A でのみ必要です。 このステップは、DB2 v8.1 フィックスパック 7 またはそれ以前のバージョンの DB2 では必要ありません。また、このステップは、DB2 v8.1 フィックスパック 8 またはそれ以降のバージョンの DB2 でも必要ありません。

コンテナー管理されるパーシスタント Bean 内の VARCHAR FOR BIT DATA 列で、不正な型変換が行われる

DB2 のテーブルに VARCHAR FOR BIT DATA 列が定義されている、コンテナー管理される永続 (CMP) タイプのエンタープライズ Bean を、DB2 Universal JDBC タイプ 4 ドライバーにデプロイしてデータを永続化させると、実行時に、不正な型変換を示す SQLException がスローされます。 この例外が発生するのは、DB2 Universal JDBC タイプ 4 ドライバーを使用し、deferPrepares プロパティーを true に設定している場合だけです。 deferPrepares プロパティーを true に設定すると、DB2 Universal JDBC タイプ 4 ドライバーは、標準の JDBC データ・マッピングを使用します。

現在のところ、生成されてデプロイ済みのコードは、標準の JDBC 仕様のマッピングには準拠していません。実行時の失敗は、実行用にエンタープライズ Bean を準備したツールにおける問題が原因です。

この例外を受け取らないようにするには、以下のいずれかのオプションを選択してください。
  • データ・ソース構成で、deferPrepares プロパティーを false に設定する。
  • テーブルに VARCHAR FOR BIT DATA または LONG VARCHAR FOR BIT DATA 列がある場合には、DB2 Universal JDBC タイプ 4 ドライバーを使用しない。 詳細は、DB2 V8.1 の readme を参照してください。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_dsaccess3
ファイル名:rtrb_dsaccess3.html