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サポート
DB2 UDB(LUW)との関係性
– RDBとしての機能は同じだが実装が異なる – 管理方法も異なる – ユーティリティー、ツールも個別のものが多い – DB2ファミリー間で共通の機能を実装していく方向性 Power Systems 参考 主な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年IBM DB2ファミリー
DB2には大きく３つの製品ラインがあります。
DB2 for z/OS DB2 for i
(DB2/400)
DB2 for LUW
L – Linux U – UNIX W - Windows
z/OS 用 DB2 IBM i 用 DB2 Linux, UNIX, Windows用 DB2 ・過去の開発経緯から細 かい機能レベルでは差異 が存在。 ・現在は各製品ラインの 機能を整理・統合しすべ てのDB2製品で同じ機能 が使用可能となるよう開 発を進めています。 ・例えばXMLデータベー ス対応、RCRA等はDB2 LUWが最も早く対応し ましたがDB2 for i でも 順次実装、機能拡張され ています。 ・カラムレベルセキュリ ティの実装はDB2 for i が最初、次いで他のDB2 製品でした。 アプリケーションからはDB2ファミリーに対し基本的に同様な操作が可能
DB2 for IBM i の特徴
DB2 for i はOSより下位のマイクロコード層で実装されています。
・DB2 for i 以外のデータベースは基本的に はすべてOS上のアプリケーションとして稼 動します。 OS上のアプリケーションとして稼働するDB S/Wはさまざまなデメリットを享受できま す。 - 表領域などDBがM/W層実装による複雑 な管理を排除 - OS層での単一なパフォーマンス監視 - バックアップ・回復設計を簡素化（バッ クアップが復元できない等の障害は皆無） - OS/DB一体の堅牢なセキュリティ実装 上記のほかにもDB2 for i はアプリケーショ ン層に対する互換性を最大限維持する設計 思想で開発されている、1OS上で4,000ス キーマ以上をサポートする拡張性などの特 徴があります。 IBM i (OS/400) 運用管理機能 DB2 for IBM i DBMS データ実体 アプリケーション ハードウェア Linux, UNIX, WindowsなどのOSDBミドルウェア
Oracle, SQL Server, DB2 LUW他
DBMS データ実体 運用管理機能 アプリケーション
SQL、一般DB用語 OS/400用語 補足 スキーマ （コレクション） ライブラリー ライブラリーは IFSでは /QSYS.LIB ディレクトリー の下に作成されるディレクトリーとして識別される テーブル 物理ファイル データが入っているファイル 行 レコード 一連のフィールドを含む表の水平部分 列 フィールド 同じデータ属性を持った表の垂直部分 ビュー 論理ファイル １つまたは複数の物理ファイルのフィールドまたはレ コードのサブセット（データ自体は内部に持たない） インデックス 論理ファイル キー付けされた論理ファイル パッケージ SQLパッケージ SQLステートメントの制御構造が入っているオブジェ クト カタログ なし テーブル、パッケージ、ビュー、インデックス、制約 の情報を含むテーブルとビュー
データベース用語の対比
DB2 for i の操作環境
5250、System i ナビゲーター、IBM Navigator for iの3種類のインターフェースを提供しています。 – 5250インターフェースで対話式にSQL文を入力する際には、有償ライセンス 57xx-ST1(*)が必要
(*) 57xx-ST1： IBM DB2 Query Manager and SQL Development Kit for i 5250
System i ナビゲーター
IBM Navigator for i PCOMM、IBM i
Access for Windows等エミュ
レーターから実行
IBM i Access for Windowsで提供されるコ ンポーネントをWindows PCにインストール IBM i で HTTPサーバー （ADMINサーバー）を開 始し、ブラウザーで2001 ポートにアクセス
一般的なオープン系データベースとの比較
オープン系データベース
UNIT3 データファイル USERDATA1.dbf データファイル USERDATA2.dbf 表領域1 データファイル USERDATA3.dbf データファイル USERDATA4.dbf UNIT1 UNIT2 データファイル USERDATA5.dbf 表領域2 オープン系データベースでは ・物理ディスク,LUNを考慮した管理 ・表領域をまたぐ移動はオブジェク トの再作成 ・テーブル毎にエクステントなどの アロケーション管理が必要 ・表領域毎に使用率の管理が必要 UNIT1 UNIT2 UNIT3 DB2 for i では ・仮想化されたSLSのため物 理ディスク,LUNは意識しな い ・表領域、テーブルエクステ ントの概念は不要 ・テーブル等のアロケーショ ンはOSが全ディスクの使用 率を見て均等に自動割当&拡 張DB2 for i
テーブル EMPLOYEE テーブル EMPLOYEE テーブル EMPLOYEE テーブル EMPLOYEE テーブル EMPLOYEE EMPLOYEE テーブル CUSTOMER テーブル CUSTOMER テーブル CUSTOMER テーブル CUSTOMER テーブル CUSTOMER テーブル CUSTOMER テーブル CUSTOMERIBM iにおけるストレージ管理
WRKSYSSTS
コマンド
通常のストレージ管理は
この画面だけ
*必要に応じて WRKDSKSTSコマンド 収集サービスデータ取得 等を行います。 *外部ストレージを利用している場合 は外部ストレージ側でも管理が必 要です。 CPU使用率(%) DB機能% トータルCPU使用率と, DB機能だけのCPU使用 率%を表示 画面中央(プール) プールとはメインメモリのこ と。メモリの使用状況を表示。 この値を調べることでシステ ム全体としてのメモリの過不 足を測定可能 システムASP システムASP使用率(%) このシステムに接続されたトータ ルディスク容量と使用率% IBM i でのディスク容量管理とは この値の監視だけデータベース・オブジェクトの作成方法
２種類のインターフェースで作成可能です。
DDSインターフェース
SQLインターフェース
CRTLIB
CRTPF
CRTLF
CREATE SCHEMA
または
CREATE COLLECTION
CREATE TABLE
CREATE INDEX
CREATE VIEW
ライブラリー スキーマ（コレクション） 生成するオブジェクト 上段（AS/400用語） 下段（SQL用語） 物理ファイル テーブル 論理ファイル インデックス、ビューDDSインターフェース、SQLインターフェースの比較
（IBM i 7.2の例）
DDSインターフェース
SQLインターフェース
CRTLIB
CRTPF
CREATE SCHEMA
CREATE TABLE
PF(テーブル）だけが作成される。 PFにジャーナルは自動開始されない。 テーブル（PF）以外にジャーナル関連やSQL 関連のシステムテーブルが作成される。 テーブル（PF）に対しジャーナル取得が自動 設定SQL利用を前提に最適化されている事が わかります補足事項
DB2 for i ではテーブル（PF）に対するジャーナル取得は必須ではありません。このため
特にSQLを使用しないシステムではジャーナルを取得していないシステムが大多数でし
た。
昨今ではSQLの普及に伴ってジャーナルを取得しているシステムが大半になっています
。
かつては追加のジャーナル取得による負荷増によりパフォーマンス劣化、必要ディスク
領域増が課題となりましたが、昨今のH/Wは高性能化されているためシステム導入時に
適切なアセスが完了していれば、ほとんどのケースで大きな問題は発生しません。
ジャーナル取得によりパフォーマンス面で懸念がある場合はOSオプション42 ジャーナ
ル・キャッシングの適用をご検討ください。
– 注意：ジャーナル・キャッシングは、システムが大きなグループでジャーナル項目をメモリーに 書き込みできるようにする、別途有料のフィーチャーです。メモリー内にいくつかのジャーナル 項目がある場合は、システムはジャーナル項目をメモリーからディスクに書き込みます。アプリ ケーションが数多くの変更を実行する場合は、この書き込みにより、同期ディスク書き込みの回 数が減り、パフォーマンスが向上する可能性があります。ただし、ジャーナル・キャッシングを 使用する場合、ジャーナル処理されたオブジェクトに対する最新の更新の一部が異常 IPL または 独立 ASP のオンへの変更によって失われることがあります。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オブジェクトを作成する方が パフォーマンス上有利な場合があります。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を事前コンパイル化し、実行時負荷・処 理を短縮する）作成されたインデックスがSQL実行時に使用されているか？の確認
方法1. System i ナビゲーターから確認する
– SQLパフォーマンス・モニターで該当のテーブル(物理ファイル）をモニター対象とする。SQLを実行後 にiSeriesナビゲーターから調べたい索引を右クリックし、ステートメントを表示 を選択しSQL文が表示 されていればその索引は使用されています。方法2. DB2 for i のカタログ表をSQLで参照してインデックスの使用状況を確認する
– インデックスの使用状況が格納されているシステム・ビュー（システム作成のLF）は – オブジェクト名 ： QSYS2/SYSIXSTAT – SQLでのビュー名 ： SYSINDEXSTAT – 上記の表をSQL, QUERY等でアクセスして以下のカラム(フィールド）の値等を参照する – LAST_QUERY_USE, → このインデックスをデータアクセス用に使用した最終日付 – LAST_STATISTICS_USE, → このインデックスを統計情報として利用した最終日付カタログ表から索引（インデックス）が使用されているか？の確認例
< インデックス最終使用日付を取得する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’ ; →ライブラリー名
この索引が使用された最新の日時
上記いずれかの日付が有意に新しければこのインデックス は使用されている（必要）と考えることができます。 どちらの日付も古い場合、このインデックスは使用されて
