Comments
Description
Transcript
クリーナー小さな価格を蒸します
目次 目次 はじめに xvii 献辞および謝辞 xxi 第 1 部 パッケージとライセンス 第1章 v 1 DB2 Universal Database および DB2 Connect の パッケージとライセンスの変更 3 DB2 Universal Database および DB2 Connect がサポートするオペレーティ ング・システム 4 DB2 Universal Database のライセンスとパッケージの変更 6 DB2 UDB Personal Edition 6 vi 目次 DB2 UDB Express 7 DB2 UDB Workgroup Server Edition と Workgroup Server Unlimited Edition 8 DB2 UDB Enterprise Server Edition とデータベース・パーティション・フィーチャー 9 DB2 UDB Data Warehouse Edition 9 DB2 Connect のライセンスとパッケージの変更 DB2 Connect Application Server Edition 14 14 DB2 Universal Database Enterprise Edition に組み込まれた DB2 Connect コンポーネント 15 その他の変更 16 DB2 Universal Database 関連製品の変更 16 第 2 部 パフォーマンス 21 第2章 23 多次元クラスタリング表 MDC 101: 従来の表と多次元クラスタリング表の単純な対比 25 MDC 表を理解するために必要な用語 29 MDC 表 29 次元 29 スライス 30 セル 31 ブロック 32 ブロック・サイズまたはブロック化因数 32 ブロック索引 33 ブロック ID 33 生成列 34 単調性 34 MDC 表の働き 34 MDC 表の作成 36 索引と MDC 表 38 MDC と照会の SELECT、INSERT、UPDATE、DELETE 操作 47 MDC 表の次元の選別 52 vii 目次 まとめ 第3章 54 宣言済みグローバル一時表 DGTT の索引サポート 57 58 DGTT の索引の制約事項 58 DGTT の索引の作成 59 DGTT に対するデータ変更のロールバックをサポートするための最小 UNDO ロギング 61 DGTT に関する統計のサポート 第4章 システム・デフォルト値と NULL の圧縮 DB2 UDB のデータ圧縮の方法 新規の行レコード・フォーマット 61 63 63 65 圧縮の例 67 圧縮がサポートされるデータ・タイプ 71 圧縮がオンかどうかを知る方法 72 圧縮による節約の見積もり 73 第5章 情報制約 75 情報制約が導入された理由 75 情報制約の使用 78 情報制約の例 79 使用上の考慮事項 82 第6章 コネクション・コンセントレーター 83 接続の管理の改善 83 コネクション・コンセントレーターの活動化 84 viii 目次 コネクション・コンセントレーターの操作 第7章 ユーザー保守のマテリアライズ照会表 84 87 制約事項 88 マテリアライズ照会表の作成 88 マテリアライズ照会表へのデータの追加 88 パフォーマンス向上のためのマテリアライズ照会表の活用 89 第8章 データベース・システム・モニターの機能強化 91 タイム・スタンプの収集の防止 91 デッドロック・モニターの拡張 92 イベント・モニター・データへの SQL アクセス 92 スナップショット・モニター・データへの SQL アクセス 94 SNAPSHOT_FILEW スナップショット要求タイプ 95 SNAPSHOT_FILEW の使用によるファイルへのスナップショットの取り込み 96 ファイルからのスナップショットの取り込み 96 DB2_SNAPSHOT_NOAUTH レジストリー変数 97 コントロール・センターのパフォーマンス・モニター・ツールは推奨されない 98 第9章 その他のパフォーマンスの機能強化 分散カタログ・キャッシュ 99 99 ブロック・ベースのバッファー・プールを使用したプリフェッチの機能強化 101 ページ・クリーナー I/O の改善 101 Java ベースのルーチンのマルチスレッド化 102 64 ビット・サポート 102 ix 目次 自動関係・関連管理（ARAM） 103 結合の新規バリエーション 103 ビット・フィルターの選択の機会の増加 104 第 3 部 管理の容易性 第 10 章 ロギング トランザクション・ロギングの改善 105 107 107 ログ・スペースの増加 107 無制限アクティブ・ログ・スペース 107 ログ・スペースの使用量の制御 108 トランザクション・ロギングのパフォーマンスの向上 109 ログのミラーリング 109 ログがフルのときのトランザクションのブロック 110 診断ロギングの改善 第 11 章 ロードの機能強化 110 113 オンライン・ロード 113 ロックの動作 115 新規の表状態 115 パーティション・データベースへのデータのロード 117 カーソルからのデータのロード 119 ロード・ウィザード 120 第 12 章 DB2 ツール 構成アシスタント 127 127 x 目次 ヘルス・センター 130 メモリー・ビジュアライザー 138 メモリー・トラッカー 140 ストレージ管理 「ストレージ管理」ビューの列 141 147 未確定トランザクション・マネージャー 150 障害モニター 152 第 13 章 コンテナーの操作 155 表スペース・マップ 155 DMS 表スペースからのコンテナーのドロップ 158 DMS 表スペース内のコンテナーのサイズの縮小 159 再平衡化を回避した DMS 表スペースへのコンテナーの追加 160 第 14 章 動的メモリー割り振りとオンライン再構成 163 第 15 章 オンライン・ユーティリティー 167 オンライン再編成 167 表の再編成 167 索引の再編成 169 オンラインのデータベース検査ツール 170 マテリアライズ照会表の増分保守 173 第 16 章 その他の管理の容易性の機能強化 177 スロットル・ユーティリティー 177 新規の管理通知ログ 179 xi 目次 表スペース変更履歴ファイル 181 QUIESCE コマンド 182 RUNSTATS コマンドの機能強化 184 現地時間でのポイント・イン・タイム・ロールフォワード・リカバリー 185 XBSA サポート 185 OEM のデータベースのデータ移動の機能強化 186 トレース機能の強化 186 UNIX 上の複数のサービス・レベルのインストール 187 新規の Tivoli 対応オプション 188 Linux 上の LDAP サポート 189 AIX5.2B の動的 LPAR サポート 190 動的システム・ドメイン・サポート 190 トランザクションのログ・スペースの使用 190 ALTER TABLE VARGRAPHIC 191 コマンド履歴サポートと CLP の双方向編集 191 第 4 部 開発 第 17 章 SQL の機能強化 193 195 UNION ALL を使用した SQL 挿入 195 UNION ALL を使用した表スペースの使用 198 INSTEAD OF トリガー 201 ORDER BY の機能強化 204 FETCH FIRST 文節 204 xii 目次 ORDER BY ORDER OF 205 FETCH FIRST 206 SQL 関数 207 VARCHAR_FORMAT と TIMESTAMP_FORMAT 207 XML パブリッシュ 208 スナップショット API 210 ヘルス・スナップショット 213 IDENTITY 列のサポート IDENTITY 列 215 215 シーケンス 217 IDENTITY 列に関するその他の考慮事項 219 CALL ステートメント 219 MERGE SQL 220 MERGE 構文 222 追加の WHEN MATCHED 論理 225 レコードの無視 226 エラー条件の通知 226 許可 228 SQL のサンプリング 229 BERNOULLI サンプリング 230 SYSTEM サンプリング 232 REPEATABLE サンプリング 234 その他の考慮事項 236 要約 236 第 18 章 アプリケーション開発の機能強化 デベロップメント・センター 239 239 デベロップメント・センターの開始 241 プロジェクト・ビュー 242 UDF の作成 248 ストアード・プロシージャーの作成 256 xiii 目次 デベロップメント・センター 259 デバッグとテスト 262 Java と SQL PL のデバッグ 265 SQL PL デバッガー 265 Java ストアード・プロシージャーのデバッグ 265 SQL アシスタント 266 SQL アシスタントの開始 267 SQL アシスタントの構造 268 一括表示ビュー 269 詳細ビュー 270 SQL コード 272 パネルのボタン 273 SQL アシスタント・セッションの例 274 要約 288 Java の機能拡張 288 タイプ 4 ドライバー・プラットフォームのサポート 289 タイプ 2 プラットフォームのサポート 289 追加機能 290 パッケージのバージョン ID 290 パッケージの概要 290 VERSION の例 291 パッケージの特権 292 パッケージ・キャッシュのフラッシュ 292 要約 293 第 19 章 Microsoft 環境の DB2 295 Windows 2003 サポート 296 DB2 Development Add-Ins for Visual Studio .NET 298 製品納期情報 298 Visual Studio .NET Add-In の登録 299 開発の概要 300 xiv 目次 ソリューションエクスプローラ 301 Server Explorer 303 SQL エディター 307 動的ヘルプ 308 出力ビュー 308 DB2 開発ツールのカスタマイズ 309 DB2 開発および管理ツールの立ち上げ 311 要約 313 ネイティブ管理.NET プロバイダー 313 DB2 管理プロバイダー ADO.NET オブジェクト 313 Visual Studio .NET Data ツールボックス内の DB2 オブジェクト 313 サンプル DB2 ADO.NET コード 314 管理プロバイダー・ツール 315 Visual Studio .NET の DB2 データベース・プロジェクト 318 DB2 データベース・プロジェクトの追加 318 プロジェクトの DB2 データベース参照の選択 319 DB2 プロジェクト・スクリプト 321 拡張スクリプト記述とスクリプト・オプション 327 拡張スクリプト・オプション 327 プロジェクトの構成とプロパティー 330 プロジェクトの依存関係とビルド順序 333 要約 334 疎結合トランザクションのサポート 335 Windows Management Instrumentation（WMI） 336 OLE DB プロバイダー 339 要約 機能強化 340 制約事項 340 341 xv 目次 第 5 部 情報の統合 第 20 章 フェデレーティッド・システム 343 345 DB2 Information Integrator 345 フェデレーティッド・システムの機能拡張 346 データ・ソース上のデータの操作 346 データ・ソース上の表の操作 346 データ・ソースの MQT 348 DB2 コントロール・センターでのフェデレーティッド・オブジェクトの管理 349 サポートされるフェデレーティッド・サーバー・プラットフォームの追加 350 DB2 Information Integrator で使用可能なデータ・ソース 350 WebSphere MQ 統合の機能強化 351 非同期 MQ リスナー 351 Websphere MQ メッセージ・キューのトランザクション・サポート 352 第 21 章 Web サービス Web サービス・コンシューマーとしての DB2 355 355 SOAP UDF のインストール 356 SOAP UDF のシグニチャー 356 SOAP UDF の使用 357 Web サービス・プロバイダーとしての DB2 359 DB2 Web サービスのアーキテクチャー 360 DADX ファイル 360 WORF のインストールと構成 362 DB2 Web Tools と Application Server for DB2 362 XML の機能強化 363 XML 使用可能データベースの v8 へのマイグレーション 363 スキーマに対する XML 文書の自動的な妥当性検査 363 XML 文書の手動による妥当性検査 364 xvi 目次 新規の XML UDF 364 タイム・スタンプとデータの正規化 365 パーティション・データベース環境の XML エクステンダー機能 366 新規の XML MQ UDF とストアード・プロシージャー 366 第 22 章 レプリケーションの機能強化 レプリケーション・センター レプリケーション・センターの開始 レプリケーション・センター・ランチパッド 369 369 370 370 「レプリケーションの定義」フォルダー 371 「操作」フォルダー 372 レプリケーションのモニター 372 レプリケーション・アラート・モニター 372 レプリケーション・プログラムの現在の状況のチェック 374 レプリケーション・プログラムの履歴データの分析 375 一般的な機能強化 376 レプリケーション・プログラムの Windows 処理モデル 376 レプリケーション・プログラムのパスワードの暗号化 377 Data Links 値の複製 377 長い表名と列名 377 マイグレーション・ユーティリティー 377 新規のトレース機能 377 レプリケーション・プログラムの 64 ビット・サポート 378 キャプチャーの機能強化 378 キャプチャー・プログラムの制御 378 キャプチャー・プログラムの稼働パラメーターの変更 378 キャプチャーの新しい開始モード 379 キャプチャーおよびアプライ・プログラムは任意の順序で開始できる 379 動的に更新可能なレプリケーション定義 380 レプリケーション・ソース表への列の動的な追加 380 個々のレプリケーション・ソースを対象にした行キャプチャーの使用可能化 380 レプリカからのデータの再キャプチャーに対する制御 381 xvii 目次 データのキャプチャーと整理を並行して実行 382 複数のキャプチャー・インスタンス 382 アプライの機能強化 トランザクションのコミット頻度 384 ターゲット・キー列に対する変更の複製 384 レプリケーションのパフォーマンス 索引 384 385 レプリケーション表間の結合の削減 385 ターゲット表の高速フル・リフレッシュ 385 ASNLOAD EXIT ルーチンの改良 385 1 つのサブスクリプション・セット用のアプライ・プログラムの最適化 386 複数のメンバーを持つサブスクリプション・セットの更新の削減 386 387 P A R T 1 パッケージと ライセンス DB2 Universal Database および DB2 Connect のパッケージと ライセンスの変更 ■ C H A P T E R 1 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 DB2 UDB v8.1（および v8.1.2 における拡張）for Linux, UNIX, and Windows（特に 指示がない限り、これを DB2 UDB v8.1 と呼びます）は、リレーショナル・データベー スを次なるステージに進める製品です。DB2 UDB v8 は、e- ビジネス、ビジネス・イン テリジェンス（BI）、コンテンツ・マネージメント、エンタープライズ・リソース・プ ランニング（ERP）、カスタマー・リレーションシップ・マネージメント（CRM）、プラ ンニング・ロジスティック・マネージメント（PLM）など、重要なソリューションの開 発と展開に最適なデータベースです。 DB2 UDB v8.1 および v8.1.2 リリースのハイライトは、新しい革新的な管理機能、従来 型、非従来型データ・タイプとストレージ・エンジン間の新たなレベルでの統合、パ フォーマンスと可用性の向上、オンライン管理機能、開発者の生産性の向上など、数 多くのものが挙げられます。この章では、特に指示がない限り、v8.1 についての説明 は v8.1.2 にも適用されます。 企業アプリケーションを配置する際に、価値を生むまでの時間（time to value）を短 縮できる新機能が豊富に導入され、それに伴い DB2 UDB（および、その関連製品）の パッケージ化とライセンス交付の条件が変更されて、お客様により大きな柔軟性と価 値を提供できるようになりました。この章では、バージョン 8.1 とバージョン 8.1.2 リ リースで DB2 UDB 製品ポートフォリオに対して実施された、パッケージとライセンスの 変更について詳しく説明します。詳細な内容は、www.ibm.com/software/data/db2/ に掲載 されています。 4 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 DB2 UNIVERSAL DATABASE およびDB2 CONNECT がサポートするオペレーティン グ・システム DB2 UDB v8.1 は、2002 年末に一般出荷可能となり、Linux（z/OS および Intel/AMD ベー ス・システム）、Windows®、および UNIX® ベース（AIX®、Solaris®、および HP-UX®）の システム向けに提供されています。DB2 UDB v8.1.2 は、2003 年中頃に一般出荷可能に なりました。 DB2 UDB v8.1 では、OS/2® と NUMA-Q/PTX® に対するサポートは、DB2 UDB v7.2 のレベル に保たれています。Microsoft のデスクトップ用オペレーティング・システムのパーソ ナル・バージョンに対するサポート・スケジュールに合わせる方向で、Windows 95 と Windows 98（DB2 Personal Edition の場合）に対するサポートは終了しました（ただ し、DB2 クライアントは、Windows 98 でまだ使用可能です）。 DB2 UDBの全リリースとサポートされるオペレーティング・システムのサービス終了日 についての詳しい情報は、www.ibm.com/software/data/support から入手できます。この Web サイトには、リリースに固有の製品資料、保守用の FixPak、保守用の更新、テクニ カル・ヒントなども掲載されています。 DB2 UDB v8.1 では、AIX、Solaris、および HP-UX 上で実行される 64 ビット・オペレー ティング・システムに対する全機能サポートも提供されます。DB2 UDB v8.1.2は、v8.1.2 アップデート（以前に Fix Pack 2 と呼ばれていたもの）を適用することによって提供 されますが、このバージョンでは、Windows と Linux を実行する Intel Itanium 64 ワー クステーションだけでなく、Linux ベースの AMD インストール・システムに対しても、 64 ビット・サポートが追加されます。AIX、Solaris、および HP-UX 上の DB2 UDB は、同 じワークステーション上で 32 ビット・モードと 64 ビット・モードの両方を（インスタ ンス・ベースで）実行できます。64 ビット・モードの DB2 UDB における混合ビット・ バージョンは、Windows IA-64 または Linux IA-64 環境では共存できません。これらの 環境では、64 ビット DB2 UDB のみがサポートされます。例えば、32 ビット・バージョン の DB2 UDB for Windows は、64 ビット・マシンにはインストールできません。 世界で広く使用されているハードウェア全体で Linux に対応するという IBM のコミット メントを完全に実現するために、DB2 UDB v8.1.2 では、iSeries および pSeries ハード ウェア用の 32 ビット・バージョンのエンジンも提供しています。これらのプラット フォームで DB2 UDB をご利用のお客様は、低コストで柔軟性に富む Linux 環境を使用し て、IBM の強力なプロセッサーの利点を活用できるようになりました。今日では、お客 様はすべての IBM e-server（iSeries、pSeries、ZSeries、xSeries）で Linux の利点を ご活用いただけます。 DB2 Universal Database および DB2 Connect がサポートするオペレーティング・システム 5 v8.1.2 の一般出荷可能日現在、DB2 UDB および DB2 Connect は、表 1.1 に示すオペレー ティング・システム上でサポートされています。 表 1.1 テム DB2 UDB および DB2 Connect v8.1 と v8.1.2でサポートされるオペレーティング・シス オペレー ティング システム DB2 UDB PE、WSE、WSUE、ESE、 および DB2 Connectのサポートされるバージョン AIX ･ バージョン 4.3.3（64 ビット・インスタンス・サポートなし） ･ バージョン 5.1 ･ バージョン 5.2 （DB2 UDB v7.2 は、FixPak 4 以上が適用された AIX 5.2 をサポート） Solaris ･ Solaris 7 ･ Solaris 8 ･ Solaris 9 （DB2 UDB の Solaris に対するサポートは、SPARC 配布用のみ） HP-UX ･ HP-UX 11i（11.11） Linux Linuxは、絶えず変化する性質を持っているため、DB2 UDBのLinux検証テスト・ パッケージに合格した配布のみがサポートされます。DB2 UDB用の検証済みLinux 配布の全リストは、www.ibm.com/software/data/db2/linux/validate/ に掲載されてい ます。 Windows ･ Windows 98 と Windows Me（DB2 UDB Personal Edition および DB2 Connect Personal Edition のみをサポート。ただし、DB2 UDB クライアントは Windows 98上でサポートされます。 ） ･ Windows XP（DB2 UDB Workgroup Server Edition、DB2 UDB Workgroup Server Unlimited Edition、および DB2 Universal Developer Editionのみをサポー ト。これは、Microsoft が設定した Windows XP に対する方針に沿ったもので す）。最低限として Service Pack 1を適用することをお勧めします。 ･ Windows NT v4（ServicePack6a+を適用） ･ Windows 2000（Windows Terminal ServerにはServicePack 2が必要です。最 低限として Service Pack 1 を適用することをお勧めします。） ･ Windows Server 2003 ご使用のオペレーティング・システムをサポートするために必要な APARまたは PTF につ いては、常に DB2 UDB の製品資料やサポート Web サイトでご確認ください。 6 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 DB2 UNIVERSAL DATABASE のライセンスとパッケージの変更 DB2 UDB v8.1 では、ライセンスとパッケージが変更されて、ユーザーはこれまでにな く多くの価値を引き出せるようになりました。名称の小さな改訂のほかに、新しいエ ディションがいくつか追加されています。ここでは、その内容について説明します。 DB2 UDB v8.1.2 オファリングは、パームトップからテラフロップまでのソリューショ ンに対応します。図 1.1 は、マルチプラットフォーム・ファミリーの DB2 UDB v8.1.2 を示しています。 図 1.1 マルチプラットフォーム・ファミリー用の DB2 UDB v8 DB2 UDB PERSONAL EDITION バージョン8.1リリースでは、DB2 UDB Personal Edition（DB2 UDB PE）のパッケージに ついては変更はありませんが、DB2 UDB Satelliteバージョン6.1がDB2 UDB PEに組み入 れられています。随時接続ソリューションを実装したいお客様は、DB2 Everyplace （こ れはCloudscapeおよびJ2MEクライアントもデータ・ストアとしてサポートします）また はDB2 UDB PEを選択できるようになりました。また、サテライト・システムのリモート 管理に関連したControl Serverフィーチャーが拡張され、DB2 UDBサーバーをサテライト と同じ方法で管理できるようになっています。 DB2 UDB Express 7 DB2 UDB EXPRESS DB2 UDB Express は、DB2 UDB v8.1.2 の新しい画期的なオファリングです。中小規模市 場や組み込みのインプリメンテーションで、利便性と隠れた価値を提供します。DB2 UDB Express は、価値を生むまでの時間（time to value）を加速させている中小規模 の企業や独立ソフトウェア・ベンダー向けに特別に調整されたフル装備、高性能、オー プン業界標準ベースのリレーショナル・データベースです。 DB2 UDB Express は、Linux や Windows の利点を活用することを選択したお客様にとって 非常に魅力的な導入価格となっています。また、ビジネス・パートナーのアプリケー ション、サービス、サポートを幅広く選択できるのも魅力です。IBM の自己チューニン グ・オプティマイザー、構成アドバイザー、ヘルス・センターなど、管理の容易性を 実現するオートノミック（自己管理）機能が組み込まれています。これらのツールは、 DB2 UDBソリューションのパフォーマンスと信頼性の向上に役立つと同時に、管理の複 雑さ、要求されるスキル、および総費用（TCO）を最小化するのにも貢献します。DB2 UDB のこのエディションは、Linux、Windows、および UNIX プラットフォーム用の拡張が 容易な DB2 UDB ファミリーの他のリレーショナル・データベースと完全な互換性があり ます。ビジネス・パートナーは、DB2 UDB Express をアプリケーション内で透過的にイ ンストールするよう事前構成して、関係するお客様に容易に配置できます。 DB2 UDB Express の主な機能と利点は、次のとおりです。 ･ インストールと配置が容易。データベースはアプリケーション内でサイレント・ インストールできます。また、オートノミック（自己管理）機能を備えている ため、インストールや管理に必要とされる複雑さ、スキル、リソースを最小限 に抑えることができます。DB2 UDB Express は、アプリケーション内で目立たな いように自動的にインストールされるので、金融、保険、小売りなどの主な垂 直市場（バーティカル・マーケット）向けオファリングに事前構成で容易に組 み込めます。 ･ 価値を生むまでの時間（time to value）を迅速化。DB2 UDB Express は、アプ リケーションとの統合が容易で、PartnerWorld サポート構造が標準装備されて いるため、選択されたソリューションの製品化までを迅速化します。 ･ 手頃な価格。このソフトウェアは、市場のニーズに応えて、非常に競争力のあ る価格に設定されています。事実、DB2 UDB Express の 5 ユーザー・ソリュー ション（これは、DB2 UDB サーバーとまったく同じであり、この点では妥協して いないことを念頭に置いてください）の価格は、1,000 ドル以下です（小売価格 は米国通貨単位です。地域によって価格が変動します）。 ･ お客様のベンダー固定化を回避。DB2 UDB は、オープンな業界標準に基づいてお り、業界の広く普及しているプラットフォーム間での移植が可能です。 ･ 既存の投資を保護。既存の設備を「除去した上で置換」する必要がなく、DB2 UDB のオープン・スタンダードおよびフェデレーション（連合）機能に移行する ことができ、複数のプラットフォームおよびデータ・ストアにまたがるデータ をより高速、より効率的に洞察できるようになります。 8 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 ･ オンデマンドでの拡張が容易。業務の拡大に応じて、基礎のデータベースを拡 張できます。 DB2 UDB Express は、2 way 対称マルチプロセッサー（SMP）以下のハードウェア・ボッ クスで実行される Windows または Intel/AMD Linux ベースのワークステーションにのみ インストールできます。このバージョンの DB2 UDB への Web アクセスに対するライセン スは、イントラネット（会社のファイアウォールの背後）またはエクストラネット （ユーザーを識別できる場合。例えば、オンライン・バンキング用）での使用のみを対 象とし、32 ビット・ランタイム・メモリー・モデルのみに限定されます。 DB2 UDB Express についての詳しい情報は、www-3.ibm.com/software/data/info/db2express/ をご覧ください。 DB2 UDB Workgroup Server Edition とWorkgroup Server Unlimited Edition DB2 UDB v8.1 では、DB2 UDB Workgroup Edition （DB2 UDB WE）v7.2 と DB2 UDB Workgroup Unlimited Edition（DB2 UDB WUE）v7.2 は、それぞれ DB2 UDB Workgroup Server Edition （DB2 UDB WSE）と DB2 WorkgroupServer Unlimited Edition（DB2 UDB WSUE）に名称が 変更されました。これらの製品は、パッケージについては大きな変更はありませんが、 ライセンスが変更されているので注意が必要です。 DB2 UDB v7.2 では、DB2 UDB WE に対してインターネット・プロセッサー・ライセンス を取得できました。DB2 UDB v8.1 では、DB2 UDB WSE は、登録ユーザーおよび同時ユー ザーを使用したライセンスのみが交付されます。DB2 UDB WSE v8.1 では、インターネッ ト接続（会社のファイアウォールの外部からのアクセス）に対するライセンスを取得 することはできません。ただし、イントラネット接続（会社のファイアウォールの内 部）については、登録ユーザーまたは同時ライセンスを使用してライセンス交付を受 けることができます。 DB2 UDB WEおよびDB2 UDB WUE v7.2では、基本ハードウェアが所有できるプロセッサー の最大数に関する制限もありました。UNIX ベースのワークステーションの場合、DB2 UDB WE v7.2 では、2 つ以下のプロセッサーを持つ SMP マシンにのみインストールできま した。Windows および Linux がインストールされたシステムの場合は、4 つのプロセッ サーが最大許容数でした。DB2 UDB WUE v7.2 では、限度は、UNIX ベースのワークステー ションの場合は4つのプロセッサー、LinuxベースまたはWindowsベースのワークステー ションの場合は 8 つのプロセッサーでした。DB2 UDB v8.1 からは、これらの製品は両方 とも、どのオペレーティング・システムの場合も、最大 4 つのプロセッサーを持つ SMP ハードウェアにインストールできるようになりました。 DB2 UDB の Workgroup サーバー製品と Enterprise サーバー製品の相違について詳しく は、www7b.boulder.ibm.com/dmdd/library/techarticle/0301zikopoulos/0301zikopoulos1.html に 掲載されている Paul Zikopoulos 著の「Differences Between DB2 UDB’s Workgroup and Enterprise Edition Offerings」を参照してください。 DB2 UDB Express 9 DB2 UDB Enterprise Server Edition とデータベース・パーティション・ フィーチャー DB2 UDB の新規バージョンでは、DB2 UDB のエンタープライズ製品のパッケージ化に重要 な変更が行われています。DB2 UDB v8.1 では、DB2 UDB Enterprise Edition v7.2（DB2 UDB EE）の名称が変更されてDB2 UDB Enterprise Server Edition（DB2 UDB ESE）となり ました。DB2 UDB v7.2 では、DB2 のデータベース区分化機能は、DB2 UDB EnterpriseExtended Edition（DB2 UDB EEE）と呼ばれる別のエディションで提供されていました。 機能上の観点からは、DB2 UDB EEとDB2 UDB EEEは6年以上にわたって同じコード・ベー スを共有しており、DB2 UDB EEEの方は、データベースを単一イメージとして複数のデー タベース・サーバー上に区分する機能を備えていることだけが相違でした。DB2 UDB v8.1 では、DB2 UDB EEEで提供されていた追加機能は、データベース・パーティション・フィー チャー（DPF）と呼ばれるDB2 UDB ESEの有償コンポーネントになっています。DPFは、そ れを使用するライセンスを取得するだけで済みます。DB2 UDBデータベースを区分する機 能を得るために別途インストール・プロセスを実行する必要はありません。つまり、DB2 UDBプラットフォームに対してコミットメントしたお客様は、ワークロードやビジネス要 求に応じてシームレスに拡張することが可能です。また、DB2 UDB v8 のGUIツールもパー ティション・データベース環境を完全にサポートしています。このパッケージは常に同 じ製品であったことから、組み合わされることになったのは当然の成り行きと言えます。 DB2 UDB v8.1 では、フェイルオーバー構成のライセンス交付条件が変更されています。 アクティブ・スタンバイ・システムの場合、スタンバイ・サーバー上のすべてのプロ セッサーに対するライセンスを取得する必要があります。アイドル・スタンバイ・サー バーの場合は、1 つのプロセッサーに対するライセンスを取得するだけで済みます。 フェイルオーバー用 DB2 UDB サーバーのライセンスの取得方法については、http:// www7b.boulder.ibm.com/dmdd/library/techarticle/0301zikopoulos/0301zikopoulos.html に掲載 されている Paul Zikopoulos 著の「Licensing Distributed DB2 UDB Version 8 Servers in a High-Availability Configuration」を参照してください。 DB2 UDB Data Warehouse Edition DB2 UDB Data Warehouse Edition（DB2 UDB DWE）は、吟味して選択されたIBM BI製品を 組み合わせて、お客様やパートナーが次世代の分析ソリューションを配置または構築す るのに必要なあらゆる機能を備えた包括的なBIプラットフォームを提供します。このエ ディションは、BIに関するIBMの方針（つまり、データベースにBI機能を組み込み、統 合BIプラットフォームの一部としてオープン・スタンダード・インターフェースのみを 通してアクセスできるようにし、アーキテクチャーの他の層に対してパートナーと共同 作業をする）を強化するものです。 DB2 UDB は、BI アプリケーションの豊かなフレームワークを提供し、お客様が自社の データをより深く洞察できるように支援する既製の分析ソリューションを提供するこ とにかけては、強い伝統を誇っています。事実、分析機能は、長年にわたって DB2 UDB 10 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 の標準 SQL アプリケーション・プログラミング・インターフェース（API）の強力なコ ンポーネントの 1 つとなっています。機能には、次のものが含まれます。 ･ ･ ･ ･ ･ ･ Rank、Denserank、Rownumber、AVG、MIN、MAX、CNT、SUM 共分散、相関、標準偏差 一定期間の平滑化された移動平均を定義するための行による配列 グループ式 : Cube、Rollup、Group by、Partition by 回帰 : こう配、交差、診断統計、決定係数 サンプリング : SQL 文節としての RAND 関数 多次元クラスタリング（MDC）表、マテリアライズ照会表（MQT）、および DPF 機能など の DB2 UDB の基本データベース・オブジェクトは、拡張が容易な環境を提供し、エンジ ンを活用して高速照会を実行するのに貢献します。 データウェアハウスおよび分析用の DB2 UDB インフラストラクチャーを、11 ページの図 1.2 に示します。 11ページの図 1.2から、DB2 UDBエンジンに深く組み込まれたインフラストラクチャー・ テクノロジーは、オープン・スタンダード・インターフェースを通してのみアクセス が可能であることが分かります。この構造の利点は、並列処理、高可用性、セキュリ ティー、分散処理、新規イノベーションなど、DB2 UDB からの属性を継承していること です。 多次元オンライン分析処理（MOLAP）データベースは、一般的には、分析問題を解くた めのより高速な OLAP アプローチと考えられ、最終的に「思考速度」の応答時間が得ら れるものと期待して、ビジネスを洞察する手段として好んで使用されてきました。 MOLAP の欠点は、データ・ストア用の別のエンジン、別の管理アプローチ、別の照会言 語、および別の API が必要になることです。 DB2 UDB OLAP Server（IBM のオリジナル装置製造業者の Hyperion’s Essbase サーバー 製品）や Microsoft の Analysis Services エンジンが、MOLAP エンジンの例です。リレー ショナル OLAP（ROLAP）の支持者は、新たなデータベース・エンジンを管理したり、新 しい照会言語を書くのは負担であると感じており、既存の SQLスキルを活用して OLAP を 行うことを選択しています。また、MOLAP アプローチは、単一バージョンの真理が複数 のキューブ・サーバー間で重複しているという点で、データの冗長性も多く見られま す。完全に異なるデータベースを所有し、異なる照会言語を使用する必要がある点に ついては、最近、スピードかコストかの論議が話題になっています。 DB2 UDB Express 11 図 1.2 DB2 UDB エンジンに深く組み込まれた BI インフラストラクチャー リレーショナル・エンジンが思考速度の応答時間を達成でき、管理タスク、キューブ・ モデリング、ETL、および API が一元化され、Cognos、Business Objects、BRIO などの 最も一般的なフロントエンド分析ツールにシームレスに適合できるような別のアプ ローチがあるとしたらどうでしょうか。 DB2 UDB DWE では、Cube Views と呼ばれる新しいフレームワークが追加されています。 DB2 UDB の Cube Views は、リレーショナル・エンジンによる分析の生産性を高めます。 Cube Views を使用すると、データベース管理者（DBA）は、データベース内のキューブ を一度だけモデル化し、それを別の場所で再利用できます。そのオープンなフレーム ワークにより、選択した設計ツール（例えば、ERwin）でキューブをモデル化し、その モデルを DB2 UDB にインポートすることも可能です。このフレームワークは、各 BI ツー ルごとのキューブ・モデリング・スキルの必要性を排除し、それぞれのツールにイン ポートするだけで、高速かつ迅速に分析が行えるようにします。ツール間で努力が重 複することも避けられます。DB2 UDB Cube Views のトポロジーを 12 ページの図 1.3 に 示します。 12 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 図 1.3 DB2 UDB の Cube Views Cube Views フレームワークは、基礎の DB2 UDB オブジェクトに基づいて仮想キューブを モデル化し、思考速度の応答時間を達成できる機能を提供します。アドバイザーが組 み込まれており、仮想キューブ用に作成する必要がある DB2 UDB オブジェクトを提案し ます。このフレームワークの利点として、専有の個別 API から解放されて自由に高速分 析が行えること、情報の整合性が高まること（誰もが同じ詳細と集約を見る）、一貫性 のある一連のメトリックを使用できること（すべてのアプリケーションが同じ測度と 公式を使用するため）、分析ソフトウェアのキューブ構築フェーズが信じられないほど スピードアップされること、データベース内の SQL アクセス可能 OLAP のパフォーマンス が向上することなどが挙げられます。 Cube Viewsフレームワークは、 Microsoft ExcelプラグインのOffice Connect Analytics とも連動し、DB2 UDB 内のキューブ・ビューを表示してナビゲートしたり、スプレッド シートを調整してOLAPツールに組み込んだりすることができます。Cube Viewsについて の詳しい情報は、www-3.ibm.com/software/data/db2/db2md/features.html に掲載されていま す。 DB2 UDB Express 13 DB2 UDB DWEには、 DB2 UDB DW Enterprise Edition （EE） とDB2 UDB DW Standard Edition （SE）の2種類のエディションがあり、プロセッサー・ベースでライセンスが交付されま す。 DB2 UDB DW EE には、次のものが含まれます。 ･ ･ ･ ･ ･ DB2 UDB Enterprise Server Edition DPF Cube Views Intelligent Miner Modeling, Visualization, and Scoring Information Integrator Standard Edition（ETL オペレーションのリレーショ ナル・ラッパー・サポート用の限定使用ライセンス） ･ Office Connect Web Enterprise Edition ･ DB2 Query Patroller（DB2 UDB 8.1.2アップデートとして入手可能） ･ Warehouse Manager Standard Edition DB2 UDB DW 製品は、別途ライセンス交付されるスタンドアロン製品として入手するこ ともできます。 DPF、Warehouse Manager、Office Connect、Information Integrator、お よ び Query Patroller 製品は、DB2 UDB DW SE パッケージには含まれていません（本書は、DB2 UDB for Multiplatforms v8.1.2 までのコア・フィーチャーを対象としているため、Cube Views の説明は、本書には含まれていません）。 要約すると、DB2 UDB DW EE と DB2 UDB DW SE は、立証済み線形スケーリングを使用し たオープンなプラットフォーム中立のモデルと、統一エンジンを搭載したリアルタイ ム・データウェアハウス（OLAP、マイニング、空間解析、統計、変換、および連合を サポートする包括的な BI プラットフォームにラップされた）の基本的なアーキテク チャーの利点を提供します。加えて、これらをパッケージした小売り価格は、各コン ポーネントを個別に購入した場合に比べて、最大で 80% の割引になります。まさに一般 大衆向けの BI です。 14 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 DB2 CONNECT のライセンスとパッケージの変更 DB2 Connect v8.1 は、より費用効果の高いソリューションである真新しいDB2 Connect オファリングを提供し、ライセンス交付の条件が多少変更されています。 DB2 Connect Application Server Edition DB2 Connect v8.1 では、DB2 Connect Application Server Edition（DB2 Connect ASE） と呼ばれる新しいエディションが導入されました。DB2 Connect ASE では、zSeries ま たは iSeries プラットフォーム上の DB2 UDB データにアクセスする必要がある多層クラ イアント / サーバーまたは Web サーバー・アプリケーションを配置する必要があるお客 様の特定ニーズに対応するために、異なるライセンス条件が提示されています。この タイプのアプリケーションは、中層のアプリケーション・サーバーを使用し、そこで 大多数のアプリケーション・ロジックが実行されるのが特徴です。こうしたアプリケー ションの例としては、PeopleSoft、Siebel、WebSphere、BEA Weblogic、i2、Microsoft IIS、CICS、Microsoft MTS、Microsoft COM+、Ascential DataStage、Brio、Business Objects、COGNOS、Microstrategies などがあります。 DB2 Connect ASE のライセンス使用料は、DB2 Connect を使用してホスト・ベースのデー タにアクセスする Web サーバーまたはアプリケーション・サーバーが使用できるプロ セッサーの数に基づきます。DB2 Connect ASE のライセンス使用料は、DB2 Connect 自 体が使用できるプロセッサーの数、接続先のバックエンド・データベースのサイズ、あ るいはアプリケーション・サーバー上で実行されているアプリケーションの量に基づ くものではありません。例えば、DB2 Connect ASE がアプリケーション・サーバーと同 じボックスに配置さている場合でも、別のサーバーにインストールされている場合で も、DB2 Connect ASE のライセンス使用料は同じです。 ソリューションのプレゼンテーション・ロジックとビジネス・ロジックをそれぞれ異 なるアプリケーション・サーバー層に配置するような環境を実装する場合もあります。 このような複雑な環境の場合、DB2 Connect ASE サーバーのライセンス取得方法を知る ための最も簡単な方法は、「SQL が生成される場所はどこか」を考えてみることです。 SQL の生成を援助するプロセッサーは、ライセンス交付を受ける必要があります。 例えば、15 ページの図 1.4 に示したようなトポロジーを考えてみてください。 この実装では、3 つの 2 way SMP サーバーがプレゼンテーション・ロジックを処理し、 そこに Hypertext Transfer Protocol（HTTP）アプリケーション・サーバーがインス トールされています。クライアントは、Web ソリューションへのフロントエンドとして、 この層に接続します。8 way SMP サーバーにはアプリケーション・サーバーが組み込ま れており、そこでビジネス・ロジックと SQL が生成されます。SQL 要求は、DB2 Connect ASE が格納されている、6 つのプロセッサーを備えた別の層を通して経路指定されます。 この環境では、DB2 Connect ASE ライセンスを 8 つ購入する必要があります。 DB2 Connect のライセンスとパッケージの変更 15 図 1.4 DB2 Connect ASE に適した従来の多層トポロジー DB2 Universal Database Enterprise Edition に組み込まれた DB2 Connect コ ンポーネント DB2 UDB ESE v8.1 には、データ・レプリケーションやサーバー管理のためにミッドレ ンジまたはメインフレームに随時接続する環境向けに、DB2 Connect コンポーネントが 組み込まれています。DB2 ESE サーバーの DB2 Connect コンポーネントは、zSeries およ び iSeries ベースの DB2 UDB サーバーにアクセスするために（追加料金なしで）5 名の 登録ユーザーにライセンスを交付します。このライセンス交付を受けるユーザーの数 を増やすには、DB2 Connect のエディションのライセンスを取得する以外に方法はあり ません。 追加ユーザーがこれらのサーバーにアクセスする必要がある場合は、適切な DB2 Connect 製品を購入して、インストールする必要があります。ただし、無償で 5 名の登 録ユーザーのライセンス交付を受ける権利があります。例えば、11 名の登録ユーザー のライセンスが必要であり、4 way DB2 UDB ESE サーバーのライセンスを取得している 場合、6 名の追加登録ユーザー・ライセンス付きの DB2 Connect サーバー・ライセンス を購入することが必要です（登録ユーザー・モデルをそのまま使用すると仮定した場 合） 。11 名の同時ライセンスが必要な場合は、10 名の同時ライセンス付きの DB2 Connect 16 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 サーバー・ライセンスを購入することが必要です（DB2 Connect EE サーバー・ライセ ンスには、1 名の登録ユーザーまたは同時ユーザー・ライセンスが付いているため）。 その他の変更 DB2 UDB v8.1 の発表では、ユーザーが DB2 UDB WSE または DB2 UDB WSUE サーバー上に DB2 Connect サーバーをインストールすることを制限しています。この条件は、DB2 UDB v8.1.2 の発表レターで正式に変更されました。DB2 UDB WSE v8.1 または DB2 UDB WSUE v8.1 サーバー上に DB2 Connect サーバーをインストールする権利が与えられています。 DB2 UDBおよびDB2 Connect v8.1では、分散リレーショナル・データベース体系（DRDA） サーバーに直接接続できるように、JDBC タイプ 4 ドライバーが付属していました。この ドライバーを使用することを選択する場合でも、 iSeriesまたはzSeriesサーバー上のDB2 に接続するには、DB2 Connectを通してライセンス交付を受ける必要があります。 最後に、 DB2 Connect Web Starter Kitはもう使用できなくなくなりました。 DB2 Connect パッケージの内容と DB2 Connect のライセンス交付については、www7b.boulder.ibm.com/ dmdd/library/techarticle/0303zikopoulos1/0303zikopoulos1/html の「Which Edition of DB2 Connect is Right for You?」（Paul Zikopoulos、Leon Katsnelson、Roman Melnyk著） で分かりやすく説明しています。 DB2 Universal Database 関連製品の変更 DB2 UDB v8.1 リリースでは、DB2 UDB で使用できる拡張性フィーチャーの一部のものも 変更されています。 DB2 UDB XML Extender DB2 UDB v7.2 では、DB2 UDB XML Extender は無償の追加製品で、DB2 UDB サーバーに Extensible Markup Language（XML）機能を提供するために別途インストールする必要 がありました。DB2 UDB v8.1 リリースでは、XML 拡張機能はコンポーネントとなり、す べての DB2 UDB サーバーの標準インストールに含まれています。別途 DB2 UDB XML Extender をインストールする必要はなくなりました。 Text Searching Extender DB2 UDB v7.2 では、3 種類のテキスト検索エンジンを個別に入手できました。 ･ DB2 UDB Text Information Extender（DB2 UDB TIE） ･ DB2 UDB Net Search Extender（DB2 UDB NSE） ･ DB2 UDB Text Extender（DB2 UDB TE） DB2 UDB v8.1では、DB2 UDB TIE と DB2 UDB NSE が同じ箱で出荷されるようになりまし た。 DB2 Connect のライセンスとパッケージの変更 17 DB2 UDB NSE は無償コピーが提供され、最大 5 名の指定ユーザーの DB2 UDB PEおよび DB2 UDB WSE にインストールできます。このテクノロジーのユーザー数が 5 名を超える場合 は、DB2 UDB NSE のライセンスを購入し、それを DB2 UDB WSUE または DB2 UDB ESE サー バーにインストールする必要があります。この製品は、プロセッサー・ベースでライ センスが交付されます。DB2 UDB NSE v7.2 のコピーをご購入の方は、DB2 UDB NSE v8.1 の無償コピーを受け取る権利があります。 DB2 UDB v8.1 が一般出荷可能になった以降は、DB2 UDB TE は v7.2 レベルでしか使用で きませんでした。TE は、多言語検索に使用されます。DB2 UDB v8.1.2 では、TE は DB2 UDB NSEの一部として出荷されるようになり、言語専用辞書に基づく完全言語検索機能 を DB2 UDB に提供します。DB2 UDB NSE は、プロセッサー・ベースでライセンスが交付 されます。 v8.1.2 では、DB2 UDB NSE は、通常のサポートされるプラットフォームに加えて、Linux （Intel および AMD サーバー）および HP-UX 上でも使用できるようになりました。また、 DB2 UDB NSE for AIX は、パーティション・データベース環境でも実行できます。 DB2 UDB Spatial Extender DB2 UDB v7.2 では、DB2 UDB Spatial Extender（DB2 UDB SE）は、DB2 UDB EE および DB2 UDB EEE システム上にのみ、購入してインストールできました。DB2 UDB v8.1 で は、DB2 UDB SE の無償コピーが提供され、最大 5 名の指定ユーザーで、DB2 UDB PE およ び DB2 UDB WSE にインストールできます。テクノロジーのユーザー数が 5 名を超える場 合は、DB2 UDB SE のライセンスを購入し、それを DB2 UDB WSUE または DB2 UDB ESE サー バーにインストールすることが必要です。この製品は、プロセッサー・ベースでライ センスが交付されます。 v8.1 リリースには、Linux、Solaris、および zLinux プラットフォームに対するサポー トも組み込まれています。これらのプラットフォームでは、以前は DB2 UDB を使用した 空間解析はサポートされていませんでした。 DB2 UDB DataJoiner、DB2 UDB Relational Connect、および DB2 Information Integrator DB2 UDB v7.2 では、従来型および非従来型データを管理する異機種データ・ストアへ の 読 み 書 き ア ク セ ス は、DB2 UDB DataJoiner、DB2 UDB Relational Connect、DB2 DataPropagator（DPropR）、Life Sciences Data Connect など（ただし、これだけに限 りません）の単一製品または複数の製品の組み合わせによってサポートされていまし た。DB2 UDB v8.1 では、これらの製品は発注可能なオファリングとしてなくなりまし た。これらの製品は、単一の標準 SQL API を使用し、最適化および関数補正の機能を 備えており、企業が異種のデータ・ストアを費用効果の高い方法で活用するのに貢献 していたために、DB2 UDB v8.1 の機能に一時的にギャップが生じることになりました。 （ただし、DB2 UDB v8.1 では DB2 ファミリーおよび Informix データベースの任意のメン バーと連合することができました。これはコア・エンジン機能の一部です。） 18 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 新規のオファリングである DB2 Information Integrator（DB2 II）は、DB2 UDB v8.1.2 で使用可能となり、お客様に構造化および非構造化データへの読み書きアクセスを提 供します（図 1.5 を参照）。 図 1.5 オープン・スタンダード SQL API と DB2 II を通してデータにアクセス DB2 IIによって提供される具体的な統合機能としては、連合照会のパフォーマンスを向 上するキャッシングの連合（MQT を通した）、DB2 の SQL API に対する完全なサポート、 コンテンツとライフ・サイエンスの連合、XMLとマテリアライズ照会の統合、IBM Lotus Extended Search、.net、ODBC、OLE DB、DB2 UDB NSE、異機種リレーショナル・レプリ ケーションなどがあります。 DB2 UDB II には、4 種類のエディションがあります。 ･ DB2 Information Integrator Replication Edition。このパッケージには、限 定使用のデータ・ストア（レプリケーション・コントロール・サーバーとして 使用）および接続ベースの価格のコネクターが含まれています。 DB2 Connect のライセンスとパッケージの変更 19 ･ DB2 Information Integrator Standard Edition。このパッケージには、限定使 用のデータ・ストア（ローカル・キャッシュとして使用）、DB2 UDB NSE、およ び接続ベースの価格のコネクターが含まれています。DB2 UDB v7.2 のお客様で DB2 DataJoiner、DB2 Relational Connect、お よ び DB2 Life Sciences Data Connect を購入された方は、DB2 II Standard Edition にアップグレードする権 利があります。 ･ DB2 Information Integrator Advanced Edition。このパッケージには、フル機 能のデータ・ストア、DB2 UDB NSE、および接続ベースの価格のコネクターが含 まれています。 ･ DB2 Information Integrator Advanced Unlimited Edition。このパッケージに は、フル機能のデータ・ストア、DB2 UDB NSE、および異機種データ・ストアへ の無限数のコネクターが組み込まれています。 DB2 II の課金方式には、プロセッサー・ベースの課金と接続ベースの課金があります。 DB2 UDB DataJoiner、DB2 UDB Relational Connect、または Life Science Data Connect を購入されたお客様のアップグレード・パスは、DB2 II Standard Edition で提供され ます。 もう1つ、DB2 II for Contentと呼ばれるオファリングも提供されています。この製品 は、Enterprise Information Portal（EIP）の後継製品で、パッケージ化は先行製品と 同じです。 DB2 II についての詳しい情報は、www-3.ibm.com/software/data/integration/から入手でき ます。 DB2 UDB Query Patroller DB2 UDB v8.1.2 より、DB2 UDB Query Patroller は独立した製品として注文できるよう になりました。以前は、このソフトウェアのユーザーに与えられていなかった選択肢 です。製品が完全に再構築されたため、DB2 UDB Query Patroller v8 は、DB2 UDB v8 サーバーの管理にのみ使用できます。 DB2 UDB Query Patroller のワークロード管理機能は、管理者にデータウェアハウスを 制御する機能を提供し、管理者は以下のことが可能になります。 ･ ユーザーおよびグループに対して個別に照会の応答時間やスループットの優先 順位を付ける。 ･ 大きい複雑な照会がシステムに与える影響を制限する。 ･ キャッシュされた照会結果を共用する。 ･ ウェアハウスの使用に関するレポート。 ･ 「ランナウェイ照会」症候群を除去する。 ･ 定義されたサービス・レベルに従ってウェアハウス・リソースを割り振ること によって、エンド・ユーザーの満足度を高める。 20 第 1 章 DB2 Universal Database および DB2 Connect の パッケージと ライセンスの変更 DB2 Query Patroller v8 は、照会のサブミットと実行のすべての局面を管理および制 御するための拡張機能を備えています。こうした拡張機能としては、サーバー・ベー スでのすべてのソースからの SQL インターセプト、SQL ステートメントのコスト計算の 改善、結果セットの保管のための追加オプション、インストール、構成、および管理 の単純化などが挙げられます。 使用すべきでないパッケージ DB2 UDB v8.1 サーバー・リリースでは、その他のパッケージ化の変更として、DB2 UDB OLAP スターターキット、DB2 Warehouse Manager connectors for i2TradeMatrix and ETI*Extract、および DB2 Connect Web Starter Kit が除去されています。DB2 Net.Data は、DB2 UDB v7.2 レベルに保たれています。 P A R T 2 パフォーマンス ■ ■ ■ 多次元クラスタリング表 宣言済みグローバル一時表 システム・デフォルト値と NULL 圧縮 ■ ■ ■ ■ 情報制約 コネクション・コンセントレーター ユーザー保守のマテリアライズ照会表 データベース・システム・モニターの機能強化 ■ その他のパフォーマンスの機能強化 C H A P T E R 2 多次元クラスタリング表 企業アナリストが事業について考える場合、 「2000 年の東部地域の売上はどうであっ たか？ 2001 年の第 4 四半期のメキシコのブルー・ウィジェットの売上はどうか？」と いう次元で答えを出すのが一般的です。 今日のリレーショナル・データベース・ベンダーが直面している課題は、現在のテク ノロジーがサポートできるのは、順序付けられたデータ・ストレージと単一対象（ま たは、次元）のデータ・アクセスに限られていることです。これに代わる方法として、 多 次 元 オ ン ラ イ ン 分 析 処 理（Multidimensional OnLine Analytical Processing （MOLAP） ）エンジンが検討されています。MOLAP は、多次元分析用に設計されたベンダー 専有のストレージ・エンジンを搭載しています。しかし MOLAP は、アプリケーション・ プログラミング・インターフェース（API）の専有アクセス、専有の照会言語、独立し たデータベース・エンジン、変換コスト、管理コストなど、さまざまなコストを伴い ます。 これに加えて、CPU 速度はムーアの法則（プロセッサーの速度は 18 か月ごとに倍増す る）に従って加速するのに対して、ディスク・コントローラーのアームはそうではあ りません。つまり、コンピューターの CPU 速度が 100% 増加しても、ディスクとやり取り されるデータのパイプは、CPU の進歩のほんの一部分（おそらく、10％程度の増加）に とどまります。明らかに、パイプのフィード速度を速くし、高速の CPU を活用できるよ うにする、もっと良い方法があるはずです。 DB2 UDB v8 は、MDC 表をサポートすることにより、データ・アクセスとストレージの概 念に、新鮮でユニークな画期的アプローチを導入しています。事実、このアプローチ は革命的とも言えるもので、IBM ではこの技法を中心に多数の特許を申請しています。 24 第 2 章 多次元クラスタリング表 このことは、データベースの特許件数において、DB2 UDB は他のすべてのリレーショナ ル・ベンダーを組み合わせた数を上回っている理由を如実に実証しています。 MDC は、複数の次元でデータのクラスタリングを柔軟に、継続的かつ自動的に実行する 画期的な方法を提供します。この新機能により、照会のパフォーマンスが大きく向上 するだけでなく、表の再編成や INSERT、UPDATE、DELETE（I/U/D）操作後の索引保守な ど、データ管理操作のオーバーヘッドを大幅に削減できます。この章では、MDC がユー ザーに提供する以下の利点について学びます。 ･ 要求されたデータを含んでいるデータ・ページのみにアクセスし、誤った検索 を排除し、ディスク・アクセスの回数を減らすことによって、照会の速度を高 速化する。これにより、CPU の使用とディスク I/O が削減され、こうしたリソー スを他のアプリケーションのために維持できるようになります。 ･ エグゼクティブ・レポートやサマリーのような OLAP スタイルの階層分析に最適 な環境を提供する。 ･ 索引のサイズを縮小する。これは、ディスクの節約と照会の高速化につながり ます。 ･ 表の再編成や再クラスタリングなど、一部の保守操作を実質的に排除する。 ･ 削除を高速化する。 ･ 挿入を高速化する。 基本的には、MDC は、表を複数の次元で同時に物理的に順序付けることを可能にします （これは、そのようなことが可能であるとすれば、単一の表に対して複数のクラスター 索引を持つのと同じことです）。特に、MDC 表では、ディスク上の行が連続したページ を含むブロック単位で編成されることが保証されるので（MDC 用語では、ブロックはエ クステントと同義）、ブロック内のすべての行が事前定義された同じ次元値を持ちま す。すべてのブロックが同じページ数から成り、複数のブロックが同じ次元値を持つ とができます（その次元値を持つレコード数が十分にある場合）。 MDC 表の次元は、表の作成時に指定します。各次元ごとにそれ専用の単純索引が自動的 に作成され、多くの場合は、次元セット全体に対する複合索引も作成されます。 MDC 表は、大部分は他の表と同様に扱われます。つまり、トリガー、参照保全、ビュー、 マテリアライズ照会表（DB2 UDB 7.x では自動サマリー表 [AST] と呼ばれていたもの） をすべて定義できます。 MDC 表を説明するのに使用される用語（スライス、次元など）は、OLAP ユーザーがよく 知っている用語です。MDC 表は、OLAP 操作にとって便利なものですが、OLAP 専用ではな いことを明確にしておくことが重要です。MDC 表は、どのようにしてデータをディスク に固定化するか、つまり、データの同一場所への配置（コロケーション）という観点 から考える必要があります。 この章では、MDC 表の概要、その使用方法、どのような場合に使用するか、従来の表や 代替のパーティション方式より優れている理由は何か、などについて詳しく説明しま MDC 101: 従来の表と多次元クラスタリング表の単純な対比 25 す。この章の全体を通して、 「表面下」で行われている概念を表すために、図を使用し ています。2 次元で表示した方が概念を表しやすい場合は、そのようにしています。同 様に、多次元で表示されている場合もあります。詳しい情報については、インフォメー ション・センターまたは「DB2 UDB バージョン 8 管理ガイド」も参照してください。 MDC 101: 従来の表と多次元クラスタリング表の単純な対比 MDC 表の利点とそれがユーザー環境にもたらす貢献を最もよく理解するには、従来の表 と対比、比較してみるのが便利です。あるビジネスで3つの特定次元のデータ（つまり、 売上商品を表す関連の最小在庫管理単位（SKU） 、商品が売られた店の場所、および売上 日）に最も関心がある場合を例にとって見てみましょう。 図 2.1 は、従来の表に保管されたデータの例を示しています。 このような複数の次元のデータを従来の表を使用して編成しようとすると、何らかの制 限につき当たります。データの順序を維持して効率的な検索が行えるようにするための 最善の選択肢は、クラスタリング索引を作成して、単一次元で順序立ったデータ・アク セスが行えるようにすることです（例 : 図 2.1 に示されている NATION に基づくクラスタ リング索引）。この索引は、I/U/D 操作時に、索引の順序に従ってデータを物理的にクラ スター化します。この順序は、DB2 UDB のプリフェッチャーを使用することにより、パ フォーマンス上の利点が得られます。同種のデータが順次に保管されるので、DB2 UDBは 「ビッグ・ブロック」I/O を活用できるからです（つまり、出資に対する見返りが多いと 図 2.1 従来の表 26 第 2 章 多次元クラスタリング表 いうわけです） 。事実、クラスタリングが適切に行われていれば、NATION 属性を対象にし た照会では、表の一部分にアクセスするだけで済みます。 クラスタリング索引を使用すると、修飾する次元（この場合は、NATION）を含む範囲照 会のパフォーマンスが向上します。では、クラスタリング索引のどこがいけないので しょうか。 従来の表の最初の制限は、1 つの表に対して 1 つのクラスタリング索引しか作成できず、 他の索引はすべて非クラスタリング索引にならざるを得ないことです。NATION 次元だけ でなく、NATION と YEAR への高速アクセスに関心があるような場合、これが問題になりま す。 従来の表で考慮する必要があるもう 1 つの問題は、時間が経過すると順序付けられた データがどうなるかということです。ユーザーが表にデータ値を挿入したり、更新や削 除を行う機会があります。おそらく、それぞれのタプルに新規または重複する NATION が 含まれています（発注された商品に応じて）。ユーザーが NATION 属性を含む行を挿入す るたびに、INSERT アルゴリズムは、共通の次元値が保管されているデータ・ページを見 付けようとします。クラスタリング索引を持つ従来の表は、将来に新規データを挿入で きるように、各データ・ページの最後に一定の割合でフリー・スペースを残すように初 期設定されるのが通常です。INSERT アルゴリズムは、最初にこの場所で新規レコード用 のスペースを探します。 しかし、時間が経つにつれて、この事前割り振りされたフリー・スペースは埋め尽くさ れます。ターゲット・ページ上にスペースが見付からない場合、INSERT アルゴリズムは、 現行ターゲットのフリー・スペース制御レコード（FSCR）をら旋状に検索して、適切な データの配置を探します。 そのFSCR内でスペースを見つけることができない場合、 INSERT アルゴリズムは、通常の INSERT で使用されるのと同じ「最善（best-it-can-do）」検索 方式で、別の FSCR を検索します。検索される FSCR の個数は、MAXFSCR レジストリー変数 によって制限できます。使用可能なフリー・スペースがない場合、INSERT アルゴリズム は、最終的に表の末尾にデータを挿入します。 このことを念頭に置くと、保管された表データが時間とともにフラグメント化されて いくことがお分かりになると思います。ページ内のデータは、フリー・スペースが埋 め尽くされると、乱れた順序で配置されるようになります。これが、表の保守と再編 成が必要になる理由です（この様子は、25 ページの図 2.1 の NATION の矢印で示されて います）。その結果、クラスタリング索引に従って表を再編成し、順序を維持し、パ フォーマンスを向上させるための管理コストと可用性コストがかかることになります （ちなみに、DB2 UDB v8 では、表と索引のオンライン再編成が導入されています。詳細 については、第 15 章で説明します。この機能も役立つことは確かですが、MDC 表はこの 問題を完全に解決します）。 この例では、NATION 次元のデータのアクセスは、クラスタリング索引を通して行われま す。クラスタリング索引とは、レコード ID（RID）に基づく索引で、表内の特定の順序 付けられたエントリーを指します。通常の表の他の次元（例えば、YEAR）の索引も作成 MDC 101: 従来の表と多次元クラスタリング表の単純な対比 27 できますが、表内のデータを順序付けることはできません（そのため、25 ページの図 2.1 では、YEAR の場合は矢印が大混乱しています） 。このことは、従来方式の表に別の制 限をもたらします。RIDベースのアクセスは、ブロックID（BID）ベースのアクセスを行 うMDCと比較すると（これについては、後で詳しく学習します） 、各データ・レコードを 指示する必要があるためにパフォーマンスが低下します。これに加えて、表が非常に大 きい場合、RID索引は非常に大きくなる可能性があります（関連の基本表の中の1つ1つ の行のエントリーを持っているためです）。大きい索引を保守する必要があるだけでな く、それを保管する必要もあります。表のサイズによっては、大量のスペースを占める 可能性があります。 要約すると、従来の表と索引は、興味のある次元のデータをリレーショナルに活用す るには、パフォーマンス上および管理上の追加コストがかかります。その理由として、 単一次元についてのみクラスター化できること（サポートする必要がある他の索引は すべてクラスター化されません）、時間が経つにつれてクラスタリングが低下して保守 が必要になること、索引がレコード・ベースであること、およびそのサイズが関連の 表と相関していることなどが挙げられます。 MDC 表は、データを複数（n）の次元でエクステント境界に沿って物理的にクラスター化 することにより、こうした問題を解決します（図2.2を参照） 。本質的に、MDC表は、1つ の表に対して複数のクラスター索引を持つ能力を備えています。これはパフォーマンス の向上につながることは明らかです（分かりやすいように、図 2.2 では、データ・ペー ジを正方形で表しています） 。 図 2.2 次元 NATIONと YEAR持つ MDC表を構成するエクステント（MDC表では「ブロック」と呼ばれます） MDC 表は、新規の効率的なブロック索引もサポートします。ブロック索引は非常にコン パクトで、ブロック単位で（レコード単位ではなく）データに高速にアクセスできま す。この索引は、特定の次元値に割り振られているデータのブロックを指します。ブ 28 第 2 章 多次元クラスタリング表 ロック・ベースの索引は、表の中の 1 つ 1 つのレコードを指さないので（同一場所に配 置されたデータが格納されているブロックを指します）、RID 索引よりずっと小さく、ロ ギングや保守のためのオーバーヘッドもはるかに少なくて済みます。 新規の MDC 機能は、長時間にわたってクラスタリングを自動的かつ動的に保守するメカ ニズムを備えています。MDC 表の場合、表の再編成の実際の用途は、まばらな削除が原 因で生じたフラグメント化されたスペースを圧縮するためと、ポインター /オーバーフ ローの組み合わせをクリーンアップするためだけです。再クラスタリングのためには必 要ありません。 最後に、MDC 表を作成するための構文は、単純で柔軟です :CREATE TABLE...ORGANIZE BY DIMENSIONS(X,Y,...)。 最終成果として、さまざまな異なる照会および I/U/D 操作のパフォーマンスを向上させ る強力な方式と範囲パーティションのロールイン / ロールアウト機能のいくつかを提 供するメカニズムが得られ、これらはすべて DBA の負担を軽減し、データを保管するの に必要なリソースを削減し、高速のパフォーマンスを達成するのに大きく貢献します。 例に戻って、ビジネスの問題を見てみましょう（ビジネスを複数の次元で、しかも編 成されたコンパクトで効率的な形で、相関的（リレーショナル）に洞察したいと思い ます）。MDC では、複数の次元を作成し、その次元に従って表データを保管することが できます。ここでは、話を単純にするために、2 つ次元だけを見てみましょう。27ペー ジの図 2.2は、NATION と YEAR の 2 つの次元で編成された MDC 表を示しています。 27 ページの図 2.2 を見ると、表が 2 つの次元で編成されていることが分かります。DBA は、MDC 表の宣言の中で、次元 NATION と YEAR で表を編成するように指定したことになり ます。27 ページの図 2.2 では、宣言された対象データの固有の組み合わせごとに、そ れ専用のブロックに割り振られていることが分かります（ブロックとは、同じ次元値 を持つレコードを格納するデータ・ページのエクステントのことです）。 MDC を使用しない場合、対象の両方の列に対する索引を保持する必要がありますが、そ のうちの 1 つしかクラスター化できません（25 ページの図 2.1 のように）。NATION='CANADA' の分析のために要求が出された場合、DB2 UDB は NATION='CANADA' のオカレンスをす べて検出するために、多数のエクステントにアクセスすることが必要になります。DB2 UDB は、MDC 表を使用して、異なる次元値を持つ行を別のデータ・ページまたはブロッ クに保管します。すべての次元に同じ値を持つ行だけをまとめて 1 つのブロックに保管 します。データベース・マネージャーに対して NATION='CANADA' を条件とした SELECT が出 された場合、DB2 UDB は、その次元値を持つ行を含んでいるブロックを検索するだけで 済みます。行が挿入、更新、または削除されるたびに、DBA のために、このすべてが DB2 UDB によって自動的に保守されます。 MDC 表を理解するために必要な用語 29 MDC 表を理解するために必要な用語 このテクノロジーの使用法とその詳しい内容を見る前に、MDC 表について説明する際に 使用される用語を理解しておくことが大切です。ここでは、この章で使用されている 主な用語を取り上げ、簡単に説明します。その後で、それぞれの用語の詳しい内容と その使用法について説明します。 MDC 表 MDC 表とは、データが複数の表列（または、次元）で同時に物理的にクラスター化され る表です。この表は、標準 CREATE TABLE ステートメントで ORGANIZE BY DIMENSIONS 文節を 使用して作成します。 次元 特別に定義された対象領域を表し、表の作成時に指定します。MDC の次元は、表のクラ スタリング・キーです。特定の次元値を持つデータは、後述のキューブ図の中で、そ の次元の軸によって見つけることができます（キューブは、データが 3 つの次元を持つ MDC 表に編成される様子を概念的に表す簡単な方法です。図 2.3 を参照）。MDC 表の使用 は、OLAP タイプの操作に役立ちますが、ここでの次元という用語は、多次元データベー スには関係がないことを覚えておいてください。ここでの次元とは、ディスク上に一 緒にまとめて保管される同種データを表します。 図 2.3 NATION、COLOR、および YEAR 次元で編成された表 30 第 2 章 多次元クラスタリング表 スライス スライスは、MDC 表の作成時に指定されたクラスタリング次元の 1 つと同値のデータを 持つページを含んでいるブロックの集合です。例えば、表の作成時に指定された次元 が NATION であり、そのデータ配分がとる値の 1 つが 'CANADA' であった場合、MDC 表のス ライスは図 2.4 のようになります（図 2.4 では、値の範囲に 'MEXICO' が含まれているた め、NATION 次元の一部として別のスライスが含まれていることに注意してください）。 図 2.4 NATION、COLOR、および YEAR 次元で編成された表、値'CANADA' がスライスを構成 特定次元の任意の値が表のスライスを定義し、そのスライスには、表内のその特定次 元の値を持つデータのすべて、しかもそのデータのみが含まれます。 データのスライスは、次元値の個数と同じ数だけ存在します。例えば、31 ページの図 2.5 は、値が 'YELLOW' の COLOR スライスを示しています。このスライスは、図 2.4 に示さ れたスライスと部分的にオーバーラップしていることに注意してください。これは、一 部のレコードは 'CANADA' の NATION と 'YELLOW' の COLOR の両方を持っており、その他のレ コードは持っていないことを示しています。 MDC 表を理解するために必要な用語 31 図 2.5 NATION、COLOR、および YEAR 次元で編成された表、値'YELLOW' がスライスを構成 セル 次元値の固有の組み合わせが、それぞれ 1 つの論理セルを構成します。物理的には、セ ルは各クラスタリング列にまったく同じ値を共有するレコードのみを含むページの 1 つ以上のブロックで構成されます（ここでは、話を単純にするために、特定セルのデー タはすべて 1 ブロックのデータ・ページに収まるものと想定しています）。セルは、固 有の次元値セットを持つデータ値を含んでいる表の部分、つまり、各次元からスライ ス を 取 る こ と に よ っ て 形 成 さ れ る 交 点 で す。例 と し て、次 元 値 NATION='CANADA'、 COLOR='YELLOW'、および YEAR='1997' の組み合わせを、32 ページの図 2.6 に示します。図 のセルは、定義された次元のこれらの特定属性によって指定されたデータのみを格納 します。 32 第 2 章 多次元クラスタリング表 図 2.6 値 'CANADA'、'YELLOW'、および '1997' を持つデータのみを含むセル（ディスク上でデータ・ペー ジの 1 つ以上のブロックを構成） ブロック ブロックは、ディスクの連続したページの集合です。MDC 表について論じる場合、エク ステントという用語はブロックと同義です。多次元表は、指定された次元値の固有の組 み合わせごとにブロックを割り振り、ブロックを埋めていきます。指定の次元値の組 み合わせに対して複数のブロックが必要な場合は、複数のブロックを割り当てて、同 種データを格納します。特定のセル値を持つレコードが存在しない場合は、それに対 してブロックを割り振る必要はないことに注意してください。ほとんどの場合、ブロッ クはレコードを含んでいるセルに対してのみ割り振られます。 ブロック・サイズまたはブロック化因数 ブロック・サイズまたはブロック化因数は、1 ブロックのページ数を指定します。これ は、表スペースのエクステント・サイズに等しくなります。この因数は、データをディ スク上に配置する方法に関して、MDC ソリューションでは重要な役目を果たします。ブ ロック化因数を大きくすると、特定の次元を持つレコードを格納するために表に新規 ブロックを追加するたびに、大きなスペースが割り振られることになります。カーディ ナリティーが非常に高いデータに対して大きいブロック化因数を割り当てるのは得策 ではありません。 MDC 表を理解するために必要な用語 33 ブロック索引 ブロック索引は、従来の RID 索引と同じ方法で構造化された新規の索引ですが、リー フ・レベルで、キーが RID の代わりに BID を指す点が異なっています。このことは、ブ ロック索引のサイズは、RID ベースの索引に比べると非常に小さいことを意味していま す。ブロック索引はブロック番号を指すのに対して（ブロックには同じ次元値を持つ レコードが多数含まれています）、従来の索引はそれぞれのデータ・レコードを指すエ ントリーを含んでいるためです。次元ブロック索引の例を図 2.7 に示します。この図 では、次元 'CANADA' は 12 個の異なるブロックに保管されたデータを持っていることが 示されています。 ブロック索引が特定のブロック番号を指している様子に注意してください。これらは、 この例の場合は値 'CANADA' を含むデータが保管されているブロックです。特定次元に対 するブロック索引は、次元ブロック索引と呼ばれます。この索引にリストされているブ ロックは、論理的に30ページの図 2.4の 'CANADA' スライスに対応しています。本書の例 では、もう 1 つ別に NATION = 'MEXICO' という次元値があります。'MEXICO' は、それ専用 の次元 BID リスト（図 2.7 と同様の）を持っています（ただし、当然のことですが、 'CANADA' の代わりに NATION ='MEXICO' を含むブロックへのポインターを持っています） 。 ブロック・ベースの索引は、DB2 UDB オプティマイザーが照会のための可能なアクセ ス・プランを決める際に、RID ベースの索引とまったく同様に考慮されます。処理時に も RID 索引とまったく同様に扱われます。ブロック索引を相互に、あるいは他の RID 索 引とともに、AND または OR 演算したり（この概念については後述します）、索引を逆ス キャンしたりできます。 次元ブロック索引は、MDC 表の作成時に次元ごとに自動的に作成されます。この索引は 除去することができません。ただし、名前を変更することはできます（各索引にシステ ム生成名が割り当てられます） 。索引の名前変更の機能は、DB2 UDB v8.1の新機能です。 ブロックID BID は、ブロック索引のリーフ・ノードにキー値とともに保管され、MDC 表の特定のブ ロックを参照します。BIDは、図2.7では、NATION キー 'CANADA' の右側に示されています。 参照された次元のBIDの集合は、BIDリストと呼ばれます。 図 2.7 次元 NATIONに対するブロック索引の例 34 第 2 章 多次元クラスタリング表 生成列 生成列とは、表内の1つ以上の列を含む式から派生する列を言います。生成列は、DB2 v7 以来DB2 UDBでサポートされています。これを使用すると、次元の細分性を制御したり、 次元値をロールアップして粗い表現にし、ブロック化の効率を高めたりすることができ ます。例えば、カスタマー番号の範囲をインプリメントする場合、次元 CUSTGROUPID='1' は値 1 から 100 を表し、次元 CUSTGROUPID='2' は、値 101 から 200 を表すというように設定 します。これは、カスタマー IDごとに1ブロックを割り当てるよりも適切な方法です（カ スタマーがユニーク列であった場合） 。 単調性 プリンストン大学（WordNet v1.6 ©1997）では、単調性（monotonicity）とは「（数学 の）順序または関数において、値が一貫して増加して決して減少しないこと、あるい は一貫して減少して決して増加しないこと」と定義しています。 例えば、関数 B = A/100 は、単調式です。値の集合 A = 1、10、250、378 をこの関数に 当てはめると、結果の B’ の近似値は、それぞれ 0、1、2、3 となります。A の値が増加 するにつれて、B の値が減少することは決してないので、式 B = A/100 は単調であると 判断できます。 非単調式の例としては、関数 B = month(date) があります。この関数への入力が、集合 （1999/03/03、1999/05/17、2000/02/01、2001/05/04）である場合、結果値はそれぞれ （03、05、02、05）になります。お分かりのように、日付は先に進んでいますが、month(date) 値は、先に進んだ後、循環して低い値になり、それぞれの値はその年の月を表してい ます。 単調性は、MDC では、範囲スキャンの場合に重要です。これについては、後で詳しく学 習します。ここでは、用語の意味だけを理解してください。 MDC 表の働き MDC では、同時に複数の次元に基づいて表を物理的にクラスター化することができま す。MDC 表を使用しない場合、DB2 UDB はクラスター索引を使用してデータの単一次元 クラスタリングを相関的（リレーショナル）にサポートできるにすぎません。MDC を使 用すると、この利点を複数の次元またはクラスタリング・キーに拡張できます。 照会のパフォーマンスに関しては、表の指定された次元の 1 つまたは組み合わせを含む 照会は、クラスタリングから恩恵を受けます。これらの照会は正しい次元値を持つレ コードを含むデータ・ページにのみアクセスするだけでなく、修飾ページが同一場所 に配置されるようにもなります。さらに、クラスタリング索引を使用した表では、時 間とともに表のスペースが埋め尽くされてクラスター化されない状態になることがあ りますが、MDC 表の場合は、すべての次元のクラスタリングを自動的かつ継続的に保守 MDC 表の働き 35 することができるので、データの物理的順序を整えるために表を再編成する必要があ りません。 DBA は、表の作成時に、表のデータをクラスター化する次元として、1 つ以上のキーを 指定できます。それぞれの次元は 1 つ以上の列から構成され、これは索引キーの場合と 同様です。事実、指定された次元ごとに次元ブロック索引が自動的に作成され、それ を使用して各次元のデータに高速かつ効率的にアクセスできます。複合ブロック索引 も自動的に作成される場合があります（指定された次元のすべての列がすでに組み込 まれている次元が存在する場合は、複合ブロック索引は作成されません）。この索引に はすべての次元キー列が含まれており、INSERT および UPDATE アクティビティーの間に データのクラスタリングを保守するのに使用されます。 次元値のユニークな組み合わせが、それぞれ 1 つの論理セルを形成します。論理セル は、物理的にはデータ・ページの 1 つ以上のブロックから構成されます。ここで、ブ ロックとは、ディスク上の連続したページの集合のことです。次元ブロック索引の 1 つ の特定キー値を持つデータを含むページを格納しているブロックの集合を、スライス と呼んでいます。表の各ページは 1 つだけのブロックに格納され、表のブロックはすべ て同じページ数（ブロック化因数）から成っています。ブロック化因数はエクステン ト・サイズに等しいので、ブロック境界はエクステント境界と整列します。 話を単純にするために、2 つの次元を持つMDC表内のブロックを見てみましょう。36ペー ジの図 2.8 は、YEAR と NATION の 2 つの次元でクラスター化されている MDC 表の論理図で す。表内のレコードはブロック単位で保管され、ブロックにはエクステントに相当する ディスク上の連続したページが保管されています。36 ページの図 2.8 では、ブロック は長円形で表され、表に割り振られたエクステントの論理順序に従って番号が付けられ ています。例えば、ブロック1、6、12には、year '2001' と nation 'CANADA' を持つ行の みが含まれています。 36 ページの図 2.8 の格子はこれらのブロックの論理区画を表し、正方形はそれぞれ論 理セルを表します。格子内の列または行は、特定の次元のスライスを表します。例え ば、NATION 次元に値 'CANADA' を含むレコードは、すべて格子内の 'CANADA' 列によって定 義されたスライスに含まれているブロック内で見付かります（ブロック 1、3、5、6、7、 8、10、12、13、14、32）。事実、このスライスの各ブロックには、NATION フィールドに 'CANADA' を持つレコードのみが入っています。このように、ブロックが NATION フィール ドに 'CANADA' を持つレコードを含んでいる場合、しかもその場合にのみ、ブロックは格 子のこのスライスまたは列に含まれています。 36 第 2 章 多次元クラスタリング表 図 2.8 2 次元 MDC 表 MDC 表の作成 MDC 表の作成は、容易で柔軟です。構文は、DB2 UDBの CREATE TABLE データ定義言語（DDL） の単純な拡張です。MDC 表の作成に使用される DDL については、第 17 章の「SQL の機能 強化」で詳しく説明します。 YEAR、NATION、および COLOR の情報を含む従来の表を作成する DDL は（前述の定義のセク ションの例に示したように）、次のようになります。 CREATE TABLE NOTMDC (YEAR INT NOT NULL, NATION VARCHAR(25) NOT NULL, COLOR VARCHAR(25) NOT NULL) MDC 表を作成するには、表を編成する次元を定義する ORGANIZE BY DIMENSIONS 文節を追加 するだけです。作成時には、表を編成するための次元の選択には十分に注意してくだ さい（詳しくは、この章の後方の「MDC 表の次元の選別」のセクションを参照してくだ さい）。MDC 表の次元を定義した後は、表を除去して再作成しない限り、次元を変更す ることができません。前の例の表を MDC 表として作成するには、次のコマンドを入力し ます。 MDC 表の働き 37 CREATE TABLE MDC (YEAR INT NOT NULL, NATION VARCHAR(25) NOT NULL, COLOR VARCHAR(25) NOT NULL) ORGANIZE BY DIMENSIONS (YEAR, NATION, COLOR) RUNSTATS ON TABLE MDC ON ALL COLUMNS MDC 表の次元の集合には、最大 16 の異なる列を組み込むことができます。 T I P 次元は、索引キーの定義であるため、実際には複合キーを持つ ことができます。例えば、対象の 2 つの次元が YEAR と NATION である場合、次の方法で次元を結合することができます : CREATE TABLE . . . ORGANIZE BY DIMENSIONS ((YEARandNATION)) 他のパーティション方式（例えば、他のデータベース・ベンダーによって実装された 「リスト」または「範囲」によるパーティション方式）とは異なり、次元値の範囲また はリストを明示的に定義する必要はなく、またデータの範囲が変更されたときに既存の 次元に新規の範囲境界値を追加する必要もありません。インプリメンテーションが容易 になることは管理者の夢です。このことについて少し考えてみましょう。多くのDBAは、 データのパーティション（または、範囲）に容易にロールイン、ロールアウトできると いう理由で、範囲パーティションの概念を好んで使用しています。例えば、1999 年の第 1 四半期（Q1Y99）の売上は、2 年間関係があるとすると、2 年後の時点でロールアウト する必要があります。ロールアウトごとに、それに関連した新しい四半期と年の組み合 わせに対する新規のロールインが生じます。この技法には、多くの利点がありますが、 顕著な欠点があります。問題は両方とも MDC表によって解決できます。 最初の問題は、範囲パーティションは、ディスク・サブシステムにホット・スポット を生じることがあることです。例えば、DBA は、QY データを各パーティションに広げて 配置するのが一般的です。Q1Y99 はパーティション 1、Q2Y99 はパーティション 2 という ように配置します。さて、最新の四半期データが使用可能になると、誰もがそのデー タを見たいと思い、すべてのユーザーが最新の QY に対する範囲述部または同等述部を 含めた検索を行うことが予想されます。このような照会はすべて 1 つのノードに送ら れ、そのノードが所有するデータに対する要求を処理します。その間、他のノードは アイドル状態になります。そのため、範囲パーティションでは、しばしばパフォーマ ンスの問題が起こります。DB2 UDB によって実装されたハッシュ・パーティション方式 では、このような問題は起こりません。データベースの各パーティションは、パーティ ション・キーによって記述されたデータ・セットの断片を所有するからです。MDC と DB2 UDB Enterprise Server Edition のデータベース・パーティション・フィーチャーを組 み合わせて使用すれば、複数の表にわたってハッシュされる、あるいは前述の例を反 映するように分離されている、範囲パーティションを作成できます。 38 第 2 章 多次元クラスタリング表 2 番目の問題は、範囲パーティションは操作上の使いやすさ（ロールイン、ロールアウ ト）がありますが、管理上および集計上のトレードオフ・コストを伴います。次のデー タ定義言語（DDL）は、DBAが異なるベンダーのデータベースを使用して範囲パーティショ ンを作成する方法を示しています。 CREATE TABLE PART1 (Date DATE, Province PARTITION BY RANGE ( Date) (PARTITION cell1 VALUES LESS THAN PARTITION cell2 VALUES LESS THAN PARTITION cell3 VALUES LESS THAN PARTITION cell4 VALUES LESS THAN ...) CHAR(2), Color VARCHAR(10), ... ) (1999/02/01) (1999/03/01) (1999/04/01) (1999/05/01) TABLESPACE TABLESPACE TABLESPACE TABLESPACE TB1, TB2, TB3, TB4, この構文は、非常に繁雑で、長たらしくなることに注意してください。そのうえ、非 常に拡張性に富んでいるというわけでもありません。前もって現在と将来のデータを すべて扱えるように工夫する必要があります。例えば、新しい範囲を作成したい場合、 これを DDL レベルで行う必要があり、表を作成したり除去したりすることが必要になる 可能性があります（新しい色が追加された場合を想像してください。そのための新規 の範囲パーティションを手動で追加することが必要になります）。MDC 表を使用した場 合は、次元値を含むデータ行が表に挿入されると、新しい次元ブロックが動的に割り 振られます（ブロックが存在する場合は、事前割り振りされたブロックに入れられ、存 在しない場合は、ブロックが自動的に作成されます）。もう 1 つの例は、DBA がハイエン ドで「キャッチ・オール」範囲を作成し、時間の経過につれて、それを分割して新た に複数の範囲に分けることが必要になるような環境の場合です。 企業がデータからより的確な洞察を引き出したい場合はどうでしょう。通信会社 （telco）が月ベースで電話の通話をスキャンして、新しい消費者のぜい弱性モデルを 開発したいとします。これは簡単です。12 個の範囲です。では、会社がオペレーショ ナル・データ・ストア（ODS）を増設して、情報の処理を日ベース（この場合、365 個 の範囲を管理する必要があります）、さらに時間ベース（8,760 個の範囲）にしたい場 合はどうでしょうか。これで、私の言いたいことはお分かりいただけたと思います。 索引と MDC 表 MDC 表では、自動的に作成できる索引が 2 種類あります。次元ブロック索引と複合ブロッ ク索引です。1 つだけ次元を定義して MDC 表を作成した場合、あるいは MDC 表に複合次 元を定義し、それにのみ基づいて表を編成するように指定した場合、複合ブロック索 引は作成されません。それ以外の場合は、指定された各次元ごとに次元ブロック索引 が作成され、加えて複合ブロック索引も作成されます。 これらの索引タイプは、どちらも RID ベースの索引ではなく、ブロック・ベースの索引 です。ブロック索引は、通常のレコード索引と構造的には同じですが、レコードの代わ りにブロックを指します。その結果、ブロック索引は RID 索引よりずっと小さくなりま MDC 表の働き 39 す。例えば、RID索引の場合は、従来の表内の各レコードごとに1つのポインターが存在 しますが、MDC表では、各ブロックごとに1つのポインターが存在するだけです。このよ うにスリムな索引は、高速のパフォーマンスと低い保守コストにつながります（MDC 表 は、ロールイン、ロールアウトに特に適しています）。ブロックのサイズは、エクステ ント内のページ数に等しくなります。この値は、2から256ページの間に設定でき、その デフォルト値はデータベースの作成時に定義され、オーバーライド値は表スペースの作 成時に定義できます。 次元ブロック索引 次元ブロック索引は、MDC表のスライスを構成するブロックを判別しやすくします。次 元ブロック索引は、表の作成時に自動的に各次元ごとに作成され、その MDC 表のために システムが必要とします。 36 ページの図 2.8 では、ブロック 1、6、12 は、NATION 次元ブロック索引の 'CANADA' キー によって示されます。 前節で DDL の例を示した表 MDC を考えてみましょう。この表を作成したら、次の DML ス テートメントを実行します。 INSERT INTO MDC VALUES (1997, 'CANADA', 'YELLOW'), (1997, 'MEXICO', 'YELLOW') ここで、次の DML ステートメントを発行します。 SELECT * FROM MDC WHERE NATION = 'CANADA' この DML は、YEAR = 1997, NATION = 'CANADA', COLOR = 'YELLOW' の 1 行を表示した単一結 果セットを生成します。この情報に DB2 UDB エンジンがアクセスした方法を見るのは、 さらに興味深いことです。前の SELECT ステートメントに対して Visual Explain を実行 してみるために、コントロール・センターを開始し、作成した MDC 表が常駐するデータ ベースを右クリックして、「SQL の EXPLAIN」を選択します。SQL テキスト・ボックスに SQL ステートメントを入力して、「OK」を選択します。40 ページの図 2.9 と同様の出力 が表示されます（環境によって異なることがあります）。 40 ページの図 2.9 で、照会を解決するために使用された索引（40 ページの図 2.9 の枠 で囲まれている部分）に注意してください。ここで、次の SQL ステートメントを発行し て、索引のタイプを調べます。 SELECT INDEXTYPE, INDNAME FROM SYSCAT.INDEXES 受け取る出力は、40 ページの図 2.10 のようになります。 40 図 2.9 単一次元の MDC 表からのSELECT の Visual Explain 図 2.10 次元ブロック索引を通した MDC 表内のデータへのアクセス 第 2 章 多次元クラスタリング表 MDC 表の働き 41 40 ページの図 2.10 の DIM キーワードに注意してください。このキーワードは、要求さ れた情報に次元ブロック索引を通してアクセスしたことを示しています（これらのブ ロック ID ベースの索引を覚えておいてください。データが置かれているブロックを指 しています）。ここでの重要な利点は、MDC では修飾行と非修飾行が混在するページに アクセスするのが通常である大量のランダム I/O や順次 I/O（あるいは、その両方）を 回避できるということです。要するに、MDC は、対象データの保証付きビッグ・ブロッ ク読み取りのようなものです。 この例を完了させるために、やはり前節に DDL を示した NOTMDC 表に対して、まったく同 じ INSERT DML ステートメントを実行してみます。MDC の例で行ったのと同じステップを 実行しますが、SELECT ステートメントを発行する前に、次のコマンドを実行して NOTMDC 表に対する索引を作成します。 CREATE INDEX IDXNATION ON NOTMDC(NATION) NOTMDC 表に対する SELECT ステートメントに対して Visual Explain を実行してみると、 表 へのアクセスには REG（通常）索引が使用されたことが分かります（索引は、システム 名の代わりに、CREATE INDEX ステートメントで指定した名前で表示されます。DB2 UDB v8.1 では、必要な場合は、MDC 索引の名前を変更できます）。 ブロック索引は、ブロックを指すだけで済み、個々のレコードを指す必要はないので、 RID 索引よりずっと小さくなります。各ブロックに 1,000 のレコードを保管できる場合 を想像してください。MDC の場合、そのブロックへの 1 個の索引エントリーが必要です。 RID の場合は、1,000 個のエントリー（各レコードごとに 1 つずつ）が必要になります。 実際に、次元ブロック索引は、次の係数で縮小します。 ブロック・サイズ * ページ内の平均レコード数 ここで、ブロック・サイズ = エクステント内のページ数（2–256） 。 索引がずっと小さくなるので、クラスタリング索引を使用する場合に比べて、データ へのアクセスがはるかに高速になります。次元ブロック索引では、修飾するページ・ブ ロックにつき 1 ポインターが存在するのに対して、クラスタリング索引では修飾行につ き 1 ポインターが存在するからです。ブロック索引から BID が与えられると、DB2 UDB は、表内の対応するブロックのスキャンを非常に効率的に実行できます。 繰り返しますが、次元ブロック索引は、MDC 表で指定された各次元ごとに作成されます。 したがって、本書の MDC 表の例の場合は、YEAR、NATION、COLOR 次元のそれぞれに対して 次元ブロック索引が自動的に作成されます。これらの索引を図で示すと、32 ページの 図 2.6 の三角形をそれぞれ次元ブロック索引と見なすことができます。 各次元ブロック索引は、リーフ・レベルでキーが RID の代わりに BID を指す点を除いて、 従来の RID 索引と同じ方法で構造化されます。そのため、ブロック・ベースとレコー ド・ベースの索引を MDC 表に共存させて、相互作用させることができます（これについ ては、すぐ後で詳しく説明します）。各ブロックには多数のレコード・ページを含める 42 第 2 章 多次元クラスタリング表 ことができるので、ブロック索引はレコード索引よりずっと小さくなり、それを更新 する必要があるのは、新規ブロックが必要になってセルに追加された場合、あるいは 既存のブロックが空になってセルから除去された場合に限られます。 スライス（つまり、次元に特定のキー値を持つレコードのみを含むページが格納され ているブロックの集合）は、関連の次元ブロック索引内にそのキー値の BID リストに よって表されます。 そこで、この例では、NATION 次元に 'CANADA' を持つすべてのレコードを格納しているブ ロックのスライスを見つけたいと思います。これを容易に達成するために、DB2 UDB は、 NATION 次元ブロック索引でこのキー値を検索して、図 2.11 に示されているような該当 のキーを見つけます。 図 2.11 のキーは、キー値（つまり、'CANADA'）と BID のリストから構成されています。 各 BID には、ブロックのロケーションが入っています。この例では、リストされたブ ロック番号は、36 ページの図 2.8 に示された MDC 表の格子内の 'CANADA' スライスで見 つかったものと同じであることが分かります。 次元ブロック索引は、指定された各次元ごとに自動的に生成（および、保守）される ことを思い出してください。したがって、同様に YEAR 次元に '1997' を持つすべてのレ コードを格納しているブロックを見つける場合は、DB2 UDB は YEAR 次元ブロック索引で この値を検索します。 次元ブロック索引は、RID ベースのクラスタリング索引と一緒に使用することはできま せん（通常の索引とは一緒に使用できることを覚えておいてください）。もっとも、MDC 表ではクラスタリングが保証されるので、MDC 表にはクラスタリング索引は必要ないこ とになります。ブロック索引は RID 索引と一緒に使用することができ、DB2 UDB オプティ マイザーは、照会のアクセス・プランを生成する際に、索引の AND および OR を行うこと によって、それらの使用を個別に、あるいは相互を合わせて検討します（詳細につい ては、この章の後方の該当するセクションを参照してください）。 図 2.11 NATIONに対する次元ブロック索引からのキー MDC 表の働き 43 複合ブロック索引 複合ブロック索引は、MDC 表に定義されたすべての次元の組み合わせを形成するブロッ クへのポインターから構成されます。したがって、このブロック索引は、表のすべて の次元列に対する索引であり、各キー値は表内の特定のセルに対応し、BID リストはそ のセルを構成するブロックのリストに対応しています。 複合ブロック索引は、セル値を各セルのブロック・リストにマップします。そのキー は、次元に含まれるすべての列から構成されます。したがって、この例における 3 つの 次元を持つ MDC 表の場合は、4 つの索引が作成されることになります。各次元（YEAR、 NATION、COLOR）ごとに 1 つの次元ブロック索引と、NATION、YEAR、および COLOR を対象に した複合ブロック索引が 1 つです。DB2 UDB は、この索引を使用して、特定のセルが存 在するかどうか、存在する場合は、そのセル値が正確にどのブロックに含まれている かを、非常に迅速に判別できます。 その次元値のセルが存在するかどうかを DB2 UDB が速やかに判別できることから、複合 ブロック索引は主として INSERT 操作に使用されます。また、MDC 表内の次元がすべて組 み込まれた述部を使用した照会や、その他の照会（特に、最初のキー部分の順次サブ セットが含まれている場合）にも使用されます。 次の照会に対して Visual Explain を実行して、DB2 UDBが、要求された結果セットを取 り出す際に複合ブロック索引の使用を選択する様子を見てみましょう。 SELECT * FROM MDC WHERE NATION = 'CANADA' AND COLOR = 'YELLOW' AND YEAR = 1997 次元ブロック索引の使用を調べたときと同じ手順に従うと、索引の使用状況の出力は その Visual Explain と一致していることが分かり、代わりに複合ブロック索引が使用 されています（44 ページの図 2.12 に BLOK として示されています）。図 2.12 には、NOMDC 表に作成するように求めた IDXNATION 索引も表示されています。 複合ブロック索引の場合、キーは、表内のレコードを含んでいる各セルでのみ検出さ れます。このブロック索引は、次元の特定の値セットを持つレコードを含んでいるブ ロックを高速かつ効率的に検索するのに役立ちます。また、INSERT アクティビティーの 過程で、表の次元に従ってデータの物理的クラスタリングを動的に管理・保守するの にも使用されます。 44 第 2 章 多次元クラスタリング表 図 2.12 すべての次元の照会に複合ブロック索引を使用 例えば、表の中から NATION が 'CANADA'、COLOR が 'YELLOW'、YEAR が '1999' であるすべての レコードを検索したい場合、DB2 UDBは、複合ブロック索引で各次元のキー値 'CANADA'、 'YELLOW'、'1999' を検索し、それぞれに一致するブロックを見つけます。この操作を図 2.13に示します。 図 2.13 複合次元ブロック索引 MDC 表の働き 45 この場合も、キーは各次元のキー値（つまり 'CANADA、YELLOW、1999'）と、このデータ を格納するブロック（データ・ページのエクステント）を識別する BID のリストから構 成されます。リストされたBIDは52と292だけであることが分かり（述部NATION='CANADA'、 COLOR='YELLOW'、および YEAR='1999' に対して） 、これは、MDC 表の中にはこの 2 つの特定 値を持つレコードを含んでいるブロックは 2 つしかないことを示しています。 索引の操作 ブロック索引を相互に、あるいは RID ベースの索引と一緒に、結合（AND、OR）すること ができます。これらの操作を実行すると、クラスター化されたデータ・アクセスを提供 しながら、高速スキャンのために対象データを含むブロックを迅速に識別することがで きます。このセクションでは、このような操作の例を示します。 索引 AND ブロックの AND は、次元ブロック索引を使用してデータのスライスを結合し、対象デー タを含む結果セットに高速かつ効率的に到達することを可能にします。次の照会を考 えてください。 SELECT * FROM MDC WHERE COLOR='YELLOW' AND NATION='CANADA' DB2 UDBオプティマイザーは、AND を使用して、値 'YELLOW' と 'CANADA' を含む結果のデー タ・ブロックに高速かつ効率的に到達します。これらの値は、この例の MDC 表に定義さ れた次元であるため、DB2 UDB は、これらの次元にはブロック索引が存在することを認 識しており、結果セットに到達するためにそれを使用することを選択します。前の照 会では、DB2 UDB は次元ブロック索引（2 つの索引を AND したブロック）に基づく索引検 索を行い、結果ブロックに対するミニ・リレーショナル・スキャンを実行して、大き なパフォーマンス上の利益を生んでいます。これを図 2.14 に示します。 図 2.14 MDCを使用して迅速に結果を得るための次元ブロック索引の AND 46 第 2 章 多次元クラスタリング表 MDC 表の作成時に次元として定義されなかったビジネス値に対して索引を作成したと考 えてください。例えば、最小在庫管理単位（SKU）のマテリアライズ集約または変換を 生成しなかった場合、それは次元として選択するのは適切ではありません（SKU 数が 100,000のときに、SKUを次元にすることを想像してください。結果は100,000ブロック になります!） 。 前述のように、DB2 UDB ではブロック・ベースの索引と RID ベースの索引を一緒に活用 できます。ブロック・ベースと RID ベースの索引を AND する、次のような照会を考えて ください。 SELECT * FROM MDCTABLE WHERE COLOR='YELLOW' AND SKU-# >= 1000 DB2 UDBは、図 2.15 のように、この照会を処理します。 図 2.15 MDCを使用して迅速に結果を得るための次元ブロック索引とRID索引の AND 結果セットには、修飾ブロックに属する RID のみが含まれます。 索引 OR DB2 UDB では、AND 技法を使用するのと同様に、索引の OR を使用して結果セットに到達 することもできます。DB2 UDB オプティマイザーがこのタイプの演算を使用することに 決めるには、言うまでもなく、照会に OR 述部が含まれていることが必要です。そこで、 次のような照会を考えてみましょう。 SELECT * FROM MDCTABLE WHERE COLOR='YELLOW' OR SKU-# >= 1000 この照会は、47 ページの図 2.16 に示すような方法で処理されます。 MDC 表の働き 47 図 2.16 MDCを使用して迅速に結果を得るための次元ブロック索引とRID索引の OR 結果セットには、修飾ブロック内のすべてのレコードに加えて、OR 条件があるために、 これらのブロックの外部にある追加の RID も含まれています。勿論、DB2 UDB では、AND の例で示したのと同様に、2 つの次元ブロック索引の OR 演算を行うこともできます（照 会に応じて）。 このように、MDC表の索引の利点の 1つは、DB2 UDB がブロック・ベースおよび RID ベー スの索引を利用して、表内の特定の次元値または値の範囲を持つ部分を高速かつ容易 に絞り込めることです（ブロック除去）。ブロック索引は小さく、ブロックのリレー ショナル・スキャンは RID ベースの検索より高速であるため、非常に高速で索引検索を 行いながらこの絞り込みを達成できます。MDC 表は、ブロック先読みプリフェッチと呼 ばれる、プリフェッチのパフォーマンスを機能強化する新方式を備えています。この 方式は、順次に検出せずに、前もってブロック索引をスキャンして、データのブロッ ク全体をメモリーに読み込みます。データは次元に基づいてクラスター化されること が保証されているので、データの検索がはるかに高速になります。ブロック索引の存 在は、従来のアクセス・プラン（RID スキャン、結合、表スキャンなど）の使用を妨げ ることなく、DB2 UDB オプティマイザーにアクセス・プランの選択肢を追加します。 MDC と照会の SELECT、INSERT、UPDATE、DELETE 操作 このセクションでは、リレーショナル表に対して実行される各種の処理操作と、MDC 表 によるその処理方法を見てみます。 SELECT 操作 MDC 表は、幅広い照会でオプティマイザーが評価対象にできる効率的な代替アクセス・ プランを提供します。該当する照会には、スター型結合を持つ照会と、範囲、同等、お よび IN 述部を持つ照会が含まれます。 スター型結合の例としては、クラスタリング次元が次元表の 1 つ以上の外部キーである ような MDC ファクト表を考えてください。この場合、オプティマイザーは、次元ブロッ 48 第 2 章 多次元クラスタリング表 ク索引（サイズが小さい）を使用して、次元表に結合するレコードを含んでいる修飾 ブロックのリストを高速で検索できます。必要な場合は、ブロック索引の AND を使用し て、それらのブロック内の行のミニ・リレーショナル・スキャンを実行することもで き、RID ベースのフェッチに比べると、行の検索がはるかに効率的になります（特に、 新規ブロックの先読みプリフェッチを考慮に入れた場合）。これに加えて、DB2 UDB v8.1 のバッファー・プールはブロック・ベースのオプションを備えており、ブロック化因 数と同じサイズに相当するブロック単位でプリフェッチを行うことができます。 非スター型結合の場合は、1 つ以上の範囲述部または同等述部の項が MDC 次元に相当し、 オプティマイザーは、RID処理の代わりにブロック処理を行うことを選択し（必要な場 合は、ブロックの AND を使用して）、スキャンする修飾レコードの大きなブロック数の 小さいセットを高速で絞り込むことができます。 このように、 DB2 UDBはブロック索引を使用して非常に効率的にデータにアクセスでき、 信じられないような SELECT パフォーマンスを達成できる可能性があります。DB2 UDB が ブロック索引を使用するとこれほど効率的になる理由は、ブロック索引から BID を受け 取ると、そのブロックの最初のプール・ページが分かるため、直接そのページに進み、 ページ・ブロック全体をスキャンできるからです。DB2 UDB では、 これらのページで見つ かったレコードは、 見つかったブロック索引キーの次元値を持っていることが保証され ます。 各BIDはその次元値を持つデータを含むことが保証されている表内の順次ページ・ セットに対応しているため、 次元索引に基づくスキャンでは、 クラスター化されたデー タ・アクセスが行えます。 データのブロック （範囲または同等、 IN など） を含むプランの場 合は、 クラスター化されたアクセスが可能です。 MDC 表に対する SELECT での DB2 UDB の処理を見てみましょう（この処理の大部分は「索引 と MDC 表」の節で明らかになったはずですので、 ここでは簡単に述べるにとどめます。 まだよく理解できていない場合は、このセクションを読み直してください）。ユーザー は次の SELECT ステートメントを実行したいものと仮定しましょう（これは、索引の AND の 最初の例で使用したのと同じものです）。 SELECT * FROM MDC WHERE COLOR='YELLOW' AND NATION='CANADA' MDC 表の働き 49 この照会を処理するには、まず DB2 UDB は、COLOR 次元ブロック索引内で YELLOW キーを検 索して、データのスライスに対応する該当のキーを見つけて、COLOR が 'YELLOW' に等し いすべてのブロックを含んでいるスライスを判別します（図 2.17 を参照）。 図 2.17 MDC表の修飾データの最初のブロックの識別 次に DB2 UDB は、NATION 次元ブロック索引内で CANADA キーを検索し、データのスライス に対応する該当のキーを見つけて、NATION が 'CANADA' に等しいすべてのレコードを含ん でいるブロックを判別します（図 2.18 を参照）。 図 2.18 MDC表の修飾データの 2番目のブロックの識別 両方の値を持つすべてのレコードを含んでいるブロックの集合を見つけるには、DB2 UDB はこの 2 つのスライスの交点を見つけることが必要です。これは、索引を AND して、 2 つの BID の論理積を求める方法で行います（もちろん、異なる SELECT 処理を例として 取り上げれば、 「索引と MDC表」の節で説明したように、ブロックを OR したり、RIDベー スの索引と結合したりすることもあります） 。 共通の BID 値は、1、5、100、216で、これは、45ページの図 2.14 の結果セットに対応 しています。スキャンするブロックのリストが得られると、DB2 UDB は各ブロックのミ ニ・リレーショナル・スキャンを行うことができます。このスキャンでは、1 つのブ ロックにつき 1 回だけ I/O を行います。ブロックはディスク上にエクステントとして保 管されており、エクステントと同じ方法でバッファー・プールに読み込むことができ るからです。分離レベルがカーソル固定または読み取り固定であり、照会の述部が次 元値に関するもののみである場合、ブロック内のすべてのレコードが同じ次元キー値 を持つことが保証されているため、DB2 UDB はブロック内のレコードに対して述部を再 適用する必要があります。他にも述部が存在する場合は、DB2 UDB はブロック内の残り のレコードでそれらの述部を検査するだけで済み、最初のレコード以外は次元述部を 50 第 2 章 多次元クラスタリング表 再適用する必要はありません（反復可能読み取りの場合は、前もってロックが取得さ れるため、述部を再適用する必要はまったくありません）。 INSERT 操作 MDC表は、INSERT 操作にも役立ちます。次のような INSERT ステートメントを考えてくださ い。 INSERT INTO MDC VALUES (1999, 'CANADA') DB2 UDBがこの表に新規レコードを挿入する場合、その保管場所を最も効率的に判別す る方法は何でしょうか。MDC 表のクラスタリングを保守するために、DB2 UDB は次元値 NATION='CANADA' と YEAR='1999' 用の固有のセルを見つける必要があります（ちなみに、こ の例では、3 つ目の次元 COLOR は意図的に除外してあります。DB2 UDB は、この例では COLOR='NULL' を想定して、INSERT 操作を進めます。COLOR 列に NOT NULL オプションが定義 されていた場合は、INSERT は失敗します）。 ご存じのように、MDC 表の作成時に各次元ごとに次元ブロック索引が自動的に生成さ れ、保守されます。そのため、DB2 UDB には、各次元のスライスを見つけて、スライス の交点からセルを判別するという選択肢があります。これは、45 ページの図 2.14 に示 したシナリオです。 言い換えると、DB2 UDB は、各次元の索引を検索して、それぞれのキー値に対応するブ ロックのリストを検出し、BID リストの AND を行って、表内でこのセルのブロック・セッ トを見つけます。結果ブロックには、指定された次元キー値を持つレコードの全セッ トが含まれています。DB2 UDB は、ページ上にスペースがある場合、これらのブロック の 1 つに新規レコードを挿入します。これらのブロック内のページにスペースがない場 合、DB2 UDB は表内の前に空になったブロックを使用するか、または表に新規ブロック を割り振ります。 ところで、複合ブロック索引のことを覚えているでしょうか。複合ブロック索引は、次 元として定義されたすべての列からなるキーを持ち、各セルのブロック・リストにセ ル値をマップします。本書の例では、（NATION, COLOR, YEAR）という複合ブロック索引 が INSERT 処理に使用されることになります。DB2 UDB は、次元ブロック索引の AND の代 わりに、この索引を使用することを選択して、特定のセルが存在するかどうかを速や かに判別し（存在しない場合は、セルを作成する必要があります）、それが存在する場 合、これらのセル値が正確にどのブロックに含まれているかを判別できます。 このように、INSERT 操作では、DB2 UDB は挿入するレコードの次元値に対応するセルの 複合ブロック索引をプローブします（それが存在する場合）。索引内でセルのキーが見 つかった場合、その BID リストは、表内のそのセルの次元値を持つブロックの全リスト を DB2 UDB に提供します。このように、複合ブロック索引を使用すれば、DB2 UDB は挿 入を完了させるためにスペースを探索する必要がある表のブロック数を限定すること ができます。索引内でセルのキーが見つからない場合、またはこれらの値を含むエク MDC 表の働き 51 ステントがいっぱいの場合、DB2 UDB はセルに新規ブロックを割り当てる必要がありま す。可能であれば、表を拡張して新規のページ・エクステントを追加する前に、まず 表内の空きブロックを再利用します。 新規データ用のセルが存在するかどうかは、INSERT を完了させるために DB2 UDB が実行 する必要がある処理に影響を与えます。INSERT は、複合ブロック索引をプローブして、 一致するセル値を見つけます。一致するセル値が存在した場合、BID リストをスキャン します。各 BID ごとに、DB2 UDB はブロックをスキャンし、そのブロックのフリー・ス ペース制御レコード（FSCR）使用してスペースを見つけます。ブロック内にスペース が見つかった場合、DB2 UDB は操作をログに記録し、データ・レコードを挿入します。 MDC 表上に RID 索引が存在する場合、DB2 UDB は該当するキーと RID 値をログに記録しな ければなりません。複合ブロック索引のプローブ時に、新規レコードのセル値が存在 しない場合、あるいはセルは存在するが、どのブロックにもスペースが見つからない 場合、DB2 UDB はこのセルのブロックを再利用するために、ブロック・マップをスキャ ンして、以前に空になってセルから解放されたブロックがないか探します。ブロック・ マップとは、フリー・ブロックを確認するために MDC が使用する内部構造です。フリー・ ブロックが見つかった場合、DB2 UDB はログに記録した上で、ブロックの状況を使用中 に変更します。フリー・ブロックが存在しない場合は、前述の場合と同様に、ブロッ クを割り振って、挿入を終了させます。 UPDATE 操作 DB2 UDBがMDC表のUPDATE操作を処理する方法は、更新する値によって異なります。UPDATE ステートメントが非次元値に対するものである場合は、通常の更新とまったく同様に、 その場で更新されます。 UPDATE が可変長データ・タイプに対するものであり、更新された値の結果としてその データ・ページに収まらなくなる場合には、DB2 UDB はレコードを入れるために別の ページを探す必要があります。DB2 UDB は最初に同じブロック内でこの追加スペースを 探します。データ・レコードがある現行ブロック内にスペースが見つからない場合、 INSERT アルゴリズムを使用してセル内の他のブロックを探索するか、または必要に応じ て新規ブロックをセルに割り振ります。DB2 UDB は、ブロック索引を更新する必要はあ りません（オーバーフロー・レコードを挿入するために新規ブロックをセルに追加す る必要がない限り）。 次元値に対して UPDATE を実行する場合は、DB2 UDB はそのレコードを異なるセルに移動 する必要があります。DB2 は、まず操作を DELETE 操作に変換して次元値に対する更新を 処理し、次に、変更データを INSERT 操作として処理して該当するセルに挿入します。 52 第 2 章 多次元クラスタリング表 DELETE 操作 DELETE 操作は、削除によってブロックが空になるか、ならないかによって操作が異なり ます。 最も簡単な場合は、DB2 UDBはブロックからレコードを除去するだけで、他のレコード は引き続きその中に存在します。例えば、NATION='CANADA' のカスタマーの注文を除去す る場合を考えてみましょう。この場合、DB2 UDBはログに記録した上で、表からレコー ドを削除します（この場合は、ブロックは空にならないことを覚えておいてください） 。 RID索引が存在する場合、DB2 UDBはログに記録した上で各索引からRIDを削除すること も必要です。 DELETE 操作がブロック内の最後のレコードに関係している場合は、DB2 UDB は追加の処 理が必要です。ブロックが空になる場合、DB2 UDB はブロックと現行セルの関連付けを 解除して、必要なときに他のセルがそのブロックを再利用できるようにする必要があ ります。このようにすると、新規ブロックが必要になった場合に常に MDC 表に新規ブ ロックを割り振るよりも効率的です。この場合も、DB2 UDB はログに記録した上で表か らレコードを削除しますが、今回は、ブロックが空になっています。ブロックは再利 用が可能になったので、これをブロック・マップに反映させる必要があります。これ を達成するために、DB2 UDB はブロック・マップで対応するブロック・エントリーを検 索し、ログに記録した上でブロック状況を freeに変更し、さらにログに記録した上で各 索引（次元索引と複合索引）から BID を除去し、既存の RID エントリーも処理します。 最後に、ブロックに最初のレコードが挿入された場合、またはブロックから最後のレ コードが削除された場合にのみ、ブロック索引を更新するだけです。これにより、RID 索引となる各ブロック索引の保守とロギングのためのセルのカーディナリティー係数 で、索引のオーバーヘッドを著しく削減できます。 MDC 表の次元の選別 MDC 表は、通常の表に比べて、途方もなく大きなパフォーマンス上の利点を提供できま す。ただし、MDC 表を定義する際には、次元の選択を十分に考慮する必要があります。 次元が細分化されすぎていると（例：カスタマー番号）、その次元の同種情報を含むブ ロック内の個々のレコード数が少なすぎて、最悪の場合には、情報が一意になってし まいます。明らかに、これでは MDC 表のパフォーマンス上の利益が得られなくなり、過 剰なスペースを必要とします。 表の次元を選択する際には、照会のアクセスを高速にすることが目的であることを考 えて、まず予想される照会を検討することから始めるのが最善です。同等照会または 範囲照会の列、および粗い細分度を持つ列は、ブロック・レベルのクラスタリングか ら最大の利益が得られます。生成列を使用すれば、提案された次元に粗さを追加でき ることを覚えておいてください。 MDC 表の次元の選別 53 MDC 表を作成する前に、最初に次元の候補を識別する必要があります。最良の開始点は、 MDC 表に対して実行する予定の照会のワークロードを調べることです。たいていの場合 は、以下の照会特性に注意を払う必要があります。 ･ 属性に関する述部のタイプが、範囲、同等、IN リストのいずれであるか。例 : shipdate > 1999-01-01 or shipdate = 1999-01-04 ･ データのロールインまたはロールアウト。例えば、四半期 2002–01 のデータを ロードし、四半期 2001–01 のデータを削除する。 ･ Group By 文節の属性。例えば、出荷日によってグループ化する。 ･ Join 文節（特に、スタースキーマの場合）。例 : Lineitem.partkey = Part.partkey and Part.partkey < 1000 ･ 上記の任意の組み合わせ。 ワークロードによっては、これらの基準を満たす属性候補が複数ある可能性が大きく なります。その場合には、ワークロードの特性に基づいて属性をランク付けし、候補 の適切なサブセットを選択できるようにすることが重要です。MDC 次元の選択は、精密 科学ではありません。次元候補の組み合わせを繰り返し変更しながら絞り込み、適切 な選択を行うことが必要です。 MDC 次元の選択の対象となる事項を順序付けしてください。最低のカーディナリティー を持つ次元が適した候補です。例えば、3 つの次元 DAY、NATION、COLOR に基づいて表を クラスタリングする場合を考えてみましょう。対象の年数が 20 年、100 か国、5 色であ る場合、潜在的なセル数は 20 × 100 × 5 × 365 = 3,650,000 になります。データのス キューにより一部のセルは粗密度で、他のセルは高密度になる場合、スペースの消費 が心配な場合には、ブロック・サイズを小さくして、粗密度のセルがスペースを浪費 しないようにすることが必要です。逆に、DAY の代わりに YEAR のような粗い測度に基づ いてクラスター化すると、セルの密度が高くなり、潜在的なセル数は 20 × 100 × 5 = 10,000 になります。 MDC ユーティリティー ユーティリティーに関しては、MDC 表をデフォルトでロードすると、入力データは次元 値に従って編成されます。ロードの設計では、入力データの順序付け、非順序付けを区 別する必要がないことに注意してください。順序付けられている場合、LOAD ユーティリ ティーはターゲット表に直接書き込んで入力を最適に管理することができ、大きなオー バーヘッドを伴いません。 順序付けられていない場合、LOAD ユーティリティーは、キャッシュとシステム一時表を 使用して、内部でデータを順序付けます。Load は、着信データ・ストリームを調べて、 一度にデータの一部分ずつメモリー・バッファー内にクラスタリングします。バッ ファー内のデータは、セル値に従ってブロック単位に分離され、ブロックがいっぱいに なると、ディスクに直接書き込まれます。一部充てんされたブロックは、動的キャッ 54 第 2 章 多次元クラスタリング表 シュに保管され、後でデータ・ストリーム内で同じセルのデータが見つかったときに、 さらに充てんされます。キャッシュがいっぱいになると、データベース・コンテナーに 直接送られて、最終的にそこに属します。一時表は、データ・ストリーム内で見つかっ たセル値を保管し、各セル値を、そのセル用のデータが充てんされている動的キャッ シュ内のブロックにマップします。 MDC サポートは、LOAD の重複レコード処理と削除にも影響を与えることに注意してくだ さい。非 MDC の場合は、重複レコードが検出された場合、LOAD ユーティリティーはユ ニーク・キーを持つ最も古いレコードを見分ける（そして、保持する）ことができま す。しかし、MDC 表に重複レコードを挿入しようとした場合は、2 通りの結果が考えら れます。 ･ LOAD の開始前にユニーク・キーが表内に存在した場合、オリジナル・レコード が存続し、新規、重複、またはロードされたレコードは削除されます。 ･ ユニーク・キーが表内に前に存在していなかった場合には、ロードされたレコー ドのうちの 1つだけ（最低のオブジェクト相対ページ番号を持つレコード）が存 続します。その上、候補レコードのどれがこれに当たるという保証はありませ ん（簡単な計算方法もありません） 。 MDC 表の再編成が必要になる頻度は、クラスタリング索引を使用した表より少なくなり ます。クラスタリングが自動的かつ継続的に保守されるため、データを再クラスタリ ングする目的での再編成はもう必要ありません。ただし、表内のスペースを再利用し たり（特に、セル内のスペースを再利用する場合）、オーバーフロー・レコードをク リーンアップするなどの目的では引き続き使用できます。MDC 表に対しては、オンライ ン再編成はまだ利用不能です。その他の DB2 UDB ユーティリティーはすべてサポートさ れます。最後に、MDC 表は、データ・パーティションと共存し、それを補完することが できます。各パーティションには、論理キューブ内のパーティション・キーに対応し たスライスを持つ MDC 表が入ります。パーティション・キーは、次元であっても、なく ても構いません。 まとめ ご覧のように、MDC 表は、大きなデータベースのパフォーマンスと高可用性を実現する ユニークで強力なソリューションを提供します。MDC の利点として、次のものが挙げら れます。 ･ ･ ･ ･ ･ クラスタリングによるパフォーマンス上の利点を複数の次元に拡張する。 長期間にわたりクラスタリングを自動的かつ動的に保守する。 再編成の必要性が削減され、スペース再利用の目的にのみ限られる。 データ編成は、パーティションが除去されることによる利点を提供する。 ブロック・ベースの索引は、ハイパフォーマンスのアクセス・プランを追加し、 照会内でのブロックの除去を実現する。 まとめ 55 ･ ブロック索引のサイズが小さいことにより、スキャンが高速になり、ロギングお よび保守のオーバーヘッドを削減できる。 ･ 構文は単純で柔軟であり、セットアップや保守が容易である。 56 第 2 章 多次元クラスタリング表