パーソナルツール
現在の場所: ホーム ブログ DB2 9 を利用したメール・アーカイブ・システムの開発 (5)
« 2018January »
Su Mo Tu We Th Fr Sa
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
このBlogについて
 代表の向井田ことMUKAです。当ブログサイトでは、MAGICやDB2に関する技術者向け情報を公開しています。お気軽にお立ち寄り下さい。
最近のエントリ
twitter / 新RT機能を英語モードで・・・ muka 2009年11月19日
twitter / List Widget muka 2009年11月03日
twitter API / Retweet の仕様が・・・ muka 2009年10月30日
twitter API / Lists muka 2009年10月24日
IBM Rational Software Conference 2009 と アジャイル開発 muka 2009年10月08日
twitter API / geoタグ! muka 2009年10月01日
Twitter Developers Meetup in Tokyo muka 2009年09月11日
Club DB2 2009/9/4 muka 2009年09月05日
最近のコメント
Re:Club DB2 2009/8/29 muka 2009年09月01日
Re:Club DB2 2009/8/29 SIM 2009年08月31日
最近のトラックバック
Club DB2 8/29の感想エントリと今後の予定 Unofficial DB2 BLOG 2009年09月01日
カテゴリ
misc (47)
dbMAGIC (47)
DB2 (47)
mail (47)
Web (47)
twitter (47)
 

DB2 9 を利用したメール・アーカイブ・システムの開発 (5)



DB2 9.5へ


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

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


新バージョンとの並存


 さて9.5を入手したものの、9.1で開発してきた環境はどうなるのかと思いました。
 何台も開発用のマシンがあるわけではないし、開発したアプリのテスト環境にも影響しないかどうかと心配になりました。しかしたまたま、クラブDB2でお会いしたIBMの方にお聞きしたところ、「いろんなエディションも入れられるようですよ」という答だったんです。
 なんだ、複数のDB2エディションがインストールできるのか!(知らなかった・・・)

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

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

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


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

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

 ただ、NSE(Net Search Extender)絡みでは、移行時に若干問題が起きました。

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

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

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


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


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

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

XMLの基本表行保管機能を使う

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

  1. EXPORTコマンドにより、XMLと表の情報を出力
    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. 既存のXML表、NSE索引のドロップ
    これはコントロールセンターなどで行いました。
    念のために、ドロップする前にデータベースをバックアップしておきましょう。
  3. 32K用バッファプールの作成
    ページサイズを指定して新しいバッファプールを作成します。
    CONNECT TO MAIL_ARC;
    CREATE BUFFERPOOL FOR_XML32K
    IMMEDIATE SIZE 250 AUTOMATIC PAGESIZE 32 K ;
    CONNECT RESET;
  4. 32K用の表スペースを作成
    作成したバッファプールを指定して、3種の表スペースを作成します。
    「...」の部分には、「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 コマンドによるXML表データを読みこみ
    さて、いよいよデータの取り込みです。あいにくまだLOADに慣れていないのでIMPORTで実行しました。(LOADコマンドは9.5からXMLを含んだ表に対しても利用できるようになったのですが・・・。)
    2で既に表をドロップしてしまっていますが、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. NSE索引の作成と更新
    NSEのテキスト索引がある場合はそれを更新します。


マイグレーションその後


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

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

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



カテゴリ
DB2
mail