IBM Presentations: Blue Pearl Deluxe template

DB2 for i 概説
参考
 1988年OS/400 V1R2発表時からの一機能
– オープン系のDB2より先に発表されたRDBMS
– S/38 内臓RDB(1979年8月出荷開始)からの上位互換性
– SLSアーキテクチャー中に実装（ミドルウェアではなくH/W、
マイクロコード層に実装）
 SQL対応
– 当初からSQL対応
– V5R2で新しいSQL実行エンジン：SQE を初実装。以降SQE
に対してSQL機能を拡張
– V5R4以降で大きく機能拡張され、以降PTF, OS Ver.upに
よって機能拡張を継続
– V5R4で業界標準SQL2003 コア機能 100%対応
– ODBC、JDBC、.NETサポート
主なDBの出荷開始時期
S/38 RDB
1979年
IBM SQL/DS
1981年
DB2（メインフレーム用） 1983年
DB2 for AIX
1993年
DB2 for Windows
1995年
Oracle V2
1979年
MS SQL Server
1989年
Postgres
1989年
MySQL
1995年
 DB2 UDB(LUW)との関係性
–
–
–
–
1
RDBとしての機能は同じだが実装が異なる
管理方法も異なる
ユーティリティー、ツールも個別のものが多い
DB2ファミリー間で共通の機能を実装していく方向性
Power Systems
© 2015 IBM Corporation
IBM DB2ファミリー
 DB2には大きく３つの製品ラインがあります。
・過去の開発経緯から細
かい機能レベルでは差異
が存在。
アプリケーションからはDB2ファミリーに対し基本的に同様な操作が可能
・現在は各製品ラインの
機能を整理・統合しすべ
てのDB2製品で同じ機能
が使用可能となるよう開
発を進めています。
・例えばXMLデータベー
ス対応、RCRA等はDB2
LUWが最も早く対応し
ましたがDB2 for i でも
順次実装、機能拡張され
ています。
・カラムレベルセキュリ
ティの実装はDB2 for i
が最初、次いで他のDB2
製品でした。
2
DB2 for LUW
DB2 for z/OS
DB2 for i
L – Linux
(DB2/400)
U – UNIX
W - Windows
z/OS 用 DB2
IBM i 用 DB2
Linux, UNIX,
Windows用 DB2
© 2015 IBM Corporation
DB2 for IBM i の特徴
 DB2 for i はOSより下位のマイクロコード層で実装されています。
・DB2 for i 以外のデータベースは基本的に
はすべてOS上のアプリケーションとして稼
動します。
アプリケーション
DBミドルウェア
OS上のアプリケーションとして稼働するDB Oracle, SQL Server, DB2 LUW他
S/Wはさまざまなデメリットを享受できま
DBMS
す。
データ実体
- 表領域などDBがM/W層実装による複雑
運用管理機能
な管理を排除
- OS層での単一なパフォーマンス監視
IBM i (OS/400)
- バックアップ・回復設計を簡素化（バッ
クアップが復元できない等の障害は皆無）
運用管理機能
- OS/DB一体の堅牢なセキュリティ実装
上記のほかにもDB2 for i はアプリケーショ
ン層に対する互換性を最大限維持する設計
思想で開発されている、1OS上で4,000ス
キーマ以上をサポートする拡張性などの特
徴があります。
3
アプリケーション
Linux, UNIX, WindowsなどのOS
ハードウェア
DB2 for IBM i
DBMS
データ実体
ハードウェア
© 2015 IBM Corporation
データベース用語の対比
SQL、一般DB用語
OS/400用語
スキーマ
ライブラリー
ライブラリーは IFSでは /QSYS.LIB ディレクトリー
の下に作成されるディレクトリーとして識別される
テーブル
物理ファイル
データが入っているファイル
行
レコード
一連のフィールドを含む表の水平部分
列
フィールド
同じデータ属性を持った表の垂直部分
ビュー
論理ファイル
１つまたは複数の物理ファイルのフィールドまたはレ
コードのサブセット（データ自体は内部に持たない）
インデックス
論理ファイル
キー付けされた論理ファイル
パッケージ
SQLパッケージ
SQLステートメントの制御構造が入っているオブジェ
クト
カタログ
なし
テーブル、パッケージ、ビュー、インデックス、制約
の情報を含むテーブルとビュー
（コレクション）
4
補足
© 2015 IBM Corporation
DB2 for i の操作環境
 5250、System i ナビゲーター、IBM Navigator for iの3種類のインターフェースを提供しています。
–
5250インターフェースで対話式にSQL文を入力する際には、有償ライセンス 57xx-ST1(*)が必要
5250
PCOMM、IBM i
Access for
Windows等エミュ
レーターから実行
System i ナビゲーター
IBM i Access for
Windowsで提供されるコ
ンポーネントをWindows
PCにインストール
IBM Navigator for i
(*) 57xx-ST1： IBM DB2 Query Manager and SQL Development Kit for i
5
IBM i で HTTPサーバー
（ADMINサーバー）を開
始し、ブラウザーで2001
ポートにアクセス
© 2015 IBM Corporation
一般的なオープン系データベースとの比較
オープン系データベース
UNIT1
DB2 for i
UNIT2
データファイル
データファイル
USERDATA1.dbf
USERDATA2.dbf
テーブル EMPLOYEE
テーブル CUSTOMER
データファイル
データファイル
USERDATA4.dbf
UNIT1
表領域1
テーブル EMPLOYEE
テーブル CUSTOMER
UNIT2
テーブル EMPLOYEE
テーブル CUSTOMER
USERDATA3.dbf
表領域2
UNIT3
テーブル EMPLOYEE
EMPLOYEE
テーブル CUSTOMER
テーブル CUSTOMER
テーブル CUSTOMER
データファイル
USERDATA5.dbf
6
オープン系データベースでは
UNIT3
・物理ディスク,LUNを考慮した管理
・表領域をまたぐ移動はオブジェク
トの再作成
・テーブル毎にエクステントなどの
アロケーション管理が必要
・表領域毎に使用率の管理が必要
テーブル EMPLOYEE
テーブル CUSTOMER
DB2 for i では
・仮想化されたSLSのため物
理ディスク,LUNは意識しな
い
・表領域、テーブルエクステ
ントの概念は不要
・テーブル等のアロケーショ
ンはOSが全ディスクの使用
率を見て均等に自動割当&拡
張
© 2015 IBM Corporation
IBM iにおけるストレージ管理
WRKSYSSTS コマンド
通常のストレージ管理は
この画面だけ
*必要に応じて
WRKDSKSTSコマンド
収集サービスデータ取得
等を行います。
*外部ストレージを利用している場合
は外部ストレージ側でも管理が必
要です。
システムASP
CPU使用率(%)
画面中央(プール)
DB機能%
プールとはメインメモリのこ
と。メモリの使用状況を表示。
この値を調べることでシステ
ム全体としてのメモリの過不
足を測定可能
トータルCPU使用率と,
DB機能だけのCPU使用
率%を表示
7
システムASP使用率(%)
このシステムに接続されたトータ
ルディスク容量と使用率%
IBM i でのディスク容量管理とは
この値の監視だけ
© 2015 IBM Corporation
データベース・オブジェクトの作成方法
 ２種類のインターフェースで作成可能です。
生成するオブジェクト
上段（AS/400用語）
下段（SQL用語）
DDSインターフェース
SQLインターフェース
ライブラリー
スキーマ（コレクション）
CRTLIB
CREATE SCHEMA
または
CREATE COLLECTION
物理ファイル
テーブル
CRTPF
CREATE TABLE
論理ファイル
インデックス、ビュー
CRTLF
CREATE INDEX
CREATE VIEW
8
© 2015 IBM Corporation
DDSインターフェース、SQLインターフェースの比較
（IBM i 7.2の例）
DDSインターフェース
CRTLIB
CREATE SCHEMA
CRTPF
CREATE TABLE
PF(テーブル）だけが作成される。
PFにジャーナルは自動開始されない。
9
SQLインターフェース
テーブル（PF）以外にジャーナル関連やSQL
関連のシステムテーブルが作成される。
テーブル（PF）に対しジャーナル取得が自動
設定SQL利用を前提に最適化されている事が
わかります
© 2015 IBM Corporation
補足事項
 DB2 for i ではテーブル（PF）に対するジャーナル取得は必須ではありません。このため
特にSQLを使用しないシステムではジャーナルを取得していないシステムが大多数でし
た。
 昨今ではSQLの普及に伴ってジャーナルを取得しているシステムが大半になっています
。
 かつては追加のジャーナル取得による負荷増によりパフォーマンス劣化、必要ディスク
領域増が課題となりましたが、昨今のH/Wは高性能化されているためシステム導入時に
適切なアセスが完了していれば、ほとんどのケースで大きな問題は発生しません。
 ジャーナル取得によりパフォーマンス面で懸念がある場合はOSオプション42 ジャーナ
ル・キャッシングの適用をご検討ください。
– 注意：ジャーナル・キャッシングは、システムが大きなグループでジャーナル項目をメモリーに
書き込みできるようにする、別途有料のフィーチャーです。メモリー内にいくつかのジャーナル
項目がある場合は、システムはジャーナル項目をメモリーからディスクに書き込みます。アプリ
ケーションが数多くの変更を実行する場合は、この書き込みにより、同期ディスク書き込みの回
数が減り、パフォーマンスが向上する可能性があります。ただし、ジャーナル・キャッシングを
使用する場合、ジャーナル処理されたオブジェクトに対する最新の更新の一部が異常 IPL または
独立 ASP のオンへの変更によって失われることがあります。
10
© 2015 IBM Corporation
SQL実行エンジン
CQE と SQE
 DB2/400 V5R2以降ではSQLを解釈し実行する
SQLエンジンは２種類搭載している
 CQE – V5R1以前から存在した古いSQL最適化プ
ログラム
 SQE – V5R2で新しく実装されたSQL最適化プロ
グラム
– 実行されるSQL文に応じて（たとえば副照会で
特定の構文を使用している場合はCQEで実行さ
れる、等）SQEとCQEどちらでSQLが実行され
るかがシステム的に一意に決まります。
 OSのバージョンが新しい程（同一バージョンでも
PTFレベルが新しい程）SQEで実行されるSQL文が
多くなります。
 基本的にはCQEよりSQEの方がSQLの処理速度が
速くなります。
– ただし、特定条件下では例外的にCQEの方が速
いという現象が発生しえます。
 SQLインターフェースから作成したデータベース
オブジェクトはDDSインターフェースで作成した
オブジェクトに比較してSQEが利用可能なDB統計
情報を多く提供可能になるメリットがあります
（厳密にはOSバージョン等で差異があります）。
 結果、SQEがSQL文実行時に行うアクセスプラン
の作成等をより正確に最適化できSQL処理のパ
フォーマンスが高速化する可能性が高くなります。
このため特にIBM i 7.1まではSQLインターフェー
スでテーブル等のDBオブジェクトを作成する方が
パフォーマンス上有利な場合があります。
11
© 2015 IBM Corporation
SQLパフォーマンスを向上させる基本的な考え方・アプ
ローチ
 基本的にSQEで処理させる方がパフォーマンスはよい
 SQEが必要とする統計情報を出来る限り、システムに提供する事が望ましい
– この観点ではインデックスは多い方がいい ⇔ インデックス更新時の負荷増とのトレードオフを考慮
1. より新しいOSバージョンを使用する
2. より新しいPTF（累積PTFパッケージ、DBグループPTF）を適用する
3. SQLパフォーマンスが遅い場合は、SQLパフォーマンスモニター（DBモニター）を取得してビジュアル･
エクスプレイン(Visual Explain）で分析し、対応策を施す
（ビジュアルエクスプレインでの対応策やチェックポイントの例）
 CQEが使われていないか、を確認する。
 テーブルスキャンなど処理負時間の長い処理がないかを確認し、可能ならインデックスを作成し長い処
理を回避する
 索引アドバイザーでシステムが提示する推奨インデックスを作成する
 アプリケーションのSQL構文を見直し、SQEが使用されるようにする、インデックスが使用されるよう
にする、SQL構文そのものを見直す。
 SQL構文全体の見直し
 タイムスタンプ計算をSQLでなくJAVA等のPGMで行う
 PREPAREDステートメントを使用する(頻繁に実行されるSQLを事前コンパイル化し、実行時負荷・処
理を短縮する）
12
© 2015 IBM Corporation
作成されたインデックスがSQL実行時に使用されているか？の確認
DB2 for IBM iでインデックスがSQL実行時に使用されているか？
方法1. System i ナビゲーターから確認する
– SQLパフォーマンス・モニターで該当のテーブル(物理ファイル）をモニター対象とする。SQLを実行後
にiSeriesナビゲーターから調べたい索引を右クリックし、ステートメントを表示 を選択しSQL文が表示
されていればその索引は使用されています。
方法2. DB2 for i のカタログ表をSQLで参照してインデックスの使用状況を確認する
–
–
–
–
–
–
13
インデックスの使用状況が格納されているシステム・ビュー（システム作成のLF）は
オブジェクト名 ： QSYS2/SYSIXSTAT
SQLでのビュー名 ： SYSINDEXSTAT
上記の表をSQL, QUERY等でアクセスして以下のカラム(フィールド）の値等を参照する
LAST_QUERY_USE,
→ このインデックスをデータアクセス用に使用した最終日付
LAST_STATISTICS_USE, → このインデックスを統計情報として利用した最終日付
© 2015 IBM Corporation
カタログ表から索引（インデックス）が使用されているか？の確認例
< インデックス最終使用日付を取得するSQLサンプル >
SELECT INDEX_NAME,
SYSTEM_TABLE_SCHEMA,
SYSTEM_TABLE_NAME, LAST_QUERY_USE, LAST_STATISTICS_USE,
QUERY_USE_COUNT, QUERY_STATISTICS_COUNT, LAST_USED_TIMESTAMP,
DAYS_USED_COUNT, INDEX_SIZE
FROM QSYS2.SYSINDEXSTAT
WHERE
SYSTEM_TABLE_SCHEMA = ‘UTFTEST‘
→物理ファイル名
AND SYSTEM_TABLE_NAME = ‘TOKMASP’ ;
→ライブラリー名
この索引が使用された最新の日時
上記いずれかの日付が有意に新しければこのインデックス
は使用されている（必要）と考えることができます。
14
どちらの日付も古い場合、このインデックスは使用されて
おらず、削除する方がパフォーマンス上有利と考える事が
出来ます。
© 2015 IBM Corporation
（参考）System i ナビゲーターによるDB統計情報表示
V5R3～
 スキーマ（ライブラリー）毎にテー
ブル（物理ファイル)のレコード数
15
 スキーマ（ライブラリー）毎にテー
ブル（物理ファイル)のカラム数
（フィールド数)などの制限値
© 2015 IBM Corporation
（参考）System i ナビゲーター 統計情報の表示
V5R3～
 最適なSQLアクセスを実行するために必要なデー
タベースの統計情報をOSが自動で収集、更新
カラムの情報を表示
カラム毎の詳細情報を表示
図はカラム毎の値の分布を表示
16
© 2015 IBM Corporation
まとめ
 DB2 for i は、1988年OS/400 V1R2発表時からの一機能としてIBM i に組み込まれ
ています
– 当初からSQL対応し、ODBC、JDBC、.NETサポートのドライバーも用意されています
 一般的なオープン系データベースとの比較して、ストレージ管理等の運用が容易です
 DB2 for iでは2種類のインターフェース（DDSインターフェース、SQLインターフェ
ース）でデータベース・オブジェクトの作成が可能です
– SQLインターフェースで作成すると、ジャーナル取得が自動設定SQL利用を前提に最適化さ
れている事がわかります
– SQLパフォーマンスを向上させるため、インデックスの使用状況やDB統計情報を確認してみ
ましょう
DB2 for iはマイクロコード層で実装されているため、ストレージ管理やセキュリティ、
パフォーマンス等、運用面でのメリットがあります！
ただし、他データベースと同様にSQLを利用する場合には、
インデックスの使用等、SQLパフォーマンスを向上させるアプローチが必要です！
17
© 2015 IBM Corporation