当ハンズオンの進め方 13:00 14:00 17:00 18:00 オープニング BLUご紹介（講義) ハンズオン クロージング

Presentation on theme: "当ハンズオンの進め方 13:00 14:00 17:00 18:00 オープニング BLUご紹介（講義) ハンズオン クロージング"— Presentation transcript:

0 D B 2 B L U Acceleration H a n d s - O n @ C l o u d

1 当ハンズオンの進め方 13:00 14:00 17:00 18:00 オープニング BLUご紹介（講義) ハンズオン クロージング
DB2 BLUの簡単なご紹介をさせていただきます。 視聴ご不要の方は14:00少し前に参加ください。 14:00 ハンズオン ハンズオン進め方のご案内 手順書に沿って各自のペースでハンズオンをお進めください。（接続まではご一緒にやります) 全体の休憩時間等は設けませんので、皆様のペースで適宜、ご休憩ください。 講師がリモートで待機しておりますので、ご質問があれば電話やチャットでお声かけください。 早く終了された方はご退席していただいても結構です。（その場合、講師に一声おかけください） 17:00 クロージング QAタイム 別途、アンケートへのご回答を願いたく存じます。 18:00 環境シャットダウン

2 当ハンズオンでご体験いただくこと DB2 V10.5を導入しましょう データベースを作成しましょう カラム型テーブルを触ってみましょう
性能測定しましょう（従来型テーブルとの比較) お時間がある方は、こちら↓もどうぞ。 チューニング(Query Workload Tuner)

3 ハンズオン環境 Windows2008 64bit リモート･デスクトップ接続 X-Client JMETER インターネット
VNC Client QWT クラウドセンター内通信 皆様のPC DB2 Server MYDB BLUDB RHEL bit

4 当ハンズオン環境固有のお約束 Windowsのリモート・デスクトップ接続を使います Windows2008/ RHEL6.4を各1台使います
皆様のPCからクラウド環境へはリモートデスクトップで接続します。 リモートデスクトップが利用可能なPCをご準備ください。 Windows2008/ RHEL6.4を各1台使います 皆様お一人ずつにクラウド上の上記仮想マシンを各1台づつ割り当てます。 割り当てる仮想マシンやIPアドレスはすべて違うものです。 RHEL(DB2 サーバー)への操作はすべてWindows 2008上の(TeraTermなどの)クライアントから行います。 皆様のPCにLinuxのためのソフトを準備いただく必要はありません。 ×仮想マシンは「シャットダウン」しないでください 本日のハンズオンの手順で再起動が必要な箇所はありません。 万が一、誤って「シャットダウン」すると、ご自身ではブートできません。ホスト名やIPアドレスも変わってしまいます。(ハングしてしまった、など止むうえない事情の場合は「リブート」にしてください。リブートならホスト名やIPアドレスは変わりません。） パフォーマンス 諸般の事情により、本日の環境は本来のBLUの推奨環境を下回っていますのでデータの規模も抑えてあります。皆様が実サーバーで実施する場合よりも遅いでしょうが、その点、ご容赦ください。

5 ハンズオン環境のメモ 項目 ホスト名 IPアドレス ユーザーID Administrator 1) ec2-user 2) root
Windows bit(x64) RHEL bit(x64) ホスト名 メールでリモートデスクトップ接続のファイル(*.rdp)をお送りします。 未使用 IPアドレス 実施当日にメールでご連絡します ユーザーID Administrator 1) ec2-user 2) root Password(共通) Passw0rd (oオーではなく0ゼロです) ディスク C:\HandsOn /handson スクリプト類 /db1-/db データベース /work　　 導入イメージと 　　　　　　　　　　ロード用データ

6 ご参考) 本日利用する仮想マシンの仕様 1 4 2 13 3.75GB 15GB Windows2008 64bit(x64)
ご参考)　本日利用する仮想マシンの仕様 Windows bit(x64) RHEL bit(x64) インスタンス・タイプ m1.medium x3.large vCPU 1 4 ECU(※) 2 13 メモリー 3.75GB 15GB ディスク 30GB(C:\) 7GB(/) +40GB (/db1～/db4各10GBを4本) +10GB (/work) ミドルウエア DB2 Advanced Enterprise Edition 10.5 CPU Option データ量1TB前後の小規模構成でのBLUの推奨は16コア/128～256GBなので、それに比べるとハンズオン環境は貧弱なのですが、今日は利用するユーザーデータ量が5GBと小さいのでメモリにデータが全部乗ります。 ※...ECU＝Amazon EC2 Compute Unitの略。AMAZON EC2での相対的なCPU能力を表す指標です。

7 当節は当日rdpファイルご受領後、午前中に先に実施しておいてください。 (勿論、ご多忙であればハンズオンの冒頭でご実施いただいて結構ですが、 万が一接続できないとその後が続行できませんので、念のため早めのご確認をお勧めしております.) D I V E I N T O T H E C L O U D

8 お一人にWindows2008環境とRHEL環境を各1台ずつ割り当ててあります。
本日のハンズオンはすべてWindows2008上での操作になります。ただし、X-クライアントやVNC Viewerを使った操作では、実際の操作はRHEL上で行なっていることになります。どちらのマシンで操作しているのかを明確にするために、以下、当資料ではRHEL上での操作の場合は右上に以下の記号を記載してあります。 ハンズオンの内容とは直接関係がありませんが、知っておくと良いと思うFYI 的なご説明は緑色のコメントで表記します。 Windows RHEL RHEL

9 クラウドへのログイン 事前にメールにてお配りした *.rdp をご自身のPCのお好みの場所に保管します。
もし下記のたぐいの警告が出たら「接続」ボタン 「リモートデスクトップ接続」が起動してデスクトップ接続が開きます。 Administratorをクリック。パスワード「Passw0rd」（0=ゼロ)を入力してWindows2008にログオンします。 うまくいかない方は講師にお声かけください。

10 リモートデスクトップに接続できないときのご確認事項
rdpファイルに書いてあるサーバーの名前にpingが通りますか？ C:\Documents and Settings\Administrator>ping ec compute-1.amazonaws.com Pinging ec compute-1.amazonaws.com [ ] with 32 bytes of data: Reply from : bytes=32 time=195ms TTL=96 PCのパーソナル・ファイアーウオールでリモートデスクトップ接続を遮断していませんか？ 御社のインターネット環境でリモートデスクトップ接続が遮断されていませんか？ リモートデスクトップのポート#: TCP　3389　PINGは ICMPです。 これが遮断されている場合は、ポートを開放して頂かないとハンズオンへご参加いただくことができません。

11 RHELサーバーのIPアドレスの確認 IPアドレス RHEL
リモートデスクトップでWindows2008にログインできたら、以降のハンズオンはその環境で操作を行います。当日AMにメールでご連絡済のRHELサーバー(=DB2サーバー)のIPアドレスを以下にメモしておいてください。 皆様にメールでご連絡しているのはセンター内でのプライベートなIPアドレスです。 当該仮想マシンはグローバルなDNS名、グローバルなIPアドレスも割り当て済ですが、 当ハンズオンで利用する必要がないので、お知らせしていません。 IPアドレス RHEL

12 まずはLinuxサーバへのログインです。 TeraTerm / puttyのお好きな方をお使いください。
ネットワーク環境の確認(ping) Windows 2008のコマンドプロンプトを開きます。 Windows2008からRHELサーバーに対してpingを打ち、通信が可能なことを確認してください。 ping RHELサーバーのIPアドレス では、ハンズオンを開始しましょう！ まずはLinuxサーバへのログインです。 TeraTerm / puttyのお好きな方をお使いください。 TeraTerm派の方 →次のページへ putty派の方 →p17へ

13 Linuxサーバーへのログイン（TeraTermの場合)
以下を入力/選択して「OK」ボタン ホスト：割り当てられたIPアドレス TCPポート#: 22 サービス: SSHを選択(確認のみ)

14 セキュリティ警告は無視してそのまま「接続」ボタン
ユーザー名に以下を指定 ec2-user (英語小文字) 「RSA/DSA鍵を使う」の「秘密鍵」ボタン パネルが開いたら「デスクトップ」上の以下のファイルを選択して「開く」ボタン BLU.ppk

15 秘密鍵に入力できたら「OK」ボタン ec2-userでログインできました

16 ec2-userでログインできたら、以下でrootになります。 su - root ( - ... ハイフンです)
パスワード: Passw0rd Enter rootでログインできました! TeraTermのフォントサイズや背景の色は「設定」-「ウインドウ」「フォント」で変更可能です。お好みに合わせてご変更ください。

17 Linuxサーバーへのログイン（puttyの場合)
デスクトップ上のputtyjpをダブルクリック 左のパネルで「実行」ボタン

18 ① 以下を入力/選択 「セッションの読込、保存、削除」で BLUをダブルクリック 又は BLUを選択して「読込」ボタン
ホスト名：割り当てられたIPアドレス ポート#: 22 接続タイプ: SSHを選択(確認のみ) 「開く」ボタン 「BLU」の名前で、事前に文字コード(UTF8(CJK))やRSA鍵ファイル名を定義してあります。 ①

19 左記の警告は無視して「はい」ボタン ウインドウが開き、login as: が表示されたら以下を入力してEnter ec2-user ec2-userでログインできたら、以下でrootになります。 su - root ( ハイフンです) パスワード: Passw0rd Enter rootでログインできました!

20 I N S T A L L D B 2 B L U

21 GUI画面の起動(VNCクライアント) DB2は非GUI環境でコマンドにより導入することも可能ですが、今回はGUIで導入しましょう。
デスクトップ上のvncviewerのアイコンをダブルクリック 左記の警告は無視して「実行」ボタン 以下を入力して「OK」ボタン Server : 割り当てられたIPアドレス:1　(：=コロン) :1はLinux上で稼働しているvncserverの１番目のセッション画面を使いますよ、という意味です。

22 RHEL 以下を入力して｢OK」ボタン Password: Passw0rd LinuxのGUI画面が表示されました
このパスワードはvncserverで事前に定義済のもの。OSのパスワードではありません。 LinuxのGUI画面が表示されました ユーザーとしてはrootでログインしています

23 左上の「アプリケーション」から以下を選択
RHEL 左上の「アプリケーション」から以下を選択 「システム・ツール」- 「端末」 コマンド行端末のウインドウが開きました

24 DB2 V10.5 を導入しましょう（簡単です) RHEL ではDB2のインストーラーを起動しましょう コマンドで以下を入力
cd　/work/images/server ls にて db2setupがあることを確認 ./db2setup しばらくお待ち下さい

25 今回導入するのはDB2 10.5 Advanced Enerprise Edition CPU Optionです。
RHEL では導入を始めましょう。 「製品のインストール」を選択 今回導入するのはDB Advanced Enerprise Edition CPU Optionです。 横のスライド・バーを下に移動します。 先頭から「DB2 バージョン10.5 Workgroup Edition, Enterprise Edition およびAdvanced Edition」以降複数のエディションが羅列されていますが、始め「新規インストール」ボタンを探します。 (DB2 Workgroup Server Editionの直下です） LINUX版ではESE/WSE/AESE/AWSEの導入イメージは同じで、登録するライセンスファイルによってエディションと利用できる機能が決まります。 BLUはAdvanced版(AESE/AWSE)でのみ利用できます。 「新規インストール」ボタン

26 RHEL ウイザードが開始したら「次へ」ボタン ライセンスに同意し、「次へ」ボタン

27 RHEL 標準(デフォルト)が選択されていることを確認の上、「次へ」ボタン そのまま「次へ」ボタン

28 DB2は/opt/ibm/db2/V10.5に導入されます
RHEL そのまま「次へ」ボタン DB2は/opt/ibm/db2/V10.5に導入されます 管理サーバーのユーザー情報を設定します。 「新規ユーザー」でユーザーとグループ名はそのまま 「パスワード&パスワードの確認」の各々に以下のパスワードを入力します Passw0rd ユーザーIDやパスワードは上記でなくてもいいのですが、ハンズオン実施上のわかりやすさを優先しています。別のユーザーidやパスワードを指定した場合は以下、読み替えてください。 「次へ」ボタン

29 RHEL 「DB2インスタンスを作成する」にチェックされていることを確認して「次へ」ボタン 「単一パーティション」にチェックされていることを確認して「次へ」ボタン

30 RHEL インスタンス所有者のユーザー情報を設定します。 「新規ユーザー」でユーザーとグループ名はそのまま 「パスワード&パスワードの確認」の各々に以下のパスワードを入力します Passw0rd 「次へ」ボタン fencedユーザーのユーザー情報を設定します。

31 RHEL 今回は通知機能は不要なので「現時点では通知を送信するようにDB2サーバーをセットアップしない」を選択して「次へ」ボタン サマリーパネルに到達したら「完了」ボタン

32 導入が開始したら、しばらくお待ち下さい。 5分くらいです。
RHEL 導入が開始したら、しばらくお待ち下さい。 5分くらいです。 おめでとうございます！導入が完了しました すでにdb2は起動済です。 「完了」ボタンでパネルを終了します。 では次はDB2のライセンスを登録しましょう ライセンス登録をしないと以下のメッセージが出てBLU機能は利用できません。 SQL8029N 要求された機能に対して有効なライセンス・キーが見つかりません。この製品の現行ライセンス・キーでは、要求された機能を実行できません。 IBM担当員または認定販売店からこの機能用のライセンス・キーを購入し、db2licmコマンドを使用してライセンスを更新してください。

33 db2licdコマンドでライセンスを追加します
RHEL db2licdコマンドでライセンスを追加します インストーラのパネルが終了し、端末が開いているので、そこで以下のコマンドを入力します。 現在のユーザーはrootです。 DB2インスタンス管理者であるdb2instにsu します。 DB2 AESE CPUオプションのライセンスファイルは以下 /work/images/db2aese_c.lic 手順 su - db2inst1 db2inst1になります cd /work/images ls -al ライセンスファイルを確認します db2licm -a db2aese_c.lic ライセンスファイルを追加します db2licm -l ライセンス登録状況を表示します ~]$ cd /work/images/ images]$ ls -al 合計 16 drwxrwxrwx 3 root root 月 24 09: drwxrwxrwx 5 root root 月 24 09: -rw-rw-r-- 1 ec2-user ec2-user 月 29 19: db2aese_c.lic drwxr-xr-x 5 root root 月 30 20: server images]$ db2licm -a db2aese_c.lic LIC1402I ライセンスが正常に追加されました。 LIC1426I この製品は現在、ご使用条件の指定に基づいてご使用いただくことができます。 この製品をご使用いただくには、次のディレクトリーにある IBM ご使用条件への同意が必要です: "/opt/ibm/db2/V10.5/license/ja_JP.utf8" images]$ db2licm -l 製品名: "DB2 Advanced Enterprise Server Edition" ライセンス・タイプ: "CPU オプション" 有効期限: "永続" 製品 ID: "db2aese" バージョン情報: "10.5" 制約ポリシー: "ソフト・ストップ" images]$

34 E X P E R I E N C E D B 2 B L U

35 当章でのハンズオンの進め方 RHEL 当章でのハンズオンはTeraTermまたはputtyを使用します。
以降、コマンド端末より、色々なコマンドやSQLを実行していきます。 皆様のキー入力のお手間を省くため、一括実行できるシェルやSQLファイルを以下に準備しています。 C:\Handson　(Windowsのデスクトップにショートカットあり) 各自、下記のお好みの方法でハンズオンをお勧めください。 「いちいちコマンドを打つのが面倒だ。結論を知りたい」という方 シェルやSQLファイルをそのまま実行することで近道ができます。実行して、結果をご確認ください。 「じっくりと、一つずつ結果を見ながら進めたい」という方 上記シェルやSQLファイルをエディターで開き、コピペして一つずつ実行していってください。 (もちろん一から入力するのでもOKですが、、） →こんな感じで、コピペしていけば、楽ができます。

36 (オプション) 最新のdb2diag.logを見られるようにしておきましょう
RHEL (オプション) 最新のdb2diag.logを見られるようにしておきましょう tpch]$ db2diag -f E E LEVEL: Info PID : TID : PROC : db2sysc 0 INSTANCE: db2inst NODE : DB : BLUDB APPHDL : APPID: *LOCAL.db2inst AUTHID : DB2INST HOSTNAME: ip EDUID : EDUNAME: db2agent (BLUDB) 0 FUNCTION: DB2 UDB, data protection services, sqlpinit, probe:1500 DATA #1 : <preformatted> Database is starting up with the following values: Head Extent ID: 0 Log File Size: 1024 Startup Lso: 0 Base Lso: Last Log Record Lso: Current Write Log Extent Limit: E E LEVEL: Warning FUNCTION: DB2 UDB, SQO Memory Management, sqloMemLogPoolConditions, probe:20 Reserved heap size exceeded for Kernel(BSU) Heap on node 0, allocating additional unreserved memory. Requested block size : bytes. Physical heap size : bytes. Configured heap size : bytes. Unreserved memory used by heap : bytes. Unreserved memory left in set : bytes. DB2の実行ログであるdb2diag.logを表示しておくと、DB2の内部的な動きを見ることができます。 前の章の手順でTeraTermかPuttyのコマンド端末をもう一つ起動して、db2diagを常に見られるようにしておきましょう。 TeraTermでは「ファイル」ー「セッションの複製」が操作が簡単です。 ec2-userからdb2inst1にsu してdb2diagコマンドを実行します。 su - db2inst1 パスワードとして「Passw0rd」を入力 db2diag -f これで更新がある都度、最新のメッセージが流れていきます tail -f /home/db2inst1/sqllib/db2dump/db2diag.logと同じ事です。 36 © 2013 IBM Corporation

37 DB2レジストリー・パラメーターを設定しましょう
RHEL DB2レジストリー・パラメーターを設定しましょう 実行例 TeraTermまたはputtyから実行します。 現在のユーザーはrootです。 DB2インスタンス管理者であるdb2instにsu します。 su - db2inst1 実行スクリプトは /handsonにあります。 cd /handson FastPath　 お急ぎの方はこちら。 ./01_start_blu.sh Step by Step　じっくり、の方はこちら。 DB2のレベルを見てみましょう。10.5になっていますね? db2level 現在のDB2レジストリー変数を見てみましょう。 右の2つのみ設定されていることと思います。 db2set handson]# su - db2inst1 ~]$ cd /handson ~]$ ~]$ db2level DB21085I このインスタンスまたはインストール (該当する場合のインスタンス名: "db2inst1") は "64" ビットおよび DB2 コード・リリース "SQL10050" をレベル ID " E" で使用します。 情報トークンは、"DB2v "、"s130528"、"LINUXAMD64105"、およびフィックスパック "0"です。 製品は "/opt/ibm/db2/V10.5" にインストールされています。 ~]$ db2set DB2COMM=TCPIP DB2AUTOSTART=YES 37 © 2013 IBM Corporation

38 db2 -v stop dbm force (or db2stop force)
RHEL BLUアクセラレーションに最適な設定とするため、db2setで「DB2_WORKLOAD=ANALYTICS」を追加して、設定されていることを確認します db2set DB2_WORKLOAD=ANALYTICS db2set 上記を反映するためにDB2を再起動します。 db2 -v stop dbm force (or db2stop force) db2 -v start dbm (or db2start ) ではデータベースを作成しましょう。 データベースの名前は「MYDB」とします。 db2 -v CREATE DB MYDB ON /db1, /db2,/db3,/db4 AUTOCONFIGURE USING MEM_PERCENT 80 APPLY DB AND DBM 「MYDBという名前のDBを/db1-/db4上に作れ」 「搭載メモリの80%を使って自動チューニングしろ」との指示。 MYDBは文字コードUTF-8(デフォルト)で作成されます。BLU AccelerationではUTF-8以外の文字コードはサポートしていませんのでご注意ください。 当環境ではディスクが遅いので/db1～/db4の4本入れて多重度を上げています。 ~]$ db2set DB2_WORKLOAD=ANALYTICS ~]$ db2set DB2_WORKLOAD=ANALYTICS DB2COMM=TCPIP DB2AUTOSTART=YES →この設定により、以降作成されるデータベースではBLUに最適な設定が自動的に行われ、新規に作成するテーブルはカラム型がデフォルトになります。便利です。 ~]$ db2 -v stop dbm force stop dbm force DB20000I STOP DATABASE MANAGER コマンドが正常に完了しました。 ~]$ db2 -v start dbm start dbm DB20000I START DATABASE MANAGER コマンドが正常に完了しました。 ~]$ db2 -v start dbmdb2 -v CREATE DB MYDB ON /db1,/db2,/db3,/db4 AUTOCONFIGURE USING MEM_PERCENT 80 APPLY DB AND DBM CREATE DB MYDB ON /db/mydb AUTOCONFIGURE USING MEM_PERCENT 80 APPLY DB AND DBM データベース・マネージャー構成の以前の値と適用値 説明 パラメーター 以前の値 適用値 アプリケーション・サポート層ヒープ・サイズ (4KB) (ASLHEAPSZ) = 内部通信バッファーの数 (4KB) (FCM_NUM_BUFFERS) = AUTOMATIC AUTOMATIC 38 © 2013 IBM Corporation

39 RHEL 前ページの例のようにAUTOCONFIGUREオプションをつけてデータベースを作成すると、デフォルト値からBLUの最適値に調整されたパラーメーター一覧が表示されます。 出力例 （設定値は、HWのスペックなど環境によって異なります） 　　※FastPathで「01_start_blu.sh」を実行された方は、mydb.outファイルに以下の内容が出力されています。 データベース構成の以前の値と適用値 説明 パラメーター 以前の値 適用値 デフォルト・アプリケーション・ヒープ (4KB) (APPLHEAPSZ) = カタログ・キャッシュ・サイズ (4KB) (CATALOGCACHE_SZ) = (MAXAPPLS*5) 変更ページしきい値 (CHNGPGS_THRESH) = データベース・ヒープ (4KB) (DBHEAP) = 並列処理の度合い (DFT_DEGREE) = ANY デフォルトの表スペース・エクステント・サイズ (ページ) (DFT_EXTENT_SZ) = デフォルトのプリフェッチ・サイズ (ページ) (DFT_PREFETCH_SZ) = AUTOMATIC AUTOMATIC デフォルトの照会最適化クラス (DFT_QUERYOPT) = ロック・リスト用最大ストレージ (4KB) (LOCKLIST) = AUTOMATIC ログ・ファイルのサイズ (4KB) (LOGFILSIZ) = 1 次ログ・ファイルの数 (LOGPRIMARY) = 2 次ログ・ファイル数 (LOGSECOND) = アクティブ・アプリケーションの最大数 (MAXAPPLS) = AUTOMATIC AUTOMATIC アプリケーションあたりのロック・リストのパーセント (MAXLOCKS) = AUTOMATIC 非同期ページ・クリーナー数 (NUM_IOCLEANERS) = 入出力サーバー数 (NUM_IOSERVERS) = パッケージ・キャッシュ・サイズ (4KB) (PCKCACHESZ) = (MAXAPPLS*8) AUTOMATIC ソート・リスト・ヒープ (4KB) (SORTHEAP) = SQL ステートメント・ヒープ (4KB) (STMTHEAP) = 統計ヒープ・サイズ (4KB) (STAT_HEAP_SZ) = ユーティリティー・ヒープ・サイズ (4KB) (UTIL_HEAP_SZ) = AUTOMATIC セルフチューニング・メモリー (SELF_TUNING_MEM) = OFF ON 自動 RUNSTATS (AUTO_RUNSTATS) = ON ON 共有ヒープのソート・ヒープしきい値 (4KB) (SHEAPTHRES_SHR) = ログ・バッファー・サイズ (4KB) (LOGBUFSZ) = デフォルトの表編成 (DFT_TABLE_ORG) = ROW COLUMN データベース・メモリーしきい値 (DB_MEM_THRESH) = CPUパラレルのデフォルトの多重度を自動調整 BLUの利用に最適化するため、SORTヒープとユーティリティヒープを 調整 デフォルトの表タイプは、カラム・オーガナイズ表

40 1.5e+04を超えるコストのクエリーは最大11同時実行に調整
RHEL    バッファー・プールの以前の値と適用値 説明 パラメーター 以前の値 適用値 IBMDEFAULTBP バッファー・プール = Former and Applied Values for System WLM Objects Description Former Value Applied Value Work Action SYSMAPMANAGEDQUERIES Enabled = Y Y Work Action Set SYSDEFAULTUSERWAS Enabled = Y Y Work Class SYSMANAGEDQUERIES Timeroncost = E E+05 Threshold SYSDEFAULTCONCURRENT Enabled = Y Y Threshold SYSDEFAULTCONCURRENT Maxvalue = 1.5e+04を超えるコストのクエリーは最大11同時実行に調整

41 db2 -v stop dbm force (or db2stop force)
RHEL 上記を反映するためにDB2を再起動します。 db2 -v stop dbm force (or db2stop force) db2 -v start dbm (or db2start ) 以上でデータベースが作成され、環境のチューニングが自動的に行われました。 次はテーブルを作成してデータをロードしましょう。 ~]$ db2 -v stop dbm force stop dbm force DB20000I STOP DATABASE MANAGER コマンドが正常に完了しました。 ~]$ db2 -v start dbm start dbm DB20000I START DATABASE MANAGER コマンドが正常に完了しました。

42 カラム型テーブルを作成してデータをロードしましょう
RHEL カラム型テーブルを作成してデータをロードしましょう 実行例 現在のユーザーはdb2inst1です。 FastPath　 お急ぎの方はこちら。 db2 -tvf 02_try_blu.sql drop tableのエラーは無視してください。リラン可能にするために念のため追加しているものです。 Step by Step　じっくり、の方はこちら。 DB2コマンドプロンプトを開始します db2 以降はDB2コマンドプロンプト上で入力します create table文などは一から入力するのは大変なのでコピペをお勧めします。 MYDBに接続します connect to mydb カラム型テーブルを作成します create table t1_c ( c1 bigint not null primary key, c2 int, c3 double, c4 char(10), c5 varchar(10)) create table t1_c ( c1 bigint not null primary key, c2 int, c3 double, c4 char(10), c5 varchar(10)) DB20000I SQL コマンドが正常に完了しました。 後のハンズオンのためにC1をプライマリー・キーに指定しています。 42 © 2013 IBM Corporation

43 比較のために従来の行型のテーブルも作成します。
RHEL 実行例 比較のために従来の行型のテーブルも作成します。 create table t1_r ( c1 bigint not null primary key, c2 int, c3 double, c4 char(10), c5 varchar(10)) organize by row 今のデフォルトがカラム型なので、明示的にorganize by rowで行型を指定しています。 再帰SQLを利用して、データを1000万件生成します export to /work/data/data01.txt of del with temp(a) as ( values(1) union all select a+1 from temp where a< ) select a,a/10000,rand()*1000,'AAAAA','BBBBB' from temp /work/data/data01.txtに1000万件のランダムなデータが出力されます。 3-4分かかります。お待ちください。 create table t1_r ( c1 bigint not null primary key, c2 int, c3 double, c4 char(10), c5 varchar(10)) organize by row DB20000I SQL コマンドが正常に完了しました。 後のハンズオンのためにC1をプライマリー・キーに指定しています。 export to /work/data/data01.txt of del with temp(a) as ( values(1) union all select a+1 from temp where a< ) select a,a/10000,rand()*1000,'AAAAA','BBBBB' from temp SQL3104N エクスポート・ユーティリティーが、 ファイル "/work/data/data01.txt" へのデータのエクスポートを開始しています。 SQL3105N エクスポート・ユーティリティーが、" " 行のエクスポートを完了しました。 エクスポートされた行数:

44 次はカラム型のテーブルにデータをロードします。
RHEL 行型のテーブルにデータをロードします。 load from /work/data/data01.txt of del replace into t1_r nonrecoverable 次はカラム型のテーブルにデータをロードします。 load from /work/data/data01.txt of del replace into t1_c nonrecoverable db2diag.logを見ると、ロードの始めにデータを分析するANALAYZEフェーズがあること、統計情報も同時に収集していること、などが見て取れます。 行型テーブルに対して統計情報を取得します runstats on table db2inst1.t1_r カラム型テーブルは統計情報も自動化されています。 ここまで終わったらDB2のコマンド行プロンプトを終了します terminate load from /work/data/data01.txt of del replace into t1_c nonrecoverable SQL3501W 順方向リカバリーがデータベースに対して使用でき ないため、表が存在する表スペースが、バックアップ・ペン ディング状態に 置かれません。 SQL3109N ユーティリティーが、ファイル "/work/data/data01.txt" から データのロードを開始しています。 <<途中省略>> 読み込まれた行数 = スキップされた行数 = 0 ロードされた行数 = 拒否された行数 = 0 削除された行数 = 0 コミットされた行数 = runstats on table db2inst1.t1_r DB20000I RUNSTATS コマンドが正常に完了しました。

45 以下、今開いているTeraTerm/PuttyのウインドウでOSのコマンドとして実行します。 まずはデータベースに接続します。
RHEL 以下、今開いているTeraTerm/PuttyのウインドウでOSのコマンドとして実行します。 まずはデータベースに接続します。 db2 connect to mydb 手始めに件数を取得して時間を比較しましょう。 まずは行型のテーブルです。 time db2 “select count(*) from t1_r” 次はカラム型のテーブルです。 time db2 “select count(*) from t1_c” 02_try_blu.sqlではdb2batchを利用しています。 実行時間の結果はいかがでしょうか? handson]$ time db2 "select count(*) from t1_r" 1 1 レコードが選択されました。 real 0m0.268s user 0m0.016s sys 0m0.029s handson]$ time db2 "select count(*) from t1_c" real 0m0.309s user 0m0.017s sys 0m0.028s handson]$

46 システムカタログとディスク所要量を確認しましょう
RHEL システムカタログとディスク所要量を確認しましょう 実行例 現在のユーザーはdb2inst1です。 FastPath　 お急ぎの方はこちら。 db2 –tvf 03_check_cat.sql Step by Step　 ここは打つのが面倒なのでFastPath方式で実行して、結果を見るだけにすることをお勧めします。 カタログからテーブルが行型か、列型かを識別します。 select varchar(tabschema,8) tabschema, varchar(tabname,10) tabname, tableorg from syscat.tables where tabschema='DB2INST1‘ カタログから、両テーブルのディスク所要量を調べます select varchar(tabname,10) tabname, data_object_p_size, index_object_p_size, col_object_p_size, data_object_p_size + index_object_p_size + col_object_p_size allsize from sysibmadm.admintabinfo where tabschema='DB2INST1' handson]$ db2 -tvf 03_check_cat.sql connect to mydb データベース接続情報 データベース・サーバー = DB2/LINUXX SQL 許可 ID = DB2INST1 ローカル・データベース別名 = MYDB <<途中省略>> TABSCHEMA TABNAME TABLEORG DB2INST1 T1_C C DB2INST1 T1_R R 2 レコードが選択されました。 TABNAME DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE COL_OBJECT_P_SIZE ALLSIZE T1_C T1_R T1_CはT1_Rに比してディスク所要量が半分くらいで済んでいることがわかります。 46

47 カラム型テーブルを更新してみましょう FastPath お急ぎの方はこちら。 Step by Step RHEL
BLUはDWHや分析特化した機能なので、殆どのワークロードは照会になるかと思われます。とはいえ、BLUでは更新・削除・挿入やユニーク制約を設定することも可能です。 実際にそうか、見て行きましょう。 実行例 現在のユーザーはdb2inst1です。 FastPath　 お急ぎの方はこちら。 db2 –tvf 04_sql_crud.sql Step by Step DB2のコマンド行プロセッサーを起動します db2 まずは20万件を削除してみます。 (更新ログFULLを回避するために削除対象を絞っています) delete from t1_c where c1 between 1 and select count(*) from t1_c handson]$ db2 -tvf 04_sql_crud.sql connect to mydb データベース接続情報 データベース・サーバー = DB2/LINUXX SQL 許可 ID = DB2INST1 ローカル・データベース別名 = MYDB delete from t1_c where c1 between 1 and DB20000I SQL コマンドが正常に完了しました。 select count(*) from t1_c 1 1 レコードが選択されました。 47

48 次は更新です。20万件を更新してみます。 (更新ログFULLを回避するために削除対象を絞っています)
RHEL 実行例 次は更新です。20万件を更新してみます。 (更新ログFULLを回避するために削除対象を絞っています) update t1_c set c5='hoge' where c1 between and select c1,c5 from t1_c order by c1 fetch first 10 rows only 10万件のデータを生成して挿入してみます。 insert into t1_c with temp(a) as ( values(1) union all select a+1 from temp where a<100000) select a,a/1000,rand()*1000,'XXXXX','YYYYY' from temp select count(*) from t1_c 最後に重複するキーを持つデータを1件挿入します。 insert into t1_c values(1,1,1,'aaaa','bbbb') ユニーク制約に抵触したとのエラーが返りましたね? update t1_c set c5='hoge' where c1 between and DB20000I SQL コマンドが正常に完了しました。 select c1,c5 from t1_c order by c1 fetch first 10 rows only C C5 hoge hoge <<途中省略>> hoge 10 レコードが選択されました。 insert into t1_c with temp(a) as ( values(1) union all select a+1 from temp where a<100000) select a,a/1000,rand()*1000,'XXXXX','YYYYY' from temp select count(*) from t1_c 1 1 レコードが選択されました。 insert into t1_c values(1,1,1,'aaaa','bbbb') DB21034E コマンドが、有効なコマンド行プロセッサー・コマ ンドでないため、 SQLステートメントとして処理されました。 SQL 処理中に、次のエラーが返されました。 SQL0803N INSERT ステートメント、UPDATE ステートメントの 1 つ以上の値、 および DELETEステートメントが原因で発生した外部キーの更新は無効です。 これは、"1"で識別される主キー、ユニーク制約、またはユニーク索引が表 "DB2INST1.T1_C"が索引キーに対して重複する値を持つことを制限しているためです。SQLSTATE=23505 48

49 カラム型テーブルを再編成してスペースを空けましょう
RHEL カラム型テーブルを再編成してスペースを空けましょう BLUではDELETEは論理削除です。つまり、「削除した印」をつけるだけであり、即座にディスクのスペースが解放されるわけではありません。スペースの解放はバックグラウンドで自動的に行われるので運用が楽です。とはいえ時間差があるので、「すぐに解放したい」場面もあるでしょう。そのような場合は再編成を行えば解放されます。 実行例 現在のユーザーはdb2inst1です。 前のステップで削除を実行しましたので、そのスペースを解放しましょう。 FastPath　 お急ぎの方はこちら。 db2 –tvf 03_check_cat.sql db2 –tvf 05_reorg_tbl.sql TABNAME DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE COL_OBJECT_P_SIZE ALLSIZE T1_C T1_R reorg table db2inst1.t1_c reclaim extents DB20000I REORG コマンドが正常に完了しました。 TABNAME DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE COL_OBJECT_P_SIZE ALLSIZE T1_C T1_R 49

50 Step by Step RHEL DB2のコマンド行プロセッサーを起動します db2
実行例 Step by Step DB2のコマンド行プロセッサーを起動します db2 先ほど「システムカタログとディスク所要量を確認しましょう」で実行した照会を使って現状のディスク・サイズを確認します。 select varchar(tabname,10) tabname, data_object_p_size, index_object_p_size, col_object_p_size, data_object_p_size + index_object_p_size + col_object_p_size allsize from sysibmadm.admintabinfo where tabschema='DB2INST1‘ 上記、打つのは大変なのでコピペで。 再編成を実行します reorg table db2inst1.t1_c reclaim extents 再編成後のディスクサイズを確認します。 上のselectと同じ ディスクの使用量が減っていますね? TABNAME DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE COL_OBJECT_P_SIZE ALLSIZE T1_C T1_R reorg table db2inst1.t1_c reclaim extents DB20000I REORG コマンドが正常に完了しました。 TABNAME DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE COL_OBJECT_P_SIZE ALLSIZE T1_C T1_R

51 従来型(行型)テーブルをカラム型テーブルへ変換してみましょう
RHEL 従来型(行型)テーブルをカラム型テーブルへ変換してみましょう BLUでは、既存の行型テーブルをカラム型テーブルに変換するdb2convertコマンドが提供されています。先ほど作った t1_rをカラム型テーブルに変換してみましょう。 実行例 現在のユーザーはdb2inst1です。 FastPath　 お急ぎの方はこちら。 db2 -tvf 06_convert_tbl.sql Step by Step 以下をOSのコマンドとして実行します。 db2convert -d mydb -u db2inst1 -z db2inst1 -t t1_r 実際は数秒ごとに状況の進捗が表示されます。 db2diag.logを見ると内部的にはexport/loadを行なって最終的にSWAPで置き換えている様子が見て取れます。 実際に本番でdb2convertを実行する場合は、万が一の事態に備えて既存表のDDLとデータのバックアップをとっておくことをオススメします。例えば db2look -d db名 -e -tw テーブル名 -o アウトプットファイル名　(DDLのバックアップ) db2 export to アウトプットファイル名 of del select * from テーブル名　(データのバックアップ） db2convert -d mydb -u db2inst1 -z db2inst1 -t t1_r 変換を続行しています... Table RowsNum RowsComm Status Progress (%) "DB2INST1"."T1_R" UNSTARTED "DB2INST1"."T1_R" INIT <<途中省略>> "DB2INST1"."T1_R" COPY "DB2INST1"."T1_R" REPLAY "DB2INST1"."T1_R" SWAP 最終サマリー: Table RowsNum InitSize (MB) FinalSize (MB) CompRate (%) State "DB2INST1"."T1_R" Completed Pre-Conversion Size (MB): Post-Conversion Size (MB): Compression Rate (Percent): 53.27 51

52 RHEL !db2convert -d mydb -u db2inst1 -z db2inst1 -t t1_r 変換を続行しています...
Table RowsNum RowsComm Status Progress (%) "DB2INST1"."T1_R" UNSTARTED "DB2INST1"."T1_R" INIT "DB2INST1"."T1_R" COPY "DB2INST1"."T1_R" COPY "DB2INST1"."T1_R" COPY "DB2INST1"."T1_R" REPLAY "DB2INST1"."T1_R" SWAP 最終サマリー: Table RowsNum InitSize (MB) FinalSize (MB) CompRate (%) State "DB2INST1"."T1_R" Completed Pre-Conversion Size (MB): Post-Conversion Size (MB): Compression Rate (Percent): 53.27

53 (TBライセンスの場合の)準拠状況を確認しましょう
RHEL (TBライセンスの場合の)準拠状況を確認しましょう DB2 BLUをTBライセンスでご利用の場合は、コンプライアンスの観点で、ご購入済のTBサイズやご利用条件を逸脱していないかの確認をしたい場合があります。その場合はカタログを照会して現状をご確認いたたくためのスクリプト(※)が製品に同梱され、導入されています。 ※...TBライセンスのTBは元のデータのサイズではなく、DB2に圧縮・格納された時点でのサイズです。また、全体のデータ量の75%以上がDWH的用途(今の場合はカラム型テーブル)に格納されている必要があります。 ※..../opt/ibm/db2/V10.5/bin/tbpsize_entitlement_req.sql

54 このデータ量なら1TB分のライセンスがあればいいことがわかります
RHEL FastPath　 db2 connect to mydb db2 -tvf /opt/ibm/db2/V10.5/bin/tbpsize_entitlement_req.sql Step by Step 打つのが大変なので、FastPathをそのまま実行してください。 実行例 handson]$ db2 -tvf /opt/ibm/db2/V10.5/bin/tbpsize_entitlement_req.sql <<途中省略>> select substr(SERVICE_LEVEL, 1, 20) SERVICE_LEVEL, substr(BLD_LEVEL, 1, 20) BLD_LEVEL, substr(PTF, 1, 20) PTF from SYSIBMADM.ENV_INST_INFO SERVICE_LEVEL BLD_LEVEL PTF DB2 v s LINUXAMD64105 1 レコードが選択されました。 -- -- SUMMARY OF USER TABLE DATA SIZES select CURRENT SERVER as DBNAME, CURRENT TIMESTAMP as CURRENT_TIMESTAMP, S.USER_DATA_L_SIZE_KB, DEC( (S.USER_DATA_L_SIZE_KB/ ), 31, 11 ) as USER_DATA_L_SIZE_TB, COALESCE( CEIL( DEC( (S.USER_DATA_L_SIZE_KB/ ), 31, 11 ) ), 1 ) as USER_DATA_L_ENTITLEMENT_REQ_TB from ( select ( sum(A.DATA_OBJECT_L_SIZE) + sum(A.LONG_OBJECT_L_SIZE) + sum(A.LOB_OBJECT_L_SIZE) + sum(XML_OBJECT_L_SIZE) + sum(A.COL_OBJECT_L_SIZE) ) as USER_DATA_L_SIZE_KB from SYSIBMADM.ADMINTABINFO as A, ( select TABSCHEMA, TABNAME, OWNER, OWNERTYPE, TYPE, STATUS, TABLEID, TBSPACEID from SYSCAT.TABLES where OWNERTYPE = 'U' and TYPE IN ('G', 'H', 'L', 'S', 'T', 'U') ) as T where A.TABNAME = T.TABNAME and A.TABSCHEMA = T.TABSCHEMA ) as S DBNAME CURRENT_TIMESTAMP USER_DATA_L_SIZE_KB USER_DATA_L_SIZE_TB USER_DATA_L_ENTITLEMENT_REQ_TB MYDB このデータ量なら1TB分のライセンスがあればいいことがわかります

55 RHEL 実行例（続き) テーブル別の内訳明細。ご参考情報。 --
-- BREAKDOWN OF USER TABLE DATA SIZES (INFORMATIONAL: NOT REQUIRED TO RUN TO COLLECT THE SIZE OF USER DATA) select substr(A.TABSCHEMA, 1, 18) SCHEMA, substr(A.TABNAME, 1, 18) TABLENAME, sum(A.DATA_OBJECT_L_SIZE) as DATA_OBJECT_L_SIZE_KB, sum(A.LONG_OBJECT_L_SIZE) as LONG_OBJECT_L_SIZE_KB, sum(A.LOB_OBJECT_L_SIZE) as LOB_OBJECT_L_SIZE_KB, sum(XML_OBJECT_L_SIZE) as XML_OBJECT_L_SIZE_KB, sum(A.COL_OBJECT_L_SIZE) as COL_OBJECT_L_SIZE_KB, ( sum(A.DATA_OBJECT_L_SIZE) + sum(A.LONG_OBJECT_L_SIZE) + sum(A.LOB_OBJECT_L_SIZE) + sum(XML_OBJECT_L_SIZE) + sum(A.COL_OBJECT_L_SIZE) ) as USER_DATA_L_SIZE_KB, T.COMPRESSION from SYSIBMADM.ADMINTABINFO as A, ( select TABSCHEMA, TABNAME, OWNER, OWNERTYPE, TYPE, STATUS, COMPRESSION, TABLEID, TBSPACEID from SYSCAT.TABLES where OWNERTYPE = 'U' and TYPE IN ('G', 'H', 'L', 'S', 'T', 'U') ) as T where A.TABNAME = T.TABNAME and A.TABSCHEMA = T.TABSCHEMA group by A.TABSCHEMA, A.TABNAME, T.COMPRESSION order by A.TABSCHEMA, A.TABNAME SCHEMA TABLENAME DATA_OBJECT_L_SIZE_KB LONG_OBJECT_L_SIZE_KB LOB_OBJECT_L_SIZE_KB XML_OBJECT_L_SIZE_KB COL_OBJECT_L_SIZE_KB USER_DATA_L_SIZE_KB COMPRESSION DB2INST T1_C DB2INST T1_R SYSTOOLS HMON_ATM_INFO N SYSTOOLS HMON_COLLECTION N SYSTOOLS OTM_SEMAPHORE_TABL N SYSTOOLS POLICY N 6 レコードが選択されました。

56 性能測定用のデータベースを準備しましょう
RHEL 性能測定用のデータベースを準備しましょう 次は性能測定のためのデータベースを準備します。とはいえ、データ生成やロードを実行している間、何もせず待っているのは退屈です。皆様のお時間を節約するために、すでに5GBのサイズの測定用のDB(BLUDB)を作成してあります。先ほど作成したMYDBはもう利用しないのでアンカタログし、性能測定用のDB(BLUDB)をカタログして使えるようにします。 実行例 現在のユーザーはdb2inst1です。 FastPath　 お急ぎの方はこちら。 ./08_switch_db.sh Step by Step 以下をOSのコマンドとして実行します。 現状を確認します。 db2 list database directory MYDBをアンカタログします。 db2 uncatalog database mydb 本来はアンカタログは必須ではないのですが、性能測定中に誤ってmydbにアクセスするとDBが活動化され不要なメモリを確保し、性能測定環境へ悪影響をおよぼす可能性があります。そのような事態を防止する意味で念のためアンカタログします。 システム・データベース・ディレクトリー ディレクトリー中の項目数 = 1 データベース 1 項目: データベース別名 = MYDB データベース名 = MYDB ローカル・データベース・ディレクトリー = /db1 データベース・リリース・レベル = 10.00 コメント = ディレクトリー項目タイプ = 間接 カタログ・データベース・パーティション番号 = 0 代替サーバー・ホスト名 = 代替サーバーのポート番号 = DB20000I UNCATALOG DATABASE コマンドが正常に完了しました。 DB21056W ディレクトリーの変更は、 ディレクトリー・キャッシュがリフレッシュされるまで反映されません。 56

57 性能測定用のBLUDBをカタログします。 db2 catalog database bludb on /db1
RHEL 実行例 性能測定用のBLUDBをカタログします。 db2 catalog database bludb on /db1 BLUDBは/db1上に作成されていますので、そのpathを指定します。環境面では(MYDB同様に)メモリ80%でチューニング済です。 BLUDBがカタログされていることを確認します。 db2 list database directory DB2を再起動します。 db2stop force db2start DB20000I UNCATALOG DATABASE コマンドが正常に完了しました。 DB21056W ディレクトリーの変更は、 ディレクトリー・キャッシュがリフレッシュされるまで反映されません。 システム・データベース・ディレクトリー ディレクトリー中の項目数 = 1 データベース 1 項目: データベース別名 = BLUDB データベース名 = BLUDB ローカル・データベース・ディレクトリー = /db1 データベース・リリース・レベル = 10.00 コメント = ディレクトリー項目タイプ = 間接 カタログ・データベース・パーティション番号 = 0 代替サーバー・ホスト名 = 代替サーバーのポート番号 = :03: SQL1064N DB2STOP の処理が正常に終了しました。 SQL1064N DB2STOP の処理が正常に終了しました。 06/28/ :03: SQL1063N DB2START の処理が正常に終了しました。 SQL1063N DB2START の処理が正常に終了しました。 DB20000I ACTIVATE DATABASE コマンドが正常に完了しました。 57

58 性能測定の前に．．データ・スキッピングを確かめてみましょう
RHEL 性能測定の前に．．データ・スキッピングを確かめてみましょう BLUでは、索引を作らずとも、条件に一致しないデータ範囲を自動的に読み飛ばして性能を上げてくれる「データ・スキッピング」という機能が実装されています。 データの一定の塊ごとに、格納されているデータの最小値/最大値を持ちます。 情報は自動的に収集され、管理者によるメンテナンスは不要です。 Min:2012/10/01 Max:2012/12/31 Min:2013/01/01 Max:2013/02/28 Min:2012/12/01 Max:2012/12/31 2013年5月のデータは？ Min:2013/04/01 Max:2013/04/30 Min:2013/04/20 Max:2013/05/15 Min:2013/01/10 Max:2013/05/20 Min:2012/05/01 Max:2013/05/10 Min:2013/03/01 Max:2013/03/31 58

59 FastPath お急ぎの方はこちら。 Step by Step RHEL ./09_data_skip.sh
ではデータスキッピングを確かめてみましょう。　絞り込み条件である日付の範囲が　①１ケ月　②1日 と異なる2つのSELECT文があります。両者を実行したら、どれくらい時間が変わるでしょうか? 当機能は本当はもっと前に紹介したかったのですが、データの件数が少ないとあまり差が出ないので、件数の多いBLUDBで実行します。 現在のユーザーはdb2inst1です。 FastPath　 お急ぎの方はこちら。 ./09_data_skip.sh Step by Step まずは件数を確認しておきましょう。 以下をOSのコマンドとして実行します。 db2 connect to bludb db2 -tv "select count(*) from tpch_c.lineitem where l_shipdate between ' ' and ' ' “ db2 -tv "select count(*) from tpch_c.lineitem where l_shipdate between ' ' and ' ' " 実行例 select count(*) from tpch_c.lineitem where l_shipdate between ' ' and ' ' 1 386375 1 レコードが選択されました。 select count(*) from tpch_c.lineitem where l_shipdate between ' ' and ' ' 12478 31日分 件数 1日分 件数 59

60 初回はディスクIOが発生するので、同じSELECTを3回ずつ実行して、3回目の実行時間を比べてみましょう。 まずは31日分を3回繰り返し
RHEL 実行例 初回はディスクIOが発生するので、同じSELECTを3回ずつ実行して、3回目の実行時間を比べてみましょう。 まずは31日分を3回繰り返し time db2 -tv +o "select * from tpch_c.lineitem where l_shipdate between ' ' and ' ' “ timeコマンドで、後に続くコマンドの実行時間が表示されます 次は1日分を3回繰り返し time db2 -tv +o "select * from tpch_c.lineitem where l_shipdate between ' ' and ' ' “ いかがでしょう？索引を一切作らなくても、7秒 vs 0.7秒と実行時間が10倍違いますね。これがデータスキッピングの効果です。 通常のＲＤＢでは、索引を何も作成しない場合、結果を得るための「近道」がありませんので、条件が31日分であろうが1日分であろうが、表全体を読むことになります。BLUではある種の「索引」的なものが自動的に作られて条件により「近道」できる、ということですね。 ******************* 31 days * 3 times real 0m23.558s user 0m1.146s sys 0m4.842s real 0m6.655s user 0m1.204s sys 0m3.482s real 0m7.099s user 0m1.348s sys 0m3.753s 1 days * 3 times real 0m0.717s user 0m0.057s sys 0m0.104s real 0m0.747s user 0m0.067s sys 0m0.129s real 0m0.703s user 0m0.038s sys 0m0.125s 60

61 ついでにEXPLAINしてみましょう FastPath お急ぎの方はこちら。 Step by Step RHEL 1日分
現在のユーザーはdb2inst1です。 FastPath　 お急ぎの方はこちら。 ./10_explain.sh Step by Step 以下をOSのコマンドとして実行します。 db2 connect to bludb 31日分 db2expln -database bludb -statement "select * from tpch_c.lineitem where l_shipdate between ' ' and ' '" -terminal -terminator ';' -graph 1日分 db2expln -database bludb -statement "select * from tpch_c.lineitem where l_shipdate between ' ' and ' '" -terminal -terminator ';' -graph 実行例は次のページにあります。 61

62 以上で「入門編」は終わりです。次は性能測定です。
RHEL 実行例 ******************* 31 days DB2 Universal Database Version 10.5, (c) Copyright IBM Corp. 1991, 2012 Licensed Material - Program Property of IBM IBM DB2 Universal Database SQL and XQUERY Explain Tool ******************** DYNAMIC *************************************** ==================== STATEMENT ========================================== Isolation Level = Cursor Stability Blocking = Block Unambiguous Cursors Query Optimization Class = 5 Partition Parallel = No Intra-Partition Parallel = Yes (Bind Degree = ANY ) SQL Path = "SYSIBM", "SYSFUN", "SYSPROC", "SYSIBMADM", "DB2INST1" Statement: select * from tpch_c.lineitem where l_shipdate between ' ' and ' ' Intra-Partition Parallelism Degree = 4 Section Code Page = 1208 Estimated Cost = Estimated Cardinality = Process Using 2 Subagents | CDE Subquery | | Tables Referenced: | | | 1: TPCH_C.LINEITEM ID = 2,18 | | #Input Columns = 2 | | #Output Columns = 16 | | Parallel CDE Scan | Insert Into Asynchronous Local Table Queue ID () = q1 Access Local Table Queue ID () = q1 #Columns = 16 Return Data to Application | #Columns = 16 End of section Optimizer Plan: Operator (ID) RETURN ( 1) | LTQ ( 2) CTQ ( 3) * Table: TPCH_C LINEITEM BLUではINTRA_PARALLEL必須 コスト・ベースで動いてます。 31日と1日ではコストは似ていますがCardinarityがかなり異なっているはずです。 以上で「入門編」は終わりです。次は性能測定です。 62

63 D B 2 B L U P E R F O R M A N C E

64 お待たせしました。ではパフォーマンスを測りましょう
前章ではBLUの機能や使い方をごく簡単に体験しました。環境設定は非常に簡単で、通常のRDBと同じ感覚でご利用いただける点がお分かりいただけたかと思います。 当章では同一構造の行型・カラム型　両方のテーブルに負荷ツール JMETERで照会を実行してパフォーマンスの違いを経験してみましょう。なお、ワークロードとしてデータウエアハウス用のベンチマークであるTPC-Hを利用します。 Windows2008 RHEL6.4 JDBC SELECT BLUDB SELECT SELECT 64

65 ご参考) 利用するスキーマ TPC-Hでは左のように8つのテーブルが定義されています。 今回はデータを5GB分用意しました。
実行する照会もTCP-Hで定義されているものを利用します。 より転載

66 BLUDB上に作成済のテーブルと環境 TPCH_C TPCH_R
BLUDB上には、スキーマの異なる同じレイアウトのテーブルが各々8つ定義されており、すでに5GBのデータが各々にロード済です。 スキーマ テーブル名 行数 カラム型 TPCH_C PART 1,000,000 SUPPLIER 50,000 PARTSUPP 4,000,000 CUSTOMER 750,000 行型 TPCH_R NATION 25 LINEITEM 29,999,795 REGION 5 ORDERS 7,500,000 従来型（行型)テーブルは以下の定義 データ圧縮あり（Adaptive) 索引はJOINキーのみ付与 圧縮もせず索引一切なし、のテーブルは毎回全件スキャンになるので、それと比べて「カラム型は速いでしょう」といっても説得力がないので。。。 カラム型テーブルは特に何も指定せず バッファープールは8GB= データが全部メモリに乗る大きさ、です。

67 JMETERを準備しましょう ではJMETERを起動して負荷スクリプトを準備しましょう。

68 JMETERの負荷定義ファイルを開きます。 「ファイル」 DB2_BLU_TPCH_COL.jmxを選択
DB2_BLU_TPCH_ROW.jmxは従来型テーブル用で、次に使います。お間違えなきよう。 開いたら、以下をダブルクリック 「カラム型スレッドグループ」 下に定義が展開されます。

69 jdbcの接続URLに宛先となるDB2サーバーのIPアドレスを指定します。
「JDBC Connection Configuration」 「Database URL」欄 XX.XX.XX.XXの箇所を、事前に皆様にお知らせしたRHELサーバーのIPアドレスに書き換えてください。 SELECT文のスキーマが「TPCH_C」になっていることを念のため確認します。 「スキーマ」 変数schemaの値が「TPCH_C」になってますね？

70 Query01をクリックすると、実際に実行するselect文が定義されていることがわかります。これらがTPC-Hで定義された照会です。JMETERはこのSELECTを01から順番に実行し、実行時間をレポートしてくれます。 よろしければ、コマンド端末をもう一つ起動してシステムのモニタリング・ツールであるnmonを起動しておきましょう。nmonを使えばCPUやディスクIOの状況をグラフィックで見ることができますので、DB2の動きがご覧いただけます。 コマンド端末を開く nmon と入力して改行 上のメニュー画面が表示されたら 英小文字 c 英小文字 d と連続して入力すれば、CPUとディスクの状況が位置画面に表示されます。

71 定義ファイル(*.JMX)を開く、閉じる、保存する
ご参考) JMETERのメニュー・ボタン 以降で共通の操作なので、以下にJMETERのボタンの意味をお示しします。 当ハンズオンで使うものは、「実行」と「結果のクリア」のみ、ですので、この2つだけ覚えておいてください。 実行 結果のクリア 実行の停止 定義ファイル(*.JMX)を開く、閉じる、保存する COPY&PASTE

72 性能測定を実行しましょう(1) ～ カラム型テーブル
性能測定を実行しましょう(1)　～　カラム型テーブル では、まずはカラム型テーブルの性能を確認しましょう。初回はメモリー上のバッファーにデータが一切載っていないのでディスクの読み込みが発生し、それなりに時間がかかります。 ディスク読み込みが発生する場合、発生しない場合での性能を区別するために、測定は以下の2回、実行します。 #1 20種類のSELECTを各1回　これでディスクが読まれ、データがメモリに展開される #2 20種類のSELECTを各5回　全件メモリ上でヒット 結果パネルを表示して、実行します 「統計レポート」をクリック 「実行」ボタン

73 それぞれのSELECTが完了すると、応答時間が次第にパネルに表示されます。
nmonも見ている場合、ディスクReadが発生し、負荷が上がっているのがご覧いただけます。 Query01-22までが各1回実行されると、JMETERは自動的に処理を停止します。 完了は実行ボタンが再び選べるようになることでわかります。 左記は当方での実行結果です。(皆様の結果とは異なるかもしれませんが、環境が同じなので大筋は似ているかと存じます）数字の単位はミリ秒です。これを見ると、19個のSELECTの平均は5.1秒であったこと、最長がQuery01で18.3秒かかったこと、が見て取れます。

74 今の実行でデータはすべてメモリ上に展開されたはずです。では、2回目の処理を実行しましょう。今回は20個のselectを各5回実行します。
実行回数を変更します。 「カラム型スレッドグループ」を選択 「ループ回数」を5に変更 クリアボタンで先程の実行結果をクリアします。 改めて実行します 「統計レポート」をクリック 先ほどの結果はクリアされていますね? 「実行」ボタン しばらくお待ち下さい。

75 以下が実行の例です。平均実行時間は1.7秒(1回目は5.1秒でした)、最大が6.3秒、1秒以下のものも散見されます。

76 数字だけだと全体を理解しづらいのでグラフにしましょう。
「Aggregae Graph」をクリック 「Display Graph」ボタン 左記のように、棒グラフが表示されます。 １秒近辺のものが結構ありますね。

77 性能測定を実行しましょう(2) ～ 従来型(行型)テーブル
性能測定を実行しましょう(2)　～　従来型(行型)テーブル 次は従来型のテーブルに対して性能測定を行います。あとで両方の結果を比較したいので、先ほど起動したJMETERは終了せず、もういちどアイコンをクリックして別のJMETERを起動します。 JMETERの負荷定義ファイルを開きます。 「ファイル」 DB2_BLU_TPCH_ROW.jmxを選択 上記は表のスキーマ以外は先ほどのファイルと同じものです。 開いたら、以下をダブルクリック 「従来型（行型)スレッドグループ」 下に定義が展開されます。

78 先ほどと同様に、jdbcの接続URLに宛先となるDB2サーバーのIPアドレスを指定します。
「JDBC Connection Configuration」 「Database URL」欄 XX.XX.XX.XXの箇所を、事前に皆様にお知らせしたRHELサーバーのIPアドレスに書き換えてください。 SELECT文のスキーマが「TPCH_R」になっていることを念のため確認します。 「スキーマ」 変数schemaの値が「TPCH_R」になってますね？

79 まずは初回はディスク読み込みパターンです。
「従来型（行型）スレッドグループ」をクリック 「ループ回数」が 1 であることを確認します。 では実行します。 「統計レポート」をクリック 「実行」ボタン

80 しばらくお待ち下さい Query01-22までが各1回実行されると、JMETERは自動的に処理を停止します。 左記は当方での実行結果です。数字の単位はミリ秒です。これを見ると、19個のSELECTの平均は5.6秒であったこと、最長がQuery01で29.6秒かかったこと、が見て取れます。

81 今の実行でデータはすべてメモリ上に展開されたはずです。では、2回目の処理を実行しましょう。今回は20個のselectを各5回実行します。
実行回数を変更します。 「従来型(行型)スレッドグループ」を選択 「ループ回数」を5に変更 改めて実行します クリアボタンで先程の実行結果をクリアします。 「統計レポート」をクリック 先ほどの結果はクリアされていますね? 「実行」ボタン しばらくお待ち下さい。

82 以下が実行の例です。平均実行時間は4.2秒(1回目は5.6秒でした)、最大が14秒、1秒以下のものは、あまりありません。

83 「Aggregae Graph」をクリック 「Display Graph」ボタン
同様に、グラフにしましょう。 「Aggregae Graph」をクリック 「Display Graph」ボタン 左記のように、棒グラフが表示されます。 全体的に、3-4秒近辺のものが多いですね。 カラム型のほうは、何もチューニングせずとも1秒前後のものが結構ありました。翻って従来型の場合は、まだまだチューニングの余地がありそうです。 誤解無いように申し添えますが、あらゆるケースでカラム型のほうが常に性能が良い、と申しているわけではございません。次のハンズオンで見ていきますが、従来型でもここから頑張ってチューニング作業を施せば性能は改善します。ただ、カラム型ならそういうご苦労(工数）が不要でシンプルです、管理が楽です、というお話です。

84 以下はご参考までに両方の結果を並べてみたものです。皆様もご自身の結果を比較してみてください。
カラム型の結果 従来型の結果

85 以上で性能測定は終了です。 2つのJMETERを終了してください。 「ファイル」－「終了」　または 右上の終了ボタン 左記のメッセージには「いいえ」ボタン。

86 お疲れ様でした！ 当ハンズオンへのご参加ありがとうございました！
以上でハンズオンは終わりです。最後までお付き合い頂き、ありがとうございました。 DB2 BLUは「LOAD & GO !」が合言葉で何ら難しい設定や準備が不要なので、 もしかしたら「ハンズオンのやりがいが無いなあ」と拍子抜けした方もおられるかもしれませんね。 でも、それでいいのです。それくらい簡単に、高性能を実現できるのだ、とご実感いただけたのであれば、ハンズオンの目的は達成したことになると思っております。 お時間に余裕のあるかたは、以降の「Tune DB2」のパートにお取り組みください。 製品に添付の「Query Workload Tuner」を使って「従来表のチューニング」や「このテーブルはカラム型テーブルへ変換したらいいのではないか、と推奨してくれる機能」をご紹介しております。 所要時間は30-40分です。 ハンズオンで利用した環境はそのままで結構です。(当方で遮断します) Windowsのリモートデスクトップの接続を切って、終了してください。 最後に、別途メールでご案内したアンケートにご回答頂けると大変有難く存じます。 当ハンズオンへのご参加ありがとうございました！

87 以降はオプションです。お時間に余裕がある方はお取り組みください。
T U N E D B 2

88 Query Workload TunerでDB2をチューニングしましょう
DB2 10.5のAdvanced版(AESE/AWSE)では、カラム型ストア以外にも、従来有償であった様々なDB2の便利ツールのライセンスが添付されており、標準で利用することができます。今回はSQLのチューニング・ツールであるOptim Query Workload Tuner(QWT)を使用して、従来型の行テーブルのチューニングを少し体験してみましょう。 当ハンズオンでは、先ほど使ったTPC-Hの一連のselect文を利用します。 QWTを使うと様々な索引やMQTを、(その期待効果と共に)推奨してくれますが、本日の環境で実際にそれらの改善策を適用すると20-30分くらいの時間がかかります。ハンズオンであまりにも「待ち時間」が長いのはよろしくありませんので、本日は「仮想テスト」のみとし、実際の適用は行いません。その点、ご了承ください。 推奨 入力ワークロード 索引の推奨 SQLテキスト群 MQT/MDCの推奨 パッケージキャッシュ 統計情報の推奨 Explain表 ※2 カラム型の推奨 イベントモニター Query Workload Tuner .... .... ※1....Query Workload Tuner...前のバージョンではOptim Query Tunerという名前でした。※2....パッケージキャッシュなど、実際に実行した結果を入力にすることもできます。この場合、ワークロード特性や実行回数なども加味して推奨が出るので、より正確な結果になります。 ※3....無償版のIBM Data Studio 4.1でも単一SQLのチューニングは可能です。

89 Query Workload Tunerの実行の準備
QWTはEclipseベースのツールです。無償のIBM DataStudioへのアドオンとして提供されています。 皆様のお手間を省くために、すでにOptim Workload Quuery Tuner（以下QWT)は Windows上に導入済みです。( RHEL上ではありませんのでお間違えなきよう！） 以下の手順でQWTを起動します。 デスクトップ上の「DataStudio Client」をダブルクリック ワークスペースは下記を指定 C:\temp\workspace1 今回はイチから使うので、上記は実はどこでもいいのですが、まあ一応上記に決めます。 「OK」ボタン しばらくお待ち下さい。

90 QWTが起動しました。 ではツールからRHEL上のDB2サーバーに接続します。 左上の「管理エクスプローラー」で左から2番目の「データベースへの新規接続」をクリック

91 左側のペインで以下を選択 「DB2 for Linux, UnixおよびWindows」 表示されるパネルで以下を入力 データベース: BLUDB　(固定) ホスト: RHELサーバーのIPアドレス ポート番号: (デフォルト) ユーザー名: db2inst1 パスワード: Passw0rd 「パスワードの保存」にチェック 「接続のテスト」ボタン 「接続が成功しました」のパネルが表示されたら「OK」ボタンで戻る 「終了」ボタン

92 左記のようにBLUDBへの接続ができました。
EclipseのパースペクティブをQWTのものに変更します。 右上の「パースペクティブ」ボタン 「IBM Query Tuning」を選択 「OK」ボタン

93 チューニングを開始する前に、まずチューニング機能を有効化して環境を整えます。 パースペクティブが切り替わったら以下を選択
左下の「データ・ソース・エクスプローラー」 BLUDBの名前の接続をクリックして展開 以下の青いディスクの絵の「BLUDB」を右クリック BLUDBの表記が2つあるのでお間違えなきよう。 展開した方のBLUDBです。 「分析とチューニング」－「チューニング・フィーチャーのフルセットのアクティブ化」を選択 ライセンスの確認のパネルで、「はい」ボタン。

94 これでQWTの機能がアクティブになりました。
「OK」ボタン 次にBLUDB上にチューニングのためのEXPLAIN表やストアド・プロシージャを定義します 先ほどと同じく「BLUDB」－「分析とチューニング」－「チューニング用に構成」－「ガイド付き構成」 BLUDB上に定義出来ました。 「OK」ボタン

95 従来型(行型) テーブルをチューニングしましょう
以上で環境面の準備は完了です。早速チューニングを行なってみましょう。 タスク・ランチャーより 「チューニング」タブ 「チューニングの開始」をクリック ウイザードが起動します。 「次へ」ボタン

96 「BLUDB」を選択して「終了」ボタン 左のように画面が切り替わります。

97 ご参考) QWTへの入力となるselect文の与え方
① ② ①は外部のファイルなどからSELECT文を与える場合のメニューです。 今回のハンズオンではこちらの方法を使います。 ②は実際のDB2システムから実行済のSELECT文や性能情報を抜き出して分析する場合のメニューです。 当然ながら、②のほうが実行回数やトランザクション・ミックス/重み付けを加味した実態に近いワークロードを入力に利用できますので、より効果的な推奨結果が得られるものと思われます。 ただし、①②いずれでも推奨を計算する場合には実際のDB2システムに接続して統計情報やEXPLAIN結果を利用しますのでご安心ください。（逆に申しますと、個人PCでの開発DB2環境など、あまりに本番とかけ離れた小規模なDB2に接続して実行した場合、効果的な結果が得られない可能性があるかと存じます。）

98 まずは従来型（行型）テーブルに対する照会をチューニングします。 「2.キャプチャー」のタブ 「ファイル」-「ファイル・パス」 「参照」ボタン
デスクトップ上の以下のファイルを選択して「開く」ボタン 99_all_query.sql 上記は先程JMETERで実行したSELECT文をそのまま20個書いてある普通のテキスト・ファイルです。 「キャプチャー」ボタン

99 キャプチャーされたステートメントにSELECT文が表示されたら、一旦保管しましょう。
「すべてをワークロードへ保存」 「OK」ボタン タブが「管理」に切り替わったら 「アドバイザーの起動」ボタン。

100 以下を選択します 「ワークフロー・アドバイザーの実行」 「実行する項目の選択」ボタン 「すべてを選択」-「OK」ボタン 次のパネルで
メニューをよく見ると「表編成」というメニューがあって、グレイアウトされていますね。これは「カラム型テーブルに変更したらどうなる?」という場合に指定するもので、あとで試みます。索引やマテリアライズド照会表はカラム型テーブルでは利用できない（というか不要)です。要は今回推奨を要求しているオブジェクトはカラム型テーブルではありえないので、グレイアウトされているわけです。 次のパネルで 「EXPLAINの開始」ボタン

101 QWTがパフォーマンスを最適化すべく、色々と考えております。気長にお待ちください。 (4-5分くらいです）
もし左記のメッセージが出たら「はい」ボタン しばらくお待ち下さい アドバイザーが終わると左記のようなレポートが生成/表示されます。 早速、中身を見てみましょう。

102 アドバイザーの推奨内容をさらっと見てみてください。例として、当方の環境では左記の内容が推奨されていました。
要は統計を4つ、統計ビューを3つ、索引を33個( ! ) MQTを5つ追加して、MDCへの変換を1つ行ったら、パフォーマンスがかなりよくなるのでは？と言ってます。 (「えー！そんなにやるのか！」と思わないでください。あくまでアドバイスであって全部の実装が必須、というわけではありません。後で見ていきますが、アドバイスは個別に効果を評価して、個別に適用できますので。。。）

103 QWTは推奨された内容から実行ステートメントを生成して、そのまま実行することもできます。
左のペインで以下をクリック ワークロード推奨情報を開く まずは統計情報です 「統計」タブをクリック 「RUNSTATSの表示」ボタン

104 推奨されたRUNSTATS文が表示されていますね。
ここまま「次へ」で進めば実行できますが、今日は「キャンセル」で戻ります。

105 x 次は索引です。 「索引」タブをクリック 下の段にQWTが推奨した33個の索引がリストされていますね。 下の段の左から５つめのアイコン 「候補索引のテスト」をクリック 「呼び出し」タブに画面が変わります 「候補索引のワークロードテストの実行」をクリック 「索引候補のテスト」ボタン

106 今回はオプションは設定しません。 そのまま「OK」　ボタン しばらくお待ち下さい。

107 新しく「索引候補のテスト」タブが表示されましたので、クリック。
「パフォーマンスにおける変化の見積もり」では推奨された索引を付与すれば全体で47.89%の改善が見込める、と言っています。

108 では、これらの個々の索引の効果はどの程度でしょうか？
スライダー・バーを右にずらすと、①パフォーマンス向上の見積もり　②ディスク・スペースの見積もりのカラムがあり、索引別に期待できる効果と必要なディスク・リソースが参照できます。 更に、個々のSELECT文の性能がどの程度改善されそうか、も新旧比較で知ることができます。 左から6つめの「アクセスプランの比較」ボタンをクリック。

109 しばらくお待ち下さい 比較対象はこのままで「OK」ボタン。 「OK」ボタン

110 完了するとタブのパネルが切り替わります。
「比較履歴」をクリック 「結果を検討」ボタン 下記のように個々のSELECT文でどの程度の効果が見込めるか、がExplainの結果としての実行コストをベースに表示されます。90%以上性能改善するものもある、と言っていますね。

111 他にもMQT/MDC/統計ビューなどの推奨が出ていますが、ハンズオンはこのへんにしておきます。
見ると、平均時間は3.4秒です。カラム型は何もしなくても平均1.7秒でした。とはいえ一部のselectは数十msと劇的に早くなっていますので、「手間をかけてチューニングすれば、改善は見込める」のは確かです。要は「従来型でも、今までのように手間をかけてコツコツとチューニングすれば(当然) 性能は上がるが、カラム型では何もしなくても、平均して結構良い性能を得られる」ということが見て取れるかと思います。

112 チューニング前 チューニング後 x 従来型テーブルの性能測定結果をチューニング前後でグラフで比べてみました。
全般的には確かに改善していますが、チューニング後もバラツキがあることが見て取れます。要はチューニング策が照会の条件にフィットすればそこは効果が得られるが、フィットしなかったり自由検索など条件が変わる場合は、なかなか改善が見込めない、というある意味アタリマエの結果が見て取れます。 一部、却って悪化しているものもありますが、この原因は未調査です。すいません。。。 チューニング後

113 従来型(行型) テーブルからカラム型への変換のアドバイス
先程は従来型(行型)テーブルの範疇でのチューニングと効果の見極めをご経験いただきました。 QWTは「このテーブルはカラム型に変換したらいいのではないですか？」というオススメもしてくれます。 それをやってみましょう。ワークロード(select文)は先程保存したものを使います。 アドバイザーを起動します。 左の「管理」タブ 「ワークロード・リスト」 「アドバイザーの起動」ボタン

114 x パネルが「呼び出し」タブに変わります。 「ワークロード・アドバイザーの実行」 「実行する項目の選択」ボタン カラム型の推奨を指定します。 「すべてクリア」ボタン 「表編成」のみにチェック 「OK」ボタン

115 「続行」ボタン しばらくお待ち下さい (2-3分) 「表編成」のタブが表示されたらクリック。

116 本日は前の操作と同様に「仮想テスト」に止め、実際の変換は行いません。
「候補表編成のテスト」ボタン 「呼び出し」タブにパネルが切り替わります 「候補表編成のワークロードテストの実行」をダブルクリック 上記ボタンは始めはグレイアウトされていますが、 「候補表編成のワークロードテストの実行」をダブルクリックすると選択できるようになります。

117 しばらくお待ち下さい。 「表候補編成」のタブが表示されたらクリック。

118 以下のようにカラム型に変更したらよいと思われる表、その場合のselect文の性能改善の期待値が表示されます。(一つ、-62
従来型の時と同様に、QWTから変換を行うこともできますが、実際に実行すると待ち時間が長いので、本日のハンズオンはここまでとさせていただきます。

119 お疲れ様でした！ 当ハンズオンへのご参加ありがとうございました！
以上でハンズオンは終わりです。最後までお付き合い頂き、ありがとうございました。 DB2 BLUは「LOAD & GO !」が合言葉で何ら難しい設定や準備が不要なので、 もしかしたら「ハンズオンのやりがいが無いなあ」と拍子抜けした方もおられるかもしれませんね。 でも、それでいいのです。それくらい簡単に、高性能を実現できるのだ、とご実感いただけたのであれば、ハンズオンの目的は達成したことになると思っております。 ハンズオンで利用した環境はそのままで結構です。(当方で遮断します) Windowsのリモートデスクトップの接続を切って、終了してください。 最後に、別途メールでご案内したアンケートにご回答頂けると大変有難く存じます。 当ハンズオンへのご参加ありがとうございました！

120 M I S S I O N : C O M P L E T E