Transcript DB 2 BLU Acceleration Hands-On @ C loud

D B 2 B L U Acceleration
Hands-On@Cloud
D B 2 B L U Acceleration Hands-On @ C l o u d
当ハンズオンの進め方
13:00
オープニング
BLUご紹介（講義)
 DB2 BLUの簡単なご紹介をさせていただきます。
 視聴ご不要の方は14:00少し前に参加ください。
 ハンズオン進め方のご案内
14:00
 手順書に沿って各自のペースでハンズオンをお進
めください。（接続まではご一緒にやります)
ハンズオン
 全体の休憩時間等は設けませんので、皆様の
ペースで適宜、ご休憩ください。
 講師がリモートで待機しておりますので、ご質問
があれば電話やチャットでお声かけください。
 早く終了された方はご退席していただいても結構
です。（その場合、講師に一声おかけください）
17:00
1
18:00
クロージング
環境シャットダウン
 QAタイム
 別途、アンケートへのご回答を願いたく存じます。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
当ハンズオンでご体験いただくこと
DB2 V10.5を導入しましょう
データベースを作成しましょう
カラム型テーブルを触ってみましょう
性能測定しましょう（従来型テーブルとの比較)
お時間がある方は、こちら↓もどうぞ。
チューニング(Query Workload Tuner)
2
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
ハンズオン環境
Windows2008 64bit
リモート･デスクトップ接続
インターネット
X-Client
JMETER
VNC Client
QWT
クラウドセンター内通信
皆様のPC
DB2 Server
MYDB
3
BLUDB
RHEL 6.4 64bit
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
当ハンズオン環境固有のお約束
 Windowsのリモート・デスクトップ接続を使います
►
皆様のPCからクラウド環境へはリモートデスクトップで接続します。
►
リモートデスクトップが利用可能なPCをご準備ください。
 Windows2008/ RHEL6.4を各1台使います
►
皆様お一人ずつにクラウド上の上記仮想マシンを各1台づつ割り当てます。
►
割り当てる仮想マシンやIPアドレスはすべて違うものです。
►
RHEL(DB2 サーバー)への操作はすべてWindows 2008上の(TeraTermなどの)クライアントから行います。
皆様のPCにLinuxのためのソフトを準備いただく必要はありません。
 ×仮想マシンは「シャットダウン」しないでください
►
本日のハンズオンの手順で再起動が必要な箇所はありません。
►
万が一、誤って「シャットダウン」すると、ご自身ではブートできません。ホスト名やIPアドレスも変わってしまいます。(ハ
ングしてしまった、など止むうえない事情の場合は「リブート」にしてください。リブートならホスト名やIPアドレスは変わ
りません。）
 パフォーマンス
►
4
諸般の事情により、本日の環境は本来のBLUの推奨環境を下回っていますのでデータの規模も抑えてあります。
皆様が実サーバーで実施する場合よりも遅いでしょうが、その点、ご容赦ください。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
ハンズオン環境のメモ
項目
ホスト名
Windows2008
64bit(x64)
メールでリモートデスクトップ接続のファイル(*.rdp)をお
送りします。
未使用
実施当日にメールでご連絡します
IPアドレス
ユーザーID
Administrator
1) ec2-user
2) root
Password(共通)
Passw0rd
Passw0rd
(oオーではなく0ゼロです)
(oオーではなく0ゼロです)
C:\HandsOn
/handson
/db1-/db4
/work
ディスク
5
RHEL 6.4
64bit(x64)
...スクリプト類
...データベース
...導入イメージと
ロード用データ
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
ご参考) 本日利用する仮想マシンの仕様
Windows2008 64bit(x64)
RHEL 6.4 64bit(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と小さいのでメモリにデータが全部乗ります。
6
※...ECU＝Amazon EC2 Compute Unitの略。AMAZON EC2での相対的なCPU能力を表す指標です。
V1.1 as of 2013/07/27
当節は当日rdpファイルご受領後、午前中に先に実施しておいてください。
(勿論、ご多忙であればハンズオンの冒頭でご実施いただいて結構ですが、
万が一接続できないとその後が続行できませんので、念のため早めのご確認をお勧めしております.)
DIVE
INTO THE CLOUD
D B 2 B L U Acceleration Hands-On @ C l o u d
 お一人にWindows2008環境とRHEL
環境を各1台ずつ割り当ててあります。
Windows
 本日のハンズオンはすべて
RHEL
Windows2008上での操作になります。
ただし、X-クライアントやVNC Viewerを
使った操作では、実際の操作はRHEL
上で行なっていることになります。どちらの
マシンで操作しているのかを明確にするた
めに、以下、当資料ではRHEL上での操
作の場合は右上に以下の記号を記載し
てあります。
RHEL

8
ハンズオンの内容とは直接関係があり
ませんが、知っておくと良いと思うFYI
的なご説明は緑色のコメントで表記し
ます。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
クラウドへのログイン
 事前にメールにてお配りした *.rdp をご自身の
PCのお好みの場所に保管します。
 インターネット環境に接続できることを確認後、
各々のRDPファイルをダブルクリック
 もし下記のたぐいの警告が出たら「接続」ボタン
 「リモートデスクトップ接続」が起動してデスク
トップ接続が開きます。
 Administratorをクリック。パスワード
「Passw0rd」（0=ゼロ)を入力して
Windows2008にログオンします。
 うまくいかない方は講師にお声かけください。
9
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
リモートデスクトップに接続できないときのご確認事項
 rdpファイルに書いてあるサーバーの名前にpingが通りますか？
C:\Documents and Settings\Administrator>ping ec2-184-73-80-108.compute-1.amazonaws.com
Pinging ec2-184-73-80-108.compute-1.amazonaws.com [184.73.80.108] with 32 bytes of data:
Reply from 184.73.80.108: bytes=32 time=195ms TTL=96
Reply from 184.73.80.108: bytes=32 time=195ms TTL=96

PCのパーソナル・ファイアーウオールでリモートデスクトップ接続を遮断していませんか？

御社のインターネット環境でリモートデスクトップ接続が遮断されていませんか？
リモートデスクトップのポート#: TCP 3389 PINGは ICMPです。
これが遮断されている場合は、ポートを開放して頂かないとハンズオンへご参加いただくことができません。
10
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHELサーバーのIPアドレスの確認

リモートデスクトップでWindows2008にログインできたら、以降のハンズオンはその環境で操作
を行います。当日AMにメールでご連絡済のRHELサーバー(=DB2サーバー)のIPアドレスを以
下にメモしておいてください。
►
皆様にメールでご連絡しているのはセンター内でのプライベートなIPアドレスです。
当該仮想マシンはグローバルなDNS名、グローバルなIPアドレスも割り当て済ですが、
当ハンズオンで利用する必要がないので、お知らせしていません。
IPアドレス
RHEL
11
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
ネットワーク環境の確認(ping)
 Windows 2008のコマンドプロンプトを開きます。
 Windows2008からRHELサーバーに対してpingを打ち、通信が可能なことを確認してください。
►
ping RHELサーバーのIPアドレス
では、ハンズオンを開始しましょう！
まずはLinuxサーバへのログインです。
TeraTerm / puttyのお好きな方をお使いください。
12
TeraTerm派の方
putty派の方
→次のページへ
→p17へ
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
Linuxサーバーへのログイン（TeraTermの場合)
 デスクトップ上のTeraTermをダブルクリック
 以下を入力/選択して「OK」ボタン
13
►
ホスト：割り当てられたIPアドレス
►
TCPポート#: 22
►
サービス: SSHを選択(確認のみ)
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 セキュリティ警告は無視してそのまま「接続」ボタン
 ユーザー名に以下を指定
►
ec2-user (英語小文字)
 「RSA/DSA鍵を使う」の「秘密鍵」ボタン
►
パネルが開いたら「デスクトップ」上の以下のファイルを
選択して「開く」ボタン
● BLU.ppk
14
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 秘密鍵に入力できたら「OK」ボタン
 ec2-userでログインできました
15
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 ec2-userでログインできたら、以下でroot
になります。
►
su - root ( - ... ハイフンです)
►
パスワード: Passw0rd
►
Enter
 rootでログインできました!
 TeraTermのフォントサイズや背景の色は「設定」-「ウ
インドウ」「フォント」で変更可能です。お好みに合わせ
てご変更ください。
16
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
Linuxサーバーへのログイン（puttyの場合)
 デスクトップ上のputtyjpをダブルクリック
 左のパネルで「実行」ボタン
17
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 以下を入力/選択
►
「セッションの読込、保存、削除」で
● BLUをダブルクリック
又は
● BLUを選択して「読込」ボタン
 「BLU」の名前で、事前に文字コード(UTF8(CJK))やRSA
鍵ファイル名を定義してあります。
①
►
ホスト名：割り当てられたIPアドレス
►
ポート#: 22
►
接続タイプ: SSHを選択(確認のみ)
 「開く」ボタン
18
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 左記の警告は無視して「はい」ボタン
 ウインドウが開き、login as: が表示された
ら以下を入力してEnter
►
ec2-user
 ec2-userでログインできたら、以下でroot
になります。
►
su - root ( - ... ハイフンです)
►
パスワード: Passw0rd
►
Enter
 rootでログインできました!
19
V1.1 as of 2013/07/27
INSTALL
DB2 BLU
D B 2 B L U Acceleration Hands-On @ C l o u d
GUI画面の起動(VNCクライアント)
 DB2は非GUI環境でコマンドにより導入することも可能ですが、今回はGUIで導入しましょう。
 デスクトップ上のvncviewerのアイコンをダブルクリック
 左記の警告は無視して「実行」ボタン
 以下を入力して「OK」ボタン
►
Server : 割り当てられたIPアドレス:1 (：=コロン)
→ :1はLinux上で稼働しているvncserverの１番目のセッション
画面を使いますよ、という意味です。
21
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
 以下を入力して｢OK」ボタン
►
Password: Passw0rd
→ このパスワードはvncserverで事前に定義済
のもの。OSのパスワードではありません。
 LinuxのGUI画面が表示されました
►
22
ユーザーとしてはrootでログインしています
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
 左上の「アプリケーション」から以下を選択
►
「システム・ツール」- 「端末」
 コマンド行端末のウインドウが開きました
23
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
DB2 V10.5 を導入しましょう（簡単です)
 ではDB2のインストーラーを起動しましょう
 コマンドで以下を入力
►
cd /work/images/server
►
ls にて db2setupがあることを確認
►
./db2setup
 しばらくお待ち下さい
24
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
 では導入を始めましょう。
 「製品のインストール」を選択
 今回導入するのはDB2 10.5 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)でのみ利用できます。
 「新規インストール」ボタン
25
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
 ウイザードが開始したら「次へ」ボタン
 ライセンスに同意し、「次へ」ボタン
26
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
 標準(デフォルト)が選択されていることを確認の
上、「次へ」ボタン
 そのまま「次へ」ボタン
27
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
 そのまま「次へ」ボタン
►
DB2は/opt/ibm/db2/V10.5に導入されます
 管理サーバーのユーザー情報を設定します。
►
「新規ユーザー」でユーザーとグループ名はそのまま
►
「パスワード&パスワードの確認」の各々に以下のパ
スワードを入力します
● Passw0rd
→ ユーザーIDやパスワードは上記でなくてもいいのですが、ハンズオン実施上のわかりや
すさを優先しています。別のユーザーidやパスワードを指定した場合は以下、読み替
えてください。
 「次へ」ボタン
28
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
 「DB2インスタンスを作成する」にチェックされて
いることを確認して「次へ」ボタン
 「単一パーティション」にチェックされていることを
確認して「次へ」ボタン
29
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
 インスタンス所有者のユーザー情報を設定します。
►
「新規ユーザー」でユーザーとグループ名はそのまま
►
「パスワード&パスワードの確認」の各々に以下の
パスワードを入力します
● Passw0rd
 「次へ」ボタン
 fencedユーザーのユーザー情報を設定します。
►
「新規ユーザー」でユーザーとグループ名はそのまま
►
「パスワード&パスワードの確認」の各々に以下の
パスワードを入力します
● Passw0rd
 「次へ」ボタン
30
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
 今回は通知機能は不要なので「現時点では
通知を送信するようにDB2サーバーをセットアッ
プしない」を選択して「次へ」ボタン
 サマリーパネルに到達したら「完了」ボタン
31
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
 導入が開始したら、しばらくお待ち下さい。
►
5分くらいです。
 おめでとうございます！導入が完了しました
►
すでにdb2は起動済です。
►
「完了」ボタンでパネルを終了します。
►
では次はDB2のライセンスを登録しましょう
→ ライセンス登録をしないと以下のメッセージが出
てBLU機能は利用できません。
SQL8029N 要求された機能に対して有効なライセンス・キーが見つかりませ
ん。この製品の現行ライセンス・キーでは、要求された機能を実行できません。
IBM担当員または認定販売店からこの機能用のライセンス・キーを購入し、
db2licmコマンドを使用してライセンスを更新してください。
32
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
 db2licdコマンドでライセンスを追加します

インストーラのパネルが終了し、端末が開いているので、
そこで以下のコマンドを入力します。

現在のユーザーはrootです。
DB2インスタンス管理者であるdb2instにsu します。

DB2 AESE CPUオプションのライセンスファイルは以下
►

/work/images/db2aese_c.lic
手順
►
su - db2inst1
●
►
cd /work/images
►
ls -al
●
►
►
ライセンスファイルを確認します
db2licm -a db2aese_c.lic
●
ライセンスファイルを追加します
db2licm -l
●
33
db2inst1になります
ライセンス登録状況を表示します
[db2inst1@ip-10-149-3-72 ~]$ cd /work/images/
[db2inst1@ip-10-149-3-72 images]$ ls -al
合計 16
drwxrwxrwx 3 root root 4096 6月 24 09:18 2013 .
drwxrwxrwx 5 root root 4096 6月 24 09:19 2013 ..
-rw-rw-r-- 1 ec2-user ec2-user 915 5月 29 19:50 2013 db2aese_c.lic
drwxr-xr-x 5 root root 4096 5月 30 20:06 2013 server
[db2inst1@ip-10-149-3-72 images]$ db2licm -a db2aese_c.lic
LIC1402I ライセンスが正常に追加されました。
LIC1426I この製品は現在、ご使用条件の指定に基づいてご使用い
ただくことができます。 この製品をご使用いただくには、次のディレ
クトリーにある IBM ご使用条件への同意が必要です:
"/opt/ibm/db2/V10.5/license/ja_JP.utf8"
[db2inst1@ip-10-149-3-72 images]$ db2licm -l
製品名:
"DB2 Advanced Enterprise Server
Edition"
ライセンス・タイプ:
"CPU オプション"
有効期限:
"永続"
製品 ID:
"db2aese"
バージョン情報:
"10.5"
制約ポリシー:
"ソフト・ストップ"
[db2inst1@ip-10-149-3-72 images]$
V1.1 as of 2013/07/27
EXPERIENCE
DB2 BLU
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
当章でのハンズオンの進め方
 当章でのハンズオンはTeraTermまたはputtyを使用します。
 以降、コマンド端末より、色々なコマンドやSQLを実行していきます。
皆様のキー入力のお手間を省くため、一括実行できるシェルやSQLファイルを以下に準備しています。
►
C:\Handson (Windowsのデスクトップにショートカットあり)
 各自、下記のお好みの方法でハンズオンをお勧めください。
►
「いちいちコマンドを打つのが面倒だ。結論を知りたい」という方
● シェルやSQLファイルをそのまま実行することで近道ができます。実行して、結果をご確認ください。
►
「じっくりと、一つずつ結果を見ながら進めたい」という方
● 上記シェルやSQLファイルをエディターで開き、コピペして一つずつ実行していってください。
(もちろん一から入力するのでもOKですが、、）
→こんな感じで、コピペして
いけば、楽ができます。
35
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
(オプション) 最新のdb2diag.logを見られるようにしておきましょう

DB2の実行ログであるdb2diag.logを表示し
ておくと、DB2の内部的な動きを見ることがで
きます。

前の章の手順でTeraTermかPuttyのコマンド
端末をもう一つ起動して、db2diagを常に見ら
れるようにしておきましょう。
►

36
36
TeraTermでは「ファイル」ー「セッションの複製」が操作が簡単です。
ec2-userからdb2inst1にsu してdb2diagコマ
ンドを実行します。
►
su - db2inst1
►
パスワードとして「Passw0rd」を入力
►
db2diag -f
►
これで更新がある都度、最新のメッセージが流れていきます
►
tail -f /home/db2inst1/sqllib/db2dump/db2diag.logと同じ事です。
[db2inst1@ip-10-151-48-91 tpch]$ db2diag -f
........
2013-06-28-23.54.07.246062+540 E6429046E763
LEVEL: Info
PID : 3001
TID : 139825281754880 PROC : db2sysc 0
INSTANCE: db2inst1
NODE : 000
DB : BLUDB
APPHDL : 0-7
APPID: *LOCAL.db2inst1.130628145404
AUTHID : DB2INST1
HOSTNAME: ip-10-151-48-91
EDUID : 22
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: 128410305
Last Log Record Lso: 124270015
Current Write Log Extent Limit: 132584129
2013-06-28-23.54.07.315777+540 E6429810E833
LEVEL:
Warning
PID : 3001
TID : 139825281754880 PROC : db2sysc 0
INSTANCE: db2inst1
NODE : 000
DB : BLUDB
APPHDL : 0-7
APPID: *LOCAL.db2inst1.130628145404
AUTHID : DB2INST1
HOSTNAME: ip-10-151-48-91
EDUID : 22
EDUNAME: db2agent (BLUDB) 0
FUNCTION: DB2 UDB, SQO Memory Management,
sqloMemLogPoolConditions, probe:20
DATA #1 : <preformatted>
Reserved heap size exceeded for Kernel(BSU) Heap on node 0,
allocating additional unreserved memory.
Requested block size
: 8521344 bytes.
Physical heap size
: 18415616 bytes.
Configured heap size
: 14352384 bytes.
Unreserved memory used by heap : 4063232 bytes.
Unreserved memory left in set : 17104896 bytes.
V1.1 as of 2013/07/27
© 2013 IBM Corporation
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
DB2レジストリー・パラメーターを設定しましょう
実行例

TeraTermまたはputtyから実行します。

現在のユーザーはrootです。
DB2インスタンス管理者であるdb2instにsu します。
►

su - db2inst1
実行スクリプトは /handsonにあります。
►
cd /handson
 FastPath
►
37
db2level
現在のDB2レジストリー変数を見てみましょう。
右の2つのみ設定されていることと思います。
►
37
じっくり、の方はこちら。
[db2inst1@ip-10-138-30-57 ~]$ db2level
DB21085I このインスタンスまたはインストール
(該当する場合のインスタンス名: "db2inst1") は "64"
ビットおよび DB2 コード・リリース "SQL10050" をレベル ID
"0601010E" で使用します。
情報トークンは、"DB2v10.5.0.0"、"s130528"、"LINUXAMD64105"、およ
びフィックスパック "0"です。
製品は "/opt/ibm/db2/V10.5" にインストールされています。
DB2のレベルを見てみましょう。10.5になっていますね?
►

お急ぎの方はこちら。
./01_start_blu.sh
 Step by Step

[root@ip-10-149-3-72 handson]# su - db2inst1
[db2inst1@ip-10-149-3-72 ~]$ cd /handson
[db2inst1@ip-10-149-3-72 ~]$
[db2inst1@ip-10-138-30-57 ~]$ db2set
DB2COMM=TCPIP
DB2AUTOSTART=YES
db2set
V1.1 as of 2013/07/27
© 2013 IBM Corporation
D B 2 B L U Acceleration Hands-On @ C l o u d



38
38
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本入れて多重
度を上げています。
RHEL
[db2inst1@ip-10-138-30-57 ~]$ db2set DB2_WORKLOAD=ANALYTICS
[db2inst1@ip-10-138-30-57 ~]$ db2set
DB2_WORKLOAD=ANALYTICS
DB2COMM=TCPIP
DB2AUTOSTART=YES
→この設定により、以降作成されるデータベースではBLUに最
適な設定が自動的に行われ、新規に作成するテーブルはカラム
型がデフォルトになります。便利です。
[db2inst1@ip-10-138-30-57 ~]$ db2 -v stop dbm force
stop dbm force
DB20000I STOP DATABASE MANAGER コマンドが正常に完了しまし
た。
[db2inst1@ip-10-138-30-57 ~]$ db2 -v start dbm
start dbm
DB20000I START DATABASE MANAGER コマンドが正常に完了しま
した。
[db2inst1@ip-10-138-30-57 ~]$ 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)
= 15
15
内部通信バッファーの数 (4KB)
(FCM_NUM_BUFFERS) =
AUTOMATIC
AUTOMATIC
.....
V1.1 as of 2013/07/27
© 2013 IBM Corporation
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
• 前ページの例のようにAUTOCONFIGUREオプションをつけてデータベースを作成すると、デフォルト値からBLUの
最適値に調整されたパラーメーター一覧が表示されます。
– 出力例 （設定値は、HWのスペックなど環境によって異なります）
※FastPathで「01_start_blu.sh」を実行された方は、mydb.outファイルに以下の内容が出力されています。
データベース構成の以前の値と適用値
39
説明
パラメーター
以前の値
適用値
------------------------------------------------------------------------------------------------CPUパラレルのデフォル
デフォルト・アプリケーション・ヒープ (4KB) (APPLHEAPSZ) = 256
256
トの多重度を自動調整
カタログ・キャッシュ・サイズ (4KB)
(CATALOGCACHE_SZ) = (MAXAPPLS*5)
360
変更ページしきい値
(CHNGPGS_THRESH) = 60
80
データベース・ヒープ (4KB)
(DBHEAP) = 1200
6171
並列処理の度合い
(DFT_DEGREE) = 1
ANY
デフォルトの表スペース・エクステント・サイズ (ページ) (DFT_EXTENT_SZ) = 4
4
デフォルトのプリフェッチ・サイズ (ページ) (DFT_PREFETCH_SZ) = AUTOMATIC
AUTOMATIC
デフォルトの照会最適化クラス
(DFT_QUERYOPT) = 5
5
ロック・リスト用最大ストレージ (4KB)
(LOCKLIST) = 4096
AUTOMATIC
ログ・ファイルのサイズ (4KB)
(LOGFILSIZ) = 1000
1024
BLUの利用に最適化する
1 次ログ・ファイルの数
(LOGPRIMARY) = 3
45
ため、SORTヒープとユー
2 次ログ・ファイル数
(LOGSECOND) = 10
19
ティリティヒープを
アクティブ・アプリケーションの最大数
(MAXAPPLS) = AUTOMATIC
AUTOMATIC
調整
アプリケーションあたりのロック・リストのパーセント (MAXLOCKS) = 10
AUTOMATIC
非同期ページ・クリーナー数
(NUM_IOCLEANERS) = 4
2
入出力サーバー数
(NUM_IOSERVERS) = 16
13
パッケージ・キャッシュ・サイズ (4KB)
(PCKCACHESZ) = (MAXAPPLS*8)
AUTOMATIC
ソート・リスト・ヒープ (4KB)
(SORTHEAP) = 256
46030
SQL ステートメント・ヒープ (4KB)
(STMTHEAP) = 8192
16384
統計ヒープ・サイズ (4KB)
(STAT_HEAP_SZ) = 4384
4384
ユーティリティー・ヒープ・サイズ (4KB) (UTIL_HEAP_SZ) = 5000
AUTOMATIC
デフォルトの表タイプは、
セルフチューニング・メモリー
(SELF_TUNING_MEM) = OFF
ON
カラム・オーガナイズ表
自動 RUNSTATS
(AUTO_RUNSTATS) = ON
ON
共有ヒープのソート・ヒープしきい値 (4KB) (SHEAPTHRES_SHR) = 5000
920618
ログ・バッファー・サイズ (4KB)
(LOGBUFSZ) = 256
2152
デフォルトの表編成
(DFT_TABLE_ORG) = ROW
COLUMN
データベース・メモリーしきい値
(DB_MEM_THRESH) = 100
100
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
バッファー・プールの以前の値と適用値
説明
パラメーター
以前の値
適用値
------------------------------------------------------------------------------------------------IBMDEFAULTBP
バッファー・プール = 1000
115077
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
= 1.50000E+05
1.50000E+05
Threshold SYSDEFAULTCONCURRENT Enabled
= Y
Y
Threshold SYSDEFAULTCONCURRENT Maxvalue
= 11
11
1.5e+04を超えるコストの
クエリーは最大11同時実
行に調整
40
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d

41
上記を反映するためにDB2を再起動します。
►
db2 -v stop dbm force (or db2stop force)
►
db2 -v start dbm (or db2start )

以上でデータベースが作成され、環境のチューニングが
自動的に行われました。

次はテーブルを作成してデータをロードしましょう。
RHEL
[db2inst1@ip-10-138-30-57 ~]$ db2 -v stop dbm force
stop dbm force
DB20000I STOP DATABASE MANAGER コマンドが正常に完了しまし
た。
[db2inst1@ip-10-138-30-57 ~]$ db2 -v start dbm
start dbm
DB20000I START DATABASE MANAGER コマンドが正常に完了しま
した。
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
カラム型テーブルを作成してデータをロードしましょう
実行例

現在のユーザーはdb2inst1です。
 FastPath
►
db2 -tvf 02_try_blu.sql
►
drop tableのエラーは無視してください。リラン可能にするために念のため
追加しているものです。
 Step by Step


►
db2
►
以降はDB2コマンドプロンプト上で入力します
►
create table文などは一から入力するのは大変なのでコピペを
お勧めします。
MYDBに接続します
42
connect to mydb
カラム型テーブルを作成します
►
42
じっくり、の方はこちら。
DB2コマンドプロンプトを開始します
►

お急ぎの方はこちら。
create table t1_c ( c1 bigint not null
primary key, c2 int, c3 double, c4
char(10), c5 varchar(10))
後のハンズオンのためにC1をプライマリー・キーに指定しています。
create table t1_c ( c1 bigint not null primary key, c2 int, c3 double, c4
char(10), c5 varchar(10))
DB20000I SQL コマンドが正常に完了しました。
V1.1 as of 2013/07/27
© 2013 IBM Corporation
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
実行例

比較のために従来の行型のテーブルも作成します。
►
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で行型を指定しています。
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をプライマリー・キーに指定しています。

再帰SQLを利用して、データを1000万件生成します
►
43
export to /work/data/data01.txt of del
with temp(a) as ( values(1) union all
select a+1 from temp where a<10000000)
select
a,a/10000,rand()*1000,'AAAAA','BBBBB'
from temp
►
/work/data/data01.txtに1000万件のランダムなデータが
出力されます。
►
3-4分かかります。お待ちください。
export to /work/data/data01.txt of del with temp(a) as ( values(1) union all
select a+1 from temp where a<10000000) select
a,a/10000,rand()*1000,'AAAAA','BBBBB' from temp
SQL3104N エクスポート・ユーティリティーが、 ファイル
"/work/data/data01.txt"
へのデータのエクスポートを開始しています。
SQL3105N エクスポート・ユーティリティーが、"10000000"
行のエクスポートを完了しました。
エクスポートされた行数: 10000000
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d

行型のテーブルにデータをロードします。
►



次はカラム型のテーブルにデータをロードします。
►
load from /work/data/data01.txt of del replace
into t1_c nonrecoverable
►
db2diag.logを見ると、ロードの始めにデータを分析する
ANALAYZEフェーズがあること、統計情報も同時に収集
していること、などが見て取れます。
行型テーブルに対して統計情報を取得します
►
runstats on table db2inst1.t1_r
►
カラム型テーブルは統計情報も自動化されています。
load from /work/data/data01.txt of del replace into t1_c nonrecoverable
SQL3501W 順方向リカバリーがデータベースに対して使用でき
ないため、表が存在する表スペースが、バックアップ・ペン
ディング状態に 置かれません。
SQL3109N ユーティリティーが、ファイル "/work/data/data01.txt"
から データのロードを開始しています。
<<途中省略>>
読み込まれた行数
= 10000000
スキップされた行数 = 0
ロードされた行数
= 10000000
拒否された行数
=0
削除された行数
=0
コミットされた行数 = 10000000
runstats on table db2inst1.t1_r
DB20000I RUNSTATS コマンドが正常に完了しました。
ここまで終わったらDB2のコマンド行プロンプトを終了し
ます
►
44
load from /work/data/data01.txt of del replace
into t1_r nonrecoverable
RHEL
terminate
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d

以下、今開いているTeraTerm/Puttyのウインドウ
でOSのコマンドとして実行します。
まずはデータベースに接続します。
►

手始めに件数を取得して時間を比較しましょう。
まずは行型のテーブルです。
►


45
db2 connect to mydb
time db2 “select count(*) from t1_r”
次はカラム型のテーブルです。
►
time db2 “select count(*) from t1_c”
►
02_try_blu.sqlではdb2batchを利用しています。
実行時間の結果はいかがでしょうか?
[db2inst1@ip-10-151-48-91 handson]$ time db2 "select count(*) from t1_r"
1
----------10000000
1 レコードが選択されました。
real 0m0.268s
user 0m0.016s
sys 0m0.029s
[db2inst1@ip-10-151-48-91 handson]$ time db2 "select count(*) from t1_c"
1
----------10000000
1 レコードが選択されました。
real 0m0.309s
user 0m0.017s
sys 0m0.028s
[db2inst1@ip-10-151-48-91 handson]$
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
システムカタログとディスク所要量を確認しましょう

 FastPath
►
お急ぎの方はこちら。
db2 –tvf 03_check_cat.sql
 Step by Step
ここは打つのが面倒なのでFastPath方式で実行して、結果を見る
だけにすることをお勧めします。

カタログからテーブルが行型か、列型かを識別しま
す。
►

46
select varchar(tabschema,8) tabschema,
varchar(tabname,10) tabname, tableorg
from syscat.tables where
tabschema='DB2INST1‘
カタログから、両テーブルのディスク所要量を調べます
►
46
実行例
現在のユーザーは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'
[db2inst1@ip-10-138-30-57 handson]$ db2 -tvf 03_check_cat.sql
connect to mydb
データベース接続情報
データベース・サーバー = DB2/LINUXX8664 10.5.0
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
256
229248
108544
338048
T1_R
519680
207488
0
727168
2 レコードが選択されました。
T1_CはT1_Rに比してディスク所要量が半分くらいで
済んでいることがわかります。
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
カラム型テーブルを更新してみましょう
BLUはDWHや分析特化した機能なので、殆どのワークロードは照会になるかと思われます。
とはいえ、BLUでは更新・削除・挿入やユニーク制約を設定することも可能です。
実際にそうか、見て行きましょう。
実行例

現在のユーザーはdb2inst1です。
 FastPath
►
お急ぎの方はこちら。
db2 –tvf 04_sql_crud.sql
 Step by Step

DB2のコマンド行プロセッサーを起動します
►

db2
まずは20万件を削除してみます。
(更新ログFULLを回避するために削除対象を絞っています)
47
47
►
delete from t1_c where c1 between 1 and
200000
►
select count(*) from t1_c
[db2inst1@ip-10-138-30-57 handson]$ db2 -tvf 04_sql_crud.sql
connect to mydb
データベース接続情報
データベース・サーバー = DB2/LINUXX8664 10.5.0
SQL 許可 ID
= DB2INST1
ローカル・データベース別名 = MYDB
delete from t1_c where c1 between 1 and 200000
DB20000I SQL コマンドが正常に完了しました。
select count(*) from t1_c
1
----------9800000
1 レコードが選択されました。
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
実行例

次は更新です。20万件を更新してみます。
(更新ログFULLを回避するために削除対象を絞っています)
►
update t1_c set c5='hoge' where c1
between 200001 and 400000
►
select c1,c5 from t1_c order by c1 fetch
first 10 rows only
update t1_c set c5='hoge' where c1 between 200001 and 400000
DB20000I SQL コマンドが正常に完了しました。
select c1,c5 from t1_c order by c1 fetch first 10 rows only
C1
C5
-------------------- ---------200001 hoge
200002 hoge
<<途中省略>>
200010 hoge
10 レコードが選択されました。

10万件のデータを生成して挿入してみます。
►
►

48
48
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')
►
ユニーク制約に抵触したとのエラーが返りましたね?
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
DB20000I SQL コマンドが正常に完了しました。
select count(*) from t1_c
1
----------9900000
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
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
カラム型テーブルを再編成してスペースを空けましょう
BLUではDELETEは論理削除です。つまり、「削除した印」をつけるだけであり、即座にディ
スクのスペースが解放されるわけではありません。スペースの解放はバックグラウンドで自動
的に行われるので運用が楽です。とはいえ時間差があるので、「すぐに解放したい」場面もある
でしょう。そのような場合は再編成を行えば解放されます。
実行例

現在のユーザーはdb2inst1です。

前のステップで削除を実行しましたので、そのスペースを
解放しましょう。
 FastPath
お急ぎの方はこちら。
►
db2 –tvf 03_check_cat.sql
►
db2 –tvf 05_reorg_table.sql
►
db2 –tvf 03_check_cat.sql
TABNAME DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE
COL_OBJECT_P_SIZE ALLSIZE
---------- -------------------- -------------------- -------------------- -------------------T1_C
256
233856
123904
358016
T1_R
519680
207488
0
727168
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
256
233856
120320
354432
T1_R
519680
207488
0
727168
49
49
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
実行例
 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‘
●

50
reorg table db2inst1.t1_c reclaim extents
再編成後のディスクサイズを確認します。
►

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
256
233856
123904
358016
T1_R
519680
207488
0
727168
上のselectと同じ
TABNAME DATA_OBJECT_P_SIZE INDEX_OBJECT_P_SIZE
COL_OBJECT_P_SIZE ALLSIZE
---------- -------------------- -------------------- -------------------- -------------------T1_C
256
233856
120320
354432
T1_R
519680
207488
0
727168
ディスクの使用量が減っていますね?
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
従来型(行型)テーブルをカラム型テーブルへ変換してみましょう
BLUでは、既存の行型テーブルをカラム型テーブルに変換するdb2convertコマンドが提供
されています。先ほど作った t1_rをカラム型テーブルに変換してみましょう。
実行例

現在のユーザーはdb2inst1です。
 FastPath
►
お急ぎの方はこちら。
db2 -tvf 06_convert_tbl.sql
 Step by Step

以下をOSのコマンドとして実行します。
►
51
51
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"
10000000
0
UNSTARTED
0.00
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
0
INIT
0.00
<<途中省略>>
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
10000000
COPY
100.00
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
0
0
REPLAY
100.00
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
0
0
SWAP
100.00
最終サマリー:
Table
RowsNum
InitSize (MB) FinalSize (MB) CompRate (%) State
--------------------------------------- --------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
710.12
331.88
53.27
Completed
Pre-Conversion Size (MB): 710.12
Post-Conversion Size (MB): 331.88
Compression Rate (Percent): 53.27
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
!db2convert -d mydb -u db2inst1 -z db2inst1 -t t1_r
変換を続行しています...
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
0
UNSTARTED
0.00
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
0
INIT
0.00
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
0
COPY
0.00
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
8930304
COPY
89.30
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
10000000
COPY
100.00
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
0
0
REPLAY
100.00
Table
RowsNum
RowsComm
Status
Progress (%)
--------------------------------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
0
0
SWAP
100.00
最終サマリー:
Table
RowsNum
InitSize (MB) FinalSize (MB) CompRate (%) State
--------------------------------------- --------------- --------------- --------------- --------------- --------------"DB2INST1"."T1_R"
10000000
710.12
331.88
53.27
Completed
Pre-Conversion Size (MB): 710.12
Post-Conversion Size (MB): 331.88
Compression Rate (Percent): 53.27
52
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
(TBライセンスの場合の)準拠状況を確認しましょう
DB2 BLUをTBライセンスでご利用の場合は、コンプライアンスの観点で、ご購入済のTBサイ
ズやご利用条件を逸脱していないかの確認をしたい場合があります。その場合はカタログを照
会して現状をご確認いたたくためのスクリプト(※)が製品に同梱され、導入されています。
※...TBライセンスのTBは元のデータのサイズではなく、DB2に圧縮・格納された時点でのサイズです。
また、全体のデータ量の75%以上がDWH的用途(今の場合はカラム型テーブル)に格納されている必要
があります。
※..../opt/ibm/db2/V10.5/bin/tbpsize_entitlement_req.sql
53
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
 FastPath
►
db2 connect to mydb
►
db2 -tvf /opt/ibm/db2/V10.5/bin/tbpsize_entitlement_req.sql
 Step by Step
►
実行例
打つのが大変なので、FastPathをそのまま実行してください。
[db2inst1@ip-10-141-157-251 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 v10.5.0.0
s130528
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/1073741824.0), 31,
11 ) as USER_DATA_L_SIZE_TB, COALESCE( CEIL( DEC( (S.USER_DATA_L_SIZE_KB/1073741824.0), 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
------------------ -------------------------- -------------------- --------------------------------- --------------------------------MYDB
2013-07-27-11.17.06.954351
238272
0.00022190809
1 レコードが選択されました。
54
USER_DATA_L_ENTITLEMENT_REQ_TB
1.
このデータ量なら1TB分のライセンス
があればいいことがわかります
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
実行例（続き)
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
------------------ ------------------ --------------------- --------------------- -------------------- -------------------- -------------------- -------------------- ----------DB2INST1
T1_C
256
0
0
0
123904
124160
DB2INST1
T1_R
256
0
0
0
112256
112512
SYSTOOLS
HMON_ATM_INFO
256
0
0
0
0
256 N
SYSTOOLS
HMON_COLLECTION
256
0
0
0
0
256 N
SYSTOOLS
OTM_SEMAPHORE_TABL
256
0
0
0
0
256 N
SYSTOOLS
POLICY
256
0
576
0
0
832 N
6 レコードが選択されました。
55
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
性能測定用のデータベースを準備しましょう
次は性能測定のためのデータベースを準備します。とはいえ、データ生成やロードを実行している間、何も
せず待っているのは退屈です。皆様のお時間を節約するために、すでに5GBのサイズの測定用の
DB(BLUDB)を作成してあります。先ほど作成したMYDBはもう利用しないのでアンカタログし、性能測定用
のDB(BLUDB)をカタログして使えるようにします。
実行例

現在のユーザーはdb2inst1です。
 FastPath
►
システム・データベース・ディレクトリー
お急ぎの方はこちら。
./08_switch_db.sh
 Step by Step

以下をOSのコマンドとして実行します。

現状を確認します。
►

56
56
db2 list database directory
ディレクトリー中の項目数 = 1
データベース 1 項目:
データベース別名
= MYDB
データベース名
= MYDB
ローカル・データベース・ディレクトリー = /db1
データベース・リリース・レベル
= 10.00
コメント
=
ディレクトリー項目タイプ
= 間接
カタログ・データベース・パーティション番号 = 0
代替サーバー・ホスト名
=
代替サーバーのポート番号
=
MYDBをアンカタログします。
►
db2 uncatalog database mydb
►
本来はアンカタログは必須ではないのですが、性能測定
中に誤ってmydbにアクセスするとDBが活動化され不要
なメモリを確保し、性能測定環境へ悪影響をおよぼす
可能性があります。そのような事態を防止する意味で念
のためアンカタログします。
DB20000I UNCATALOG DATABASE コマンドが正常に完了しました。
DB21056W ディレクトリーの変更は、
ディレクトリー・キャッシュがリフレッシュされるまで反映されません。
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
実行例


性能測定用の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
代替サーバー・ホスト名
=
代替サーバーのポート番号
=
2013-06-28 14:03:42 0 0 SQL1064N DB2STOP の処理が正常に終
了しました。
SQL1064N DB2STOP の処理が正常に終了しました。
06/28/2013 14:03:45 0 0 SQL1063N DB2START の処理が正常に終
了しました。
SQL1063N DB2START の処理が正常に終了しました。
DB20000I ACTIVATE DATABASE コマンドが正常に完了しました。
57
57
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
性能測定の前に．．データ・スキッピングを確かめてみましょう
BLUでは、索引を作らずとも、条件に一致しないデータ範囲を自動的に読み飛ばして性能を上げてくれる
「データ・スキッピング」という機能が実装されています。
►データの一定の塊ごとに、格納されているデータの最小値/最大値を持ちます。
►情報は自動的に収集され、管理者によるメンテナンスは不要です。
2013年5月のデータは？
Min:2013/01/10
Max:2013/05/20
Min:2013/04/20
Max:2013/05/15
Min:2012/05/01
Max:2013/05/10
Min:2013/03/01
Max:2013/03/31
Min:2013/01/01
Max:2013/02/28
58
58
Min:2013/04/01
Max:2013/04/30
Min:2012/12/01
Max:2012/12/31
Min:2012/10/01
Max:2012/12/31
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
ではデータスキッピングを確かめてみましょう。 絞り込み条件である日付の範囲が ①１ケ月 ②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 '1993-01-01' and '1993-0131' “
31日分
件数
1日分 ►
件数
59
59
db2 -tv "select count(*) from
tpch_c.lineitem where l_shipdate
between '1993-01-01' and '1993-0101' "
実行例
select count(*) from tpch_c.lineitem where l_shipdate between '1993-01-01' and '1993-01-31'
1
----------386375
1 レコードが選択されました。
select count(*) from tpch_c.lineitem where l_shipdate between '1993-01-01' and '1993-01-01'
1
----------12478
1 レコードが選択されました。
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
実行例


初回はディスクIOが発生するので、同じSELECTを3回
ずつ実行して、3回目の実行時間を比べてみましょう。
まずは31日分を3回繰り返し
►
time db2 -tv +o "select * from tpch_c.lineitem
where l_shipdate between '1993-01-01' and
'1993-01-31' “
●

次は1日分を3回繰り返し
►

60
time db2 -tv +o "select * from tpch_c.lineitem
where l_shipdate between '1993-01-01' and
'1993-01-01' “
いかがでしょう？索引を一切作らなくても、7秒 vs 0.7
秒と実行時間が10倍違いますね。これがデータスキッ
ピングの効果です。
►
60
timeコマンドで、後に続くコマンドの実行時間が表示されます
通常のＲＤＢでは、索引を何も作成しない場合、結果を得るための
「近道」がありませんので、条件が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
V1.1 as of 2013/07/27
RHEL
D B 2 B L U Acceleration Hands-On @ C l o u d
ついでにEXPLAINしてみましょう
カラム型テーブルであっても、従来と同様、EXPLAINでのアクセスパス解析が可能です。

現在のユーザーはdb2inst1です。
 FastPath
►
お急ぎの方はこちら。
./10_explain.sh
 Step by Step

以下をOSのコマンドとして実行します。
►

61
1日分
►
db2expln -database bludb statement "select * from
tpch_c.lineitem where l_shipdate
between '1993-01-01' and '1993-0101'" -terminal -terminator ';' -graph
db2 connect to bludb
31日分
►
61

db2expln -database bludb statement "select * from
tpch_c.lineitem where l_shipdate
between '1993-01-01' and '1993-0131'" -terminal -terminator ';' -graph
実行例は次のページにあります。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
RHEL
実行例
*******************
31 days
*******************
DB2 Universal Database Version 10.5, 5622-044 (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 '1993-01-01' and '1993-01-31'
Intra-Partition Parallelism Degree = 4
BLUではINTRA_PARALLEL必須
Section Code Page = 1208
Estimated Cost = 77383.671875
Estimated Cardinality = 396158.687500
コスト・ベースで動いてます。
31日と1日ではコストは似ていますが
Cardinarityがかなり異なっているはず
です。
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
以上で「入門編」は終わりです。次は性能測定です。
62
62
V1.1 as of 2013/07/27
DB2 BLU PERFORMANCE
D B 2 B L U Acceleration Hands-On @ C l o u d
お待たせしました。ではパフォーマンスを測りましょう
前章ではBLUの機能や使い方をごく簡単に体験しました。環境設定は非常に簡単で、通常
のRDBと同じ感覚でご利用いただける点がお分かりいただけたかと思います。
当章では同一構造の行型・カラム型 両方のテーブルに負荷ツール JMETERで照会を実行
してパフォーマンスの違いを経験してみましょう。なお、ワークロードとしてデータウエアハウス
用のベンチマークであるTPC-Hを利用します。
Windows2008
SELECT
SELECT
SELECT
RHEL6.4
JDBC
BLUDB
http://www.tpc.org/tpch/
64
64
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
ご参考) 利用するスキーマ
 TPC-Hでは左のように8つのテーブルが定
義されています。
 今回はデータを5GB分用意しました。
 実行する照会もTCP-Hで定義されてい
るものを利用します。
http://www.tpc.org/tpch/spec/tpch2.15.0.pdf より転載
65
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
BLUDB上に作成済のテーブルと環境
 BLUDB上には、スキーマの異なる同じレイアウトのテーブルが各々8つ定義されており、すでに5GBの
データが各々にロード済です。
カラム型
スキーマ
テーブル名
TPCH_C
PART
SUPPLIER
PARTSUPP
CUSTOMER
行型
TPCH_R
NATION
LINEITEM
REGION
ORDERS
66
 従来型（行型)テーブルは以下の定義
行数
1,000,000
►
データ圧縮あり（Adaptive)
50,000
►
索引はJOINキーのみ付与
►
圧縮もせず索引一切なし、のテーブルは毎回全件
スキャンになるので、それと比べて「カラム型は速いで
しょう」といっても説得力がないので。。。
4,000,000
750,000
25
29,999,795
5
 カラム型テーブルは特に何も指定せず
 バッファープールは8GB=
データが全部メモリに乗る大きさ、です。
7,500,000
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
JMETERを準備しましょう
ではJMETERを起動して負荷スクリプトを準備しましょう。
 デスクトップ上の「JMETER」アイコンを
ダブルクリック
 しばらくお待ち下さい。
JMETERが起動します。
67
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 JMETERの負荷定義ファイルを開きます。
►
「ファイル」
►
DB2_BLU_TPCH_COL.jmxを選択
● DB2_BLU_TPCH_ROW.jmxは従来型テーブル用で、
次に使います。お間違えなきよう。
 開いたら、以下をダブルクリック
►
「カラム型スレッドグループ」
 下に定義が展開されます。
68
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 jdbcの接続URLに宛先となるDB2サーバーの
IPアドレスを指定します。
►
「JDBC Connection Configuration」
►
「Database URL」欄
►
XX.XX.XX.XXの箇所を、事前に皆様にお
知らせしたRHELサーバーのIPアドレスに書
き換えてください。
 SELECT文のスキーマが「TPCH_C」になって
いることを念のため確認します。
69
►
「スキーマ」
►
変数schemaの値が「TPCH_C」になって
ますね？
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 Query01をクリックすると、実際に実行する
select文が定義されていることがわかります。
これらがTPC-Hで定義された照会です。
JMETERはこのSELECTを01から順番に
実行し、実行時間をレポートしてくれます。
 よろしければ、コマンド端末をもう一つ起動し
てシステムのモニタリング・ツールである
nmonを起動しておきましょう。nmonを使
えばCPUやディスクIOの状況をグラフィックで
見ることができますので、DB2の動きがご覧
いただけます。
►
コマンド端末を開く
►
nmon と入力して改行
►
上のメニュー画面が表示されたら
● 英小文字 c
● 英小文字 d
● と連続して入力すれば、CPUとディス
クの状況が位置画面に表示されます。
70
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
ご参考) JMETERのメニュー・ボタン
 以降で共通の操作なので、以下にJMETERのボタンの意味をお示しします。
 当ハンズオンで使うものは、「実行」と「結果のクリア」のみ、ですので、この2つだけ覚えておいてく
ださい。
実行
定義ファイル
(*.JMX)を開く、閉じ
る、保存する
71
COPY&PASTE
結果のクリア
実行の停止
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
性能測定を実行しましょう(1) ～ カラム型テーブル
 では、まずはカラム型テーブルの性能を確認しましょう。初回はメモリー上のバッファーにデータが一切載っ
ていないのでディスクの読み込みが発生し、それなりに時間がかかります。
 ディスク読み込みが発生する場合、発生しない場合での性能を区別するために、測定は以下の2回、
実行します。
►
#1 20種類のSELECTを各1回 これでディスクが読まれ、データがメモリに展開される
►
#2 20種類のSELECTを各5回 全件メモリ上でヒット
 結果パネルを表示して、実行します
72
►
「統計レポート」をクリック
►
「実行」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 それぞれのSELECTが完了すると、応答時
間が次第にパネルに表示されます。
►
nmonも見ている場合、ディスクReadが
発生し、負荷が上がっているのがご覧い
ただけます。
 Query01-22までが各1回実行されると、
JMETERは自動的に処理を停止します。
►
完了は実行ボタンが再び選べるようになることでわかります。
 左記は当方での実行結果です。(皆様の結
果とは異なるかもしれませんが、環境が同じ
なので大筋は似ているかと存じます）数字の
単位はミリ秒です。これを見ると、19個の
SELECTの平均は5.1秒であったこと、最長
がQuery01で18.3秒かかったこと、が見て
取れます。
73
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 今の実行でデータはすべてメモリ上に展開され
たはずです。では、2回目の処理を実行しましょ
う。今回は20個のselectを各5回実行します。
 実行回数を変更します。
►
「カラム型スレッドグループ」を選択
►
「ループ回数」を5に変更
►
クリアボタンで先程の実行結果をクリアします。
 改めて実行します
74
►
「統計レポート」をクリック
►
● 先ほどの結果はクリアされていますね?
「実行」ボタン
►
しばらくお待ち下さい。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 以下が実行の例です。平均実行時間は1.7秒(1回目は5.1秒でした)、最大が6.3秒、1秒以下の
ものも散見されます。
75
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 数字だけだと全体を理解しづらいのでグ
ラフにしましょう。
►
「Aggregae Graph」をクリック
►
「Display Graph」ボタン
 左記のように、棒グラフが表示されます。
►
76
１秒近辺のものが結構ありますね。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
性能測定を実行しましょう(2) ～ 従来型(行型)テーブル
 次は従来型のテーブルに対して性能測定を行
います。あとで両方の結果を比較したいので、
先ほど起動したJMETERは終了せず、もうい
ちどアイコンをクリックして別のJMETERを起動
します。
 JMETERの負荷定義ファイルを開きます。
►
「ファイル」
►
DB2_BLU_TPCH_ROW.jmxを選択
● 上記は表のスキーマ以外は先ほどのファイルと
同じものです。
 開いたら、以下をダブルクリック
►
「従来型（行型)スレッドグループ」
 下に定義が展開されます。
77
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 先ほどと同様に、jdbcの接続URLに宛先とな
るDB2サーバーのIPアドレスを指定します。
►
「JDBC Connection Configuration」
►
「Database URL」欄
►
XX.XX.XX.XXの箇所を、事前に皆様にお
知らせしたRHELサーバーのIPアドレスに書
き換えてください。
 SELECT文のスキーマが「TPCH_R」になって
いることを念のため確認します。
78
►
「スキーマ」
►
変数schemaの値が「TPCH_R」になって
ますね？
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 まずは初回はディスク読み込みパターンです。
►
「従来型（行型）スレッドグループ」をクリック
►
「ループ回数」が 1 であることを確認します。
 では実行します。
79
►
「統計レポート」をクリック
►
「実行」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 しばらくお待ち下さい
 Query01-22までが各1回実行されると、
JMETERは自動的に処理を停止します。
 左記は当方での実行結果です。数字の単
位はミリ秒です。これを見ると、19個の
SELECTの平均は5.6秒であったこと、最長
がQuery01で29.6秒かかったこと、が見て
取れます。
80
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 今の実行でデータはすべてメモリ上に展開され
たはずです。では、2回目の処理を実行しましょ
う。今回は20個のselectを各5回実行します。
 実行回数を変更します。
►
「従来型(行型)スレッドグループ」を選択
►
「ループ回数」を5に変更
 改めて実行します
►
クリアボタンで先程の実行結果をクリアします。
►
「統計レポート」をクリック
● 先ほどの結果はクリアされていますね?
81
►
「実行」ボタン
►
しばらくお待ち下さい。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 以下が実行の例です。平均実行時間は4.2秒(1回目は5.6秒でした)、最大が14秒、1秒以下のも
のは、あまりありません。
82
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 同様に、グラフにしましょう。
►
「Aggregae Graph」をクリック
►
「Display Graph」ボタン
 左記のように、棒グラフが表示されます。
►
全体的に、3-4秒近辺のものが多い
ですね。
 カラム型のほうは、何もチューニングせず
とも1秒前後のものが結構ありました。
翻って従来型の場合は、まだまだチュー
ニングの余地がありそうです。
►
83
誤解無いように申し添えますが、あらゆるケースで
カラム型のほうが常に性能が良い、と申しているわ
けではございません。次のハンズオンで見ていきま
すが、従来型でもここから頑張ってチューニング作
業を施せば性能は改善します。ただ、カラム型な
らそういうご苦労(工数）が不要でシンプルです、
管理が楽です、というお話です。V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 以下はご参考までに両方の結果を並べてみたものです。皆様もご自身の結果を比較してみてください。
カラム型の結果
従来型の結果
84
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 以上で性能測定は終了です。
 2つのJMETERを終了してください。
►
「ファイル」－「終了」 または
►
右上の終了ボタン
 左記のメッセージには「いいえ」ボタン。
85
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
お疲れ様でした！
 以上でハンズオンは終わりです。最後までお付き合い頂き、ありがとうございました。
 DB2 BLUは「LOAD & GO !」が合言葉で何ら難しい設定や準備が不要なので、
もしかしたら「ハンズオンのやりがいが無いなあ」と拍子抜けした方もおられるかもしれ
ませんね。
でも、それでいいのです。それくらい簡単に、高性能を実現できるのだ、とご実感い
ただけたのであれば、ハンズオンの目的は達成したことになると思っております。
 お時間に余裕のあるかたは、以降の「Tune DB2」のパートにお取り組みください。
製品に添付の「Query Workload Tuner」を使って「従来表のチューニング」や
「このテーブルはカラム型テーブルへ変換したらいいのではないか、と推奨してくれる
機能」をご紹介しております。
所要時間は30-40分です。
 ハンズオンで利用した環境はそのままで結構です。(当方で遮断します)
Windowsのリモートデスクトップの接続を切って、終了してください。
 最後に、別途メールでご案内したアンケートにご回答頂けると大変有難く存じます。
 当ハンズオンへのご参加ありがとうございました！
86
V1.1 as of 2013/07/27
以降はオプションです。お時間に余裕がある方はお取り組みください。
TUNE DB2
D B 2 B L U Acceleration Hands-On @ C l o u d
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の推奨
パッケージキャッシュ
統計情報の推奨
※2
Explain表
カラム型の推奨
イベントモニター
Query Workload Tuner
....
88
....
※1....Query Workload Tuner...前のバージョンではOptim Query Tunerという名前でした。
※2....パッケージキャッシュなど、実際に実行した結果を入力にすることもできます。この場合、
ワークロード特性や実行回数なども加味して推奨が出るので、より正確な結果になります。
※3....無償版のIBM Data Studio 4.1でも単一SQLのチューニングは可能です。 V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
Query Workload Tunerの実行の準備
 QWTはEclipseベースのツールです。無償のIBM DataStudioへのアドオンとして提供されています。
 皆様のお手間を省くために、すでにOptim Workload Quuery Tuner（以下QWT)は
Windows上に導入済みです。( RHEL上ではありませんのでお間違えなきよう！）
 以下の手順でQWTを起動します。
►
デスクトップ上の「DataStudio 4.1.0.0
Client」をダブルクリック
►
ワークスペースは下記を指定
● C:\temp\workspace1
– 今回はイチから使うので、上記は実はどこでもいいのです
が、まあ一応上記に決めます。
89
►
「OK」ボタン
►
しばらくお待ち下さい。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 QWTが起動しました。
 ではツールからRHEL上のDB2サーバーに
接続します。
►
90
左上の「管理エクスプローラー」で左から
2番目の「データベースへの新規接続」
をクリック
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 左側のペインで以下を選択
►
「DB2 for Linux, UnixおよびWindows」
 表示されるパネルで以下を入力
►
データベース:
BLUDB (固定)
►
ホスト:
RHELサーバーのIPアドレス
►
ポート番号:
50000 (デフォルト)
►
ユーザー名:
db2inst1
►
パスワード:
Passw0rd
►
「パスワードの保存」にチェック
 「接続のテスト」ボタン
►
「接続が成功しました」のパネルが表示されたら
「OK」ボタンで戻る
 「終了」ボタン
91
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 左記のようにBLUDBへの接続ができました。
 EclipseのパースペクティブをQWTのものに
変更します。
92
►
右上の「パースペクティブ」ボタン
►
「IBM Query Tuning」を選択
►
「OK」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 チューニングを開始する前に、まずチューニング機能
を有効化して環境を整えます。
 パースペクティブが切り替わったら以下を選択
►
左下の「データ・ソース・エクスプローラー」
►
BLUDBの名前の接続をクリックして展開
►
以下の青いディスクの絵の「BLUDB」を右クリッ
ク
● BLUDBの表記が2つあるのでお間違えなきよう。
展開した方のBLUDBです。
►
「分析とチューニング」－「チューニング・フィー
チャーのフルセットのアクティブ化」を選択
 ライセンスの確認のパネルで、「はい」ボタン。
93
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 これでQWTの機能がアクティブになりました。
►
「OK」ボタン
 次にBLUDB上にチューニングのためのEXPLAIN表やストアド・プロシージャを定義します
►
先ほどと同じく「BLUDB」－「分析とチューニング」－「チューニング用に構成」－「ガイド付き構成」
 BLUDB上に定義出来ました。
►
94
「OK」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
従来型(行型) テーブルをチューニングしましょう
 以上で環境面の準備は完了です。早速チューニングを行なってみましょう。
 タスク・ランチャーより
►
「チューニング」タブ
►
「チューニングの開始」をクリック
 ウイザードが起動します。
►
95
「次へ」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 「BLUDB」を選択して「終了」ボタン
 左のように画面が切り替わります。
96
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
ご参考) QWTへの入力となるselect文の与え方
①
 ①は外部のファイルなどからSELECT文を与える場合のメニューです。
今回のハンズオンではこちらの方法を使います。
②
 ②は実際のDB2システムから実行済のSELECT文や性能情報を抜き出し
て分析する場合のメニューです。
 当然ながら、②のほうが実行回数やトランザクション・ミックス/重み付けを加
味した実態に近いワークロードを入力に利用できますので、より効果的な推
奨結果が得られるものと思われます。
 ただし、①②いずれでも推奨を計算する場合には実際のDB2システムに接
続して統計情報やEXPLAIN結果を利用しますのでご安心ください。（逆に
申しますと、個人PCでの開発DB2環境など、あまりに本番とかけ離れた小
規模なDB2に接続して実行した場合、効果的な結果が得られない可能性
があるかと存じます。）
97
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 まずは従来型（行型）テーブルに対する照
会をチューニングします。
►
「2.キャプチャー」のタブ
►
「ファイル」-「ファイル・パス」
►
「参照」ボタン
►
デスクトップ上の以下のファイルを選択し
て「開く」ボタン
● 99_all_query.sql
● 上記は先程JMETERで実行したSELECT文をそ
のまま20個書いてある普通のテキスト・ファイルです。
 「キャプチャー」ボタン
98
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 キャプチャーされたステートメントに
SELECT文が表示されたら、一旦
保管しましょう。
►
「すべてをワークロードへ保存」
►
「OK」ボタン
 タブが「管理」に切り替わったら
「アドバイザーの起動」ボタン。
99
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 以下を選択します
►
「ワークフロー・アドバイザーの実行」
►
「実行する項目の選択」ボタン
►
「すべてを選択」-「OK」ボタン
● メニューをよく見ると「表編成」というメニューが
あって、グレイアウトされていますね。これは「カ
ラム型テーブルに変更したらどうなる?」という
場合に指定するもので、あとで試みます。索
引やマテリアライズド照会表はカラム型テーブ
ルでは利用できない（というか不要)です。要
は今回推奨を要求しているオブジェクトはカラ
ム型テーブルではありえないので、グレイアウト
されているわけです。
 次のパネルで
►
100
「EXPLAINの開始」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 QWTがパフォーマンスを最適化すべく、色々
と考えております。気長にお待ちください。
(4-5分くらいです）
 もし左記のメッセージが出たら「はい」ボタン
 しばらくお待ち下さい
 アドバイザーが終わると左記のようなレポート
が生成/表示されます。
早速、中身を見てみましょう。
101
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 アドバイザーの推奨内容をさらっと見てみ
てください。例として、当方の環境では左
記の内容が推奨されていました。
►
102
要は統計を4つ、統計ビューを3つ、索引を33個( ! )
MQTを5つ追加して、MDCへの変換を1つ行ったら、
パフォーマンスがかなりよくなるのでは？と言ってます。
(「えー！そんなにやるのか！」と思わないでください。
あくまでアドバイスであって全部の実装が必須、という
わけではありません。後で見ていきますが、アドバイス
は個別に効果を評価して、個別に適用できますの
で。。。）
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 QWTは推奨された内容から実行ステートメントを生成して、そのまま実行することもできます。
 とはいえ、今日はお時間がないので実行ステートメントを生成して、見るだけにします。
(QWTの推奨を全部実行すると30分以上かかります。その間何もせず待っているのは申し訳なく..)
 左のペインで以下をクリック
►
ワークロード推奨情報を開く
 まずは統計情報です
103
►
「統計」タブをクリック
►
「RUNSTATSの表示」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 推奨されたRUNSTATS文が表示されて
いますね。
 ここまま「次へ」で進めば実行できますが、
今日は「キャンセル」で戻ります。
104
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 x
 次は索引です。
►
「索引」タブをクリック
►
下の段にQWTが推奨した33個の
索引がリストされていますね。
►
下の段の左から５つめのアイコン
「候補索引のテスト」をクリック
 「呼び出し」タブに画面が変わります
105
►
「候補索引のワークロードテストの
実行」をクリック
►
「索引候補のテスト」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 今回はオプションは設定しません。
 そのまま「OK」 ボタン
 しばらくお待ち下さい。
106
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 新しく「索引候補のテスト」タブが表示さ
れましたので、クリック。
 「パフォーマンスにおける変化の見積もり」
では推奨された索引を付与すれば全体
で47.89%の改善が見込める、と言ってい
ます。
107
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 では、これらの個々の索引の効果はどの
程度でしょうか？
 スライダー・バーを右にずらすと、①パ
フォーマンス向上の見積もり ②ディス
ク・スペースの見積もりのカラムがあり、索
引別に期待できる効果と必要なディス
ク・リソースが参照できます。
 更に、個々のSELECT文の性能がどの
程度改善されそうか、も新旧比較で知
ることができます。
►
108
左から6つめの「アクセスプランの比
較」ボタンをクリック。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 しばらくお待ち下さい
 比較対象はこのままで「OK」ボタン。
 「OK」ボタン
109
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 完了するとタブのパネルが切り替わります。
►
「比較履歴」をクリック
►
「結果を検討」ボタン
 下記のように個々のSELECT文でどの
程度の効果が見込めるか、がExplainの
結果としての実行コストをベースに表示さ
れます。90%以上性能改善するものもあ
る、と言っていますね。
110
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 他にもMQT/MDC/統計ビューなどの推奨が出ていますが、ハンズオンはこのへんにしておきます。
 ご参考までに、以下は筆者が皆様と同じ環境で推奨を実際に適用した時の再測定結果です。
(正確には、MQT2つとMDCは所要リソースの関係で適用しておりません。統計情報と索引はすべて作成しました)
 見ると、平均時間は3.4秒です。カラム型は何もしなくても平均1.7秒でした。とはいえ一部の
selectは数十msと劇的に早くなっていますので、「手間をかけてチューニングすれば、改善は見込
める」のは確かです。要は「従来型でも、今までのように手間をかけてコツコツとチューニングすれば(当
然) 性能は上がるが、カラム型では何もしなくても、平均して結構良い性能を得られる」ということが
見て取れるかと思います。
111
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
チューニング前
 x
 従来型テーブルの性能測定
結果をチューニング前後でグ
ラフで比べてみました。
 全般的には確かに改善して
チューニング後
いますが、チューニング後もバ
ラツキがあることが見て取れま
す。要はチューニング策が照
会の条件にフィットすればそこ
は効果が得られるが、フィット
しなかったり自由検索など条
件が変わる場合は、なかなか
改善が見込めない、というあ
る意味アタリマエの結果が見
て取れます。
►
112
一部、却って悪化しているものもあ
りますが、この原因は未調査です。
すいません。。。
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
従来型(行型) テーブルからカラム型への変換のアドバイス
 先程は従来型(行型)テーブルの範疇でのチューニングと効果の見極めをご経験いただきました。
 QWTは「このテーブルはカラム型に変換したらいいのではないですか？」というオススメもしてくれます。
それをやってみましょう。ワークロード(select文)は先程保存したものを使います。
 アドバイザーを起動します。
113
►
左の「管理」タブ
►
「ワークロード・リスト」
►
「アドバイザーの起動」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 x
 パネルが「呼び出し」タブに変わります。
►
「ワークロード・アドバイザーの実行」
►
「実行する項目の選択」ボタン
 カラム型の推奨を指定します。
114
►
「すべてクリア」ボタン
►
「表編成」のみにチェック
►
「OK」ボタン
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 「続行」ボタン
 しばらくお待ち下さい
(2-3分)
 「表編成」のタブが表示されたらクリック。
115
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 本日は前の操作と同様に「仮想テス
ト」に止め、実際の変換は行いませ
ん。
►
「候補表編成のテスト」ボタン
 「呼び出し」タブにパネルが切り替わり
ます
►
「候補表編成のワークロードテスト
の実行」をダブルクリック
►
「候補表編成のテスト」ボタン
● 上記ボタンは始めはグレイアウトされていま
すが、 「候補表編成のワークロードテスト
の実行」をダブルクリックすると選択できるよ
うになります。
116
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 しばらくお待ち下さい。
 「表候補編成」のタブが表示されたらクリック。
117
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
 以下のようにカラム型に変更したらよいと思われる表、その場合のselect文の性能改善の期待値が
表示されます。(一つ、-62.14%と「却って悪化するかも。。」と言っているのがありますね。)
 従来型の時と同様に、QWTから変換を行うこともできますが、実際に実行すると待ち時間が長いの
で、本日のハンズオンはここまでとさせていただきます。
118
V1.1 as of 2013/07/27
D B 2 B L U Acceleration Hands-On @ C l o u d
お疲れ様でした！
 以上でハンズオンは終わりです。最後までお付き合い頂き、ありがとうございました。
 DB2 BLUは「LOAD & GO !」が合言葉で何ら難しい設定や準備が不要なので、
もしかしたら「ハンズオンのやりがいが無いなあ」と拍子抜けした方もおられるかもしれ
ませんね。
でも、それでいいのです。それくらい簡単に、高性能を実現できるのだ、とご実感い
ただけたのであれば、ハンズオンの目的は達成したことになると思っております。
 ハンズオンで利用した環境はそのままで結構です。(当方で遮断します)
Windowsのリモートデスクトップの接続を切って、終了してください。
 最後に、別途メールでご案内したアンケートにご回答頂けると大変有難く存じます。
 当ハンズオンへのご参加ありがとうございました！
119
V1.1 as of 2013/07/27
MISSION :COMPLETE