ＤＢ２　９．５へ

　ご無沙汰してま~す。
　このシリーズも前回から２ヶ月も経ってしまいました。またボツボツと進めていきますので、お付き合いのほど宜しくお願い致します。
　さて、その間、ＤＢ２の周辺でもいろいろな出来事がありましたが、なんと言っても大きいのは９．５のリリースでした。（昨年１０月末のリリース）
　９．５のメリットや拡張された機能は沢山ありすぎて、ここで述べるのは大変なくらいです。知れば知るほど使ってみたいと思うものも増えてきます。先日も、今年初めての「クラブＤＢ２」に参加させて頂きましたが、そこでも新機能（ ワークロード管理）の実際的なところの紹介があり、興味深い勉強をさせて頂きました。

　今回は、現時点までの弊社９．５移行関連の状況について紹介させて頂きたいと思います。

新バージョンとの並存

　さて９．５を入手したものの、９．１で開発してきた環境はどうなるのかと思いました。
　何台も開発用のマシンがあるわけではないし、開発したアプリのテスト環境にも影響しないかどうかと心配になりました。しかしたまたま、クラブＤＢ２でお会いしたＩＢＭの方にお聞きしたところ、「いろんなエディションも入れられるようですよ」という答だったんです。
　なんだ、複数のＤＢ２エディションがインストールできるのか！（知らなかった･･･）

　ということで、早速９．５をインストールすることになりました。
　複数のＤＢ２のバージョンを同じマシンにインストールしたときの状況は次のようになります。

• 　追加インストールを行うと、「C:\Program Files\IBM\SQLLIB_v95」に新しいバージョンがインストールされる
• データベースも別個のフォルダ（例えば、「C:\DB2_01」等）に作成される。レジストリ上は「DB2COPY2」という名称で管理されている模様。
• ＤＢ２用のサービスも「DB2COPY1」用とは別個に「DB2COPY2」用のものがもう１セット作成される。
  
• データベースの切り替えは、セットアップ・ツールの「デフォルト DB2 およびデータベース・クライアント・インターフェース選択ウィザード」を起動し、デフォルトDB2コピーを「DB2COPY2」を選択することで可能。
  

新バージョンへのマイグレーション(1)

　９．１から９．５の移行については、次の手順により、殆ど何の問題も無く移行できることが分かりました。（実は半年ほど前にインストールしたベータ版では思うように動作しないなどの経験があったので、大丈夫なのかどうか、ちょっと心配でした。）

1. ９．１でデータベースをバックアップ
2. ９．５をインストール
3. ９．１でバックアップしたものをリストア
   

　ただ、ＮＳＥ（Net Search Extender）絡みでは、移行時に若干問題が起きました。

• ＮＳＥ用に使用可能にしたデータベースを、db2extmdb マイグレーション・スクリプトを使用してマイグレーションすればよいらしい・・・
• 実際に実行してみたが、完了のメッセージは出るものの、正常に動作せず？

　私の理解不足が原因かと思いますが、結局テキストインデックスのマイグレーションはできませんでした。しょうがないので、テキスト索引をドロップし、再作成することにより済ませてしまいました。

　このレベルで、１～２ヶ月アプリケーションを動作させてみました。
　どのような機能を使っているかという問題はありますが、前のバージョンと同じように動作するかどうかという互換性の問題では、殆ど問題ないことが分かりました。

新バージョンへのマイグレーション(2)

　９．５で試してみたい機能は、やはりＸＭＬに関連する拡張機能です。
　ＤＢ２では、ＸＭＬ列に格納されるデータは基本表とは別のオブジェクト（ＸＭＬストレージ・オブジェクト）に格納されていますが、９．５では、３２Ｋまでの指定したサイズより小さいＸＭＬデータは基本表内に格納（基本表行保管）できるようになった模様です。
　この機能を使用した場合、小さいＸＭＬファイルを格納することが多いケースでは、ストレージを圧縮できたり、パフォーマンスも向上するということでした。

　３万件程のメールデータのＸＭＬファイルのサイズを調べたところ、98.8％は32K以下のサイズであることが分かりました。
　ということで、この機能を使うべく、メインとなっているＸＭＬ格納用の表を変更することにしました。

ＸＭＬの基本表行保管機能を使う

　ＸＭＬの基本表行保管機能を使うためには、CREATE TABLE または ALTER TABLE ステートメントで、INLINE LENGTH キーワードを指定する必要があります。
　また、デフォルトで作成される表スペース（今まで使用していた表スペース）の行サイズはは４Ｋなので、３２Ｋ用の表スペースを新たに作成し、そこに表を作成する必要があります。
　３２Ｋ用の表スペースを作成するためには、３２Ｋ用のバッファプールも作成しておく必要があります。
　表スペースを作成する際、データ格納用の表スペース以外に、システム一時領域用と一時表格納領域用の表スペースも別途作成する必要があります。
　表内に他のカラムがある場合は、それらのサイズの合計値も INLINE LENGTH で指定できるサイズに影響します。
　ということで、表の変更を含めたデータの移行手順とその実際をまとめると次のようになります。

1. EXPORTコマンドにより、ＸＭＬと表の情報を出力
   

   CONNECT TO MAIL_ARC;
   EXPORT TO "U:\export\export.del" OF DEL XML TO "U:\export\xml"
    XMLFILE "data" MODIFIED BY CHARDEL""
    TIMESTAMPFORMAT="YYYY/MM/DD HH:MM:SS.UUUUUU"
    COLDEL, XMLINSEPFILES
    MESSAGES "U:\export\export.log"
    SELECT * FROM MAIL_ARC.MAIL_DB;
   CONNECT RESET;
   

2. 既存のＸＭＬ表、ＮＳＥ索引のドロップ
   これはコントロールセンターなどで行いました。
   念のために、ドロップする前にデータベースをバックアップしておきましょう。
   
3. ３２Ｋ用バッファプールの作成
   ページサイズを指定して新しいバッファプールを作成します。
   

   CONNECT TO MAIL_ARC;
   CREATE BUFFERPOOL FOR_XML32K
    IMMEDIATE SIZE 250 AUTOMATIC PAGESIZE 32 K ;
   CONNECT RESET;
   

4. ３２Ｋ用の表スペースを作成
   作成したバッファプールを指定して、３種の表スペースを作成します。
   「...」の部分には、「EXTENTSIZE 16 OVERHEAD 12.67 PREFETCHSIZE 16 TRANSFERRATE 0.18」等の数値を含んだ文字列が入ります。

   CONNECT TO MAIL_ARC;
   CREATE LARGE TABLESPACE FOR_XML32K PAGESIZE 32 K
    MANAGED BY AUTOMATIC STORAGE ...  BUFFERPOOL FOR_XML32K ;
   CREATE SYSTEM TEMPORARY FOR_XML32K_TMP PAGESIZE 32 K
    MANAGED BY AUTOMATIC STORAGE ...  BUFFERPOOL FOR_XML32K ;
   CREATE USER TEMPORARY FOR_XML32K_USR PAGESIZE 32 K
    MANAGED BY AUTOMATIC STORAGE ...  BUFFERPOOL FOR_XML32K ;
   CONNECT RESET;
   

5. INLINE LENGTH キーワードを使用して表を作成
   いよいよ表作成です。INLINE LENGTHで指定する数値は最初32000を指定してみたのですが、行サイズを超えてしまったというエラーが出ました。他のカラムのサイズを考慮する必要があります。「IN」、「INDEX IN」、「LONG IN」でそれぞれの表スペースを指定します。
   

   CONNECT TO MAIL_ARC;
   CREATE TABLE MAIL_ARC.MAIL_DB (
     MAIL_ID BIGINT NOT NULL ,
     MAIL_DES VARCHAR (254) NOT NULL ,
     MAIL_DATA XML INLINE LENGTH 31000 ,
     MESSAGE_ID VARCHAR (254) NOT NULL ,
     IN_REPLY_TO VARCHAR (254) NOT NULL ,
     TIMESTAMP TIMESTAMP ,
     MAIL_DATE CHARACTER (14) ,
     DATE_ATTR INTEGER ,
     MAIL_SIZE BIGINT ,
     CNT_FILES INTEGER ,
     BODY_TYPE INTEGER ,
     POPT_ATTR INTEGER ,
     CONSTRAINT MAIL_ID PRIMARY KEY (MAIL_ID) ,
     CONSTRAINT MAIL_DES UNIQUE (MAIL_DES) ,
     CONSTRAINT MESSAGE_ID UNIQUE (MESSAGE_ID),
     CONSTRAINT IN_REPLY_TO UNIQUE (IN_REPLY_TO, MAIL_ID)
    )
    IN FOR_XML32K
    INDEX IN FOR_XML32K_TMP
    LONG IN FOR_XML32K_USR
    COMPRESS YES ;
   CONNECT RESET;
   

6. INPORT , LOAD コマンドによるＸＭＬ表データを読みこみ
   さて、いよいよデータの取り込みです。あいにくまだLOADに慣れていないのでIMPORTで実行しました。（LOADコマンドは９．５からＸＭＬを含んだ表に対しても利用できるようになったのですが・・・。）
   ２で既に表をドロップしてしまっていますが、REPLACEであれば自動的に入替えされるはずです。
   

   CONNECT TO MAIL_ARC;
   IMPORT FROM "U:\export\export.del" OF DEL
    XML FROM "U:\export\xml"
    MODIFIED BY TIMESTAMPFORMAT="YYYY/MM/DD HH:MM:SS.UUUUUU"
    CHARDEL""
    MESSAGES "U:\export\import.log"
    REPLACE INTO MAIL_ARC.MAIL_DB;
   CONNECT RESET;
   

7. ＮＳＥ索引の作成と更新
   ＮＳＥのテキスト索引がある場合はそれを更新します。
   

マイグレーションその後

　さて、パフォーマンスやディスクのサイズは変わったでしょうか？

　移行後にとったバックアップファイルのサイズと比較すると、84％ほどに小さくなりました。しかし、これは信頼できる数値結果なのかどうかはまだ良く分かりません。
　肝心の計測方法をどうするかは、すっかり頭に無かったので・・・。（これから考えてみます。(^^;）
　パフォーマンスのほうも少し動作させてみながら・・・。

　ということで、取り敢えず今回は、「９．５の新機能である基本表行保管への対応の実際は、無事成功！」・・・ということで、終わりにしたいと思います。
（きっと、新機能の効果はあった・・・と思いつつ・・・。）