管理の手引き


DB2 ユニバーサル・データベース バージョン 7 の非互換性

このセクションでは、DB2 ユニバーサル・データベース バージョン 7 の非互換性について説明します。

アプリケーション・プログラミング

クエリー・パトローラー・ユニバーサル・クライアント


WIN UNIX OS/2

変更点

このクライアント・アプリケーション・イネーブラー (CAE) の新しいバージョンは、 新しいストアード・プロシージャーを含んでいるために、 クエリー・パトローラー・サーバー バージョン 7 でのみ動作します。 CAE は DB2 へのアプリケーション・インターフェースで、 すべてのアプリケーションは最終的には CAE を通して データベースにアクセスします。

症状

この CAE がバック・レベルのサーバーに対して実行されると、 メッセージ SQL29001 が戻されます。

オブジェクト変換関数および構造型


WIN UNIX OS/2

変更点

SQLDA が変更されたことが原因で、 バージョン 7 以前のクライアントとバージョン 7 のサーバーとの間には、 ごくわずかな非互換性がリモートに発生する可能性があります。 アプリケーション開発の手引き で説明されているように、 2 番目の SQLVAR の 8 番目のバイトには、 (値 X'00' および X'01'に加えて) 値 X'12' が使用可能になりました。 新しい値を予期しないアプリケーションは、 この拡張によって影響されるかもしれません。

解決方法

将来のリリースでは、この分野で他にも拡張される点が出てくる可能性があるため、 開発者は明示的に定義された値のみをテストするようお勧めします。

JVM の使用するクラスおよび jar ファイルのバージョン


WIN UNIX OS/2

変更点

これまでは、 いったん Java ストアード・プロシージャーまたはユーザー定義関数 (UDF) が開始されると、 Java 仮想マシン (JVM) によって、CLASSPATH で指定されたすべての ファイル (sqllib/function の中のファイルを含む) がロックされました。 JVM は、データベース・マネージャーが停止するまでこのファイルを使用しました。 ストアード・プロシージャーや UDF を実行する環境 (つまり、 データベース・マネージャー構成パラメーター keepdari の値、 およびストアード・プロシージャーが隔離されているかどうか) によっては、 クラスをリフレッシュすることにより、 データベース・マネージャーを停止せずにクラスおよび jar ファイルを置換できます。 この点が以前の動作と異なります。

インストール、置換、および除去 jar コマンドの機能の変更


WIN UNIX OS/2

変更点

これまでは、jar のインストールの際、 すべての DARI (データベース・アプリケーション・リモート・ インターフェース) プロセスがフラッシュされていました。 このようにして、 新しいストアード・プロシージャー・クラスが次の呼び出しで使用されることが保証されていました。 今後は、jar コマンドによって DARI プロセスがフラッシュされることはありません。 新しくインストールまたは置換された jar からのクラスを使用するには、 SQLEJ.REFRESH_CLASSES コマンドを明示的に発行する必要があります。

DARI プロセスをフラッシュしないことによる別の非互換性として、 隔離されたストアード・プロシージャーの場合、 データベース・マネージャー構成パラメーター keepdari の値 が "YES" に設定されていれば、 クライアントは異なるバージョンの jar ファイルを受け取る可能性があります。 次のシナリオを考えてください。

  1. ユーザー A は jar を置換しますが、クラスをリフレッシュしません。
  2. 次に ユーザー A は jar からストアード・プロシージャーを呼び出します。 この呼び出しで同じ DARI プロセスが使われるとすれば、 ユーザー A は jar ファイルの以前のバージョンを受け取ります。
  3. ユーザー B は、同じストアード・プロシージャーを呼び出します。 この呼び出しは、新しい DARI を使用します。つまり、 新しく作成されたクラス・ローダーは jar ファイルの新しいバージョンを使用します。

言い換えると、jar 操作の後でクラスがリフレッシュされない場合は、 使用される DARI プロセスに応じて、 異なるバージョンの jar からのストアード・プロシージャーが呼び出される可能性があります。 この点が、(DARI プロセスをフラッシュすることによって) 常に新しいクラスが 使用されていた以前の動作と異なります。

32 ビット・アプリケーションの非互換性



UNIX

変更点

32 ビット実行可能プログラム (DB2 アプリケーション) は、 新しい 64 ビット・データベース・エンジンに対しては実行されません。

症状

アプリケーションはリンクに失敗します。 32 ビット・オブジェクトを 64 ビット DB2 アプリケーション・ライブラリーに リンクしようとすると、 オペレーティング・システムのリンカー・エラー・メッセージが表示されます。

解決方法

アプリケーションを 64 ビット実行可能プログラムとして再コンパイルし、 新しい 64 ビット DB2 ライブラリーにリンクしなおす必要があります。

スクラッチパッドの長さフィールドの変更


WIN UNIX OS/2

変更点

ユーザー定義関数 (UDF) で、渡されるスクラッチパッドの長さフィールドを 変更すると、SQLCODE -450 が戻されるようになりました。

症状

スクラッチパッドの長さフィールドを変更する UDF は失敗します。 呼び出しステートメントは SQLCODE -450 を受け取り、 ここにスキーマおよび関数の固有の名前が示されます。

解決方法

スクラッチパッドの長さフィールドを変更しないように UDF 本文を書き直します。

SQL

スキーマ SESSION によって修飾される正規表を使用するアプリケーション


WIN UNIX OS/2

変更点

スキーマ SESSION は、一時表に使用できる唯一のスキーマです。 DB2 はこれを使用して、SESSION 修飾表が一時表を参照する 可能性があることを示すようになりました。 ただし、SESSION は一時表のために予約されたキーワードではないため、 正規基本表用のスキーマとして使用できます。 このため、アプリケーションで、 実表 SESSION.T1 と宣言済み一時表 SESSION.T1 とが 同時に存在することが検出される可能性があります。 パッケージのバインド時に、 (明示的または暗黙的に) "SESSION" で修飾されている表参照を含む静的ステートメントが見つかると、 このステートメントのセクションや従属関係はカタログに保管されません。 代わりに、このセクションを実行時に増分的にバインドする必要があります。 これによって、このセクションのコピーが 動的 SQL のキャッシュに入ります。 キャッシュに入れられたコピーは、 アプリケーション固有のインスタンス専用となります。 実行時に、表名が一致する宣言済み一時表が存在する場合、 たとえ同じ名前の永続基本表が存在しても、宣言済み一時表が使用されます。

症状

バージョン 6 以前では、 SESSION によって修飾される表を含む静的ステートメントのパッケージは、 常に永続基本表を参照していました。 パッケージをバインドする際には、 セクションおよびそのステートメントに関連した従属関係レコードが カタログに保管されました。 バージョン 7 では、これらのステートメントはバインド時にはバインドされず、 実行時に同じ名前の宣言済み一時表に解決されます。 したがって、次のような状況が生じる可能性があります。

要約すると、バージョン 7 でバインドされたパッケージのうち、 SESSION 修飾表を参照する静的ステートメントを持つものは、 増分的バインドが必要であるため、もはや静的 SQL のようには動作しません。 実際、既存の SESSION 修飾表、視点、 または別名と同じ名前を持つ表に関してアプリケーション・プロセス が DECLARE GLOBAL TEMPORARY TABLE ステートメントを発行すると、 それらのオブジェクトへの参照は、 すべて宣言済み一時表を参照するものとみなされます。

解決方法

可能であれば、永続表のスキーマ名を "SESSION" 以外に変更します。 それができなければ、パフォーマンスに与える影響について、 および宣言済み一時表との競合について、意識しておく以外に方法はありません。

以下の照会を使用すれば、 アプリケーションが一時表を使用するときに影響を受ける可能性のある表、 視点、および別名を識別することができます。

   select tabschema, tabname from SYSCAT.TABLES where tabschema = 'SESSION'

以下の照会を使用すれば、バージョン 7 でバウンドされたパッケージのうち、 静的セクションがカタログに保管されており、 パッケージの再バインド時に動作が変わる可能性のあるものを識別できます (これは、 バージョン 6 からバージョン 7 に移行する場合にのみ関係があります)。

   select pkgschema, pkgname, bschema, bname from syscat.packagedep
      where bschema = 'SESSION' and btype in ('T', 'V', 'I')

ユーティリティーとツール

Solaris でのデータ・リンク・ファイル・マネージャーとファイル・システム・フィルター



UNIX

変更点

データ・リンク・ファイル・マネージャーと ファイル・システム・フィルターは、Solaris OS 2.5.1 ではサポートされていません。

AIX および Solaris での db2set



UNIX

変更点

コマンド db2set -ul (ユーザー・レベル) およびこれに関連する関数は、 AIX および Solaris には移植されていません。

接続性と共存

32 ビット・ クライアントの非互換性


WIN UNIX OS/2

変更点

32 ビット・クライアントは、 64 ビット・サーバー上のインスタンスやデータベースには接続できません。

症状

クライアントおよびサーバーの両方がバージョン 7 のコードを実行している場合は、 SQL1434N が戻されます。 それ以外の場合は、接続が SQLCODE -30081 を出して失敗します。

解決方法

64 ビット・クライアントを使用します。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]