DB2 V9.7のOracle互換機能(NUMBER)
今回は、DB2 Ver 9.7で追加された機能の一部を検証してみましたので、結果をご報告致します。
某二次会で・・・
この前のClub DB2の二次会ネタなのですが、DB2 9.7のOracle互換性の件が話題になりました。
私:「ねぇ、新しいDB2ではORACLEのNUMBERがサポートされるようになったじゃない?」
A:「そうだね...」
私:「Create TableでNUMBERを指定して表を作り、db2lookでカラムの属性見たら
どうなるんだろう?」
A:「そうだね。桁数によって、INTEGERとかBIGINTとかFLOATみたいに変わるの
かなぁ?」
私:「えぇっ、誰も知らないのかなぁ・・・?」
A:「Express-Cだと試せないじゃん。誰だろう製品版持ってるのは・・・?」
結局9.7のExpress-C版でないバージョンを持っている人がその場にいなかったので、「お前が試せ!」と言うことになりました。(--;
ということで、夏休みの宿題を、これからやってみます・・・。
互換機能の設定は・・・
まず、互換性の設定については、SIMさんのブログで公開されていますので、そちらを参考にして下さい。
DB2 9.7小ネタ - Oracleとの互換性を最大にする設定
ちなみに、このエントリーで私は別件で質問をコメントしたのですが、SIMさんからの返信が無いので、私に会う人の何人かが、「どうして回答が無いのかなぁ」なんて聞かれてしまったのですが、個人的にSIMさんからはTwitterで回答をもらっていました。
証拠といってはなんですが、それを、私のIDのファブリンク(twitterの機能)に入れておきました。
※ きっとそのうち新たな回答(「こうすればできるみたいよ」みたいな・・・)が来るのではないかと期待しています。(^^)
表を作成する・・・
データベースが作成されたら表を作ってみましょう。
コントロールセンターのウィザードで生成されたSQLを編集してみても良いでしょう。
変な表ですが、テストなので・・・
CREATE TABLE DB2ADMIN.ORA_TEST_1 (
ID NUMBER(4) NOT NULL
, NUM1 NUMBER(9)
, NUM2 NUMBER(10)
, NUM3 NUMBER(5,3)
, CONSTRAINT ID PRIMARY KEY (ID)) ;
成功すると次のような画面になります。

ちなみに、失敗したときは、次のようなメッセージが出ます。
SQL0204N "NUMBER" は未定義の名前です。 SQLSTATE=42704
レジストリ変数を変更した後、インスタンスの再起動が必要なのですが、それを忘れてしまうと同じようなメッセージが出ると思います。
db2lookを実行する・・・
さて、今回の結論を確かめるために「db2look」を実行します。
コントロールセンターを実行していれば、表をマウス右ボタンでクリックして「DDLの生成」を実行します。
オプションの指定ですが、「データベース・オブジェクト」だけチェックしても目的は達成されます。実行されるコマンドは次のものです。
db2look -d ORA_TEST -t "ORA_TEST_1" -a -e -l -x -c ;
さて、結果ですが、次のようになりました。

-- この CLP ファイルの作成に使用した DB2LOOK のバージョン: "9.7"
-- タイム・スタンプ: 2009/08/18 21:17:46
-- データベース名: ORA_TEST
-- データベース・マネージャーのバージョン: DB2/NT Version 9.7.0
-- データベース・コード・ページ: 943
-- データベース照合シーケンス: UNIQUE
CONNECT TO ORA_TEST;
------------------------------------------------
-- 表の DDL ステートメント "DB2ADMIN"."ORA_TEST_1"
------------------------------------------------
CREATE TABLE "DB2ADMIN"."ORA_TEST_1" (
"ID" DECIMAL(4,0) NOT NULL ,
"NUM1" DECIMAL(9,0) ,
"NUM2" DECIMAL(10,0) ,
"NUM3" DECIMAL(5,3) )
IN "USERSPACE1" ;
-- 表の主キーの DDL ステートメント "DB2ADMIN"."ORA_TEST_1"
ALTER TABLE "DB2ADMIN"."ORA_TEST_1"
ADD CONSTRAINT "ID" PRIMARY KEY
("ID");
COMMIT WORK;
CONNECT RESET;
TERMINATE;
-- すべての作成者に統計を生成します
-- db2look ユーティリティーは指定された表のみ考慮します
-- 表の DDL の作成
「桁溢れ」を起こしてみる・・・
「もしかしたらエラーコードも変わるんじゃないの?」って話になりましたので(をい!)、実際に桁あふれを起こしてエラーメッセージを確かめてみました。
UPDATE DB2ADMIN.ORA_TEST_1 SET NUM1 = 1234567890 WHERE ID = 1
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、 SQL
ステートメントとして処理されました。 SQL 処理中に、そのコマンドが返されました。
SQL0413N 数値データ・タイプの変換中にオーバーフローが発生しました。
SQLSTATE=22003
どうやら、変わりないようです。
「へぇ、へぇ、へぇ・・・」(^^;
まとめ
今回の検証結果から見ると、整数、小数、桁の大きい数など、数値については全て「NUMBER」タイプは、「DECIMAL」タイプに置き換えられて保持されるようです。
正直言って、表の設計において「DECIMAL」タイプを使ったことはあまり無いんですね。ですから、その良し悪しについてまでは言及できませんが、どうなのでしょうか?
関連する内容について、まとめておきたいと思います。
- DB2 V9.7では、様々なOracle互換機能が追加されている
- DB2 V9.7のOracle互換機能を使うためには、db2setコマンドを使い、システム変数「DB2_COMPATIBILITY_VECTOR」を設定する。
(フル互換にするなら、「DB2_COMPATIBILITY_VECTOR=ORA」を設定) - 機能を有効にするには、インスタンスの再起動が必要
- CREATE DATABASE コマンドを実行したときのレジストリ変数の値によって、互換性有無(度合)が決定される
- しかし、どういう互換性でCREATE DATABESE が実行されたかを知る術は無い...
(もしくは非公開・・・?) - CREATE TABLE コマンドで、NUMBERタイプがサポートされた
- NUMBERで作成されたカラムのタイプは、内部的には「DECIMAL」で保持されている
- エラーコードやメッセージが変わることは無い?(少なくとも今回のケースでは...) ※1
※1: 実は、あるアプリを実行していて、この互換性を変更した場合に挙動が変わってしまったことがありました。それについては、徐々に原因を解明していこうと思っています。
- Category(s)
- DB2
