パーソナルツール
現在の場所: ホーム ブログ Categories DB2
« 2018June »
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
このBlogについて
 代表の向井田ことMUKAです。当ブログサイトでは、MAGICやDB2に関する技術者向け情報を公開しています。お気軽にお立ち寄り下さい。
最近のエントリ
xpa版 いろいろ… muka 2018年03月24日
ソース管理ツール xpa版の不具合 muka 2018年03月16日
MAGIC ソース管理ツール SMSYS muka 2018年03月10日
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日
最近のコメント
K stool what, underline non-diabetics. odesisenexo 2018年06月24日
Lies pharmacy nephropathy, them buy retin a online immunoparesis, levitra canada principle females, then. yofaaqhoneqaf 2018年06月22日
Slowly one-half squint; appropriately endocrinology tilt jaw. elesezacawixa 2018年06月22日
Detectable adi- keeping labial bent cyclophosphamide dentists. ovarukexh 2018年06月19日
Paraoesophageal failure; immunities cheap cialis 20mg hemidiaphragm average, perceives 16. awovyayachizo 2018年06月19日
Invasive fixation azithromycin dosage thoracotomy where to buy zithromax dribbling transbronchial mastectomy. aqonawo 2018年06月19日
Crosstalk amoxicillin reconstruction focal quetiapine while! ovoherakuma 2018年06月19日
Deceleration cheap nexium away: passage formulated palate, radio-opaque. idujamujeaw 2018年06月19日
最近のトラックバック
Club DB2 8/29の感想エントリと今後の予定 Unofficial DB2 BLOG 2009年09月01日
カテゴリ
misc (50)
dbMAGIC (50)
DB2 (50)
mail (50)
Web (50)
twitter (50)
 

DB2

一つ上に移動
IBMのハイブリッドデータベースDB2 9(デービー・ツー・ナイン)に関するもの

MAGIC V10解析(11)


春ですね。でも・・・


 すっかり暖かくなりました。皆さん、お元気でしょうか?
 でも今年の花粉はちょっときついですね。花粉症と付き合ってもうかれこれ二十数年になるんですが、目がかゆくてたまらなくなるのは過去最高レベルです。さすがに耐え切れず、「目を丸ごと洗う」という「〇イボン」という薬を買ってきました。
 「丸ごと」というのはちょっと誇大広告気味だと思うんですが、「眼球の半分ほど」は洗ってくれるので、とても良いですね!
 洗った後はさすがに爽快なんですが、でも、ものの1・2時間で、また痒みが再発してしまう・・・。ちょっと期待し過ぎたかなぁ?


「フォーム状態ID」って使ってます?


 さて、今回は、MAGICネタです。
 V10になってから増えたフォームの属性に「フォーム状態ID」というのがあります。皆さん、もうお使いでしょうか?

ma11_02.jpg

フォーム状態IDはフォームの一つの属性で任意のテキストを入力します。


 このフォーム状態IDを指定しておくことにより、ウインドウの表示位置とサイズ、Showの状態(最大化、最小化、通常・・・)、テーブルカラムの順番と幅などのサイズ、等を記憶してくれるようになっています。エンドユーザが操作した内容・・・つまり、この画面はこのあたりに表示させよう・・・といった結果を記録し、次回表示時もその状態で表示してくれるんです。GUI画面を持つアプリケーションの操作は、とてもフレンドリーになりました。

 実は、V8を使っていた頃の話ですが、このリサイズしたり移動したウインドウの状態を記憶するための仕組みを独自のロジックを行使して実現させていました。V10の機能では、そのための仕掛けがまったく必要なくなりました。プログラムソースもすっきりするし、とても便利になったものです。

 表示させるフォームに適当な識別名を入れるだけで済むので、是非使いたい機能だと思います。
 ちなみに、開発版でデバッグしている最中は有効にはならないので、気をつけてください。機能が効いていないのではと勘違いしてはいけません。クライアント実行をインストールして実行させれば、フォーム状態IDの入っている画面はその表示位置とか画面サイズ、テーブルカラムのサイズが記憶されます。


「フォーム状態ID」って良いことずくめ?


 さて、良いことずくめのような「フォーム状態ID」の利用ですが、果たしてどうなのでしょうか?少し思っているところを書いてみました。

  1. 入れ忘れる・・・

     まず、最初にぶち当たるのが「入れ忘れ」ですね。積極的にこの機能を使おうとすると、どこかのタスクだけ抜けてしまうことがあるんです。
     全体の中の一部でも効かないところがあると、ちょっとアンバランスになってしまいます。
  2. 命名に悩む・・・

     命名方法が何等かのルールで決まっていれば良いのかもしれませんが、それも無いとなると、これがまた悩むんですね。
     自分ひとりで作っていても、日によって付け方の方法が微妙に変わってくることもしばし。
     プログラムのID+タスクのID+フォームのIDで必ずユニークになるから、それを無条件に入れるという手はあるかも知れないけど、さてどうでしょう?
  3. ダブっているのに気付かない・・・

     次に、入れたのは良いけど、同じIDが別なプログラムのタスクのフォームでかち合ってしまう。しかもそれに気付かないという始末。これは結構深刻です。プログラムは似たようなものをコピーして複成してから作成することも多いですから、前のプログラムに入っていたIDがそのまま使用されてしまうということも多々あります。
     これがダブってしまうことによる弊害はそんなに大きくはないかと思いますが、MAGICは警告も何も出してくれません。
  4. 一覧表が作成できない・・・

     もうこういう状態になると、一覧表ができないものか・・・とかなり切実になってきます。
     当然ながら、現在のMAGICにそんな機能はありません。やるとなるとソースを何等かの方法で検索しなければならなくなる。プログラム毎にソースファイルが独立してますから、結構しんどいですね。
     ちなみに、プログラムソースのXMLファイル中、このフォーム状態IDなるものが記載されている場所を紹介しておきます。XPATH的に紹介しておきますと、「/Application//TaskForms/FormEntry/PropertyList/UserStateIdentifier/@val」です。
  5. クリア方法はあるの?

     そもそも、どこに記録されるんだ?という疑問が湧くわけですが、これはなんとか見つけました。
     えーとまずですね、プロジェクトファイルの中をテキストエディタで覗くと、「Application/Project/GUID」という要素が記録されていると思います。
        <GUID val="{AF265071-2FB7-4CA0-A3EE-96E85C484FE0}"/>
    次に、ログイン中のユーザ(つまり私)のプロファイルフォルダの下に、「Local Settings\Application Data\MSJ」というフォルダがあります。この下に、先のGUID要素の「val」属性と同じ名前のフォルダがあって、その中に、「FormsUserState.xml」というファイルがあると思うんですね。
     これがまさにこのフォーム状態を記憶しているファイルです!
     実行中は、このXMLファイルに表示したフォーム毎にノードがどんどん追加されていきますから、どんなフォームが表示されたかは、このXMLファイルを見れば分かるというわけです。
     で、おもむろにこのファイルを削除してしまえば、問題クリアです。
     が、こういう機能はMAGICに実装されていませんから、使っているユーザが画面をこねくりまわしてしまい、カラムが消えてしまったとか、テーブルからはみ出してしまった・・・なんてことになったときにどう対処してあげたらいいのか・・・。「プロファイルフォルダの、GUIDが・・・ですから・・・」なんていう説明ができるのかどうかという問題ですね。そう考えると、リリースするアプリケーションの機能として実装しておく必要もあるのかな?なんて考えてしまうわけです。

  6. 使い勝手は良いか?

     使っていてちょっと微妙な点があるかな?と思うのは、ウインドウを最大化したり戻したりしたときのテーブルのカラムのサイズに関するものです。
     つまり、最大化した状態で、テーブルのカラムを調整したまま、最大化を解除したりすると、そのカラムの状態は絶対的なサイズで記録されているので、必ずしも思ったようなサイズに伸縮されるとは限らないという点です。
     当然ながら、最大化した状態か通常の状態で使用し続けて頂ければ、殆ど問題は無いかとは思います。

解析ツールBeta Ver 0.8で実装した機能


 先月末に公開した「MAGIC Decrypter for V10 Beta Version 0.80」ですが、もう試してみられたでしょうか?
 その中に、このフォーム状態IDと関連する機能を実装しています。簡単に、ここで紹介させて頂きます。

  1. 機能の呼び出し方法

     追加実装した機能は、ツリーナビゲーションの「アプリケーション」を選択すると、「基本情報」タブのポップアップメニュー(マウス右ボタンをクリック)から起動が可能です。

    ma11_03.jpg

    アプリケーションの「基本情報」からマウス右ボタンでメニューを表示します。

    ma11_04.jpg

  2. テーブル表示機能

     「フォーム状態保存データ」というのは私が勝手に付けてしまった名前です。正式には何と呼ぶのか分かりません。
     メニューから「フォーム状態保存データを開く」を選択すると、ソースファイル(XMLファイル)を表示してくれます。
    ma11_01.jpg

    ソースデータ中には、「フォーム状態ID」毎にウインドウの表示位置などの情報が記録されています。


     メニューから「フォーム状態保存データの参照」を選択すると、上記のソースファイルをMAGICのGUI画面で表示します。

    ma11_05.jpg

    実際に使用されている「フォーム状態ID」をテーブル表示する機能を実装している
    更に、XMLDBを使っていれば、該当プログラムを逆引き可能


  3. その他の機能

     メニューから、「フォーム状態保存データの削除」を選択すると、データファイルを削除します。これでクリアした状態を作ることができるんですが、もしちょっと心配なら「フォルダを開く」という機能もあるので、エクスプローラ上からリネームして下さい。



一覧表を取得するには?


 先の、問題編で挙げた「一覧表」の作成機能を少し考えてみました。
 結論的にはXMLデータベースを使って、XQueryするしかないかな・・・と。
 Ver 0.8のセットアップ機能により、DB2連携環境は割りと簡単に構築できるようになっています。この連携機能では、修正したプログラムを見つけると、解析ツール起動時に全てアップデートするような仕掛けがあり、割とほぼ無意識的かつ自動的に連動して動きます。あとは検索機能を組み込めばよい訳です。

 さて、そのXQueryの方法ですが、下記のような構文を使って「フォーム状態IDが存在しているフォームエントリー」を探すことが可能です。
 xmlexist関数は、Select文のwhere句の中で使います。これで、プログラム単位に格納された該当レコードを絞り込みます。

xmlexists('$i/Application//Task/TaskForms/FormEntry[PropertyList
/UserStateIdentifier/@val!=""]'
passing c.ITEM as "i")

 更に、プログラム中の該当フォームを探すためには、selectの対象となるひとつのカラムとして、XML文書を取得します。
 xmlquery関数を使えば、そのプログラムソース内のどのタスクのどのフォームにどんなフォーム状態IDが付いていたのかを取得することが可能です。

xmlquery('
 <Datas>{
  for $e
  in $i/Application//Task/TaskForms/FormEntry
[PropertyList/UserStateIdentifier/@val!=""]

  return
 <Data>{$e/../../Header/@Description,$e/../../Header/@ISN_2,$e/@id}
    <Attr1>{$e/PropertyList/FormName/@valUnicode}</Attr1>
    <Attr2>{$e/PropertyList/UserStateIdentifier/@val}</Attr2>
  </Data>
 }</Datas>'
passing c.ITEM as "i") from DB2MRCA.PSOURCE c

 上記のソース中、「in」句でループさせているのが「Application//Task/TaskForms/FormEntry」であることに注意して下さい。ひとつのプログラム中に複数のタスクが存在しえますし、同じタスクにフォームも複数作れますから、起点が例えば「/Application//Task」では不都合です・・・。
 「return」句では、何をどのように出力するかを決定する箇所です。タスク名($e/../../Header/@Description)とタスク番号($e/../../Header/@ISN_2)とフォームのID($e/@id)を取得しつつ、子ノードを作成してそこにフォーム名($e/PropertyList/FormName/@valUnicode)とフォーム状態ID($e/PropertyList/UserStateIdentifier/@val)を出力しています。
 この部分は自分の好みで好きな形式に整形することが可能です。HTMLに直すことも可能ですし、k計算コンストラクタというものを使うと属性名を別なものに変えたり、属性値を要素として出力することなども可能です。
 下の例は、計算コンストラクタ「attribute」を使って、属性名「Description」を「TaskName」等に変更しているものです。

  return
   <Data>
    {attribute TaskName {fn:string($e/../../Header/@Description)}}
    {attribute TaskId {fn:string($e/../../Header/@ISN_2)}}
    {attribute ItemId {fn:string($e/@id)}}
   </Data> 

 検索の後処理はMAGICで行うわけですが、この部分はXMLで受けて、XMLに関連する関数でアクセスするのが効率よいと思うので、予め固定的な書式を決定しておくと良いと思います。
 現在改良中のバージョンでは、従来の「RM互換タスクの検索」機能を拡張し、コンボボックスでリストしたい種別を選択できるようにしています。
 このコンボボックスから「フォーム状態ID一覧の取得」を選択して「実行」ボタンを押すと結果が一覧表で返ってきます。(下図)

ma11_06.jpg

新バージョンでは検索種別を選択できるようになっています。


 DB2から返ってくるのはプログラム毎の情報なので、該当タスクとフォームの情報の格納されたXMLカラムを展開し、一覧表示用のワークテーブルを準備して表示します。

 「フォーム状態ID」のカラムでソートすれば、どこでぶつかっているかとかが分かるわけですね。(下図)
 

ma11_07.jpg

出力されたリストはエクセルシートに出力可能。画面上でもフォーム状態IDでソートできる。



未入力の一覧表を作成するには?


 入力済みのリストが出来たので、今度は未入力の一覧表を作成してみようと思います。
 条件式は、「@val!=""」を「@val=""」に変えるだけかな?と思ったんですが、これではうまく行かないことが分かりました。

xmlexists('$i/Application//Task/TaskForms/FormEntry[PropertyList
/UserStateIdentifier/@val=""]'
passing c.ITEM as "i")
というのは、「UserStateIdentifier」という要素は作成されるのですが、「val」という属性そのものが存在しないのです。

ma11_08.jpg

入力が無いと、「UserStateIdentifier」は空要素になるが、属性「val」も存在しない。


 存在しないものを探すためには、「@val=""」ではだめで、関数「fn:exists」を使用して行います。

xmlexists('$i/Application//Task/TaskForms/FormEntry[
not(fn:exists(PropertyList/UserStateIdentifier/@val))]'
passing c.ITEM as "i")
(※ この方法は分からなかったんですが、某IBMの方の助言を頂き、無事解決することができました。この場を借りてお礼申しあげます。)

 このままだと、画面表示の無いタスクや、バッチタイプのタスクも検索条件に引っかかってしまうので、実際は下記のような条件を加えて実行します。

xmlexists('$i/Application//Task/TaskForms/FormEntry[
 not(fn:exists(PropertyList/UserStateIdentifier/@val)) and
 ../../Header/TaskType/@val="O" and
 ../../Information/WIN/OpenTaskWindow/@val!="N"
]' passing c.ITEM as "i")

 実行方法は前と同じで、先のコンボボックスから「状態ID未入力フォームの検索」を選択し、「実行」ボタンを押します。



連絡事項


 リリース済みのベータ版(Ver 0.80)には、DB2連携の部分で不具合があることが判りました。これに対応した修正版(Ver 0.81)をリリースしました。
 また、上記の追加機能を搭載していますので、この機会に是非DB2連携機能もお試し下さい。


<不具合内容>

  •  連携中の不要なプロジェクトを削除したりしたときに、DB2へのインポートが正しく行われないことがある。(レコード数が不足したりする)





MAGIC V10解析(1) MAGIC V10解析(1)
サイズ 8337 - File type text/html
MAGIC V10解析(2) MAGIC V10解析(2)
サイズ 8904 - File type text/html
MAGIC V10解析(3) MAGIC V10解析(3)
サイズ 9714 - File type text/html
MAGIC V10解析(4) MAGIC V10解析(4)
サイズ 9882 - File type text/html
MAGIC V10解析(5) MAGIC V10解析(5)
サイズ 10443 - File type text/html
MAGIC V10解析(6) MAGIC V10解析(6)
サイズ 9739 - File type text/html
MAGIC V10解析(7) MAGIC V10解析(7)
サイズ 12563 - File type text/html
MAGIC V10解析(8) MAGIC V10解析(8)
サイズ 7011 - File type text/html
MAGIC V10解析(9) MAGIC V10解析(9)
サイズ 8221 - File type text/html
MAGIC V10解析(10) MAGIC V10解析(10)
サイズ 21278 - File type text/html
インストール手順について インストール手順について
サイズ 11.5 kB - File type text/html
MAGIC Decrypter for V10 MAGIC Decrypter for V10
サイズ 6.3 kB - File type text/html
カテゴリ
dbMAGIC
DB2

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


XQuery(SQL/XML )による検索処理


 前回までは、XMLデータに変換したメールデータをDB2(Ver 9.1、9.5)に格納するところまでは前回までで説明させて頂きました。
 今回は、格納したメールの検索方法について述べてみたいと思います。
 検索方法については、幾つかの方法があるのですが、まずは、標準的な、XQuery(SQL/XML )によるもの、その後、全文検索エンジンを使用したものについてそれぞれ説明したいと思います。

 まず、リレーショナル表として配置してあるカラムを使用することにより、通常のSQLによる検索が可能です(当たり前ですね)。
 下のSQL文はリレーショナル表のカラムとして設置した日付カラム(MAIL_DATE)を使用して2008年5月1日からのメールを10件取得するためのものです。

select MAIL_ID, MAIL_DATE
from MAIL_ARC.MAIL_DB
where MAIL_DATE >= '20080501000000'
order by MAIL_DATE fetch first 10 rows only

 この結果は、下図のようになります。

ma_041.jpg

 次に、XMLカラムの属性に対して検索条件を追加してみましょう。
 例えば、メールヘッダの日付属性(Date)に「Apr」のあるものを条件として追加するには下記のようにSQL文を変更します。

(補足すると、カラム「MAIL_DATE」に格納する時刻はJSTに変換して格納しているので、JSTの5月1日に送信されたメールは、他の標準時で4月30日の日付となることもありえます。)

select c.MAIL_ID, c.MAIL_DATE
from MAIL_ARC.MAIL_DB c
where c.MAIL_DATE >= '20080501000000' and
 xmlexists(
'declare default element namespace
 "http://schemas.eternaldesign.jp/oides/mail2xml" ;
  $i/RFC822[Header/Date[contains(.,"Apr")]]'
passing c.MAIL_DATA as "i")

order by c.MAIL_DATE fetch first 10 rows only

 少し複雑になりますが、「from」句で表「MAIL_ARC.MAIL」を「c」として扱い、「xmlexist」関数の中でXMLカラムである「c.MAIL_DATA」を変数「i」に渡しています。
 格納されているXMLドキュメントに名前空間が設定されている場合は「declare ~」以下の指定が必要です。
 日付属性のXPathは「/RFC822/Header/Date」ですから、「contain」関数で「Apr」を含むものを指定しています。
 今度は、実際にメールのヘッダの日付値に「Apr」が含まれているのかを表示してみましょう。
 Select句の中に「xmlquery」関数を挿入することにより、XMLの任意の情報を出力させることが可能になります。

select c.MAIL_ID, c.MAIL_DATE,
xmlquery(
'declare default element namespace
  "http://schemas.eternaldesign.jp/oides/mail2xml" ;
$i/RFC822/Header/Date' passing c.MAIL_DATA as "i") as DATE

from MAIL_ARC.MAIL_DB c
where c.MAIL_DATE >= '20080501000000' and
xmlexists(
'declare default element namespace
 "http://schemas.eternaldesign.jp/oides/mail2xml" ;
 $i/RFC822[Header/Date[contains(.,"Apr")]]'
 passing c.MAIL_DATA as "i")
order by c.MAIL_DATE fetch first 10 rows only

 結果はXMLタイプのオブジェクトとして返されます。

ma_042.jpg

 照会結果画面の「...」ボタンを押して中身の確認が可能です。

ma_043.jpg

 XQueryは出力結果をFLOWER式(「フラワー」と読む)を使用することによって自由な形式で出力が可能なのですが、もしテキストにシリアライズするのであれば、上記の太線部分は下記のように書き換えることも可能です(「xmlserialize」関数と「fn:data」関数を使用)。

xmlserialize(
xmlquery(
 'declare default element namespace
  "http://schemas.eternaldesign.jp/oides/mail2xml" ;
  $i/RFC822/Header/fn:data(Date)' passing c.MAIL_DATA as "i")
 as varchar(40)) as DATE
ma_044.jpg

 あとは組み合わせで複雑な条件を指定することも可能です。
 開発したアプリケーションでは、検索条件の指定によりダイナミックにクエリ文を生成します。

ma_045.jpg

メールアーカイブの検索画面(NSEを使わない=非標準の場合)

ちなみに 「大文字と小文字を同一視」というチェックボックスを入れた場合は、

$i/RFC822[Header/Date[contains(.,"Apr")]]

を下記のように変更しています。

$i/RFC822[Header/Date[contains(fn:upper-case(.),"APR")]]


Net Search Extenderによる検索処理


 Net Search Extender(以下NSE)は、DB2用の全文検索用エンジンです。別途インストール操作が必要になります。DB2のデータベースに対し、「テキスト索引」と呼ばれる専用の索引を作成し、高速検索を可能にします。インストール後は、各種保守用のコマンドにより、有効化したり、索引の作成や更新を行います。
 当然ながらXML などの構造化されたテキスト・フォーマットにも対応しており、XPathを指定した任意のノードに対するテキスト検索も可能です。
 NSEの使い方としては「Contain関数」が代表的なもので、Where句の中で指定することにより該当する行を高速に検索します。
 もし先のクエリーをNSEを使用したものに変えたとすると、下記のようになります。

select c.MAIL_ID,c.MAIL_DATE,
 xmlserialize(xmlquery(
 'declare default element namespace
  "http://schemas.eternaldesign.jp/oides/mail2xml" ;
  $i/RFC822/Header/fn:data(Date)' passing c.MAIL_DATA as "i")
 as varchar(40)) as DATE
 from MAIL_ARC.MAIL_DB c
where c.MAIL_DATE >= '20080501000000' and
contains(MAIL_DATA,' section("/RFC822/Header/Date") "Apr" ')=1
order by c.MAIL_DATE fetch first 10 rows only

 「section」を指定することにより、XMLのノードを指定することが可能です。(指定しなければ、任意のテキストを検索します。)
 複数の条件をAND条件で検索する場合は下記のような構文になります。

contains(MAIL_DATA,' section("/RFC822/Body/Data/Body")  "見積"
 & section("/RFC822/Body/Data/Body") "訪問" ')=1
XQueryなどとは、微妙に式の連結方法や構文が異なりますが、たとえ混在しても動作するというのは面白いものだと思います。
 ついでにNSEモードに変更したときの検索画面を掲載しておきます。(アプリケーションとしては、こちらのモードでの利用が主たるものになります。)

ma_046.jpg

メールアーカイブの検索画面(NSEを使う=標準の場合)


 NSEの最大のメリットはなんと言っても「高速な検索」です。純粋なXQuery(SQL/XML)による検索ではストレスが多少あったものも、処理をNSEに置き換えることにより、全くなくなりました。また、大文字や小文字の混在を気にしなくても良いというメリットもあります。メールアドレスなど、リレーショナルデータでは、大文字・小文字が混在すると、違うデータ扱いになりますが、NSEの検索では、これを気にしなくても済むようになりす。
 その他、Highlight関数による検索結果の表示機能など有用な機能も幾つかあります。

 さて、良いところばかり並べましたが、NSEを使う上での問題点を上げると、「テキスト索引の更新に多少時間がかかる」ということです。
 メールアーカイブの場合は、定期的な処理として、メールの取り込み時にテキスト索引も一緒に更新しますから、特に大きな問題にはなり得ませんが、リアルタイム性が要求されるようなシステムの場合はテキスト索引の更新処理についても若干の考慮が必要になりそうです。(索引の更新は差分で行われますが、データ量が大きくなればなるほど索引の更新処理に要する処理時間は顕著になるような気がします。)




カテゴリ
DB2
mail

MAGIC V10解析(12)

DB2のXML部分更新機能の利用について


 ちょっとご無沙汰してました。
 暑い日が続きますが、皆さん体調崩してないでしょうか?(私は元気にしています。)

 さて、いろいろと研究活動は進めていたんですが、忙しさに追われてしまい、このブログもしばしサボってしまいました。「まとめ作業」をして残しておかないといけないものが幾つかあるので、また少し気合を入れなおしてみたいと思います。
 何しろ私自身が忘れてしまわないように・・・。

 さて、DB2をいじり始めて1年、XQueryも多少は書けるようになり、個人的には「新たな世界」を垣間見ることができ、自己満足気味でもあるんです。w
 そこで無謀にも、次なる「MAGIC V10 & DB2」のテーマとして掲げようとしているのが「リポジトリ入出力ファイルの置換処理」です。
 完結できるのかどうかも分かりませんが、しばし「MAGIC V10解析」はこの話題で進めて参ります。

 ところでDB2のXML更新機能についてですが、Version9.1までは、全てドキュメント丸ごと更新を行うしかなかったのですが、Version9.5からは、部分更新が可能になっています。
 9.5になって、「PureXML」も全開状態になったわけですね。
 これを使って、ソースファイルや、リポジトリ入出力ファイルの中に記述されたオブジェクト(モデルやデータソース、プログラム)などを置換することを考えてみようと思っています。

 XML部分更新機能については、MAGICの関数でもできるじゃないの?と言われそうですが、使えるときもあるし、使えないこともあるわけで、適材適所で使うと、もっと面白いことができるのではないかというのがこの企画の趣旨なわけです!
 ここで、MAGICとDB2のXML関連の全般的な処理についてまとめてみました。
 見て頂けるとなんとなくお分かり頂けるのではないかと思うんですが、「お互いに補い合う関係」にあるわけですね。

 
MAGICのXML関連処理の特長

  • XMLExist 、XMLGet 等の関数は直接的でプログラムする際はそれなりに使いやすい
  • どちらかと言うと、シーケンシャルに舐めてアクセスする方式
  • XPathの指定はフルパス記述なもののみで、条件を含めた指定ができない
  • XML Database(MAGIC独自のテーブル)と組み合わせて利用が可能
  • 複数のXMLドキュメントに対してQueryを実行するような機能は無い
  • XMLInsert 、XMLModify 、XMLDelete 関数等で部分更新可能

DB2=XQueryによるXML関連処理の特長

  • 条件を含めたXPathを指定することができるので、ランダムアクセス的な検索が可能
  • XQueryの数式コンストラクタを使って結果の出力を自由に整形できる
  • 条件判定などをXQueryに行わせることができるが、結果の整形的なものを行わせるにしか過ぎず、処理的にはアプリ側に委ねられる宿命
  • 複数行に亘るドキュメントの検索も可能(SQL/XML)
  • 場合によっては全文検索エンジンもあり
  • insert、modify、delete関数による部分更新が可能
    (しかし、この処理は、フルパス的にXPathが指定されねばならないようで、MAGICの仕様に似ている...詳細はまたの機会に...)



リポジトリ入出力ファイルの置換処理


 今回のテーマとして、特に想定しているのが、コンポーネントを利用したアプリケーションのケースです。
 コンポーネントで作成したオブジェクト(プログラム等)をホストアプリに持って来たい・・・とか、逆にホストアプリで作成したものをコンポーネントに移動したい・・・というような場面に遭遇したことはないでしょうか?(えっ、コンポーネントは使っていない?(^^;)

 実はその時に困ることが幾つかあります。

 既に経験された方ならお分かりかと思いますが、まず第一にやっかいなのがテーブル(データソース)の番号がズレてしまうことではないでしょうか?
 何故なら、一緒にカラムの番号が抜け落ちてしまうからです。プログラムの場合はリンクが外れてしまっても番号を合わせ直すだけでなんとか修復できますから、割とダメージは軽いと思います。
 これを手で修復しているうちに、「あぁ、コンポーネントにしなければ良かった?」なんて後悔してしまうようではダメなわけです。

 もう一つ、厄介なのが「モデルの出力」を実行したときの問題です。

v10db2_101.jpg


 この機能は、コンポーネントのモデルではなくて、1)「ローカルリソースのモデル」を使用しているものを、2)リポジトリ出力ファイルに埋め込んで、3)インポートしたときに自動的に採用してくれる・・・というものです。
 つまりローカルのモデルを移行してくれるものと言って良いでしょう。
 使っているモデルを集約して必要なものだけを持って行ってくれるので、一見便利といえば便利です。
 しかしこれが結構「落とし穴」・・・。
 次のようなケースではちょっと問題が発生します。

  • 出力するプログラムのアプリケーションは持って行きたいアプリケーションのコンポーネントアプリになっている
  • ローカルリソースと言えども既にホストアプリのコンポーネントとして登録されている
  • 開発途上の作業なので、プログラムのリポジトリ入出力操作は度々行われる(一括して一回で終わらない)

 このような場合、入出力を繰り返す度に、同じ目的で作成したモデルが何個も登録されてしまうという悲しい結果になります。
 それを承知の上で使うなら、オブジェクトの置換を何度も繰り返すことになるでしょう。

 一見便利そうなモデルの出力によってなんとも厄介なことになってしまうこの問題は、コンポーネントの構成の方法を次のようにすることによって、割と簡単に回避することが出来ます。

  • モデルのみを登録したコンポーネント(仮に「コンポーネントA」とします)を作成する
  • 他のアプリケーションはコンポーネントであるか否かに関わらず、コンポーネントAを一番最初のコンポーネントに定義する
  • モデルを登録するコンポーネントは極力コンポーネントAのみとする

 さて、どうして回避できるかというと、「モデルの出力」を指定しても出力されない・・・からです。
 あくまでもローカルリソースのモデルが対象となるので、コンポーネントに登録されたモデルのみであれば、そのまま移行されます。

 但し、コンポーネント-ホストアプリケーション間でコンポーネントインタフェースファイル(ECIファイル)は統一されていて、最新の状態に保持(「再読込」により更新)されていることが条件ですね。


 なんか少し話題がズレましたが、上記のような問題を回避するために考えたわけです。
要約すると、

  1. ホスト-コンポーネントのプロジェクト相互の関連があるなら、
  2. それらの間のオブジェクトの情報入替えを自動的に行い、
  3. 自由にプロジェクト間で、プログラムソースの利用ができるようにする
  4. そのためのツールをDB2のXML更新機能を使って作ろう

・・・ということです。
 言い換えれば、「コンポーネントアプリ完全征服のための無敵ツールを作る」というこです。「コンポーネントを制することができずしてMAGIC開発は有り得ない」・・・ということですね!(すげぇ...w)




リポジトリ入出力ファイルとプログラムソースの違い


 話はいきなり変わりますが、リポジトリ入出力ファイルの仕様に関して、ちょっと触れておきましょう。
 皆さんは、同じプログラムについて、リポジトリファイルとして出力したものと、開発中のソース用フォルダに格納されているソースファイルで内容が異なることをご存知でしょうか?
 「そんな馬鹿な?」と思ったかたは、実際に試してみてくださいね。
 「そんなの常識でしょ」と言えたかたは、多分、相当な「MAGIC通」だと思います。


相違点

  • オブジェクトの番号の意味が異なる
  • リポジトリ入出力ファイルでは、ソース内に保持していた「内部番号」などの属性が抜け落ちる
  • モデルの出力オプションによる情報の付加などの違い
  • その他


上記のことは、「リポジトリファイルのオブジェクト置換」を行う上での重要な問題になるので、詳細については、次回、じっくりと説明させて頂きたいと思います。
 なんか今日は迷言だらけになってしまいました。すんません。




おまけ


 最近、ある人とメールでやり取りしている際に、MAGICの話題になったんですが、今まで知らない機能があることを知りました。
 それは、色テーブル(オプション→設定→基本色)やフォントテーブル(オプション→設定→フォント)で「オブジェクトの置換」ができるというものです。
 実際的にはモデルの色番号や、フォント番号を一括で置き換えるというもののようですね。
 さて、皆さんはご存知でしたでしょうか?

 もうMAGIC始めてかれこれ20年になりますが、まだいろいろと未知な機能があるようです!
(何かの機会に20周年記念をせねば・・・!w)






カテゴリ
dbMAGIC
DB2

DB2のアクセスプラン


アクセスプランって何?


 某勉強会でここ数ヶ月のテーマになっているアクセスプランなのですが、いつも講義を受けっぱなしという状態だったので、そこから少し脱却すべく、最近の週末の休みを利用して、自分でいじってみました。(いわゆる復習というヤツです。)
 「アクセスプランって何だ?」という話をしだすとちょっと長くなるのでやめておきたいのですが、一言だけ・・・。
 私がこの単語(アクセスプラン)を知ったのは正直に言えばまだ1年位前のことにしかなりません。SQL系のRDBMSでは当たり前の話のようですが、それ以前はDB2のようなインテリジェンスなRDBMSは使っていませんでしたので・・・。
 私がそれまで持っていた概念としては、「インデックスを使ったアクセスは常に速い!」とか、「インデックスを使わせるために、そのインデックスの項目をORDER BY句に入れれば良いじゃん!」とか、そういう固定的な観念がありました。
 しかし、どうやら最近のRDBMSは違う様です・・・。
 インデックスを使うように仕向けても、使ってくれないことがあるようですし、インデックススキャンになるか表スキャンになるかはSQLオプティマイザー次第だとか、その他もろもろ・・・。
 まず、ここにショックを受けたわけですね。



とりあえず取得ツールを作る


 アクセスプランが何かという話の詳細は、「DB2 UDB アクセス・プラン速習」という有名な連載記事がありまして、詳しく書かれていますので是非ご参照下さい。 (私も目下勉強中です。(^^;)

 何をすれば良いかというと、(1)詳細なEXPLAINの取得(2)SQLの実行時間の計測です。
 EXPLAINの取得は、SQL文を用意し、スクリプトを実行します。
 次のような処理を記載したバッチファイルを作成し、引数にスクリプト名を付けて実行すればOKです。
db2 connect to sample
db2 set current explain mode explain
db2 -tf %1.sql
db2 set current explain mode no
db2exfmt -d sample -e db2admin -n %% -s %% -w -1 -# 0 -o %1exp.txt
ここで、sampleはデータベース、db2adminはスキーマ名なので、適当に修正する必要があります。
 なお、このバッチファイルは、2段階になっていて、データベースに接続するところから始まりexplain mode を切り替えてSQLを実行するまでの部分と、その後のdb2exfmtを実行する部分です。

 SQLの実行時間の計測については、db2batchユーティリティを起動します。下記のようなバッチファイル作成して実行すればOKです。
db2batch -d sample -f %1.sql -o p 3 e 2 -r %1p.txt

 確かに両者ともスクリプトでできるのですが、日頃の開発作業の現場では、スクリプトはどこにあったのかを探したり、それをまた書き直したりするのが結構煩わしいですし、何をどうすれば良いのかすら忘れてしまいがちです。ということで、私の場合は、某ツールを使ってGUIのフォームを作ってみました。
 下記の画面がソレです。

db2_tool_01.jpg


 プログラムといっても、入力テキストをファイルに書き出したり、実行するプログラムをコールする程度のものなので、週末の半日もあれば出来上がります。
 操作はコントロールセンターと同じようなインタフェースにしました。データベースをコンボボックスで選択して、スクリプトを貼り付けてから実行ボタンを押せば、結果がタブに表示されるという仕組みです。

db2_tool_12.jpg

 まぁ、スクリプトをいちいち修正しながらテストするよりは気が利いているのではないでしょうか?
(次の解析ツールのバージョンアップ版には組み込んで、使えるようにしたいと思っています。)

 工夫した点は次の箇所です。

  • データベースの一覧を取得するようにして、コンボボックスで切り替えできるようにしました。
    起動時に、「list database directory」を実行して一覧を取得しています。
  • デリミタを指定できるようにしました。
     XQueryを含むSQL文では、セミコロンは使われるので、デリミタ指定は必要な機能ですね。
     それとSQL文の記載で末尾等に入力を省略してしまった場合は、内部的に自動付加するようにしてあります。これをしないと、何故かdb2batchでは結果が全く出てこないみたいで・・・。
     ちなみに、db2batchを起動する場合に、デリミタの指定は読み込ませるSQL文を記載したファイルの先頭に「--#SET DELIMITER #」等を付加しなければならないようです。
  • スクリプト実行時にログを書き出し、そのテキストで処理結果を判定できるようにしました。
     スクリプトの実行は「db2cmd」で行い、「-z」オプションによりログを書き出すようにしてあります。 このログでの結果取得は後の処理判定で利用されます。もしSQL文にエラーが無い場合は良いのですが、エラーがあった場合は後のdb2exfmt等を実行しないようにしています。というのは、最新の取得済みExplainがあれば、毎回そのデータで出力を作成しまうからです。
     ちなみに、正常に処理された場合は、「情報の要求だけが実行されており・・・」というメッセージが表示されるようです。
  • 結果をタブで切り替えられるようにしました。
    処理が正常に終了すると、自動的に「アクセスプラン」のタブを表示します。

    db2_tool_02.jpg

     この画面に出力結果が表示されます。
     内容の正しい把握には、かなりの修練が必要となりますが・・・。w

  • db2batchも実行し、ベンチマーク結果も取得できるようにしました。
     せっかくなので、ベンチマーク結果も取得できるようにしました。(煩わしい場合もあるかなということで、オプション指定により実行しないようにも設定できるようにしてあります。また、出力のレベルオプション「-o p 3」も指定できるようにしてあります。)

    db2_tool_03.jpg

     ちなみに、出力結果はファイルで保存し、表示はie(Internet Explorer)のコンポーネントを利用して表示するようにしました。これにより、タブを切り替えても、表示位置を残すことができ、2つの結果画面を比較しながら操作することも可能です。

動かして結果を見てみよう!



 私の関心の中心はXMLなので、SQL/XMLや、XQueryのクエリーで検証を実行してみました。
 また、実際のサイズの異なるXML文書での検証を行ってみました。

A. テーブル全体にアクセスするケースで検証する

 まず、Where句で曖昧検索を指定し、テーブル全体にアクセスするようなパターンを2種。

  1. XQueryで件数を取得する

     下記のスクリプトは、アーカイブのデータから、送信先メールアドレスに"IBM"を含むメールの件数を取得するためのものです。
    select count(*) from MAIL_ARC.MAIL_DB c 
    where xmlexists(
    'declare default element namespace
    "http://schemas.eternaldesign.jp/oides/mail2xml" ;
    $i/RFC822/Header/To[contains(fn:upper-case(.),"IBM")] '
    passing c.MAIL_DATA as "i")
    このスクリプトのEXPLAINを見ると、元のSQL文に対して、最適化されたSQL文が表示されているのですが、XML用に内部的な処理がされていることが分かります。

    db2_tool_04.jpg

     次にアクセスプランの図です。下図の赤枠の部分のテーブルスキャン(TBSCAN)の箇所のI/Oコストの4295は、表の全ページの値と一致しており、総なめになっています。
     XML索引を作れば改善されるかという話もあるのですが、今回の例のように「Contain」関数を使った場合は索引は使われないと推測します。

    db2_tool_05.jpg

    db2_tool_06.jpg

  2. 全文検索エンジンで件数を取得する

     下記のスクリプトは、1と同じような条件のメール件数をカウントするものですが、XQueryではなく全文検索エンジン(Net Search Extender)を使用したものです。
    select count(*) from MAIL_ARC.MAIL_DB c
    where CONTAINS(
    MAIL_DATA,'section("/RFC822/Header/To") "IBM"'
    )=1
    取得したEXPLAINを見てみましょう。
     今回もDB2がステートメントを最適化しているのが分かります。

    db2_tool_07.jpg

     アクセスプランを見ても、表現上は表スキャン(TBSCAN)ですが、実際はNSEの索引を使ってアクセスするので、I/Oコスト(=索引の使用ページ数?)も11という値になっています。

    db2_tool_08.jpg
    db2_tool_09.jpg
  3. ベンチマーク結果の比較

    1と2の処理をベンチマーク結果で比較してみたものを下表に示します。

    処理のタイプ XQuery NSE
    経過時間 18.073455 秒 3.326436 秒
    バッファー・プール・データ論理読み取り 4918 8
    バッファー・プール・データ物理読み取り 9 0
    バッファー・プール一時データ論理読み取り 1 0
    バッファー・プール索引論理読み取り 782 187
    バッファー・プール索引物理読み取り 0 22
    バッファー・プール xda 論理読み取り 644 0
    バッファー・プール xda 物理読み取り 0 0
    バッファー・プール一時 xda 論理読み取り 170 0
    バッファー・プール読み取り時間の合計 (ミリ秒) 188 219
    プリフェッチ待機時間 (ミリ秒) 2267 0
    直接読み取り 12 24
    直接読み取り要求 3 4
    直接読み取り経過時間 (ミリ秒) 14 0
    読み取り行数 52169 4
    書き込み行数 0 0
    エージェントによって使用される合計ユーザー CPU 時間 (秒) 0.546875 0.0625
    ホスト実行経過時間 5.59027 1.082779
    最後に完了したステートメントの経過時間 (sec.ms) 0.177223 0.136443
    ステートメント・ユーザー CPU 合計時間 2.53125 0.03125
    ステートメント・システム CPU 合計時間 0 0.03125
    timeron 時の SQL コンパイラー・コスト見積もり 535550 12

     今回の結果は、XQueryのケースに対しては、厳しい条件での結果となってしまいましたが、  Where句での絞り込みを行う場合は、最悪全レコード総なめ(テーブルスキャン)を覚悟しなければならないことを示していると思います。

B. 同じスキーマの異なる文書に対するアクセスで検証する

 次に、同じスキーマの異なるXMLドキュメントに対してXQueryのアクセスプランを取ってみます。
 実行するクエリーは某ツールのプログラムソースから、利用しているオブジェクトを抽出するためのもので、そのオブジェクトの番号と位置を取得するためのものです。
select xmlquery('
<Datas>{
for $e in
$i/Application//Task/TaskLogic/LogicUnit/LogicLines/LogicLine/
CallTask[OperationType/@val="P" and fn:exists(TaskID/@obj)]
return
<Data>
{attribute TNm {fn:string($e/../../../../../Header/@Description)}}
{attribute TId {fn:string($e/../../../../../Header/@ISN_2)}}
{attribute Cmp {fn:string($e/TaskID/@comp)}}
{attribute Obj {fn:string($e/TaskID/@obj)}}
</Data>
}</Datas>'
passing c.ITEM as "i")
from DB2MRCA.PSOURCE c
where c.SOURCEID=nnn
最後の"nnn"のところには、異なる2つの番号が入るのですが、下記のようにそれぞれファイルサイズが大きく異なる2つのドキュメントを指定します。

SOURCEID 
ファイルサイズ
284
10,706KB
304
91KB

 さて、EXPLAINの結果は変わるでしょうか?

db2_tool_10.jpg

 アクセスプランを見ると、「GENROW」という内部で生成した表を作成し、「XSCAN」という「for」文で指定したXPATHの検索との結合を行っており、ほとんどのコストはその部分で費やされているのが分かります。

db2_tool_11.jpg

 結果ですが、実行した時刻とソース内で指定した番号が異なるだけでした。つまりEXPLAIN自体は変わりません。
 それでは、ベンチマークのほうで違いを見てみることにします。
 下記の表は、経過時間とアプリケーションのスナップショットを取得した際の違いの出た主な項目です。

Where句で指定したSOURCEIDの値
(データの番号)
304 284
経過時間 0.478864 秒 5.178961 秒
バッファー・プール一時データ論理読み取り 1 637
バッファー・プール索引論理読み取り 117 3324
バッファー・プール索引物理読み取り 1 4
バッファー・プール xda 論理読み取り 205 5715
バッファー・プール xda 物理読み取り 0 24
バッファー・プール一時 xda 論理読み取り 145 2797
バッファー・プール読み取り時間の合計 (ミリ秒) 0 152
プリフェッチ待機時間 (ミリ秒) 0 823
読み取り行数 2 317
書き込み行数 0 310
エージェントによって使用される合計ユーザー CPU 時間 (秒) 0.015625 0.515625
ホスト実行経過時間 0.154833 1.603549
最後に完了したステートメントの経過時間 (sec.ms) 0.00025 0.00005
ステートメント・ユーザー CPU 合計時間 0.015625 0.515625

 見て頂ければお分かりのように、値の違いは顕著に現れています。
 推測するに、内部的に処理されたXML行(GENROW)のサイズによるものと思われます。
 結論的には、統計情報として取得される値は、目安的なものといってよく、実測しないと分からないということのようです。

 それでは、アクセスプランで表示されるコストなどの数値(I/O Cost=16、Total Cost=170.574 等)は何を根拠に算出されているのでしょう?
 これは今のところよく分かりません。(どなたか教えて下さい。)



まとめ


  • XML関連のクエリーに対しても、アクセスプランやベンチマークの取得を、通常のクエリーと同じようにDB2のツールを使って検証することが可能です。
  • XQUeryをWhere句で使うような場合は、高コストの表スキャンになることを覚悟しなければならないので、アプリケーションに実装する上では良く考慮すべきです。全文検索エンジンを利用すべきと思われます。
  • データサイズの違うオブジェクトに対して、XQueryを実行する場合は、アクセスプランでは代表的な数値を用いてコストを表示しているようなので、実際の値を得るにはベンチマーク等を実行して確認する必要があります。




DB2のLockを捕まえる・・・(1)

 ご無沙汰してました。
 これだけブランクがあいてしまうと、どこからどうやって再開していいものか悩むんですが、まずは「最近、こんなものを作ってみました~!」というのを幾つか紹介していこうと思います。


DB2の問題判別ツール


 さて今回はDB2に関する話題です。
 DB2と言えば、先々月(6/14)、DB2の新しいバージョン(DB2 Ver9.7)がリリースされました。7月の初めにはイベントがあったり、解説本が出たり、また幾つかのIT系の雑誌などにも紹介されたりしましたので、徐々にその全貌が知られつつあるかと思います。
 実は私のほうでは、β版なるものを半年ほど前から評価させて頂いていたのですが、なかなか忙しくて新機能などを試すことができず、専ら9.5で動作していたアプリケーション(某ツール)を動かしてみる程度でした。まぁ、現時点の状況も同じ程度なのですが(実は、この間、9.7の障害対応等に追われていまして・・・(^^;)、徐々に試してみて、またここで紹介していきたいと思います。

 今回ご紹介するのは「db2pd」というDB2のツールです。いわゆる「問題判別に利用するコマンドラインツール」というものです。
 IBMのサイトでも使用法を解説したPDFが提供されています。

 db2pd コマンド使用ガイド

 さて、そのドキュメントによると、下記のような特長があるとのことです。

  • スタンドアローンのユーティリティでデータベースに接続せずに使うことができる
  • Informix のonstat ユーティリティに良く似ており、onstat と同様の使用方法、機能を持っている
  • コマンドラインから実行する。対話モードでの実行も可能
  • スナップショット・モニターやイベント・モニターと異なり内部的にロックやラッチを取らない。したがって、高速に実行することができ、かつ、データベース本体へ与える影響が小さい
  • DB2 エンジンの外で実行されるので、DB2 エンジンがハングしている状態でも使用可能である
  • DB2 エンジンに、より近い情報を取得することができる

 ここで重要なのは、「DB2 が使用しているメモリー上の情報を読み取って解析」しているという点です。「ハングアップした状態でも使用可能」とありますが、当然ながら(ハングアップしていない)アプリケーションの実行中でもその動作状況に影響を与えずに情報の取得ができるということです。
 コマンドラインのオプションが多数あって、アプリケーション、トランザクション、ロック、SQLステートメント等、さまざまな情報を取得することが可能です。
 このツール、私が良く行かせて頂いているクラブDB2でもいわゆる「お勧めツール」の筆頭に挙げられていまして、紹介される度に「いつかマスターしなくては・・・」と思っておりました。


db2pdを動かしてみる


 それでは、手始めに、db2pdを使ってOS情報を取得してみましょう。
 通常、DB2のコマンドはいわゆる「CLP」というDB2のコマンドプロンプトで起動するんですが、このツールの場合は、普通の「DOS窓」でもOKです。もしWindows XPの環境ならスタートメニューから「ファイル名を指定して実行」を開き、「cmd」と打って下さい(もちろんCLPを起動してもOKです!)。
 コマンドプロンプトが現れたら、次のように入力します。
db2pd -osinfo
結果が画面に表示されましたか?正常に起動するとOSやCPU、メモリ等の情報を表示してくれます。

v092_21.jpg

db2pdによりOS情報を取得した画面



 今度は、少し複雑になりますが、アプリケーションに関する情報を取得してみます。適当なデータベースに接続して次のコマンドを実行します。
db2pd -db データベース名 -applications

 「データベース名」にはアクティブに接続しているデータベースの名称を指定します。 

さて、結果はどうなりましたか?

v092_22.jpg

db2pdによりApplication情報を取得・・・。行が折り返されて見辛い・・・。


 実はこの出力結果は、改行までの横幅が206~320バイトあるので、折り返してしまうのです。
 もう少し見易くするには、DOS窓のプロパティを変更すると解決します。

v092_23.jpg

DOS窓のプロパティで設定値を変更してみる・・・


 「レイアウト」タブを開き、画面バッファのサイズの「幅」を320に変更します。

v092_24.jpg

画面バッファのサイズを320程度に変更します。


 更に、若干フォントサイズも小さく(「6 x 13」等を選択)すると良いかもしれません。OKボタンを押して変更結果を反映させます。プロパティの適用確認画面が出たら取り敢えず最初は「現在のウインドウだけに適用する」を選択して下さい。
 さて結果は如何でしょうか?(コマンドを再実行する必要があります)今度はだいぶ見易くなりました!

v092_25.jpg

今度は行が折り返されなくなったのでだいぶ見易くなった・・・。

ディスプレイの解像度が良ければウインドウを広げたり、画面下のスクロールバーをスライドさせると隠れている部分も見えるようになります。フォントサイズも小さくできるのですが、あまり小さくしすぎて読めなくなってしまってはしょうがないですね。
 こういうときはファイルに出力して、メモ帳や、もう少し気の利いたテキストエディタで読むと良いかもしれません。
 結果をファイルに出力するためには、次のようにオプションを加えます。
db2pd -db データベース名 -applications -file ファイル名

 「-file ファイル名」の代わりに、「file=ファイル名」でもOKのようです。勿論OSの機能を使ってリダイレクトで出力する手もありますが・・・。


今回のまとめ


 db2pdの出力は、メモリ内に格納している状態を表形式で出力するのですが、独特な情報なので馴染むには若干の慣れが必要かもしれません。

でも、習得することによって、DB2の仕組みに近い情報を理解することができるのではないかと期待させてくれます。
 次回は、もう少し高度なdb2pdの使い方と、作成したツールについて説明しようと思います。



カテゴリ
dbMAGIC
DB2