IBM Red Brick Warehouse バージョン 6.2 年 9 月 2002

IBM Red Brick Warehouse
バージョン 6.2
2002 年 9 月
Part No. 000-9057-8
注意 :
本書の情報および該当製品をご利用になる前に、付録「特記事項」の内容をお読みください。
本書には、IBM の著作権情報が含まれます。本書は、使用許諾契約に基づいて提供され、著作権法により
保護されます。本書の内容には、いかなる製品の明示的または黙示的保証も含まれません。
お客様が IBM に情報をお送りなる場合は、IBM に当該情報を自由に使用、頒布するための権利を許諾され
たものとみなされます。IBM が当該情報を利用することにより、お客様に責任が及ぶことはありません。
© Copyright International Business Machines Corporation 1996, 2002. All rights reserved.
米国政府機関ユーザーの権利の制限 - IBM Corporation との間の GSA ADP Schedule Contract により、使用、複
製、および開示が制限されます。
ii Administrator’s Guide
目次
目次
まえがき
この章について . . . . .
このマニュアルの内容 . .
対象読者 . . . . . .
ソフトウェア要件 . .
本書の表記法 . . . . . .
文字の表記規則 . . .
構文の規則 . . . . .
構文ダイアグラム . .
キーワードと区切り文字
識別子と名前 . . . .
文中記号の表記規則 . .
関連文献 . . . . . . .
その他のドキュメント . .
オンライン マニュアル .
印刷マニュアル . . .
オンライン ヘルプ . .
第1章
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
3
3
3
4
5
5
6
7
9
9
10
11
13
13
13
13
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
1-3
1-4
1-5
1-7
1-7
1-8
1-8
1-8
1-9
1-9
1-10
IBM Red Brick Warehouse の概要
この章について . . . . . . . . . . .
データベース サーバのテクノロジー . . .
データベース サーバの構成要素 . . . . .
IBM Red Brick Warehouse . . . . . .
Parallel Table Management Utility . . . .
RISQL エントリ ツールと RISQL レポータ
Administrator ツール . . . . . . . .
Client Connector Pack . . . . . . . .
データベース サーバ . . . . . . . . .
プロセス間の通信 . . . . . . . .
ウェアハウス API プロセス . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
データベース サーバ プロセス . . . . .
管理デーモン プロセス . . . . . . .
Performance Monitor デーモン . . . . .
ログ デーモン プロセス . . . . . . .
プロセス チェッカー デーモン . . . . .
バキューム クリーナ デーモン . . . . .
リスナー スレッド . . . . . . . . .
CTRL-C 処理スレッド . . . . . . . .
共有メモリ . . . . . . . . . . . .
データベース管理の概要 . . . . . . . .
Red Brick Warehouse のインストール . . .
データベース設計の立案 . . . . . . .
データベースの実装 . . . . . . . .
ユーザ アクセスの設定 . . . . . . .
データのロードおよびアンロード . . . .
データベースのメンテナンスと性能の調整
パックアップおよび復旧の手順の計画 . .
Aroma サンプル データベース . . . . . . .
データベースの制限 . . . . . . . . . .
第2章
Administrator’s Guide
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-10
1-12
1-12
1-12
1-13
1-13
1-14
1-14
1-14
1-14
1-15
1-15
1-16
1-17
1-18
1-19
1-19
1-20
1-20
基本概念
この章について . . . . . . . . . .
データのロード . . . . . . . . . .
並列処理 . . . . . . . . . . . .
データベースの物理的構成 . . . . . .
インデックスの作成と検索効率 . .
格納領域のセグメント化 . . . . .
クエリ性能を向上する事前計算ビュー
アプリケーションへの入力のためのクエリ
サンプリング . . . . . . .
データベースのディレクトリとファイル .
データベース論理名 . . . . . .
セグメント名 . . . . . . . . .
環境設定と初期化 . . . . . . . . .
コンフィグレーション ファイル . .
初期設定ファイル . . . . . . .
SET コマンド . . . . . . . . .
環境変数 . . . . . . . . . .
Administrator ツール . . . . . .
サーバ ロケール . . . . . . . . .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
. . .
. . .
2-3
2-3
2-5
2-6
2-6
2-7
2-14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-15
2-15
2-16
2-21
2-21
2-21
2-22
2-24
2-25
2-25
2-27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ロケールの要素 . . . . . . .
サーバ ロケールの設定 . . . . .
サーバ ロケールのオーバーライド .
クライアント / サーバの互換性 . .
ファイルの所有権とアクセス許可 . . .
データベースの権限と特権 . . . . .
バージョン管理されたデータベース . .
参照整合性 . . . . . . . . . . .
データのロードと挿入 . . . . .
データの削除とカスケード デリート
第3章
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-27
2-30
2-31
2-34
2-36
2-37
2-38
2-39
2-39
2-40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-3
3-3
3-3
3-5
3-6
3-7
3-7
3-7
3-13
3-16
3-17
3-19
3-22
3-23
3-23
3-23
3-24
3-26
3-26
3-28
3-30
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
4-3
4-3
4-4
4-6
4-9
スキーマ設計
この章について . . . . . . . . . . . . . .
トランザクション処理システムと意思決定支援システム
トランザクション処理型データベース . . . .
意思決定支援型データベース . . . . . . . .
スター スキーマ . . . . . . . . . . . . . .
スター スキーマの性能 . . . . . . . . . .
用語 . . . . . . . . . . . . . . . .
シンプル スター スキーマ . . . . . . . . .
マルチスター スキーマ . . . . . . . . . .
ビュー . . . . . . . . . . . . . . . .
スキーマ設計の要点 . . . . . . . . . . . .
スキーマを構成するブロック . . . . . . . .
例 : サラダ ドレッシング データベース . . . .
スキーマの分析 . . . . . . . . . . . . . .
ディメンジョン テーブルの検索 . . . . . . .
ファクト テーブルへのクエリ . . . . . . .
属性データの決定 . . . . . . . . . . . .
スキーマの例 . . . . . . . . . . . . . . .
予約システム データベース . . . . . . . .
投資信託データベース . . . . . . . . . .
医療保険データベース . . . . . . . . . .
第4章
.
.
.
.
.
.
.
.
.
.
ウェアハウス データベースの物理設計
この章について . . . . .
データベースのデータ モデル
インデックスの追加 . . .
STAR インデックス . .
B-TREE インデックス .
.
.
.
.
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
目次
v
TARGET インデックス . . . . . . . . . . . . . .
ローカルにセグメント化されるインデックス . . . . . . .
インデックスがない場合 . . . . . . . . . . . . . .
TARGETjoin 処理の管理方法 . . . . . . . . . . . .
セグメントの設計 . . . . . . . . . . . . . . . . . .
デフォルト セグメントと名前付きセグメントの使い分け . .
名前付きセグメントの使用方法 . . . . . . . . . . .
定期的にデータを更新するデータベースの設計 . . . . . . .
ファクト テーブルと同様のインデックスのセグメント化 . .
ローカル インデックスの特性 . . . . . . . . . . . .
テーブルおよび各インデックスの末尾の小さなセグメント . .
ディスク領域の構成 . . . . . . . . . . . . . . . . .
ユーザ テーブルのサイズの見積り . . . . . . . . . .
インデックス サイズの見積り . . . . . . . . . . . .
例 : テーブル、インデックス、システム テーブルのサイズの試算
システム テーブルのサイズの見積り . . . . . . . . . .
ユーザ テーブル、インデックス、
システム テーブルの総スペース . . . . . . . .
一時領域の所要量の見積もり . . . . . . . . . . . . . .
オプティマイズ モードのインデックス作成における
一時領域の使用法 . . . . . . . . . . . . .
一時領域の割り当て . . . . . . . . . . . . . . .
インデックス作成に必要な一時領域の見積り . . . . . . .
TARGET インデックスの一時領域の所要量 . . . . . . .
現在の設定値の確認 . . . . . . . . . . . . . . .
テンポラリ ファイルの削除 . . . . . . . . . . . . .
クエリ処理における一時領域の使用法 . . . . . . . . .
クエリ処理に必要な QUERY_MEMORY_LIMIT の見積り . .
クエリ処理に必要な MAXSPILLSIZE 値の見積り . . . . .
実行時間の長いクエリのリザルト バッファ . . . . . . .
テーブル データの増加への対応 . . . . . . . . . . . . .
テーブルの拡大が STAR インデックスに及ぼす影響 . . . .
第5章
4-41
4-41
4-43
4-44
4-46
4-51
4-52
4-53
4-53
4-55
4-56
4-56
4-58
4-59
データベースの作成
この章について . . . . . .
概要 . . . . . . . . . .
データベースの作成 . . . .
データベース作成の構文 .
データベースの初期化 . .
データベース論理名の設定
vi Administrator’s Guide
4-10
4-13
4-13
4-14
4-16
4-16
4-18
4-22
4-22
4-24
4-25
4-25
4-26
4-27
4-33
4-39
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
5-3
5-3
5-4
5-4
5-6
5-8
DBA アカウント パスワードの変更 . . . . . . . .
データベース オブジェクトの作成 . . . . . . . . .
セグメントの作成 . . . . . . . . . . . . . . .
セグメント化の規則 . . . . . . . . . . . . .
セグメント化の方法 . . . . . . . . . . . . .
STAR インデックスのセグメント化 . . . . . . .
セグメントの作成と削除および部分的に利用可能な
テーブルへのクエリ . . . . . . . . . .
テーブルの作成 . . . . . . . . . . . . . . . .
MAXSEGMENTS オプションと
MAXROWS PER SEGMENT オプションの設定
プライマリ キー制約とフォーリン キー制約の命名 . .
ON DELETE による参照整合性の維持 . . . . . . .
VARCHAR 列フィル ファクタの設定 . . . . . . .
VARCHAR フィル ファクタの精度の監視 . . . . .
インデックスの作成 . . . . . . . . . . . . . .
INDEX TEMPSPACE . . . . . . . . . . . . .
並列インデックス . . . . . . . . . . . . . .
インデックス フィル ファクタの設定 . . . . . . .
定期的に更新されるデータベースの作成 . . . . . . .
データ セグメントとインデックス セグメントの作成 .
テーブルの作成 . . . . . . . . . . . . . .
STAR インデックスの作成 . . . . . . . . . . .
ローカル TARGET インデックスの作成 . . . . . .
データ . . . . . . . . . . . . . . . . . .
ビューの作成 . . . . . . . . . . . . . . . . .
マクロの作成と管理 . . . . . . . . . . . . . .
マクロ定義のガイドライン . . . . . . . . . .
マクロの利用範囲 . . . . . . . . . . . . . .
第6章
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-9
5-11
5-12
5-13
5-15
5-16
. . . 5-19
. . . 5-21
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-22
5-22
5-23
5-24
5-30
5-33
5-34
5-35
5-36
5-41
5-42
5-49
5-50
5-53
5-55
5-57
5-59
5-59
5-60
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-3
6-4
6-4
6-4
6-5
6-6
6-6
6-7
6-7
目次
vii
バージョン管理されたデータベースの使用
この章について . . . . . . . . . . .
バージョニングを使用するケース . . . . .
ロード ウィンドウ . . . . . . . .
復旧性能の向上 . . . . . . . . .
定期コミットを行うロード . . . . .
ロード復旧性の提供 . . . . . . . .
Vista によるバージョニング . . . . .
ディメンジョン テーブルのクリーニング
バージョン ログのコスト . . . . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
バージョン管理されたデータベースへのデータのロード
バージョン ログについて . . . . . . . . . . .
バージョン ログの構造 . . . . . . . . . .
バージョン管理された DELETE 操作 . . . . . .
凍結バージョンについて . . . . . . . . . . .
高復旧性オプションを使用したデータのロード . . .
バージョニングの制御 . . . . . . . . . . . .
バージョン ログの作成 . . . . . . . . . .
バージョン ログのクリーニング . . . . . . .
バージョン ログの削除と領域の追加 . . . . . .
凍結バージョンの制御 . . . . . . . . . . .
バージョン管理されたデータベースのメンテナンス方法
バージョン ログの監視 . . . . . . . . . .
バックアップと復旧 . . . . . . . . . . .
バキューム クリーナの制御 . . . . . . . . . .
例 : バージョン管理された Aroma データベースの作成 .
第7章
viii Administrator’s Guide
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-8
6-10
6-11
6-13
6-13
6-16
6-16
6-18
6-19
6-20
6-21
6-23
6-23
6-24
6-25
6-26
この章について . . . . . . . . . . . . . . . . . .
データベース ユーザの追加 . . . . . . . . . . . . .
オペレーティング システムのアカウントの作成 . . . . .
データベース アクセス権の付与 . . . . . . . . . .
パスワードの変更 . . . . . . . . . . . . . . .
システム ロールによるアクセス権の付与 . . . . . . . . .
DBA、RESOURCE、CONNECT の権限 . . . . . . . .
DBA および RESOURCE システム ロールの付与と取り消し
データベース オブジェクト特権の付与 . . . . . . . . .
ロールに基づくセキュリティでのアクセス権の設定 . . . . .
タスク権限 . . . . . . . . . . . . . . . . . .
ロール権限 . . . . . . . . . . . . . . . . . .
ロールの作成 . . . . . . . . . . . . . . . . .
タスク権限の付与 . . . . . . . . . . . . . . .
ロールへのオブジェクト特権の付与 . . . . . . . . .
ロールの付与 . . . . . . . . . . . . . . . . .
タスク権限、オブジェクト特権、ロールの取り消し . . .
ロールの権限とメンバーの監視 . . . . . . . . . .
パスワードのセキュリティ管理 . . . . . . . . . . . .
パスワードの強制変更 . . . . . . . . . . . . . .
パスワード期限切れの警告 . . . . . . . . . . . .
パスワード再使用の制限 . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-3
7-3
7-4
7-5
7-6
7-7
7-7
7-8
7-9
7-11
7-12
7-14
7-15
7-16
7-16
7-18
7-21
7-23
7-26
7-27
7-29
7-30
データベースのアクセス権とセキュリティ
パスワード変更頻度の制限 . . . . . . . .
パスワードでのログイン名の使用制限 . . . .
最初のログイン時での初期パスワードの強制変更
変更前後のパスワードに関する強制 . . . . .
パスワードの文字の組み合わせと長さの指定 . .
接続失敗によるユーザ アカウントのロック . . .
第8章
.
.
.
.
.
.
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
7-31
7-32
7-32
7-32
7-34
7-36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-3
8-4
8-4
8-6
8-7
8-9
8-10
8-10
8-11
8-11
8-11
8-12
8-12
8-14
8-14
8-15
8-16
8-21
8-24
8-25
8-29
8-29
8-29
8-30
8-31
8-32
8-33
8-34
8-35
8-35
8-37
8-38
組織におけるデータベース運用の管理
この章について . . . . . . . . . . . .
データベース動作を管理するためのタスク権限 .
管理データベース . . . . . . . . . . .
動的統計テーブルによるデータベース動作の監視
Read と Write の統計値 . . . . . . . .
データベース動作の制御 . . . . . . . . .
データベースを静止状態にする . . . . .
データベースを稼働状態にする . . . . .
累積統計値のリセット . . . . . . . .
ユーザ コマンドの取り消し . . . . . .
ユーザ セッションの終了 . . . . . . .
現在のセッションでのユーザ優先順位の変更
管理デーモン プロセス . . . . . . . . .
統計データの収集期間 . . . . . . . .
DST の更新間隔 . . . . . . . . . .
イベントのロギング . . . . . . . . . .
ロギングのサブシステム . . . . . . .
イベント ログ メッセージ . . . . . . .
ログファイル . . . . . . . . . . .
ロギング機能の環境設定 . . . . . . .
クエリのロギング . . . . . . . . . .
Advisor ロギングの制御 . . . . . . . . .
Advisor ログ ファイル . . . . . . . .
Advisor のログ項目 . . . . . . . . .
Advisor ログの開始と停止 . . . . . . .
ADMIN ADVISOR_LOG_ DIRECTORY . .
ADMIN ADVISOR_LOG_MAXSIZE . . . .
アカウンティング . . . . . . . . . . .
アカウンティング プロセス . . . . . .
アカウンティング レコードのフォーマット .
アカウンティング ファイル . . . . . .
アカウンティングの環境設定 . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
目次 ix
アカウンティングの制御 . . . .
第9章
. . . .
. . . .
8-40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-5
9-6
9-6
9-7
9-7
9-9
9-9
9-10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-12
9-13
9-14
9-17
9-17
9-31
9-32
9-32
9-33
9-34
9-35
9-36
9-37
9-39
9-42
9-42
9-43
9-44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-45
9-48
9-49
9-49
9-49
9-50
9-54
9-55
9-55
データ ウェアハウスのメンテナンス
この章について . . . . . . . . . . . . . . . . .
テーブルとデータベースのロック . . . . . . . . . .
テーブルとデータベースの手動ロック . . . . . . .
READER PRIORITY オプション . . . . . . . . .
テーブル ロックの種類 . . . . . . . . . . . .
ロックとセグメント . . . . . . . . . . . . .
テーブルやデータベースの明示的なロック . . . . .
データベース サーバや TMU のロックの待機動作の指定 .
バージョン管理されたトランザクションの
アイソレーション レベル . . . . . . . .
テーブルとインデックスの情報の取得 . . . . . . . . .
CHECK TABLE でのセグメント統計 . . . . . . . .
テーブル構造の検査と修復 . . . . . . . . . . .
CHECK INDEX サイズおよびコンフィグレーション情報 .
インデックス破損のチェック . . . . . . . . . .
テーブルやインデックスのデータの増加の監視 . . . . .
STAR インデックス . . . . . . . . . . . . . .
MAXSIZE 列 . . . . . . . . . . . . . . . .
USED 列 . . . . . . . . . . . . . . . . .
TOTALFREE 列 . . . . . . . . . . . . . . .
シュード列 . . . . . . . . . . . . . . . . .
freespace フィールド . . . . . . . . . . . . .
セグメントへの領域の割り当て方法 . . . . . . . .
セグメントの変更 . . . . . . . . . . . . . . . .
ALTER SEGMENT の使用 . . . . . . . . . . .
アクティブなユーザがいないことの確認 . . . . . .
セグメントのアタッチと切り離し . . . . . . . . .
シングル セグメント テーブルまたは
インデックスへのセグメントのアタッチ . . .
セグメント範囲の指定 . . . . . . . . . . . . .
セグメントのオフライン / オンライン . . . . . . .
セグメントのクリア . . . . . . . . . . . . .
セグメント名の変更 . . . . . . . . . . . . .
セグメントからの格納領域の解放と削除 . . . . . .
PSU サイズの変更 . . . . . . . . . . . . . .
セグメント全体の移動 . . . . . . . . . . . . .
PSU のロケーション変更 . . . . . . . . . . . .
x Administrator’s Guide
. .
セグメントの検証 . . . . . . . . . . . . . . . .
セグメントの強制復旧 . . . . . . . . . . . . . .
定期的に更新されるデータベースのメンテナンス方法 . . . .
データ セグメントおよびインデックス セグメントの
ロールオフと再使用 . . . . . . . . . . . .
新規セグメントの追加 . . . . . . . . . . . . . .
古いデータの削除 . . . . . . . . . . . . . . . .
破損したセグメントの復旧 . . . . . . . . . . . . . .
光ディスクの管理 . . . . . . . . . . . . . . . . .
光ディスクの割り当て . . . . . . . . . . . . . .
光ディスク上のセグメントへのアクセス動作 . . . . . .
光ディスク上のセグメントでのインデックス選択方法の指定
テーブルの変更 . . . . . . . . . . . . . . . . . .
列の追加と削除 . . . . . . . . . . . . . . . .
列名の変更 . . . . . . . . . . . . . . . . . .
列のデフォルト値の変更 . . . . . . . . . . . . .
MAXSEGMENTS 値と MAXROWS PER SEGMENT 値の変更 .
参照整合性を維持する削除動作の変更 . . . . . . . .
列のデータ型の変更 . . . . . . . . . . . . . . .
フォーリン キーの追加と削除 . . . . . . . . . . .
VARCHAR 列のフィル ファクタの変更 . . . . . . . .
SERIAL 列の開始値とステップ値の変更 . . . . . . . .
中断した ALTER TABLE 操作からの復旧 . . . . . . . .
データベースのコピーと移動 . . . . . . . . . . . . .
互換性 . . . . . . . . . . . . . . . . . . . .
絶対パスと相対パス . . . . . . . . . . . . . . .
相対パスだけを使用したデータベースのコピー . . . . .
絶対パスを使用したデータベースのコピー . . . . . . .
相対パスだけを使用したデータベースの移動 . . . . . .
絶対パスを使用したデータベースの移動 . . . . . . . .
rbw.config ファイルのエントリと SET コマンドのパラメータ . .
構成ファイルの修正 . . . . . . . . . . . . . . .
データベース サーバの監視と制御 . . . . . . . . . . .
UNIX でのデータベース サーバの監視と制御 . . . . . .
Windows でのデータベース サーバの監視と制御 . . . . .
バージョン情報の確認 . . . . . . . . . . . . . . . .
データベース オブジェクトとデータベースの削除 . . . . . .
データベース オブジェクトの削除 . . . . . . . . . .
データベースの削除 . . . . . . . . . . . . . . .
. 9-55
. 9-56
. 9-56
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-57
9-63
9-67
9-69
9-71
9-72
9-73
9-74
9-75
9-76
9-76
9-76
9-77
9-77
9-78
9-78
9-79
9-79
9-80
9-82
9-82
9-82
9-84
9-84
9-85
9-85
9-86
9-87
9-96
9-96
9-99
9-100
9-101
9-101
9-105
目次 xi
付録 A
例 : データベースの作成
付録 B
構成ファイル
付録 C
システム テーブルと動的統計テーブル
特記事項
索引
xii Administrator’s Guide
まえがき
まえがき
このマニュアルの内容
対象読者 . . . .
ソフトウェア要件 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
本書の表記法
. . . . .
文字の表記規則 . . .
構文の規則 . . . . .
構文ダイアグラム . . .
キーワードと区切り文字
識別子と名前 . . . .
文中記号の表記規則 . .
コメント記号 . . .
プラットフォーム記号
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
7
9
9
10
10
10
関連文献
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
. .
. .
. .
. .
13
13
13
13
.
.
.
.
.
.
.
.
.
その他のドキュメント .
オンライン マニュアル
印刷マニュアル . .
オンライン ヘルプ .
.
.
.
.
. . . . .
. . . . .
. . . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
2 Administrator’s Guide
この章について
この章では、本書の概要と表記法について説明します。
このマニュアルの内容
このマニュアルでは、IBM Red Brick Warehouse の管理に関する重要情報、および、
データベース サーバの計画、構成、使用について説明します。また、データベース
サーバの特徴、データベース サーバに関するさまざまな概念、および、データベー
ス サーバ管理作業とデータベース保守作業の手順について説明します。
対象読者
本書では、以下のユーザを対象としています。
■
■
■
■
■
■
■
データベース管理者
データベース サーバ管理者
データベース設計者
データベース デザイナー
データベース開発者
バックアップ オペレータ
パフォーマンス エンジニア
本書では、読者に以下の知識や経験があることを前提としています。
■
■
■
使用しているコンピュータ、オペレーティング システム、およびオペレー
ティング システムが提供するユーティリティに対する実務知識
リレーショナル データベースの使用経験、またはデータベースの概念に関
する知識
データベース サーバ管理、オペレーティング システム管理、またはネッ
トワーク管理の経験
まえがき 3
ソフトウェア要件
ソフトウェア要件
本書では、データベース サーバとして IBM Red Brick Warehouse、Version 6.2 を使用
することを前提としています。
IBM Red Brick Warehouse には、コーヒーと紅茶を取り扱う架空の会社の販売データ
をおさめた Aroma というデータベースが添付されています。このデータベースで
は、Aroma Coffee and Tea Company という企業の毎日の販売業務を管理しています。
このデータベースのディメンジョン モデルは、1 つのファクト テーブルと、それに
付属する複数のディメンジョン テーブルから成っています。
サンプル データベースの作成とデータのロードの詳細は、『Administrator's Guide』
を参照してください。データベースとそのデータ内容の詳細は、
『SQL Self-Study
Guide』を参照してください。
サンプル データベースのインストール スクリプトは、UNIX では
<redbrick_dir>/sample_input に、Windows では <redbrick_dir>¥SAMPLE_INPUT に
あります。<redbrick_dir> は使用しているシステムの Red Brick ディレクトリを指し
ます。
4 Administrator’s Guide
本書の表記法
本書の表記法
ここでは、このマニュアルで使用される、以下の表記規則について説明します。表
記規則を覚えておくと、このマニュアル、およびほかのマニュアルの内容を理解す
るのに役立ちます。
以下のような表記規則があります。
■
■
■
■
■
■
文字の表記規則
構文の規則
構文ダイアグラム
キーワードと区切り文字
識別子と名前
文中記号の表記規則
文字の表記規則
このマニュアルは、新しい用語、画面表示、コマンド構文などを表記するのに、以
下の規則を使用します。
表記規則
意味
KEYWORD
プログラミング言語の文中では、主要な要素 ( キーワード )
は、すべて大文字のセリフ フォントで表記されます。
Computer
製品の表示情報やユーザの入力情報はモノスペース フォント
で表記されます。
♦
この記号は、製品やプラットフォームなどに特有の情報の終
わりを表します。
➞
この記号は、メニュー項目を表します。たとえば、"[ ツール ]
➞[ オプション ] を選択します。" は、[ ツール ] メニューの
[ オプション ] を選択することを意味します。
ヒント : コマンドの入力、または実行の指示がある場合、入力後に ENTER キーを
押してください。コマンド以外の文字の入力やほかのキーを押す指示がある場合、
ENTER キーを押す必要はありません。
まえがき 5
構文の規則
構文の規則
このマニュアルでは、オペレーティング システム コマンドの構文の記述に以下の
表記規則を使用します。
コマンドの構成要素 例
表記規則
値および
パラメータ
<table_name>
適切な名前、値、式に置き換える項目は、
山形かっこ < > で囲んで表記します。
オプション項目
[ ]
オプション項目は、角かっこで囲みます。
角かっこは入力しません。
選択肢
ONE |TWO
選択肢は縦線で区切ります。必要に応じ
て、いずれか 1 つを選択できます。
必須選択肢
{ONE|TWO}
必須選択肢は、中かっこで囲みます。いず
れか 1 つを選択してください。中かっこは
入力しません。
デフォルト値
ONE|TWO
デフォルト値は、下線を付けて表記しま
す。ただし、図の部分では、太字で表記し
ます。
繰り返し項目
name, …
繰り返し可能な項目は、後にカンマと省略
記号を記述します。各項目は カンマで区切
ります。
記述記号
() , ; .
丸かっこ、カンマ、セミコロン、ピリオド
は記述記号です。記述されているとおりに
使用してください。
6 Administrator’s Guide
構文ダイアグラム
構文ダイアグラム
このマニュアルでは、以下の要素で作成されたダイアグラムを使用して、ステート
メントの構文と、システム レベルのコマンド以外のすべてのコマンドを記述しま
す。
構成要素
意味
ステートメントの開始。
ステートメントの構文は次の行に続きます。完全
なステートメント以外の構文要素はこの記号で終
了します。
ステートメントは前の行から続いています。完全
なステートメント以外の構文要素はこの記号で始
まります。
ステートメントの終了。
SELECT
ステートメントの必須項目。
オプション項目。
DISTINCT
DBA TO
CONNECT TO
選択を含む必須項目。1 つの項目が存在する必要
があります。
SELECT ON
ASC
選択を含むオプション項目。デフォルト値が存在
する場合、太字で印刷されます。
DESC
,
オプション項目。複数項目が可能です。繰り返す
項目の前にカンマが必要です。
ASC
DESC
まえがき 7
構文ダイアグラム
先行する構文要素は、以下のように組み合わされてダイアグラムを形成します。
REORG
<table_name>
,
INDEX
(
<index_name>
)
;
ON
OPTIMIZE
RECALCULATE RANGES
OFF
以下のように複雑な構文ダイアグラムは、要素の詳細なダイアグラムのポイント参
照用として繰り返されます。ポイント参照ダイアグラムは、影を付けて角を囲み、
グレーの線と小さい文字で表します。
LOAD
<INPUT_CLAUSE>
DATA
<optimize_clause>
<FORMAT_CLAUSE>
<TABLE_CLAUSE>
<segment_clause>
’<DISCARD_CLAUSE>’
;
<criteria_clause>
<comment_clause>
ポイント参照ダイアグラムの後に、影付き部分の拡大ダイアグラム ( この場合は
INPUT_CLAUSE) が続きます。
INPUTFILE
filename
INDDN
(
START
RECORD
8 Administrator’s Guide
'<FILENAME> '
<START_ROW>
<START_ROW
)
TAPE
DEVICE
STOP
RECORD
'<DEVICE_NAME>'
<stop_row>
キーワードと区切り文字
キーワードと区切り文字
キーワードとは、ステートメントおよびコマンド ( システム レベルのコマンドを除
く ) で使用するために予約された単語のことです。構文ダイアグラムでは、キー
ワードが大文字で表記されます。ユーザが実際にキーワードを記述する場合は、大
文字 / 小文字のどちらを使用してもかまいません。ただし、スペルは構文ダイアグ
ラムに表記されるとおりでなければなりません。
構文ダイアグラム内の区切り文字も、ダイアグラムに示されているとおりにステー
トメントとコマンドの中に入れる必要があります。
識別子と名前
構文ダイアグラムおよび例の中の変数は、識別子および名前に対するプレースホル
ダです。変数は、文脈に応じて任意の名前、識別子、またはリテラルに置き換える
ことができます。変数は、追加の構文ダイアグラムで拡大される複雑な構文要素を
表すためにも使用されます。変数は、構文ダイアグラム、例、テキストでは、< >
（山形かっこ）で表記されますす。
以下に示す構文ダイアグラムでは、変数を使用して簡単な SELECT 文の一般的な
フォームを説明しています。
SELECT
<column_name>
FROM
<table_name>
このフォームの SELECT 文を書き込む場合、変数の <column_name> と <table_name>
を特定の列とテーブルに置き換えます
まえがき 9
文中記号の表記規則
文中記号の表記規則
マニュアル内では、数種類の記号によってその内容が区別されるテキストがありま
す。この節では、これらの記号について説明します。
コメント記号
コメント記号によって区別される情報には、次の表に示す 3 種類があります。
記号
ラベル
説明
警告 :
必須の情報、注意、重要な情報が含まれています。
重要 :
現在説明されている手順または機能に関する重要な
情報が含まれています。
ヒント :
現在説明されている機能に関する、詳細または
ショートカットなどの追加情報が含まれます。
プラットフォーム記号
機能記号、製品記号、およびプラットフォーム記号、特定のプラットフォームに関
する情報を意味します。
記号
説明
UNIX
Windows
10 Administrator’s Guide
UNIX と Linux オペレーティング システムにのみ関連のあ
る情報を意味します。
Windows プラットフォームにのみ関連のある情報を意味
します。
関連文献
これらの記号は、節全体に適用される場合と、節内の一部の段落にのみ適用される
場合があります。記号が節見出しの隣に付いている場合、その機能、製品、または
プラットフォーム固有の情報の範囲は、同じレベルまたは上位レベルの節が現れる
直前までです。 ♦ 記号は、機能、製品、またはプラットフォーム固有の情報が節内
の一部のパラグラフにのみ記述されている場合に、その固有情報の範囲の末尾を表
します。
関連文献
IBM Red Brick Warehouse のマニュアルには、次の文書が含まれています。
マニュアル
説明
このマニュアル
ウェアハウスのアーキテクチャやサポートされる
スキーマなど、データべースに関連した基本概念
のマニュアルです。データべースのインプリメン
トや保守の手順について説明しています。システ
ム テーブルとコンフィグレーション ファイルの説
明も含まれています。
『Client Installation and
Connectivity Guide』
ODBC、Red Brick JDBC Driver、RISQL エントリ
ツール、RISQL レポータ をクライアント システム
にインストールして構成するためのガイドです。C
および C++ アプリケーション用 ODBC 製品と Java
アプリケーション用 JDBC 製品を使用して、IBM
Red Brick Warehouse にアクセスする方法を説明し
ています。
『IBM Red Brick Vista User’s
Guide』
IBM Red Brick Vista の集約計算とマネジメントのシ
ステムについて説明しています。集約を使用して
クエリを自動的にリライトすることによって Vista
クエリ パフォーマンスを向上させる方法、毎日集
められるデータをもとに最高の集約セットを作る
よう推奨すること、詳細テーブルが更新されると
きに集約テーブルがどのように保守されるかを説
明しています。
『Installation and Configuration
Guide』
IBM Red Brick Warehouse のインストールと環境設
定に関する説明書と、プラットフォーム別マニュ
アルです。UNIX および Linux ベースのシステム用
と、Windows ベースのシステム用があります。
(１/２)
まえがき
11
関連文献
マニュアル
説明
『Messages and Codes
Reference Guide』
IBM Red Brick Warehouse 製品が出力するすべての
状態情報、警告、エラー メッセージとその考えら
れる原因、対処方法が示されています。ログ ファ
イルに書き込まれるイベント ログ メッセージも記
述されています。
『Query Performance Guide』
クエリ パフォーマンスの決定要因と、最適なクエ
リ パフォーマンスを得るためのデータベースの
チューニング方法について説明しています。Red
Brick ツール (SET STATS、Dynamic Statistic Tables :
動的統計テーブル、EXPLAIN、および Query
Performance Monitor) を使用してクエリ パフォーマ
ンスを評価する方法についても、例を挙げて説明
しています。
『リリースノート』
マニュアルの印刷後に判明した現リリースに関す
る情報が含まれます。
『RISQL Entry Tool and RISQL
Reporter User's Guide』
SQL 文の入力に使用するコマンドライン ツールで
ある RISQL エントリ ツール と、RISQL エントリ
ツール にレポートのフォーマット設定機能を付加
した RISQL エントリ ツール の詳細なガイドです。
『SQL Reference Guide』
Red Brick SQL のインプリメントと RISQL (IBM Red
Brick Warehouse データベースのための拡張機能 ) に
関する詳細な言語リファレンスです。
『SQL Self-Study Guide』
例題に基づいて SQL を復習し、RISQL 拡張機能、
マクロ関数、Aroma のサンプル データベースを紹
介します。
『Table Management Utility
Reference Guide』
データのロード、管理、バックアップに関連した
機能をまとめた、Table Management Utility について
説明しています。データのコピーと rb_cm コピー
管理ユーティリティについても説明しています。
(２/２)
このほか、以下の書籍やマニュアルも役に立つ場合があります。
■
■
■
12 Administrator’s Guide
SQL の入門書
リレーショナル データベースの入門書
ご使用のハードウェア プラットフォームとオペレーティング システムの
マニュアル
その他のドキュメント
その他のドキュメント
上記以外の情報は、以下のマニュアルを参照してください。
■
■
■
オンライン マニュアル
印刷版マニュアル
オンライン ヘルプ
オンライン マニュアル
Red Brick 製品には、各種の IBM Red Brick Warehouse マニュアルを電子フォーマット
で収録した CD-ROM が同梱されています。収録されているマニュアルは、システム
にインストールして使用することも、CD-ROM から直接アクセスすることも可能で
す。
印刷マニュアル
印刷マニュアルを注文する場合は、担当販売員までご連絡ください。
オンライン ヘルプ
IBM はグラフィカル ユーザ インタフェース (GUI) を用いたオンライン ヘルプを提
供します。これにより、各インタフェースや実行する関数についての情報を参照す
ることができます。オンライン ヘルプを表示するには、GUI のヘルプ機能を利用し
てください。
まえがき
13
第1章
の概要
データベース サーバのテクノロジー
.
.
.
.
.
.
.
.
.
.
.
.
1-4
1-5
1-7
1-7
1-8
1-8
1-8
データベース サーバの構成要素 . . . . .
IBM Red Brick Warehouse . . . . . .
Parallel Table Management Utility . . . .
RISQL エントリ ツールと RISQL レポータ
Administrator ツール . . . . . . . .
Client Connector Pack . . . . . . . .
. .
. .
. .
. .
. .
. .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
. .
. .
データベース サーバ . . . . .
プロセス間の通信 . . . . .
ウェアハウス API プロセス .
データベース サーバ プロセス
管理デーモン プロセス . . .
Performance Monitor デーモン .
ログ デーモン プロセス . . .
プロセス チェッカー デーモン
バキューム クリーナ デーモン
リスナー スレッド . . . .
CTRL-C 処理スレッド . . .
共有メモリ . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-9
1-9
1-10
1-10
1-12
1-12
1-12
1-13
1-13
1-14
1-14
1-14
データベース管理の概要
. . . . .
Red Brick Warehouse のインストール
データベース設計の立案 . . . .
データベースの実装 . . . . . .
ユーザ アクセスの設定 . . . . .
初期化ファイル . . . . . .
マクロ . . . . . . . . .
データのロードおよびアンロード .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-14
1-15
1-15
1-16
1-17
1-17
1-17
1-18
クエリと同時のロード . . . . . .
クエリ結果のエクスポート . . . .
データベースのメンテナンスと性能の調整
パックアップおよび復旧の手順の計画 .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
1-18
1-18
1-19
1-19
Aroma サンプル データベース .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-20
データベースの制限
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1-20
1-2 Administrator’s Guide
.
.
.
.
この章について
IBM Red Brick Warehouse は、データ ウェアハウス、データ マート、オンライン分析
処理 (OLAP) アプリケーションを対象としたリレーショナル データベース管理シス
テム (RDBMS) です。Red Brick はクエリ処理とデータのロードの性能に優れ、管理
が容易です。数ギガバイトから数十テラバイト、数人のユーザから数千人のユーザ
まで、広範囲のアプリケーションに対応する機能を備えています。
Red Brick Warehouse は、ワークグループから全社的スケールまで対応し、業界標準
オープン データベース コネクティビティ (ODBC)、および Java データベース コネク
ティビティ (JDBC) を使用するクライアント / サーバの環境向けに設計され、業界標
準 SQL でアクセスします。Red Brick Warehouse は、Red Brick サーバ用に特別に開発
された独自の RISQL 表示関数と、ANSI SQL-99 標準に準拠し、この標準をさらに拡
張する SQL OLAP 関数という 2 つの分析関数をサポートします。Vista、STARjoin、
STARindex、TARGETjoin、および TARGETindex 技術は、各種のスキーマ設計を持
つ非常に大きなデータベースに対して、非並列のアドホック クエリと分析性能を提
供します。分析的なクエリを数多く実行し、必要な情報をすぐに得られるため、ビ
ジネス上の決定を迅速かつ的確に下すことができます。
この章では、以下について説明します。
■
■
■
■
■
■
データベース サーバのテクノロジー
データベース サーバの構成要素
データベース サーバ
データベース管理の概要
Aroma サンプル データベース
データベースの制限
IBM Red Brick Warehouse 概要
1-3
データベース サーバのテクノロジー
データベース サーバのテクノロジー
Red Brick Warehouse は、戦略的データ分析を行うアナリストやビジネス マネージャ
のニーズに合ったリレーショナル データベース環境の提供を目的として設計されて
います。これには、大規模なデータベースへの対応、データの高速ロード、実用的
なクエリの作成、クエリへの迅速な応答などの能力が要求されます。
Red Brick Warehouse は以下の機能によってこれらの要件を実現しています。
■
■
■
■
■
■
■
■
■
1-4 Administrator’s Guide
ディメンショナル セグメンテーション : テーブルのデータやインデックス
を複数の独立した物理格納ユニットに分散させ、データのロード中でも部
分的にアクセスできるようにし、クエリ性能を高め、インクリメンタルな
バックアップや復旧の作業を効率化します。
単一プロセッサおよび対称型マルチ プロセッサ (SMP) システムでの並列処
理 : 並列処理はクエリ処理、マルチ ユーザ リレーション スキャン、イン
デックス作成、データのロードに利用できます。
Red Brick サーバ用に特別に開発された独自の RISQL 表示関数と、ANSI
SQL-99 標準に準拠し、この標準をさらに拡張する SQL OLAP 関数という 2
つの分析関数。Red Brick サーバは、この標準の「基本的な OLAP」パッ
ケージに定義されたすべての関数をサポートします。
詳細については『SQL Reference Guide』、『SQL Self-Study Guide』および
『RISQL Entry Tool and RISQL Reporter User’s Guide』を参照してください。
Parallel Table Management Utility (Parallel TMU) : データのロード、インデッ
クス付け、バッチ プロセスのデータに対する参照整合性チェックに加え、
さまざまな管理機能を実行します。Parallel TMU の Auto Aggregate モードで
は、ロード処理中に既存データと新規データの集約を行うことができま
す。データのロードとインデックスの作成を最適化して行うために、多数
の TMU 操作が並列に実行されます。
詳細については、『Table Management Utility Reference Guide』を参照してく
ださい。
Vista の集約計算管理 : 集約クエリを自動的に最適化し、詳細テーブルが
ロードされた場合に事前計算集約データの保守を行います。また、クエリ
の作業負荷に対する最適の集約手法についてのヒントを示します。詳細に
ついては、『IBM Red Brick Vista User’s Guide』を参照してください。
日付データ型の定期的なデータをサポートし、日付に応じてデータをセグ
メント化することができます。
最新の RDBMS でテーブル間の結合パスを任意に設定できます。
優れたインデックス作成技術である STARindex および TARGETindex に
よって、データを迅速に検索できます。
再利用可能な生成クエリを容易に作成できるマクロ機能を備えています。
データベース サーバの構成要素
データベース サーバの構成要素
データベース サーバは以下のソフトウェアで構成されています。
■
■
■
■
■
■
IBM Red Brick Warehouse
Parallel Table Management Utility (Parallel TMU)
コマンド ライン エントリ ツールである RISQL エントリ ツールおよびリ
ポート生成ツールである RISQL レポータ
Administrator ツール
集約計算管理システムである Vista。Vista のすべての機能はデータベース
サーバ、Parallel TMU、および Administrator ツールに統合されています。
アプリケーション プログラミング インターフェイス (API) を実装したもの
である Red Brick ODBC Driver および Red Brick JDBC Driver を含む IBM Red
Brick Client Connector Pack
次の図は、IBM Red Brick Warehouse の構成を示したものです。
IBM Red Brick Warehouse 概要
1-5
データベース サーバの構成要素
図 1-1
IBM Red Brick Warehouse の構成要素
Windows または
UNIX の
クライアント アプリケーション
Red Brick
ODBC Driver
クライアント
アプリケーション :
ブラウザと Java
Red Brick
JDBC Driver
ハードウェア
プラットフォーム
データベース サーバ
入力
ソース
1-6 Administrator’s Guide
Table
Management
Utility
Red Brick
Warehouse
データベース
Red Brick
Warehouse
IBM Red Brick Warehouse
IBM Red Brick Warehouse
IBM Red Brick Warehouse は、API を通じて、SQL 文を受け取り、データベース サー
バに接続された RISQL エントリ ツールや RISQL レポータなどのクライアント アプ
リケーションまたはその他のクライアント ツールに結果を送ります。Windows で
は、IBM Red Brick Warehouse は Windows サービスとして実行されます。データベー
ス サーバ機能は、1-9 ページ「データベース サーバ」に記述する各プロセスによっ
て実行されます。
Parallel Table Management Utility
Parallel Table Management Utility (Parallel TMU) は、データベースにデータをロードし
ます。多彩なフォーマットが使用でき、データ型の変換や任意のデータ操作などを
併用したユーザ テーブルへのロードが可能です。データベース管理者は、TMU プ
ログラムをリモート起動して、ネットワークで結ばれたクライアント マシン上にあ
る入力ファイルから、プロダクション サーバ マシン上のデータベース テーブルに
データをロードできます。ロード処理中は、TMU がプライマリ キーとフォーリン
キーの関係を検証してデータの参照整合性を確立します。
TMU は、テーブルの一括ロードまたはインクリメンタル ロードのいずれかと、一
定間隔のコミットによってバージョン管理されたロードを実行します。割り込みや
エラーが発生した場合は、TMU を再起動してロード処理を続行することもできま
す。
データのロードに加え、TMU には次の機能があります。
■
■
■
■
■
■
■
新バージョンの IBM Red Brick Warehouse への移行のためのデータベースの
アップグレード
テーブルの修正に合わせたインデックス再編成による性能の向上
データのアンロードや再ロードによるデータベースの移動やほかの解析
ツールへのロードの簡略化
参照整合性に必要な新規行の自動生成
データのロードと同時に行われるデータの集約 (Auto Aggregate モード )
複数のプロセッサを使ったロード操作の実行 (Parallel TMU)
複数のプロセッサを使って並列に実行するデータ変換とインデックス作成
TMU の詳細については、付録 A「例 : データベースの作成」および『Table
Management Utility Reference Guide』を参照してください。
IBM Red Brick Warehouse 概要
1-7
RISQL エントリ ツールと RISQL レポータ
RISQL エントリ ツールと RISQL レポータ
RISQL エントリ ツールは、IBM Red Brick Warehouse に対話形式でアクセスするため
のコマンド ライン クライアント ツールです。主にデータベース管理者やアプリ
ケーション開発担当者を対象としており、RISQL クエリの入力やデータの抽出、
データベース管理機能を実行するために使用します。RISQL レポータは、RISQL エ
ントリ ツールの全機能に加え、レポート フォーマット設定機能も提供します。
RISQL エントリ ツールと RISQL レポータは、UNIX ワークステーション、ネット
ワーク上の端末エミュレータ、IBM Red Brick Warehouse に接続された Windows クラ
イアントから利用できます。各ツールの詳細については、『RISQL Entry Tool and
RISQL Reporter User’s Guide』を参照してください。
Administrator ツール
Administrator ツールはデータベースをグラフィカルに管理するツールです。このク
ライアント ツールは、Windows ベースのコンピュータで動作します。UNIX または
Windows 上にあるデータベースに接続して、セグメンテーションを含むさまざまな
データベース管理タスクを実行するのに使用できます。
詳細については、2-25 ページ「Administrator ツール」を参照してください。
Client Connector Pack
Client Connector Pack には、ODBC と Red Brick JDBC Driver の 2 つのアプリケーショ
ン プログラミング インターフェイス (API) が含まれています。
Red Brick ODBC Driver を使って、ODBC に準拠したさまざまなデータベース アプリ
ケーションを IBM Red Brick Warehouse と連携させることができます。この API を使
うと、Microsoft Access などのフロントエンド アプリケーションを使って、IBM Red
Brick Warehouse の情報にアクセスできるようになります。
Red Brick JDBC Driver を使って、JDBC に準拠したさまざまなデータベース アプリ
ケーションを IBM Red Brick Warehouse と連携させることができます。Java データ
ベース コネクティビティ (JDBC) は、Java プログラムを使ってデータベース管理シ
ステムにアクセスできるようにする標準 API の JavaSoft 仕様です。Red Brick JDBC
Driver は、Java プログラム言語を使って作成されたインターフェイスとクラスで構
成されています。
各 API の詳細については、
『Client Installation and Connectivity Guide』を参照してくだ
さい。
1-8 Administrator’s Guide
データベース サーバ
データベース サーバ
UNIX
IBM Red Brick Warehouse は、UNIX System V の Interprocess Communication (IPC) 制
御、共有メモリ、およびセマフォを使用して相互通信する一連のプロセスにより、
UNIX 上で実装されます。ウェアハウス デーモンという 1 つのプロセスがユーザ
セッションごとにサーバ プロセスを起動し、監視します。この構成は各サーバ プ
ロセスを個別のプロセッサ上で実行できるマルチ プロセッサ システムに最適です。
データベース サーバ プロセスの詳細については、9-96 ページ「UNIX でのデータ
ベース サーバの監視と制御」を参照してください。♦
Windows
IBM Red Brick Warehouse は、Windows サービスとして実行される 1 つのマルチス
レッド プロセスにより、Windows 上で実装されます。Windows サービスは 1 つ以上
のスレッドから構成されます。このスレッドは常に動作しており、ほかのスレッド
の起動と停止を行うことができます。Windows 上では、スレッドはプロセスとして
実行されます。スレッド間の通信には、共有メモリを使用します。Red Brick API
(rbwapid) という 1 つのスレッドがユーザ セッションごとにデータベース サーバ ス
レッドを起動し、監視します。Table Management Utility (TMU) は、IBM Red Brick
Warehouse サービスと通信する、別のプロセスとして実行されます。
Windows 版の IBM Red Brick Warehouse は次の機能をサポートしています。
■
■
■
Winsock 2.0 ネットワーク プロトコル スタック
Windows の統一ログオン
Systems Management Server によるソフトウェアの配布
データベース サーバ スレッドの詳細については、9-99 ページ「Windows でのデー
タベース サーバの監視と制御」を参照してください。♦
プロセス間の通信
次の図はデータベース サーバのプロセスの間の通信を示しています。ユーザがクラ
イアント ツールを使ってデータベースにアクセスすると、クライアント ツールが
Red Brick ODBC Driver または Red Brick JDBC Driver を通じてウェアハウス デーモン
およびサーバ プロセスと通信します。RISQL エントリ ツールまたは RISQL レポー
タを使ってデータベースにアクセスすると、これらのツールが直接ウェアハウス
デーモンおよびサーバ プロセスと通信します。
Windows
Windows では、IBM Red Brick Warehouse サービスは 1 つのマルチスレッド プロセス
として実行されます。スレッドは UNIX のプロセスに対応する名前のついたプロセ
スとして実行されます。♦
IBM Red Brick Warehouse 概要
1-9
ウェアハウス API プロセス
ウェアハウス API プロセス
ウェアハウス デーモン プロセス (rbwapid) は各サーバ プロセス (rbwsvr) と、各サー
バと関連のクライアント プロセスとの通信を管理します。rbwapid プロセスは、
データベース サーバ プロセスの作成、データベース サーバ プロセス数のコント
ロール、例外処理、サーバ プロセスの終了とクリーンアップを行います。標準の設
定では、システムの起動と同時に rbwapid プロセスが自動的に起動し、継続的に動
作します。
詳細については、9-96 ページ「データベース サーバの監視と制御」を参照してくだ
さい。
データベース サーバ プロセス
IBM Red Brick Warehouse は、ユーザ当たり 1 プロセスというアーキテクチャを採用
しており、データベースにアクセスするユーザ セッションごとに、rbwsvr という
新規プロセスが作成されます。データベース サーバ プロセスは、Red Brick ODBC
Driver または Red Brick JDBC Driver を通じて、Red Brick Warehouse に接続されてい
る RISQL エントリ ツール、RISQL レポータ、またはその他のクライアント ツール
から SQL 文を受け取り、その構文を解析して制御文を実行し、出力データをクライ
アントに返します。各クライアント セッションはそれぞれ固有のデータベース
サーバのプロセスによって処理されます。各データベース サーバ プロセスはクラ
イアントがそのセッションを終了するまで存続します。並行してクエリ処理を実行
するときは、必要に応じて、追加のデータベース サーバ プロセスは、クライアン
トが接続しているサーバ プロセスの子として作成されます。
1-10 Administrator’s Guide
データベース サーバ プロセス
図 1-2
プロセス間の通信
クライアント
ツール
データの流れ
制御、
または状態情報の流れ
Windows のみ
Red
Red Brick
Brick
JDBC
または
ODBC
JDBC
または
ODBC
Driver
rbwlsnr
( コンピュータ
当たり 1 つ )
rbwlsnr
rbwlsnr
(60
(60の接続当た
の接続
り 1 1つつ) )
当たり
rbwpchk
( コンピュータ
当たり 1 つ )
共有メモリ
rbwsvr
rbwsvr
( ユーザ
セッショ
rbwsvr
( ユーザ
セッショ
( ユーザ
セッション
当たり 1 つ )
rbwpmond
( コンピュータ
当たり 1 つ )
Parallel TMU
rbwapid
( コンピュータ
当たり 1 つ )
バージョン
ログ
rbwvcd
rbwadmd
( コンピュータ
当たり 1 つ )
データ ベー
ス PSU
rbwlogd
( コンピュータ
当たり 1 つ )
ログ
ファイル
集約保守のために、TMU はデータベース サーバと直接通信します。この通信によ
り、詳細テーブルを更新する 1 つの TMU トランザクションの一部として、データ
ベース サーバによる事前計算ビューへの変更を行うことができます。集約保守につ
いては、『IBM Red Brick Vista User’s Guide』を参照してください。
IBM Red Brick Warehouse 概要
1-11
管理デーモン プロセス
管理デーモン プロセス
管理デーモン プロセス (rbwadmd) は、動的統計テーブル (DST) の統計値を収集し、
ALTER SYSTEM 文で指定された動作を実行します。rbwadmd プロセスは、
rbwapid プロセスが起動されるのと同時に起動されます。
rbwadmd プロセスの詳細については、8-12 ページ「管理デーモン プロセス」を参
照してください。
Performance Monitor デーモン
クエリの実行状況のプロフィールを作成する場合、管理者は Performance Monitor
デーモン プロセス (rbwpmond) を起動して、Performance DST の統計値を追加収集し
ます。データベース管理者は ALTER SYSTEM START PERFORMANCE MONITOR 文
を使って、rbwadmd プロセスを起動します。
Performance Monitor の使用方法の詳細については、『Query Performance Guide』を参
照してください。
ログ デーモン プロセス
ログ デーモン プロセス (rbwlogd) は、Red Brick Warehouse で発生した各種イベント
をログ ファイルに記録します。このデーモンは、rbwapid プロセスと同時に自動的
に起動されます。ログに記録するイベントは、データベース管理者が指定すること
ができます。特に何も指定されていなければ、IBM 製品テクニカル サポートがエ
ラーの診断に使用するイベントだけが記録されます。
rbwlogd プロセスの詳細については、8-16 ページ「ログ デーモン」を参照してくだ
さい。
1-12 Administrator’s Guide
プロセス チェッカー デーモン
プロセス チェッカー デーモン
プロセス チェッカー (rbwpchk) は、接続が異常終了した場合に、使用されたままに
なっている共有リソースを解放します。これによって、Red Brick Warehouse の制御
外でプロセスが終了した場合でも ( たとえば、UNIX の kill -9 コマンド、あるいは
Windows のスレッド終了またはタスク マネージャからの End Task 要求で終了した場
合 )、システムを正常にクリーンアップできます。プロセス チェッカーは rbwapid
プロセスにより起動されます。
バキューム クリーナ デーモン
バキューム クリーナ デーモン (rbwvcd) はバージョン管理されたデータベースに存
在します。rbwvcd プロセスはデータベースごとに 1 つあります。バキューム ク
リーナの目的は、バージョン ログにあるコミットされたデータをデータベース
ファイルにマージして、バージョン ログ内の領域を解放することです。バキューム
クリーナは、バージョン管理を有効にしたとき、またはバージョン管理されたデー
タベースに初めて接続したときに起動します。
バージョン管理されたデータベースに変更があると、まず変更されたブロックが
バージョン ログに書き込まれます。この変更が行われている間も、既存のコミット
されたブロックでのクエリ ( 読み取り ) 操作は可能です。新規のブロックがバー
ジョン ログにコミットされた後、そのブロックがデータベース ファイルに移動さ
れる前に、クエリ操作がバージョン ログの新規のブロックにアクセスします。
バキューム クリーナ デーモン プロセスは、以前のバージョンのデータベースを読
み取っているユーザがいなくなるまで待機してから、変更されたブロックをバー
ジョン ログから取り出して、データベース ファイルに再び書き込みます。データ
をバージョン ログから移動したあと、バキューム クリーナはバージョン ログから
これらのブロックを削除して、新しいバージョン管理トランザクションが使用でき
るようにバージョン ログ内の領域を解放します。
バージョン ログの詳細については、第 6 章「バージョン管理されたデータベースの
使用」を参照してください。
IBM Red Brick Warehouse 概要
1-13
リスナー スレッド
Windows
リスナー スレッド
リスナー スレッド (rbwlsnr) は、Red Brick Warehouse サービスを構成するスレッド
で、Red Brick Decision Server からの接続を受け付けます。リスナー スレッドは
rbw.config ファイルを読み込んで、受け付けるポートと、( パラメータ
MAX_SERVERS の値に基づく ) 同時接続の許容数を判断します。リスナー スレッド
はデータベース サービスを起動すると自動的に起動します。
Windows
CTRL-C 処理スレッド
CTRL-C 処理スレッド (rbwconc) は Red Brick Warehouse に接続された各クライアン
トからの CTRL-C 割り込みを受け付けます。CTRL-C スレッドはリスナー スレッド
によって起動され、60 の同時接続ごとに 1 つずつ作成されます。
rbwconc スレッドは、各クライアントからの CTRL-C あるいは取り消しを検出する
と、取り消しを要求した rbwsvr スレッドを正常に、整合性を保った状態で動作終
了させます。
共有メモリ
データベース プロセスはすべて、グローバルな共有メモリにアクセスします。バー
ジョン管理されたデータベースでは、共有メモリの一部分が各データベース用に割
り当てられます。
データベース管理の概要
Red Brick Warehouse データベースの管理作業には、以下のものがあります。
■
■
■
■
1-14 Administrator’s Guide
インストレーション : データベース環境の設定、ソフトウェアのインス
トール、データベース ディレクトリ、ファイル、管理者アカウントの設定
と管理など
データベース設計 : スキーマ設計、物理領域とインデックスに関する運用
計画など
データベースのインプリメンテーション : システム テーブル、セグメント、
ユーザ テーブル、インデックスの作成、およびデータベース ユーザの設
定など
セキュリティとユーザ アクセスに関連した作業 : アクセス権の付与と取り
消し、マクロの作成、初期化ファイルの設定
Red Brick Warehouse のインストール
■
■
■
データのロードおよびアンロード : 同時クエリおよび更新に必要なバー
ジョン管理機能など
ハードウェア、データベース、ユーザ要件に基づいた、最適な性能が得ら
れるようなデータベースの調整
保守作業 : 物理領域やクエリ性能の監視、物理領域の再割り当て、テーブ
ルやインデックスの再作成、定期的なバックアップの実行など
次の節では、上記の管理作業について簡単に説明し、詳細な情報の参照先を記述し
ます。
Red Brick Warehouse のインストール
IBM Red Brick Warehouse ソフトウェアは、IBM が提供するメニュー形式のスクリプ
トによって CD-ROM 装置からインストールされ、検証されます。データベース管理
者は、ソフトウェアのインストール先を決定し、そのディレクトリを作成し、CDROM からインストレーション スクリプトを実行します。その後、メニュー選択に
よってインストレーションと検証のプロセスが行われます。プロンプトに従って環
境設定情報を入力し、ソフトウェアのインストール、構成ファイルの作成、Aroma
サンプル データベースの作成とロードを行ってください。さらにメンテナンス リ
リースをインストールする場合も、インストレーション スクリプトを実行します。
データベース管理者は、インストレーションや管理者タスクに使用する専用の管理
者アカウントを作成しなければなりません。IBM Red Brick Warehouse のマニュアル
では、このアカウントを redbrick ユーザと総称します。インストレーションによ
り、すべてのユーザが正しくファイルにアクセスできるようになります。
インストール手順の詳細については、『Installation and Configuration Guide』を参照し
てください。
データベース設計の立案
Red Brick は、あらゆるデータベース スキーマをサポートしますが、データベース
設計者は実際に構築するデータウェアハウスに合ったスキーマ設計を選定する必要
があります。スキーマの物理的な配置については、まずデータの格納方法を決定し
ます。効率的にディスクへ格納するためには、データベース テーブルおよびイン
デックスのサイズを見積ることと、テーブルとインデックスに利用できるファイル
システムの構成に関する知識が必要となります。セグメント別に格納すれば、デー
タのアクセスとロードが効率的になり、大規模データベースにも対応できます。
データベースの設計では、参照整合性チェックの方法と、参照整合性を維持する方
法も考慮する必要があります。
IBM Red Brick Warehouse 概要
1-15
データベースの実装
参照整合性、セグメント別格納などの技術的な原理に関する詳細は、第 2 章「基本
概念」を参照してください。スキーマ設計の詳細は、第 3 章「スキーマ設計」を参
照してください。また、インデックス作成の方針、物理領域、サイズの見積りに関
する詳細については、第 4 章「ウェアハウス データベースの物理設計」を参照して
ください。
データベースの実装
データベースの作成と削除は、ウェアハウスが提供するユーティリティを使って行
います。各ユーティリティは、管理ユーザ (redbrick) が実行します。
新規データベースを作成するには、UNIX では rb_creator ユーティリティを、
Windows では dbcreate ユーティリティを使用します。データベースへのアクセス権
を持つ、あらかじめ決められたユーザ名が作成され、デフォルトのパスワードが設
定されます。データベース管理者は、データベースのセキュリティを確保するため
に、直ちにこのパスワードを変更してください。新規データベース作成後は、ほか
のデータベース ユーザにもアクセス権を付与することができます。
ユーザ定義のセグメントをユーザ テーブルやインデックスに使用する場合は、
CREATE SEGMENT 文でそのセグメントを指定します。その後、CREATE 文を使用
してユーザ テーブルなどのデータベース オブジェクトを作成します。CREATE 文
は、RISQL エントリ ツールを使用して対話形式またはファイルによって入力する
か、SQL を使用できるほかのクライアント ツールから入力します。セグメント、
テーブル、インデックスなどのデータベース オブジェクトに関する情報は、システ
ム テーブルに格納されます。システム テーブルの詳細は、付録 C「システム テー
ブルと動的統計テーブル」を参照してください。RISQL エントリ ツール の詳細に
ついては、
『RISQL Entry Tool and RISQL Reporter User’s Guide』を参照してください。
rb_creator ユーティリティまたは dbcreate ユーティリティの使用方法の詳細につい
ては、5-4 ページ「データベースの作成」を参照してください。CREATE 文と
GRANT 文の詳細については、『SQL Reference Guide』を参照してください。
データベース ファイルは、UNIX では rb_deleter ユーティリティで、Windows では
dbcreate ユーティリティで削除します。これらのユーティリティを実行するには、
削除するデータベース ファイルと親ディレクトリに対する書き込み許可が必要で
す。各ユーティリティの詳細については、9-105 ページ「データベースの削除」を
参照してください。
1-16 Administrator’s Guide
ユーザ アクセスの設定
ユーザ アクセスの設定
データベース管理者は、RISQL エントリ ツール、RISQL レポータ、あるいは SQL
文の入力が可能なほかのクライアント ツールを使って GRANT 文および REVOKE
文を入力することにより、ユーザ アカウントの作成、オブジェクト特権の設定、お
よびロールに基づくセキュリティ管理の確立を行います。
ユーザ アクセスとセキュリティに関する詳細については、第 7 章「データベースの
アクセス権とセキュリティ」を参照してください。データベース管理の詳細につい
ては、第 8 章「組織におけるデータベース運用の管理」を参照してください。
初期化ファイル
データベースにアクセスするユーザ セッションが起動されるたびに、サーバ初期化
ファイル ( ファイル名は .rbwrc) によってセッションが初期化されます。初期化
ファイルは、グローバル レベル、データベース レベル、ユーザ レベルのいずれで
も作成でき、セッションの起動情報を記述します。RISQL エントリ ツールと RISQL
レポータの起動情報は、別の初期化ファイル ( ファイル名は .rbretrc) に記述しま
す。
詳細については、2-22 ページ「初期設定ファイル」を参照してください。
マクロ
ユーザ セッションは、データベース毎に定義されたマクロを使用することができま
す。マクロは、データベース管理者と特権を持ったユーザが定義でき、繰り返し使
用するクエリを汎用化します。
■
■
■
特定データベースのすべてのユーザが利用できるパブリック マクロ
特定データベースでマクロの作成者だけが利用できるプライベート マクロ
セッションの接続中のみ存在し、作成者だけが利用できるテンポラリ マク
ロ
SQL マクロの詳細については、5-59 ページ「マクロの作成と管理」および『SQL
Reference Guide』を参照してください。
IBM Red Brick Warehouse 概要
1-17
データのロードおよびアンロード
データのロードおよびアンロード
システム テーブルとユーザ テーブルの作成後は、Table Management Utility (TMU) を
使ってデータベースにデータをロードし、データの抽出に使用するインデックスを
作成します。ロード方法には、大量データの一括ロードとインクリメンタル ロード
があります。データをソートするとロード性能が向上しますが、TMU ではソート
していないデータもロードできます。
TMU は、自動集約保守にも使用します。詳細テーブルがロードされると、その
テーブルに関連する事前計算ビューは増分方式で更新されるか、全面的に作成し直
されます。集約保守については、
『IBM Red Brick Vista User’s Guide』を参照してくだ
さい。
TMU に関する詳細およびテーブルのロードとアンロードに関する詳細については、
付録 A「例 : データベースの作成」および『Table Management Utility Reference
Guide』を参照してください。
クエリと同時のロード
バージョニング機能を使用すると、クエリと同時に更新を実行できます。バージョ
ニングの詳細については、第 6 章「バージョン管理されたデータベースの使用」を
参照してください。
クエリ結果のエクスポート
EXPORT 機能を使用すると、クエリの結果を指定したファイルに効率的にエクス
ポートできます。EXPORT 文については、
『SQL Reference Guide』を参照してくださ
い。この機能のタスク権限については、7-12 ページ「タスク権限」を参照してくだ
さい。
1-18 Administrator’s Guide
データベースのメンテナンスと性能の調整
データベースのメンテナンスと性能の調整
データベースの更新に伴い、データベース管理者は以下のような保守作業を行う必
要があります。
■
■
■
■
■
クエリ パフォーマンスの監視
使用状況やデータベース環境の変化に応じて、構成パラメータの修正、メ
モリ容量の調整、一時領域の割り当て、データの格納とアクセスを効率化
するテーブルの再編成、必要に応じた新規のインデックスと集約テーブル
の作成など、性能を高める操作 Query Performance Monitor を使用して、特
定のクエリの性能を向上させることができます。
データベースに必要な格納領域の監視と、データベースの拡大に応じた追
加領域の割り当て
データやデータベースの変更が反映されるようなテーブルとセグメントの
修正
回復不能なデータ消失を防ぐための定期的バックアップ
データベース操作の監視と制御
データベースのメンテナンスに関する詳細については、第 9 章「データ ウェアハウ
スのメンテナンス」を参照してください。企業内データベースの管理の詳細につい
ては、第 8 章「組織におけるデータベース運用の管理」を参照してください。性能
の調整と Query Performance Monitor に関する詳細については、『Query Performance
Guide』を参照してください。
パックアップおよび復旧の手順の計画
ほとんどのデータベースは、テーブルのロードや、サーバ側での DDL 操作および
DML 操作によって定期的に変更されます。したがって、システムやソフトウェア
の障害に備えてデータベースを定期的にバックアップしておく必要があります。障
害が発生した場合でも、最近のバックアップ データがあれば、データベースを完全
に復旧することができます。データベースが大きくなればなるほど、バックアップ
の重要性は高まります。データベースをいつ、どのぐらいの頻度でバックアップす
るかを決める前に、実行できる Table Management Utility (TMU) バックアップの種類
を理解して、それぞれのバックアップにかかる時間と労力を予測しておく必要があ
ります。また、障害の影響を受けるデータの量をデータベースの増大に合わせて考
慮し、必要な場合にデータベースを復旧できるように準備しておく必要がありま
す。
TMU はオンライン バックアップとチェックポイント バックアップに加え、部分的
な復元操作および全面的な復元操作をサポートします。詳細については、『Table
Management Utility Reference Guide』を参照してください。
IBM Red Brick Warehouse 概要
1-19
Aroma サンプル データベース
Aroma サンプル データベース
本書、『SQL Reference Guide』、『SQL Self-Study Guide』の例は、Aroma というデー
タベースを主に使用しています。Aroma は、コーヒー専門チェーン店での売上を解
析する小規模なデータベースです。Aroma データベースは、データベース サーバ
のインストール時にインストールされます。Aroma データベースの作成と使用方法
の詳細については、付録 A「例 : データベースの作成」を参照してください。
データベースの制限
IBM Red Brick Warehouse データベース、SQL、および RISQL 拡張機能には、以下の
制限があります。
■
■
■
■
■
■
■
■
■
■
■
■
■
■
1 つのデータベースに格納できるテーブルの最大数は、32,767 です。
1 つのセッションに格納できる一時テーブルの最大数は、4,096 です。
1 つのデータベースに格納できるセグメントの最大数は、61,439 です。
1 つのセグメントに割り当てられるファイルの最大数は 250、1 つのファイ
ルの最大容量は 2GB です。したがって、1 セグメントの最大容量は 500GB
になります。
1 つのテーブルには、7,280 列まで作成することができます。
1 つのテーブルに設定できるフォーリン キーの最大数は 256 です。
1 つのテーブルに格納できる行の最大数は、248 です。
テーブルが 8 列未満の場合は、その行に最大 8178 バイトのデータを含める
ことができます。列数が 8 以上の場合は、最大量は 8 列当たり 1 バイトず
つ減少します。可変長文字データを含む行の最大長は、テーブルの
VARCHAR 列ごとに 4 バイト少なくなります。
クエリの中間および最終結果テーブルには、約 8KB の最大行サイズを含め
ることができます。この制限は、テーブルの行の最大サイズと同じです。
マクロ定義に使用できるテキストの最大長は 1024 バイトです。
CHAR 列または VARCHAR 列の最大長は 1024 バイトです。
文字リテラルの最大長は 1024 バイトです。
データベース識別子の最大長は 128 バイトです。
データベース パスワードの最大長は 128 バイトです。RISQL エントリ ツー
ルや RISQL レポータを使用する場合、プロンプトに対して入力できるパス
ワードの最大長は 8 文字になります。
警告 : これらの制限は、データベース ファイルのサイズを推定するためのもので
はありません。テーブルやインデックスに必要な物理領域を算出する手順は、第 4
章「ウェアハウス データベースの物理設計」を参照してください。
1-20 Administrator’s Guide
第2章
基本概念
データのロード .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-3
並列処理
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-5
データベースの物理的構成 . . . . . . . . . . .
インデックスの作成と検索効率 . . . . . . . .
格納領域のセグメント化 . . . . . . . . . .
名前付きセグメントとデフォルト セグメント .
物理構成 . . . . . . . . . . . . . .
複数セグメントへのデータの分散 . . . . . .
オンライン セグメントとオフライン セグメント
テーブルとインデックスの部分的な利用 . . .
クエリ性能を向上する事前計算ビュー . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-6
2-6
2-7
2-8
2-9
2-10
2-12
2-13
2-14
アプリケーションへの入力のためのクエリ
サンプリング . . . . . . . . . .
.
.
.
.
.
2-15
.
.
.
.
.
.
.
データベースのディレクトリとファイル . . . .
データベース論理名 . . . . . . . . . .
セグメント名 . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
2-15
2-16
2-21
環境設定と初期化 . . . . . .
コンフィグレーション ファイル
初期設定ファイル . . . . .
.rbwrc ファイル . . . .
.rbretrc ファイル . . . .
ODBC 初期設定ファイル .
SET コマンド . . . . . .
環境変数 . . . . . . . .
Administrator ツール . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
. .
. .
. .
. .
. .
2-21
2-21
2-22
2-22
2-23
2-24
2-24
2-25
2-25
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
サーバ ロケール . . . . . . . . . . .
ロケールの要素 . . . . . . . . .
言語 . . . . . . . . . . . .
テリトリ . . . . . . . . . . .
コード セット . . . . . . . . .
照合シーケンス . . . . . . . .
サーバ ロケールの設定 . . . . . . .
ロケールのシステム テーブルへの格納
ロケールで変更できないテキスト . .
サーバ ロケールのオーバーライド . . .
クライアント ツールのロケール設定 .
環境変数 RB_NLS_LOCALE の設定 .
クライアント / サーバの互換性 . . . .
コード セットの変換 . . . . . .
メッセージ システム . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-27
2-27
2-27
2-28
2-28
2-29
2-30
2-30
2-31
2-31
2-32
2-32
2-34
2-34
2-35
ファイルの所有権とアクセス許可
.
.
.
.
.
.
.
.
.
.
.
.
.
2-36
.
.
.
.
.
.
.
.
.
.
.
.
.
2-37
バージョン管理されたデータベース .
.
.
.
.
.
.
.
.
.
.
.
.
2-38
参照整合性 . . . . . . . . . . .
データのロードと挿入 . . . . . .
データの削除とカスケード デリート .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2-39
2-39
2-40
データベースの権限と特権 .
2-2 Administrator’s Guide
.
.
この章について
データベース管理機能を効率的に実行するには、IBM Red Brick Warehouse の基本的
な動作を理解しておく必要があります。この章では、以下について説明します。
■
■
■
■
■
■
■
■
■
■
■
データのロード
並列処理
データベースの物理的構成
アプリケーションへの入力のためのクエリ サンプリング
データベースのディレクトリとファイル
環境設定と初期化
サーバ ロケール
ファイルの所有権とアクセス許可
データベースの権限と特権
バージョン管理されたデータベース
参照整合性
データのロード
データは Parallel Table Management Utility (Parallel TMU) によって一括処理でロードさ
れます。ロードの進行中に、Parallel TMU はデータにインデックスを付け、参照整
合性を確認し、必要に応じて集約テーブルを保守します。データロードは CPU 集約
型の処理であるため、CPU の能力が高いほどロードが短時間ですみ、CPU の性能に
ほぼ正比例します。IBM Red Brick Warehouse のロード処理は CPU 集約型ですが、ほ
かの RDBMS データベースのロードと同じか、それ以上の性能を発揮します。
基本概念
2-3
データのロード
TMU がサポートするデータ型は、次のとおりです。
■
■
■
ASCII 文字セットや IBM U.S. EBCDIC 文字セットを含む、シングルバイト
およびマルチバイト文字
サポートされるハードウェア プラットフォームおよび IBM System/370 の
整数データおよび数値データ
IBM System/370 のパック 10 進数データとゾーン 10 進数データ
データのロードは次の方法で行えます。
UNIX
■
■
■
ディスク上のファイルを使用
ほかのシステム プログラムのパイプを使用
TAR フォーマットまたは ANSI 標準ラベルのテープを使用 ♦
データベース管理者は TMU プログラムをリモート起動して、ネットワークで結ば
れたクライアント マシン上にある入力ファイルから、プロダクション サーバ マシ
ン上のデータベース テーブルにデータをロードできます。
複数のユーザ定義インデックスを持つテーブルについては、インデックスの並列作
成を利用するとインデックスの作成時間が短くなり、各インデックスを個別に作成
するよりも効率的になります。
ユーザ定義インデックスは、データをロードする前でも後でも定義することができ
ます。インデックスを持つテーブルのロードの詳細については、5-33 ページ「イン
デックスの作成」を参照してください。
2-4 Administrator’s Guide
並列処理
並列処理
IBM Red Brick Warehouse は、シングル マイクロプロセッサ システムから大規模なマ
ルチプロセッサ システムまで、幅広いハードウェア システム上で動作します。
データベースのロードとクエリ処理に必要な性能、およびシステムのロード性能に
応じて、データベース サーバや TMU のプロセスが複数プロセッサを活用する度合
いを設定することができます。
IBM Red Brick Warehouse では、複数プロセッサを用いた並列処理だけでなく、作業
を複数のプロセスに自動的に分割することで、単一プロセッサ システムにも並列処
理を取り入れています。たとえば、データの格納状況に応じて一部のクエリを複数
のプロセスに分割し、1 つのプロセスがディスクの入出力を待機している間にほか
のプロセスを処理し、クエリ処理の効率と速度を上げることができます。
IBM Red Brick Warehouse のディメンジョナル セグメンテーションを使用して、複数
のドライブにデータを格納した場合は、並列処理により複数のディスクに同時アク
セスできるため、性能が大幅に向上します。
クエリの並列処理の詳細については、『Query Performance Guide』を参照してくださ
い。
UNIX
UNIX では、また 1 つのディスクにデータが格納されている場合でも、あるプロセ
スが読み込んだデータをほかのプロセスが活用するデータベース サーバの
SuperScan 技術により、各プロセスのディスク アクセスの遅延を短縮することがで
きます。♦
基本概念
2-5
データベースの物理的構成
データベースの物理的構成
IBM Red Brick Warehouse は複数のデータベースを構築することができ、システム
ディスクのスペースが許すかぎり、事実上数に制限はありません。通常は、1 ∼ 20
のデータベースを作成、使用します。
データベースは、システム テーブル、コントロール ファイル、任意の数のユーザ
テーブルを格納する独立したシステムです。ユーザ テーブルには、ユーザがアクセ
ス更新する実際のデータが格納されます。データベースには、ユーザ テーブルのほ
かに、シノニム ( テーブルの別名 )、各ユーザへのテーブル データの見せ方を制限
するビュー、実行頻度の高い操作を SQL で簡単に実行する方法を定義するマクロも
格納できます。
インデックスの作成と検索効率
ユーザ テーブルには、各種のインデックスを作成することができます。インデック
スは、ウェアハウスのユーザが認識するものではありませんが、データの整合性と
性能には不可欠なものです。IBM Red Brick Warehouse は、データの整合性確保に必
要なインデックスを自動的に作成します。これ以外にも、性能の向上のためのイン
デックスをデータベース管理者が作成することができます。
■
■
■
■
2-6 Administrator’s Guide
STAR インデックスは、フォーリン キー参照により関連するテーブルの
ジョイン処理 (STARjoin) や、共通の列を基準としたテーブル ジョインを効
率化します。STAR インデックスは、マルチテーブル ジョインを高速化す
るインデックスです。管理者は、任意の数の STAR インデックスを作成
し、性能の向上を図ることができます。複数の STAR インデックスがある
場合は、Red Brick server がコスト モデルを適用し、クエリの実行に最適な
STAR インデックスを自動的に選択します。
B-TREE インデックスは、性能の向上とデータの整合性確保のために使用
されます。Red Brick server は、プライマリ キーごとに B-TREE インデック
スを 1 つずつ自動作成し、値の一意性とフォーリン キー参照の整合性を保
証します。管理者は、任意のテーブル列や、クエリで制約する列につい
て、クエリ性能を高めるほかの B-TREE インデックスを作成することがで
きます。インデックスが増えると、必要な格納領域も増えるため、処理速
度と格納領域を考慮して作成する必要があります。
TARGET インデックスは、クエリが制限が弱い複数の制約からなる場合
に、性能を向上させます。パフォーマンスは 2 倍に向上します。クエリの
実行速度が上がり、処理に必要なメモリの量が少なくなります。
TARGETjoin 処理は参照元 ( ファクト ) テーブルのフォーリン キーで
TARGET または B-TREE インデックスを利用してマルチテーブル ジョイン
を実行します。TARGETjoin 処理は STARjoin 処理を補完します。この 2 つ
の技術を組み合わせることで広範囲のクエリで最高の性能を実現します。
格納領域のセグメント化
格納領域のセグメント化
ユーザ テーブルとインデックスは、それぞれ別のセグメントに格納されます。セグ
メントは、オペレーティング システムのファイル、つまり物理格納ユニット (PSU)
の集まりです。PSU は、テーブルやインデックスのデータに必要な物理ディスク上
の格納領域です。
大規模データベースの場合、格納領域のセグメント化には以下のような利点があり
ます。
■
■
■
■
■
■
必要に応じて格納領域を動的に割り当て、論理データを物理セグメントに
マッピングすることができます。
データベースのロードと更新を容易にします。定期的にデータを追加した
り削除したりする場合は特に便利です。
並列クエリ処理のためにデータを分割することができます。
クエリ処理の並列性は、テーブルに使用するセグメントと PSU の数 ( デー
タ セグメントとインデックス セグメントの合計 ) に依存します。
テーブル レベルではなく、セグメント レベルのロックができるため、オ
フライン ロード操作とクエリ処理を同時に行うことができます。
一部のデータ セグメントやインデックスが利用不能な場合、クエリを部分
的に実行することができます。
格納媒体に障害が発生した場合、小さな単位でデータの復元ができます。
基本概念
2-7
格納領域のセグメント化
名前付きセグメントとデフォルト セグメント
名前付きセグメントとデフォルト セグメントの 2 種類のセグメントがあります。名
前付きセグメントは、CREATE SEGMENT 文を使って管理者が明示的に作成するセ
グメントです。デフォルト セグメントは、名前付きセグメントに配置されないテー
ブルやインデックスについて、システムが自動的に作成するセグメントです。
大規模データ ウェアハウスでは、名前付きセグメントを使用することをお勧めしま
す。名前付きセグメントを利用すると、セグメントの設計、作成、管理が必要には
なりますが、ディスク領域の割り当て、ファイルのサイズと配置、データベースの
拡張に対して管理者が制御できる範囲が広がるからです。名前付きセグメントを使
うと、テーブルを水平に分割し、データを複数のセグメントに分散させることがで
きます。セグメント単位でデータを管理できるため、メンテナンスが簡単になり、
アクセスを効率化できます。
重要 : クエリの並列処理を実行する場合は、名前付きセグメントを使用する必要
があります。
例
格納領域のセグメント化の例として、過去 2 年間の売上データを追跡するデータ
ベースを考えてください。データは複数のセグメントに分散され、各セグメントに
はそれぞれ 1 カ月分のデータが格納されます。売上データは、データベースのほか
の部分とは独立して、セグメント単位で追加、ロード、削除できるようにします。
毎月、インデックスを付けた当月分のデータをロードしたセグメントを追加し、最
も古い月のデータを格納しているセグメントを削除すれば良いのです。データベー
スをオフラインにしなくても各セグメントが更新でき、削除した古いセグメントの
領域は、来月のデータに使用することができます。詳細については、4-22 ページ
「定期的にデータを更新するデータベースの設計」、5-41 ページ「定期的に更新され
るデータベースの作成」および 9-56 ページ「定期的に更新されるデータベースのメ
ンテナンス方法」を参照してください。
デフォルト セグメントは特別な管理を必要としません。実際、管理者とユーザのど
ちらもその存在を意識する必要はありません。デフォルト セグメントのテーブルと
インデックスは、複数のセグメントやファイルに分散させることができます。デ
フォルト セグメントの PSU は、データベース ディレクトリ ( またはユーザが指定
したデフォルト ディレクトリ ) に配置されます。
デフォルト セグメントは、デフォルトの 2 GB に収まるような小規模なテスト用
データベースに便利です。状況が変わって、デフォルト セグメントのテーブルのサ
イズと拡張をさらに制御する必要が生じた場合は、これらのデフォルト セグメント
を名前付きセグメントにアタッチして変更できます。詳細については、9-45 ページ
「シングル セグメント テーブルまたはインデックスへのセグメントのアタッチ」を
参照してください。
2-8 Administrator’s Guide
格納領域のセグメント化
物理構成
セグメント化した格納領域の物理構成は、以下のようになります。
■
■
■
■
1 つのセグメントは、任意の数の物理格納ユニット (PSU) で構成できます。
1 つの PSU は、1 つのセグメントだけに属します。
1 つのセグメントには、1 つのテーブルの行データか、1 つのインデックス
のインデックス データのどちらかを格納でき、両方を格納することはでき
ません。
テーブルの行データとインデックスは、複数のセグメントに分散させるこ
とができます。
セグメントは、作成時に指定したディレクトリ、構成ファイルに指定したデフォル
トのロケーション、データベースを格納しているディレクトリのいずれかに配置さ
れます。
次の図は、デフォルト セグメントと名前付きセグメントの使い方を示したもので
す。
図 2-1
名前付きセグメントとデフォルト セグメントの使用法
名前付きセグメント
行データ
STAR
インデックス
セグメント
セグメント
セグメント
セグメント
セグメント
デフォルト セグメント
セグメント
セグメント
行データ
セグメント
STAR
インデックス
セグメント
セグメント
プライマリ
インデックス
セグメント
セグメント
プライマリ
インデックス
TARGET
インデックス
セグメント
セグメント
TARGET
セグメント
インデックス
名前付きセグメントは、CREATE SEGMENT 文で作成します。CREATE TABLE 文で
行データのセグメントと自動生成インデックスのセグメントをテーブルに割り当て
ます。管理者が作成するインデックスには、CREATE INDEX 文でセグメントを割り
当てます。
テーブルまたはインデックスにセグメントが割り当てられていない場合は、1 つま
たは複数の PSU からなるデフォルト セグメントにテーブルまたはインデックスが
作成されます。
基本概念
2-9
格納領域のセグメント化
複数セグメントへのデータの分散
行データは、指定した列 ( セグメント化の基準となる列 ) の値の範囲か、ハッシュ
によって複数のセグメントに分散させることができます。値の範囲に基づくセグメ
ント化は、データおよび対応するインデックスの格納先が明らかになるという利点
がありますが、データが均等に分散されないことがあります。ハッシュによるセグ
メント化の場合は、データが均等に分散され、ホット スポットを回避できますが、
データのロケーションが不明なため、オフライン操作の使用が制限されます。ハッ
シュを使用すると、すべての行がハッシュの対象になります。
TARGET および B-TREE インデックスのインデックス エントリは、以下の 2 つの方
法で複数のセグメントに分散できます。
■
インデックスの先頭列の値の範囲を基準にして分散
B-TREE インデックスの場合、先頭列とは、CREATE INDEX 文で最初に指
定した列です。プライマリ インデックスは、B-TREE インデックスで、イ
ンデックスの先頭列のキー値でセグメント化することも可能です。
TARGET インデックスの場合、先頭列とは、CREATE TARGET INDEX 文で
指定した列だけです。
インデックスでこのセグメント化を定義するためのさまざまな SQL 句につ
いての詳細については、5-15 ページ「セグメント化の方法」を参照してく
ださい。
■ テーブルのセグメント化に使用されるのと同じ列値を使用して分散
この場合、基準となる列はインデックスの列である必要はありません。こ
の方法でセグメント化されたインデックスは、ローカル インデックスと呼
ばれ、各インデックス セグメントは対応するテーブル セグメントの行
データを示します。ローカル インデックスとして定義できるのは、BTREE インデックスと TARGET インデックスだけで、プライマリ インデッ
クスはローカル インデックスとしては定義できません。ローカル イン
デックスを定義する方法については、5-15 ページ「セグメント化の方法」
を参照してください。
ローカル インデックスを使用すると、定期的に更新されるデータの
TARGET join 処理に使用される TARGET および B-TREE インデックスのメ
ンテナンスが容易になります。ローカル インデックスを使用すると、
TARGETjoin の処理性能は向上しますが、パラメータを調整しないと、ほ
かのクエリ処理の性能が低下することがあります。詳細については、
『Query Performance Guide』を参照してください。ローカル インデックスを
使用して、定期的に更新されるデータのメンテナンスを容易にする方法に
ついては、4-24 ページ「ローカル インデックスの特性」を参照してくださ
い。
2-10 Administrator’s Guide
格納領域のセグメント化
STAR インデックスのインデックス エントリはインデックス データの値ではなく、
そのデータを格納している参照先テーブルの行番号になります。STAR インデック
ス エントリを複数のセグメントに分散する方法は 2 種類あります。
■
■
セグメント間に均一に分散 ( デフォルトの方法 )
この場合、各セグメントにはほぼ同じ数のエントリが格納されます。
インデックスの先頭列がテーブルのセグメント化の基準となる列である場
合に、インデックスの先頭列の値の範囲を基準に分散
STAR インデックスのインデックス エントリは、参照先の列の行番号で
す。STAR インデックスの内容の詳細については、5-16 ページ「STAR イ
ンデックスのセグメント化」を参照してください。STAR インデックスの
このセグメント化を定義するためのさまざまな SQL 句についての詳細につ
いては、5-15 ページ図 5-2 を参照してください。
例
図 2-2 は、2 つのインデックスのついたテーブルの行データ セグメントとインデッ
クス エントリ セグメントの関係を示したものです。このテーブルには、STAR イン
デックスと、TARGET インデックスがあり、いずれも同じデータ値でセグメント化
されています。STAR インデックスの先頭列は、このテーブルのセグメント化の基
準となる列と同じです。ローカル TARGET インデックスには、このテーブルのセグ
メント化の基準となる列が含まれている必要はありません。
対応するデータ セグメントとインデックス セグメントを両方ともオンラインかオ
フラインにし、データベースのほかの部分を使用しながらセグメントを操作するこ
とができます。このセグメント化により、2-8 ページの例でデータを定期的に更新
するのが容易になります。また、ローカル インデックスを使用すると、定期的に更
新されるデータのメンテナンスも容易になります。詳細については、4-24 ページ
「ローカル インデックスの特性」を参照してください。
基本概念
2-11
格納領域のセグメント化
データ セグメン
トと同様にセグ
メント化された
TARGET イン
デックス
図 2-2
行データ
セグメント
セグメント化の 基準となる列
データ セグメント
と同様にセグメン
ト化された STAR
インデックス
データ セグメント
と同様にセグメント
化された行データ
セグメントと
インデックス
先頭列
オンライン セグメントとオフライン セグメント
テーブルまたはインデックスのセグメントは、オンラインかオフラインのどちらか
になっています。1 つのテーブルおよびテーブルのインデックスのセグメントがす
べてオンラインの場合は、テーブル全体にアクセスできます。オンラインが通常の
状態です。テーブルおよびインデックスのセグメントに、オフライン セグメントが
1 つ以上ある場合、そのテーブルは部分的にしか利用できません。
セグメントをオフラインにできるのは、テーブルやインデックスのセグメントが複
数ある場合だけです。テーブルやインデックスが 1 つのセグメントだけに格納され
る場合は、オフラインにすることはできません。定義では、デフォルト セグメント
には、1 つのテーブルまたはインデックス全体が格納され、オフラインにすること
はできません。ただし、管理者はセグメント化の基準となる列を指定してテーブル
またはインデックスを変更すれば、そのテーブルまたはインデックスにデフォルト
セグメントに格納されている名前付きセグメントをアタッチできます。詳細につい
ては、9-45 ページ「シングル セグメント テーブルまたはインデックスへのセグメ
ントのアタッチ」を参照してください。この場合、デフォルト セグメントはテーブ
ルの複数のセグメントの中の 1 つになり、オフラインにできます。
管理者はセグメントごとに、オフライン、新規データのロード、セグメントの変
更、格納媒体の障害時のリストア、テーブルからの切り離し、テーブルからの削除
を行うことができます。テーブルは部分的に利用可能なため、セグメントがオフラ
インでもユーザはアクセスすることができます。
2-12 Administrator’s Guide
格納領域のセグメント化
テーブルとインデックスの部分的な利用
オフラインの行データ セグメントがあり、部分的にしか利用できないテーブルに対
するクエリの動作は、SET コマンドで以下のいずれかに指定します。
■
■
■
すべてのクエリを処理し、結果を返します。オフライン セグメントにアク
セスするクエリの場合は、結果が不正確 / 不完全 / 無効なことがあるとい
う警告メッセージが表示されます。
オフライン セグメントにアクセスするクエリのみを禁止します。ほかのク
エリからは、結果が返されます。
オフライン セグメントを持つテーブルに対するすべてのクエリを禁止しま
す。
オフラインのインデックス セグメントがあるために部分的にしか利用できないテー
ブルに対するクエリの動作は、すべてのインデックスを考慮して最適なクエリ処理
方法を選択するか、または全体が利用可能なインデックスだけから選択するかのど
ちらかを SET コマンドで指定します。部分的に利用可能なテーブルに対するクエリ
の動作の詳細については、『Query Performance Guide』を参照してください。
オフライン ロード操作を除き、部分的に利用可能なテーブルとインデックスの内容
を修正する操作は禁止されます。たとえば、データのロード、挿入、更新、削除
や、インデックスの作成と削除などです。削除操作は、部分的に利用可能なテーブ
ルのフォーリン キーが参照しているテーブルに対しても禁止されます。
基本概念 2-13
クエリ性能を向上する事前計算ビュー
クエリ性能を向上する事前計算ビュー
大規模なデータベースでは、集約テーブルを使用するとクエリ性能を飛躍的に向上
することができます。事前計算ビューを定義し、利用可能な最適の集約テーブルを
利用するように、自動的にクエリを書き換えることができます。事前計算ビューの
定義には、以下が含まれます。
■
■
事前計算された集約値を格納する物理テーブル
クエリ書き換えエンジンに事前計算テーブルの存在を認識させ、詳細レベ
ルのテーブル ( 例 : 日別売上 ) に対するクエリを、事前計算テーブル ( 例 :
月別売上 ) を検索するように書き換える論理ビュー
さらに、論理的ロールアップ階層構造を定義し、事前計算 ( 集約 ) テーブルのデー
タと完全一致しないクエリを、事前計算テーブルを利用するように書き換えること
ができます。
データベースの導入を計画する場合は、作成する事前計算 ( 集約 ) テーブルを設計
しなければなりません。集約テーブルはほかの種類のテーブルとまったく同様のも
のです。したがって、集約テーブルは、セグメント化、インデックス付けが可能で
あり、またセグメント化、インデックス付けされなければなりません。集約テーブ
ルは、一般的にプライマリ キー / フォーリン キー定義を含むので、STAR インデッ
クスを指定して STARjoin 処理を有効にしたり、フォーリン キーに TARGET イン
デックスおよび B-TREE インデックスを指定して TARGETjoin 処理を有効にするこ
ともできます。
Vista には、集約テーブルの詳細テーブルが更新された場合に集約テーブルを自動的
に更新する、集約保守サービスがあります。集約保守により、ユーザ定義の更新ス
クリプトがなくても、詳細テーブルと集約テーブルの一貫性が保証されます。
Vista オプションには、クエリ履歴データをログ ファイルに記録する Advisor も組み
込まれています。Advisor は、ログ ファイルを使って、データベース内の事前計算
ビューがアクセスされる頻度と、事前計算ビューが実現する性能上の効果 (Benefit)
を記録します。
Vista の使用方法の詳細については、『IBM Red Brick Vista User’s Guide』を参照して
ください。
2-14 Administrator’s Guide
アプリケーションへの入力のためのクエリ サンプリング
アプリケーションへの入力のためのクエリ
サンプリング
IBM Red Brick Warehouse には、完全なデータ セットではなく行のランダムなサンプ
ルを処理するクエリを実行するための、サンプリング機能があります。サンプリン
グを使用するクエリのリザルト セットは、完全なリザルト セットを代表するもの
であり、サンプリングによるクエリの結果が、別のアプリケーションへの入力デー
タになることがあります。たとえば、クエリの結果をテスト データベースのトレー
ニング セットや、データ マイニング プログラムに渡されるデータとして使用する
場合です。この場合は、サンプリング機能は性能最適化機能というよりアプリケー
ション拡張機能という方が適切です。クエリまたはサブクエリが完全なリザルト
セットを返すためにテーブル スキャンを必要とする場合を除き、サンプリングでク
エリまたはサブクエリの性能が最適化されることはありません。テーブル スキャン
を必要としないクエリでは、サンプリング機能を使用すると性能が低下することが
あります。
Vista Advisor で実行する候補ビューの分析については、ファクト テーブル行のサン
プルを強制的に使用しても、性能は最適化されません。候補分析を最適化するに
は、『IBM Red Brick Vista User’s Guide』の説明に従って、デフォルトのパラメータ
ADVISOR_SAMPLE_SIZE を使用することをお勧めします。
クエリ サンプリングの詳細については、『SQL Reference Guide』を参照してくださ
い。
データベースのディレクトリとファイル
初期化されたデータベースは、データベース ディレクトリという 1 つのディレクト
リに格納されます。データベース ディレクトリには、コントロール ファイルとシ
ステム テーブルが格納されます。デフォルト セグメントはデータベース ディレク
トリに作成され、ユーザ テーブルとインデックスを格納します。名前付きセグメン
トを使うと、データベース ディレクトリのサブディレクトリ以外のディレクトリ
や、複数のファイル システムのディレクトリに各ファイルを格納することができま
す。
データベース ディレクトリを含め、名前付きセグメントを格納するディレクトリ
は、オペレーティング システムのファイル領域 ( 任意のファイル システムのディレ
クトリ構造体 ) のどこにでも配置できます。
基本概念 2-15
データベース論理名
データベースおよびデータベースのセグメントのディレクトリとファイルは、すべ
て redbrick ユーザが所有者でなければなりません。セキュリティを確保するため、
ほかのユーザやグループに読み込みや書き込みのアクセス権を与えないようにして
ください。データベース ディレクトリとテーブルのセグメントを格納するディレク
トリの内容へのアクセスは、IBM Red Brick Warehouse が管理します。
データベース論理名
ユーザがアクセスするデータベースは、データベース論理名によって指定します。
IBM Red Brick Warehouse は、データベース論理名を対応するパスに変換します。
データベース論理名とデータベース ディレクトリのパスの対応は管理者が設定し、
rbw.config ファイルに記述します。
次に、一般的なデータベース ディレクトリの内容と構造を示します。
例
デフォルト セグメントを使ったデータベース作成のステートメントの例を示しま
す。データベース ディレクトリの名前は newdb です。ディレクトリのパスは、
UNIX では /warehouse/mktg/newdb、Windows では c:¥warehouse¥mktg¥newdb です。
CREATE TABLE period (
...
PRIMARY KEY (perkey));
CREATE TABLE product (
...
PRIMARY KEY (prodkey));
CREATE TABLE market (
...
PRIMARY key (mktkey));
CREATE TABLE fact1 (
...
PRIMARY KEY (perkey, prodkey, mktkey)
FOREIGN KEY (perkey) REFERENCES period (perkey)
FOREIGN KEY (prodkey) REFERENCES product (prodkey)
FOREIGN KEY (mktkey) REFERENCES market (mktkey));
次の図は、デフォルト セグメントを使った前述のデータベースを格納しているディ
レクトリの内容です。
デフォルト セグメントでは、テーブルとインデックスがそれぞれ別のセグメントに
格納され、どのセグメントも最初は 1 つの PSU で構成されます。テーブルのデータ
が増え、1 つの PSU に格納しきれなくなった場合は、必要な数の PSU を追加するこ
とができます。
2-16 Administrator’s Guide
データベース論理名
図 2-3
論理データ ベース
名のディレクトリ
In newdb directory
RB_DEFAULT_IDX
RB_DEFAULT_INDEXES
RB_DEFAULT_LOCKS
rb_creator (UNIX) または dbcreate (Windows)
で作成されたデータベース システム ファイル
RB_DEFAULT_SEGMENTS
RB_DEFAULT_TABLES
RB_DEFAULT_LOADINFO
TMU LOAD で作成
dfltseg1_psu1
dfltseg2_psu1
dfltseg3_psu1
...
CREATE TABLE 文で作成したテーブルと
インデックスのデフォルト セグメント
dfltseg8_psu1
基本概念 2-17
データベース論理名
例
上記と同じデータベースを newdb ディレクトリに作成し、Fact1 テーブルとそのイ
ンデックスを格納するセグメントを作成する例を示します。Fact1 テーブルのデー
タは期間別にセグメント化され、1 つのセグメントには 1999 年のデータ、もう 1 つ
には 2000 年のデータが格納されます。プライマリ キー インデックスが作成され、3
つ目のセグメントに格納されます。
UNIX
CREATE SEGMENT fact_99
STORAGE '/disk1/fact_99/99_dat1'
MAXSIZE 1000 initsize 100 extendsize 100,
STORAGE '/disk1/fact_99/99_dat2'
MAXSIZE 1000 initsize 100 extendsize 100;
CREATE SEGMENT fact_00
STORAGE '/disk2/fact_00/00_dat1'
MAXSIZE 1000 initsize 100 extendsize 100,
STORAGE '/disk2/fact_00/00_dat2'
MAXSIZE 1000 initsize 100 extendsize 100;
CREATE SEGMENT fact_pi
STORAGE '/disk2/fact_pi/fact_pi1'
MAXSIZE 100 initsize 20 extendsize 10,
STORAGE '/disk2/fact_pi/fact_pi2'
MAXSIZE 100;
CREATE TABLE market (
...
PRIMARY key (mktkey));
CREATE TABLE product (
...
PRIMARY KEY (prodkey));
CREATE TABLE period (
...
PRIMARY KEY (perkey));
CREATE TABLE fact1 (
...
PRIMARY KEY (perkey, prodkey, mktkey)
FOREIGN KEY (perkey) REFERENCES period(perkey)
FOREIGN KEY (prodkey) REFERENCES product (prodkey)
FOREIGN KEY (mktkey) REFERENCES market (mktkey)
) DATA IN (fact_99, fact_00)
SEGMENT BY VALUES OF (perkey)
RANGES (MIN:'1998-12-31', '2000-01-01':MAX)
PRIMARY INDEX IN fact_pi;
2-18 Administrator’s Guide
データベース論理名
ディレクトリ /disk1/fact_99、/disk1/fact_00、/disk2/fact_pi は、CREATE SEGMENT
文を実行する前に作成しておく必要があります。セグメント名とディレクトリ名
は、同じでなくてもかまいません。♦
Windows
CREATE SEGMENT fact_99
STORAGE 'c:¥disk1¥fact_99¥99_dat1'
MAXSIZE 1000itsize 100 extendsize 100,
STORAGE 'c:¥disk1¥fact_99¥99_dat2'
MAXSIZE 1000 initsize 100 extendsize 100;
CREATE SEGMENT fact_00
STORAGE 'c:¥disk2¥fact_00¥00_dat1'
MAXSIZE 1000itsize 100 extendsize 100,
STORAGE 'c:¥disk2¥fact_00¥00_dat2'
MAXSIZE 1000 initsize 100 extendsize 100;
CREATE SEGMENT fact_pi
STORAGE 'c:¥disk2¥fact_pi¥fact_pi1'
MAXSIZE 100 initsize 20 extendsize 10,
STORAGE 'c:¥disk2¥fact_pi¥fact_pi2'
MAXSIZE 100;
CREATE TABLE market (
...
PRIMARY key (mktkey));
CREATE TABLE product (
...
PRIMARY KEY (prodkey));
CREATE TABLE period (
...
PRIMARY KEY (perkey));
CREATE TABLE fact1 (
...
PRIMARY KEY (perkey, prodkey, mktkey)
FOREIGN KEY (perkey) REFERENCES period(perkey)
FOREIGN KEY (prodkey) REFERENCES product (prodkey)
FOREIGN KEY (mktkey) REFERENCES market (markey)
) DATA IN (fact_99, fact_00)
SEGMENT BY VALUES OF (perkey)
RANGES (MIN:'1999-12-31', '2000-01-01':MAX)
PRIMARY INDEX IN fact_pi;
ディレクトリ c:¥disk1¥fact_99、c:¥disk1¥fact_00、c:¥disk2¥fact_pi は、CREATE
SEGMENT 文を実行する前に作成しておく必要があります。セグメント名とディレ
クトリ名は、同じでなくてもかまいません。♦
次の図は、名前付きセグメントを使用したデータベース ファイルが格納される様子
です。
基本概念 2-19
データベース論理名
図 2-4
データベース システム ファイルのセグメント化スキーマの例
In newdb directory
RB_DEFAULT_IDX
RB_DEFAULT_INDEXES
RB_DEFAULT_LOCKS
rb_creator、または dbcreat ユーティリティ
で作成したデータベース システム ファイル
RB_DEFAULT_SEGMENTS
RB_DEFAULT_TABLES
RB_DEFAULT_LOADINFO
TMU LOAD で作成
dfltseg1_psu1
dfltseg2_psu1
dfltseg3_psu1
...
CREATE TABLE 文で作成したテーブルと
インデックスのデフォルト セグメント
dfltseg6_psu1
disk1
fact_99
99_dat1
99_dat2
Fact1 テーブルの名前付きセグメントと PSU
(CREATE SEGMENT 文で作成 )
disk2
fact_00
00_dat1
00_dat2
fact_pi
fact_pi1
fact_pi2
2-20 Administrator’s Guide
Fact1 テーブルのプライマリ インデックスの名前付き
セグメントと PSU (CREATE SEGMENT 文で作成 )
セグメント名
セグメント名
RBW_SEGMENTS システム テーブルには、以下に示すように、各テーブルのセグ
メント名が格納されています。
select name, tname, iname from rbw_segments;
NAME
RBW_SYSTEM
DEFAULT_SEGMENT_1
DEFAULT_SEGMENT_2
DEFAULT_SEGMENT_3
DEFAULT_SEGMENT_4
DEFAULT_SEGMENT_5
DEFAULT_SEGMENT_6
FACT_99
FACT_00
FACT_PI
TNAME
NULL
PERIOD
PERIOD
PRODUCT
PRODUCT
MARKET
MARKET
FACT1
FACT1
FACT1
INAME
NULL
NULL
PERIOD_PK_IDX
NULL
PRODUCT_PK_IDX
NULL
MARKET_PK_IDX
NULL
NULL
FACT1_PK_IDX
環境設定と初期化
IBM Red Brick Warehouse は、構成ファイル、初期化ファイル、SET コマンド、環境
変数を使って、各データベース サーバの環境設定をカスタマイズします。ファイル
による設定と SET コマンドによる対話形式の設定を組み合わせ、グローバル レベ
ル、データベース レベル、ユーザ レベルなど、柔軟なカスタマイズを行うことが
できます。
コンフィグレーション ファイル
データベース サーバの構成情報は、データベース サーバ ディレクトリにある
rbw.config ファイルに記述されています。このファイルは、インストール時に生成
され、UNIX ではウェアハウス デーモン、データベース サーバ、TMU プロセスが
使用する構成パラメータと性能調整パラメータを格納し、Windows では IBM Red
Brick Warehouse サービスと TMU が使用する構成パラメータと性能調整パラメータ
を格納します。このファイルは、テキスト エディタで編集できます。
基本概念 2-21
初期設定ファイル
初期設定ファイル
IBM Red Brick Warehouse は、データベース サーバ (rbwsvr) の初期化用ファイルであ
る .rbwrc ファイル、RISQL エントリ ツールおよび RISQL レポータの初期化用ファ
イルである .rbretrc ファイル、そして Red Brick ODBC Driver アプリケーションの定
義を含む Red Brick ODBC Driver 初期化ファイルという 3 種類の初期化ファイルを使
用します。(Red Brick JDBC Driver には、JDBC URL によってマシン名とポート番号
が指定されるため、初期化ファイルはありません。)
.rbwrc ファイル
ユーザ固有の要求にあわせて各ユーザ セッションをカスタマイズするために、
.rbwrc ファイルを利用できます。.rbwrc ファイルには、CREATE MACRO、INSERT
および SET などのクエリ以外の SQL 文を記述することができます。redbrick ユーザ
として実行するデータベース サーバ プロセスが、.rbwrc ファイルの読み取りと
.rbwerr ファイルの書き込みができるように各ファイルのアクセス権を設定してく
ださい。
.rbwrc ファイルは 1 つのユーザ プロフィールについて 4 つまで設定できます。ファ
イルは次の順で処理されます。
UNIX ファイル
Windows ファイル
説明
$RB_CONFIG/.rbwrc
%RB_CONFIG%¥
.rbwrc
rbw.config と同じディレクトリにある、グロー
バル ウェアハウス ファイル
$RB_PATH/.rbwrc
%RB_PATH%¥.rbwrc
各データベース ディレクトリにある、データ
ベース別ファイル
$HOME/.rbwrc
なし
IBM Red Brick Warehouse が動作しているコン
ピュータ上にある RISQL エントリ ツールまた
は RISQL レポータを使ってデータベースにアク
セスするユーザを対象とした、各ユーザのホー
ム ディレクトリにあるユーザ別ファイル
$RB_PATH/
.rbwrc.<DBUSERNAME>
%RB_PATH%¥
.rbwrc.<DBUSERNAME>
ユーザ別初期設定ファイル。使用するファイル
は、次の拡張子を持ち、データベース ディレク
トリに存在しなければなりません。
.rbwrc.DBUSERNAME
DBUSERNAME は、オペレーティング システム
のユーザ アカウント名ではなく、データベース
ユーザ名です。拡張子は、大文字でなければな
りません。
2-22 Administrator’s Guide
初期設定ファイル
サーバ設定、データベース設定、ユーザ設定の順に処理されるので、後から処理さ
れるファイルで先に処理されるファイルで設定された内容を上書きすることができ
ます。
データベース サーバとデータベースの初期設定ファイルは、データベース管理者が
管理します。一般に、これらのファイルには、グローバルなテンポラリ マクロまた
はデータベース別のテンポラリ マクロ、アクセス制御文、データベースの作業ファ
イルのサイズを制限する値、ORDER BY 句における NULL 値の順番の設定などを記
述します。
ユーザ別ファイルは、個々のユーザが編集できます。一般に、テンポラリ マクロ
や、ユーザ セッションを制御する SET コマンドを記述します。
上記のファイルに記述されたコマンドの実行は、各コマンドによるエラー メッセー
ジ、通知メッセージ、警告メッセージとともに、ユーザのホーム ディレクトリにあ
る .rbwerr というログ ファイルに記録されます。ログ ファイルは、無制限に増える
のを防ぐため、データベース サーバ プロセス (rbwsvr) が起動されるたびに削除さ
れます。
.rbretrc ファイル
.rbretrc ファイルは、RISQL エントリ ツールおよび RISQL レポータを使用してデー
タベース サーバにアクセスするユーザに関する実行プロフィールをカスタマイズし
ます。ファイルには SET コマンドが記述されています。たとえば、エディタを指定
するコマンドや、システム テーブルの列の表示幅を指定し、画面に表示されるよう
にフォーマットを設定するコマンドです。.rbretrc ファイルは 2 つあり、以下の順
序で処理されます。
UNIX ファイル
Windows ファイル
説明
$RB_CONFIG/.rbretrc
%RB_CONFIG%¥.rbretrc
rbw.config ファイルと同じ
ディレクトリにあるファイ
ル。データベース サーバに
アクセスするユーザのセッ
ションを初期化します。
$HOME/.rbretrc
%HOMEDRIVE%%HOMEPATH%¥.rbretrc
各ユーザのホーム ディレク
トリにあるユーザ別のファ
イル。このファイルは、そ
のユーザのプロファイルだ
けに影響します。
基本概念 2-23
SET コマンド
処理の順序により、ユーザ設定はサーバ設定に優先します。コマンド ラインからの
入力による設定は、.rbretrc ファイルの設定に優先しますが、現在のセッションに
のみ適用されます。
ODBC 初期設定ファイル
ODBC のデータ ソース名 (DSN) 定義は、クライアント アプリケーション (RISQL エ
ントリ ツールや RISQL レポータなど ) が Red Brick ODBC Driver を介して IBM Red
Brick Warehouse に接続するときに使用します。DSN とは、サーバ、データベース論
理名、データベース ユーザ名を指定し、必要に応じてデータベース パスワードも
指定する論理名のことです。
UNIX
UNIX では、環境変数 ODBCINI を設定した場合は、DSN 定義は ODBCINI で指定
したファイルから取得されます。この環境変数を設定しない場合は、DSN 定義は
ユーザのホーム ディレクトリにあるユーザごとの .odbc.ini ファイルから取得されま
す。Client Connectivity コンポーネントをインストールすると、redbrick ディレクト
リに odbc.ini というテンプレート ファイルが作成されます。このテンプレート ファ
イルを使用して、管理者はすべてのユーザがアクセスする共有 DSN 定義ファイル
を作成できます。このファイルを作成するには、環境変数 ODBCINI をそのファイ
ル名に設定します。または、各ユーザが自分のホーム ディレクトリに格納される
ユーザごとの .odbc.ini ファイルを作成することもできます。♦
Windows
Windows では、コントロール パネルの [ODBC Data Source Administrator] を使用して
DSN を追加または変更します。Windows オペレーティング システム ディレクトリ
の rbodbc32.ini ファイルには、Red Brick ODBC Driver の初期化情報が格納されてい
ます。このファイルを使用して、システム上のすべてのクライアントのデフォルト
のロケールを設定します。♦
詳細については、『Client Installation and Connectivity Guide』を参照してください。
SET コマンド
SET コマンドは、データベース サーバ、TMU、RISQL エントリ ツール、RISQL レ
ポータの環境設定とカスタマイズに使用します。SET コマンドは、コマンドの内容
に応じていくつかの方法で指定できます。
■
■
■
■
2-24 Administrator’s Guide
.rbwrc または .rbretrc 初期化ファイルでの指定
TMU コントロール ファイルでの指定
RISQL エントリ ツールまたは RISQL レポータからの指定
SQL コマンドを実行するクライアント ツールからの指定
環境変数
環境変数
データベース サーバは、以下の環境変数を使用します。
環境変数
説明
RB_CONFIG
rbw.config ファイルのあるディレクトリへのパス。通常、この
ディレクトリにはデータベース サーバの実行可能ファイルがあ
る bin ディレクトリがあります。
RB_DSN
データソース名 (DSN) の定義。詳細については、
『Client
Installation and Connectivity Guide』を参照してください。
RB_EXE
(Windows)
Red Brick Service の実行可能ファイルの名前。デフォルト名は
service.exe です。
RB_HOME
(Windows)
IBM Red Brick Warehouse がインストールされているホーム
RB_HOST
ウェアハウス デーモン プロセス (UNIX) または IBM Red Brick
Warehouse サービス (Windows) を識別する論理名。
RB_PATH
rbw.config ファイルの中で定義され、データベース ディレクトリ
のパスが割り当てられるデータベース論理名。アクセスするデー
タベースの論理名。
ディレクトリのパス。
Administrator ツール
IBM Red Brick Warehouse Administrator ツールは、視覚的に操作できるデータベース
サーバ管理ツールです。Windows オペレーティング システムで動作するスタンドア
ロン アプリケーションであり、UNIX または Windows で稼動しているデータベース
にアクセスできます。Administrator ツールを使用すると、複数のデータベースに直
接アクセスして、次のようなデータベース管理タスクを行えます。
■
■
■
■
■
■
■
ユーザ、ロール、マクロ、テーブル、インデックス、セグメント、シノニ
ム、ビューの作成、変更、削除
PSU の検査と確認、セグメントのアタッチと切り離し、PSU の属性の定義
など、詳細なセグメント関連タスクの実行
ユーザやロールに対する特権と権限の付与、取り消し
管理デーモンの停止、再開、リセット、データベースの統計のリセットな
ど、一般的なデータベース タスクの実行
ユーザ操作の制御、現在のユーザ セッションの優先順位の変更
データベースのログ機能の管理
データベースのアカウンティング操作の管理
基本概念 2-25
Administrator ツール
■
データベースのテーブルおよびインデックスの、実際のサイズと最大サイ
ズの指定
さらに、Administrator ツールでは、以下を視覚的に表示することができます。
■
■
■
■
■
■
■
データベース内の参照先テーブルと参照元テーブルの関係
ファイル システムの構造
データベース内のデータ、インデックス、および接続されていないセグメ
ントに関する情報
ユーザ、ロール、マクロ、データ オブジェクト ( テーブル、システム テー
ブル、ビュー、シノニム ) を表示したデータベースの構造
関連するシステム テーブルから取得したデータ オブジェクトのプロパ
ティ情報
EXPLAIN コマンドで生成されたクエリ予定
Vista Advisor で生成された使用状況と候補ビューの分析結果
また、Administrator ツールは、SQL コマンド文を手入力するためのインタラクティ
ブな SQL ウィンドウ、および指定したデータベース オブジェクトの作成に使用さ
れた SQL を表示する SHOW DDL ウィンドウを提供します。
2-26 Administrator’s Guide
サーバ ロケール
サーバ ロケール
この節では、ロケールとは何か、インストール時にサーバ ロケールを指定する方
法、クライアント ツールのロケールを設定する方法、クライアント / サーバ環境に
おける互換性の問題、ロケールの設定とメッセージの関係について説明します。以
下について説明します。
■
■
■
■
ロケールの要素
サーバ ロケールの設定
サーバ ロケールのオーバーライド
クライアント / サーバの互換性
ロケールの要素
ロケールとは、言語とテリトリの一意な組み合わせのことです。サーバのロケール
はインストール時に定義され、データベースの実行時の動作を制御するために管理
者が使用する機構です。ロケール指定は、言語、テリトリ、コード セット、照合
シーケンスという 4 つの要素から構成されます。例を示します。
Japanese_Japan.MS932@Binary
■
■
■
■
Japanese = 言語
Japan = テリトリ
MS932 = コード セット
Binary = 照合シーケンス
次の各節では、ロケールの各要素を詳しく説明します。サポートされているロケー
ルの一覧については、IBM Red Brick Warehouse 製品の CD-ROM にある relnotes ディ
レクトリの locales.pdf ファイルを参照してください。サーバ ロケールの定義に関す
る詳細については、2-30 ページ「サーバ ロケールの設定」を参照してください。
言語
言語はテリトリと組み合わせて、使用する言語を制御します。一般にテキスト文字
列は、ユーザが選択した言語で入力し表示されます。テキスト文字列には、通知
メッセージ、警告メッセージ、オブジェクト名、月、日、クエリ結果として返され
る文字データなどがあります。SQL 文に使用するキーワードなどのプログラミング
言語の固定エレメントは、変換できません。
基本概念 2-27
ロケールの要素
テリトリ
テリトリは、通貨記号、数値および金額のフォーマット規則、日付 時刻フォーマッ
トなど、各国に応じた情報を制御します。たとえば、アメリカ合衆国とイギリスで
は英語を使用し、スペインとメキシコではスペイン語を使用しますが、各言語の使
い方はテリトリによって異なります (1 つのテリトリが複数の国に適用される場合も
あります )。
文字以外のデータ型に関するフォーマット規則は、世界各国で異なります。たとえ
ば、ヨーロッパの多くの国々では、浮動小数点付き数値の小数点をカンマで表しま
すが、一部のヨーロッパの国々とアメリカでは小数点をピリオドで表します。同様
に、千の位の区切り記号も国によって異なり、3 桁ごとに区切らない国もあります。
日付のフォーマットも、テリトリの表記規則に従います。日付を構成する要素 ( 年、
月、日 ) の順序、各要素を区切る文字、各要素の名称、略記方法、カレンダーの内
容も、テリトリによって異なります。時刻は、各言語ごとに 12 時間または 24 時間
表記のどちらかで、ラテン ラベルの A.M. および P.M. に基づいて表示できます。通
貨のフォーマット規則も、通貨記号の位置を始めとして大きく異なります。
コード セット
コード セットは、文字の符号化 ( エンコーディング ) の仕様、つまり情報のフォー
マット設定と表示に使用するコード ページを指定するものです。コード セットは、
各言語で使用する文字セットを、任意の数字セットにマッピングする方法を指定し
ます。この数字は、キーボードからの入力を画面に表示する情報に変換する際に参
照されます。文字を認識させるには、文字を処理するすべてのシステムが同じエン
コーディング方法を使用していなければなりません。
アメリカでは、ASCII と呼ばれる 7 ビットのエンコーディングを一般に使用してい
ます。128 の符号がありますが、英語以外の言語を表すのに必要な文字がすべて含
まれているわけではないので国際的に使用するには不十分です。このため、IBM
Red Brick Warehouse では、次の文字エンコーディングもサポートしています。
■
■
8 ビット エンコーディング : バイトの第 8 ビットを ASCII の拡張ビットとし
て使用し、256 文字が表現できるようにしています。8 ビット エンコー
ディングは、ほとんどのヨーロッパ言語に対応でき、1 バイトと 1 文字が
同じサイズであるという利点があります。
マルチバイト エンコーディング : 文字幅を、1 ∼ 4 バイトの範囲で変えるこ
とができます。マルチバイト エンコーディングには、7 ビットの ASCII 符
号がサブセットとして含まれています。アジアの言語 ( 日本語、中国語、
韓国語 ) は、256 をはるかに超える文字を使用するため、マルチバイト エ
ンコーディングを使用するのが一般的です。
サポートされているコード セットと、コード セット間でサポートされている変換
の一覧については、IBM Red Brick Warehouse 製品の CD-ROM にある relnotes ディレ
クトリの locales.pdf ファイルを参照してください。
2-28 Administrator’s Guide
ロケールの要素
照合シーケンス
ロケールのソート順序を決める照合シーケンスは、文字列を比較し、正しい順序に
並べ替える規則を定義します。文字の比較には、バイナリとリングィスティックと
いう 2 つの方法があります。
バイナリ方式の文字比較
バイナリ方式の比較では、各文字に割り当てられた文字符号を数値に変換し、数値
として比較しソートします。たとえば、2 つの文字を比較する場合、対応する数値
が小さい方の文字が、照合シーケンスで前に配置されます。
バイナリ方式の比較は比較的高速ですが、実用的な結果にならない場合もありま
す。a ∼ z の文字は正しくソートされるため、7 ビット ASCII および英語については
十分ですが、以下のような制限が適用されます。
■
■
■
ソートの結果、大文字は小文字より前に置かれます。たとえば、小文字の
a は、大文字の Z より後になります。
8 ビット ASCII エンコーディングでソートすると、128 以下のコードに対
応する文字の間に、128 ∼ 255 に対応する文字は挿入されません。たとえ
ば、ヨーロッパ言語で用いる区分発音符のついた母音は、区分発音符のな
い母音と同等の文字としてではなく、8 ビット ASCII エンコーディングの
前に割り当てられます。
ソートする文字の位置はその次の文字に依存する場合もあるため、バイナ
リ照合シーケンスでは正しい結果にならない言語もあります。
リングィスティック方式の文字比較
バイナリ方式の制限を解決するのが、リングィスティックまたはレキシカルという
方式の文字比較です。これは、言語習慣に基づくソート規則を考慮した方法です。
言語のソート規則は 1 つだけとはかぎりません。たとえば、電話帳に記載する氏名
を、辞書の単語とは違う規則でソートする国もあります。これらの方法は、ソート
規則が違っていてもバイナリ文字エンコーディングとは無関係であるため、リン
グィスティック方式と見なされます。
リングィスティック方式の比較は、テーブルからエントリを抽出することにより、
特定の文字を比較します。このエントリは、ソート シーケンス内における文字の位
置を示すもので、同じテーブルからほかのエントリを抽出して比較し、ほかの文字
との関係を判定できます。リングィスティック ソートでは、コンテキスト ( 文字の
前後関係 ) も考慮されます。テーブルの検索とコンテキストの考慮が加わるため、
リングィスティック方式は、バイナリ方式よりやや低速になります。
基本概念 2-29
サーバ ロケールの設定
バイナリ方式の比較は、十分な柔軟性はありませんが性能が高く、リングィス
ティック方式の比較は、性能はやや落ちますが各国語において意味のある結果を返
します。IBM Red Brick Warehouse は、インストレーションの際のロケール設定に基
づき、この 2 つの方式をサポートします。
サーバ ロケールの設定
IBM Red Brick Warehouse ソフトウェアのインストール時に、サーバのロケール設定
が要求されます。その際に設定されたロケールは、パラメータ NLS_LOCALE
LOCALE として rbw.config ファイルに格納されます。ロケールを設定しないと、次
のデフォルト値が使用されます。
English-UnitedStates.US-ASCII@Binary
ロケールの設定は、作成するデータベースの数にかかわらず、IBM Red Brick
Warehouse インストレーション全体に適用されます ( インストールは、環境変数
RB_CONFIG が参照するディレクトリにある rbw.config ファイルの内容によって定
義されます )。つまり、各データベースのすべての文字列が、同じ文字エンコー
ディングを使用して格納され、すべてのインデックスが、同じ照合シーケンスに
従ってソートされます。
ロケールは、ソートされるデータ ( データベース、TMU の入力ファイル、バック
アップ テープ ) の属性であると同時に、実行時の動作を制御するデータベース サー
バ製品の構成パラメータでもあります。通常、インストール時に設定したロケール
と、各製品の動作ロケールは同じでなければなりません。例外は、この章で後述し
ます。
IBM Red Brick Warehouse、TMU、汎用ユーティリティ プログラムなどのクライアン
ト以外の製品は、rbw.config ファイルに定義されたロケールを使って実行時の動作
を決定します。たとえば、言語を日本語に設定すると、サーバと TMU のエラー
メッセージは、すべて日本語で表示されます。同様に、MS932 などのマルチバイト
コード セットを指定するロケールを設定した場合は、データベース オブジェクト
名や文字列にマルチバイト文字を使用できます。
インストール時のサーバ ロケールを設定する手順については、『Installation and
Configuration Guide』を参照してください。
ロケールのシステム テーブルへの格納
サーバ ロケールと現在のクライアント ロケールは、それぞれ、RBW_OPTIONS シ
ステム テーブルの DB_LOCALE 行と NLS_LOCALE 行に格納されています。
2-30 Administrator’s Guide
サーバ ロケールのオーバーライド
ロケールで変更できないテキスト
サーバのインストール時に設定したロケールにかかわらず、以下のテキストは常に
英語で表示されます。
■
■
■
■
■
■
インストレーション スクリプト
rbw.config ファイルの内容
ファイルの全テキストは、ASCII 文字でなければなりません。
システム テーブルの内容 ( オブジェクト名を除く )
ログ メッセージ
EXPLAIN 文の出力データ ( オブジェクト名を除く )
すべての IBM Red Brick Warehouse ユーティリティ プログラム (rb_creator
または dbcreate、rb_deleter、dbsize など ) の出力
ただし、これらのユーティリティは、データおよびオブジェクト名にマル
チバイト文字が使用でき、サーバ ロケールの照合シーケンスに基づく比較
も実行できます。また、データのフォーマット設定はローカライズされて
いません。
サーバ ロケールのオーバーライド
クライアント / サーバ環境では、クライアントの動作ロケールと、rbw.config ファ
イルに設定されたサーバ ロケールが異なっている場合があります。つまり、クライ
アント ツールに設定したロケールが、サーバのロケールと一致しないことがありま
す ( 警告メッセージは出ません )。ただし、実際に影響があるのは、言語とコード
セットの違いだけです。
言語を変更すると、メッセージ表示の言語が変更されます。コード セットを変更す
ると、変換が正常に実行されることを条件として、クライアントとデータベース
サーバが異なるコード セットを使用できるようになります。各言語でサポートされ
ているコード セットの一覧については、IBM Red Brick Warehouse 製品の CD-ROM
にある relnotes ディレクトリの locales.pdf ファイルを参照してください。
テリトリが異なってもあまり影響はありません。テリトリは、主に表示フォーマッ
トをコントロールするもので、データベース サーバはフォーマット設定を行わない
からです。同様に、ソート順序が異なっても大きな変化はありません。すべての
ソートは、データベースに設定された照合シーケンスに従ってサーバが行うからで
す。
TMU を使ってクライアント ロケールを設定する方法は、『Table Management Utility
Reference Guide』を参照してください。
基本概念 2-31
サーバ ロケールのオーバーライド
クライアント ツールのロケール設定
クライアント ツールは、データベースのロケールと異なるロケールで実行すること
ができます。クライアント ロケールは、出力データのフォーマット設定と、正しい
メッセージ ファイルの識別に使用されます。クライアントを通じて表示されるメッ
セージは、クライアントが出力する場合と、サーバが出力する場合があります。す
べてのメッセージは、出力元を問わず、クライアント ロケールの言語で表示されま
す。
各コード セットが同じ言語をサポートし、正常に変換されることを条件として、ク
ライアントとデータベース サーバは異なるコード セットを使用できます。たとえ
ば、MS932 の日本語文字は、JapanEUC の日本語文字に変換できます。
RISQL エントリ ツールおよび RISQL レポータは、IBM のクライアント アプリケー
ションです。これらのクライアントの動作ロケールは、環境変数
RB_NLS_LOCALE で個別に設定できます。クライアント ロケールを指定しない場
合、動作はオペレーティング システムによって決まります。
UNIX
Windows
UNIX では、rbw.config ファイルにある現行のエントリ NLS_LOCALE LOCALE で指
定されたサーバ ロケールをクライアントが使用します。
Windows では、Windows オペレーティング システム ディレクトリにある
rdodbc32.ini ファイルにクライアント ロケールが指定されています。
ヒント：サード パーティのクライアント ツールでは、そのツール独自のロケール
指定方法を使用する必要があります。ただし、サード パーティのクライアント
ツールでも環境変数 RB_NLS_LOCALE を使用して、コード セットの変換と、デー
タベース サーバが生成するメッセージのロケールを制御することができます。
環境変数 RB_NLS_LOCALE の設定
環境変数 RB_NLS_LOCALE は、ユーザのロケールを制御するものです。RISQL エ
ントリ ツールおよび RISQL レポータのユーザが、アプリケーションの起動時に言
語を指定するには、この環境変数を使用します。
UNIX
たとえば、UNIX C シェル プロンプトから次のように入力します。
%setenv RB_NLS_LOCALE German_Austria.Latin1@Default
♦
2-32 Administrator’s Guide
サーバ ロケールのオーバーライド
Windows
たとえば、MS-DOS シェル プロンプトから以下のように入力します。
c:¥> set RB_NLS_LOCALE=German_Austria.Latin1@Default
♦
この例では、変数は次のようになっています。
German = 言語
Austria = テリトリ
Latin1 = コード セット
Default = 照合シーケンス
ロケールの 4 つの要素について、必ずしもすべてを指定する必要はありません。た
だし、ロケールを完全に設定しない場合も、言語は指定してください。そうしない
と、未指定の要素に不適切なデフォルト値が設定される場合があります。
指定されていないロケールの要素のデフォルト値には、次の規則が適用されます。
■
言語だけを指定した場合、省略した要素は、その言語のデフォルト値に設
定されます。たとえば、ロケールが Japanese に設定されている場合、全
体のロケール指定は次のようになります。
Japanese_Japan.JapanEUC@Binary
■
各言語のデフォルトの要素の一覧については、IBM Red Brick Warehouse 製
品の CD-ROM にある relnotes ディレクトリの locales.pdf ファイルを参照し
てください。
テリトリだけを指定した場合、デフォルトでは言語が English、コード
セットが US-ASCII、照合シーケンスが _Binary に設定されます。たと
えば、ロケールが _Japan に設定されている場合、ロケール指定は以下の
ような実用的ではないものになります。
English_Japan.US-ASCII@Binary
■
■
コード セットだけを指定した場合、デフォルトでは言語が English、テ
リトリが UnitedStates、照合シーケンスが Binary に設定されます。
照合シーケンスだけを指定した場合、デフォルトでは言語が English、
テリトリが UnitedStates、コード セットが US-ASCII に設定されます。
ヒント：ロケールの一部だけを指定する場合は、すべての区切り記号 ( 下線、ピリ
オド、@ 記号 ) を指定する必要はありません。指定する要素の直前の文字 ( 上記の
テリトリのみの指定例では下線 "_") だけを入力します。
基本概念 2-33
クライアント / サーバの互換性
クライアント / サーバの互換性
クライアント / サーバ環境では、ロケールの設定による互換性が問題になることが
あります。以下のような状況を考えてみましょう。
■
日本のユーザが PC を使用する際に、クライアント ロケールを以下のよう
に設定したとします。
Japanese_Japan.MS932
■
これに対しデータベース サーバは、MS932 ではなく、JapanEUC のコード
セットを使用していたとします。データベース サーバは、処理したデータ
のコード セットを変換してから、クライアント PC に送らなければなりま
せん。このコード セットの変換はサポートされているため、データの消失
や非互換性の問題は発生しません。
フランス語を話すユーザが、ドイツ語をロケールとするデータベースに接
続するとします。
French_France.Latin1 (client locale)
German_Germany.Latin1 (warehouse locale)
■
この場合は、コード セットの変換は不要です。ドイツ語とフランス語はど
ちらも、Latin1 のコード セットを使用するからです。ユーザのクライアン
ト ツールは、メッセージをフランス語で表示し、日時データにもフランス
語のフォーマット規則を適用します。データそのものはドイツ語と見なさ
れ、クライアントに指定されたソート順序とは関係なく、ドイツ語のソー
ト規則に従います。
英語を話すユーザが、日本語のデータベースを使用するとします。
English_UnitedStates.US-ASCII (client locale)
Japanese_Japan.JapanEUC (warehouse locale)
サーバのロード操作と挿入操作については ASCII 文字を使用できますが、
マルチバイト データのクエリは正しく表示されません。クライアントと
サーバのロケールに、互換性がないためです。
次の各節では、クライアント / サーバ間の非互換性を回避し、修正する方法を説明
します。
コード セットの変換
データベース ロケールとクライアント ロケールのコード セットが異なるクライア
ント / サーバ環境を設定する場合は、コード セット間の変換がサポートされている
ことを確認してください。
警告 : IBM Red Brick Warehouse には、コード セットの非互換性によるデータの消
失や破損が発生した場合の復旧機構がありません。
2-34 Administrator’s Guide
クライアント / サーバの互換性
メッセージ システム
メッセージ システムは、エラー メッセージ、警告メッセージ、通知メッセージを
適切な言語でユーザに表示する必要があります。このためシステムは、サポートさ
れている言語ごとに別個のメッセージ ファイルを管理しています。
クライアント / サーバ環境で使用するメッセージ ファイルは、クライアントのロ
ケールによって決まります。これ以外はすべて、サーバ ロケールに基づいてメッ
セージ ファイルが選択されます。どのメッセージ ファイルが選択されるかは、ロ
ケール指定の言語およびテリトリによって決まります。メッセージは対応する言語
で表示され、メッセージのテキストは、各地域の表記規則に従います。
設定したロケールのメッセージ ファイルがない場合は、デフォルトのアメリカ英語
メッセージ ファイルが使用されます。その際に警告メッセージは表示されません。
デフォルトのメッセージ ファイルがない場合は、エラー メッセージが表示されま
す。このエラー メッセージは、常に英語で表示されます。
メッセージ ファイルの命名規則
1 つのインストレーションで、異なる言語の複数のメッセージ ファイルが使用でき
るように、次のフォーマットでファイルが命名されています。
■
■
■
データベース サーバのエラー メッセージ : RBLLTTT.MB
データベース サーバのログ メッセージ : RLLLTTT.MB
クライアント メッセージ : RCLLTTT.MB
<LL>
言語を識別します。
<TTT>
テリトリを識別します。
メッセージ ファイル名は、すべて大文字です。たとえば、アメリカ英語のサーバ
メッセージ ファイル名は、RBENUSA.MB となります。
メッセージ ファイルのロケーションは、rbw.config ファイルのパラメータ
NLS_LOCALE MESSAGE_DIR に設定されています。
内部エラー メッセージ
内部エラー メッセージは、メッセージ ファイルには格納されず、常にアメリカ英
語で表示されます。
基本概念 2-35
ファイルの所有権とアクセス許可
管理デーモンとログ デーモンの出力データ
管理デーモン (rbwadmd) とログ デーモン (rbwlogd) は、データベース動作の履歴情
報を生成します。この情報はローカライズされませんが、サーバが生成するデータ
も含まれているため、サーバ ロケールの言語が使用されます。
管理デーモンとログ デーモンの詳細については、第 8 章「組織におけるデータベー
ス運用の管理」を参照してください。
ファイルの所有権とアクセス許可
サーバのインストール手順として、まずオペレーティング システムのユーザ アカ
ウントを作成します。アカウントのデフォルト名は redbrick ですが、任意の名前に
変更することができます。IBM Red Brick Warehouse のマニュアルでは、このユーザ
アカウントを redbrick と総称します。このユーザ ID は、オペレーティング システ
ム レベルでのすべてのデータベース管理操作に使用します。
redbrick は、インストールしたすべてのソフトウェアの所有者に設定され、必要な
アクセスに対する許可が与えられます。データベースの作成、削除、ロードなどの
管理操作は、redbrick ユーザだけが実行できるユーティリティを使って行われま
す。セグメント、システム テーブル、ユーザ テーブル、インデックス、構成ファ
イルを含め、すべてのデータベース ファイルとディレクトリは、redbrick が所有し
ます。Read アクセス権は、ほかのユーザやグループに与えないでください。ユーザ
はサーバ インタフェースを通じてのみ各ファイルへアクセスでき、データベース
ファイルを直接読み込んだり修正することはできません。
2-36 Administrator’s Guide
データベースの権限と特権
データベースの権限と特権
redbrick アカウントは、オペレーティング システム レベルのアカウントですが、
データベース管理者がユーザにデータベースのアクセス権を付与するには、各デー
タベースの DBA アカウントを使用します。DBA アカウントは、ユーザ名 system と
パスワード manager で新規に作成したデータベースごとに設定され、DBA システ
ム ロールのメンバー権が与えられます。データベース管理者は、DBA アカウント
から GRANT 文を実行し、各データベースへのユーザ アクセスを設定します。
GRANT 文によってデータベース管理者からデータベースのアクセス権を付与され
たユーザは、事前に定義されたシステム ロールのメンバーになります。IBM Red
Brick Warehouse には、3 つのシステム ロールが事前に定義されています。
システム
ロール
説明
CONNECT
データベースにアクセスする権限。CONNECT システム ロール
のメンバー権しか持たないユーザは、データベース オブジェク
トの作成や削除を行うことはできません。
RESOURCE
テーブル、インデックス、ビューの作成および削除、テーブル
とビューに対する特権の付与と取り消しを行う権限。
RESOURCE システム ロールには、CONNECT システム ロールの
権限が含まれます。
DBA
DBA、RESOURCE、CONNECT の各システム ロールの付与と取
り消しを行い、管理タスクを実行する権限。DBA システム ロー
ルには、RESOURCE および CONNECT システム ロールの権限が
含まれます。
オブジェクト特権は、テーブル単位で付与されます。特定のタスク (SELECT、
INSERT、UPDATE、DELETE) について付与するか、すべてのタスクについて一括
して (ALL PRIVILEGES) 付与することができます。
オブジェクト特権は、PUBLIC (CONNECT システム ロールの全メンバー ) に対して
付与するか、各ユーザに個別に付与することができます。
データベース管理者は、ロールに基づくセキュリティ機能を利用して、データベー
スのアクセスをより詳細に制御することができます。このセキュリティ機能を使う
と、RESOURCE システム ロールや DBA システム ロールのタスクのタスク権限を分
割して、ユーザ定義のロールを作成することができます。
システム ロール、特権、ロールに基づくセキュリティの詳細については、第 7 章
「データベースのアクセス権とセキュリティ」および『SQL Reference Guide』を参照
してください。
基本概念 2-37
バージョン管理されたデータベース
バージョン管理されたデータベース
バージョニングとは、INSERT、UPDATE、DELETE、REORG、LOAD といった更新
処理によってデータベースのバージョンに変更が行われているときに、整合性のと
れた状態のデータベースに対して、検索などの読み取り処理をほとんど支障なく行
えるようにする機能です。常に最新の状態のデータベースに対して検索を行うか、
すべての検索処理が同じ時点のデータベースに対して行われ、検索結果の整合性が
確実に保たれるようにするか、選択できます。バージョニング以外の処理は、ブ
ロッキングといいます。
IBM Red Brick Warehouse データベースのトランザクションは、単一の実行ステート
メントとして定義されます。BEGIN TRANSACTION と COMMIT には構文はありま
せんが、実行されるすべての SQL 文、およびすべての TMU 処理において、それぞ
れ最初と最後に実行されます。トランザクションの実行時間は、ステートメントの
処理完了に要する時間です。
バージョン管理されたトランザクションとは、INSERT、UPDATE、DELETE、
LOAD などの処理により、バージョン管理されたデータベースのデータを変更する
トランザクションのことです。バージョン管理されたトランザクションによって変
更されたブロックには、新しいバージョンが作成されます。新しいバージョンは、
データベース ファイルに再び書き込まれるまで、バージョン ログに格納されます。
IBM Red Brick Warehouse では、同時実行性に対応したバージョニングと、復旧性に
対応したバージョニングの 2 種類のバージョニングを利用できます。
同時実行性に対応したバージョニングは、膨大なデータを使用して複雑な分析を行
う意思決定支援システム (DSS) に効果的な方法です。これに対し、OLTP システム
は、複数の小規模なトランザクション処理の支援に適しており、複雑な同時実行モ
デルを使用して分析データの操作を効果的に行います。意思決定支援システムは、
膨大なデータを使用する複雑な分析の実行や、多数のテーブルの多数の行にアクセ
スするような検索を想定して設計されています。このような複雑なクエリは DSS
データベースの実データと同じ場所で実行されるため、DSS 環境における同時実行
モデルが更新処理の性能を向上させます。
復旧性に対応したバージョニングは、バージョン ログを従来型の先行書き込みログ
として使用します。高復旧性オプションを使用すると、同時実行性に対応したバー
ジョニングを使用する場合より、バージョン ログに必要なリソースが少なくなり、
データが失われる可能性のある時間ウィンドウが短くなります。復旧性に対応した
バージョニングは、テーブルに排他的にアクセスする、夜間の大量のロード操作に
適しています。このバージョニングでは、並行クエリは考慮されていません。
詳細については、第 6 章「バージョン管理されたデータベースの使用」を参照して
ください。
2-38 Administrator’s Guide
参照整合性
参照整合性
参照整合性とは、参照元テーブルのフォーリン キー値が参照先テーブルのプライマ
リ キー値に存在するという関係を示す特性です。正しいクエリ結果と STAR イン
デックスの作成を保証するため、IBM Red Brick Warehouse は、参照整合性を強制し
ます。参照整合性の関係は、CREATE TABLE 文で SQL の FOREIGN KEY 句と
PRIMARY KEY 句を使用して定義します。参照元テーブルのロード、更新、挿入
と、参照先テーブルの行データの削除について、参照整合性の関係が自動的に維持
されます。
データのロードと挿入
ロード操作または挿入操作で行をテーブルに追加する場合、その行のフォーリン
キー列の値がフォーリン キーの参照先テーブルに存在しないと、行の追加は参照整
合性に違反するため、破棄されます。ロード操作の場合は、破棄されたレコードを
ファイルに保存しておき、後で再ロードすることができます。欠落しているフォー
リン キー値を含む新規の行を参照先テーブルに挿入するか、破棄レコードのファイ
ルを編集してデータの変換または内容のエラーを修正することにより、このファイ
ルを再ロードすることができます。
参照整合性に違反した行を破棄する代わりに、参照整合性に必要な値を持つ行を生
成し、参照先テーブルに追加することもできます。新規行には、テーブルの作成時
に設定されたデフォルト値が充填されます。この動作は、Automatic Row Generation
(AUTOROWGEN) という TMU オプションを使って指示します。
基本概念 2-39
データの削除とカスケード デリート
データの削除とカスケード デリート
テーブルから削除する行に、ほかのテーブルのフォーリン キーが参照している値が
含まれている場合は、参照整合性違反になります。これを避けるには、以下のいず
れかの動作をします。
■
■
その行を削除し、参照元テーブルの行も削除します。これは、カスケード
デリートと呼ばれ、すべての参照元テーブルに波及させることができま
す。
どちらの行も削除しない、つまり何もしません。このように何もしないこ
とをリストリクト デリートといいます。
カスケード デリートとリストリクト デリートのどちらの動作をするかは、テーブ
ルの作成時に指定します。CREATE TABLE 文の ON DELETE 句で、CASCADE か
NO ACTION を指定してください。
削除操作中は、行が削除されるテーブルと、参照元テーブルの両方をシステムが
ロックします。ロックするテーブルとロックの種類 (Read か Write) を説明するため
に、テーブルのイミディエート ファミリおよびコンプリート ファミリという概念
を使います。
■
■
テーブルのイミディエート ファミリとは、操作対象のテーブルを
FOREIGN KEY 参照句によって参照するすべてのテーブルを指します。
テーブルのコンプリート ファミリとは、イミディエート ファミリに加え、
イミディエート ファミリを参照するすべてのテーブル、そのテーブルを参
照するすべてのテーブル、というように、参照元となるすべてのテーブル
を指します。
コンプリート ファミリについては、1 種類のデリート モードしか許可されず、リス
トリクト デリートがカスケード デリートに優先します。リストリクト デリート
(NO ACTION) が設定されたテーブルがコンプリート ファミリに 1 つでもある場合
は、カスケード デリートの設定が無視されます。
警告 : DELETE 文の OVERRIDE REFCHECK オプションを使うと、参照整合性
チェックを省略することができますが、動作内容を正しく理解した上で慎重に使用
してください。
Fact1、Fact2 という 2 つのファクト テーブル、Product、Market、Period という 3
つのディメンジョン テーブル、Brand、Monthname という 2 つのアウトボード
テーブルを持つデータベースがあり、以下の図のような参照が行われているとしま
す。
2-40 Administrator’s Guide
データの削除とカスケード デリート
図 2-5
Brand
Product
Fact1
スキーマの例
Monthname
Market
Period
Fact2
次の表は、Delete ロックをかけた場合の各テーブルのイミディエート ファミリとコ
ンプリート ファミリの関係を示したものです。
テーブル名
イミディエート
ファミリ
コンプリート ファミリ
Fact1
なし
なし
Fact2
なし
なし
Product
Fact1、Fact2
Fact1、Fact2
Market
Fact2
Fact2
Period
Fact2
Fact2
Brand
Product
Product、Fact1、Fact2
Monthname
Period
Period、Fact2
削除操作 ( および LOCK TABLE 文の FOR DELETE オプション ) は、すべての関連
テーブルのアクセスに必要かつ十分な Delete ロックを使用します。この Delete ロッ
クは、指定されたテーブルを Write ( 排他 ) アクセス専用にロックします。さらに、
イミディエート ファミリの全テーブルをロックします。ロックの種類 (Read か
Write) は、テーブルの作成時に指定された参照動作によって決まります。同様に、
ロックされた各テーブルのイミディエート ファミリの全テーブルもロックします。
コンプリート ファミリに Write ロックがかけられるのは、すべての ON DELETE 動
作が CASCADE モードの場合だけです。そうでない場合は、イミディエート ファミ
リのテーブルだけに Read ロックがかけられます。
以下の例では、削除操作を行ったときのテーブル ロックと、参照整合性が維持され
る仕組みを示します。
基本概念 2-41
データの削除とカスケード デリート
例
すべてのテーブル参照が、カスケード デリートである場合の削除動作を示します。
Brand テーブルが、以下の参照句で Product テーブルから参照されます。
brandkey char(3) not null,
...
foreign key brandkey references brand (brandkey)
on delete cascade
Brand テーブルが、以下の参照句で Fact テーブルから参照されます。
prodkey char(5) not null,
...
foreign key prodkey references product (prodkey)
on delete cascade
図 2-6
カスケード
デリート
Brand
x
y
z
...
Monthname
Product
y
z
...
Market
カスケード
Fact
z
...
2-42 Administrator’s Guide
Period
データの削除とカスケード デリート
Brand テーブルから行を削除する場合、その行を参照する ( その行のプライマリ
キー値と一致するフォーリン キー値を持つ ) 行が Product テーブルにあれば、この
参照元行も削除します。さらに Product テーブルから削除された行を参照する、
Fact テーブルの行も削除します。このカスケード デリート動作は次の表のようにな
ります。
削除の有無
Brand テーブル から
削除する行の値
Brand
Product
Fact
x
あり
存在しない
存在しない
y
あり
あり
存在しない
z
あり
あり
あり
Brand テーブルに Delete ロックをかけると、Brand テーブルおよびそのコンプリー
ト ファミリの全テーブルに Write ロックがかかります。いずれのテーブルからも、
行が削除されるかもしれないからです。Delete ロックが解除されるまでは、ほかの
ユーザはコンプリート ファミリのテーブルにアクセスできません。
例
テーブル ファミリにリストリクト (NO ACTION) デリートがある場合を示します。
削除動作は、すべてリストリクトになります。
Monthname テーブルが、以下の参照句で Period テーブルから参照されます。
monkey char(3) not null,
...
foreign key monkey references monthname (monkey)
on delete no action
Fact テーブルから Period テーブルへの参照は、Monthname テーブルに影響しませ
ん。Period テーブルから Monthname テーブルへの参照がリストリクト (NO
ACTION、Period テーブルの行は削除されない ) だからです。
基本概念 2-43
データの削除とカスケード デリート
図 2-7
リストリクト削除
Monthname
x
y
z
...
Brand
リストリクト
Product
Market
Period
y
z
...
カスケード
またはリストリクト
Fact
z
...
Monthname テーブルから削除される行が、Period テーブルの行から参照されてい
れば、Monthname テーブルから行は削除されません。その行を参照する行が
Period テーブルになければ削除されます。Period テーブルの行は削除されないた
め、Fact テーブルにアクセスして参照元行の有無をチェックする必要はありませ
ん。このリストリクト デリート動作は、次の表のようになります。
削除の有無
Monthname から
削除する行の値
Monthname
Period
x
あり
Period テーブルから Fact テーブルから
は何も削除されない は何も削除されない
y
インデックス
なし
z
インデックス
なし
Fact
Monthname テーブルに Delete ロックをかけると、Monthname テーブルに Write
ロックがかけられ、Period テーブル (Monthname のイミディエート ファミリの唯一
のテーブル ) に Read ロックがかけられます。Fact テーブルはロックされません。
2-44 Administrator’s Guide
データの削除とカスケード デリート
例
コンプリート ファミリにはリストリクト デリートとカスケード デリートが設定さ
れ、イミディエート ファミリにはカスケード デリートだけが設定されているとし
ます。削除動作は、すべてリストリクトになります。
Brand テーブルが、以下の参照句で Product テーブルから参照されます。
brandkey char(3) not null,
...
foreign key brandkey references brand (brandkey)
on delete cascade
Product テーブルは、カスケード デリートで Fact1 テーブルから参照されます。
prodkey char(5) not null,
...
foreign key prodkey references product (prodkey)
on delete cascade
Product テーブルは、リストリクト デリートで Fact2 テーブルから参照されます。
prodkey char(5) not null,
...
foreign key prodkey references product (prodkey)
on delete no action
Product テーブルから Brand テーブルへの参照がカスケード モードに設定されてい
ても、リストリクト モードの参照がコンプリート ファミリにあるため、Product
テーブルから Brand テーブルへの参照はリストリクト デリートになります。
基本概念 2-45
データの削除とカスケード デリート
図 2-8
リストリクト
デリート
Brand
x
y
z
...
Monthname
Product
y
z
...
Market
Period
カスケード
Fact
1
y
z
...
Fact
2
z
...
リストリクト
Brand テーブルから削除する行を参照する行が Product テーブルにあれば、Brand
テーブルの行は削除されません。次の表はリストリクト デリートとカスケード デ
リートが組み合わされている場合の動作を示します。
Brand テーブル
から削除する行
の値
Brand
Product
Fact1
Fact2
x
あり
存在しない
Fact1 テーブル
からは何も削除
されない
Fact2 テーブル
からは何も削除
されない
y
インデック
スなし
インデック
スなし
z
インデック
スなし
インデック
スなし
2-46 Administrator’s Guide
削除の有無
データの削除とカスケード デリート
この例では、Market、Period、Monthname から行を削除した場合の Fact2 に対する
動作は示されていません。これは、各テーブルのコンプリート ファミリの設定によ
ります。たとえば、Market テーブルがカスケード デリートによって Fact2 テーブル
から参照される場合、Market テーブルから削除する行を参照する行が Fact2 テーブ
ルにあれば、その参照元行も削除されます。Product テーブルと Fact2 テーブル間
の参照はリストリクト デリートであるため、Fact2 テーブルとほかのテーブル間の
参照には影響がありません。
Delete ロックを Brand テーブルにかけると、Brand テーブルには Write ロックがか
けられ、Product (Brand のイミディエート ファミリ ) に Read ロックがかけられま
す。Fact1 テーブルと Fact2 テーブルはロックされません。y を含む行は、Fact2 か
らは参照されません。また Brand、Product、Fact1 テーブルからも削除されないこ
とに注意してください。
参照整合性に関する ON DELETE 句および DELETE FROM 文の例について、『SQL
Reference Guide』の DELETE 文の説明を参照してください。
基本概念 2-47
第3章
スキーマ設計
トランザクション処理システムと意思決定支援システム . . .
トランザクション処理型データベース . . . . . . . .
意思決定支援型データベース . . . . . . . . . . . .
. .
. .
. .
スター スキーマ
. . . . .
スター スキーマの性能 . .
用語 . . . . . . . .
シンプル スター スキーマ .
複数のファクト テーブル
複数列フォーリン キー
アウトボード テーブル
マルチスター スキーマ . .
ビュー . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3-3
3-3
3-5
.
.
.
.
.
.
.
.
.
3-6
3-7
3-7
3-7
3-9
3-11
3-12
3-13
3-16
スキーマ設計の要点 . . . . . . . . . . .
スキーマを構成するブロック . . . . . . .
例 : サラダ ドレッシング データベース . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
3-17
3-19
3-22
スキーマの分析 . . . . . . .
ディメンジョン テーブルの検索
ファクト テーブルへのクエリ
属性データの決定 . . . . .
スキーマの例
. . . . . .
予約システム データベース
投資信託データベース . .
医療保険データベース . .
. .
. .
. .
. .
. . . .
. . . .
. . . .
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
3-23
3-23
3-23
3-24
. . .
. . .
. . .
. . .
. . . .
. . . .
. . . .
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
3-26
3-26
3-28
3-30
3-2 Administrator’s Guide
この章について
スキーマ設計はデータベースの性能と検索の容易さに大きく影響します。この章で
は以下について説明します。リレーショナル データベースの知識がすでにあること
を前提としています。
■
■
■
■
■
トランザクション処理システムと意思決定支援システム
スター スキーマ
スキーマ設計の要点
スキーマの分析
スキーマの例
トランザクション処理システムと意思決定支援
システム
理論上は、リレーショナル モデルはトランザクション処理システムと意思決定支援
システムの両方に適用できます。しかし、この 2 つのシステムは目的が異なるた
め、実際のデータベース管理ソフトウェアの設計の方針も異なります。トランザク
ション処理型データベースの最適化を図る場合は、データの変化による挿入、更
新、削除の操作が中心になりますが、意思決定支援型データベースの最適化では、
データの分析に必要なクエリ操作が中心になります。意思決定支援システムでは、
オンライン トランザクション処理システムで作成されたデータを抽出し、意思決定
支援システムにロードすることがよくあります。
トランザクション処理型データベース
トランザクション処理システムは、情報の迅速な抽出と更新を目的として設計され
ています。情報の内容が絶えず変化し、1 日 24 時間のオンライン体制がとられるこ
とも珍しくありません。トランザクション処理システムの例としては、注文入力シ
ステム、スキャナを使った販売時点情報管理 (POS) レジスタ、自動現金引出し機
(ATM)、航空券の予約アプリケーションなどがあります。これらのシステムは会社
の業務を支援し、企業を「運営」するものです。
スキーマ設計
3-3
トランザクション処理型データベース
トランザクション処理システムには、以下の特徴があります。
■
■
■
■
■
■
■
トランザクションの高い処理率
高いスループットを確保するため、トランザクションを単純にし、アクセ
スするテーブルを少なくしています。
絶えまない変化
トランザクションの数が非常に多く、システムの制限内で変更を管理した
り予測することはほとんど不可能です。
ジョイン パス
ジョイン パスはランダム、またはサイクリック ( 周期的 ) で、その選択は
クエリの処理時に行われます。
冗長性がない
データの整合性を維持し、ロックの競合を少なくするため、冗長データや
集約データをもちません。
関係整合性
データの信頼性は、トランザクションの整合性によって維持されます。関
係整合性チェックは非常に時間がかかり、構造が非常に複雑です。
予測可能な SQL クエリ
応答時間を一定にするため、単純な SQL を事前に定義し、検証します。
SQL 文を最適化するインデックスが使用されますが、それ以外のインデッ
クスは、更新や挿入の性能が低くなるため使用されません。
リカバリ
データの消失に備えて、2 フェーズ コミットとロールバックのメカニズ
ム、継続的なトランザクションのログ記録、ディスクのミラーリング技術
などが使用されます。
これらのためには、高度に正規化されたデータベース スキーマ、つまり複雑な結合
パスで接続された多数のテーブルを持つスキーマが必要です。正規化により、トラ
ンザクションの応答が高速になり、スキーマが複雑になります。複雑なスキーマ
は、アプリケーション処理が簡単になりますが、実際にデータを必要とする人々に
は理解しにくいものになります。
3-4 Administrator’s Guide
意思決定支援型データベース
意思決定支援型データベース
意思決定支援システムは、アナリストが情報を速く簡単に抽出できることを目的に
設計されています。分析されるデータは、通常、履歴データであるので、毎日、毎
週、および毎年の結果となります。意思決定支援システムの例には、売上収益の分
析、マーケティング情報、保険の補償請求、カタログ販売などのアプリケーション
があります。1 つの企業内の意思決定支援データベースには、最初から最後までの
データを含めることができます。つまり、製造現場での原材料の受け取り、受注入
力、請求書の追跡、およびデータベース在庫の監視から最終消費者の購入にいたる
までのすべてのデータです。これらのシステムは、ビジネスの管理に使用され、ビ
ジネスの分析や計画に必要な情報を提供します。
意思決定支援システムには、以下の特徴があります。
■
■
■
■
■
■
■
理解しやすいこと
データ構造がユーザにわかりやすく、非正規化や集約 ( データの要約 ) が
必要になることが多くあります。
比較的変更が少ないこと
データのロードが定期的なため、データベースの変更が管理できます。
ジョイン パス
ジョイン パスは単純かつ非サイクリックであり、ビジネス関係に基づいて
データベースの作成時に定義されます。
関係整合性
正しい結果の確保に必要な関係整合性は、データのロード時や削除時に
データベースで確保されます。
SQL クエリが予測不能で複雑
データベースに対する SQL クエリ文は、クエリごとに大きく異なり、予
測は不可能です。比較や順次処理を必要とする、長く複雑な SELECT 文が
含まれるクエリや、何千、何百万、何十億もの行データやインデックスを
参照するクエリもあります。
大きなリザルト セット
広範囲で高頻度の検索機能をサポートしなければなりません。
リカバリ
静的データベースの定期的バックアップやスナップショットにより、デー
タの消失を防ぎます。
IBM Red Brick Warehouse は、様々なスキーマをサポートしますが、意思決定支援シ
ステムにはスター スキーマと呼ばれるデータベース スキーマが適切です。スター
スキーマは、比較的少数のテーブルと、明確に定義された結合パスを使った単純な
構造のスキーマです。トランザクション処理型データベースの正規化された構造と
比べると、クエリの応答が速く、データベース構造にあまり詳しくないアナリスト
にも理解しやすいシンプルなスキーマです。
スキーマ設計
3-5
スター スキーマ
次の節では、シンプル スター スキーマとマルチ スター スキーマという 2 種類のス
ター スキーマについて説明します。
スター スキーマ
スター スキーマは、ファクト テーブルとディメンジョン テーブルからなります。
ファクト テーブルには、ビジネスに関する事実 ( ファクト ) を表す数量データ、つ
まりクエリの分析対象となる情報を格納します。この情報は、集約可能な計測値な
どの数値であることが多く、多数の列で構成され、行数は何百万、何十億にもなる
ことがあります。ディメンジョン テーブルはファクト テーブルより小さいことが
多く、ディメンジョン、つまりビジネスの属性を示す記述的なデータを格納しま
す。SQL クエリは、ファクト テーブルとディメンジョン テーブルの結合とデータ
の制約によって返す情報を指定します。
ファクト テーブルとディメンジョン テーブルの違いは、スキーマ上の役割だけで
す。物理的構造と、テーブル作成に使用する SQL の構文は同じです。複雑なス
キーマでは、状況に応じて、1 つのテーブルがファクト テーブルとしても、ディメ
ンジョン テーブルとしても動作することがあります。ファクト テーブルとディメ
ンジョン テーブルのどちらとして動作するかは、そのテーブルがクエリでどのよう
に参照されるかによって決まります。
ファクト テーブルとディメンジョン テーブルは物理的に同じですが、その論理的
な違いを知っておく必要があります。ファクト テーブルとディメンジョン テーブ
ルの違いを理解するため、アナリストがどのようにビジネスの実績を分析するかを
考えてみましょう。
■
■
■
営業部員は、顧客、製品、市場、期間別に収益を分析します。
財務アナリストは、品目、製品、期間別に実績と予算を比較分析します。
マーケティング部員は、製品、市場、期間別に出荷状況をチェックしま
す。
上記のケースで分析対象となる「ファクト」は、収益、実績と予算、出荷状況で
す。これらの項目は、ファクト テーブルに所属するものです。評価の切り口となる
ビジネスの「ディメンジョン」は、製品、市場、期間、品目です。これらは、ディ
メンジョン テーブルに所属します。
たとえば、スター スキーマを使用した売上データベースのファクト テーブルには、
顧客、地理的な市場、期間ごとの製品の売上収益を格納することができます。この
データベースのディメンジョン テーブルは、顧客、製品、市場、期間を定義しま
す。
スキーマ設計が適切であれば、ユーザはデータベースを検索しながらデータの内容
が理解でき、取り出したい情報だけを返すクエリを作成できるようになります。
3-6 Administrator’s Guide
スター スキーマの性能
スター スキーマの性能
どのようなスキーマでも検索の性能は重要なポイントとなりますが、大量データの
問い合わせを毎日行う意思決定支援システムでは特に重要です。IBM Red Brick
Warehouse はあらゆるスキーマ設計をサポートしますが、意思決定支援アプリケー
ションにはスター スキーマが最も適しています。
スター スキーマの性能に関する詳細については、『Query Performance Guide』を参照
してください。
用語
ファクト テーブルとディメンジョン テーブルという用語は、論理スキーマにおけ
る各オブジェクトの役割を示すものです。データベースの構造上はファクト テーブ
ルは、参照元テーブルになります。つまり、ほかのテーブルに対してフォーリン
キー参照を行います。ディメンジョン テーブルは、参照先テーブルです。1 つ以上
のテーブルからフォーリン キー参照されるプライマリ キーをもちます。
シンプル スター スキーマ
ほかのテーブルを参照したり、ほかのテーブルから参照されるテーブルは、プライ
マリ キーを持っていなければなりません。プライマリ キーは、それによって行を
一意に特定する列または列のグループです。シンプル スター スキーマの場合、
ファクト テーブルのプライマリ キーは、1 つ以上のフォーリン キーで構成されま
す。フォーリン キーとは、ほかのテーブルのプライマリ キーの値と一致する列ま
たは列のグループです。IBM Red Brick Warehouse では、フォーリン キーとプライマ
リ キーを使用し、データの抽出性能を高める STAR インデックスを作成することが
できます。
データベースを作成する際は、テーブルを作成する SQL 文で、プライマリ キーと
フォーリン キーの列を指定しなければなりません。
スキーマ設計
3-7
シンプル スター スキーマ
次の図は、1 つのファクト テーブルと 3 つのディメンジョン テーブルから構成され
るシンプル スター スキーマで、ファクト テーブルとディメンジョン テーブルがど
のような関係にあるかを示したものです。ファクト テーブルには、Key1、Key2、
Key3 という 3 つのフォーリン キーがあり、それぞれが、ディメンジョン テーブル
のプライマリ キーになっています。キー列以外の列は、ファクト テーブルの場合
はデータ列、ディメンジョン テーブルの場合は属性と呼ばれます。
図 3-1
シンプル スター スキーマ
太字の列名は
プライマリ キーを示します。
線は、
1 対多のフォーリン キー関係
を示します。
ディメンジョン
テーブル
Key 1
属性
属性
...
属性
ファクト テーブル
ディメンジョン
テーブル
Key 2
属性
属性
...
属性
Key 1
Key 2
Key 3
データ列
データ列
...
太字のイタリックで示す列名は、
プライマリー キー列であると同時
に、ほかのテーブルに対する
フォーリン キー参照もあるという
意味です。
ディメンジョン
テーブル
Key 3
属性
属性
...
スキーマを示す図では、以下の表記規則を使用します。
■
■
■
■
■
3-8 Administrator’s Guide
テーブル名の下にある枠の中の項目は、そのテーブルの列を示します。
プライマリ キー列は太字で表記します。
フォーリン キー列は、イタリックで表記します。
プライマリ キーの一部であると同時に、フォーリン キーでもある列は、
太字のイタリックで表記します。
フォーリン キーの関係は、テーブル間を結ぶ線で示します。
プライマリ キーの値は、ディメンジョン テーブルで一意ですが、ファク
ト テーブルではフォーリン キーとして何度でも使用することができます。
つまり、多対 1 の関係です。
シンプル スター スキーマ
次の図は、シンプル スター スキーマである売上データベースを示したものです。
Sales というファクト テーブルのプライマリ キーは、Product_id、Period_id、
Market_id という 3 つのフォーリン キーで構成され、各フォーリン キーは、ディメ
ンジョン テーブルのプライマリ キーを参照します。
図 3-2
Sales Database
Period テーブル
Period_id
Period_desc
Quarter
Year
Sales テーブル
Product テーブル
Product_id
Prod_desc
Brand
Size
Period_id
Product_id
Market_id
Units
Dollars
Discount
Market テーブル
Market_id
Market_desc
District
Region
ファクト テーブルのフォーリン キーと、フォーリン キーが参照するディメンジョ
ン テーブルのプライマリ キーとは、多対 1 の関係です。たとえば、Product テーブ
ルは製品を表します。テーブルの各行は特定の製品を示し、重複しない製品 ID を
持っています。この製品 ID は、製品の売上を期間別、市場別に示す Sales テーブル
では何度も現われます。
複数のファクト テーブル
スター スキーマでは、複数のファクト テーブルを使用できます。請求書と売上な
ど、互いに関係のないものを複数のファクト テーブルにしたり、性能を向上させる
ために複数のファクト テーブルを使うこともあります。たとえば、多様なレベルの
集約 ( 要約 ) データがあり、特に日別売上、月間売上、年間売上など集約データが
多い場合などです。
スキーマ設計
3-9
シンプル スター スキーマ
以下の図は、前年の売上を格納するファクト テーブルを追加した Sales データベー
スを示したものです。
図 3-3
ディメンジョンを追加した Sales データベース
Period テーブル
Period_id
Period_desc
Quarter
Year
Sales_Current
Product テーブル
Product_id
Prod_desc
Brand
Size
Period_id
Product_id
Market_id
Units
Dollars
Discount
Sales_Previous
Period_id
Product_id
Market_id
Units
Dollars
Discount
3-10 Administrator’s Guide
Market テーブル
Market_id
Market_desc
District
Region
シンプル スター スキーマ
参照元テーブルのもう 1 つの使い方は、ビジネスのディメンジョン間における多対
多の関係を定義することです。このようなテーブルは、相互参照テーブルまたは関
係テーブルと呼ばれます。たとえば、Sales データベースで、1 つの製品が 1 つ以上
のグループに所属し、1 つのグループが複数の製品で構成される場合、製品とグ
ループの可能な組み合わせを定義する参照元テーブルを設定し、多対多の関係をモ
デル化します。
図 3-4
相互参照テーブルを持つ Sales データベース
Period テーブル
Period_id
Period_desc
Quarter
Year
Sales_Current
Product テーブル
Product_id
Prod_desc
Brand
Size
Period_id
Product_id
Market_id
Units
Dollars
Discount
Market テーブル
Market_id
Market_desc
District
Region
Product/Group テーブル
Group テーブル
Group_id
Group_desc
Product_id
Group_id
複数列フォーリン キー
多対多の関係を定義するもう 1 つの方法は、複数列プライマリ キーをディメンジョ
ン テーブルに設定し、ファクト テーブルのフォーリン キーから参照させます。た
とえば、1 つの製品が 1 つ以上のグループに所属し、1 つのグループが複数の製品で
構成される Sales データベースの多対多の関係です。この関係をモデル化するには、
以下の図のように、Product テーブルを参照する Sales_Current テーブルに複数列
フォーリン キーを定義します。
スキーマ設計
3-11
シンプル スター スキーマ
図 3-5
複数列フォーリン キーを使用する Sales データベース
Period テーブル
Period_id
Period_desc
Quarter
Year
Sales_Current
Product テーブル
Product_id
Group_id
Prod_desc
Brand
Size
Group_desc
Period_id
Product_id
Group_id
Market_id
Units
Dollars
Discount
Market テーブル
Market_id
Market_desc
District
Region
この図では、Product_id 列と Group_id 列は、Product テーブルの複合プライマリ
キーであり、2 列合わせて Sales_Current テーブルのフォーリン キー参照を構成し
ています。
アウトボード テーブル
ディメンジョン テーブルには、ほかのディメンジョン テーブルのプライマリ キー
を参照するフォーリン キーを複数設定することもできます。参照先ディメンジョン
テーブルは、アウトボード ディメンジョン テーブル、アウトリガー ディメンジョ
ン テーブル、またはセカンダリ ディメンジョン テーブルとも呼ばれます。以下の
図の District と Region は、Market テーブルで使用する ID コードを定義する 2 つの
アウトボード テーブルです。
3-12 Administrator’s Guide
マルチスター スキーマ
図 3-6
アウトボード テーブルを持つ Sales データベース
Period テーブル
Period_id
Period_desc
Quarter
Year
Sales_Current
Product テーブル
Product_id
Prod_desc
Brand
Size
Period_id
Product_id
Market_id
Units
Dollars
Discount
District テーブル
Market テーブル
Market_id
Market_desc
District_id
Region_id
District_id
District_desc
Region テーブル
Region_id
Region_desc
この図では、Market テーブルは参照元テーブルかつ参照先テーブルなので、クエ
リに応じて、ファクト ( 参照元 ) テーブルにもディメンジョン ( 参照先 ) テーブルに
もなります。
マルチスター スキーマ
シンプル スター スキーマでは、フォーリン キー列を結合してファクト テーブルの
プライマリ キーが作成されます。フォーリン キー列を結合しても、ファクト テー
ブルの行を特定できる一意な ID にならない場合は、これらのアプリケーションに、
マルチ スター スキーマが必要です。
マルチスター スキーマでは、ディメンジョン テーブルを参照するフォーリン キー
と、行を特定する 1 つ以上の列で構成されるプライマリ キーの両方がファクト テー
ブルに設定されます。マルチ スター スキーマでは、プライマリ キーとフォーリン
キーは同一ではありません。これが、マルチ スター スキーマとシンプル スター ス
キーマの違いです。
スキーマ設計 3-13
マルチスター スキーマ
次の図は、マルチ スター スキーマにおけるファクト テーブルとディメンジョン
テーブルの関係を示します。ファクト テーブルには、Fkey1、Fkey2、Fkey3 という
3 つのフォーリン キーがあり、それぞれが、ディメンジョン テーブルのプライマリ
キーです。シンプル スター スキーマと異なり、ファクト テーブルのプライマリ
キーはこれらの列ではなく、ディメンジョン テーブルを参照する Fkey1 と、ディメ
ンジョン テーブルを参照しない Key1 と Key2 が結合されて、プライマリ キーを構
成します。プライマリ キーは、マルチ スター スキーマのフォーリン キーとほかの
列との任意の組み合わせから構成できます。
図 3-7
マルチスター スキーマにおけるファクト テーブルとディメンジョン テーブルの関係
太字の列名は
プライマリ キーを示します。
線は、
1 対多のフォーリン キー関係
を示します。
ディメンジョン
テーブル
Key 1
属性
属性
...
属性
ファクト テーブル
ディメンジョン
テーブル
Pkey 2
属性
属性
...
属性
3-14 Administrator’s Guide
Fkey 1
Fkey 2
Fkey 3
Key1
Key2
データ列
データ列
...
データ列
太字のイタリックで示す列名は、
プライマリー キー列であると同時
に、ほかのテーブルに対する
フォーリン キー参照もあるという
意味です。
イタリックの列名は、プライマリ
キーに使用されないフォーリン
キーです。
ディメンジョン テーブル
Pkey 3
属性
属性
...
属性
マルチスター スキーマ
次の図は、2 つのアウトボード テーブルを持つマルチ スター スキーマである小売
データベースを示します。Transact というファクト テーブルは、7 日分の日別売上
を保持します。ファクト テーブルのプライマリ キーは、Date、Receipt、および
Line_item の 3 つの列からなります。これらのキーを組み合わせると、ある行を特
定する重複しない ID になります。フォーリン キーは、Store ディメンジョン テーブ
ルと SKU ( 在庫保有単位 ) ディメンジョン テーブルを参照する Store_id 列と
SKU_id 列から構成されます。Class と Subclass という 2 つのアウトボード テーブル
は、SKU ディメンジョン テーブルから参照されます。
図 3-8
2 つのアウトボード テーブルを使用するマルチスター スキーマ
Class テーブル
Transact テーブル
SKU テーブル
Class_id
Class_desc
SKU_id
Class_id
Subclass_id
Item
Subclass テーブル
Store_id
SKU_id
Date
Receipt
Line_item
Units
Price
Amount
Store テーブル
Store_id
Store_name
Region
Manager
Subclass_id
Subclass_desc
このデータベース スキーマでは、Transact テーブルに対するクエリにより、品目別
の売上、店舗や地域別の売上、日付別の売上などの情報を得ることができます。
シンプル スター スキーマと異なり、マルチ スター スキーマでは、ファクト テーブ
ルのフォーリン キーを結合した値を重複して使用できるため、フォーリン キーを
結合しても行を特定できません。この例では、店舗 (Store_id)、品目 (SKU_id)、日
付 (Date) の売上データが同じものが複数あります。代わりに、列 ID はプライマリ
キーに基づいています。つまり、Date、Receipt、Line_item によって特定されます。
スキーマ設計 3-15
ビュー
ビュー
ビューの使用によってスキーマ設計がシンプルになることもあります。ビューは、
既存のテーブルやテーブルの組み合わせから、行と列を選択して作成する仮想テー
ブルです。たとえば、従業員の氏名と内線番号を従業員データベースから選択して
ビューを作成すると、住所や給与などの個人的な情報を除いた社内全体の電話番号
リストになります。一定期間のファクトだけを抽出したビューを作成すれば、クエ
リで期間を指定する必要がありません。
ビューは、以下のような用途に使用できます。
■
■
■
■
■
セキュリティの強化
複雑なテーブルを単純にし、必要な情報だけを抜き出します。
クエリ制約の簡易化
テーブルに対する権限の付与などのセキュリティ管理の簡略化
ユーザに意識させずに管理者がテーブルを変更します。
スキーマ設計が変わっても、ユーザから見たビューは変わりません。
ビューを作成するには、CREATE VIEW 文を使用します。
さらに、事前計算ビューを作成し、最適の集約テーブルを利用するように、自動的
にクエリを書き換えることができます。事前計算ビューおよび自動的なクエリ書き
換えの詳細については、『IBM Red Brick Vista User’s Guide』を参照してください。
3-16 Administrator’s Guide
スキーマ設計の要点
スキーマ設計の要点
データベースの使いやすさや性能は、スキーマ設計によってさまざまな影響を受け
ます。初期設計で十分に検討し、ユーザのニーズを満たす適切なデータベースを設
計する必要があります。ここでは、データベース設計の詳しい手順ではなく、デー
タベースを設計するときに注意すべき点を説明します。
以下の点を考慮して適切なスキーマ設計を行います。
■
■
■
■
■
ビジネス プロセス
製品の受注、保険証書の記入、販売促進活動など、ビジネスの主要プロセ
スを定義します。プロセスの内容は企業ごとに異なりますが、適切なデー
タベースを作成するためには、各プロセスを明らかにし、定義しなければ
なりません。プロセスの定義では、現場で働いている人々へのインタ
ビューが不可欠です。
ユーザがデータベースを使って達成したいことは何か
何を記録するか、ビジネスのファクトとディメンジョンを表す用語の使い
方など、データベースはビジネスを反映しなければなりません。マネー
ジャやユーザとのインタビューから、彼らが知りたいこと、どのようにし
てビジネスを評価しているか、何を基準として決定を下しているか、それ
らを表すのにどういう用語を使っているかなどがわかるでしょう。これら
の情報は、ファクト テーブルやディメンジョン テーブルの内容の決定に
役立ちます。
データの情報源
データベースのテーブルに格納するデータは、一貫性のある有効かつ有用
なデータでなければなりません。入手可能な入力データと情報源を分析
し、スキーマを実現できるデータであるかどうかを判定します。
ディメンジョン テーブルに反映させるビジネスのディメンジョンと属性に
は、どのようなものがあるか
独立したディメンジョンは、それぞれ個別のテーブルで表します。従属関
係にあるディメンジョンは、1 つのテーブルに統合することができます。
製品の記述や地理的位置などの属性は、テキストやコードで表されます。
属性は、クエリの制約やレポートの区分に使用する要素になります。ディ
メンジョン テーブルは、インタビューやデータ分析の結果を基に設定しま
す。
ディメンジョンは、時間とともに変化するものか
変更の多いディメンジョンは、ディメンジョンではなくファクトにした方
が良い場合があります。
スキーマ設計 3-17
スキーマ設計の要点
■
■
■
■
3-18 Administrator’s Guide
評価するファクトには、どのようなものがあるか
ファクトは、収益や在庫のように、定量的な数値で表されるのが一般的で
す。加算可能なファクトは、合計値を算出してレポートの評価基準とする
ことができます。たとえば、月間売上は加算可能な値であるため、これを
合計して当月までの年間累計を算出することができます。在庫の月末残高
は、加算可能な値とは言えません。月末の在庫数を合計しても年末の残高
にはならないからです。ただし、月ごとの平均値を算出する上では意味が
あるかもしれません。
ファクト テーブルのファミリは必要か
評価単位となるディメンジョンや評価時期が異なるファクトは、別のテー
ブルに格納する必要があります。たとえば、受注、出荷、製造を 1 つの
データベースで管理する場合、各分野で評価するファクトはそれぞれ異な
り、共通でないディメンジョンもあるでしょう。
ファクトのグラニュラリティ
グラニュラリティとは、ファクト テーブルの各行に格納する情報の詳細度
のことです。各行には必ず同じ種類のデータを格納します。たとえば各行
に製品、店別の 1 日の売上や店別の日用品を格納します。
グラニュラリティの異なるデータを格納するには、複数のファクト テーブ
ル ( 日別、月間、年間のテーブル ) を使うか、シングル テーブルを修正し
てデータとともにグラニュラリティ フラグ ( 日別、月間、年間いずれの
データであるかを示す列 ) が格納されるようにします。グラニュラリティ
の異なるデータの格納方法を決める際は、データの量、ディスク領域の所
要量、要求される性能も考慮する必要があります。
変更の処理方法と、履歴情報の重要度
データがあまり変化しない場合や、履歴情報がそれほど重要でない場合
は、新しい事実だけをディメンジョン テーブルに反映させます。過去の履
歴データが重要であれば、新旧のデータを反映できるようにします。ディ
メンジョンが頻繁に変更される場合は、時間に依存するディメンジョンと
して、月間、四半期、年間などの時間属性をもたせる必要があります。
スキーマを構成するブロック
スキーマを構成するブロック
一般的なスキーマの例をいくつか示します。Fact または Factx というテーブルは、
ファクト ( 参照元 ) テーブルを表します。それ以外のテーブルは、ディメンジョン
( 参照先 ) テーブルです。以下の図は、シンプル スター スキーマとマルチ スター ス
キーマの両方に適用します。
1 つのディメンジョン テーブルから構成されるスキーマ
図 3-9
1 つの
ディメンジョン
テーブル
Market
...
1 つのファクト テーブルと 1 つのディメンジョン テーブルから構成されるスター ス
キーマ
図 3-10
Fact
...
Market
...
1 つの
ディメンジョン
テーブルから
構成される
スター スキーマ
スキーマ設計 3-19
スキーマを構成するブロック
1 つのファクト テーブルと複数のディメンジョン テーブルから構成されるスター ス
キーマ
図 3-11
Fact
Product
...
...
Period
複数の
ディメンジョン
テーブルから
構成される
スター スキーマ
...
Market
...
ディメンジョン テーブルの一部を共有するファクト テーブルのファミリがある複
数のスター スキーマ
Fact1
...
図 3-12
Product
...
Fact2
...
Period
...
Fact1a
Market
...
...
3-20 Administrator’s Guide
SalesPerson
...
複数の
ファクト テーブル
から構成される
スター スキーマ
スキーマを構成するブロック
ほかのディメンジョン テーブル ( アウトボード テーブル ) を参照するディメンジョ
ン テーブルを持つ拡張スター スキーマ
Fact1
Product
...
...
図 3-13
アウトボード テー
ブルを持つスター
スキーマ
Period
Country
...
...
Market
...
Type
...
スキーマをスター スキーマにすることができます。これは、シングル ディメン
ジョン テーブルを参照する複数のフォーリン キーを格納するファクト テーブルを
持つスキーマです。
Period
Fact1
Product
...
...
図 3-14
複数のフォーリン
キーを持つスター
スキーマ
...
Market
...
スキーマ設計 3-21
例 : サラダ ドレッシング データベース
例 : サラダ ドレッシング データベース
スキーマ設計が、データベースの使いやすさと価値に影響を与える例を示します。
このデータベースは、スーパーマーケットにおけるサラダ ドレッシング製品の 4 年
間の売上を週単位で記録しています。消費者向け商品の代表的なマーケット分析
データベースです。汎用製品コード (UPC) で表したサラダ ドレッシング製品は、
14,000 品目あります。全米を 120 の地域 ( 市場 ) に分け、4 年間 208 週の各週ごとに
データを集計します。
以下の図に示すように、サラダ ドレッシング データベースには、1 つのファクト
テーブル Sales と、3 つのディメンジョン テーブル Product、Week、および Market
があります。
図 3-15
Period テーブル
Product テーブル
( レコード数 14,000)
Product_id
Description
Brand
Manufacturer
Pack
Class
Flavor
Size
Sales テーブル
( レコード数 3,800,000)
Product_id
Period_id
Market_id
Units
Dollars
Discount
Selling_price
Large_ads
Medium_ads
Small_ads
Period_id
Period_desc
Quarter
Fiscal_year
Calendar_year
Agg_level
サラダ
ドレッシング
データベースの例
Market テーブル
Market_id
Market_desc
District
Region
Sales ファクト テーブルの各レコードには、3 つのディメンジョン Product、Period、
Market のそれぞれに対応するフィールドが 1 つずつあります。これらの列が Sales
テーブルのフォーリン キーになります。フォーリン キーの値を結合すると、Sales
テーブルのある行を特定する一意な ID になります。Sales テーブルには、市場分析
の評価対象となる値を格納する 7 つの項目があります。
ディメンジョン テーブルは、それぞれ 1 つのビジネス ディメンジョンを表し、1 つ
のプライマリ キーと、各ディメンジョンの属性列から構成されます。
3-22 Administrator’s Guide
スキーマの分析
スキーマの分析
システム管理者は通常、データベースを新規作成するより、既存のデータベースを
活用して仕事をすることが多いでしょう。既存のスキーマを分析し、向上させるに
は、ディメンジョン テーブルの値の範囲を考慮し、ファクト テーブルとディメン
ジョン テーブルをジョインするクエリを作成し、使用する属性を決定します。
ディメンジョン テーブルの検索
あるディメンジョンについて値の範囲を知りたい場合は、そのディメンジョンに対
応するディメンジョン テーブルにクエリを実行します。たとえば、売上データの対
象となる市場にはどのようなものがあるかを知るには、次のように入力します。
select market_desc from market;
すべての市場 ( この場合は 120) の一覧が表示されます。Product テーブルと Week
テーブルに同様のクエリを実行すると、Sales テーブルの対象となる製品と期間の
一覧が表示されます。
ワイルドカード式を使うと、検索範囲を限定することができます。たとえば、田舎
風ドレッシング (ranch-style dressing) について知りたい場合は、ranch を含むワイル
ドカード式を SELECT 文に指定します。すると、Product テーブルからの表示リス
トには、14,000 の全品目ではなく、ranch という文字が製品説明に含まれている製
品だけが検索されます。
ディメンジョン テーブルを検索すると、行数が何百万にも及ぶファクト テーブル
に SELECT DISTINCT 文を実行するよりも速く結果が得られます。スター スキーマ
の各ディメンジョンを定義するテーブルを作成しておけば、このような検索が可能
になります。ディメンジョン テーブルを使ってデータベースのディメンジョンを検
索し、その内容を把握することができます。
ファクト テーブルへのクエリ
各ディメンジョンのリストを作成し、データベースにある市場、製品、期間を把握
したら、関心のある市場、製品、期間を絞り込みます。リストには、各項目の正確
な記述が表示されるため、クエリの制約を正しく記述することができます。ファク
ト テーブルとディメンジョン テーブルをジョインするクエリを作成し、ファクト
テーブルの加算データとディメンジョン テーブルの記述データをリンクさせます。
スキーマ設計 3-23
属性データの決定
属性データの決定
ディメンジョン テーブルの非キー列は、属性と呼ばれます。属性の使い方を理解す
るため、サラダ ドレッシング データベースの Product テーブルについて考えてみま
しょう。Product テーブルには、汎用製品コード (UPC) で識別される 14,000 の品目
が格納されます。UPC は、プライマリ キー (Product_id) になります。この ID によ
り、特定の行を抽出することができます。UPC ではなく、ブランドやメーカーのよ
うなカテゴリでデータにアクセスしたい場合もあります。属性は、データを分類す
る際の基準として頻繁に使用される尺度となります。
たとえば、ブランド属性は、14,000 のサラダ ドレッシング製品をブランド別に分類
し、特定のブランド名の製品だけを選択できるようにします。別の属性を使うと、
同じ 14,000 の製品をメーカー別に分類することができます。大手メーカーが製造す
る 12 オンスのビン入り田舎風サラダ ドレッシングを選択したい場合は、以下の属
性の中から該当のものを使用します。
属性
戻り値
Class
ダイエット、レギュラー
Flavor
田舎風、ブルーチーズ、サウザン アイランド
Size
12 オンス、8 オンス
Manufacturer
Great Foods、Major Mills、Crafty Cuisine
良いスキーマ設計とは、ユーザの関心事項と集約、選択的制約、レポートの区分に
使用できる属性を反映したものです。Product テーブルには、前述の属性に加え、
以下のような属性を設定することができます。
UPC ( キー フィールド )
販売地域
製造元
ブランド グループ
ブランド
分類
3-24 Administrator’s Guide
濃度
風味
サイズ
特殊パッケージ
販売促進活動
属性データの決定
属性が少ないテーブルもあります。たとえば、財務アプリケーションの期間ディメ
ンジョンは、以下の 3 つの属性だけです。
■
■
■
期間 ID ( キー フィールド )
開始日
終了日
詳細データと集約データをそれぞれ違うテーブルに格納したい場合は、Period テー
ブルの集約レベルによって区別することができます。一方、集約データと詳細デー
タを同一のテーブルに格納した場合は、そのテーブルに対するクエリを集約レベル
に限定し、データの重複を避けなければなりません。
属性は階層順でなくてもかまいませんが、総勘定元帳の勘定一覧表のように、階層
順でなければならない場合もあります。1 つのテーブルに複数の階層をもたせるこ
ともできます。たとえば、地域のテーブルに地理的な階層だけでなく、販売組織や
顧客の地域的分布といった異なる階層を合わせ持たせることもできます。これらの
属性は、いずれも制約の基本要素となります。
特定の品目にない属性や、値が不定な属性は、NULL 値を許すように設定します。
整合性のある正確な属性を十分に設定したスキーマに対しては直勧的にクエリがで
き、データベース管理部門の負担も少なくなります。
スキーマ設計 3-25
スキーマの例
スキーマの例
次に、使用しやすさと効率に重点を置いた一般的なスキーマ設計について、例を挙
げて説明します。
予約システム データベース
プライマリ キーとフォーリン キーが、同じ列で構成されないマルチ スター スキー
マの例を示します。この設計には、ファクト テーブルのファミリも含まれます。つ
まり、Bookings テーブル、Actuals テーブル、および Promo_Schedule テーブルで
す。
このデータベースは、ホテル チェーンの予約 (Bookings) と実際の宿泊状況
(Actuals)、各種の販売促進活動 (Promo_Schedule) を追跡します。ホテル チェーンの
顧客 (Frequent_Stayers)、販売促進活動の内容 (Promo_Type)、系列ホテルの情報
(Facility) も管理します。
3-26 Administrator’s Guide
予約システム データベース
図 3-16
予約システムのスキーマ
Frequent_Stayers
テーブル
Actuals テーブル
Facility テーブル
Facility_id
Hotel_name
Num_rooms
City
State
Type
IATA_city_code
...
Chkout_date
Facility_id
Cust_id
Room_type_id
Confirm_#
Promo_id
Chkin_date
#_nights
#_party
Actual_room_rate
Std_room_rate
...
Cust_id
Cust_name
Street_add
City
State
Zip
Cust_type
Point_bal
...
Bookings テーブル
Room テーブル
Room_type_id
Bed_type
Smoking_status
Room_desc
Patio_flag
Promo_Schedule
テーブル
Promo_Type テーブル
Promo_id
Name
Type
Description
Chkout_date
Facility_id
Cust_id
Room_type_id
Confirm_#
Promo_id
Chkin_date
Arrival_code
#_nights
#_party
Room_rate
...
Period テーブル
( およびシノニム )
Perkey
Date_long
Day_of_wk
Fiscal_qtr
...
Start_date
Facility_id
Promo_id
End_date
前払金 ( 予約金、ケーブル TV 加入料、自動車保険など ) がある業務では、前払金を
受領した時ではなく、所得として計上された時点で取引が成立するので、データ
ベースもそのような取引形態をサポートする設計にしておく必要があります。
スキーマ設計 3-27
投資信託データベース
投資信託データベース
集約データをもつスキーマの例を示します。異なる集約レベルのデータを 1 つの
テーブルに統合するのではなく、日別データを 1 つのテーブルに格納し、集約デー
タ ( 月間、年間など ) を別のテーブルに格納します。複数の集約レベルを 1 つの
テーブルに統合するか、複数のテーブルに分けるかは、非集約データに対する集約
データの比率と、予想されるクエリの内容に依存します。集約データと非集約デー
タを同一のテーブルに格納した場合は、集約レベルを制約として各クエリに指定し
てください。
集約データを別のテーブルに格納すると、ディスク領域の所要量は増えますが、性
能は向上します。それに、集約テーブルのディスク領域は、非集約ファクト テーブ
ルより少ないのが普通なので、場合によっては、このスペースとパフォーマンスの
トレードオフは考慮する価値があります。
たとえば、ファクト テーブルのデータ量が 100GB だとします。5GB、100MB、
2MB の集約テーブルを 3 つ作成した場合、データの増加量はファクト テーブルの
5% に過ぎません。その結果、ディメンジョン テーブルとファクト テーブルを集約
したものを結合するクエリが実行できるようになり、100GB のファクト テーブルで
はなく、2MB のファクト テーブルを結合するだけで結果が得られるようになりま
す。クエリの複雑さにもよりますが、何千倍も高速になり、数分、数時間、あるい
は数日かかっていた結果が数秒で返されるようになります。もちろん、使用状況は
それぞれ異なるため、集約データの使用が常に適切であるとはかぎりません。
Vista を使用すると、既存の集約テーブルを使用して事前計算ビューを作成できま
す。事前計算ビューを作成すると、Vista は、詳細テーブルに対して実行されたクエ
リを、集約テーブルを利用するように自動的に書き換えます。TMU のロード操作
および REORG 操作中に、詳細テーブルの変更に基づいて集約テーブルを自動的に
更新できます。Vista の詳細については、『IBM Red Brick Vista User’s Guide』を参照
してください。
3-28 Administrator’s Guide
投資信託データベース
次の図に示す投資信託のデータベースは、投資信託の日別売上と月間売上を記録す
るものです。顧客の組織、投資信託の内容、運用計画に関する情報も管理します。
図 3-17
投資信託データベースのスキーマ
Product Line テーブル
Daily テーブル
Client Org テーブル
Orgkey
Organization
Org_type
Parent_name
Market
Segment
Region
Contract
System
Perkey
Orgkey
Fundkey
Progkey
Closing_price
#_transactions
Month_to_date_sales
Ending_assets
Measure_1
Measure_2
...
Monthly テーブル
Program テーブル
Progkey
Prog_name
Sales Person テーブル
Saleskey
Sales_person
Sales_type
Organization
Market
Segment
Region
Level
Perkey
Orgkey
Fundkey
Progkey
Monthly_sales
#_transactions
Month_end_assets
Month_to_date_sales
Year_to_date_sales
Ending_assets
Average_assets
Measure_1
Measure_2
...
P_line_key
Product_line
...
Security テーブル
Fundkey
Progkey
Fund_name
Discipline
Basis_points_1
Basis_points_2
...
Period テーブル
Perkey
Date_long
Day_of_wk
Fiscal_qtr
B_days_mo
...
Contact Mgmt テーブル
Perkey
Fundkey
Saleskey
To_dos
Dollar_sales
Profitability
#_of_contacts
Measure_1
Measure_2
...
スキーマ設計 3-29
医療保険データベース
医療保険データベース
医療保険会社の保険金請求状況を分析するスター スキーマの例を示します。この
データベースは、保険の売上と保険金請求金額を記録し、顧客、各顧客の保険、保
険金請求のレコードを管理します。
図 3-18
医療保険会社のスキーマ
Policy テーブル
Policykey
Policy type
Agent
Conditions
Policy Sales テーブル
Policykey
Policy_holderkey
Perkey (start date)
Transactkey
Premium_dollars
Coverage_period
Coverage_limit
Period テーブル
Perkey
Month
Year
Fiscal_period
Transaction テーブル
Transactkey
Transaction_desc
Claims テーブル
Policy_holder テーブル
Policy_holderkey
Name
Address
City
State
3-30 Administrator’s Guide
Perkey
Claimkey
Transactkey
Claim_dollars
Claim Type テーブル
Typekey
Type_desc
Claim_Desc テーブル
Claimant テーブル
Claimkey
Typekey
Claimantkey
ProvID
ProcCode
Claimantkey
Name
Address
City
State
医療保険データベース
医療保険に関連した分野の例をもう 1 つ示します。団体保険について、加入者
(Members) の保険金請求 (Claim) と認定状況 (Authorization) を記録し、患者と保険会
社 (Provider) の情報、診断 (Diagnosis)、サービスの内容 (ServiceType) を始めとする多
くのビジネス ディメンジョンを管理します。このスキーマには、2 つのファクト
テーブルがあります。1 つは、スター スキーマの Claim テーブルです。もう 1 つは、
1 つの列からなるプライマリ キーと、プライマリ キーではない複数のフォーリン
キーを持つマルチスター スキーマの Authorization テーブルです。Authorization
テーブルには、フォーリン キー列に同じ値の組み合わせをもつ行を重複して格納す
ることができます。テーブルの各行は、プライマリ キーの値で特定されるからで
す。どちらのテーブルにも、多くのディメンジョン テーブルを参照する多数の
フォーリン キーがあります。
この図では、各テーブルのプライマリ キーがゴシック体で表示され、プライマリ
キー名とフォーリン キー名のみが示されています。テーブルのほかの属性は示され
ていません。ディメンジョン テーブルの数が多いため、ファクト テーブルの
フォーリン キーと、ディメンジョン テーブルのプライマリ キーとを結ぶ多対 1 の
線も省略されています。
スキーマ設計 3-31
医療保険データベース
図 3-19
複数のディメンジョン テーブルを持つ医療保険会社のマルチ スター スキーマ
Claim テーブル
Members
MemID
...
MemGroups
MemGrp
...
Diagnosis
DiagCode
...
Procedure
ProcCode
...
Occupation
MemID
MemGrp
DiagCode
ProcCode
PCPID
PCPRisk
OccCode
DateCode
ProvID
ProvRisk
ProvVendor
ServCode
SPICode
ProvSpec
ServCat
Provider
ProvID
...
ProviderRisk
ProvRisk
...
ProviderVendor
ProvVendor
...
ProviderSpecialty
ProvSpec
...
PriCareProv
OccCode
...
PCPID
...
PCPRisk
PCPRisk
...
PCPVendor
AdmitType
AdmitType
...
AdmitDate
AdDate
...
DischargeDate
DisDate
...
Authorization
AuthNo
MemID
MemGrp
DiagCode
ProvID
AdDate
DisDate
PCPID
ProcCode
ServCat
ServiceType
ServCode
...
ServiceDate
DateCode
...
ServicePlace
SPICode
...
ServiceCategory
ServCat
...
3-32 Administrator’s Guide
PCPVend
...
第4章
ウェアハウス データベース
の物理設計
データベースのデータ モデル .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-3
インデックスの追加 . . . . . . . . . .
STAR インデックス . . . . . . . . .
列の順序 . . . . . . . . . . .
複数のファクト テーブルに対するクエリ
B-TREE インデックス . . . . . . . .
TARGET インデックス . . . . . . . .
選択性の低い制約について . . . . .
適切なドメイン サイズの選択 . . . .
ローカルにセグメント化されるインデックス
インデックスがない場合 . . . . . . .
TARGETjoin 処理の管理方法 . . . . . .
大規模なディメンジョン テーブル . .
複数列フォーリン キー . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-4
4-6
4-7
4-8
4-9
4-10
4-11
4-11
4-13
4-13
4-14
4-14
4-15
. .
. .
. .
. .
. .
4-16
4-16
4-18
4-19
4-21
.
.
.
.
.
.
.
.
4-22
4-22
4-24
4-25
. .
. .
. .
. .
4-25
4-26
4-27
4-28
セグメントの設計 . . . . . . . . . . . . . . .
デフォルト セグメントと名前付きセグメントの使い分け
名前付きセグメントの使用方法 . . . . . . . . .
セグメント化の方法の決定 . . . . . . . . .
PSU のサイズと拡張 . . . . . . . . . . .
. .
. .
. .
. .
. .
定期的にデータを更新するデータベースの設計
. . . . .
ファクト テーブルと同様のインデックスのセグメント化 .
ローカル インデックスの特性 . . . . . . . . . .
テーブルおよび各インデックスの末尾の小さなセグメント
ディスク領域の構成 . . . . . . .
ユーザ テーブルのサイズの見積り .
インデックス サイズの見積り . .
インデックスのフィル ファクタ
. . . .
. . . .
. . . .
. . . .
.
.
.
.
. . . . .
. . . . .
. . . . .
. . . . .
STAR インデックス . . . . . . . . . . . . . . .
B-TREE インデックス . . . . . . . . . . . . . .
TARGET インデックス . . . . . . . . . . . . . .
例 : テーブル、インデックス、システム テーブルのサイズの試算
Fact1 テーブルとインデックス . . . . . . . . . . .
Market テーブルとインデックス . . . . . . . . . .
Product テーブルとインデックス . . . . . . . . . .
システム テーブルのサイズの見積り . . . . . . . . . .
サイズ : システム テーブル . . . . . . . . . . . .
ユーザ テーブル、インデックス、
システム テーブルの総スペース . . . . . . . . . .
一時領域の所要量の見積もり . . . . . . . . . . .
オプティマイズ モードのインデックス作成における
一時領域の使用法 . . . . . . . . . . . .
一時領域の割り当て . . . . . . . . . . . . .
ランダムなディレクトリの使用 . . . . . . . .
ファイルの作成と使用 . . . . . . . . . . .
飽和状態と領域不足の状態 . . . . . . . . .
インデックス作成に必要な一時領域の見積り . . . .
DIRECTORY Location 値 . . . . . . . . . .
THRESHOLD 値 . . . . . . . . . . . . .
MAXSPILLSIZE 値 . . . . . . . . . . . .
TARGET インデックスの一時領域の所要量 . . . . .
現在の設定値の確認 . . . . . . . . . . . . .
テンポラリ ファイルの削除 . . . . . . . . . .
クエリ処理における一時領域の使用法 . . . . . .
クエリ処理に必要な QUERY_MEMORY_LIMIT の見積り
クエリ処理に必要な MAXSPILLSIZE 値の見積り . . .
実行時間の長いクエリのリザルト バッファ . . . . .
RESULT BUFFER . . . . . . . . . . . . .
RESULT BUFFER FULL ACTION . . . . . . .
テーブル データの増加への対応 . . . . . . . . .
テーブルの拡大が STAR インデックスに及ぼす影響 .
4-2 Administrator’s Guide
.
.
.
.
.
.
.
.
.
4-30
4-31
4-31
4-33
4-35
4-36
4-38
4-39
4-40
.
4-41
.
.
.
.
4-41
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4-43
4-44
4-44
4-45
4-45
4-46
4-47
4-47
4-49
4-51
4-52
4-53
4-53
4-55
4-56
4-56
4-57
4-57
. . . .
. . . .
.
.
4-58
4-59
この章について
この章では、IBM Red Brick Warehouse データベースを作成する前に考慮すべき設計
項目について説明します。以下について説明します。
■
■
■
■
■
■
■
データベースのデータ モデル
インデックスの追加
セグメントの設計
定期的にデータを更新するデータベースの設計
ディスク領域の構成
一時領域の所要量の見積もり
テーブル データの増加への対応
データベースのデータ モデル
データベースの新規作成に際しては、データベースにおけるユーザ テーブルの構
成、作成すべきデータベースの数をデータベース管理者が決定する必要がありま
す。1 つのデータベースには、多くの異なる種類のユーザ テーブルを格納できま
す。理論的には、大規模で複雑なデータベースでも、すべてのテーブルを 1 つの
データベースに作成することは理論的に可能です。しかし実際には、目的の異なる
ユーザ テーブルは、それぞれ別のデータベースに格納すると良いでしょう。複数の
データベースに分けると管理がしやすくなり、セキュリティ、バックアップ、保守
の独立性が高くなり、エンド ユーザから見てデータベースがわかりやすくなりま
す。
一般に、1 つのビジネス アプリケーションをサポートするテーブルは、1 つのデー
タベースに格納します。ユーザのアクセス許可やマクロの設定が、アプリケーショ
ン全体で共有できるからです。これに対し、ビジネス アプリケーションが異なる
テーブルは、それぞれ別のデータベースに格納します。
新規のデータベースを作成する最初のステップは、データベースに組み込むテーブ
ルの決定と設計、内容の詳細、テーブル間の関係の定義です。このプロセスは、第
3 章「スキーマ設計」で説明されています。
ウェアハウス データベースの物理設計
4-3
インデックスの追加
インデックスの追加
Red Brick サーバ データベースでは、プライマリ キーの B-TREE インデックスが
テーブルの作成時に自動的に作成されます。インデックスを追加することによっ
て、クエリの性能がさらに向上する場合があります。ただし、各インデックスに必
要な格納領域、および INSERT、UPDATE、DELETE、または LOAD の各操作時のイ
ンデックス更新にかかる時間を、クエリ性能の向上と比較して作成するかどうかを
判断する必要があります。ディスク容量が十分で、ロード性能が重要でない場合
は、クエリで制約を受けるすべての列にインデックスを付けると良いでしょう。
インデックスはいつでも削除できます。ただし、プライマリ キー インデックスを
削除した場合は、そのプライマリ キーに別の B-TREE インデックスか STAR イン
デックスを作成しないと、テーブルに対する INSERT、UPDATE、DELETE の操作
が参照整合性違反になることがあります。
インデックスを追加すると、クエリ性能に大きな影響が生じます。クエリで使用す
るインデックスの選択方法と、テーブル ジョインのアルゴリズムについては、
『Query Performance Guide』を参照してください。
4-4 Administrator’s Guide
インデックスの追加
インデックスを追加する場合は、以下の点を考慮してください。
■
■
■
■
■
■
■
■
スター スキーマの中央にある参照元 ( ファクト ) テーブルに、1 つ以上の参
照先 ( ディメンジョン ) テーブルへのプライマリ / フォーリン キー参照が
あれば、1 つ以上の STAR インデックスを作成します。
STAR インデックスは、対象とするフォーリン キー列が複数ある場合に効
果があります。
ファクト テーブルに対するクエリの制約が、既存 STAR インデックスの末
尾のフォーリン キー列だけを対象とする場合か、末尾列に対するクエリの
制約が先頭列に対する制約よりも選択性が高い場合は、その列をインデッ
クス キーの先頭列として指定した STAR インデックスを追加します。
スキーマ設計がスター スキーマで、参照先 ( ディメンジョン ) テーブルが多
く、作成した STAR インデックスがすべてのクエリに対して最適化された
性能を発揮していない場合は、参照元 ( ファクト ) テーブルのフォーリン
キー列に TARGET インデックスを作成し、TARGETjoin 処理を有効にする
ことができます。TARGETjoin 処理の詳細については、『Query Performance
Guide』を参照してください。
複数のファクト テーブルに対するクエリ (ファクト テーブルどうしの結合)
がある場合、STAR インデックスを追加して、次の条件を満たす必要があ
ります。
❑ どちらのファクト テーブルも、1 つ以上の共通ディメンジョン テーブ
ルを参照先とする 1 つ以上のフォーリン キー参照を持っていなければ
なりません。
❑ すべての共有フォーリン キーは、各テーブルの STAR インデックスに
おける相対順序が同一でなければなりません。
条件が満たされない場合は、違うジョイン アルゴリズムでクエリが実行さ
れ、性能が低下することがあります。詳細については、4-8 ページ「複数
のファクト テーブルに対するクエリ」を参照してください。
定期的に更新されるデータが複数のセグメントに格納される場合、ファク
ト テーブル上のインデックスをデータと同様にセグメント化します。デー
タセグメントを切り離すと、対応するインデックス セグメントを容易に削
除できます。次のインデックス セグメントをアタッチする際に、インデッ
クスを再作成する必要ありません。
詳細については、4-22 ページ「定期的にデータを更新するデータベースの
設計」、5-41 ページ「定期的に更新されるデータベースの作成」および
9-56 ページ「定期的に更新されるデータベースのメンテナンス方法」を参
照してください。
UNIQUE 属性を持つ列には B-TREE インデックスを設定し、一意性の制約
を強制する必要があります。
データベースにアウトボード テーブルが格納されている場合、アウトボー
ド テーブルを参照するテーブルの各フォーリン キーにインデックスを作
成します。
ウェアハウス データベースの物理設計
4-5
STAR インデックス
■
■
詳細テーブルに作成したインデックスを集約テーブルにも作成します。詳
細については、『IBM Red Brick Vista User’s Guide』を参照してください。
プライマリ キー以外の列を制約するクエリの場合は、以下の点を考慮しま
す。
❑ 制約される列ごとに B-TREE インデックスを作成するとクエリ性能が
高まります。ただし、その列に重複値が多い (20% 以上 ) 場合を除きま
す。( たとえば、YES、NO、NA のように、とり得る値が 3 つしかない
ような列には、B-TREE インデックスは作成しないでください。)
❑ 重複値が多い列には、TARGET インデックスの作成を検討します。
ヒント：ディメンジョン テーブルにフォーリン キーがある ( ディメンジョン テー
ブルがアウトボード テーブルを参照する ) 場合は、そのフォーリン キーに必ず BTREE インデックスまたは STAR インデックスを作成してください。
以下の例では、これらの各ケースを示します。
STAR インデックス
Red Brick Warehouse は、STAR インデックスを使用して、フォーリン キーを持つ
テーブルに対するクエリの性能を大きく向上させます。複数のフォーリン キーがあ
るテーブルには、フォーリン キーのすべてまたはその一部を自由に組み合わせた
STAR インデックスを作成できます。
STAR インデックスは、スキーマ設計上プライマリ / フォーリン キーの関係をもつ
テーブルを結合する STARjoin 技法を使用します。スター スキーマでこの技術を活
用するには、STAR インデックスを作成する必要があります。
STAR インデックスは、ファクト テーブルのプライマリ キーとして動作します。
ファクト テーブルのすべてのプライマリ キー列を対象とする STAR インデックスを
作成する場合は、以下の理由により、デフォルトプライマリ キーを削除する必要が
あります。
■
■
4-6 Administrator’s Guide
インデックスに必要なディスク領域を減らすため。
INSERT、DELETE、UPDATE、LOAD、または REORG 操作時に維持するイ
ンデックス数を減らすため。
STAR インデックス
列の順序
複数の STAR インデックスを作成した場合、どのインデックスが使用されるかは、
クエリのフォーリン キー制約の順序によって決まります。IBM Red Brick Warehouse
は、クエリの制約に最も適した列について作成された STAR インデックスを使用し
ます。
例
STAR インデックスの先頭フォーリン キー列に制約がない場合の例を示します。制
約される列について STAR インデックスを追加すると、性能が向上します。
ファクト テーブルは、次のように定義されています。
create table table1 (
pk int not null unique,
fk1 int not null,
fk2 char (3),
fk3 char(2),
fk4 char(6),
fk5 int,
col1 char(8),
col2 char(10),
constraint table1_pkc1 primary key (pk, fk1, fk2)
constraint tabled1_fkc3 foreign key (fk3)
references tabled1 (pk),
constraint tabled2_fkc2 foreign key (fk2)
references tabled2 (pk),
constraint tabled3_fkc1 foreign key (fk1)
references tabled3 (pk),
constraint tabled4_fkc4 foreign key (fk4)
references tabled4 (pk),
constraint tabled5_fkc5 foreign key (fk5)
references tabled5 (pk)
) ;
Pk、Fk1、Fk2 列についてプライマリ キー B-TREE インデックスが自動的に作成さ
れます。フォーリン キー列 Fk3、Fk2、Fk1、Fk4、Fk5 の順序で構成される STAR
インデックスを作成するには、次のように入力します。
create star index star1 on table1
(tabled1_fkc3, tabled2_fkc2, tabled3_fkc1, tabled4_fkc4,
tabled5_fkc5) ;
ウェアハウス データベースの物理設計
4-7
STAR インデックス
このインデックスは、Fk3、Fk2、Fk1 列に制約をかけるクエリの性能を大きく向上
させます。Fk4、Fk5 を制約するクエリについては、Fk4 列と Fk5 列を対象とした
別の STAR インデックスを以下のように作成します。
create star index star2 on table1 (tabled4_fkc4,
tabled5_fkc5) ;
複数のファクト テーブルに対するクエリ
複数のファクト テーブルに対するクエリがある場合、インデックス定義のフォーリ
ン キー列が同じ相対順序であれば、STAR インデックスを使用してこれらのファク
ト テーブルをジョインできます。
例
2 つのファクト テーブルのジョイン ( ファクト テーブルどうしのジョイン ) を効率
化する STAR インデックスの例を示します。この例では、各テーブルの CREATE
TABLE 文に指定された順序のフォーリン キーで構成される STAR インデックスを、
各テーブルに 1 つずつ作成したとします。つまり、STAR インデックスを構成する
フォーリン キー列の順序は一致していません。
2 つのテーブルの CREATE TABLE 文には、以下の FOREIGN KEY 句が指定されてい
ます。共有フォーリン キー参照は、太字で表記します。
create table fact1 (
...
foreign key (fk1) references dimension1 (pk),
foreign key (fk2) references dimension2 (pk),
foreign key (fk3) references dimension3 (pk),
foreign key (fk4) references dimension4 (pk))
create table fact2 (
...
foreign key (fky1) references dimensionx (pk),
foreign key (fky2) references dimension3 (pk),
foreign key (fky3) references dimension2 (pk),
foreign key (fky4) references dimension1 (pk),
foreign key (fky5) references dimensiony (pk)) ;
2 つのテーブルに共通のフォーリン キー句 ( テーブル Dimension1、Dimension2、
Dimension3 を参照する句 ) は、順序が違うことに注意してください。すでに作成し
た STAR インデックスは、CREATE TABLE 文に指定したフォーリン キーの順序に
なっているため、インデックス キーの順序は一致していません。
4-8 Administrator’s Guide
B-TREE インデックス
ファクト テーブルどうしのジョインを行うためには、これが一致していることが必
要です。Fact1 テーブルと Fact2 テーブルを結合し、Dimension1 テーブルと
Dimension2 テーブルに制約をかけるクエリを行う場合は、以下のように、キーの構
成と順序の条件を満たす STAR インデックスを Fact2 テーブルに作成します。
create star index star2 on fact2 (fky4, fky3, fky2) ;
ファクト テーブルどうしのジョインに使用する STAR インデックスの条件が満たさ
れます。
■
■
2 つのファクト テーブルが共有するすべてのフォーリン キーが、両テーブ
ルの STAR インデックスに存在しています (Fact1 テーブルについては、す
べてのフォーリン キーを対象とした STAR インデックス、Fact2 テーブル
については Star2)。
共有キーの順序が一致しています (Dimension1、Dimension2、Dimension3
の順 )。
共有ディメンジョン テーブルだけを制約するクエリの場合は、インデックス Star2
だけで十分です。
Fact2 テーブルの非共有フォーリン キー Fk5 (Dimensiony テーブルを参照 ) を制約す
るクエリを使う場合は、Fk5 列を組み入れた STAR インデックスも作成する必要が
あります。
create star index star3 on fact2 (fky4, fky3, fky5, fky2) ;
共有フォーリン キーの相対順序が同じであれば、完全に一致している必要はありま
せん。キーの順序を設定する際は、制約の頻度と選択性も考慮してください。
B-TREE インデックス
B-TREE インデックスは、テーブルの任意の列または列の集合について作成できま
す。ジョイン クエリに利用できる STAR インデックスや TARGET インデックスがな
く、B-TREE インデックスが利用できる場合は、B-TREE インデックスがネスト
ループ ジョイン (B-TREE 1-1 マッチ結合 ) されます。
Red Brick は、TARGET 結合に対して、複数の列から成る B-TREE インデックスを使
用します。TARGETjoin の詳細については、『Query Performance Guide』を参照して
ください。
ヒント：複数列で構成される B-TREE インデックスを作成する場合は、すべての列
を NOT NULL に指定する必要があります。
ウェアハウス データベースの物理設計
4-9
TARGET インデックス
例
テーブルの非プライマリ キー列が制約される例を示します。インデックスを追加す
ると性能が向上します。
Personality という名前のアウトボード テーブルを持つ Product テーブルが、次のよ
うに定義されています。
create table product (
prodkey integer not null,
product char (15),
distributor char (15),
beankey integer not null,
primary key (prodkey),
foreign key (beankey) references personality (beankey)) ;
Product テーブルのプライマリ キー列である Prodkey ( 同様に Personality テーブル
の Beankey) 列には、インデックスが自動的に作成されます。Product テーブルのほ
かの列を制約するクエリを実行する場合は、その列に B-TREE インデックスを作成
すると性能が向上します。たとえば、Distributor 列を制約するクエリを実行する場
合は、以下のように B-TREE インデックスを作成します。
create index on product (distributor) ;
TARGET インデックス
TARGET インデックスには 2 つの異なる用途があります。
■
■
クエリで制約される参照先 ( ディメンジョン ) テーブルの列に作成する
TARGET インデックス
TARGETjoin 処理を有効にするため、参照元 ( ファクト ) テーブルのフォー
リン キー列に作成する TARGET インデックス
TARGET インデックスを使用すると、選択性の低い列を制約したクエリの性能が向
上します。パフォーマンスは 2 倍に向上します。クエリが高速になり、処理に必要
なメモリが少なくなるという二重の効果が得られます。
たとえば、とり得る値が 5 つしかない列を制約するクエリは、TARGET インデック
スを使うと効率的になります。また、TARGET インデックスは、選択性の低い制約
に該当する行の件数を高速にカウントします。
TARGETjoin クエリ処理を有効にするための TARGET インデックスの使用方法の詳
細については、『Query Performance Guide』を参照してください。
4-10 Administrator’s Guide
TARGET インデックス
選択性の低い制約について
選択性の低い制約とは、1 つのテーブルに該当する行データが多数ある制約という意
味です。大きなテーブルにおいて、列のドメインが小さい ( とり得る値が少ない ) 場
合は、選択性が低くなります。たとえば、Employees テーブルの Gender 列のドメイ
ンには、male 列または female 列の 2 つの値しかありません。とり得る値が、Male
か Female のどちらかだけだからです。この列に対する制約は選択性が低くなり、非
常に多くの行が抽出される結果になります。
ドメインが大きくても、選択性が低くなる場合があります。たとえば、同じ
Employees テーブルの Age 列は、Gender 列より大きなドメインを持っていますが、
年齢に対する制約の選択性が低くなることがあります。特に、データがドメインに
均等に分布していない場合や、制約に指定した範囲にドメインのほとんどの値が含
まれる場合です。
適切なドメイン サイズの選択
特定の列に TARGET インデックスを作成する際、その列のデータを把握している場
合は、CREATE INDEX 文の DOMAIN 句に、LARGE、MEDIUM、SMALL のいずれ
かをドメイン サイズとして指定します。Red Brick サーバは、指定されたドメイン
サイズに基づいて、TARGET インデックスの格納方法、つまり「表現形式」を選択
します。
データ分布に偏りがあって、ドメイン サイズを正しく判断できない場合は、
DOMAIN 句を指定しないで TARGAT インデックスを作成できます。この TARGET
インデックスのハイブリッド表現形式によって、TARGET インデックス列の一意な
キー値 ( 列の各値 ) に対する適切な表現形式が動的に選択されます。つまり格納領
域の表現形式は、インデックス列に同じキー値が発生する回数に応じて、キー値ご
とに異なります。
このようなハイブリッド型の TARGET インデックスでは、ドメイン サイズを選択
する必要がないという利点があります。将来、列のデータがどう変わるかわからな
い場合、非常に便利です。欠点は、データの増加に伴うインデックスの拡大が制御
しにくいということです。つまり、インデックス サイズの予測がより困難になりま
す。
ウェアハウス データベースの物理設計
4-11
TARGET インデックス
列のデータが均等に分布しており、ドメインのサイズがわかっている場合は、
DOMAIN 句を使って TARGET インデックスを作成できます。次の表は各ドメイン
サイズ、それぞれのタイプがデータの格納に使用する表現形式、それぞれのタイプ
の使い分けを示します。
DOMAIN
サイズ
表現形式
使い分け
指定しない
ハイブリッド : データに
よって変化
データが予測できない場合、データ分布に偏りがある場
合、指定する DOMAIN サイズが判断できない場合。この
設定がデフォルトで、一般的に適切な選択となります。
SMALL
ビットマップ
一意な値が 100 未満、またはファクト テーブルの個々の一
意なフォーリン キー値に対するファクト テーブルの行数
が大きい (10 万以上 ) と予測される場合。性能は最高にな
るが、一意な値の数が多いと大量のディスク領域が必要と
なる。
MEDIUM
圧縮行リスト
一意な値の数が 100 から 1,000 の間、またはファクト テー
ブルの個々の一意なフォーリン キー値に対するファクト
テーブルの行数が中程度 (1,000 から 10 万の間 ) と予測され
る場合。
LARGE
非圧縮行リスト
一意な値が 1,000 以上、またはファクト テーブルの個々の
一意なフォーリン キー値に対するファクト テーブルの行
数が少ない (1,000 以下 ) と予測される場合。
一意な値の数を予測する場合は、ファクト テーブルの一意な値の数に注目します。
この数は、ディメンジョン テーブルの一意な値の数よりも少ない場合があります。
たとえば、Day テーブルには 10 年分の日数、つまり 3650 の一意な値が格納されて
いて、データベース ( つまりファクト テーブル ) には 1 年分の日数、つまり 365 の
一意な値しか格納されていないとします。この場合は、Day テーブルを参照する
フォーリン キーを対象とする TARGETindex には、DOMAIN MEDIUM TARGETindex
が最適となります。
CREATE INDEX 文の DOMAIN 句の詳細については、
『SQL Reference Guide』を参照
してください。
4-12 Administrator’s Guide
ローカルにセグメント化されるインデックス
例
Customer テーブルには 10,000,000 行のデータがあり、Cust_key、Last_name、
First_name、Street、Cit、State、Zip_code、Region の各列から構成されているとし
ます。Region の値は 1 ∼ 250 の範囲にあり、それぞれ、各営業部員の担当地域を示
します。Region 列を制約するクエリの性能を向上させる TARGET インデックスは、
以下のように作成します。
create target index customer_region_idx on customer (region)
domain size medium;
ローカルにセグメント化されるインデックス
ローカル インデックスは、インデックスの先頭列がテーブルのセグメント化の基準
となる列でない場合も、テーブル データと同じようにセグメント化される TARGET
インデックスまたは B-TREE インデックスです。ローカル インデックスは、イン
デックスを再編成する必要がないので、有効期限が過ぎたデータを削除し、最新
データを定期的に追加するデータベースに最適です。詳細については、4-24 ページ
「ローカル インデックスの特性」、5-41 ページ「定期的に更新されるデータベースの
作成」および 9-56 ページ「定期的に更新されるデータベースのメンテナンス方法」
を参照してください。
ローカル インデックスは、TARGETjoin のパフォーマンスも向上させます。ただし、
ローカル インデックスをほかのクエリ処理で使用する際には、調整が必要です。詳
細については、『Query Performance Guide』を参照してください。
インデックスがない場合
結合パスに有効なインデックスがないテーブルを等価結合すると、ハイブリッド
ハッシュ結合のアルゴリズムによって結合が実行されます。ハッシュ ジョインは、
サイズが極端に異なるテーブルをジョインするのに非常に効果的です。小さい方の
テーブルをメモリに収めることができるからです。
等価結合以外のジョインで、インデックスが利用できない場合は、クロス ジョイン
が実行されます。クロス結合は、結合する 2 つのテーブルの直積を算出するもの
で、SET CROSS JOIN ON コマンドによって有効にしておく必要があります。SET
CROSS JOIN コマンドの詳細については、『SQL Reference Guide』を参照してくださ
い。
ウェアハウス データベースの物理設計 4-13
TARGETjoin 処理の管理方法
TARGETjoin 処理の管理方法
ファクト テーブルのフォーリン キーを対象とする TARGET インデックス ( 複数の
列からなるフォーリン キーに対する (B-TREE インデックス ) を作成して
TARGETjoin 処理を有効にする場合は、作成したインデックスをメンテナンスする
ための管理コストを考慮する必要があります。データベースが静的な場合、つまり
インクリメンタル INSERT、UPDATE、DELETE、LOAD DATA 操作で変更されない
場合は、インデックスのコストは、インデックスに必要なディスク領域となりま
す。ディスク領域の所要量は、ファクト テーブルの行数に比例します。たとえば、
1 億行のテーブルのインデックスは 400 億行のテーブルよりも小さなインデックス
を持つことになります。インデックスのサイズを見積るには、dbsize ツールを使用
します。
大規模なディメンジョン テーブル
スキーマに大規模なディメンジョン テーブルが存在する場合は、TARGETjoin 処理
に対して以下の点を考慮します。大規模ディメンジョン テーブルの典型的な例は顧
客テーブルです。大規模なディメンジョン テーブルとは、行数の多い ( たとえば 1
万行以上の ) ディメンジョン テーブルのことです。
TARGETjoin 処理を使用してファクト テーブルに大きなディメンジョン テーブルを
結合させるクエリには、次の 2 つの問題点があります。
■
■
フォーリン キーを対象とする TARGET インデックスおよび B-TREE イン
デックスが大量のディスク領域を使用することがあります。
大規模なディメンジョン テーブルに対する、選択性が低い制約を使用する
クエリの性能が低下することがあります。
１ つめの問題は、単に資源の問題です。インデックスの作成に必要な領域と時間が
あれば、これは問題ではありません。インデックスのサイズおよび作成の所要時間
は、スキーマごとに異なります。インデックスのサイズを見積るには、dbsize ツー
ルを使用します。
2 つめの問題は、大規模なディメンジョン テーブルを、それに対する大量の該当行
がある ( 選択性の低い ) クエリを使ったファクト テーブルにジョインする場合に発
生します。たとえば、100 万行を持つ顧客テーブルがあるとします。そして、男性
顧客に関する情報が必要で、顧客の 75％ が男性だとします。すると、ディメン
ジョン テーブル中の 75 万行がこの結合に該当することを意味します。この場合は、
TARGETjoin 処理は効率的に実行されません ( 末尾キーの 1 つが大規模なディメン
ジョン テーブルに対応するフォーリン キーである STAR インデックスが存在すれ
ば、STARjoin 処理は、大規模なディメンジョン テーブルに対する選択性の低い制
約にも効率的に実行されます )。
4-14 Administrator’s Guide
TARGETjoin 処理の管理方法
ただし、顧客 (Customer) テーブルに対するクエリ制約が少数の該当行を抽出する場
合は、このクエリは TARGETjoin 処理を使って効率的に実行されます。たとえば、
クエリに次の制約があるとします。
where customer.customer_last_name like 'X%'
X で始まる姓を持つ顧客は 1 人だけであるため、このクエリは TARGETjoin 処理を
使用して正しく実行されます。
複数列フォーリン キー
ファクト テーブルに 1 つまたは複数の列からなるフォーリン キーを持つスキーマが
存在し、TARGETjoin 処理を使ってファクト テーブルを、複数の列からなるキーが
参照するディメンジョン テーブルに結合する場合は、複数の列からなるフォーリン
キーのすべての列の結合に対して 1 つの B-TREE インデックスを作成します。
たとえば、Aroma データベースの Sales テーブルには、Product テーブルを参照する
classkey および prodkey の 2 つの列からなるフォーリン キーがあります。Sales テー
ブルと Product テーブルの間の TARGETjoin 処理を可能にするには、次の CREATE
INDEX 文を使って、Sales テーブルに B-TREE インデックスを作成しなければなり
ません。
create index sales_classkey_prodkey_btree_idx
on sales (classkey, prodkey);
CREATE INDEX コマンドの詳細については、
『SQL Reference Guide』を参照してく
ださい。
ヒント：一般的に、複数の列からなるフォーリン キーを利用する TARGETjoin ク
エリの性能は、1 つの列からなるフォーリン キーを利用する場合ほど高くはありま
せん。性能を最大化するためには、可能なかぎり 1 つの列からなるフォーリン キー
を使ってスキーマを設計します。
ウェアハウス データベースの物理設計 4-15
セグメントの設計
セグメントの設計
データベース設計を計画し、ユーザ テーブルおよびシステム テーブルをすべて
ロードしてインデックスを作成するのに要するディスク容量を見積ってから、名前
付きセグメントとデフォルト セグメントのどちらを使用するかを決定します。名前
付きセグメントを使用する場合は、格納領域サイズ、データおよびインデックスの
セグメント化の方法を設計する必要があります。
デフォルト セグメントと名前付きセグメントの使い
分け
大規模なデータ ウェアハウスの場合、名前付きセグメントを使用することをお勧め
します。名前付きセグメントを使用すると、並列クエリ実行その他の IBM Red Brick
Warehouse の高度な機能を活用するためのデータ配置の場所、およびそれに必要な
データを制御できます。名前付きセグメントの利点の詳細については、2-7 ページ
「格納領域のセグメント化」を参照してください。
デフォルト セグメントは、小規模なデータベースやテスト データーベースの場合
に有効です。エンドユーザやアプリケーション ツールは、半永久的なテーブルに格
納したクエリ結果の分析を頻繁に行います。Red Brick によって自動的に作成される
これらのテーブルは、デフォルト セグメント内に置くと便利です。
デフォルト セグメントは、明示的なセグメント割り当てを含まない CREATE
TABLE 文が発行されると作成されます。デフォルト セグメントのデフォルト特性
は、rbw.config ファイルのパラメータによって定義されます。デフォルト セグメン
トの作成に、明示的な管理者による処理は必要ありません。デフォルト セグメント
は、データベース ディレクトリまたはデフォルト ディレクトリ (rbw.config ファイ
ルに指定した場合 ) に格納されます。デフォルト セグメントを修正するには、
ALTER SEGMENT コマンドを使用します。
警告 : 複数データベースに対するオフライン ロードが同時に実行される場合は、
すべてのデフォルト セグメントを 1 つのデフォルト ディレクトリに格納することは
避けてください。
名前付きセグメントは CREATE SEGMENT 文によって明示的に作成し、名前付きセ
グメントに割り当てるファイルは、CREATE SEGMENT コマンドと ALTER
SEGMENT コマンドで管理します。名前付きセグメントのファイルは、セグメント
の作成または変更時に指定したロケーションに格納されます。
4-16 Administrator’s Guide
デフォルト セグメントと名前付きセグメントの使い分け
テーブルとインデックスをデフォルト セグメントに格納しておくと、データベース
の作成や管理が簡単になりますが、名前付きセグメントのような柔軟性はありませ
ん。特に以下のような場合は、名前付きセグメントを使用してください。
■
■
■
1 つのユーザ テーブル、またはそのテーブルに自動的に作成されるイン
デックスとユーザ作成のインデックスの予想サイズが 2GB を超える場合
は、そのテーブルを名前付きセグメントに格納し、データベース ファイル
を複数のファイル システムに分散させなければなりません。
デフォルト セグメントは、rbw.config ファイルのパラメータ
DEFAULT_SEGMENT_SIZE に指定すれば、2GB 以上に設定できます。構
成ファイルのパラメータの詳細については、付録 B 「構成ファイル」を参
照してください。
データベース全体の予想サイズが 4GB を超える場合は、一部のテーブルと
インデックスを名前付きセグメントに格納する必要があります。
1 つのテーブル、そのテーブルに関連したインデックス、データベース全
体の予想サイズのいずれかが、データベース ディレクトリがあるファイル
システムで利用できる容量を超える場合は、ほかのファイル システムにあ
る PSU から構成される名前付きセグメントに、一部のテーブルまたはイン
デックスを配置しなければなりません。
データベースの拡大に伴い、複数のセグメントにデータを分散させる必要が予想さ
れる場合は、名前付きセグメントを使用した方が良いでしょう。
ただし、テーブルまたはインデックスをデフォルト セグメントに作成した後で、名
前付きセグメントを追加することは可能です。セグメントは、セグメント化の基準
列を指定 (ALTER TABLE 文 ) してから追加します。デフォルト セグメントを指定し
た後、テーブルやインデックスが拡大したためにデフォルト セグメントに格納しき
れなくなった場合は、ALTER SEGMENT 文により、1 つの PSU で構成されていたデ
フォルト セグメントを別のロケーションに移動するか、そのセグメントに新規に
PSU を追加することができます。詳細な手順については、9-42 ページ「セグメント
の変更」を参照してください。
デフォルト セグメントと名前付きセグメントの詳細については、5-12 ページ「セグ
メントの作成」と 9-42 ページ「セグメントの変更」を参照してください。
ウェアハウス データベースの物理設計 4-17
名前付きセグメントの使用方法
名前付きセグメントの使用方法
名前付きセグメントを使用する場合は、以下の点に注意してください。
■
■
■
■
■
■
■
4-18 Administrator’s Guide
名前付きセグメントには、1 つのテーブルまたはインデックスしか格納で
きません ( または何も格納しません )。
1 つのセグメントに割り当てられる PSU ( ファイル ) の最大数は 250 です。
少数の大きなファイルを割り当てるか、多数の小さなファイルを割り当て
るかを決定します。大きなファイルを割り当てる場合は、ディスク パー
ティション全体が必要になることがあります。小さなファイルにすると、
複数のファイル システムにディスク領域を少しずつ分散させ、1 つのテー
ブルまたはインデックスで複数のシステムを効率的に使用することができ
ます。管理とメンテナンスには、多数の小さなファイルよりも少数の大き
なファイルの方が簡単になります。
ファイルを拡張させる方法も決定しなければなりません。管理者は、PSU
の初期サイズ ( セグメントの作成時に予約されるサイズ )、PSU の許容最
大サイズ、拡張サイズ ( 拡張時の増分の単位 ) を、PSU ごとに指定するこ
とができます。PSU の初期サイズを大きくすると、初期に予約される領域
が大きくなります。初期サイズが小さいと、フラグメンテーションが生じ
る可能性が高くなります。
IBM Red Brick Warehouse は、8KB ブロック単位のディスク スペースを使用
します。CREATE SEGMENT 文に最大ファイル サイズを指定すると、割り
当てられるスペースは、8KB の倍数に切り上げられます。セグメントの先
頭ファイルの最小サイズは 2 ブロック、つまり 16KB になります。
システムの構成上、可能な場合は、複数のディスク ドライブと複数の入出
力バスにセグメント ファイルを分散させ、アクセス速度を向上させてくだ
さい。
テーブルやインデックスが複数のセグメントに格納されている場合、ロー
ドまたはリストアするセグメントをオフラインにし、ほかのセグメントに
アクセスできるようにすることができます。この機能を使用する場合は、
同時クエリ アクセスやセグメントのオフライン操作を念頭に置いて、デー
タのセグメント化の方法および PSU の場所とサイズを慎重に決定する必要
があります。
クエリ処理の並列度は、クエリで抽出するデータを格納する PSU の数に
よって制限されます。たとえば、テーブルに PSU が 1 つしかない場合、そ
のテーブルのリレーション スキャンを並列処理することは不可能です。つ
まり、PSU を設定する際は、どの程度の並列度が必要かを考慮する必要が
あります。PSU および並列処理の詳細については、『Query Performance
Guide』を参照してください。
名前付きセグメントの使用方法
セグメント化の方法の決定
図 4-1 は、行およびインデックス データを複数のセグメントに格納する方法とその
使い分けを示します。
図 4-1 セグメント指定と SQL キーワードの使い分け
セグメント
の内容
行データ
セグメント化の基準
CREATE INDEX
のキーワード
セグメント化の基準
列のデータ値
SEGMENT BY
VALUES OF
データが格納されるセ
グメントを把握する必
要がある場合
ハッシュ
SEGMENT BY
HASH
セグメント間でデータ
を均等に分散させたい
場合
なし
セグメント間でイン
デックス エントリを均
等に分散させたい場合
STAR インデックス
のデータを格納して
いる参照先テーブル
の行番号
SEGMENT BY
REFERENCES OF
インデックス エントリ
が格納されるセグメン
トを把握する必要があ
り、参照先テーブルが
セグメント化されてい
ない場合
STAR インデックス
のデータを格納して
いるセグメント化さ
れた参照先テーブル
の行 ID
SEGMENT LIKE
REFERENCED
TABLE
インデックス エントリ
が格納されるセグメン
トを把握する必要があ
り、参照先テーブルが
セグメント化されてい
る場合
論理的にデータと同
じ値
( 行 ID を使用 )
SEGMENT LIKE
DATA
定期的に更新するデー
タベースの保守を容易
にする場合
STAR
セグメント全体で均
インデックス 等に (Red Brick
Warehouse によって
範囲が計算される )
使い分け
ウェアハウス データベースの物理設計 4-19
名前付きセグメントの使用方法
図 4-1 セグメント指定と SQL キーワードの使い分け
セグメント
の内容
セグメント化の基準
TARGET
インデックス列の値
インデックス
データと同じ値
B-TREE
最初の ( 先頭 ) イン
インデックス デックス列の値
データと同じ値
4-20 Administrator’s Guide
CREATE INDEX
のキーワード
使い分け
SEGMENT BY
VALUES OF
インデックス列がテー
ブルのセグメント化の
基準となる列でない場
合
SEGMENT LIKE
DATA
先頭列がテーブルのセ
グメント化の基準とな
る列である場合
SEGMENT
LOCAL
定期的に更新するデー
タベースの保守を容易
にするか、
TARGETjoin 処理を向
上させる場合
SEGMENT BY
VALUES OF
先頭列がテーブルのセ
グメント化の基準とな
る列でない場合
SEGMENT LIKE
DATA
先頭列がテーブルのセ
グメント化の基準とな
る列である場合
SEGMENT
LOCAL
定期的に更新するデー
タベースの保守を容易
にするか、
TARGETjoin 処理を向
上させる場合
名前付きセグメントの使用方法
PSU のサイズと拡張
名前付きセグメントの PSU は、以下のサイズ パラメータを設定できます。
■
■
■
初期サイズ : ファイルの初期割り当て領域のサイズを指定します。
セグメントの作成時に初期サイズを設定しない場合、デフォルトで 16KB
が設定されます。
最大サイズ : ファイルを拡張する場合の最大サイズを指定します。
Red Brick Administrator ツールでのセグメントの作成時に最大サイズを設定
しない場合、デフォルトで 16KB が設定されます。RISQL でのセグメント
の作成時にキーワード値 MAXSIZE を指定する必要があります。
拡張サイズ : ファイルを拡張する場合の増分の単位を指定します。
上記のサイズを正しく設定しておくと、データやディスク領域の増大に応じて拡張
できるセグメントを作成することができます。
デフォルト セグメントの PSU には次の特性があります。
■
■
■
■
デフォルトの初期サイズは 16KB です。
各セグメントの PSU の数は、パラメータ DEFAULT_SEGMENT_SIZE の値
を 2GB (PSU の初期最大サイズ ) で割ることによって決定されます。パラ
メータ DEFAULT_SEGMENT_SIZE は、デフォルト テーブルまたはイン
デックスの格納量を指定するものです。
各 PSU のデフォルトの最大サイズは 2GB です。セグメントの最後の PSU
のサイズは、DEFAULT_SEGMENT_SIZE modulo 2GB の値です。
DEFAULT_SEGMENT_SIZE が設定されていないか、または 1 つの PSU サ
イズよりも小さい値が設定されている場合、PSU サイズはデフォルトで
2GB になります。
拡張サイズはパラメータ DEFAULT_PSU_EXTENDSIZE によって指定され
ます。デフォルトの拡張サイズは 16KB です。
たとえば、DEFAULT_SEGMENT_SIZE が 5GB に設定されていて、
DEFAULT_PSU_EXTENDSIZE が 512KB に設定されている場合は、次の表に示すよ
うに 3 つの PSU が作成されます。
PSU
初期サイズ
拡張サイズ
最大サイズ
PSU 1
16KB
512KB
2GB
PSU 2
16KB
512KB
2GB
PSU 3
16KB
512KB
1GB
ウェアハウス データベースの物理設計 4-21
定期的にデータを更新するデータベースの設計
定期的にデータを更新するデータベースの設計
データ ウェアハウスの一般的な使い方は、通常は日付などの期間ディメンジョンに
よってファクト テーブルがセグメント化される場所に、定期的に更新するデータを
格納することです。定期的に更新するデータであることが、名前付きセグメントを
使用する主な理由でもあります。たとえば、オンラインに 2 年分のデータを保存す
る必要があるとします。これらのデータを保持するためにファクト テーブルを作成
し、このテーブルを週単位にセグメント化し、104 個のセグメントを作成します。
この例における定期的に更新するデータベースでは、データベース内の最新の 104
週のみを保存するために週ごとに以下のタスクを実行します。
■
■
■
■
■
最も古い週単位のデータとそのインデックスを切り離します。
データとインデックスに対して新規にセグメントを作成するか、または切
り離したセグメントを再利用します。
次週の範囲のあるデータ セグメントをファクト テーブルの最後にアタッ
チします。
対応するインデックス セグメントをアタッチします。
新しくアタッチしたセグメントにデータをロードします。
定期的に更新するデータベースをセットアップする際は、次の操作を行ってこれら
の週次タスクの効率化を図ってください。
■
■
■
ファクト テーブル上のインデックスをデータと同様にセグメント化しま
す。
ローカル インデックスを定義します。
テーブルの最後に小さな空のセグメントを置きます。
ファクト テーブルと同様のインデックスのセグメン
ト化
ファクト テーブル上のインデックスをデータと同様にセグメント化して、データ
セグメントを切り離す際に対応するインデックス セグメントを簡単に削除できるよ
うにします。以下のような場合では、データと同じ方法でインデックスをセグメン
ト化できます。
■
4-22 Administrator’s Guide
STAR インデックスの先頭列がファクト テーブルのセグメント化の基準と
なる列である場合、SEGMENT LIKE DATA 句を使ってインデックスを作成
します。
ファクト テーブルと同様のインデックスのセグメント化
■
B-TREE インデックスまたは TARGET インデックスの先頭列がファクト
テーブルのセグメント化の基準となる列である場合、以下に示すいずれか
の句を使ってインデックスを作成します。
■ SEGMENT LIKE DATA
この句は、ローカル インデックスを使用できない場合に使用します。
たとえば、一意の列、あるいはインデックスのセグメント化の方法を
テーブルとは別に変更したい場合にこの句を使用します。
■
■
SEGMENT LOCAL
ローカル インデックス列がテーブルのセグメント化の基準となる列で
ある場合、ローカル インデックスに対しては定期的に更新するデータ
の保守が容易になり、ローカルでないインデックスに対してはパ
フォーマンスが向上します。ローカル インデックスの特性の詳細は、
4-24 ページを参照してください。ローカルでないインデックスを使用
した場合のパフォーマンスの向上については、『Query Performance
Guide』を参照してください。
B-TREE インデックスまたは TARGET インデックスの先頭列がファクト
テーブルのセグメント化の基準になる列と異なる場合、ローカル インデッ
クスを作成します。
SEGMENT LOCAL 句を使用する場合、ファクト テーブルをセグメント化
する列は B-TREE インデックスの先頭列である必要はありません。同様
に、SEGMENT LOCAL 句を使用する場合、セグメント化の基準となる列
は TARGET インデックスのインデックス キーである必要はありません。
ヒント：TARGET ジョインおよび TARGET スキャン操作を向上させるために、セ
グメント化の基準となる列がインデックスの先頭列である場合も、常にローカル イ
ンデックスを作成することを推奨します。
SEGMENT LIKE DATA 句を使って STAR インデックスを作成する場合、事前にイン
デックスの先頭列のディメンジョン テーブルにデータをロードする必要があるので
注意してください。実際の CREATE INDEX 文の例は、5-41 ページ「定期的に更新
されるデータベースの作成」を参照してください。セグメントの切り離しおよびア
タッチに関して考慮すべき点については、9-56 ページ「定期的に更新されるデータ
ベースのメンテナンス方法」を参照してください。
ウェアハウス データベースの物理設計 4-23
ローカル インデックスの特性
ローカル インデックスの特性
ローカル インデックスには次の特性があるため、ローカル インデックスを使用す
ると、定期的に更新するデータを容易に保守できます。
■
■
■
テーブル セグメントを切り離す、または削除する場合、ALTER SEGMENT
文に OVERRIDE FULLINDEXCHECK 句を指定しなければローカル イン
デックス セグメントのみが削除されます。
テーブル セグメントの範囲を変更または移動する場合、ALTER SEGMENT
文を別途実行しなければ、ローカル インデックスのセグメント範囲が自動
的に変更または移動されます。
テーブル セグメントを切り離す、またはアタッチする場合は、対応する
ローカル インデックスのセグメントに対しても同様の処理をする必要があ
ります。それ以外の場合、テーブルに対して SELECT 文、INSERT 文、ま
たは DELETE 文を実行しようとすると、次のようなエラーが発生します。
** ERROR ** (1204) The segmentation of local index
PERKEY_SALES_LOCAL_TIX does not match table segmentation.
■
ローカル インデックスを使用すると、TARGET ジョインおよび TARGET
スキャン操作のパフォーマンスが向上します。ただし、チューニング パラ
メータを設定しておかないと、ローカル インデックスはほかのクエリ処理
のパフォーマンスに影響する場合があります。詳細については、『Query
Performance Guide』を参照してください。
CREATE INDEX 文の例は、5-53 ページ「ローカル TARGET インデックスの作成」
を参照してください。セグメントの切り離しおよびアタッチ方法の詳細について
は、9-57 ページ「データ セグメントおよびインデックス セグメントのロールオフ
と再使用」を参照してください。
4-24 Administrator’s Guide
テーブルおよび各インデックスの末尾の小さなセグメント
テーブルおよび各インデックスの末尾の小さなセグメ
ント
ATTACH SEGMENT 操作は、既存のセグメントの範囲に、新しいセグメント範囲を
重ねます。Red Brick サーバにより、重ね合わせる範囲のあるこのセグメントがス
キャンされ、新しいセグメントに含まれる行が存在しないことが確認されます。
ATTACH SEGMENT 操作のパフォーマンスを向上させるには、新規セグメントをア
タッチするテーブルの末尾に空のセグメントを置きます。この空のセグメントは
16KB ( 最小サイズ ) にし、データがロードされないようにします。実際の CREATE
SEGMENT および CREATE TABLE 文の例は、5-41 ページ「定期的に更新される
データベースの作成」を参照してください。データ セグメントを切り離し、新規セ
グメントをアタッチする ALTER SEGMENT 文の例は、9-56 ページ「定期的に更新
されるデータベースのメンテナンス方法」を参照してください。
ディスク領域の構成
新規データベースを作成する前に、データベースおよびその内容に必要なディスク
容量を正確に予測してください。それによってデータベースの内容全体をデフォル
ト セグメントに配置するか、テーブルやインデックスの一部または全部を名前付き
セグメントに格納するかを決めます。必要なディスク容量を判定するには、永続的
なユーザ テーブルと一時的なユーザ テーブル、自動作成されるインデックスと追
加するインデックス、システム テーブルの所要量の合計を見積る必要があります。
また、テーブルの大きさの変化も予測する必要があります。
さらに、以下の点を把握しておかなければなりません。
■
■
■
■
■
■
データベースに作成するユーザ テーブル
データベースに存在する一時的なユーザ テーブルの最大数
ユーザ テーブルと一時的なユーザ テーブルごとの、初期にロードまたは
挿入する行数
すべてのテーブルについて、各列のデータ型とサイズ。VARCHAR 列につ
いては、列の最大サイズ、および格納されるデータの平均的なサイズを把
握する必要があります。
すべてのテーブルについて、インデックスを付ける列とインデックスのタ
イプ。自動的に作成されるインデックス ( プライマリ キー B-TREE イン
デックス ) とユーザ作成のインデックス ( 追加する B-TREE インデックス、
STAR インデックス、TARGET インデックス ) について見積ります。
各テーブルの拡張率、最大行数など、ディスク使用領域の変化
スキーマの設計に基づき、以下の手順に従ってディスク領域を適切に構成してくだ
さい。各手順は、この後の節で説明します。
ウェアハウス データベースの物理設計 4-25
ユーザ テーブルのサイズの見積り
1.
2.
3.
4.
5.
dbsize ユーティリティを使い、データベースに作成する各ユーザ テーブル
のディスク所要量を見積ります。
dbsize ユーティリティを使い、データベースに作成する自動作成インデッ
クスとユーザ作成インデックスのディスク所要量を見積ります。
dbsize ユーティリティを使い、データベースのシステム テーブルのサイズ
を見積ります。
セグメント化の方法を決定し、必要に応じて、複数のディスクにデータを
分散します。詳細は、4-16 ページ「セグメントの設計」および 4-22 ペー
ジ「定期的にデータを更新するデータベースの設計」を参照してくださ
い。
行数が増えると予想されるユーザ テーブルについては、4-58 ページで説明
するテーブル データの増加に関する節を参照してください。
dbsize ユーティリティは、redbrick_dir¥util ディレクトリの service ディレクトリに
格納されています。このユーティリティの詳細は、service ディレクトリにある
README ファイルを参照してください。
ユーザ テーブルのサイズの見積り
ユーザ テーブルのサイズを見積るには、以下の事項を知っておく必要があります。
■
■
■
■
列数
列のデータ型
可変長 (VARCHAR) 列のフィル ファクタ
予想される各テーブルの最大行数
この情報に基づいて dbsize ユーティリティを使用すれば、各行の長さのバイト数
と、すべての行を格納するのに必要なバイト数を知ることができます。
VARCHAR 列フィル ファクタを使用して効率を最適化する方法の詳細については、
5-24 ページ「VARCHAR 列フィル ファクタの設定」を参照してください。
インスタンス当たりのサイズを予測し、データベースに発生するテーブル当たりの
予想最大インスタンス数と予想サイズを掛け合わせます。この積が、テンポラリ
テーブルの予想サイズになります。詳細については、4-41 ページ「一時領域の所要
量の見積もり」を参照してください。
4-26 Administrator’s Guide
インデックス サイズの見積り
例
次のテーブルのサイズを見積ります。
create table fact_table(
prodkey integer not null,
mktkey integer not null,
description character(65),
dollars decimal (12,2),
primary key (mktkey, prodkey),
foreign key (mktkey) references market (mktkey),
foreign key (prodkey) references product (prodkey));
テーブルの行数を約 53,000,000 とします。
1.
2.
3.
4.
5.
dbsize ユーティリティを実行します。
ユーザ テーブルのサイズを見積るオプションを選択します。
dbsize を使って行サイズを見積る場合、次の 2 つの質問に対して以下のよ
うに答えます。
a. テーブル サイズの見積り方法例を確認するかどうかという質問に対し
ては、n と答えます。
b. dbsize による行の見積もりを、指定したデータ型のサイズを基に行う
かという質問に対しては、y と答えます。
プロンプトに対し、列数、列のデータ型、10 進数データ型の精度、テーブ
ルの最大行数を入力します。
上記の CREATE TABLE 文に基づき、テーブルのサイズが 4,156,872KB と見
積られます。
インデックス サイズの見積り
データベースのインデックスに必要な領域を見積るには、以下の事項を知っておく
必要があります。
■
■
■
STAR インデックス ノードと B-TREE インデックス ノードの領域の使用率
を決めるフィル ファクタ
データベースの各テーブルに設定されたインデックスの数
インデックスのタイプ (STAR、B-TREE、TARGET)
ウェアハウス データベースの物理設計 4-27
インデックス サイズの見積り
インデックスのフィル ファクタ
インデックスには、フィル ファクタが設定されています。インデックスのフィル
ファクタは、インデックス ノードの新規作成時にノードを充填する割合を指定する
ものです。新規ノードが作成されるのは、以下の 3 つの場合です。
■
■
■
初期ロード中に、プライマリ キー インデックスが作成される時
CREATE INDEX 文でインデックスを作成した時
インクリメンタル ロード中に、あるノードがフィル ファクタに達したた
め新規ノードが作成される時
作成されたインデックス ノードが、フィル ファクタで指定したレベルまで充填さ
れた後、既存ノードにエントリを挿入するロード操作を実行し、既存ノードが
100% まで充填されるとノードは分割され、充填率が 50% の 2 つの新規ノードにな
ります。このため、フィル ファクタで指定した値より充填率が高くなるノードもあ
ります。その後は、新規ノードが 100% まで充填されると再び分割されます。
重要 : TMU のオプティマイズ モード以外では、フィル ファクタは無効です。
フィル ファクタの目的は、各ノードに予備の領域を取っておくことです。この予備
領域は、既存ノードにエントリを挿入するインクリメンタル ロード操作に使用され
ます。ロード操作を完了させるのに十分な領域が既存ノードにあれば、時間のかか
るノードの分割は不要になります。ノードの分割を無くすことはできなくても、
フィル ファクタによってその頻度を減らし、インクリメンタル ロードの性能を上
げることが可能です。
インデックス ノードにエントリの予備領域を多くすると、次のようなデメリットも
あります。
■
■
4-28 Administrator’s Guide
各インデックス ノードに未使用領域が確保され、インデックスのサイズが
大きくなります。
充填率が低く階層が深いノードは、充填率が高く階層が浅いノードよりも
検索に時間がかかります。
インデックス サイズの見積り
インデックス サイズの見積りにおけるフィル ファクタ
インデックスのサイズを見積る際は、いくつかの状況を想定し、インデックスの初
期サイズとその後のサイズの変化の様子を把握します。
インデックスのサイズは、挿入するデータとその順番に依存するため、インデック
スの最小サイズと最大サイズを正確に算出することは不可能です。しかし、フィル
ファクタを変えながら何度か算出すれば、テーブルやインデックスの拡大に伴う格
納領域の所要量を大まかに把握することができます。
一般的なインデックス ( 初期作成後の挿入と削除の量が平均的なインデックス ) の
充填率は、66% ∼ 75% が目安です。以下の指針に従って STAR インデックスと BTREE インデックスのフィル ファクタを設定し、インデックスの現実的なサイズを
推定してください。
■
■
■
■
■
フィル ファクタは、新規インデックスをオプティマイズ モードで作成し
た ( オプティマイズ モードで CREATE INDEX 文または LOAD/REORG 文を
実行した ) 場合に、インデックスに使用される領域を示すものです。
フィル ファクタを 100% に設定すると、インデックスの最小サイズがわか
ります。
フィル ファクタを 75% に設定すると、平均的な更新 ( インデックスの初期
作成後 ) が発生した後のインデックス サイズの下限が推定できます。
フィル ファクタを 66% に設定すると、平均的な更新 ( インデックスの初期
作成後 ) が発生した後のインデックス サイズの上限が推定できます。
フィル ファクタを 50% に設定すると、インデックスに必要な実用的な最
大領域がわかります。50% 未満のフィル ファクタでインデックスを作成し
た場合は、そのフィル ファクタを使って実用的な最大スペースを推定する
必要があります。
ウェアハウス データベースの物理設計 4-29
インデックス サイズの見積り
インデックス フィル ファクタの設定では、以下を考慮してください。
■
■
インクリメンタル ロードを実行せず、更新するたびにデータベース全体を
再ロードする場合は、高いフィル ファクタを指定します。インデックス
ノードに挿入するエントリの予備領域が不要だからです。
初期にロードするデータが、予想されるデータ総量の一部にすぎない場合
は、その比率に対応したフィル ファクタを指定します。後からロードする
データ エントリのために、予備領域をインデックス ノードに残しておく
ためです。
たとえば、初期ロードで 95% のデータをロードし、その後に追加するデータが比較
的少ない場合は、フィル ファクタを 95% に設定します。初期ロードのデータが 5%
の場合は、フィル ファクタを 5% に設定します。
重要 : 自動的に作成されるインデックスのフィル ファクタは rbw.config ファイル
に設定し、ユーザが作成するインデックスについては CREATE INDEX 文で設定し
ます。インデックスのフィル ファクタを変更するには、ALTER INDEX 文を使用し
ます。
インデックス フィル ファクタの設定と変更、および特定のインデックスに対する
フィル ファクタの設定については、5-36 ページ「インデックス フィル ファクタの
設定」を参照してください。
STAR インデックス
STAR インデックスのサイズは、インデックスの参照先テーブルに予想される最大
行数に依存します。この行数は、テーブルの MAXROWS PER SEGMENT と
MAXSEGMENTS の値となります。MAXROWS PER SEGMENT は、STAR インデッ
クスに関連した参照先 ( ディメンジョン ) テーブルの作成時に指定しなければなり
ません。そうしないと、CREATE STAR INDEX 文がエラーになります。テーブルの
作成時に最大行数の正確な予測と明示的な指定をしておけば、ディメンジョン テー
ブルが拡大した場合に STAR インデックスを再編成する時など、サイズの見積りや
保守作業が簡単になります。
4-30 Administrator’s Guide
インデックス サイズの見積り
dbsize ユーティリティを使用して STAR インデックスのサイズを見積る際は、次の
情報が必要になります。
■
■
■
STAR インデックスに関連する各フォーリン キー列について見積られる参
照先 ( ディメンジョン ) テーブル内の最大行数と最大セグメント数
(MAXROWS PER SEGMENT に MAXSEGMENTS を掛けたもの )
参照元 ( ファクト ) テーブルに格納される最大行数
STAR インデックスのフィル ファクタ
B-TREE インデックス
dbsize ユーティリティを使用して B-TREE インデックスのサイズを見積る際は、次
の情報が必要になります。
■
■
■
■
インデックスを構成する列の数
インデックスを構成する列のデータ型
インデックスのフィル ファクタ
インデックスを付けるテーブルに格納される最大行数
TARGET インデックス
dbsize ユーティリティを使用して TARGET インデックスのサイズを見積る際は、次
の情報が必要になります。
■
■
■
■
■
インデックスを付ける列の予想ドメイン サイズ ( とり得る値の数 )
TARGET インデックス列のデータ型
テーブルの予想行数
テーブルのセグメント数
列のドメイン : SMALL、MEDIUM、または LARGE
ドメインを指定しないと、dbsize は、最小インデックスとなるドメインを
計算し、使用するドメインを示します。
ウェアハウス データベースの物理設計 4-31
インデックス サイズの見積り
テーブルがセグメント化されていると、以下の情報もまた確認されます。
■
■
インデックスがローカル インデックスかどうか
列がテーブルのセグメント化の基準となる列であるかどうか
TARGET インデックスに対して dbsize を使用する際は、以下のガイドラインに従っ
てください。
■
■
■
TARGET インデックスがテーブルのセグメント化の基準となる列にある場
合、セグメント数で割ったドメイン サイズを dbsize に入力する必要があ
ります。
セグメント化された TARGET インデックスの場合、インデックス全体のサ
イズではなく各セグメントのサイズを見積ることをお勧めします。
ローカル TARGET インデックスの場合、各セグメントには通常すべての
キーが格納されています。したがって、dbsize にはフル ドメイン サイズを
入力してください。
例 : ローカル TARGET インデックスのサイズの算出
ローカル TARGET インデックスのサイズを見積る例を示します。Sales テーブルは
約 70,000 行を格納し、以下のように定義されているとします。
create table sales (
> perkey integer not null,
> classkey integer not null,
>prodkey integer not null,
> storekey integer not null,
> promokey integer not null,
> quantity integer not null,
> dollars dec(7,2) not null,
> constraint sales_pkc primary key
>
(perkey, classkey, prodkey, storekey, promokey),
> constraint sales_date_fkc foreign key (perkey)
>
references period (perkey),
> constraint sales_product_fkc foreign key (classkey, prodkey)
>
references product (classkey, prodkey),
> constraint sales_store_fkc foreign key (storekey)
>
references store (storekey),
> constraint sales_promo_fkc foreign key (promokey)
>
references promotion (promokey))
> data in (daily_data1, daily_data2)
>
segment by values of (perkey)
>
ranges (min:415, 415:max)
> maxsegments 10
> maxrows per segment 60000;
一意の 300 の値を格納する Promokey 列にローカル TARGET インデックスを作成す
るとします。
4-32 Administrator’s Guide
例 : テーブル、インデックス、システム テーブルのサイズの試算
dbsize を使ってローカル TARGET インデックスのサイズを見積ります。
1.
2.
3.
4.
5.
6.
7.
8.
dbsize ユーティリティを実行します。
インデックスのサイズを見積るオプションを選択します。
TARGET インデックスのサイズを見積るオプションを選択します。
Promokey 列の最大ドメイン サイズ ( この場合は 300) を入力します。
各列のデータ型 ( この場合は integer) を入力します。
Sales テーブルの最大行数 ( この場合は 70000) を入力します。
テーブルのセグメント数 ( この場合は 2) を入力します。
ドメイン タイプについては、Enter キーを押すと最小インデックスとなる
ドメインが計算され、以下のメッセージが表示されます。
Using domain LARGE
9.
10.
11.
TARGET インデックスのドメイン サイズは、4-10 ページ「TARGET イン
デックス」を参照してください。
これがローカル インデックスかどうかという質問に対して、y と答えま
す。
これがテーブルのセグメント化の基準となる列かどうかという質問に対し
て、n と答えます。
Sales テーブルの CREATE TABLE 文に基づき、Promokey 列のローカル
TARGET インデックスのサイズが 480KB と計算されます。
例 : テーブル、インデックス、システム テーブルのサ
イズの試算
データベースのサイズを見積る例を示します。新規データベースに次のテーブルを
作成するとします。
テーブル Fact1 は、約 53,000,000 行を格納し、次のように定義されています。
create table fact1 (
tran integer not null,
seq integer not null,
prodkey integer not null,
mktkey integer not null,
description character(55),
dollars decimal(12,2),
primary key (tran, seq),
foreign key (mktkey) references market (mktkey),
foreign key (prodkey) references product (prodkey));
Prodkey 列と Mktkey 列には、STAR インデックスが作成されます。
ウェアハウス データベースの物理設計 4-33
例 : テーブル、インデックス、システム テーブルのサイズの試算
テーブル Market は約 5,000 行を格納し、次のように定義されています。
create table market (
mktkey integer not null,
mktname character(20),
primary key (mktkey));
Mktname 列には、TARGET インデックスが作成されます。
テーブル Product は約 520,000 行を格納し、次のように定義されています。
create table product (
prodkey integer not null,
category integer,
primary key (prodkey));
Category 列には、B-TREE インデックスが作成されます。
4-34 Administrator’s Guide
例 : テーブル、インデックス、システム テーブルのサイズの試算
Fact1 テーブルとインデックス
Fact1 テーブルには、STAR インデックスとプライマリ キー B-TREE インデックスが
あります。
テーブル サイズ : Fact1
dbsize を使い、Fact1 テーブルのテーブル サイズを見積ります。
1.
dbsize ユーティリティを実行します。
2.
ユーザ テーブルのサイズを見積るオプションを選択します。
3.
テーブルの列数 ( この場合は 6) を入力します。
4.
dbsize を使って行サイズを見積る場合、次の 2 つの質問に対して以下のよ
うに答えます。
テーブル サイズの見積り方法例を確認するかどうかという質問に対し
ては、n と答えます。
b. dbsize による行の見積もりを、指定したデータ型のサイズを基に行う
かという質問に対しては、y と答えます。
プロンプトに対し、列のデータ型、10 進数データ型の精度、テーブルの最
大行数 ( この場合は 53000000) を入力します。
a.
5.
6.
Fact1 テーブルの CREATE TABLE 文に基づき、テーブルのサイズが
4,038,104KB と計算されます。
STAR インデックス : Fact1
dbsize を使い、STAR インデックスのサイズを見積ります。Fact1 テーブルは、
Market テーブルと Product テーブルをフォーリン キー参照しているため、Prodkey
列と Mktkey 列に STAR インデックスを作成します。
1.
dbsize ユーティリティを実行します。
2.
インデックスのサイズを見積るオプションを選択します。
3.
STAR インデックスのサイズを見積るオプションを選択します。
4.
Market テーブルと Product テーブルの最大行数 ( この場合は、5000 行と
520000 行 ) を入力します。
5.
ファクト テーブルの見積り行数 ( この場合は 53000000) を入力します。
6.
フィル ファクタを入力します。初期ロードではデータがソートされ、イン
クリメンタル ロードで更新されるので、フィル ファクタを 66% に設定し
ます。66％ のフィル ファクタの場合は、dbsize に .66 と入力します。
7.
Fact1 テーブルの CREATE TABLE 文に基づき、STAR インデックスのサイ
ズが 946,448KB と計算されます。
ウェアハウス データベースの物理設計 4-35
例 : テーブル、インデックス、システム テーブルのサイズの試算
プライマリ キー B-TREE インデックス : Fact1
プライマリ キー B-TREE インデックスは、Fact1 の作成時に自動的に作成されます。
dbsize を使い、B-TREE インデックスのサイズを見積ります。
1.
dbsize ユーティリティを実行します。
2.
インデックスのサイズを見積るオプションを選択します。
3.
B-TREE インデックスのサイズを見積るオプションを選択します。
4.
インデックスを付ける列の数を入力します。この場合は、2 (Tran と Seq)
です。
5.
各列のデータ型 ( この場合は integer) を入力します。
6.
テーブルの最大行数 ( この場合は 53000000) を入力します。
7.
フィル ファクタを入力します。初期ロードではデータがソートされ、イン
クリメンタル ロードで更新されるので、フィル ファクタを 66% に設定し
ます。66％ のフィル ファクタの場合は、dbsize に .66 と入力します。
8.
Fact1 テーブルの CREATE TABLE 文に基づき、B-TREE インデックスのサ
イズが 1,265,704KB と計算されます。
Market テーブルとインデックス
Market テーブルには、プライマリ キー B-TREE インデックスと TARGET インデッ
クスがあります。
テーブル サイズ : Market
dbsize を使い、Market テーブルのテーブル サイズを見積ります。
1.
dbsize ユーティリティを実行します。
2.
ユーザ テーブルのサイズを見積るオプションを選択します。
3.
テーブルの列数 ( この場合は 2) を入力します。
4.
dbsize を使って行サイズを見積る場合、次の 2 つの質問に対して以下のよ
うに答えます。
テーブル サイズの見積り方法例を確認するかどうかという質問に対し
ては、n と答えます。
b. dbsize による行の見積もりを、指定したデータ型のサイズを基に行う
かという質問に対しては、y と答えます。
プロンプトに対し、列のデータ型とテーブルの最大行数 ( この場合は
5000) を入力します。
a.
5.
6.
4-36 Administrator’s Guide
Market テーブルの CREATE TABLE 文に基づき、テーブルのサイズが
136KB と計算されます。
例 : テーブル、インデックス、システム テーブルのサイズの試算
Market テーブルには、プライマリ キー B-TREE インデックスとオプションの
TARGET インデックスがあります。
インデックス サイズ : プライマリ キー B-TREE インデックス
dbsize を使って B-TREE インデックスのサイズを見積ります。
1.
dbsize ユーティリティを実行します。
2.
インデックスのサイズを見積るオプションを選択します。
3.
B-TREE インデックスのサイズを見積るオプションを選択します。
4.
インデックスを付ける列の数を入力します。この場合は、1 (Mktkey) で
す。
5.
各列のデータ型 ( この場合は integer) を入力します。
6.
インデックスを付けるテーブルの最大行数 ( この場合 5,000) を入力しま
す。
7.
フィル ファクタを入力します。データがソートされ、更新頻度が低いの
で、フィル ファクタを 100% に設定します。フィル ファクタが 100 の場
合、dbsize には、1.00 と入力します。
8.
Market テーブルの CREATE TABLE 文に基づき、B-TREE インデックスのサ
イズが 80KB と計算されます。
インデックス サイズ : Mktname 列の TARGET インデックス
dbsize を使って TARGET インデックスのサイズを見積ります。
1.
dbsize ユーティリティを実行します。
2.
インデックスのサイズを見積るオプションを選択します。
3.
TARGET インデックスのサイズを見積るオプションを選択します。
4.
Mktname 列のドメインの大きさを入力します。ここでは、市場の数が 20
あるので、ドメインの大きさを 20 と入力します。
5.
列のデータ型 ( この場合は character) を入力します。
6.
文字数 ( この場合は 20) を入力します。
7.
テーブルの最大行数 ( この場合は 5000) を入力します。
8.
テーブルのセグメント数 ( この場合は 1) を入力します。
9.
ドメイン サイズ ( この場合は SMALL) を入力します。TARGET インデック
スのドメイン サイズは、4-10 ページ「TARGET インデックス」を参照して
ください。
10.
Market テーブルの CREATE TABLE 文に基づき、TARGET インデックスの
サイズが 200KB と計算されます。
ウェアハウス データベースの物理設計 4-37
例 : テーブル、インデックス、システム テーブルのサイズの試算
Product テーブルとインデックス
Product テーブルには、プライマリ キー B-TREE インデックスとオプションの BTREE インデックスがあります。
テーブル サイズ : Product
dbsize を使い、Product テーブルのテーブル サイズを見積ります。
1.
dbsize ユーティリティを実行します。
2.
ユーザ テーブルのサイズを見積るオプションを選択します。
3.
テーブルの列数 ( この場合は 2) を入力します。
4.
dbsize を使って行サイズを見積る場合、次の 2 つの質問に対して以下のよ
うに答えます。
a.
テーブル サイズの見積り方法例を確認するかどうかという質問に対し
ては、n と答えます。
b.
dbsize による行の見積もりを、指定したデータ型のサイズを基に行う
かという質問に対しては、y と答えます。
5.
プロンプトに対し、列のデータ型 ( この場合は、両方の列 n に ( 整数 ) と
テーブルの最大行数 ( この場合は 520000) を入力します。
6.
Product テーブルの CREATE TABLE 文に基づき、テーブルのサイズが
4584KB と計算されます。
Product テーブルには、プライマリ キー B-TREE インデックスとオプションの BTREE インデックスがあります。
インデックス サイズ : プライマリ キー B-TREE インデックス
dbsize を使って B-TREE インデックスのサイズを見積ります。
1.
dbsize ユーティリティを実行します。
2.
インデックスのサイズを見積るオプションを選択します。
3.
B-TREE インデックスのサイズを見積るオプションを選択します。
4.
インデックスを付ける列の数を入力します。この場合は、1 ( Prodkey) です。
5.
各列のデータ型 ( この場合は integer) を入力します。
6.
ファクト テーブルの見積り行数 ( この場合は 520,000) を入力します。
7.
フィル ファクタを入力します。データの更新頻度が高いので、フィル
ファクタを 66% に設定します。66％ のフィル ファクタの場合は、dbsize
に .66 と入力します。
8.
Product テーブルの CREATE TABLE 文に基づき、B-TREE インデックスの
サイズが 9312KB と計算されます。
4-38 Administrator’s Guide
システム テーブルのサイズの見積り
インデックス サイズ : Category 列の B-TREE インデックス
dbsize を使って次の処理を実行します。
1.
dbsize ユーティリティを実行します。
2.
インデックスのサイズを見積るオプションを選択します。
3.
B-TREE インデックスのサイズを見積るオプションを選択します。
4.
インデックスを付ける列の数を入力します。この場合は、1 ( Category) で
す。
5.
各列のデータ型 ( この場合は integer) を入力します。
6.
ファクト テーブルの見積り行数 ( この場合は 520,000) を入力します。
7.
フィル ファクタを入力します。データの更新頻度が高いので、フィル
ファクタを 66% に設定します。66％ のフィル ファクタの場合は、dbsize
に .66 と入力します。
8.
Product テーブルの CREATE TABLE 文に基づき、Category 列の B-TREE イ
ンデックスのサイズが 9312KB と計算されます。
システム テーブルのサイズの見積り
システム テーブルは、データベースごとに作成および管理されます。システム
テーブルには、データベースとユーザに関する情報が格納され、データベース ディ
レクトリのファイル RB_DEFAULT_IDX、RB_DEFAULT_INDEXES、
RB_DEFAULT_LOADINFO、RB_DEFAULT_LOCKS、
RB_DEFAULT_SEGMENTS、RB_DEFAULT_TABLES に格納されます。
システム テーブルのサイズは、データベースに作成されたテーブルの数と列の数、
設定されたビューとマクロの数、データベースへのアクセスおよびロード操作を許
可されたユーザ数によって決まります。システム テーブルを格納できるよう、必要
に応じて RB_DEFAULT_IDX と RB_DEFAULT_LOADINFO ファイルが拡張されま
す。通常のデータベースでは、システム テーブルの所要領域は 1MB 未満です。
システム テーブルのサイズを見積るには、dbsize を使用します。このユーティリ
ティでは、次の情報が必要です。
■
■
■
■
■
■
■
列の総数
インデックスの総数
セグメントの総数
ビューの総数
テーブルの総数
プライマリ キーの総数と、各キーの列数
フォーリン キーの総数と、各キーの列数
ウェアハウス データベースの物理設計 4-39
システム テーブルのサイズの見積り
サイズ : システム テーブル
dbsize を使い、前述の例に使用したデータベースのシステム テーブルを見積ります。
1.
dbsize ユーティリティを実行します。
2.
システム テーブルのサイズを見積るオプションを選択します。
3.
列の総数 ( この場合は 10) を入力します。
4.
テーブルの総数 ( この場合は 3) を入力します。
5.
セグメントの総数を入力します。この例では、テーブル当たりのセグメン
ト数が 1、インデックス当たりのセグメント数が 1 なので、セグメントの
総数は 9 になります。
6.
インデックスの総数 ( この場合は 6) を入力します。
7.
ビューの総数 ( この場合は 0) を入力します。
8.
プライマリ キーの数に、複数列キー第 2 列め以降の列当たりのスペース
0.25 を加算した値を入力します。この例では、プライマリ キーが 3 つあ
り、うち 1 つは 2 列キーであるため、3.25 と入力します。
9.
10.
4-40 Administrator’s Guide
フォーリン キーの数 ( この場合は 2) を入力します。
システム テーブルのサイズが 392KB と計算されます。
ユーザ テーブル、インデックス、システム テーブルの総スペース
ユーザ テーブル、インデックス、システム テーブル
の総スペース
ユーザ テーブル、インデックス、システム テーブルの総容量を算出するには、
dbsize で見積った値を合計します。
データベース テーブル
Fact1 テーブル
STAR インデックス
プライマリ B-TREE インデックス
必要なスペース
(KB)
4,038,104
946,448
1,265,704
Market テーブル
136
プライマリ B-TREE インデックス
80
TARGET インデックス
200
Product テーブル
4,584
プライマリ B-TREE インデックス
9,312
Category 列の B-TREE インデックス
9,312
システム テーブル
総容量
392
6,274,272
一時領域の所要量の見積もり
データベースのテーブルとインデックスを格納する領域に加え、オプティマイズ
モードのインデックス作成とクエリ処理の中間結果を一時的に格納する領域も用意
する必要があります。インデックスの作成や複雑なクエリには、中間結果を格納す
る大量の一時領域が必要になる場合があります。インデックス作成の一時領域は構
成パラメータ INDEX_TEMPSPACE で、クエリ処理の一時領域は構成パラメータ
QUERY_TEMPSPACE および QUERY_MEMORY_LIMIT で制御します。これらの構
成パラメータは、一時ファイルを格納するディレクトリ、1 回の操作で一時領域と
して使用する最大ディスク容量、中間結果をメモリからディスクへと書き出す際の
しきい値、およびクエリに割り当てるメモリ容量を指定します。
ウェアハウス データベースの物理設計 4-41
一時領域の所要量の見積もり
この節では、一時領域の所要量について以下の項目を説明します。
■
■
■
インデックス作成を最適化するための一時領域の使用方法と、これらの操
作に使用する所要量の算出方法
クエリ処理における一時領域の使用法と、所要領域の算出方法
クエリ結果のための一時領域の使用法
集約保守での一時領域の要件については、
『IBM Red Brick Vista User’s Guide』を参照
してください。
データベース操作における一時領域の使用法以外にも、システム資源と作業負荷の
条件に応じて、以下の点も考慮しなければなりません。
■
■
■
UNIX
■
Windows
■
■
複数データベース :
データベースごとに、専用の一時領域を用意しなければなりません。
クエリ処理とインデックス作成について、それぞれ別の一時領域を割り当
てます。
両方の操作に同じ領域を設定した場合は、システムが必要な領域を動的か
つランダムに割り当てます。資源の割り当てを制御したい場合は、各操作
に個別の一時領域を設定する必要があります。
複数ユーザへの対応 :
利用可能な領域を各ユーザに分割するか、使用時間をずらします。
データ セグメントの最大サイズ
通常、カーネル コンフィグレーション パラメータに設定したオペレー
ティング システムの設定値で、プロセス当たりに利用可能なメモリ量が制
限されます。IBM Red Brick Warehouse は、このメモリ領域を TMU のバッ
ファ キャッシュ ( パラメータ TMU_BUFFERS で指定 ) と、インデックス作
成のステージング アレイ ( パラメータ INDEX_TEMPSPACE_THRESHOLD
で指定 ) に使用し、残りは一般作業領域に使用します。♦
物理メモリ :
使用するコンピュータのメモリのサイズを念頭にいれておく必要がありま
す。♦
スワップ領域 :
十分なスワップ領域を設定しても、スワップの発生時にプロセス スタック
とデータに利用できるスワップ領域が不足するとエラーが発生します。
一時ディスク領域の割り当て方法と、一時領域のパラメータは、4-44 ページ および
4-46 ページを参照してください。
4-42 Administrator’s Guide
オプティマイズ モードのインデックス作成における一時領域の使用法
オプティマイズ モードのインデックス作成における
一時領域の使用法
データベース管理操作によって最初にインデックスが作成されるときにはオプティ
マイズ モードが使用され、未ソートのデータからインデックスが作成されます。既
存インデックスに関わるほかの操作 (APPEND、REPLACE、INSERT モードの TMU
の LOADDATA 操作、および REORG 操作 ) では、指定された場合のみオプティマイ
ズ モードが使用されます。オプティマイズ モードでは動作が高速になり、通常の
モードで作成した場合よりもインデックスがコンパクトになりますが、メモリと一
時ディスク ( スクラッチ ) 領域の使用量が多くなります。オプティマイズ モードの
動作では、十分なメモリとディスク領域を確保してください。
ヒント：ソート済みデータを使って新しいインデックスを作成したり、既存イン
デックスを完全に置き換えるロード操作には、オプティマイズ モードが使用されな
いため、特別な一時領域は不要となります。一時領域が不要なため、本節の説明は
適用されません。
オプティマイズ モードのデータ ロード、テーブルの再編成、インデックス作成で
多くの行を処理する場合は、2 つのフェーズにプロセスが分割されます。最初の
フェーズ ( ソート フェーズ ) では、インデックス エントリがグループ別に一時領域
に作成されます。第 2 フェーズ ( マージ フェーズ ) では、各グループがインデック
スにマージされます。大量データのオンライン ロード、大規模なテーブルのイン
デックスの作成や再編成では、複数のソート サイクルとマージ サイクルが必要に
なります。
ソート フェーズでは、インデックス エントリのグループがいったんメモリに格納
され、その後一時ディスク領域に書き込まれます。ウェアハウス サーバや TMU が
インデックス エントリの格納に利用できるメモリの総量は、パラメータ
INDEX_TEMPSPACE THRESHOLD で設定します。メモリの格納領域がこの値にな
ると、パラメータ INDEX_TEMPSPACE DIRECTORY で指定したロケーションの
ファイル ( このパラメータが設定されていない場合は、システムの一時領域 ) にエ
ントリ グループが書き出されます。入力データの書き込みが完了するか、インデッ
クス作成に使用する一時ディスク領域の上限 (MAXSPILLSIZE) に達すると、ソート
フェーズからマージ フェーズになります。1 回の操作で複数のインデックスが作成
される場合は、指定した領域が各インデックスに分割されます。
これらの操作に必要な格納領域を設計する際は、十分なメモリとディスク領域を確
保し、パラメータ INDEX_TEMPSPACE を設定します。以下の節では、パラメータ
を設定する際のガイドラインを示します。
ウェアハウス データベースの物理設計 4-43
一時領域の割り当て
一時領域の割り当て
一時領域を構成するディレクトリの集合は循環バッファのようなものです。特定の
クエリやインデックス作成プロセス用の各ディレクトリ内に作成されるファイルの
集合は、MAXSPILLSIZE までであれば拡大できるバッファのスライスのようなもの
です。
ランダムなディレクトリの使用
プロセスがサイズの限界を超え、ディスクを一時的に消費すると、そのプロセス用
に一時領域ディレクトリのランダムな順序が決定されます。このランダムな順序に
よって、ディレクトリ使用順序が決まります。たとえば、4 つの一時領域ディレク
トリを定義している場合 (d1、d2、d3、d4)、1 つの操作では、d2、d1、d4、d3 、別
の操作では d4、d3、d1、d2 という順序になることがあります。図 4-2 に、循環
バッファを構成する一時領域ディレクトリの原理を表します。
図 4-2
ランダムなディレクトリの使用
INDEX_TEMPSPACE
4 つのディレクトリのランダムな使用順序
インデックス作成 1: 2, 1, 4, 3
インデックス作成 2: 4, 3, 1, 2
インデックス作成 2
のバッファ
インデックス作成 1
のバッファ
ID3
ID2
ID2
ID4
ID1
ID4
4-44 Administrator’s Guide
ID1
ID3
...
一時領域の割り当て
ファイルの作成と使用
各ディレクトリには、一時領域が必要な操作ごとに 1 つ以上のファイルが作成され
ます。先頭ディレクトリの先頭ファイルは、16KB のサイズに初期化されます。
MAXSPILLSIZE の値を 8KB 未満に設定すると、先頭ファイルの初期サイズは 8KB
になります。その他のファイルの初期サイズは 0 です。
ディレクトリは、各操作に設定された順序で使用されますが、1 つのディレクトリ
の全ファイルを使用してから、次の使用順序のディレクトリに進みます。
飽和状態と領域不足の状態
クエリまたはインデックス作成の一時領域が飽和 (FULL) するのは、次のどちらか
の条件が満たされた時です。
■
■
一時領域を構成する全ファイルのサイズの合計が、その領域の
MAXSPILLSIZE の値と等しくなった場合
ファイルを拡張して一時領域をさらに大きくすると、MAXSPILLSIZE の値
を超える場合
インデックス作成の一時領域が、領域不足の状態になるのは、一時領域が飽和した
場合ではなく、一時領域を構成する全ファイルが使用済みで、使用順序による最終
ファイルを拡張できるディスク領域がなくなった場合です。
一時領域が飽和または領域不足になると、以下のような影響が生じます。
■
■
■
インデックスの一時領域が領域不足になると、オンラインかオフラインか
に関係なく、インデックス作成は中止されます。
オンラインの一時領域が飽和すると、一時領域の内容がインデックスに
マージされ、一時領域が空になります。その領域を再使用し、インデック
ス作成が続行されます。
オフライン インデックスの一時領域が飽和すると、インデックス作成が中
止されます。
ウェアハウス データベースの物理設計 4-45
インデックス作成に必要な一時領域の見積り
インデックス作成に必要な一時領域の見積り
インデックス作成用の一時領域は、オプティマイズ モードのロード操作、テーブル
の再編成、インデックス作成に使用されます。複数のインデックスを作成する操作
では、指定した領域が各インデックスに均等分割されます。
次の表は、インデックス作成時の一時領域のロケーションと使い方を制御するパラ
メータと、対応する SET コマンドの一覧です。
図 4-3
インデックス作成の一時領域
TUNE パラメータと SET コマンド
機能
TUNE INDEX_TEMPSPACE_DIRECTORY,
SET INDEX TEMPSPACE DIRECTORIES*
インデックス作成に使用する一時領域のディレクトリ
を指定します。rbw.config ファイルには複数のエント
リを記述できます。1 つのエントリには 1 つのディレ
クトリを指定します。*
TUNE INDEX_TEMPSPACE_THRESHOLD,
SET INDEX TEMPSPACE THRESHOLD
インデックス作成または CHECK INDEX VALIDATE
FULL 操作によって、メモリからディスクのスピル領
域に書き出されるサイズを指定します。
TUNE INDEX_TEMPSPACE_MAXSPILLSIZE,
SET INDEX TEMPSPACE MAXSPILLSIZE
インデックス作成に使用できるスピル領域 ( 一時的な
領域 ) の最大サイズを指定します。
SET INDEX TEMPSPACE RESET
クエリまたはインデックスのパラメータ TEMPSPACE
を、rbw.config ファイルの設定値にリセットします。
* IBM Red Brick Warehouse と TMU の一時領域の使用率が均等になるように、自動的に指定ディレクトリに領域が分
散されます。
パラメータ INDEX_TEMPSPACE は、CREATE INDEX 文、TMU の LOAD DATA お
よび REORG 操作によるインデックスの作成と更新に使用します。
これらのパラメータの値は、rbw.config ファイルまたは SET コマンドを使って設定
できます。SET コマンドは、次のいずれかに指定できます。
■
■
■
4-46 Administrator’s Guide
.rbwrc ファイル
Red Brick Warehouse Administrator ツールの RISQL セッションまたは ISQL
ウィンドウなどの SQL 文を任意に入力できます。
TMU コントロール ファイル
インデックス作成に必要な一時領域の見積り
DIRECTORY Location 値
インデックス作成用の一時領域には、複数のファイル システムにあるディレクトリ
を使用することができます。INDEX_TEMPSPACE の一時領域ディレクトリを指定
する目的は、ファイル システムの容量制限に依存しないこと、入出力の競合を避け
ることです。ディレクトリの使用順はランダムで、必要な場合のみ領域が割り当て
られます。rbw.config ファイルのエントリを使って複数のディレクトリを定義する
には、ディレクトリごとに行を分けて記述してください。
すべてのセッションに適用される rbw.config ファイルのエントリを設定する例を示
します。
TUNE INDEX_TEMPSPACE_DIRECTORY /dbindex/spill1
TUNE INDEX_TEMPSPACE_DIRECTORY /dbindex/spill2
TUNE INDEX_TEMPSPACE_DIRECTORY /dbindex/spill3
UNIX
♦
TUNE INDEX_TEMPSPACE_DIRECTORY d:¥itemp
TUNE INDEX_TEMPSPACE_DIRECTORY e:¥itemp
TUNE INDEX_TEMPSPACE_DIRECTORY f:¥itemp
Windows
♦
複数のデータベースを使用するウェアハウスの場合は、データベースごとに個別の
一時領域ディレクトリ セットを用意しなければなりません。rbw.config ファイルの
エントリに設定するのではなく、SET コマンドで指定します。
SET INDEX TEMPSPACE DIRECTORIES ‘/qa/local/virginia/aroma/spill1’,
‘/qa/local/virginia/aroma/spill2’,
‘/qa/local/virginia/aroma/spill3’,
一時領域ディレクトリに指定したディレクトリに対する領域の割り当て方法は、
4-44 ページを参照してください。
THRESHOLD 値
しきい値には、インデックス作成または CHECK INDEX VALIDATE FULL 操作の中
間結果をディスクの一時領域に書き出す前に使用されるメモリ容量を指定します。
INDEX_TEMPSPACE_THRESHOLD のデフォルト値は、小規模なシステムに合わせ
て 10MB に設定されています。このしきい値を変更する場合は、SET INDEX
TEMPSPACE 文に THRESHOLD オプションを付けて指定し、rbw.config ファイルに
デフォルト値を指定してください。
ウェアハウス データベースの物理設計 4-47
インデックス作成に必要な一時領域の見積り
INDEX_TEMPSPACE のしきい値を設定する目的は、IBM Red Brick Warehouse を実行
しているシステムに対し、エラーを発生させない範囲で十分な領域を割り当てるこ
とです。しきい値が大きすぎる ( 利用可能なメモリの値を超える ) と、メモリ不足
により操作が失敗します。しきい値が小さすぎると、ディスクに書き出す時間が長
くなるため、性能が低下します。オンラインとオフライン両方のロード操作と、ほ
かのインデックス作成について適切なしきい値を見積る必要があります。
UNIX
しきい値を見積るには、以下のようにします。
1.
2.
コンピュータ上の物理メモリの半分以上のメモリ容量をしきい値として指
定すべきではありません。使用するコンピュータの許容最大プログラム
データ領域を確認します。通常は、使用しているコンピュータの UNIX
カーネル コンフィグレーションに設定されています。設定値がわからない
場合は、システム管理者またはシステムのベンダに問い合わせてくださ
い。
実行する操作にふさわしい INDEX_TEMPSPACE_THRESHOLD の値を選択
します。
a. ロードおよび CREATE INDEX 操作を行う場合、
INDEX_TEMPSPACE_THRESHOLD には、システム上の最大データ領
域の 4 分の 1 から 2 分の 1 の値を設定することをお勧めします。
b.
CHECK INDEX に VALIDATE FULL オプションを付けて指定する場合、
INDEX_TEMPSPACE_THRESHOLD には、システム上の最大データ領
域の 4 分の 1 の値を設定することをお勧めします。
INDEX_TEMPSPACE_THRESHOLD は、ユーザ 1 人当たりのメモリ容
量です。複数のユーザが同時にメモリ使用率の高い操作を実行してい
るときに、CHECK INDEX を VALIDATE FULL オプション付きで実行
する場合は、しきい値の設定値をユーザ数で割ってください。
たとえば、2 人のユーザが複雑な操作を実行していて、CHECK
INDEX を VALIDATE FULL オプション付きで実行する場合、しきい値
の設定値を 3 で割ります。ステップ 2 のしきい値 64 を 3 で割って、し
きい値を 22 に設定します。
SET INDEX TEMPSPACE THRESHOLD 22M
入力値は、8KB の倍数に自動的に切り上げられます ( この場合、24KB
になります )。♦
Windows
しきい値を見積るには、以下のようにします。
1.
2.
4-48 Administrator’s Guide
使用するコンピュータの物理メモリ サイズを確認します。Windows の最大
物理メモリは、2GB です。
実行する操作の種類に合わせて INDEX_TEMPSPACE_THRESHOLD の値を
選択します。前述の UNIX のステップ 2 での説明が、そのまま Windows に
も適用できます。♦
インデックス作成に必要な一時領域の見積り
MAXSPILLSIZE 値
最大スピル サイズとは、1 つの操作に使用できる一時ディスク領域の最大量です。
1 つの操作で複数のインデックスを作成する場合は、指定したサイズが各インデッ
クスに均等に分割されます。クエリ処理では、各クエリおよびサブクエリ ( サブク
エリがある場合 ) に指定したサイズが割り当てられます。
INDEX_TEMPSPACE の最大値を設定する目的は、ディスク領域が不足する前に操
作を完了させるように最大限の領域を確保することです。使用可能なディスク領域
より大きい値が選択されると、領域不足によるエラーが発生し、ロード操作、テー
ブルの再編成、インデックスの作成が失敗します。オンライン ロードの指定値が小
さすぎると、実行されるソートとマージのサイクル数が増えます。この結果、操作
に要する時間が増えます。オフライン ロードの指定値が小さすぎると、操作が失敗
します。
オンライン操作では複数のソート サイクルとマージ サイクルが実行できますが、
オフライン操作は 1 回のサイクルで完了しなければなりません。このため、オンラ
イン操作とオフライン操作では、必要な最大スピル サイズが異なります。詳細につ
いては以降の各節で説明します。
オンラインのインデックス作成操作
オプティマイズ モードのオンライン インデックス作成について、適切な最大スピ
ル サイズを設定するには、以下のようにします。
1.
操作中に処理される、DOMAIN SMALL と DOMAIN MEDIUM の TARGET
インデックス以外のインデックスの数を判定します。最大スピル サイズ
は、各インデックスに均等分割されます。
テーブルへの 1 回のロード操作または REORG 操作の対象となるインデッ
クス数は、ロードするテーブルの全インデックス (DOMAIN SMALL と
DOMAIN MEDIUM の TARGET インデックスを除く ) の数です。
指定した複数のインデックスを再作成する REORG 操作の対象となるイン
デックス数は、REORG 文に指定したインデックス (DOMAIN SMALL と
DOMAIN MEDIUM の TARGET インデックスを除く ) の数です。
CREATE INDEX 操作の対象となるインデックス数は、1 つのコマンドで作
成されるインデックス (DOMAIN SMALL と DOMAIN MEDIUM の
TARGET インデックスを除く ) の数です ( 各インデックスが、個別に処理
されるため )。
2.
ステップ 1 で判定したインデックスごとに、dbsize ユーティリティを使っ
てインデックスのサイズを見積ります。
3.
各インデックス (DOMAIN SMALL または DOMAIN MEDIUM の TARGET
インデックス以外 ) について、dbsize で算出した値を合計します。この合
計値が、インデックス作成操作の <total_space_required> の値になります。
ウェアハウス データベースの物理設計 4-49
インデックス作成に必要な一時領域の見積り
4.
システム資源と以下の条件に基づき、インデックス作成に割り当てる一時
ディスク領域 (MAXSPILLSIZE の値 ) を算定します。
<total_space_required>
<number_of_cycles>
MAXSPILLSIZE <=
<=
MAXSPILLSIZE
X
<available_temp_space>
<number_of_cycles>
ソート サイクルとマージ サイクルの数
<available_temp_space>
インデックス作成の一時領域に指定された
ディレクトリに利用できる領域
十分な一時領域がある場合は、INDEX_TEMPSPACE_MAXSPILLSIZE の値
が大きいほど、インデックスの作成に必要なソートとマージの繰り返しが
少なくなり、その結果、インデックスの作成時間が短くなります。
INDEX_TEMPSPACE_MAXSPILLSIZE の値は、8KB ブロックの倍数に自動
的に切り上げられます。
オフラインのインデックス作成操作
オフラインのロード操作では、オプティマイズ モードの 2 つの処理フェーズ ( ソー
トとマージ ) が、2 つの独立した TMU 操作に分割されます。複数セグメントで構成
された大規模なテーブルに対するオフライン ロード操作では、オフライン ロード
の第 1 フェーズ中にユーザがテーブルにアクセスできるため、データベースの利用
効率が高まります。オフラインの TMU の LOAD 操作は、入力レコードの読み込み、
フォーマット設定、オフライン セグメントへのロードを行い、インデックス デー
タのグループをインデックス作成の一時領域に作成します。TMU の SYNCH 操作
で、オフライン セグメントと対応するテーブルを同期させる第 2 フェーズが実行さ
れます。
オフライン ロードを正常に完了させるには、オンライン ロードの場合より慎重な
計画が必要です。その理由は以下の 2 つです。
■
オフライン ロードでは、1 回のマージでロード操作が完了できる十分な一
時領域を用意しないと、操作が失敗します。オンライン ロードと異なり、
インデックス グループの作成サイクルとインデックスへのマージ サイク
ルを相互に切り換えることはできません。このため、1 回のロード ステッ
プでロードできるデータの量は、利用できる一時領域の量と、パラメータ
INDEX_TEMPSPACE_MAXSPILLSIZE の設定値によって制限されます。
■
オフライン ロードに割り当てた一時領域は、SYNCH 操作が完了するまで
は解放されません。たとえば、昼間にロード操作を行い、対象テーブルが
昼間利用できるように SYNCH 操作を夕方まで延期すると、その間はロー
ドに使用した一時領域をほかの操作に使用することはできません。この間
にほかのロード操作、テーブルの再編成、インデックスの作成を行うと、
一時領域が不足する場合があります。このため、オフライン ロードに必要
4-50 Administrator’s Guide
TARGET インデックスの一時領域の所要量
なディレクトリを作成し、TMU の SET コマンドを使って
INDEX_TEMPSPACE ディレクトリのロケーションを設定する必要があり
ます。
オフライン ロードに必要なディスク領域は、以下の手順で算出します。
1.
各インデックス (TARGET インデックスを含む ) について、dbsize ユー
ティリティを使ってインデックスのサイズを見積ります。
2.
各インデックスについて、dbsize で算出した値を合計します。この合計値
が、インデックス作成操作の <total_space_required> の値になります。
3.
次の条件に基づき、MAXSPILLSIZE の値を設定します。
<total_space_required>
<available_temp_space>
<available_temp_space>
<=
MAXSPILLSIZE
<=
インデックス作成の一時領域に指定された
ディレクトリに利用できる領域
入力値は、8KB の倍数に自動的に切り上げられます。
上記の条件を満たすパラメータ INDEX_TEMPSPACE_MAXSPILLSIZE が設定できな
い場合は、オフライン ロードでロードする行数を少なくするか、ロードに利用でき
る一時領域を増やす必要があります。
TARGET インデックスの一時領域の所要量
大規模なテーブルに TARGET インデックスを作成する際 ( たとえば、TARGETjoin
処理を有効にするためにファクト テーブルのフォーリン キー列に TARGET イン
デックスを作成する場合 ) は、次の一時領域の所要量に注意します。
■
DOMAIN SMALL および DOMAIN MEDIUM の場合は、一時領域を使用し
ません。
■
DOMAIN LARGE を指定して、ドメイン値を指定しない (「ハイブリッド」
表現形式 ) 場合は、インデックス作成操作は、次の式に基づく一時領域の
最大量を使用することができます。
一時領域 = (<keysize> + 11) x <rows>
<keysize>
インデックス作成される列の幅 ( バイト数 )
<rows>
テーブルの行数
ウェアハウス データベースの物理設計 4-51
現在の設定値の確認
必ずしもインデックス作成のために大きな領域を割り当てる必要はありま
せん。ただし、一時領域を使い果たすと、それにともない一時領域から実
際のインデックスへのソート サイクルとマージ サイクルを発生します。
発生するソート サイクルとマージ サイクルが多いほど、インデックス作
成操作は時間がかかります。
たとえば、10 億行のテーブルの整数列に「ハイブリッド」TARGET イン
デックスを作成する場合、IBM Red Brick Warehouse が使用する一時領域の
最大量は次のとおりです。
(4 + 11) x 1,000,000,000 = 15,000,000,000 bytes, or
approximately 15 gigabytes
この場合は、15GB の一時領域を割り当てると、インデックスが必要とす
るソート サイクルとマージ サイクルが 1 回だけとなるので、インデックス
作成の所要時間は最短となります。2GB の一時領域を割り当てると、7 回
のソート サイクルとマージ サイクルが発生するので、インデックス作成
の合計時間が増加します。
現在の設定値の確認
パラメータ QUERY_TEMPSPACE と INDEX_TEMPSPACE の現在の設定値を確認す
るには、RBW_OPTIONS システム テーブルを参照します。
現在のセッションに適用されているパラメータ QUERY_TEMPSPACE の値を参照す
るには、次のようなクエリを実行します。
RISQL> select substr(option_name, 1, 30), substr(value, 1, 40)
from rbw_options
where username = CURRENT_USER
and option_name like 'INDEX?_%' escape '?';
INDEX_TEMPSPACE_DIRECTORY
INDEX_TEMPSPACE_THRESHOLD
INDEX_TEMPSPACE_MAXSPILLSIZE
INDEX_TEMPSPACE_DUPLICATESPILL
4-52 Administrator’s Guide
/qa/local/virginia/aroma/spill
10240 Kbytes
1 Gbytes
2
テンポラリ ファイルの削除
テンポラリ ファイルの削除
スピル ファイル ( 一時的なファイル ) は、データベース サーバ (rbwsvr)、または
TMU によってできるだけ早い時期に削除されますが、データベース サーバや TMU
が異常終了した場合、スピル ファイルをすべて削除できないことがあります。この
スピル ファイルの削除は、UNIX のウェアハウス デーモン (rbwapid)、または
Windows の IBM Red Brick Warehouse サービスによって、初期化時にクリーンアップ
スクリプトが実行されます。実行するスクリプトは、rbw.config ファイルの次のエ
ントリで指定します。
RBWAPI CLEANUP_SCRIPT <script_name>
<script_name> システムのクリーンアップ スクリプト名
UNIX
デフォルトのクリーンアップ スクリプト、redbrick_dir/bin/rb_sample.cleanup は、
rbw.config ファイルで指定されている QUERY_TEMPSPACE および
INDEX_TEMPSPACE ディレクトリからすべてのファイルを削除します。rbw.config
ファイルにディレクトリが設定されていない場合は、/tmp ディレクトリからスピル
ファイル ( 一時的なファイル ) を検索して削除します。また、残された一時セグメ
ント PSU も削除します。指定されたクリーンアップ スクリプトは、データベース
サーバや TMU セッション中に SET コマンドにより指定されたロケーションからス
ピル ファイルを検索し、削除することはありません。これらのロケーションからス
ピル ファイルを削除するには、スクリプトを修正する必要があります。♦
Windows
<redbrick_dir>¥bin¥rbclean.bat ファイルは、c:¥temp ディレクトリからスピル ファイ
ルを削除するのに使用するサンプル コマンドを示すテンプレートです。これらのサ
ンプル コマンドを実行するには、各 ERASE コマンドの先頭にある「REM」を削除
します。また、構成パラメータ QUERY_TEMPSPACE_DIRECTORY、
INDEX_TEMPSPACE_DIRECTORY、TEMPORARY_DATA_SEGMENT、および
TEMPORARY_INDEX_SEGMENT に指定したディレクトリからスピル ファイルと残
された一時セグメント PSU を削除するには、スクリプトを修正する必要がありま
す。♦
クエリ処理における一時領域の使用法
クエリに割り当てるメモリの量は、パラメータ QUERY_MEMORY_LIMIT で設定し
ます。クエリ処理に割り当てる一時領域のロケーションとサイズは、パラメータ
QUERY_TEMPSPACE_DIRECTORY とパラメータ
QUERY_TEMPSPACE_MAXSPILLSIZE で設定します。この領域は、クエリの中間結
果、サブクエリの結果、最終的なリザルト セットのステージング アレイを格納す
るのに使用されます。この領域はクエリ処理にのみ使用され、TMU には使用され
ません。
ウェアハウス データベースの物理設計 4-53
クエリ処理における一時領域の使用法
クエリの一時領域は、インデックス作成の一時領域と同様に、複数のファイル シス
テム上のディレクトリに分散させることができます。指定したメモリ量と最大スピ
ル サイズが、クエリ単位に割り当てられます ( サブクエリも 1 つのクエリと見なさ
れます )。一時領域ディレクトリに指定したディレクトリに対する領域の割り当て
方法は、『Query Performance Guide』を参照してください。
オンラインのインデックス作成では、複数のサイクルに操作を分割してディスク領
域が再利用できますが、クエリ処理の場合は、メモリの上限を超えるクエリについ
て、リザルト セット全体を処理するのに十分な一時ディスク領域を確保しなければ
なりません。
4-54 Administrator’s Guide
クエリ処理に必要な QUERY_MEMORY_LIMIT の見積り
クエリ処理に必要な QUERY_MEMORY_LIMIT の見
積り
適切な QUERY_MEMORY_LIMIT 値を見積るには、以下のようにします。
1.
返されるリザルト セットの行数を見積ります。
2.
以下の値を合計し、行のサイズを計算します。
■
返される各列のデータ型のサイズを合計したもの
■
オーバーヘッドとして 10 バイト
■
GROUP BY 操作の場合は、グループ当たり 32 バイト
3.
行のサイズと、リザルト セットの行数をかけ合わせます。これが、すべて
の中間結果が処理できるメモリの量になります。
4.
利用可能なメモリ、クエリの複雑さ、ユーザ数に基づき、計算された値を
調整します。
■
UNIX では、1 つのプロセスが利用できる最大プログラム データ領域
を確認します。Windows では、使用しているコンピュータ上の物理メ
モリの量を確認します。
QUERY_MEMORY_LIMIT には、この値を超える値を設定しないでく
ださい。
■
サブクエリを含むクエリ、GROUP BY 句、DISTINCT 句、ORDER BY
句を使用するクエリは、メモリの上限を大きくすると効率的になりま
す。グループ数の多い GROUP BY 操作も、メモリの上限が大きいほど
多くの処理がメモリで実行できるので、性能が上がります。
■
マルチユーザ環境では、QUERY_MEMORY_LIMIT の値が小さい方が
一般に効率的です。複数のクエリが物理メモリを大量に使用する際に
発生する、大規模なページングがなくなるからです。
入力値は、8KB の倍数に自動的に切り上げられます。
ウェアハウス データベースの物理設計 4-55
クエリ処理に必要な MAXSPILLSIZE 値の見積り
クエリ処理に必要な MAXSPILLSIZE 値の見積り
クエリ処理の一時領域について、適切な MAXSPILLSIZE の値を見積るには、以下
のようにします。
1.
クエリの処理に使用できるディスク領域の最大量と、一時領域を使用する
クエリを実行するユーザの数を判定します。複雑なクエリを実行するユー
ザが多くいる場合は、クエリの一時領域ディレクトリの取り合いになりま
す。ユーザごとに専用の一時領域ディレクトリを (SET コマンドで ) 設定す
れば、この問題を回避することができます。
2.
負荷のピーク時にもすべてのユーザがクエリを処理できるように、一時領
域を制限する MAXSPILLSIZE の値を設定します ( 入力値は、8KB の倍数
に自動的に切り上げられます )。
実行時間の長いクエリのリザルト バッファ
リザルト バッファは、一時領域中のクエリ結果を格納する部分です。サーバの処理
が完了し、クエリ結果をクライアントが取得するまでの間、置いておく場所です。
クライアント ツールの中には、ユーザの要求がないと一定量以上のデータを抽出で
きないものもあるため、リザルト バッファが必要になります。クエリの処理中は、
クエリに必要なテーブルに Read ロックがかけられます。実行時間の長いクエリの
場合は、Read ロックの時間も長くなり、その間はほかのユーザが INSERT、
UPDATE、DELETE、LOAD を行うことはできません。
リザルト セットが大きい場合は、すべての結果が IBM Red Brick Warehouse から出さ
れるか、バッファに入れられるまでは、テーブルに Read ロックがかけられたまま
になります。一定量以上のデータ抽出にユーザの要求を必要とするクライアント
ツールの場合は、すべての結果がクライアントに送信されるか、リザルト バッファ
に格納されてクライアントの要求を待機する状態になるまで、テーブルの Read
ロックは解除されません。
リザルト バッファの動作を制御する SQL の SET 文と、対応する rbw.config TUNE
パラメータは、次のとおりです。
■
■
■
■
4-56 Administrator’s Guide
SET RESULT BUFFER
SET RESULT BUFFER FULL ACTION
TUNE RESULT_BUFFER
TUNE RESULT_BUFFER_FULL_ACTION
実行時間の長いクエリのリザルト バッファ
RESULT BUFFER
クエリの結果をクライアントが取得するまで格納しておくバッファのサイズを指定
するには、次のフォーマットによる設定を rbw.config ファイルに記述します。
TUNE RESULT_BUFFER <value>
<value>
パラメータ rbw.config または SET 文の値には、以下が指定できます。
■ バッファのサイズを表す整数の値。指定単位は、KB、MB、GB のい
ずれかで、数値の後にそれぞれ K、M、G を指定します。
■ キーワード UNLIMITED。バッファのサイズに制限がないことを示
しています。バッファは、パラメータ QUERY TEMPSPACE
MAXSPILLSIZE で割り当てられる領域と同じ領域を使用します。
パラメータ RESULT BUFFER を UNLIMITED に設定しても、QUERY
TEMPSPACE MAXSPILLSIZE の値がサイズの上限となります。
■ 値に 0 を設定すると、結果はバッファに格納されません。
対応する SQL SET 文は、次のフォーマットで指定します。
set result buffer <value>;
RESULT BUFFER FULL ACTION
リザルト バッファのサイズがパラメータ RESULT_BUFFER の値に達した時の動作
を指定するには、次のフォーマットによる設定を rbw.config ファイルに記述しま
す。
TUNE RESULT_BUFFER_FULL_ACTION <action>
対応する SQL SET 文は、次のフォーマットで指定します。
set result buffer <value>;
<action>
アクションには、以下を指定できます。
■ キーワード ABORT。バッファ サイズに達した場合、クエリを中止
することを指定します。
■ キーワード PAUSE 。バッファ サイズに達した場合、クライアント
が次のデータを要求するまで、クエリの処理を一時停止することを
指定します。
ウェアハウス データベースの物理設計 4-57
テーブル データの増加への対応
例
この SET 文は、現在のセッションについてリザルト バッファのサイズを 100MB と
設定し、設定値に達した時点でクエリ処理を中止することを指定します。
set result buffer 100M;
set result buffer full action abort;
テーブル データの増加への対応
アプリケーションによっては、データベースのテーブルは時間とともに増大しま
す。IBM Red Brick Warehouse では、TMU のインクリメンタル ロード機能や INSERT
文を使用することで、既存テーブルに行データを追加することができます。拡大が
予想される大規模なテーブルを名前付きセグメントに格納すると、必要に応じて追
加領域を柔軟に割り当てることができます。
テーブルの拡大に備えて予約した拡張ディスク領域は、行の追加によって実際に必
要になるまでは使用されません。このため、セグメントを作成する時点では、その
領域が利用できなくてもかまいません。
経験と知識を有するユーザには、一時テーブルではなく、存在期間が限定された実
際のユーザ テーブルである一過性テーブルの作成が許可される場合があります。こ
のような上級ユーザは、一過性テーブルを使用して、中間クエリ データやプロダク
ション データ ウェアハウスから抽出したデータを格納します。ユーザに名前付き
セグメントの作成許可を与えるのは望ましくありませんが、これらの上級ユーザに
は、2GB を超える非常に大きい一過性テーブルの作成を許可してもよい場合があり
ます。この場合は、rbw.config ファイルのパラメータ DEFAULT_SEGMENT_SIZE
および DEFAULT_PSU_EXTENDSIZE に大きな値を設定できます。構成ファイルの
パラメータの詳細については、付録 B 「構成ファイル」を参照してください。
テーブルが拡大している場合、定期的に管理手順によって現在のディスク使用量の
点検と評価を行い、システム テーブルにクエリを実行して、テーブルの拡大状況と
利用可能な領域を監視する必要があります。テーブルの拡大状況に応じて、ALTER
SEGMENT 文を使って追加領域を割り当てることができます。
警告 : 拡張ディスク領域は、実際に必要になるまでは割り当てられないため、
CREATE SEGMENT 文で十分な量を指定しても、データを追加していくうちにディ
スク領域が足りなくなる場合があります。
4-58 Administrator’s Guide
テーブルの拡大が STAR インデックスに及ぼす影響
テーブルの拡大が STAR インデックスに及ぼす影響
拡大するテーブルについては、STAR インデックスがどのように拡大するかも考慮
する必要があります。
STAR インデックスは、FOREIGN KEY 句によって参照元テーブルと複数の参照先
テーブルを関連付けます。STAR インデックスを作成すると、ファクト テーブルが
参照するディメンジョン テーブルに指定された MAXSEGMENTS の値と
MAXROWS PER SEGMENT の値に基づく要素が静的に設定されます。MAXROWS
PER SEGMENT は、STAR インデックスに関連したディメンジョン ( 参照先 ) テーブ
ルの作成時に指定しなければなりません。そうしないと、CREATE STAR INDEX 文
がエラーになります。
STAR インデックスには、参照先テーブルに追加する行に対応できる領域を用意す
る必要があります。領域が不足していると、新規行を追加した時に無効になってし
まうことがあります。無効になった STAR インデックスは、TMU の REORG コマン
ドで再編成するか、削除して再作成しなければなりません。更新頻度の高い参照先
( ディメンジョン ) テーブルや大規模な参照元 ( ファクト ) テーブルの場合は、オー
バーヘッドが膨大になり、REORG 操作を定期的に行うことは不可能になります。
参照先テーブルの MAXSEGMENTS と MAXROWS PER SEGMENT の値を変更する
と、テーブルに行を追加したり ALTER SEGMENT 文によってセグメントを拡張し
た際に REORG 操作が必要になることがあります。MAXSEGMENTS および
MAXROWS PER SEGMENT の各パラメータに正確な値を設定して、ディメンジョ
ン テーブルの増大に備えて十分なスペースを予約した場合は、セグメントを変更し
て、REORG 操作を実行する必要がなくなるか、または少なくともそれを予期して
前もって計画する必要がなくなります。
各テーブルに、MAXSEGMENTS および MAXROWS PER SEGMENT の値を指定す
ることをお勧めします。これらのパラメータが指定されていないと、テーブルを参
照する STAR インデックスを作成することはできません。
ウェアハウス データベースの物理設計 4-59
第5章
データベースの作成
概要 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-3
5-4
5-4
5-6
5-8
5-9
データベースの作成 . . . . . . .
データベース作成の構文 . . . .
データベースの初期化 . . . . .
データベース論理名の設定 . . .
DBA アカウント パスワードの変更
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
. .
データベース オブジェクトの作成 .
.
.
.
.
.
.
.
セグメントの作成 . . . . . . . . . . . . .
セグメント化の規則 . . . . . . . . . . .
セグメント化の方法 . . . . . . . . . . .
STAR インデックスのセグメント化 . . . . .
セグメントの作成と削除および部分的に利用可能な
テーブルへのクエリ . . . . . . . . .
デフォルト セグメントのロケーション . . .
セグメントの削除動作 . . . . . . . . .
.
.
.
.
.
5-11
. . . .
. . . .
. . . .
. . . .
. .
. .
. .
. .
5-12
5-13
5-15
5-16
. . . .
. . . .
. . . .
. .
. .
. .
5-19
5-19
5-20
テーブルの作成 . . . . . . . . . . . . . . . . . . . .
MAXSEGMENTS オプションと
MAXROWS PER SEGMENT オプションの設定 . . . . . .
プライマリ キー制約とフォーリン キー制約の命名 . . . . . .
ON DELETE による参照整合性の維持 . . . . . . . . . . .
VARCHAR 列フィル ファクタの設定 . . . . . . . . . . .
データベース サーバにおける VARCHAR フィル ファクタの機能
性能に対するフィル ファクタの影響 . . . . . . . . . .
VARCHAR フィル ファクタの精度の監視 . . . . . . . . .
フィル ファクタの現在値の取得 . . . . . . . . . . .
CHECK TABLE 文の VERBOSE オプション . . . . . . .
VARCHAR フィル ファクタの変更 . . . . . . . . . .
5-21
5-22
5-22
5-23
5-24
5-24
5-25
5-30
5-30
5-31
5-32
インデックスの作成 . . . . . . . . . . . .
INDEX TEMPSPACE . . . . . . . . . . .
並列インデックス . . . . . . . . . . . .
インデックス フィル ファクタの設定 . . . . .
任意のインデックスのフィル ファクタの確認 .
デフォルトのフィル ファクタを変更 . . . .
インデックスのフィル ファクタの変更 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-33
5-34
5-35
5-36
5-38
5-39
5-40
定期的に更新されるデータベースの作成 . . . . . .
データ セグメントとインデックス セグメントの作成
テーブルの作成 . . . . . . . . . . . . .
STAR インデックスの作成 . . . . . . . . . .
ローカル TARGET インデックスの作成 . . . . .
データ . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-41
5-42
5-49
5-50
5-53
5-55
ビューの作成 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-57
マクロの作成と管理 . . . .
マクロ定義のガイドライン
マクロの利用範囲 . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5-59
5-59
5-60
5-2 Administrator’s Guide
.
.
.
.
.
この章について
データベース スキーマを設計してその実装を計画し、データベース システム テー
ブルとほかのデータベース オブジェクトを作成します。この章では、データベース
を作成するプロセスについて説明します。つまり、データベースを初期設定してそ
のテーブルやインデックスなどのデータベース オブジェクトを作成する処理につい
て説明します。この章では、以下について説明します。
■
■
■
■
■
■
■
■
■
概要
データベースの作成
データベース オブジェクトの作成
セグメントの作成
テーブルの作成
インデックスの作成
定期的に更新されるデータベースの作成
ビューの作成
マクロの作成と管理
概要
この章で説明する処理操作には、データベースの運用中に繰り返し行うものがあり
ます。ユーザのニーズの変化に応じてデータベースも修正しなければならないから
です。たとえば、テーブルを追加または削除したり、ビュー、マクロ、ユーザ特権
の定義を変更することが必要になります。
この章では、各種のデータベース オブジェクトを作成する一般的な手順と例を示し
ます。SQL 構文に関する詳細な説明については、
『SQL Reference Guide』を参照して
ください。また、データベースの作成方法を示す詳しい例については、付録 A 「例
: データベースの作成」を参照してください。
データベースの作成
5-3
データベースの作成
データベースを作成する手順は以下のとおりです。
1.
2.
UNIX では rb_creator ユーティリティを、Windows では dbcreate ユーティ
リティを使用して、データベースを作成します。
論理的なスキーマ設計と物理的な設計に基づき、セグメント、ユーザ テー
ブル、インデックス、シノニム、ビュー、マクロなどのデータベース オブ
ジェクトを作成します。
データベースの作成後は、第 7 章「データベースのアクセス権とセキュリティ」の
説明に従ってユーザにデータベースへのアクセスを提供し、『Table Management
Utility Reference Guide』の説明に従い、Table Management Utility (TMU) を使用して
データをロードします。
データベースの作成
データベースを作成するには、UNIX では rb_creator ユーティリティ、Windows で
は dbcreate ユーティリティを使用してデータベースを初期化し、システム テーブル
を作成します。次に、データベースの論理名を rbw.config ファイルに定義します。
このときにデータベース管理アカウントのデフォルト パスワードも変更してくださ
い。この節では、これらの処理操作について説明します。
デフォルトでは、IBM Red Brick Warehouse のインストール時に指定したロケールで
データベースが作成されます。ロケールを変更したい場合は、有効なロケールの中
から選択します。サーバ ロケールの定義に関する詳細については、2-27 ページ
「サーバ ロケール」を参照してください。ロケールのリストについては、IBM Red
Brick Warehouse 製品 CD-ROM の relnotes ディレクトリの locales.pdf ファイルを参照
してください。
データベース作成の構文
データベースの作成には、UNIX では rb_creator ユーティリティ、Windows では
dbcreate ユーティリティを使用します。
重要 : rb_creator または dbcreate ユーティリティを使用するには、環境変数
RB_CONFIG を設定しておく必要があります。RB_CONFIG の詳細については、
2-25 ページ「環境変数」を参照してください。
5-4 Administrator’s Guide
データベース作成の構文
UNIX
UNIX にデータベースを作成する手順は、以下のとおりです。
rb_creator <dirname> ["<language_territory.codeset@sort>"]
<dirname>
データベース ディレクトリです。
"<language_territory.
codeset@sort>"
オプション。データベースのロケールが、IBM Red Brick
Warehouse のロケール (rbw.config ファイルのパラメータ
NLS_LOCALE LOCALE で設定 ) とは異なる場合のロケール
です。
♦
Windows
Windows にデータベースを作成する手順は、以下のとおりです。
dbcreate -d <dirname> [-l <logical database name>] [-a]
[-u <username>] [-p <password>]
[-n "<language_territory.codeset@sort>"]
-d <dirname>
データベース ディレクトリです。
-l <logical database name> オプション。rbw.config ファイルに追加するデータベース
の論理名です。
-a
オプション。管理データベースを作成します。
-u <username>
オプション。ユーザ名です ( デフォルトは SYSTEM)。
-p <password>
オプション。パスワードです ( デフォルトは MANAGER)。
-n "<language_territory.
codeset@sort>"
オプション。データベースのロケールが、IBM Red Brick
Warehouse のロケール (rbw.config ファイルのパラメータ
NLS_LOCALE LOCALE で設定 ) とは異なる場合のロケー
ルです。
♦
データベースの削除方法については、9-105 ページ「データベースの削除」を参照
してください。
データベースの作成
5-5
データベースの初期化
データベースの初期化
新規のデータベースは、UNIX では rb_creator ユーティリティ、Windows では
dbcreate ユーティリティを使用して、初期化します。
UNIX
新しいデータベースを初期化する手順は、以下のとおりです。
1.
2.
redbrick ユーザとしてログインして、データベースを作成するディレクト
リの親ディレクトリに移動します。
データベース ディレクトリを作成します。
$ mkdir <dirname>
<dirname>
3.
/disk1/<database> などのディレクトリのパス名
redbrick ユーザは、データベース ディレクトリを作成できるアクセス権を
持っていなければなりません。ディレクトリは、空でなければなりませ
ん。
以下のように入力し、ディレクトリのアクセス権が正しく設定されている
ことを確認します。
$ ls -l
ディレクトリのアクセス権は、以下のように設定されます。
redbrick:
group:
other:
4.
rwx
-----
(read, write, execute)
(none)
(none)
上記のように設定されていない場合は、redbrick ユーザの umask が 077 に
設定されていることを確認し、システムの chmod コマンドを使ってアクセ
ス権を正しく設定してください。
rb_creator ユーティリティを使用して、データベースを作成します。構文
については、5-4 ページ「データベース作成の構文」を参照してください。
指定したディレクトリが空でない場合、あるいは redbrick ユーザに必要な
Write 特権がない場合は、rb_creator がエラー メッセージを表示して終了
し、新規データベースは作成されません。これらの条件が満たされている
場合は、rb_creator がデータベースを初期化し、5-8 ページ図 5-1 に記載さ
れているデータベース システム ファイルを作成します。
警告 : Red Brick データベースをネットワーク ファイル サーバー (NFS) システム上
に作成することはできません。
♦
5-6 Administrator’s Guide
データベースの初期化
Windows
新しいデータベースを初期化する手順は、以下のとおりです。
1.
2.
redbrick ユーザとしてログインして、データベースを作成するディレクト
リの親ディレクトリに移動します。
データベース ディレクトリを作成します。
c:¥> mkdir <dirname>
<dirname>
3.
c:¥disk1¥<database> などのディレクトリのパス名
dbcreate ユーティリティを使用して、データベースを作成します。構文に
ついては、5-4 ページ「データベース作成の構文」を参照してください。
dbcreate がデータベースを初期化し、5-8 ページ図 5-1 に記載されている
データベース システム ファイルを作成します。
dbcreate ユーティリティを使用してデータベースを初期化する場合は、ドライブ名
も含めたデータベース ディレクトリの絶対パス名を指定します。例を示します。
c:¥> dbcreate -create -l AROMA -d c:¥disk1¥new_db
データベースのパス名は自動的に rbw.config ファイルに追加されます。このファイ
ルのデータベースの項目を編集したときは、必ず各データベースへの絶対パス名を
確認してください。
rbw.config ファイルに同じ物理データベースを参照する 2 つの論理データベース名
がある場合、2 つのエントリのパス名は同一でなければなりません。
♦
データベースの作成
5-7
データベース論理名の設定
rb_creator (UNIX)、または dbcreate (Windows) を実行すると、データベース サーバ
によってデータベースが初期化され、以下のデータベース システム ファイルが作
成されます。
図 5-1
データベース システム ファイル
システム ファイル
内容
RB_DEFAULT_IDX
システム テーブル
RB_DEFAULT_LOCKS
データベース ロックとテーブル ロックに関するシ
ステム情報
RB_DEFAULT_INDEXES
インデックスに関するシステム情報
RB_DEFAULT_SEGMENTS
セグメントに関するシステム情報
RB_DEFAULT_TABLES
テーブルに関するシステム情報
ヒント：ロード操作に関する情報を格納するデータベース システム ファイル
RB_DEFAULT_LOADINFO は、ロード操作を実行するまで作成されません。
データベース論理名の設定
新規データベースを作成後、rbw.config ファイルでデータベース論理名を割り当て
ます。ユーザは、このデータベース論理名でデータベースにアクセスします。デー
タベース論理名は最大 128 文字です。
データベース論理名は、以下の手順で割り当てます。
1.
rbw.config ファイルを編集します。編集する項目名は「Logical
database name mappings」です。実際のサイトではデータベース名が
ファイルの記述とは異なりますが、通常は以下のようになっています。
# Logical database name mappings
#
DB AROMA <dirname>
<dirname> は、UNIX では /disk1/aroma/db、Windows では
c:¥disk1¥aroma¥db というように、絶対パス名と同じです。
5-8 Administrator’s Guide
DBA アカウント パスワードの変更
2.
Logical database name mappings のヘッダの後に以下のような形式
の行を挿入します。
DB <database_name> <dirname>
Windows
<database_name>
新規データベースのデータベース論理名です。大
文字と小文字の区別はありません ( 大文字のみ、小
文字のみ、両方の組み合わせのいずれでもアクセ
スできます )。
<dirname>
データベース ディレクトリへの絶対パスで、UNIX
では、大文字と小文字を区別します。
dbcreate の -l コマンド ライン オプションを使うと、データベースの作成時に、デー
タベース論理名が rbw.config ファイルに自動的に追加されます。♦
例
<pathname> ディレクトリ ( たとえば、UNIX では /disk1/new_db、Windows では
c:¥disk1¥new_db) にある NEW_DB という新規データベースを追加するには、
rbw.config ファイルに以下の行を追加します。
DB
NEW_DB <pathname>
追加前のファイル エントリが、AROMA データベースだけであったとすると、追加
後の内容は以下のようになります。
# Logical database name mappings
#
DB AROMA <pathname>
DB NEW_DB <pathname>
DBA アカウント パスワードの変更
システム レベルでの新規データベース ファイルの所有者は、redbrick ユーザです。
データベース レベルでは、system というデータベース ユーザ アカウント名で新規
データベースが作成されます。このアカウントのデフォルトのパスワードは、
manager です。このユーザ アカウントは、DBA システム ロールの権限および特権
を持つ DBA システム ロールのメンバーです。新規データベースの作成後は、デ
フォルトのパスワード manager を変更し、パスワードのセキュリティを確保してく
ださい。
データベースの作成
5-9
DBA アカウント パスワードの変更
デフォルトのパスワードは、以下の手順で変更します。
1.
OS のプロンプトで以下のコマンドを入力し、RISQL エントリ ツールを起
動します。
risql -d <logical_database_name> system manager
<logical_database_name>
2.
新しいデータベースの名前
パスワードを変更します。
RISQL> grant connect to system with <new_password>;
パスワードには、で説明されている有効なデータベース識別子かリテラルを指定で
きます。
Windows
データベースの作成時に、dbcreate のパラメータ -u およびパラメータ -p を指定す
ると、system アカウントのパスワードを変更できます。♦
例
以下の例は、ユーザ system のパスワードをデフォルトのパスワード manager から
新しいパスワード mysecret に変更する方法を示します。
$ risql -d new_db system manager
(C) Copyright IBM Corp. 1991-2002. All rights reserved.
RISQL Reporter Version 06.20.0000(0)
RISQL> grant connect to system with mysecret;
RISQL> quit;
$
UNIX
♦
c:¥> risql -d new_db system manager
(C) Copyright IBM Corp. 1991-2002. All rights reserved.
RISQL Reporter Version 06.20.0000(0)
RISQL> grant connect to system with mysecret;
RISQL> quit;
c:¥>
Windows
♦
5-10 Administrator’s Guide
データベース オブジェクトの作成
データベース オブジェクトの作成
rb_creator (UNIX) または dbcreate (Windows) でデータベースを作成後、データベー
ス スキーマを構成するオブジェクト ( セグメント、ユーザ テーブル、追加インデッ
クスなど ) を作成します。各タイプのオブジェクトは、SQL CREATE 文で作成しま
す。
複雑な CREATE 文を入力するには、テキスト ファイルに CREATE 文を記述して、
RISQL エントリ ツール、または RISQL Reporter の入力スクリプトとして使用しま
す。テーブル構造が簡単なものであれば、RISQL エントリ ツールのコマンド ライ
ンから対話形式で入力するか、SQL 文をサポートするほかのツールで入力できま
す。管理者ツールの Manage Tables 機能を使うと簡単にテーブルを作成でき、SQL
文が自動的に作成されます。
スクリプト ファイルの使用方法の詳細については、『RISQL Entry Tool and RISQL
Reporter User's Guide』を参照してください。また、CREATE TABLE 文の作成方法に
関する詳細については、5-21 ページ「テーブルの作成」を参照してください。
データベース オブジェクトは以下の手順で作成します。
1.
2.
3.
4.
5.
6.
7.
一部またはすべてのテーブルとインデックスに名前付きセグメントを使用
する場合は、必要な CREATE SEGMENT 文を作成します。
ディメンジョン ( 参照先 ) テーブルを作成する CREATE TABLE 文を作成し
ます。パラメータ MAXROWS PER SEGMENT とパラメータ
MAXSEGMENTS を使い、各テーブルの最大行数を指定してください。
ファクト ( 参照元 ) テーブルを作成する CREATE TABLE 文を作成します。
5-33 ページ「インデックスの作成」に従って、選択した STAR インデック
ス、B-TREE インデックス、または TARGET インデックスを作成する
CREATE INDEX 文を作成します。
スクリプト ファイルの CREATE 文を書き換えた場合は、RISQL エントリ
ツールを起動し、スクリプト ファイルを読み込んで実行します。
CREATE VIEW 文によってビューを作成すると、使いやすさとセキュリ
ティが高まり、システムが集約テーブルを考慮するようになります。
繰り返し使用するクエリの一部を略記したり処理操作を共有するためにマ
クロを使用する場合は、任意の CREATE MACRO 文を作成します。
事前計算ビューと階層構造を作成すると、『IBM Red Brick Vista User’s
Guide』に説明があるとおり、集約クエリの性能が向上します。
SQL 文の詳細な構文については、『SQL Reference Guide』を参照してください。
データベースの作成
5-11
セグメントの作成
セグメントの作成
CREATE SEGMENT 文は、1 つ以上の PSU で構成される格納セグメントを作成しま
す。1 つのセグメントには、1 つのテーブルまたはインデックスが格納されます。
名前付きセグメントを使用する場合は、テーブルやインデックスの作成前に定義し
ておく必要があります。セグメントの作成例については、5-42 ページ「データ セグ
メントとインデックス セグメントの作成」を参照してください。
セグメントを作成すると、Red Brick Warehouse によって、各 PSU の INITSIZE 値が
割り当てられます。第 1 PSU の INITSIZE は 16KB (2 ブロック ) 以上でなければなり
ません。第 2 PSU 以降の INITSIZE は 0KB 以上の値であれば何でもかまいません。
データが PSU に収まらなくなると、その PSU の MAXSIZE に達するまで、格納領域
が EXTENDSIZE ずつ拡張されます。PSU が MAXSIZE に達すると、次の PSU に格
納領域が割り当てられます。その場合、セグメント作成時に INITSIZE として割り
当てられたブロック数が使われます。CREATE SEGMENT 文の構文については、
『SQL Reference Guide』を参照してください。
PSU に対して INITSIZE を大きい値に設定すると、その INITSIZE 領域の割り当てが
行われるため、セグメントの作成に時間がかかります。ただし、INITSIZE を小さい
値に設定した場合よりロードは高速になります。
セグメントは、ALTER SEGMENT 文によって必要に応じていつでも変更できます。
セグメントの変更に関する詳細については、9-42 ページ「セグメントの変更」を参
照してください。
5-12 Administrator’s Guide
セグメント化の規則
セグメント化の規則
セグメントには以下の規則があります。
■
■
■
■
■
名前付きセグメントは、CREATE SEGMENT 文で作成します。CREATE
TABLE 文または CREATE INDEX 文に名前付きセグメントを指定しなかっ
た場合は、デフォルト セグメントが自動的に作成されます。デフォルト
セグメントの特性は、rbw.config ファイルのパラメータに定義されていま
す。
デフォルト セグメントのデフォルトのロケーションは、データベース
ディレクトリです。複数のデータベースを使用し、データベースごとに異
なるデフォルト ディレクトリを指定する場合は、rbw.config ファイルの
DEFAULT_DATA_SEGMENT や DEFAULT_INDEX_SEGMENT エントリに設
定するのではなく、SET コマンドを使用します。
テーブルおよびテーブルのプライマリ キー インデックスに名前付きセグ
メントを割り当てるには、CREATE TABLE 文を使用します。ユーザ作成の
インデックスに名前付きセグメントを割り当てるには、CREATE INDEX 文
を使用します。
データ値に基づくか、ハッシュのアルゴリズムにより、1 つのテーブルを
複数のセグメントに格納することができます
それぞれの TARGET インデックスおよび B-TREE インデックスは、以下の
いずれかの方法で、複数のセグメントに分散して格納できます。
■ インデックスの先頭列の値の範囲を基準にして分散
Red Brick サーバには、インデックスのこのようなセグメント化を定義
するためのさまざまな SQL 句があります。これらの SQL 句の一覧に
ついては、5-15 ページ図 5-2 を参照してください。
■ テーブルのセグメント化に使用されるのと同じ列値を使用して分散
セグメント化の基準列がインデックスの一部である必要はありませ
ん。ただし、1 つのインデックス セグメントはそれぞれのテーブル セ
グメントに対応しています。このセグメント化を定義するには、
CREATE INDEX 文で SEGMENT LOCAL 句を使います。このインデッ
クスをローカル インデックスと呼びます。
ローカル インデックスは、定期的に更新されるデータの TARGETjoin
処理を行うときによく使われますが、STAR インデックスには適用さ
れません。ローカル インデックスの作成例については、5-53 ページ
「ローカル TARGET インデックスの作成」を参照してください。
データベースの作成 5-13
セグメント化の規則
■
■
■
■
■
5-14 Administrator’s Guide
それぞれの STAR インデックスは、以下のいずれかの方法で、複数のセグ
メントに分散して格納できます。
■ 各セグメントに含まれるエントリの数がだいたい同じになる、セグメ
ント間への連続した分散
このラウンドロビン型のセグメント化が定義されるのは、複数のセグ
メント名を指定しているが、CREATE STAR INDEX 文に対して 3 つの
SEGMENT 句 (5-15 ページ図 5-2 を参照 ) のいずれも指定していない場
合です。
■ インデックスの先頭列がテーブルのセグメント化の基準となる列であ
る場合に、インデックスの先頭列の値の範囲を基準に分散
STAR インデックスのインデックス エントリは、列値ではなく参照先
の列の内部格納ロケーション ( 行 ID) です。したがって、STAR イン
デックスのセグメント範囲を定義するには、行 ID を指定します。
STAR インデックスをそのファクト テーブルと同じようにセグメント
化するには、CREATE STAR INDEX 文で SEGMENT LIKE DATA 句を指
定します。
STAR インデックスのこのセグメント化を定義するためのさまざまな
SQL 句の詳細については、5-15 ページ図 5-2 を参照してください。
STAR インデックスの構造の詳細については、5-16 ページ「STAR イ
ンデックスのセグメント化」を参照してください。
セグメントは、複数の PSU にまたがるように設定できます。
範囲を基準にしてセグメント化した場合、セグメント境界を修正するに
は、既存セグメント範囲の上限または下限でセグメントをアタッチするか
または切り離します。ただし、既存セグメント範囲の内部に新規セグメン
トを挿入することはできません。つまり、範囲を修正する場合は既存の境
界値を使う必要があります。
特定のセグメントの範囲を変更するには、ALTER SEGMENT 文を使用しま
す。そのセグメントにすでに存在する行を変更後の範囲の中にすべて含め
るか、または、変更後の範囲をそのセグメントに隣接していない範囲に移
動することができます。
セグメント間でデータ移動が発生する場合は、範囲の変更やセグメントの
アタッチはできません。インデックス セグメントの場合、範囲変更または
アタッチ処理を続行できますが、インデックスは無効になります。
セグメント化の方法
セグメント化の方法
以下の表に、データとインデックスを複数セグメントに格納する方法と、各セグメ
ント化の方法を指定するキーワードを示します。テーブルまたはインデックスをセ
グメント化するための各方法を使う状況については、4-19 ページ「セグメント化の
方法の決定」を参照してください。
図 5-2
セグメント定義と SQL のキーワード
セグメントの
内容
セグメント化の
基準
CREATE TABLE
または CREATE
INDEX の
キーワード
行データ
セグメント化の基
準列のデータ値
SEGMENT BY
VALUES OF
RANGE
(<literal>:<literal>)
ハッシュ
SEGMENT BY
HASH
ハッシュによるセグメ
ントのアタッチは不可
セグメント全体で
均等 (Red Brick
Warehouse によって
範囲が計算される )
なし ( デフォルト ) なし (Red Brick
Warehouse によって新
しいセグメントの範囲
が計算される )
STAR インデックス
のセグメント化列
を含む参照先テー
ブルの行数
SEGMENT BY
REFERENCES OF
RANGE
(<rownum>:<rownum>)
STAR インデックス
のセグメント化列
を含む参照先テー
ブルの行 ID
SEGMENT LIKE
REFERENCED
TABLE
RANGE
(<rowID>:<rowID>)
データと同じ値
SEGMENT LIKE
DATA
RANGE LIKE
SEGMENT
プライマリ イン
デックスの先頭列
のデータ値
SEGMENT BY
VALUES OF
RANGE
(<literal>:<literal>)
SEGMENT LIKE
DATA
RANGE
(<literal>:<literal>)
STAR
インデックス
プライマリ
インデックス
ALTER SEGMENT
ATTACH の
キーワード
データベースの作成 5-15
STAR インデックスのセグメント化
図 5-2
セグメント定義と SQL のキーワード
セグメントの
内容
セグメント化の
基準
CREATE TABLE
または CREATE
INDEX の
キーワード
TARGET
インデックス
インデックス列の
値
SEGMENT BY
VALUES OF
RANGE
(<literal>:<literal>)
SEGMENT LIKE
DATA
RANGE
(<literal>:<literal>)
データと同じ値
SEGMENT LOCAL
RANGE LIKE
SEGMENT
最初の ( 先頭 ) イン
デックス列の値
SEGMENT BY
VALUES OF
RANGE
(<literal>:<literal>)
SEGMENT LIKE
DATA
RANGE
(<literal>:<literal>)
SEGMENT LOCAL
RANGE LIKE
SEGMENT
B-TREE
インデックス
データと同じ値
ALTER SEGMENT
ATTACH の
キーワード
STAR インデックスのセグメント化
STAR インデックスをセグメント化する場合、基準として使えるのはその先頭列の
値だけです。STAR インデックスの値はディメンジョン テーブルの行 ID なので、
STAR インデックスのセグメント範囲はこの行 ID によって定義されます。行 ID は、
セグメント名、およびディメンジョン テーブルのデータの行番号で構成されます。
ディメンジョン テーブルがセグメント化されていない場合は、CREATE INDEX 文
の RANGE 句で行番号のみを指定します。
行番号は、行がテーブルにロードまたは挿入されるときに Red Brick Warehouse に
よって割り当てられる識別子です。新規に作成されたテーブルに VARCHAR 列がな
い場合、行番号は順に割り当てられます。したがって、行番号はその行の値に対応
しているとは限りません。対応させるには、ディメンジョン テーブルにロードする
値を順序正しく並べ、かつ、範囲に合致させる必要があります。
CREATE STAR INDEX 文で以下のいずれかの句を使って、セグメント範囲を指定し
ます。
5-16 Administrator’s Guide
STAR インデックスのセグメント化
■
■
■
SEGMENT LIKE DATA 句 - STAR インデックスをそのファクト テーブルと
まったく同じようにセグメント化する場合
先頭のディメンジョン テーブルからプライマリ キーを選択するクエリを
実行し、行が予想どおりの順にロードされているか調べます。詳細につい
ては、5-52 ページ「STAR インデックスをファクト テーブルと同じように
セグメント化するには」を参照してください。
SEGMENT BY REFERENCES OF 句および RANGES (<rownum:rownum>) 句
- ディメンジョン テーブルがセグメント化されていない場合
先頭のディメンジョン テーブルからプライマリ キー、RBW_ROWNUM
シュード列、および RBW_SEGNAME シュード列 ( 任意 ) を選択するクエ
リを実行します。手順 5-50 ページ「先頭のディメンジョン テーブルの行
ID の範囲を基準にして STAR インデックスをセグメント化するには」には
このクエリの例が含まれています。このクエリの実行結果を使って、以下
の作業を実行します。
■ 行が予想どおりの順にロードされたか調べます。
■ STAR インデックスをセグメント化するときに使用する行番号または
行 ID を取得します。各セグメントには、RANGES 句で指定する範囲
開始値は含まれますが、範囲終了値は含まれません。
シュード列の詳細については、9-36 ページ「シュード列」を参照してくだ
さい。
SEGMENT LIKE REFERENCED TABLE 句 - ディメンジョン テーブルがセグ
メント化されている場合
一般的な STAR スキーマでは、ファクト テーブルは Period ディメンジョン テーブ
ルのキー値を基準にしてセグメント化されます。また、STAR インデックスは
Period ディメンジョン テーブルの対応する行 ID を基準にしてセグメント化されま
す。セグメント化の 1 つの方法は、ファクト テーブルのセグメントを 1 つと、
Period テーブルの連続する行の各グループに対して STAR インデックス セグメント
を 1 つ設定することです。Period テーブルには、1 四半期に対する日付が格納され
ています。図 5-3 にこのセグメント化の方法を示します。
図 5-3 は、ファクト テーブル、ディメンジョン テーブル、および STAR インデック
スの先頭部分を示します。
■
左はファクト テーブルであり、perkey 列を基準にしてセグメント化されて
います。各セグメントには、1 四半期分のデータが格納されています。先
頭のセグメントには、perkey 値 01-01-00 ∼ 03-31-00 に対する行が格
納されています。2 番めのセグメントには、perkey 値 04-01-00 ∼ 0630-00 に対する行が格納されています ( 以下同様 )。
データベースの作成 5-17
STAR インデックスのセグメント化
図 5-3
STAR インデックス
セグメント
行 ID
rbw_rownum segname:rownum
ファクト テーブル
セグメント
ディメンジョン
テーブル
perkey
01-01-
perkey
01-01-00
0
0
04-01-
04-01-00
90
90
07-01-
07-01-00
181
181
セグメント化の基準となる列
■
■
STAR
インデックス
セグメントの
内容
先頭列
中央は Period ディメンジョン テーブルです。このテーブルの perkey 列は、
ファクト テーブルのセグメントを作成するときに使われます。perkey 列に
は、各日付に対する行があります。ただし説明を簡単にするため、図 5-3
では各セグメントの開始範囲を定義する値を 3 つしか示していません。対
応する rbw_rownum は、STAR インデックスのセグメントを作成するとき
に使われます。詳細については、5-50 ページ「STAR インデックスの作成」
を参照してください。
右は STAR インデックスです。このインデックスの先頭列は、Period ディ
メンジョン テーブルの perkey 列です。このディメンジョン テーブルの先
頭の perkey 値である 01-01-00 の行番号は 0 です。また、このディメンジョ
ン テーブルはセグメント default_segment_15 にあります。したがって、先
頭の STAR インデックス エントリの行 ID の値は
default_segment_15:0 です。同様に、参照先テーブルの perkey 値 0701-00 の行番号は 181 であり、この perkey に対する STAR インデックス エ
ントリは default_segment_15:181 です。
STAR インデックスをそのファクト テーブルと同じようにセグメント化した場合、
ファクト テーブルの対応するセグメントを使用することで、管理作業を迅速に実行
できます。詳細については、4-22 ページ「定期的にデータを更新するデータベース
の設計」および 9-56 ページ「定期的に更新されるデータベースのメンテナンス方
法」を参照してください。
5-18 Administrator’s Guide
セグメントの作成と削除および部分的に利用可能なテーブルへのクエリ
セグメントの作成と削除および部分的に利用可能な
テーブルへのクエリ
セグメントの作成と削除の動作、および部分的に利用可能なテーブルに対するクエ
リの動作は、rbw.config ファイルのオプション設定によって全セッションに設定で
きます。現在のセッションについてこれらのオプション設定を上書きするには、コ
マンド行で SET コマンドを入力します。
デフォルト セグメントのロケーション
行データとインデックスのデフォルト セグメント (CREATE SEGMENT 文で明示的
に作成されないセグメント ) のロケーションをそれぞれ指定できます。
すべてのセッションについて、データとインデックスのデフォルト セグメントのデ
フォルト ディレクトリを設定するには、rbw.config ファイルに以下の形式のコマン
ドを入力します。
OPTION DEFAULT_DATA_SEGMENT <dir_path>
OPTION DEFAULT_INDEX_SEGMENT <dir_path>
対応する SQL SET 文は、以下の形式で指定します。
SET DEFAULT DATA SEGMENT STORAGE PATH ‘<dir_path ＞＋ ’;
SET DEFAULT INDEX SEGMENT STORAGE PATH ‘<dir_path>’;
<dir_path>
行データまたはインデックスのデフォルト セグメントを格納するディ
レクトリのパスを指定します。
デフォルト ディレクトリを指定しないと、rbw.config ファイルまたは
環境変数 RB_PATH に設定したデータベース ディレクトリに、すべて
のデフォルト セグメントが格納されます。
例
以下に、データおよびインデックスのデフォルト セグメントにデフォルト ディレ
クトリを指定する例を示します。
データベースの作成 5-19
セグメントの作成と削除および部分的に利用可能なテーブルへのクエリ
UNIX
rbw.config ファイル エントリ :
OPTION DEFAULT_DATA_SEGMENT /dsk1/dsegs
OPTION DEFAULT_INDEX_SEGMENT /dsk1/ixsegs
SET コマンド :
set default data segment storage path 'dsk1/dsegs';
set default index segment storage path 'dsk1/ixsegs';
♦
Windows
rbw.config ファイル エントリ :
OPTION DEFAULT_DATA_SEGMENT c:¥dsk1¥dsegs
OPTION DEFAULT_INDEX_SE
GMENT c:¥dsk1¥ixsegs
SET コマンド :
set default data segment storage path 'c:¥dsk1¥dsegs';
set default index segment storage path 'c:¥dsk1¥ixsegs';
♦
セグメントの削除動作
名前付きセグメントに格納されているテーブルやインデックスを削除した場合に、
そのセグメントも削除するかを指定できます ( デフォルト セグメントは、必ず削除
されます )。
すべてのセッションについて、名前付きセグメントの削除動作を指定するには、以
下の形式による設定を rbw.config ファイルに記述します。
OPTION SEGMENTS <action>
対応する SQL SET 文の形式は以下のようになります。
SET SEGMENTS <action>;
<action>
アクションには、以下を指定できます。
■ キーワード KEEP - セグメントからテーブルやインデックスを削除した
後も、そのセグメントを残しておき、再使用できるように指定します。
そのセグメントは、ほかのテーブルやインデックスに再使用で
きます。KEEP は、名前付きセグメントのデフォルト動作です。
■ キーワード DROP - セグメントからテーブルやインデックスを削
除すると同時に、そのセグメントも削除することを指定しま
す。
5-20 Administrator’s Guide
テーブルの作成
ヒント：KEEP を指定した場合、削除するテーブルに破損したセグメントがある
と、デフォルト セグメントかユーザ定義セグメントかを問わず、破損したセグメン
トを切り離し、削除するまではテーブルを削除することができません。
例
全セッションについて、名前付きセグメントの削除動作を指定するには、以下の構
文による rbw.config ファイル エントリを実行します。
OPTION SEGMENTS DROP
特定のセッションについて、名前付きセグメントの削除動作を指定するには、以下
の構文による SET コマンドを実行します。
set segments drop;
テーブルの作成
ユーザ テーブルを定義するには、CREATE TABLE 文に、テーブル名、列の記述、
プライマリ キー定義、フォーリン キー定義、参照整合性に関する設定、セグメン
ト識別子 MAXSEGMENTS と MAXROWS PER SEGMENT の値 (STAR インデックス
に関わるテーブルの場合 ) を指定します。
テーブルは、ALTER TABLE 文によっていつでも変更できます。テーブルの変更方
法については、9-75 ページ「テーブルの変更」を参照してください。データ型の詳
細については、
『SQL Reference Guide』を参照してください。VARCHAR 列のフィル
ファクタの指定に関する詳細については、5-24 ページ「VARCHAR 列フィル ファク
タの設定」および『SQL Reference Guide』を参照してください。
テーブルの作成には、以下の規則が適用されます。
■
■
ほかのテーブルからフォーリン キー参照されるテーブルは、参照元テーブ
ルより前に作成しなければなりません。
アウトボード テーブルは、それを参照するどのテーブルよりも前に作成し
なければなりません。
データベースの作成 5-21
MAXSEGMENTS オプションと MAXROWS PER SEGMENT オプションの設定
MAXSEGMENTS オプションと MAXROWS PER
SEGMENT オプションの設定
テーブルのセグメントの最大セグメント数と最大行数を、そのテーブルの
MAXSEGMENTS および MAXROWS PER SEGMENT の値として指定するようことを
お勧めします。これらの値は、ディメンジョン テーブルの最大行数に対応できる
STAR インデックスを作成するために使用されます。参照先テーブルの MAXROWS
PER SEGMENT 値が指定されていないと、STAR インデックスの作成はエラーにな
ります。
ディメンジョン テーブルの現在 ( または見積り ) のサイズより大きな値を
MAXSEGMENTS と MAXROWS PER SEGMENT に設定すると、作成される STAR イ
ンデックスが必要以上に大きくなります。MAXSEGMENTS および MAXROWS PER
SEGMENT にさまざまな値を使用して、4-27 ページ「インデックス サイズの見積
り」に示された計算を実行し、このパラメータが STAR インデックス サイズに及ぼ
す効果を確認できます。
MAXSEGMENTS と MAXROWS PER SEGMENT の値は、STAR インデックスのセグ
メント化や、参照整合性を維持する TMU の Automatic Row Generation オプションの
検証にも必要です。
MAXROWS PER SEGMENT の上限は VARCHAR 列のフィル ファクタの設定によっ
て変化します。フィル ファクタの設定値が低すぎると、上限も低くなり、すぐに限
度に到達してしまう原因になります。VARCHAR 列が含まれるテーブルに行を挿入
しようとして、セグメントの最大数または行数に達したというエラー メッセージが
出た場合は、MAXROWS PER SEGMENT の値を調整する前に、フィル ファクタが
正しく設定されているかどうか確認してください。詳細については、5-24 ページ
「VARCHAR 列フィル ファクタの設定」を参照してください。
プライマリ キー制約とフォーリン キー制約の命名
制約名は、プライマリ キーまたはフォーリン キーに関連付けられた論理名で、
CREATE TABLE 文、または ALTER TABLE 文のキーワード CONSTRAINT を使用し
て指定します。複数の列からなるフォーリン キー参照では、STAR インデックスで
複数の列からなるフォーリン キーが参照されている場合に、制約名が必要となりま
す。1 つの列からなるフォーリン キーおよびプライマリ キーの制約名はオプション
ですが、意味のある制約名を設定すると、ほかのユーザが CREATE TABLE 文の内
容を理解しやすくなります。制約名は、RBW_RELATIONSHIPS システム テーブ
ルおよび RBW_CONSTRAINTS システム テーブルに格納されます。制約名を指定
しないと、デフォルト名が割り当てられます。
CREATE TABLE 文のキーワード CONSTRAINT の詳細については、『SQL Reference
Guide』を参照してください。
5-22 Administrator’s Guide
ON DELETE による参照整合性の維持
ON DELETE による参照整合性の維持
削除操作での参照整合性の維持には、関連するテーブルのテーブル作成と削除動作
を考慮する必要があります。参照整合性とは、テーブルの各フォーリン キー値が、
参照先テーブルのプライマリ キー値として存在するという関係を示します。
削除操作の参照整合性を維持する方法を指定するには、CREATE TABLE 文の
FOREIGN KEY 句で ON DELETE 句を使用します。ON DELETE 句には、以下のオプ
ションを指定できます。
オプション
説明
CASCADE
削除する行が、別のテーブルの 1 つまたは複数の行によって参
照される場合は、その行と参照元の行の両方が削除されます。
カスケード デリートはすべての関連テーブルに適用され、参照
整合性が維持されます。
NO ACTION
削除する行がほかのテーブルの行から参照される場合は、その
行と参照元の行のどちらも削除されません。これは、リストリ
クト デリートとも呼ばれます。ただし、ほかの行から参照され
ない行は削除されます (ON DELETE が設定されていない場合は、
この動作がデフォルトになります )。
削除操作の設定は、RBW_RELATIONSHIPS システム テーブルの DELACTION 列
に格納されます。
1 つの削除操作で、カスケード デリートとリストリクト デリートの両方を実行する
ことはできません。テーブルのコンプリート ファミリ内に NO ACTION の参照があ
る (2-40 ページ「データの削除とカスケード デリート」を参照 ) と、すべての行に
ついて NO ACTION が CASCADE より優先されます。つまり、すべての参照が NO
ACTION と同じになります。
削除を行う個々の DELETE 文で OVERRIDE REFCHECK 句を使用するとテーブルの
作成時に指定した ON DELETE の動作を無視できます。
警告 : 参照整合性チェックを省略すると削除操作の性能は向上しますが、
OVERRIDE REFCHECK を使う場合は、削除によって参照整合性の違反が発生しな
いことを確認するか、削除後に参照先テーブルの REORG 操作を実行して参照整合
性を確保してください。
フォーリン キーの ON DELETE 動作を変更する場合は、ALTER TABLE 文でその列
の指定内容を変更します。
データベースに最適な方法で参照整合性が維持されるよう、これらの削除動作を十
分に理解し、最も効果的な組み合わせを選択してください。
データベースの作成 5-23
VARCHAR 列フィル ファクタの設定
VARCHAR 列フィル ファクタの設定
VARCHAR 列フィル ファクタは、指定されたテーブルの可変長文字列の推定平均サ
イズを見積もります。最大列サイズに対する比率で指定され、デフォルトは 10% で
す。CREATE TABLE 文で定義します。クエリ性能を向上させるには、適切なフィル
ファクタを指定してください。
データベース サーバにおける VARCHAR フィル ファクタの
機能
データベース サーバでは、セグメントの行の認識やアクセスに行番号が使用されま
す。行番号に関する詳細は、9-36 ページ「シュード列」を参照してください。
データベース サーバは、以下に示す計算式 ( ブロックごとの行数を算出 ) に基づい
て、決まった数の行番号を各ブロックに割り当てます。VARCHAR 列が存在しない
テーブルの行は固定長です。1 ブロックの行数、または行番号の数は、ブロック サ
イズ (8KB) を行サイズで割って求めます。VARCHAR 列を含むテーブルについて
は、データベース サーバは以下の式を使って 1 ブロックあたりの行数を算出しま
す。
1 ブロックあたりの行数 = <block size> / <typical row size>
通常の行サイズは、すべての列サイズの合計を表わし、VARCHAR 列については
フィル ファクタの値を使用します。行サイズにおける VARCHAR フィル ファクタ
値の役割の詳細については、5-26 ページ「例 1: 1 ブロックあたりの行数に対する
VARCHAR フィル ファクタの影響」を参照してください。
5-24 Administrator’s Guide
VARCHAR 列フィル ファクタの設定
性能に対するフィル ファクタの影響
各ブロックに割り当てられる行番号の数は、フィル ファクタの設定によって変わり
ます。フィル ファクタを高く設定すると、1 ブロックあたりの行番号数は少なくな
り、低く設定すると、行番号数は多くなります。
フィル ファクタを高く設定しすぎると、各ブロックに割り当てられる行番号は少な
くなりすぎます。行番号が足りなくなると、データベース サーバは、ブロックに空
き容量があっても行を書き込まなくなります。各ブロックの未使用領域はテーブル
に必要な格納領域を圧迫し、また、多くのブロックにアクセスしなければならなく
なるため、アクセス速度も遅くなります。詳細は、5-27 ページ「例 2: VARCHAR
フィル ファクタ設定が高すぎる場合」で説明します。
フィル ファクタを低く設定しすぎると、実際に格納できる数よりも多い行番号が割
り当てられてしまいます。この場合、すべてのブロックがいっぱいになっても行番
号が割り当てられますが、使用されることはありません。未使用の行番号は、以下
のような問題を引き起こします。
■
TARGET インデックスの適合性の低下
TARGET インデックスは、ドメイン サイズによってテーブルの行番号のエ
ントリを取得します。未使用の行番号はインデックスにおいて無駄な領域
となり、その数が多すぎる場合には処理効率に影響を及ぼします。
ドメイン サイズに関する詳細については、『SQL Reference Guide』の
「CREATE INDEX」の節を参照してください。
■ MAXROWS PER SEGMENT の上限の早期到達
MAXROWS PER SEGMENT は、1 セグメントに対する最大行数から、テー
ブルの大きさを算出します。そのセグメントの最大行数にまで、未使用の
行番号がカウントされます。詳細は、5-28 ページ「例 3: VARCHAR フィル
ファクタ設定が低すぎる場合」で説明します。
パラメータ MAXROWS PER SEGMENT の詳細については、5-22 ページ
「MAXSEGMENTS オプションと MAXROWS PER SEGMENT オプションの
設定」を参照してください。
未使用の行番号が少数であれば、パフォーマンスに大きな影響を与えることはあり
ません。したがって、未使用領域があるよりも、未使用行番号があるほうが良いと
いえます。フィル ファクタを見積もる場合は、多めに見積もるよりも、少なめに見
積もるようにします。最適な処理効率を実現するには、フィル ファクタの設定をで
きるだけ的確に行います。
データベースの作成 5-25
VARCHAR 列フィル ファクタの設定
例 1: 1 ブロックあたりの行数に対する VARCHAR フィル ファクタの影響
この例は、データベース サーバがブロックごとの行番号数の算出に使用する標準行
サイズに、VARCHAR フィル ファクタが与える影響について説明したものです。
以下の CREATE TABLE 文を使用してテーブルを作成したとします。
CREATE TABLE supplier (
supkey integer,
type char(20),
name varchar (30),
street varchar (30),
city char (20),
state char (5)
zip char (10));
この文は WITH FILLFACTOR 句を指定していないため、name 列と street 列のフィ
ル ファクタは、ともにデフォルト値の 10 パーセントとなります。以下の式が示す
ように、データベース サーバはこのデフォルト値に基づいて標準行サイズを算出し
ます。
typical row size = length(SUPKEY) + length(TYPE) +
((fillfactor * length(NAME)) + 2-byte offset) +
((fillfactor * length(STREET)) + 2-byte offset) +
length(CITY) + length(STATE) + length(ZIP) +
1-byte null indicator
= 4 + 20 + ((10 percent * 30) + 2) +
((10 percent * 30) + 2)
+ 20 + 5 + 10 + 1
= 70 bytes
Supplier テーブルのブロックあたりの行数は、以下の式で算出されます。
rows per block = (block size - overhead) /
(typical row size + overhead)
= (8192 - 4) / (70 + 2)
= 113.72
5-26 Administrator’s Guide
VARCHAR 列フィル ファクタの設定
例 2: VARCHAR フィル ファクタ設定が高すぎる場合
この例では、VARCHAR フィル ファクタ設定が高すぎる場合に発生する可能性があ
る、各ブロックの未使用領域について説明します。
以下の CREATE TABLE 文を使用して、フィル ファクタ値を 90 に設定したテーブル
を作成したとします。
CREATE TABLE tab1 (
col1 integer,
col2 integer,
col3 char (18),
col4 varchar (100) WITH FILLFACTOR 90);
以下の式が示すように、サーバはこの値に基づいて、Tab1 テーブルの標準行サイズ
と、ブロックごとの行数を算出します。
typical row size = length(col1) + length(col2) + length(col3)
+ ((fillfactor * length(col4)) +
2-byte offset + 1-byte null indicator
= 4 + 4 + 18 + (90 percent * 100) + 2 + 1
= 119
rows per block = (block size - overhead) /
(typical row size + overhead)
= (8192 - 4) / (119 + 2)
= 67.67
VARCHAR 列の値の実サイズが 70 バイトの場合、各列はもっと小さな容量で十分
です。以下の式で、この例で必要な実サイズと、ブロックごとの未使用格納領域を
計算します。
actual row size = 4 + 4 + 18 + (70) + 2 + 1
= 99
actual space used = actual rowsize * rows-per-block
= 99 * 67
= 6633 bytes
以下の式は、ブロックごとの未使用領域を算出します。
wasted space = (blocksize - overhead) - actual space used
= 8188 - 6633
= 1555 bytes per block
データベースの作成 5-27
VARCHAR 列フィル ファクタの設定
例 3: VARCHAR フィル ファクタ設定が低すぎる場合
この例では、VARCHAR フィル ファクタ設定が低すぎる場合に発生する可能性があ
る、データ挿入障害について説明します。
5-26 ページ「例 1: 1 ブロックあたりの行数に対する VARCHAR フィル ファクタの影
響」の Supplier テーブルでは、フィル ファクタの値はデフォルトの 10% に設定さ
れていました。以下の式が示すように、サーバはこの値に基づいて、Supplier テー
ブルの標準行サイズと、ブロックごとの行数を算出します。
typical row size = length(SUPKEY) + length(TYPE) +
((fillfactor * length(NAME)) + 2-byte offset) +
((fillfactor * length(STREET)) + 2-byte offset) +
length(CITY) + length(STATE) + length(ZIP) +
1-byte null indicator
= 4 + 20 + ((10 percent * 30) + 2) +
((10 percent * 30) + 2 + 20 + 5 + 10 + 1
70 rows per block = (block size-overhead)/(typical row
size+overhead)
= (8192 - 4) / (70 + 2)
= 113.72
name 列の値の実標準サイズが 15 バイト、street 列の値の実サイズが 20 バイトの場
合、行の実サイズは 98 バイトになります。ブロックの空き領域は、ブロックごと
の行数の値が示す行数を格納する前になくなります。以下の式で、ブロックに 113
行挿入するには空き容量が不足していることがわかります。
actual row size = 4 + 20 + (15 + 2) + (20 + 2) + 20 + 5 + 10
= 98
actual number of rows per block = (blocksize - overhead ) /
(actual rowsize + overhead)
= (8192 - 4) / (98 + 2) = 81.88
つまり、最初のブロックに挿入できるのは 82 行だけです。データベース サーバは
次の行を 2 番めのブロックに挿入し、行番号は 113 が割り当てられます。行番号 83
∼ 112 の、31 の行番号は使用されません。
5-28 Administrator’s Guide
VARCHAR 列フィル ファクタの設定
この未使用の行番号は、MAXROWS PER SEGMENT で指定される値に算入されま
す。たとえば、MAXROWS PER SEGMENT の値に 2500 を指定し、フィル ファクタ
値にデフォルト値を使用した場合、挿入できるのは 1800 行だけです。以下に式を
示します。
CREATE TABLE supplier (
supkey integer,
type char(20),
name varchar (30),
street varchar (30),
city char (20),
state char (5)
zip char (10))
MAXROWS PER SEGMENT 2500;
number of blocks = MAXROWS PER SEGMENT / rows per block
= 2500 / 113
= 22.12 blocks
actual number rows insert = actual rows per block * num blocks
= 82 * 22
= 1804 行
1805 番めの行を挿入すると、以下のエラー メッセージが返ります。
** ERROR ** (654) 挿入先のセグメントが最大行数に達したため、テーブルにデータ
を挿入できないか、またはテーブル内のデータを更新できません。
データベースの作成 5-29
VARCHAR フィル ファクタの精度の監視
VARCHAR フィル ファクタの精度の監視
フィル ファクタ値の効果を測定するには、現在のフィル ファクタ値を取得し、
CHECK TABLE 文で VERBOSE オプションを指定します。必要に応じてフィル ファ
クタ値を修正します。
フィル ファクタの現在値の取得
VARCHAR 列のフィル ファクタの現在値と、テーブルの列すべての長さを取得する
には、RBW_COLUMNS システム テーブルを検索します。以下に例を示します。
RISQL> select name, type, length, fillfactor, nulls
> from rbw_columns where tname = 'SUPPLIER';
このクエリを実行すると、以下の結果が示すとおり、name 列と street 列のフィル
ファクタ値がデフォルトの 10% になります。
NAME
TYPE
SUPKEY
TYPE
NAME
STREET
CITY
STATE
ZIP
INTEGER
CHAR
VARCHAR
VARCHAR
CHAR
CHAR
CHAR
5-30 Administrator’s Guide
LENGTH FILLFA NULL
4
20
30
30
20
5
10
0
0
10
10
0
0
0
N
N
N
N
N
N
N
VARCHAR フィル ファクタの精度の監視
CHECK TABLE 文の VERBOSE オプション
CHECK TABLE 文で VERBOSE オプションを指定すると、以下に示すような、テー
ブルの関連セグメント統計が表示されます。
CHECK TABLE セグメント
説明
統計フィールド
storage reclen
VARCHAR 列のフィル ファクタに基づいて決定され
るレコード長 ( 単位 : バイト )。5-26 ページ「例 1: 1 ブ
ロックあたりの行数に対する VARCHAR フィル ファ
クタの影響」で説明した標準行サイズの計算式で算出
されます。
average reclen
セグメント内のレコード ( 行 ) の実際の平均サイズ
( 単位 : バイト )。
rows/block
VARCHAR 列のフィル ファクタに基づいて決定され
る、ブロックごとの割り当て行番号数。5-24 ページ
「データベース サーバにおける VARCHAR フィル ファ
クタの 機能」で説明する計算式で算出されます。
unused RowIDs
現在使用されていない行番号の数。
unusable freespace
割り当てられた行番号がすべて使用されており、標準
行サイズ以上の空き容量があるブロックの、空き容量
( 単位 : バイト )。フィル ファクタの値が実際の行サイ
ズよりも高く設定されている場合、0 以外の値が表示
されます。5-27 ページ「例 2: VARCHAR フィル ファク
タ設定が高すぎる場合」参照。
ヒント：storage reclen 値と、average reclen 値は、類似したサイズとなります。推
奨したとおりに、フィル ファクタを少なめに見積もった場合は、average reclen が
storage reclen より大きめになります。
以下の CHECK TABLE 文は、Supplier テーブルのセグメント統計を作成します。
5-26 ページ「例 1: 1 ブロックあたりの行数に対する VARCHAR フィル ファクタの影
響」を参照してください。
RISQL> CHECK TABLE supplier DIRECTORY '/qa/local/sct-pubs/
varchar-aroma/'
> VERBOSE;
INFORMATION
Table: 7 Segment: 13 is ok
No inconsistencies were detected.
データベースの作成 5-31
VARCHAR フィル ファクタの精度の監視
VERBOSE オプションは、キーワード DIRECTORY で指定されたディレクトリのセ
グメント統計を作成します。前述の CHECK TABLE 文の出力ファイル名は、テーブ
ル番号およびセグメント番号で始まります。以下に例を示します。
chk_7_13_rep.19990909.083256.25579
この CHECK TABLE 文は、Supplier テーブルに対し、以下のようなセグメント統計
を作成します。
Segment statistics:
active rows:9, deleted rows:0, total blocks:2, free blocks:0
rows/block:113, storage reclen:70, average reclen:98, indirect rows:0
max reclen:124, longest rec:106, min reclen:64, shortest rec:85
freespace:7289, unused RowIDs:104, unusable freespace:0
この例の出力データ値について説明します。
■
■
storage reclen 値は 70、average reclen 値は 98 です。このことから、
VARCHAR 列の平均実データ長は、フィル ファクタの値よりも長いことが
わかります。フィル ファクタを低く見積もりすぎた場合の問題点について
は、5-28 ページ「例 3: VARCHAR フィル ファクタ設定が低すぎる場合」
を参照してください。
freespace 値 は 7289 で、unused RowIDs 値は 104 です。未使用の空き容量
や行番号は、主に最後のブロックの終わりに置かれます。
CHECK TABLE 文の構文の詳細については、
『SQL Reference Guide』を参照してくだ
さい。
VARCHAR フィル ファクタの変更
以下のような場合、VARCHAR 列のフィル ファクタを調整します。
■
■
5-32 Administrator’s Guide
ディスク上の無駄な空き容量の削減
フィル ファクタを高く見積もりすぎた場合のディスク上の無駄な空き容量
の問題については、5-27 ページ「例 2: VARCHAR フィル ファクタ設定が
高すぎる場合」を参照してください。
ブロックごとの行番号数の削減
フィル ファクタを低く見積もりすぎた場合の TARGETjoin、および
INSERT 処理に及ぼす影響については、5-28 ページ「例 3: VARCHAR フィ
ル ファクタ設定が低すぎる場合」を参照してください。
インデックスの作成
VARCHAR 列のフィル ファクタを調整するには、ALTER TABLE CHANGE
FILLFACTOR 文を実行します。この SQL 文の実行結果は、ALTER TABLE 文で列が
追加、または削除されるまで、有効にはなりません。ALTER TABLE 文が実行され
ると、新しいフィル ファクタに従ってテーブル データが書き直されます。
たとえば、フィル ファクタを調整して、5-27 ページ「例 2: VARCHAR フィル ファ
クタ設定が高すぎる場合」で説明した Tab1 テーブルの未使用の空き容量を削減す
るとします。Tab1 テーブルの Col4 VARCHAR 列のフィル ファクタは現在 90 に設定
されています。しかし、実際の標準データ長は 70 バイトで、CREATE TABLE 文で
指定した VARCHAR(100) という定義の 70% しか使用していません。
実際の VARCHAR 列値に近い値にするには、フィル ファクタを 70 に設定します。
以下の ALTER TABLE 文は、Tab1 テーブルのフィル ファクタを変更します。
ALTER TABLE tab1 ALTER COLUMN col4
CHANGE FILLFACTOR 70;
ALTER TABLE 文の構文の詳細については、『SQL Reference Guide』を参照してくだ
さい。
インデックスの作成
IBM Red Brick Warehouse では、プライマリ キー列の B-TREE インデックスは、テー
ブルの作成時に自動的に作成されます。インデックスを追加作成すると、クエリの
性能を向上させることができます。2-6 ページ「インデックスの作成と検索効率」
で説明したように、Red Brick サーバには、STAR インデックス、TARGET インデッ
クス、および B-TREE インデックスという 3 つのインデックス技法が提供されてい
ます。
インデックスを追加定義するには、CREATE INDEX 文で、インデックスの種類、
テーブル名、列名、セグメント識別子、および並列インデックス作成に関する指示
を指定します。追加インデックス作成のタイミング、および各種のインデックスの
使用方法に関する詳細は、4-4 ページ「インデックスの追加」を参照してください。
定期的に更新されるデータベースのインデックスの作成例については、5-50 ページ
「STAR インデックスの作成」および 5-53 ページ「ローカル TARGET インデックス
の作成」を参照してください。CREATE INDEX 文に関する詳細については、『SQL
Reference Guide』を参照してください。
インデックスの作成中でも、ほかのユーザはテーブルを参照できますが、更新はで
きません。インデックスの作成中にデータベースのバックアップを行うと、作成中
のインデックスはバックアップされず、警告メッセージが表示されます。
データベースの作成 5-33
INDEX TEMPSPACE
データをテーブルにロードする前にインデックスを作成すると、インデックスは
データのロード時に作成されます。インデックスは、データをロードした後で作成
することもできます。インデックスはいつでも削除できます。
1 つのテーブルに対して複数のインデックスを作成する場合、まず遅延モードでイ
ンデックスを作成し、次に Table Management Utility (TMU) の REORG 操作を使って
全インデックスを同時に構築する方法をとれば、時間がかかりません。複数のイン
デックスを同時に作成できるのは、以下のいずれかの場合です。
■
■
TARGETJOIN に対するファクト テーブルのフォーリン キー列に TARGET
インデックスを複数作成する場合。
ディメンジョン テーブルのインデックスを削除した後。
INDEX TEMPSPACE
INDEX TEMPSPACE DIRECTORIES のロケーションは、空き領域の多いディスク
パーティションに設定し、オフライン ロードとインデックス作成の一時領域が不足
しないようにする必要があります。複数データベースの場合は、データベースごと
に違うロケーションを指定してください。
メモリ上の作業領域のサイズは、INDEX TEMPSPACE THRESHOLD の値によって決
まります。LOAD、REORG、オフライン LOAD 処理については、推奨の設定値で十
分ですが、システムによってはカスタマイズが必要な場合もあります。
複数インデックスを並列作成する CREATE INDEX 操作の場合は、この指定値が各
インデックスに分割されるため、メモリやスワップ領域が不足することがありま
す。インデックスの並列作成中にメモリ不足エラーが発生した場合は、INDEX
TEMPSPACE THRESHOLD の値を小さくするか、スワップ領域を大きくするか、並
列作成するインデックス数を減らしてください。
INDEX TEMPSPACE THRESHOLD の値を指定する目的は、IBM Red Brick Warehouse
を実行しているシステムがエラーを発生しない範囲で十分な領域を確保することで
す。しきい値が大きすぎると、メモリ不足により操作が失敗することがあります。
しきい値が小さすぎると、性能が低下する可能性があります。
パラメータ INDEX TEMPSPACE に関する詳細については、4-46 ページ「インデッ
クス作成に必要な一時領域の見積り」を参照してください。
5-34 Administrator’s Guide
並列インデックス
並列インデックス
UNIX
CREATE INDEX 文の並列インデックス作成機能によって、マルチプロセッサ ハー
ドウェアのプラットフォームで、複数のインデックスを同時に作成できます。これ
はマルチプロセッサ システムでの性能向上を図ったものですが、1 つの CREATE
INDEX 文で複数のインデックスを同時に作成する機能はどのシステムでも効率的で
す。
マルチプロセッサ システムでは、1 つの CREATE INDEX による複数のインデックス
を並列作成し、所要時間を短縮することができます。個別の CREATE 文でインデッ
クスを 1 つずつ作成するよりも、一般に効率的です。
ON ERROR 句は、複数のインデックスの作成中にエラーが発生した場合の処理を指
定します。インデックス作成をすべて中止する (ABORT) か、またはエラーの影響
を受けないインデックスの作成を続行する (CONTINUE) かのどちらかを指定できま
す。
1 つの CREATE INDEX 文で複数のインデックスを並列作成した後は、
RBW_TABLES または RBW_INDEXES システム テーブルの DATETIME 列を参照
し、すべてのインデックスが正常に作成されたことを確認してください。インデッ
クスの作成中は、インデックスごとに DATETIME 列に NULL が格納され、イン
デックスの作成が完了すると完了日時が更新されます。データベース サーバーがイ
ンデックスを正しく作成できないと、通常は RBW_INDEXES からインデックス エ
ントリが自動的に削除されます。CREATE 文の実行が完了した後も、DATETIME 列
の値が NULL の場合は、DROP INDEX 文を使って RBW_INDEXES からインデック
ス エントリを削除してください。♦
Windows
Windows では、CREATE INDEX 文によるインデックスの並列作成はできませんが、
CREATE INDEX DEFERRED 文の後に REORG コマンドを続けて、インデックス作
成を遅延させると、同じ結果が得られます。REORG コマンドの構文の詳細につい
ては、『Table Management Utility Reference Guide』を参照してください。♦
データベースの作成 5-35
インデックス フィル ファクタの設定
インデックス フィル ファクタの設定
インデックスのフィル ファクタは、ノードの作成時に、B-TREE インデックスの新
規ノードを充填する比率を指定します (B-TREE インデックスの各ノードは、ファイ
ル システムの 1 ブロックに相当します )。新規インデックス ノードが完全に充填さ
れていなければ、その後のインクリメンタル ロードでインデックス エントリを挿
入しても、ノード ( ブロック ) は分割されません。ノードを分割すると、インクリ
メンタル ロードが遅くなります。フィル ファクタを 100% 未満に設定して作成した
インデックスは格納領域の所要量が増えますが、インクリメンタル ロード、更新、
挿入が速くなります。
デフォルトのフィル ファクタは 100% です。テーブルおよびインデックスを初期
ロードし、インクリメンタル ロード、更新、挿入は行わず、クエリ処理にのみ使用
する場合は、100% が適切な値です。テーブルのデータが増加することが予想され
る場合は、インデックス ノードを分割せずにデータが挿入できるようにフィル
ファクタを設定します。
システム全体のデフォルトのフィル ファクタは、rbw.config ファイルで指定できま
す。インデックスごとにフィル ファクタを指定するには、CREATE INDEX または
ALTER INDEX 文を使用します。フィル ファクタのデフォルト値は 100% です。
ユーザが設定したフィル ファクタを TMU に使用させるには、LOAD DATA 文に
OPTIMIZE 句を指定します。OPTIMIZE 句を指定しないと、TMU は指定したフィル
ファクタを無効にするので 100% になります。
インデックスのサイズとフィル ファクタの関係の詳細については、4-28 ページ「イ
ンデックスのフィル ファクタ」を参照してください。
例
以下の図は、初期ロード時のフィル ファクタが 100% のインデックスと、66% のイ
ンデックスとを比較したものです。
100% に設定した場合は、各ノードが完全に充填されてから、新規ノードを使用し
ます。すべてのインデックス データが、3 つのリーフ ノード ( ブロック ) に格納さ
れます。図では、うち 2 つが完全に充填されており、3 番めもほぼ充填済みの状態
です。完全に充填されたノードにインデックス エントリを挿入する必要がある行
データが追加された場合は、ノードが分割されます。
同じインデックスについて、フィル ファクタを 66% に設定した場合は、必要な
ノード ( ブロック ) 数が 5 に増えますが、各インデックス ノードに未使用領域が残
るため、テーブルに追加する行データに対応できます。
5-36 Administrator’s Guide
インデックス フィル ファクタの設定
図 5-4
フィル ファクタとインデックス ノード
フィル ファクタ : 100%
フィル ファクタ : 66%
インデックスの
リーフ ノード 行データ
行データ
インデックスの
リーフ ノード
インデックスの
ルート ノート
インデックスの
ルート ノート
構文
すべてのセッションについて、システムのデフォルトのフィル ファクタを指定する
には、以下の構文を使用して、rbw.config ファイルに適切なコマンドを記述しま
す。
FILLFACTOR
PI
<x>
FILLFACTOR
STAR
<y>
FILLFACTOR
SI
<z>
データベースの作成 5-37
インデックス フィル ファクタの設定
FILLFACTOR PI <x>
すべてのプライマリ インデックスについて、システム全
体のデフォルト フィル ファクタを指定します。
FILLFACTOR STAR
<y>
すべての STAR インデックスについて、システム全体のデ
フォルト フィル ファクタを指定します。
FILLFACTOR SI <z>
STAR インデックス以外の追加インデックス (CREATE
INDEX 文で作成する STAR インデックス以外のインデッ
クス ) について、システム全体のデフォルト フィル ファ
クタを指定します。
<x>、<y>、<z>
充填比率を指定する 1 ∼ 100 の整数。デフォルト値は 100
です。
使用上の注意
ユーザが作成する任意のインデックスについて、フィル ファクタを設定するには、
インデックスの作成時に CREATE INDEX...WITH FILLFACTOR <x> を実行します。
自動的に作成されるインデックスについて、フィル ファクタを設定または変更する
には、RBW_INDEXES テーブルに格納されているインデックス名を指定した
ALTER INDEX...CHANGE FILLFACTOR <x> 文を実行します。
新規インデックスが作成された時のフィル ファクタは、自動的に作成されるイン
デックスについては rbw.config ファイルの設定値が使われ、ユーザが作成したイン
デックスについては CREATE INDEX 文または rbw.config ファイルの設定値が使われ
ます。フィル ファクタを指定しないと、100 が使用されます。使用されたフィル
ファクタは、RBW_INDEXES システム テーブルに格納されます。初期ロード中と
インクリメンタル ロード中に追加される新規ノードには、RBW_INDEXES に格納
されたフィル ファクタが使用されます。インデックスごとに、このフィル ファク
タを変更するには、ALTER INDEX 文を使用します。
TMU が自動的に作成するインデックス ( プライマリ キー インデックス、ならびに
ロード操作の前に CREATE INDEX 文で作成される B-TREE、STAR、TARGET の各
インデックス ) について、ユーザが指定したフィル ファクタを使用するには、
LOAD DATA 文に OPTIMIZE 句を指定してください。
任意のインデックスのフィル ファクタの確認
インデックスに使用されたフィル ファクタを確認するには、RBW_INDEXES シス
テム テーブルに対して以下のクエリを実行します。
select name, fillfactor
from rbw_indexes
where name = '<index_name>';
5-38 Administrator’s Guide
インデックス フィル ファクタの設定
重要 : 指定したフィル ファクタが実際に使用されるかは、TMU のオプティマイズ
モードの設定によります。
デフォルトのフィル ファクタを変更
デフォルトのフィル ファクタ ( どのインデックスについても 100%) を変更するかど
うかは、データベースのテーブルの行が増加するかどうかによります。行データが
増加する場合は、ノードの充填率を 100% 未満に下げて必要な領域が増えることと、
ロード性能の低下を考慮して判断します。
重要 : ここでは、予想されるインデックスの増加が均一であるとします。イン
デックスの末尾、あるいはセグメント化されたインデックスの新規セグメントで増
加が予想される場合は、デフォルトのフィル ファクタが最適となります。
各インデックス ノードにエントリがいくつ格納されるかを以下の式で計算すると、
フィル ファクタとインデックス サイズの関係がわかります。
Elements per index node =
fillfactor
8172
------------------------X -------------------------------100
keysize + 6
インデックス ノードのサイズは 8172 バイトで、ファイル システムの 1 ブロック
(8KB) から 20 バイトのオーバーヘッド分を減算した値に相当します。<keysize> は、
キー列のサイズに 6 バイトのアドレス分を加算した値です。
このため、フィル ファクタが小さいと、インデックス キーに使用できる最大サイ
ズも小さくなります。
例
50,000 行あるテーブルのキー サイズが 10 バイトであるとします。各種のフィル
ファクタのインデックスを格納するために必要な 8KB のブロックの数を計算するに
は、4-27 ページ「インデックス サイズの見積り」に示す計算式を使用します。以下
の表は、計算結果を示したものです。
フィル ファクタ
ノード当たりの
エレメント数
ブロック数
10
81
627
50
409
124
100
817
63
このテーブルを 1 回だけロードし、データを追加する予定がない場合は、最適な
フィル ファクタは 100 です。
データベースの作成 5-39
インデックス フィル ファクタの設定
初期サイズの 2 倍に行データが増加すると予想される場合は、フィル ファクタを 50
にするのが適切です。同様に、初期にロードするデータが全体の 10% の場合は、
フィル ファクタを 10% に設定します。
重要 : フィル ファクタを小さくすると、インデックスのサイズが非常に大きくな
り、クエリの性能を低下させることがあります。
インデックスのフィル ファクタの変更
フィル ファクタは、新規インデックス ノードの作成時にノードを充填する割合を
指定します。以下のような場合、インデックスのフィル ファクタを変更します。
■
■
ディスク上の無駄な空き容量の削減
各ノードの空き容量は、インデックスの作成時に必要な領域に影響しま
す。
インクリメンタル ロード、更新、挿入の各処理の効率向上
フィル ファクタは、完全に充填されたノードが分割される頻度に影響しま
す。
ALTER INDEX...CHANGE FILLFACTOR 文を使うと、新規ノードの作成時に使用す
るフィル ファクタを変更できます。充填済みインデックスについてフィル ファクタ
を変更しても、オプティマイズ モードのロード操作で作成された新規ノードを作成
するまでは適用されません。つまり、既存ノードの変更や再作成には使用されませ
ん。既存ノードを新しいフィル ファクタで再作成するには、フィル ファクタを変
更してから REORG によってインデックスを再編成するか、いったん削除してから
再作成してください。
5-40 Administrator’s Guide
定期的に更新されるデータベースの作成
定期的に更新されるデータベースの作成
定期的に更新されるデータベースの設計目標は、インデックスをデータと同じよう
にセグメント化し、インデックス セグメントをすばやくロール オフできるように
することです。管理が容易で停止時間を最小限に抑えた定期的に更新されるデータ
ベースを作成するには、日、週、月などの期間を基準にしてデータをセグメント化
します。
定期的に更新されるデータベースに複数のセグメントを作成する例を説明します。
この例は、フォーリン キーに対して STAR インデックスとローカルの TARGET イン
デックスが設定されている、シンプル スター スキーマです。これらのインデック
スはデータと同じ方法でセグメント化されます。
この例で使用するデータベースには、ディメンジョン ( 参照先 ) テーブルが 3 つ
(Period、Product、Market) とファクト ( 参照元 ) テーブルが 1 つ (Sales) 含まれてい
ます。Sales テーブルには過去 2 年間 (8 四半期 ) と当四半期の売上データが格納され
ています。
■
■
■
■
■
Sales テーブルのデータは、四半期ごとに個別の名前付きセグメントに格
納します。
当四半期の Sales データは、毎日更新されます。四半期末には、最も古い
四半期のデータがテーブルから削除され、当四半期のデータが 2 年間の履
歴データに加えられ、新しい当四半期が作成されます。
Sales テーブルには、このテーブルと同じ数のセグメントに格納された
ユーザ作成の STAR インデックスがあります。この STAR インデックスが
Sales テーブルのプライマリ キー インデックスとして機能するので、プラ
イマリ キー列に自動的に作成される B-TREE インデックスは削除されま
す。
Sales テーブルの各フォーリン キー (perkey、prodkey、mktkey) には、ロー
カルの TARGET インデックスが設定されています。ローカル インデック
スには以下のような利点があります。
■ Red Brick Warehouse では、ローカル インデックス セグメントとデータ
セグメントの正確な対応が認識されているので、データ セグメントを
ロール オフしたときにインデックス セグメントをすばやくロール オ
フできます。詳細については、9-57 ページ「データ セグメントおよび
インデックス セグメントのロールオフと再使用」を参照してくださ
い。
■ ローカル インデックスを設定すると、TARGETjoin 操作および
TARGETscan 操作の性能が向上します。詳細については、『Query
Performance Guide』を参照してください。
ディメンジョン テーブルのデータおよびインデックスは、すべてデフォル
ト セグメントに格納します。
データベースの作成 5-41
データ セグメントとインデックス セグメントの作成
■
Period テーブルには、DATE データ型のプライマリ キー (Perkey) がありま
す。
以下の図は、この例に使用する各テーブルを示したものです。
図 5-5
スキーマの例
Sales テーブル
Period テーブル
Perkey
Month
Year
Quarter
Tri
Product テーブル
Prodkey
Prod_desc
Brand
Size
Market テーブル
Perkey
Prodkey
Mktkey
Dollars
Weight
Mktkey
Market_desc
District
Region
以下の節では、この定期的に更新されるデータベースのサンプルに対するセグメン
ト、テーブル、およびインデックスを作成する方法について説明します。定期的に
更新されるデータベースを管理する方法の詳細については、9-56 ページを参照して
ください。
データ セグメントとインデックス セグメントの作成
セグメントを作成してから、セグメントを使用するテーブルとインデックスを作成
する必要があります。図 5-6、図 5-7、および図 5-7 の CREATE SEGMENT 文 におけ
るパス名は、Windows NT または Windows 2000 の場合の例です。UNIX の場合は、
パス名を記述するときに、Windows のような円記号ではなくスラッシュを使いま
す。以下に例を示します。
UNIX
create segment s_1q00
storage '/disk1/s1' maxsize 200,
storage '/disk1/s2' maxsize 200;
♦
5-42 Administrator’s Guide
データ セグメントとインデックス セグメントの作成
テーブルおよび各インデックス (s_max、star_max、target_per_max、
target_prod_max、および target_mkt_max) の最後のセグメントは空セグメントであ
り、セグメント範囲の上限のプレースホルダとなっています。セグメントがアタッ
チされると、その範囲は既存セグメント範囲と重なり、既存セグメントが検索さ
れ、新しい範囲内のデータが既存セグメントに含まれていないか検証されます。上
限にある空セグメントは、実際のデータが格納されているセグメントよりもすばや
く検索できます。このようなセグメントは必ずしも必要ではありませんが、空セグ
メントを設定すれば新規セグメントをよりすばやくアタッチできます。
データベースの作成 5-43
データ セグメントとインデックス セグメントの作成
Windows
図 5-6 は、Windows において Sales テーブルに対するデータ セグメントを作成する
方法を示したものです。
図 5-6
Windows における Sales テーブルのセグメント
CREATE SEGMENT 文
作成されたセグメント
含まれるファイル
create segment s_1q00
storage 'c:¥disk1¥s1' maxsize 200,
storage 'c:¥disk1¥s2' maxsize 200;
s_1q00
s1
s2
c:¥disk1
create segment s_2q00
storage 'g:¥disk2¥s1' maxsize 200,
storage 'g:¥disk2¥s2' maxsize 200;
s_2q00
s1
s2
g:¥disk2
create segment s_3q00
storage 'h:¥disk3¥s1' maxsize 200,
storage 'h:¥disk3¥s2' maxsize 200;
s_3q00
s1
s2
h:¥disk3
create segment s_4q00
storage 'i:¥disk4¥s1' maxsize 200,
storage 'i:¥disk4¥s2' maxsize 200;
s_4q00
s1
s2
i:¥disk4
create segment s_1q01
storage 'j:¥disk5¥s1' maxsize 200,
storage 'j:¥disk5¥s2' maxsize 200;
s_1q01
s1
s2
j:¥disk5
create segment s_2q01
storage 'k:¥disk6¥s1' maxsize 200,
storage 'k:¥disk6¥s2' maxsize 200;
s_2q01
s1
s2
k:¥disk6
create segment s_3q01
storage 'l:¥disk7¥s1' maxsize 200,
storage 'l:¥disk7¥s2' maxsize 200;
s_3q01
s1
s2
l:¥disk7
s_4q01
s1
s2
s3
m:¥disk8
s_1q02
s1
s2
s3
n:¥disk9
create segment s_4q01
storage 'm:¥disk8¥s1' maxsize 200,
storage 'm:¥disk8¥s2' maxsize 200,
storage 'm:¥disk8¥s3' maxsize 200;
create segment s_1q02
storage 'n:¥disk9¥s1' maxsize 200,
storage 'n:¥disk9¥s2' maxsize 200,
storage 'n:¥disk9¥s3' maxsize 200;
create segment s_max
storage 'o:¥disk10¥s_max' maxsize 16;
5-44 Administrator’s Guide
s_max
s_max
o:¥disk10
データ セグメントとインデックス セグメントの作成
図 5-7 は、Sales_star インデックスに対するインデックス セグメントを作成する方
法を示したものです。
図 5-7
Windows における Sales_star インデックスのセグメント
CREATE SEGMENT 文
作成されたセグメント
含まれるファイル
create segment star_1q00
storage 'c:¥disk1¥star1' maxsize 200,
storage 'c:¥disk1¥star2' maxsize 200;
star_1q00
star1
star2
1
c:¥disk1
create segment star_2q00
storage 'g:¥disk2¥star1' maxsize 200,
storage 'g:¥disk2¥star2' maxsize 200;
star_2q00
star1
star2
g:¥disk2
create segment star_3q00
storage 'h:¥disk3¥star1' maxsize 200,
storage 'h:¥disk3¥star2' maxsize 200;
star_3q00
star1
star2
h:¥disk3
create segment star_4q00
storage 'i:¥disk4¥star1' maxsize 200,
storage 'i:¥disk4¥star2' maxsize 200;
star_4q00
star1
star2
i:¥disk4
create segment star_1q01
storage 'j:¥disk5¥star1' maxsize 200,
storage 'j:¥disk5¥star2' maxsize 200;
star_1q01
star1
star2
j:¥disk5
create segment star_2q01
storage 'k:¥disk6¥star1' maxsize 200,
storage 'k:¥disk6¥star2' maxsize 200;
star_2q01
star1
star2
k:¥disk6
create segment star_3q01
storage 'l:¥disk7¥star1' maxsize 200,
storage 'l:¥disk7¥star2' maxsize 200;
star_3q01
star1
star2
l:¥disk7
star_4q01
star1
star2
star3
m:¥disk8
star_1q02
star1
star2
star3
n:¥disk9
create segment star_4q01
storage 'm:¥disk8¥star1' maxsize 200,
storage 'm:¥disk8¥star2' maxsize 200,
storage 'm:¥disk8¥star3' maxsize 200;
create segment star_1q02
storage 'n:¥disk9¥star1' maxsize 200,
storage 'n:¥disk9¥star2' maxsize 200,
storage 'n:¥disk9¥star3' maxsize 200;
create segment star_max
storage 'o:¥disk10¥star_max' maxsize 16;
star_max
star_max
o:¥disk10
データベースの作成 5-45
データ セグメントとインデックス セグメントの作成
図 5-8 は、TARGET インデックスの一つ ( フォーリン キー列 mktkey 上の
Sales_target_mktkey インデックス ) に対するインデックス セグメントを作成する方
法を示したものです。
図 5-8
Windows における Sales_target_mktkey インデックスのセグメントの作成
CREATE SEGMENT 文
作成されたセグメント 含まれるファイル
create segment target_mkt_1q00
storage 'c:¥disk1¥target_mkt1' maxsize 200,
storage 'c:¥disk1¥target_mkt2' maxsize 200;
target_mkt_1q00
target1
target2
c:¥disk1
create segment target_mkt_2q00
storage 'g:¥disk2¥target_mkt1' maxsize 200,
storage 'g:¥disk2¥target_mkt2' maxsize 200;
target_mkt_2q00
target1
target2
g:¥disk2
create segment target_mkt_3q00
storage 'h:¥disk3¥target_mkt1' maxsize 200,
storage 'h:¥disk3¥target_mkt2' maxsize 200;
target_mkt_3q00
target1
target2
h:¥disk3
create segment target_mkt_4q00
storage 'i:¥disk4¥target_mkt1' maxsize 200,
storage 'i:¥disk4¥target_mkt2' maxsize 200;
target_mkt_4q00
target1
target2
i:¥disk4
create segment target_mkt_1q01
storage 'j:¥disk5¥target_mkt1' maxsize 200,
storage 'j:¥disk5¥target_mkt2' maxsize 200;
target_mkt_1q01
target1
target2
j:¥disk5
create segment target_mkt_2q01
storage 'k:¥disk6¥target_mkt1' maxsize 200,
storage 'k:¥disk6¥target_mkt2' maxsize 200;
target_mkt_2q01
target1
target2
k:¥disk6
create segment target_mkt_3q01
storage 'l:¥disk7¥target_mkt1' maxsize 200,
storage 'l:¥disk7¥target_mkt2' maxsize 200;
target_mkt_3q01
target1
target2
l:¥disk7
target_mkt_4q01
target1
target2
target3
m:¥disk8
target_mkt_1q02
target1
target2
target3
n:¥disk9
create segment target_mkt_4q01
storage 'm:¥disk8¥target_mkt1' maxsize 200,
storage 'm:¥disk8¥target_mkt2' maxsize 200,
storage 'm:¥disk8¥target_mkt3' maxsize 200;
create segment target_mkt_1q02
storage 'n:¥disk9¥target_mkt1' maxsize 200,
storage 'n:¥disk9¥target_mkt2' maxsize 200,
storage 'n:¥disk9¥target_mkt3' maxsize 200;
create segment target_mkt_max
storage 'o:¥disk10¥target_mkt_max' maxsize 16;
5-46 Administrator’s Guide
target_mkt_max
target_max
o:¥disk10
データ セグメントとインデックス セグメントの作成
以下の CREATE SEGMENT 文は、その他の 2 つのローカル TARGET インデックスを
定義するものです。
create segment target_per_1q00
storage 'c:¥disk1¥target_per1' maxsize 200,
storage 'c:¥disk1¥target_per2' maxsize 200;
create segment target_per_2q00
storage 'g:¥disk2¥target_per1' maxsize 200,
storage 'g:¥disk2¥target_per2' maxsize 200;
create segment target_per_3q00
storage 'h:¥disk3¥target_per1' maxsize 200,
storage 'h:¥disk3¥target_per2' maxsize 200;
create segment target_per_4q00
storage 'i:¥disk4¥target_per1' maxsize 200,
storage 'i:¥disk4¥target_per2' maxsize 200;
create segment target_per_1q01
storage 'j:¥disk5¥target_per1' maxsize 200,
storage 'j:¥disk5¥target_per2' maxsize 200;
create segment target_per_2q01
storage 'k:¥disk6¥target_per1' maxsize 200,
storage 'k:¥disk6¥target_per2' maxsize 200;
create segment target_per_3q01
storage 'l:¥disk7¥target_per1' maxsize 200,
storage 'l:¥disk7¥target_per2' maxsize 200;
create segment target_per_4q01
storage 'm:¥disk8¥target_per1' maxsize 200,
storage 'm:¥disk8¥target_per2' maxsize 200,
storage 'm:¥disk8¥target_per3' maxsize 200;
create segment target_per_1q02
storage 'n:¥disk9¥target_per1' maxsize 200,
storage 'n:¥disk9¥target_per2' maxsize 200,
storage 'n:¥disk9¥target_per3' maxsize 200;
create segment target_per_max
storage 'o:¥disk10¥target_per_max' maxsize 16;
create segment target_prod_1q00
storage 'c:¥disk1¥target_prod1' maxsize 200,
storage 'c:¥disk1¥target_prod2' maxsize 200;
create segment target_prod_2q00
storage 'g:¥disk2¥target_prod1' maxsize 200,
storage 'g:¥disk2¥target_prod2' maxsize 200;
データベースの作成 5-47
データ セグメントとインデックス セグメントの作成
create segment target_prod_3q00
storage 'h:¥disk3¥target_prod1' maxsize 200,
storage 'h:¥disk3¥target_prod2' maxsize 200;
create segment target_prod_4q00
storage 'i:¥disk4¥target_prod1' maxsize 200,
storage 'i:¥disk4¥target_prod2' maxsize 200;
create segment target_prod_1q01
storage 'j:¥disk5¥target_prod1' maxsize 200,
storage 'j:¥disk5¥target_prod2' maxsize 200;
create segment target_prod_2q01
storage 'k:¥disk6¥target_prod1' maxsize 200,
storage 'k:¥disk6¥target_prod2' maxsize 200;
create segment target_prod_3q01
storage 'l:¥disk7¥target_prod1' maxsize 200,
storage 'l:¥disk7¥target_prod2' maxsize 200;
create segment target_prod_4q01
storage 'm:¥disk8¥target_prod1' maxsize 200,
storage 'm:¥disk8¥target_prod2' maxsize 200,
storage 'm:¥disk8¥target_prod3' maxsize 200;
create segment target_prod_1q02
storage 'n:¥disk9¥target_prod1' maxsize 200,
storage 'n:¥disk9¥target_prod2' maxsize 200,
storage 'n:¥disk9¥target_prod3' maxsize 200;
create segment target_prod_max
storage 'o:¥disk10¥target_prod_max' maxsize 16;
♦
5-48 Administrator’s Guide
テーブルの作成
テーブルの作成
Period テーブルはデフォルト セグメントに格納され、以下のように定義されている
とします。
create table period (
perkey date not null,
month char (5),
year integer,
quarter integer,
tri integer,
primary key (perkey))
maxrows per segment 2048;
Sales テーブルは、以下の CREATE TABLE 文によって作成され、四半期別にセグメ
ント化されています。セグメント指定は、セグメント、セグメント化の基準列、各
セグメントに格納されるデータの範囲を割り当てます。Perkey 列はセグメント化の
基準列です。そのため、範囲は Perkey 列の値を示します。各セグメントの範囲は、
1 つの四半期を表し、売上データは四半期ごとに個別のセグメントに格納されます。
create table sales (
perkey date not null,
prodkey integer not null,
mktkey integer not null,
dollars decimal (7, 2),
weight smallint,
primary key (perkey, prodkey, mktkey),
foreign key (perkey) references period (perkey),
foreign key (prodkey) references product (prodkey),
foreign key (mktkey) references market (mktkey))
data in (s_1q00, s_2q00, s_3q00, s_4q00, s_1q01, s_2q01,
s_3q01, s_4q01, s_1q02, s_max)
segment by values of (perkey) ranges (
min:DATE'2000-04-01',
DATE'2000-04-01':DATE'2000-07-01',
DATE'2000-07-01':DATE'2000-10-01',
DATE'2000-10-01':DATE'2001-01-01',
DATE'2001-01-01':DATE'2001-04-01',
DATE'2001-04-01':DATE'2001-07-01',
DATE'2001-07-01':DATE'2001-10-01',
DATE'2001-10-01':DATE'2002-01-01',
DATE'2002-01-01':DATE'2002-04-01',
DATE'2002-04-01':max);
データベースの作成 5-49
STAR インデックスの作成
STAR インデックスの作成
すべてのフォーリン キーを対象とする STAR インデックスが Sales テーブルに作成
され、その STAR インデックスがデータとまったく同様にセグメント化されている
とします。つまり、s_1q00 データ セグメントのデータの各行に対応するインデッ
クス エントリが star_1q00 インデックス セグメントに存在し、s_2q00 データ セグメ
ントのデータの各行に対応するインデックス エントリが star_2q00 インデックス セ
グメントに存在し、残りのデータ セグメントについても同様とします。
STAR インデックスをこのようにセグメント化するには、以下のいずれかの方法を
使います。
■
■
STAR インデックスの先頭のディメンジョン テーブル (Period) の行 ID の範
囲を基準にしてセグメント化する。
ファクト テーブルと同じようにセグメント化する。STAR インデックスの
先頭列 perkey がファクト テーブル Sales のセグメント化基準列であるから
です。
ヒント：STAR インデックスをファクト テーブルと同じようにセグメント化する方
法は、先頭のディメンジョン テーブル Period の行 ID を基準にしてセグメント化す
る方法よりも簡単です。この 2 つの方法の手順を以下に説明します。
STAR インデックスのインデックス エントリは、インデックス データの値ではな
く、そのデータが格納されているディメンジョン ( 参照先 ) テーブルの行 ID です。
この行 ID の構造、および行 ID とファクト テーブルとディメンジョン テーブルの関
係については、5-16 ページ「STAR インデックスのセグメント化」を参照してくだ
さい。
先頭のディメンジョン テーブルの行 ID の範囲を基準にして STAR イン
デックスをセグメント化するには
1.
5-50 Administrator’s Guide
データと同じようにセグメント化された STAR インデックスを作成する前
に、先頭のディメンジョン テーブルをロードします。
先頭のディメンジョン テーブルは、STAR インデックスを作成する前に
ロードする必要があります。なぜなら、CREATE STAR INDEX 文の中でセ
グメント範囲を定義するには、ディメンジョン テーブルの行 ID を指定す
る必要があるからです。
STAR インデックスの作成
2.
STAR インデックスのセグメント範囲の境界を見つけます。
先頭のディメンジョン テーブル Period の RBW_ROWNUM シュード列お
よびプライマリ キー列 (Date) に対してクエリを実行します。このクエリの
WHERE 句の Date 列を対象とする制約は、5-49 ページの Sales テーブルに
対する CREATE TABLE 文から得られる範囲の境界に一致しています。
select rbw_rownum, date
from period
where date = '04-01-00'
or date = '07-01-00'
or date = '10-01-00'
or date = '01-01-01'
or date = '04-01-01'
or date = '07-01-01'
or date = '10-01-01'
or date = '01-01-02'
or date = '04-01-02';
このクエリを実行すると、以下の行が出力されます。
RBW_ROWNUM
90
181
273
365
455
546
638
730
821
DATE
2000-04-01
2000-07-01
2000-10-01
2001-01-01
2001-04-01
2001-07-01
2001-10-01
2002-01-01
2002-04-01
ヒント：CREATE STAR INDEX 文の範囲は、Sales テーブルの行番号ではなく、参
照先テーブル Period の行番号を示します。CREATE INDEX 文の構文の詳細につい
ては、『SQL Reference Guide』を参照してください。
3.
一般に Period はこのデータベースの中で最もサイズの小さいテーブルなの
で、通常はセグメント化されません。したがって、RBW_SEGNAME
シュード列に対してクエリを実行する必要はありません。
特定の四半期の日付だけを含めるセグメントの範囲を指定します。
create star index sales_star
on sales (perkey, prodkey, mktkey)
in (star_1q00, star_2q00, star_3q00, star_4q00,
star_1q01, star_2q01, star_3q01, star_4q01,
star_1q02, star_max)
segment by references of (perkey)
ranges (min:90, 90:181, 181:273, 273:365, 365:455,
455:546, 546:638, 638:730, 730:821, 821:max)
データベースの作成 5-51
STAR インデックスの作成
STAR インデックスをファクト テーブルと同じようにセグメント化するに
は
1.
2.
データと同じようにセグメント化された STAR インデックスを作成する前
に、先頭のディメンジョン テーブルをロードします。
STAR インデックスを作成する前に、先頭のディメンジョン テーブルを
ロードする必要があります。なぜなら、インデックス作成操作では、セグ
メント境界を定義するため、ディメンジョン テーブルから行番号または行
ID が取得されるからです。これは、CREATE STAR INDEX 文でセグメント
境界を指定する必要がない場合でも同様です。
STAR インデックスは、物理的に見ると、ディメンジョン テーブルの行 ID
を基準にしてセグメント化されますが、論理的に見ると、ファクト テーブ
ルのセグメント化基準列の値を基準にしてセグメント化されます。
先頭のディメンジョン テーブルに対してクエリを実行し、行が予想どおり
の順序でロードされているか確認します。
このクエリの WHERE 句の Date 列を対象とする制約は、5-49 ページの
Sales テーブルに対する CREATE TABLE 文から得られる範囲の境界に一致
しています。
select date from period
where date = '04-01-00'
or date = '07-01-00'
or date = '10-01-00'
or date = '01-01-01'
or date = '04-01-01'
or date = '07-01-01'
or date = '10-01-01'
or date = '01-01-02'
or date = '04-01-02';
このクエリを実行すると、以下の行が出力されます。
DATE
90 2000-04-01
181 2000-07-01
273 2000-10-01
365 2001-01-01
455 2001-04-01
546 2001-07-01
638 2001-10-01
730 2002-01-01
821 2002-04-01
5-52 Administrator’s Guide
ローカル TARGET インデックスの作成
3.
CREATE STAR INDEX 文で SEGMENT LIKE DATA 句を指定します。
create star index sales_star
on sales (perkey, prodkey, mktkey)
in (star_1q00, star_2q00, star_3q00, star_4q00,
star_1q01, star_2q01, star_3q01, star_4q01,
star_1q02, star_max)
segment like data
ローカル TARGET インデックスの作成
Sales テーブルの各フォーリン キーに対して TARGET インデックスを作成し、その
TARGET インデックスをデータとまったく同じようにセグメント化する場合を考え
てみます。たとえば、データ セグメント s_1q00 のデータの各行に対応するイン
デックス エントリは、インデックス セグメント target_1q00 にあります。同様に、
データ セグメント s_2q00 のデータの各行に対応するインデックス エントリは、イ
ンデックス セグメント target_2q00 にあります。このようにセグメント化するには、
CREATE INDEX 文で SEGMENT LOCAL 句を使います。
create target index sales_target_mktkey
on sales (mktkey)
in (target_mkt_1q00, target_mkt_2q00, target_mkt_3q00,
target_mkt_4q00, target_mkt_1q01, target_mkt_2q01,
target_mkt_3q01, target_mkt_4q01, target_mkt_1q02,
target_mkt_max)
segment local
SEGMENT LIKE DATA 句ではなく SEGMENT LOCAL 句を使う必要があります。な
ぜなら、このテーブルのセグメント化基準列はこの TARGET インデックスの列では
ないからです。定期的に更新されるデータベースにおいて、ローカル TARGET イン
デックスは、ローカルでない TARGET インデックスに比べて管理が容易です。詳細
については、9-57 ページ「データ セグメントおよびインデックス セグメントの
ロールオフと再使用」を参照してください。
データベースの作成 5-53
ローカル TARGET インデックスの作成
図 5-9 は、売上データが、テーブルのセグメント、STAR インデックスのセグメン
ト、および TARGET インデックスの一つのセグメントにどのようにマッピングされ
ているかを示します。
図 5-9
テーブル セグメントおよびインデックス セグメントにマッピングされている売上データ
マップ先の
テーブル セグメント
売上データの範囲
マップ先の
STAR インデックス
セグメント
マップ先の
TARGET
インデックス
セグメント
min:DATE'2000-04-01'
s_1q00
star_1q00
target_1q00
DATE'2000-04-01':DATE'2000-07-01'
s_2q00
star_2q00
target_2q00
DATE'2000-07-01':DATE'2000-10-01'
s_3q00
star_3q00
target_3q00
DATE'2000-10-01':DATE'2001-01-01'
s_4q00
star_4q00
target_4q00
DATE'2001-01-01':DATE'2001-04-01'
s_1q01
star_1q01
target_1q01
DATE'-04-072001':DATE'2001-10-01'
s_2q01
star_2q01
target_2q01
DATE'-07-072001':DATE'2001-10-01'
s_3q01
star_3q01
target_3q01
DATE'2001-10-01':DATE'2002-01-01'
s_4q01
star_4q01
target_4q01
DATE'2002-01-01':DATE'2002-04-1'
s_1q02
star_1q02
target_1q02
DATE'2002-04-01':max
s_max
star_max
target_max
各セグメントには、そのセグメント範囲の下限以上で、上限未満のデータが格納さ
れます。たとえば、セグメント s_2q00 には、2000 年 4 月 1 日のデータは格納されま
すが、2000 年 7 月 1 日のデータは格納されません。同様に、STAR インデックス セ
グメント star_2q00 および TARGET インデックス セグメント target_2q00 には、
2000 年 4 月 1 日のデータに対するインデックス エントリは格納されますが、2000 年
7 月 1 日のデータに対するインデックス エントリは格納されません。
5-54 Administrator’s Guide
データ
最終セグメント s_max は、2001 年 4 月 1 日以降のデータを格納することを目的とし
ています。現時点では、そのデータはロードされていないため、空になっていま
す。
データ
データは、Sales テーブルおよび Period テーブルに以下のようにロードされていま
す。
load data
inputfile 'period.txt'
replace
separated by ':'
discardfile 'period_discards'
discards 5
into table period (
perkey date 'MM/Y*/DD',
month char,
year integer external,
quarter integer external,
tri integer external
);
load data
inputfile 'sales.txt'
replace
separated by ':'
discardfile 'sales_discards'
discards 5
into table sales (
perkey date 'MM/Y*/DD',
prodkey integer external,
mktkey integer external,
dollars integer external,
weight smallint external
);
Product テーブルと Market テーブルをロードしてから、Sales テーブルをロードす
る必要があります。ただし、これらのテーブルの内容は、この例とは直接関係があ
りません。
データベースの作成 5-55
データ
図 5-10 は、Period テーブルと Sales テーブルのデータ フォーマットとセグメント間
でのデータの分散方法を示します。Period テーブルのインデックスは独立したデ
フォルト セグメントにあり、Sales テーブルの STAR インデックスと TARGET イン
デックスはデータのようにセグメント化されています。5-54 ページ図 5-9 を参照し
てください。
図 5-10
Period テーブルおよび Sales テーブルのデータ フォーマット
period.txt
01/92/01:JAN:1992:1:1
01/92/02:JAN:1992:1:1
...
12/00/31:DEC:2001:4:3
default _segment
sales.txt
01/00/01:01:02:890:80
03/00/31:31:19:400:40
s_1q00
min:DATE'2000-04-01'
s_2q00
DATE'2000-04-01':DATE'2000-07-01'
s_3q01
DATE'-07-072001':DATE'2001-10-01'
10/01/01:31:04:225:20
12/01/31:21:10:111:10
s_4q01
DATE'2001-10-01':DATE'2002-01-01'
01/02/01:00:02:725:20
03/02/31:31:19:321:10
s_1q02
DATE'2002-01-01':DATE'2002-04-01'
.
04/00/01:21:04:703:71
06/00/30:20:10:559:53
...
07/01/01:01:04:456:45
09/01/30:10:06:801:81
次の四半期 (2Q02) に入ると、最も古い四半期 (1Q00) データが格納されているセグ
メントがロール オフされ、この最新の四半期データが追加されます。詳細について
は、9-56 ページ「定期的に更新されるデータベースのメンテナンス方法」を参照し
てください。
5-56 Administrator’s Guide
ビューの作成
ビューの作成
ビューは、データベースの複数のテーブルから列と行を選択して作成します。
ビューを使うと、クエリを容易にしたり、一部のデータをユーザから隠すことがで
きます。たとえば、特定の列や行だけを頻繁にクエリで参照する場合は、その列と
行だけで構成されるビューを作成します。非公開のデータがテーブルにある場合
は、その列だけを格納したビューや、その列を除外したビューを作成し、ビューの
内容に応じてアクセス権を付与します。
ビューは、ビューの参照先テーブルにデータがあるかどうかに関わらず、作成また
は削除できます。ビューが参照するテーブルは、ビューの作成時に存在していなけ
ればなりません。
ビューは作成時に最適な形態でシステムに格納されます。このため、ビューの定義
にマクロや SELECT *... 文があると、ビューの作成時にそれらが展開されます。
ビューの作成後に行ったマクロの変更や列の追加は、ビューには反映されません。
また、ビュー自体は更新できません。つまり、ビューで行を挿入、更新、または削
除することはできません。ビューの基本テーブルのデータの更新は反映されます。
ビューを定義するテキストが 256 バイトを超えると、複数の行が
RBW_VIEWTEXT システム テーブルに挿入されます。マクロを含むビューは、マ
クロを展開した後のテキストではなく、マクロ名の文字数がカウントされます。
事前計算ビューおよび階層構造も作成すると、集約クエリを自動的に書き換え、お
よび最適化することができます。クエリ書き換えシステムの詳細については、
『IBM Red Brick Vista User’s Guide』を参照してください。
データベースの作成 5-57
ビューの作成
例
Customer テーブルに対して、営業部員は担当地域だけにアクセスを制限し、管理
職は複数の地域にアクセスできるように設定する例を示します。テーブルと列は、
以下のようになっています。
図 5-11
Sales_rep テーブル
Customer テーブル
Market_access テーブル
rep_key
auth_id
fullname
quota
year_to_date
...
rep_key
market_id
Market テーブル
market_id
mkt_name
region
class
...
cust_id
market_id
cust_name
address
...
上記の制限を行うには、ユーザごとに個別のビューを作成します。
create view user1_list
as select * from customer
where market_id in
(select market_id from market_access, sales_rep
where sales_rep.auth_id = 'user1'
and sales_rep.repkey = market_access.rep_key);
各自のビューに対する SELECT 特権をユーザに付与します。ユーザ数が多い場合
は、多くのビューを作成、管理する必要があります。
SQL の CURRENT_USER ( または USER) 関数を使うと、アクセスを制限する汎用
ビューの管理が簡単になります。
create view cust_list
as select * from customer
where market_id in
(select market_id from market_access, sales_rep
where sales_rep.auth_id = CURRENT_USER
and sales_rep.repkey = market_access.rep_key);
ビュー cust_list に対する SELECT 特権を PUBLIC に付与します。
grant select on cust_list to public ;
5-58 Administrator’s Guide
マクロの作成と管理
営業部員は、以下のクエリによって担当地域の顧客を参照することができます。
select * from cust_list ;
Market_Access テーブルに登録された地域と営業部員の組み合わせにより、その営
業部員がアクセスを許可された地域の顧客だけが表示されます。
マクロの作成と管理
マクロの使用は任意ですが、データベース管理者や一般ユーザの SQL 文の作成を容
易にします。マクロを使用すると、長い文字列を略記したり、複雑なクエリを簡略
化することができます。パラメータを使用してマクロを汎用化したり、ほかのマク
ロをネストすることもできます。マクロによって簡略化または短縮できる SQL 文が
ないか検討してください。
マクロ定義のガイドライン
マクロを定義するための一般的なガイドラインを示します。
■
■
■
■
■
1 つの CREATE MACRO 文で使用できる定義文字数は、1024 文字までです。
マクロ a にマクロ b が含まれ、マクロ b にマクロ a が含まれるという再帰
的な定義でないかぎり、1 つのマクロにほかのマクロを含めることができ
ます。再帰的な定義を行うと、マクロが展開されたときにエラー メッセー
ジが表示されます。
マクロ定義には、定義を汎用化するパラメータを使用できます。
マクロ定義には、カテゴリとコメントを付けることができます。
マクロ定義は RBW_MACROS システム テーブルの TEXT 列に格納されま
す。テーブルのクエリによってマクロの定義を確認できます。マクロとそ
のパラメータ値を SQL 文に展開するには、EXPAND コマンドを使用しま
す。
カテゴリとコメントは、RBW_MACROS システム テーブルの CATEGORY 列と
COMMENT 列に格納されます。CATEGORY の値は、他社製品のアプリケーション
ツールで使用するためのもので、IBM Red Brick Warehouse では使用されません。た
とえば、マクロの構文と、完全な SQL 文の構文との対応をカテゴリによって指定で
きます。COMMENT には、マクロに関するコメントや、アプリケーション ツール
が使用するほかの情報も格納できます。
CREATE MACRO 文の詳しい定義については、『SQL Reference Guide』を参照してく
ださい。
データベースの作成 5-59
マクロの利用範囲
マクロの利用範囲
マクロの利用範囲は、作成時の指定により決定します。IBM Red Brick Warehouse
は、以下のマクロ定義をサポートしています。
■
■
■
パブリック マクロ : すべてのデータベース ユーザが利用できます。DBA 権
限を持ったユーザだけが作成でき、RBW_MACROS システム テーブルに
格納されます。
プライベート マクロ : マクロの作成者だけが利用できます。DBA 権限また
は RESOURCE 権限を持ったユーザだけが作成でき、RBW_MACROS シス
テム テーブルに格納されます。
テンポラリ マクロ : マクロの作成者だけが利用できます。どのユーザも作
成できますが、マクロが作成されたセッション中でしか利用できません。
.rbwrc ファイルにマクロ定義を格納しておけば、セッションを起動するた
びに自動的に読み込まれます。クエリごとに新規セッションを起動および
終了するツールの場合は、.rbwrc ファイルに CREATE MACRO 文を格納し
なければ、テンポラリ マクロの使用が制限されます。
マクロ定義の規則と適用範囲を以下に示します。
マクロの種類
必要な権限
利用できる
ユーザ
構文
パブリック
DBA (CREATE ANY タスク )
全ユーザ
CREATE PUBLIC MACRO ...
プライべート
DBA または RESOURCE
(CREATE ANY または CREATE OWN
タスク )
作成者
CREATE MACRO...
テンポラリ
CONNECT ( すべてのユーザ )
作成者
CREATE TEMPORARY MACRO...
マクロの処理方法は、IBM Red Brick Warehouse と併用するツールによって異なりま
す。各ツールによるマクロの使用方法については、IBM、または他社製品のマニュ
アルを参照してください。
マクロ参照は、以下のように解決されます。
■
■
■
5-60 Administrator’s Guide
指定した名前のテンポラリ マクロが存在する場合は、テンポラリ マクロ
が使用されます。
テンポラリ マクロが存在せず、指定した名前のプライベート マクロが存
在する場合は、プライベート マクロが使用されます。
テンポラリおよびプライべート マクロが共に存在せず、指定した名前のパ
ブリック マクロが存在する場合は、パブリック マクロが使用されます。
マクロの利用範囲
例
使用頻度の高い SQL 文の一部を、マクロにする例を示します。繰り返し使用するリ
スト、FROM 句、および一連の WHERE 句の制約を略記した std_select というマク
ロを作成します。
create macro std_select as
date_col, product, city, dollars
from period, product, market, sales
where period.perkey = sales.perkey
and product.prodkey = sales.prodkey
and market.mktkey = sales.mktkey ;
1998 年の San Jose の売上データを検索する SELECT 文に上記のマクロを使用するに
は、以下のように入力します。
select std_select and year = 1998 and city ='San Jose';
同じような指定をする使用頻度の高い SQL 文の一部を、パラメータを使ったマクロ
にする例を示します。繰り返し使用する制約を汎用化するために 2 つのパラメータ
を使い、std_constraint というマクロを作成します。
create macro std_constraint (yr, cty) as
year = yr and city = cty;
ヒント：パラメータ名は、マクロ定義のテキストに存在する文字列以外のものを
使用してください。たとえば、以下の定義は有効ですが、条件が必ず満たされる制
約になってしまいます。
create macro std_constraint (year, city) as
year = year and city = city;
マクロが正しく定義されていることを検証するには、RBW_MACROS システム
テーブルを参照します。マクロの識別子は大文字で格納されます。
select name, text from rbw_macros
where name = 'STD_CONSTRAINT';
NAME
TEXT
STD_CONSTRAINT
YEAR=%1 AND CITY=%2
パラメータを使用した場合など、マクロが正しく展開されることを検証するには、
EXPAND コマンドを使用してマクロの展開結果を確認します。
expand std_constraint(1998, 'San Jose');
STATEMENT
YEAR=1998 AND CITY='San Jose';
データベースの作成 5-61
マクロの利用範囲
パラメータを使ったマクロを SELECT 文で使用し、San Jose および Miami における
1998 年の売上データを検索するには、以下のように入力します。
select std_select and std_constraint (1998,'San Jose');
...
select std_select and std_constraint (1998,'Miami');
...
以下のマクロは、使用頻度の高いクエリを 1 つのコマンドとして定義します。2 つ
の組み込み ( ネスト ) マクロが含まれています。
create macro std_query (yr, cty) as
select std_select and std_constraint (yr, cty);
希望の売上データを検索する文を、マクロを使用して以下のように略記することが
できます。
std_query (1998,'San Jose');
std_query (1998,'Miami');
マクロ定義の詳しい例については、『SQL Self-Study Guide』を参照してください。
5-62 Administrator’s Guide
第6章
バージョン管理されたデー
タベースの使用
バージョニングを使用するケース . . . . . .
ロード ウィンドウ . . . . . . . . . .
復旧性能の向上 . . . . . . . . . . .
定期コミットを行うロード . . . . . . .
ロード復旧性の提供 . . . . . . . . . .
Vista によるバージョニング . . . . . . .
ディメンジョン テーブルのクリーニング . .
バージョン ログのコスト . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
. .
. .
. .
. .
6-4
6-4
6-4
6-5
6-6
6-6
6-7
6-7
バージョン管理されたデータベースへのデータのロード
.
.
.
.
.
6-8
バージョン ログについて . . . . . .
バージョン ログの構造 . . . . . .
バージョン管理された DELETE 操作 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-10
6-11
6-13
凍結バージョンについて
.
.
.
.
.
.
.
.
.
.
6-13
高復旧性オプションを使用したデータのロード
.
.
.
.
.
.
.
.
6-16
バージョニングの制御 . . . . . . . . .
バージョン ログの作成 . . . . . . . .
バージョン ログのクリーニング . . . . .
バージョン ログの削除と領域の追加 . . .
凍結バージョンの制御 . . . . . . . .
データベースの凍結 . . . . . . .
凍結バージョンの無効化 . . . . . .
データベースの凍結解除 . . . . . .
凍結バージョンでのデータのアンロード
凍結バージョンと高復旧性の使用 . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-16
6-18
6-19
6-20
6-21
6-21
6-21
6-22
6-22
6-22
. .
. .
6-23
6-23
.
.
.
.
.
.
バージョン管理されたデータベースのメンテナンス方法
バージョン ログの監視 . . . . . . . . . . .
. . .
. . .
バックアップと復旧 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-24
バキューム クリーナの制御 .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6-25
例 : バージョン管理された Aroma データベースの作成
.
.
.
.
.
.
6-26
6-2 Administrator’s Guide
この章について
バージョン管理されたデータベースを使用すると、データベース管理者は、ユーザ
によるクエリを中断したり、クエリの処理効率に影響を与えることなく、データ
ベースのロードや更新の作業を実施できます。トランザクションがコミットされる
と新しいトランザクションのリビジョン ( バージョン ) が作成され、読み取りリビ
ジョン番号が割り当てられます。
バージョニングは、営業時間中の大量データのロード、ロード中に処理が中止され
た場合の早期復旧、日中の定期的なデータベースのリフレッシュなどを行う場合に
使用します。ユーザ クエリに対して最新バージョンのデータベースにアクセスさせ
るか、または凍結バージョン モードを使用してすべてのクエリを同じバージョンに
アクセスさせるかを選択でき、リビジョンのロードと検証を行っている間にもデー
タ分析の結果に整合性を持たせられます。
この章では、以下の内容について説明します。
■
■
■
■
■
■
■
■
■
バージョニングを使用するケース
バージョン管理されたデータベースへのデータのロード
バージョン ログについて
凍結バージョンについて
高復旧性オプションを使用したデータのロード
バージョニングの制御
バージョン管理されたデータベースのメンテナンス方法
バキューム クリーナの制御
例 : バージョン管理された Aroma データベースの作成
バージョン管理されたデータベースの使用
6-3
バージョニングを使用するケース
バージョニングを使用するケース
バージョニングには、ロード ウィンドウの拡大、データベース復旧性能の向上、お
よび営業時間中における少量データの追加変更機能などの利点があります。使用し
ているデータベースの運用に上記いずれの機能も重要でない場合は、バージョニン
グを使用しない方が良いでしょう。バージョニングに関するシステム コストは、格
納領域およびバージョン ログの維持と密接に関連します。また、バージョニングを
実施するかどうかを決定するには、ロードの性能に対する影響も考慮に入れる必要
があります。
ロード ウィンドウ
ロード ウィンドウとは、クエリ操作にデータベースを使用できない時間をいいま
す。ロード操作を実行すると、更新が行われている間そのテーブルへの読み取りア
クセスがデータベース サーバによって禁止されます。ユーザの必要条件によって決
められたロード ウィンドウがデータベースのメンテナンスに必要な時間より短い場
合には、バージョニングが適していると考えられます。バージョニングを使用する
と、データベースの使用可能時間を増加させたり、常時使用可能にできます。バー
ジョニングは、大量のデータをロードする場合に特に有効です。
ユーザの環境を考えれば、稼働時間がどの程度重要であるかを判断できます。ユー
ザが複数の時間帯にまたがっている場合は、時差を超えて全ユーザが営業時間に
データベースにアクセスできるように、データベースを常に稼動させておく必要が
あります。このような場合、バージョニングを使用すればデータベースをいつでも
アクセス可能な状態にしておけます。データベースへのアクセスを必要とするユー
ザが少なく、その時間帯が午前 9:00 から午後 5:00 の間に限られる場合は、バージョ
ニングを使用する代わりに、ユーザがデータベースを利用できない夜間にデータ
ベースの保守を実行します。
復旧性能の向上
バージョニングが有効な状態でトランザクションを実行すると、データベース内の
既存ブロックは直接更新されません。変更済みブロックはデータベース ファイルで
はなく、バージョン ログの方に書き込まれます。この方法では、データベース
ファイルに変更が加えられないため、トランザクションが開始された時点への完全
な復旧が可能です。トランザクション実行中は、データベースの旧リビジョンの整
合性が完全に保たれます。
6-4 Administrator’s Guide
定期コミットを行うロード
たとえば、バージョニングが有効な状態でデータをロードする操作途中で、停電が
発生したとします。システムを再起動すれば、データベースは正常に動作し、ロー
ド操作の実行前と同じ状態が回復されます。停電の発生中に処理されたトランザク
ションはすべて中止され、データベースは自動的に整合性のある状態にロールバッ
クされます。この状態からロード操作を再実行できます。バージョニングが無効な
状態で同様のトラブルが発生した場合は、データベースが整合性のない状態とな
り、データベースを操作可能にするために復旧作業が必要となる可能性がありま
す。
定期コミットを行うロード
データを一定間隔でコミットしながらロードすると効率的な場合があります。この
方法でインクリメンタル ロードを行えば、大量のデータをロードする作業の途中で
処理が中断された場合でも、再ロードするデータの量を縮小できます。また、この
方法は断続更新アプリケーションにも使用できます。
OLTP システムからの直接入力など、データベースにロードするデータ量が一定し
ている場合、ロードを停止したり再度開始したりせずにユーザにデータを利用させ
るには、断続更新アプリケーションを使用すると効率的です。この方法では、ユー
ザはほぼリアルタイムでデータを分析できます。
たとえば、株式市場の相場情報をデータベースに格納するため、最新のデータを少
量ずつ、15 分間隔のバッチでロードするとします。バージョニングを行わない場
合、この処理中はデータベースを検索できないため、株式市場が開いている間はほ
とんどデータベースを使用できない状態になってしまいます。
デフォルト モードでは、バージョン管理されたトランザクションはコミットする前
に全ロード操作を完了するように設定されています。断続更新アプリケーションを
作成するには、コミット間隔の設定でロード操作がコミットされる間隔を短くしま
す。この間隔は、一定の行数のロードごと (SET TMU COMMIT RECORD
INTERVAL)、または一定時間の経過後 (SET TMU COMMIT TIME INTERVAL)、ある
いはその両方に設定できます。
また、間隔コミットは通常のバージョン管理されたロードにおけるチェックポイン
トとして使用できます。次のインターバルでロード操作に失敗すると、最後にコ
ミットされた時点の状態に戻ります。たとえば、1,000,000 行をロードする場合、
TMU COMMIT RECORD INTERVAL を 100,000 レコードに設定しておくと、999,000
レコードまでロードされたところで失敗しても、最後の 900,000 レコード分はコ
ミットされています。通常のバージョン管理されたロードが同じような状態で失敗
した場合は、トランザクションは最初のレコードをロードする前の状態に戻ってし
まいます。
TMU COMMIT コマンドの詳細については、『Table Management Utility Reference
Guide』を参照してください。
バージョン管理されたデータベースの使用
6-5
ロード復旧性の提供
ロード復旧性の提供
バージョン ログを従来型の先行書き込みログとして使用すると、高いレベルの復旧
性を実現できます。たとえば、これによってディスク領域不足などの致命的な障害
から復旧できます。これらはまったく同一のメカニズムを使用しますが、バージョ
ン ログ リソースの使用と、バージョン ログ自身に問題が発生した場合の両方で、
一般的なバージョニングよりも高復旧性オプションのほうが予測可能です。
高復旧性オプションを使用したロードの詳細については、6-16 ページ「高復旧性オ
プションを使用したデータのロード」を参照してください。
Vista によるバージョニング
Vista クエリ書き換えおよび集約保守機能を使用している場合、バージョニングを使
用すると大きな利点があります。集約クエリ書き換えに使用する事前計算ビューの
有効性に対しては、バージョン管理されたデータベースとバージョン管理されない
データベースの両方で同じ規則が適用されます。しかし、凍結クエリ リビジョンを
使用すると、ユーザのクエリの書き換えるのに使用している、関連する事前計算
ビューを無効化しなくても、詳細テーブルを変更できます。
バージョニングでは、集約保守を実行するロード中に、詳細テーブルと集約テーブ
ルのデータの整合性を保護することができます。バージョニングが有効な状態のと
き、何らかの理由で集約保守に障害が発生した場合、エラー処理に 2 通りの方法が
あります。問題のある事前計算ビューを無効化する方法と、詳細テーブルと集約
テーブルの両方ですべての更新をロールバックし、同期を保証する方法です。バー
ジョン管理されないデータベースでは、これらの方法を実行することができませ
ん。
クエリ書き換えシステムと集約保守の詳細については、『IBM Red Brick Vista User’s
Guide』を参照してください。
6-6 Administrator’s Guide
ディメンジョン テーブルのクリーニング
ディメンジョン テーブルのクリーニング
バージョニングを使用すると、稼動時間中にディメンジョン テーブルのデータをク
リーニングすることが可能になります。ディメンジョン テーブルのクリーニングに
は、不要な行の削除、製品の説明や顧客住所の変更、あるいは初期ロードの際に参
照整合性チェックで除かれた行を追加するなどの作業があります。バージョニング
は、このようなデータを稼動時間中に更新して、ユーザが最新のデータを使用でき
るようにできます。
バージョン ログのコスト
バージョン ログのコストは比較的小さく、以下のものが含まれます。
■
ディスク領域
クエリ性能を保つには、バージョン ログを専用のサブシステムに格納する
必要があります。できれば専用のディスク ドライブを数台使います。バー
ジョン ログの設定およびサイズ見積もりに関する詳細は、6-18 ページ
「バージョン ログの作成」を参照してください。
■ 入出力の増加
バージョン管理されたデータベースを変更すると、変更済みブロックはま
ずすべてバージョン ログに書き込まれます。その後、改めてデータベース
ファイルに書き込まれるため、入出力が増加します。逆にまったく新しい
ブロックの場合、バージョン ログではなくデータベースに直接書き込まれ
ます。バージョン管理されたトランザクションで新規ブロックを作成する
場合、入出力コストはほとんど増加しません。
■ バージョン ログ管理のコスト
バージョン ログは極めて複雑というわけではありませんが、システム全体
を複雑化します。
新規セグメントに新規テーブル データおよび新規インデックス データを追加する
ロード操作では、バージョニングのコストは小さくなります。これはデータベース
内の既存ブロックがごく少数しか変更されないため、バージョン ログに書き込まれ
るブロックが少なくなるからです。新規データはデータベースのテーブルとイン
デックスの PSU に直接送られます。バージョン ログは、書き込まれるブロック数
が比較的少ない場合に最高の効率を発揮します。バージョン ログに書き込まれるブ
ロックの数が増えると、後でデータベース ファイルに書き込まれるブロック数も増
え、結果的に入出力が増加します。
バージョン管理されたデータベースの使用
6-7
バージョン管理されたデータベースへのデータのロード
バージョン管理されたデータベースへのデータ
のロード
バージョニングが TMU に直接影響することはありませんが、バージョン管理され
たロード後の入出力がボトルネックとなってバージョン ログへのアクセスに支障が
おき、システムの性能が低下することが考えられます。ボトルネックが発生するの
は、バキューム クリーナがバージョン ログを読んでいるときに、クエリがデータ
ベース ファイルではなくバージョン ログのデータにアクセスしており、さらに
ユーザがデータベースの変更 ( バージョン ログに書き込み ) を行っている可能性が
あるためです。
バージョン管理された TMU ロードの後で効率が低下する主因は、変更される既存
のデータベース ブロック数です。ブロックが主に新規のもので、変更されるものが
ほとんどない場合は、効率への影響はごくわずかです。
TMU はデータベースの整合性を維持するために必要なものはすべて更新するため、
TMU 操作で変更されるブロック数を分析する場合は、以下の点すべてを考慮する
必要があります。
■
■
■
■
6-8 Administrator’s Guide
テーブル中で変更される既存の行数
参照テーブルへの変更の有無
操作によるインデックスへの変更の有無
維持される集約テーブルおよびそのインデックスへの変更の有無
バージョン管理されたデータベースへのデータのロード
例題 1
次の図のような、3 つのディメンジョン テーブルを参照する 1 つのファクト テーブ
ルを持ったシンプル スター スキーマがあります。
Product
...
図 6-1
シンプル スター
スキーマ
Fact1
Period
...
...
Market
...
ファクト テーブル (Fact1) は月別にセグメント化されていると仮定します ( 値は
Period テーブルのものです )。さらに、Fact1 テーブルの 3 つのフォーリン キーに 1
つの STAR インデックスが作成されており、これもまた月別にセグメント化されて
いると仮定します。ほかには 3 つのディメンジョン テーブルのプライマリ キー BTREE インデックスがあるのみです。
ファクト テーブルと STAR インデックスがセグメント化されているため、このデー
タベースにロードされるデータの月が変わると、テーブルのデータはすべて新しい
Fact1 テーブルのセグメントに格納され、対応するインデックスのデータもすべて
新しい STAR インデックスのセグメントに格納されます。その結果、新しい月の
データがロードされたときには変更済みデータがないことになります。
この場合は、バージョン管理されたモードでデータをロードしても、バージョン ロ
グに書き込まれるテーブルやインデックスのデータがないため、バージョン ログに
対する入出力は増加しません。データが新しいため、すべてデータベース ファイル
に書き込まれ、バージョン ログには変更済みブロックだけが書き込まれます。
バージョン管理されたデータベースの使用
6-9
バージョン ログについて
例題 2
例題 1 と同じ事例を検討します。ただし、ファクト テーブルにはフォーリン キー列
ごとに 1 つずつで、合計 3 つの TARGET インデックスがあります。STAR インデッ
クスの場合とは異なり、TARGET インデックスはデータのようにセグメント化され
ず、データベースに収録されている全期のデータが格納されています。ここで新し
い月のデータをロードすると、TARGET インデックスの多数のブロックが変更さ
れ、それぞれバージョン ログに書き込まれます。この操作でバージョン ログ ファ
イルへの入出力が増え、トランザクションがコミットされた後の効率の低下が予想
されます。
このコストを、バージョン管理されたロードの利点と対比して検討してください。
ユーザがデータベースに 1 日 24 時間、年中無休のアクセスを要求するのであれば、
オーバーヘッドが増えてもそれだけの価値があるといえますが、夜間には誰もシス
テムを利用せず、システム停止時間に容易に LOAD 操作を実行できるのであれば、
ブロック化 LOAD 操作を実行してオーバーヘッドを減らす方が望ましいといえま
す。
バージョン ログについて
バージョン ログには、INSERT、UPDATE、DELETE、および特定の TMU 操作で変
更されたデータ ブロックが格納されるので、データベースの新規リビジョンをロー
ドして検証する間、データを別に格納しておくことが可能になります。ユーザは、
ロード処理がすべて完了した後か、または 6-5 ページ「定期コミットを行うロード」
で説明しているとおり、一定間隔でリビジョンにアクセスできます。また、
6-13 ページ「凍結バージョンについて」で説明しているとおり、ユーザが利用でき
るバージョンを凍結することもできます。6-16 ページ「高復旧性オプションを使用
したデータのロード」で説明しているとおり、高復旧性オプションを使用すること
により、バージョン ログを従来型の先行書き込みログとして使用することもできま
す。
バージョン ログのデータは、バキューム クリーナ デーモンによって、または高復
旧性オプションを使用している場合は TMU によって、データベース ファイルに
マージされます。次に、バキューム クリーナ デーモンまたは TMU によってバー
ジョン ログの領域が解放され、再利用できるようになります。バキューム クリー
ナに関する詳細は、1-13 ページ「バキューム クリーナ デーモン」を参照してくだ
さい。
6-10 Administrator’s Guide
バージョン ログの構造
バージョン ログの構造
バージョン ログは最大 250 の独立した物理格納ユニット (PSU) を収容できる 1 つの
セグメントに格納されます。各 PSU は 1 つのオペレーティング システム ファイル
をマッピングします。データベースの物理格納ユニットはブロックに分割されてい
ます。IBM Red Brick Warehouse の各データベース ブロックは 8KB の単位でディスク
領域を使用します。次の図は、5 個のブロックで構成されたデータベースを示しま
す。
図 6-2
データベース
データベース
ブロック
DB0
DB1
DB2
DB3
DB4
データベースの最初のブロック名は DB0、最後のブロック名は DB4 です。クエリ
がデータベース全体を読み取る場合、各ブロックを次の順に読み取ります。
(DB0), (DB1), (DB2), (DB3), (DB4)
データベースがバージョン管理されていて、バージョン ログを持っていると仮定し
ます。トランザクションによってデータベースの DB0 が変更され、その変更がコ
ミットされると、そのブロックの新しいバージョンがそのブロックのリビジョン番
号 1 としてバージョン ログに格納されます。
図 6-3
データベース
DB0
バージョン ログ
( ブロック番号、リビジョン番号 )
VL0,1
最初のトランザク
ションの後の
バージョン ログ
DB1
DB2
DB3
DB4
バージョン管理されたデータベースの使用 6-11
バージョン ログの構造
この時点では、クエリがデータベース全体を読み取る場合、以下のブロックが読み
取られます。
(VL0,1), (DB1), (DB2), (DB3), (DB4)
別のトランザクションがデータベースのブロック 0 およびブロック 2 を変更すると、
結果は以下のようになります。
図 6-4
バージョン ログ
データベース ( ブロック番号、リビジョン番号 )
DB0
VL0,1
DB1
VL0,2
DB2
VL2,1
第 2 のトランザク
ションの後のバー
ジョン ログ
DB3
DB4
新規トランザクションは、データベースの最新バージョンを読み取ります。この例
ではブロック 0 に 2 つのリビジョンが格納されるため、最新リビジョンはリビジョ
ン番号 2 となります。したがって、クエリがデータベース全体を読み取る場合、以
下のブロックが読み取られます。
(VL0,2), (DB1), (VL2,1), (DB3), (DB4)
上記の例では、操作中にバキューム クリーナによるブロックのクリーニングが実行
されていないことを前提とします。クリーニングが実行された場合、そのブロック
はバージョン ログからデータベース ファイルに移動されます。バキューム クリー
ナに関する詳細は、6-25 ページ「バキューム クリーナの制御」を参照してくださ
い。
6-12 Administrator’s Guide
バージョン管理された DELETE 操作
バージョン管理された DELETE 操作
バージョン管理されたデータベースで DELETE 操作を実行する場合、削除されたブ
ロックは変更済みブロックとして扱われ、バージョン ログに書き込まれます。セグ
メントまたはテーブル内のブロック数と比較して少数のブロックを削除するかぎ
り、この方法に問題はありません。このタイプのバージョン管理された DELETE 操
作を使用すると、操作を実行中もユーザがテーブルを検索することが可能になりま
す。
ただし、セグメント全体またはテーブル全体に対するバージョン管理された
DELETE 操作は、削除する各ブロックの新しいバージョンを作成し、これらをデー
タベース ファイルに書き込まなければならないため、性能が低下することがありま
す。これによって必要なバージョン ログとトランザクション入出力のサイズが大き
くなります。さらに、テーブル内のブロックが空のブロックとして残るため、その
テーブルに対する後続のロード操作は、各ブロックの別のバージョンを作成しま
す。
テーブル内のすべてのブロックを削除する場合は、バージョン管理されていないト
ランザクションとして実行するか、または割り当てられたブロックがない状態にセ
グメントをリセットする、ブロッキング専用の ALTER SEGMENT CLEAR 操作を使
用した方が、効率よく実行できます。
凍結バージョンについて
すべてのクエリがデータベースの同じバージョンを読み取るようにするには、凍結
バージョン モードを使います。このモードは、データベースの現在のバージョン
を、今後行われる検索処理すべてに使用するデフォルトの読み取りリビジョンとし
て設定します。バージョンが凍結されていないない場合、バージョン管理された
データベースの検索は処理が開始された時点での最新のリビジョンを読み取るた
め、ごくわずかな時間をおいて実行されたクエリであっても、その間にデータが更
新され、次の例のように、異なるデータ セットにアクセスするということも起こり
得ます。
バージョン管理されたデータベースの使用 6-13
凍結バージョンについて
例
1 分おきに実行される 3 つのクエリがあるとします。最初のクエリが開始すると、
UPDATE 操作によって、データベースへの変更がコミットされます。2 つ目のクエ
リが開始すると、別の UPDATE 操作によってその変更がコミットされます。次に、
3 つ目のクエリが開始します。凍結バージョン機能を使用していない場合、これら
の各クエリは、以下の図に示すように、それぞれ異なるバージョンのデータベース
にアクセスします。
図 6-5
凍結バージョンがない場合のクエリの動作
データ
ベース
バージョン ログ
( ブロック番号、
リビジョン番号 )
データ
ベース
DB0
DB0
DB1
DB2
12:00
VL0,1
データ
ベース
バージョン ログ
( ブロック番号、
リビジョン番号 )
DB0
VL0,1
DB1
DB1
VL0,2
DB2
DB2
VL2,1
UPDATE 操作 1
ブロック 0 を変更します。
クエリ 1
(DB0), (DB1), (DB2)
バージョン ログ
( ブロック番号、
リビジョン番号 )
12:01
UPDATE 操作 2
ブロック 0 と 2 を変更します。 12:02
クエリ 2
(VL0,1), (DB1), (DB2)
時間
クエリ 3
(VL0,2), (DB1), (VL2,1)
この例では、クエリ 1 はデータベース ファイルのブロックだけを読み取り、クエリ
2 およびクエリ 3 は一部のブロックをデータベース ファイルから、その他のブロッ
クをバージョン ログから読み取ります。各クエリは、現在データベース ファイル
に格納されたデータであるか、バージョン ログに格納されたデータであるか、また
はその両方に格納されているかにかかわらず、直前にコミットされたデータベース
のバージョンを読み取ります。
ALTER DATABASE FREEZE QUERY REVISION 文を使用してバージョンを 12 時か、
それ以前に凍結すると、その後のクエリは、(DB0)、(DB1)、および (DB2) と、同じ
ブロックを読み取ります。これによって結果の整合性が確保されます。
6-14 Administrator’s Guide
凍結バージョンについて
凍結バージョン モードでは、データベースには以下の変更しかできません。
■
■
■
■
SET USE LATEST VERSION ON 文によるバージョニング操作
テンポラリ テーブルの操作 ( セッション内だけのテーブルであるため )
テーブル構造に影響しないテーブルの変更 ( コメントの追加など )
CREATE TABLE や CREATE SEGMENT のように既存のデータベース オブ
ジェクトに影響しない操作
凍結バージョン モードのバージョニング データベースで、以下の文を使用するに
は、まず SET USE LATEST REVISION ON 文を使用して凍結バージョン モードを解
除します。凍結バージョンのオンとオフの切り替えの詳細については、6-21 ページ
「凍結バージョンの制御」を参照してください。
凍結バージョン モードでは、以下の操作が実行できます。
■
CREATE TABLE
■
CREATE SEGMENT
■
CREATE VIEW
■
CREATE INDEX...DEFERRED
■
CHECK TABLE
■
CHECK INDEX
■
■
テンポラリ テーブルに対する DROP TABLE
すべての DML コマンド
❑
SELECT
❑
UPDATE
❑
INSERT
❑
DELETE
凍結バージョン モードでは、以下の操作は実行できません。
■
ALTER TABLE
■
ALTER INDEX
■
ALTER SEGMENT 文
■
CREATE INDEX
■
テンポラリ テーブルに対する場合を除くすべての DROP コマンド
バージョン管理されたデータベースの使用 6-15
高復旧性オプションを使用したデータのロード
高復旧性オプションを使用したデータのロード
ロード中に高い復旧性が必要ですが、並行クエリの実行機能は必要でない場合、
SET TMU VERSIONING RECOVER 文を使用して、バージョン ログを従来型の先行
書き込みログとして使用します。
高復旧性モードのローダは、並行クエリを防止するブロッキング ロックをテーブル
に適用します。そのため、高復旧性オプションを使用したロードは、テーブルに排
他的にアクセスする、夜間の大量のロード操作に適しています。このオプション
は、並行クエリが実行可能になるような、連続的なデータ入力が行われる環境には
適していません。
ほかのバージョニング オプションと同様に、高復旧性オプションを使用したロード
では、データをまずバージョン ログに書き込みます。次に、ロードのコミット時
に、( バキューム クリーナ デーモンではなく ) TMU が変更済みブロックを、バー
ジョン ログからターゲット データベース テーブルに移動します。高復旧性オプ
ションを指定して並列 TMU を使用する場合、並列 TMU がロードとクリーニングを
並列に実行します。
高復旧性オプションは REORG 操作と OFFLINE LOAD 操作には使用できません。高
復旧性オプションを使用したロードは、クエリ リビジョンの凍結中は実行できませ
ん。
バージョニングの制御
バージョン管理されたデータベースを作成して、有効にするには、通常以下の手順
を実行します。各手順の詳細は、この後の節で説明します。バージョン ログのサイ
ズを増やす方法、および凍結バージョン モードの使用方法は、このあとの節で説明
します。
バージョン管理されたデータベースの作成と有効化
1.
2.
6-16 Administrator’s Guide
CREATE SEGMENT 文でバージョン ログを格納するセグメントを作成しま
す。
ユーザがデータベースに接続していないことを確認します。必要であれ
ば、ALTER SYSTEM QUIESCE 操作、または ALTER SYSTEM CANCEL
USER SESSION 操作を実行します。
バージョニングの制御
3.
4.
ALTER DATABASE CREATE VERSION LOG 文を使ってバージョン ログを
作成します。
このコマンドは、すべての物理領域をバージョン ログに割り当てるため、
終了するまでに時間がかかることがあります。このコマンドを実行する前
にほかのすべてのユーザがシステムからログオフしていなければならず、
また、バージョン ログの初期化中はこのデータベースに対するすべての接
続が拒否されます。
ALTER DATABASE START VERSIONING 文を実行して、バージョニングを
開始します。
上記の手順で、バージョン管理されたデータベースがセットアップできます。サー
バ操作をバージョン管理されたトランザクションとして同時実行する場合は、次の
ように入力してバージョニングをオンに設定します。
■
■
rbw.config ファイルに OPTION VERSIONING ON と記述し、全ユーザ セッ
ションを制御
SET VERSIONING ON 文で、現在の RISQL セッションを制御
TMU 操作をバージョン管理されたトランザクションとして実行する場合は、次の
ように入力してバージョニングをオンに設定します。
■
■
rbw.config ファイルに OPTION TMU_VERSIONING ON と記述し、全ユーザ
セッションを制御
SET TMU VERSIONING ON 文で、現在の RISQL セッションを制御
同時実行ではなく、高復旧性を得るためにバージョニングをオンに設定するには、
ON の代わりにキーワード RECOVER を使用します。
バージョニングが ON または RECOVER に設定されているにもかかわらず、データ
ベース内にバージョン ログが存在しない場合、またはデータベースのバージョニン
グが (ALTER DATABASE START VERSIONING によって ) 有効になっていない場合
は、データベースを更新するすべてのトランザクションがエラーとなり失敗しま
す。
バージョン管理されたデータベースの使用 6-17
バージョン ログの作成
バージョン ログの作成
1 日の間に行われるデータベースへの小さな変更は大きなバージョン ログを必要と
しませんが、バージョン ログのサイズと変更済みデータに対するクエリの要求が増
えるにつれて、環境設定とサイズ見積もりの重要性が高まります。
バージョン ログの主な性能上のコストは、データが最初バージョン ログに書き込
まれ、後でバキューム クリーナによってデータベースに再び書き込まれることに
よって発生するディスク入出力の増加です。バージョン ログを高性能のデバイス上
でに格納すると、性能上のコストを最小限に抑えられます。
IBM では、最高の性能を得るために、バージョン ログを次の方法で格納するよう推
奨しています。
■
■
データベースから分離された専用の格納サブシステムの設置。数台の独立
したディスク ドライブがあれば理想的です。
ディスク ストライピング、または RAID レベル 0、またはレベル 1 デバイ
スの使用。
バージョン ログを複数のディスク、または RAID デバイスに格納すると、
複数のディスクに対する入出力が同時に実行できるため、クエリ操作に対
する性能上の影響が少なくなるか、影響がなくなります。
CREATE SEGMENT 文でバージョン ログを格納するセグメントを作成します。ディ
スクに領域を確保するため、すべてがバージョン ログの作成時に割り当てられま
す。バージョン ログに書き込まれるデータの量は、変更中の既存データベース内の
ブロック量に比例します。新規ブロックはバージョン ログには書き込まれず、デー
タベース ファイルに直接書き込まれます。
バージョン ログ セグメントに必要なサイズは、データベース内の変更済みブロッ
ク数 (1 ブロック当たり 8KB) にオーバーヘッドとして約 20% 加算した合計 KB 数、
または MAXSIZE ですが、この数値の推定は難しいため、IBM では現実的なデータ
ベースを設定して直接測定するよう推奨しています。バージョン ログのサイズの決
定に関する詳細は、6-23 ページ「バージョン ログの監視」を参照してください。
バージョン ログ セグメントのサイズを過大に見積もっても性能にはほとんど影響
はありませんが、見積もりが小さすぎて実行中にバージョン ログの領域が不足する
と、トランザクションは中止され、データベースを破損することはなくても、実行
した変更部分が消失してしまいます。
バキューム クリーナ デーモンがあるリビジョンをバージョン ログから取り出せる
のは、それ以前のリビジョンにアクセスしているクエリがないときです。実行時間
の長いクエリがあるとクリーニングを実行できないため、バージョン ログのサイズ
が増えることがあります。凍結バージョン モード機能は実質的には実行時間の長い
クエリであり、同様にバージョン ログのサイズを増やします。
6-18 Administrator’s Guide
バージョン ログのクリーニング
バージョン ログのクリーニング
チェックポイント バックアップなどの操作の準備としてバージョン ログをクリー
ニングするには、ALTER DATABASE CLEAN VERSION LOG 文を使用します。この
文はブロッキング文です。データベースに読み込みロックを設定してから実行して
ください。この文の構文の詳細については、
『SQL Reference Guide』を参照してくだ
さい。
ALTER DATABASE CLEAN VERSION LOG 文を使用すると、バージョン ログを削除
前にクリーニングすることもできます。バージョン ログを削除する場合、データ
ベースをロックする必要はありません。バージョニングを停止し、バージョン ログ
をクリーニングして削除してください。
システムをバックアップから復元する前にバージョン ログをクリーニングするに
は、ALTER DATABASE CLEANVERSION LOG 文の REMOVE DAMAGED
SEGMENTS オプションを使用します。このオプションによって、損傷したセグメ
ントがバージョン ログから削除されます。これを削除しないと、情報が消失するこ
とがあります。このオプションを設定しなかった場合、損傷したセグメントがバー
ジョン ログに残るため、バージョン ログを削除できません。
バージョン ログが空か、バージョン ログ内に損傷したセグメントが見つかると、
ALTER DATABASE CLEAN VERSION LOG 文は復帰します。バックアップ操作に進
む前に、バージョン ログが空であることを必ず確認してください。
バージョン ログが空であることを確認する方法は、以下のとおりです。
select dbname FROM dst_databases
where dbname = '<Database_name>'
and current_revision <> latest_merged_revision;
<Database_name> はデータベースの名前です。このクエリが行を返さなかった場合、
バージョン ログは空です。
バージョン ログが空にならないと、クエリは古いリビジョンをアクセスし、クリー
ニングできません。クエリの READ_REVISION 値が最小になっているかどうか、
DST_COMMANDS テーブルを調べてください。その後必要に応じて、ADMIN デー
タベースのクエリを終了します。
クエリのリビジョンが凍結されている場合、データベースが凍結解除されるまで、
バキューム クリーナはバージョン ログのクリーニングを完了できません。
データベースのバックアップ方法については、6-24 ページ「バックアップと復旧」
を参照してください。
バージョン管理されたデータベースの使用 6-19
バージョン ログの削除と領域の追加
バージョン ログの削除と領域の追加
データベースのバージョン ログに領域を追加するには、まずそのバージョン ログ
を削除し、改めて大きいサイズを指定して再作成します。
1.
次のステートメントを入力して、データベースのバージョニングを停止し
ます。
alter database stop versioning;
2.
このステートメントは、新規のバージョニング トランザクションを禁止し
ます。
バージョン ログをクリーニングします。
alter database clean version log;
3.
詳細は、6-19 ページ「バージョン ログのクリーニング」を参照してくださ
い。
バキューム クリーナによってバージョン ログが空になるまで待ちます。
バージョン ログが空になると、DST_DATABASES テーブルの
CURRENT_REVISION 列の値が LATEST_MERGED_REVISION 列の値に
等しくなります。
RISQL> select current_revision, latest_merged_revision
from dst_databases;
CURRENT_REV LATEST_MERG
1
1
4.
5.
ユーザがデータベースに接続していないことを確認します。必要であれ
ば、ALTER SYSTEM QUIESCE 操作、または ALTER SYSTEM CANCEL
USER SESSION 操作、あるいはその両方を実行します。
バージョン ログを削除します。
alter database drop version log;
6.
7.
バージョン ログ セグメントに PSU を追加するか、既存の PSU の最大サイ
ズを増やすことで、ALTER SEGMENT 操作を使ってセグメントに領域を追
加します。
次の例を参考にして、バージョン ログを再作成します。
alter database create version log in
version_log_segment;
8.
データベースのバージョニングを再開します。
alter database start versioning;
6-20 Administrator’s Guide
凍結バージョンの制御
凍結バージョンの制御
バージョンを凍結すると、データベース サーバは、現行リビジョン番号を読み取
り、デフォルトの読み取りリビジョン番号として設定します。セッションで特に無
効にしない限り、後続のすべてのクエリがこのリビジョン番号を使用します。バー
ジョンを凍結するには、データベース管理者のロールが必要で、最初にバージョニ
ングを有効にする必要があります。
警告 : 現在のバージョンを凍結すると、バキューム クリーナによる後続リビジョ
ンのクリーニングができなくなるため、バージョン ログの格納に必要な領域が増加
します。
データベースの凍結
次の SQL 文で、データベースを現在のリビジョンに凍結します。
alter database freeze query revision;
クエリ リビジョンがすでに凍結されている場合、処理は失敗します。凍結バージョ
ン モードは持続的で、システムの故障や再起動でも解除されません。
この SQL 文が実行されると、データベース サーバはクエリ リビジョンとして選択
されたリビジョン番号を表示します。読み取りリビジョン番号は、
DST_DATABASES テーブルの QUERY REVISION 列でいつでも参照できます。リ
ビジョンが凍結されていない場合、この列の値は NULL です。
RISQL コマンドがアクセスしているデータベースのリビジョン番号を確認するに
は、以下のように入力します。
select read_revision from dst_commands;
where command like 'select read_revision from dst_commands%';
凍結バージョンの無効化
特定のユーザ セッションで凍結バージョン モードを無効化して、現在のリビジョ
ンを使用するには、以下の SET コマンドを使います。
set use latest revision on;
凍結クエリ モードのときにデータベースを更新するには、この SET コマンドが ON
になっているセッションを使う必要があります。
バージョン管理されたデータベースの使用 6-21
凍結バージョンの制御
データベースの凍結解除
データベースの凍結を全ユーザ セッションに対して解除するには、以下の SQL 文
を実行します。
alter database unfreeze query revision;
凍結バージョンでのデータのアンロード
TMU アンロード操作は実質的にクエリとして機能します。デフォルトでは、テー
ブルをアンロードするときに、TMU は現在のクエリ リビジョン ( 凍結バージョン )
ではなく、最新のリビジョンを使用します。凍結バージョンを指定するには、TMU
UNLOAD コマンドに USING QUERY REVISION オプションを挿入します。凍結バー
ジョンがない場合、UNLOAD コマンドは最新のリビジョンを使用し、メッセージ
は返しません。
凍結バージョンと高復旧性の使用
凍結バージョンと、高復旧性オプションを指定したロードを、同じテーブルで同時
に使用することはできません。高復旧性を備えたロードは排他的な操作です。両方
の機能を同じテーブルで同時に使用すると、エラーが発生する可能性があります。
6-22 Administrator’s Guide
バージョン管理されたデータベースのメンテナンス方法
バージョン管理されたデータベースのメンテナ
ンス方法
割り当てた領域をすべて使用するバージョン ログをセットアップすると、メンテナ
ンスの必要はほとんどありません。ただし、バージョン管理されたデータベースの
メンテナンスについては、特別な考慮点がいくつかあります。
バージョン ログの監視
バージョン ログの動作を監視して、割り当てたディスク領域が多すぎたり、少なす
ぎたりしないかを確認してください。バージョン ログがいっぱいになっている場合
は、追加領域の割り当てを行うか、あるいは環境設定をし直すかを検討します。領
域の追加に関する詳細は、6-20 ページ「バージョン ログの削除と領域の追加」を参
照してください。環境設定に関する詳細は、6-18 ページ「バージョン ログの作成」
を参照してください。
バージョン ログが使用する領域の監視には、DST_DATABASES テーブルの以下の
列を参照してください。
列名
説明
VERSION_LOG_USED
バージョン ログで新規バージョンのデータベース ブロックが使
用するディスク領域を表示 ( 単位 : KB)。バージョン ログが存在
しない場合は NULL となります。
VERSION_LOG_ AVAILABLE
バージョン ログで使用可能なディスク空き容量 (KB)。バージョ
ン ログが存在しない場合は NULL となります。
VERSION_LOG_ MAXIMUM_USED
バージョン ログに使用可能な最大ディスク容量 (KB)。最高水準
とも呼ばれる。ALTER SYSTEM RESET STATISTICS 文でリセッ
ト可能。バージョン ログが存在しない場合は NULL となります。
詳細は、8-6 ページ「動的統計テーブルによるデータベース動作の監視」を参照し
てください。
監視情報はイベント ログのメッセージからも得られます。バージョン ログが容量
の 90 % に達すると、イベント ログに警告メッセージが送られます。イベント ログ
に関する詳細は、第 8 章「組織におけるデータベース運用の管理」を参照してくだ
さい。
バージョン管理されたデータベースの使用 6-23
バックアップと復旧
バックアップと復旧
チェックポイント バックアップ、部分的な復元操作、または全面的な復元操作を実
行する前、あるいはバージョン管理されたデータベースをコピーまたは移動すると
きは、バージョン ログを空にする必要があります。オンライン バックアップでは、
バージョン ログを空にする必要はありません。
復旧性を確保するためにバージョニングを行う場合は、データのロード後にチェッ
クポイント バックアップを実行します。同時実行のためにバージョニングを行う場
合は、以下の手順を完了してからチェックポイント バックアップを実行します。確
実な復元ができるよう、これらのバックアップは適切なバックアップ方法に従って
実行します。TMU のガイドラインおよびバックアップ方法の詳細については、
『Table Management Utility Reference Guide』を参照してください。
同時実行のためにバージョニングを使用する場合の、チェックポイント
バックアップの準備方法
1.
バックアップする PSU のリストを生成します。
2.
このクエリは PSU のリストとそれらのサイズを返します。
読み取りロックを使用してデータベースをロックします。
3.
読み取りロックを使用すると、並行クエリは実行可能ですが、更新は行わ
れません。詳細は、9-6 ページ「テーブルとデータベースの手動ロック」を
参照してください。
バージョン ログをクリーニングします。
4.
詳細は、6-19 ページ「バージョン ログのクリーニング」を参照してくださ
い。
バージョン ログが空であることを確認します。
select used, physical_location from rbw_storage;
lock database read;
alter database clean version log;
select dbname from dst_databases
where dbname = '<Database_name>'
and current_revision <> latest_merged_revision;
<Database_name> はデータベースの名前です。このクエリが行を返さない
場合、データベースを安全にバックアップできます。
データベースの破損が著しいためにバージョン ログが空にならない場合は、IBM テ
クニカル サポートにご連絡ください。バージョン ログの削除方法は、6-20 ページ
「バージョン ログの削除と領域の追加」を参照してください。
バックアップ操作および復元操作の詳細については、『Table Management Utility
Reference Guide』を参照してください。
6-24 Administrator’s Guide
バキューム クリーナの制御
バキューム クリーナの制御
バキューム クリーナはバージョン ログ内にコミットされたデータをデータベース
ファイルに移動します。バージョン管理されたデータベース 1 つにつき 1 個のバ
キューム クリーナが存在します。データがバージョン ログにコミットされると、
バキューム クリーナは以前のバージョンのデータにアクセスしているすべてのクエ
リが終了するまで待機してから、新たに更新したデータをデータベース ファイルに
書き込みます。さらに、バキューム クリーナは、新しいトランザクションが使用す
るバージョン ログ内の領域を解放します。
バキューム クリーナはその処理をバックグラウンドで実行し、データベース サー
バ上のほかの操作に悪影響を及ぼさずに、バージョン ログをクリーニングします。
性能に悪影響を及ぼしていると思われる場合、管理者はバキューム クリーナの開始
および停止を手動で制御できます。バキューム クリーナを停止するとバージョン
ログが領域不足になる可能性があるため、通常はバキューム クリーナを停止しない
でください。
バージョン管理されたデータベースを変更するブロッキング トランザクション ( た
とえば、SET TMU VERSIONING OFF オプションを指定した LOAD 操作 ) を実行す
る場合、バキューム クリーナはトランザクション実行前にバージョン ログをク
リーニングします。次に、ブロッキング トランザクションが、バージョン ログ上
ではなく、データベース ファイル上のみで処理を実行します。
バキューム クリーナは、クエリが以前のバージョンの読み込みを終了するまで待機
してから、新しいバージョンをデータベース ファイルに再び書き込むため、データ
ベースにユーザが接続していないときもバキューム クリーナがシステム上で動作し
ている可能性があることに注意してください。
バキューム クリーナを手動で無効にするには、以下の文を入力します。
alter database stop cleaning;
上記のコマンドを使用すれば、クリーニング実行のタイミングを制御できます。バ
キューム クリーナは、入出力集約型プロセスであるため、同じデバイス上で大量の
入出力を実行するクエリが存在する場合に、性能上のボトルネックとなることがあ
ります。
警告 : バキューム クリーナを手動で停止するとバージョン ログが領域不足になる
可能性があります。領域不足になると、トランザクションは中止され、バージョン
ログへの変更は廃棄され、データベースは以前の状態のままとなります。
バージョン管理されたデータベースの使用 6-25
例 : バージョン管理された Aroma データベースの作成
バキューム クリーナを手動で停止後、システムの使用率が低くなった時点で再び開
始するには、以下の文を入力します。
alter database start cleaning;
例 : バージョン管理された Aroma データベー
スの作成
Aroma サンプル データベースは IBM Red Brick Warehouse インストール時に作成さ
れます。Aroma データベースは、約 69,000 行のデータを格納した小売業用データ
ベースです。Aroma データベースで同時実行用にバージョニングを有効にするに
は、以下の手順を実行します。
1.
2.
Aroma データベースを作成します。Aroma を削除してしまった場合は、付
録 A 「例 : データベースの作成」の説明を参照し、再作成してください。
バージョン ログを格納するセグメントを作成します。RISQL プロンプトか
ら、以下の文を入力します。
RISQL> create segment versionlog
storage 'version.log' maxsize 10000;
3.
次のコマンドを入力し、新規作成したセグメントにバージョン ログを作成
します。
4.
次のコマンドを入力し、バージョニングを開始します。
5.
コンフィグレーション ファイルのパラメータ OPTION VERSIONING ON を
使用してグローバル レベルでバージョン管理されたトランザクションを有
効にするか、または次のコマンドを入力してこのセッション レベルで有効
にします。
RISQL> alter database create version log in versionlog;
RISQL> alter database start versioning;
RISQL> set versioning on;
これで、データベースのクエリと更新を同時に実行できます。
6-26 Administrator’s Guide
第7章
データベースのアクセス権
とセキュリティ
データベース ユーザの追加 . . . . . . . .
オペレーティング システムのアカウントの作成
データベース アクセス権の付与 . . . . . .
パスワードの変更 . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
7-3
7-4
7-5
7-6
システム ロールによるアクセス権の付与 . . . . . . . . .
DBA、RESOURCE、CONNECT の権限 . . . . . . . .
DBA および RESOURCE システム ロールの付与と取り消し .
. .
. .
. .
7-7
7-7
7-8
データベース オブジェクト特権の付与
.
.
.
.
.
.
.
.
.
.
.
7-9
ロールに基づくセキュリティでのアクセス権の設定 .
タスク権限 . . . . . . . . . . . . . .
ロール権限 . . . . . . . . . . . . . .
ロールの作成 . . . . . . . . . . . . .
タスク権限の付与 . . . . . . . . . . . .
ロールへのオブジェクト特権の付与 . . . . .
ロールの付与 . . . . . . . . . . . . .
タスク権限、オブジェクト特権、ロールの取り消し
ロールの権限とメンバーの監視 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-11
7-12
7-14
7-15
7-16
7-16
7-18
7-21
7-23
パスワードのセキュリティ管理 . . . . . . . .
パスワードの強制変更 . . . . . . . . . .
パスワード期限切れの警告 . . . . . . . .
パスワード再使用の制限 . . . . . . . . .
パスワード変更頻度の制限 . . . . . . . .
パスワードでのログイン名の使用制限 . . . .
最初のログイン時での初期パスワードの強制変更
変更前後のパスワードに関する強制 . . . . .
パスワードの文字の組み合わせと長さの指定 . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7-26
7-27
7-29
7-30
7-31
7-32
7-32
7-32
7-34
接続失敗によるユーザ アカウントのロック . . . .
ロックされたアカウントの状態 . . . . . . .
7-2 Administrator’s Guide
. . . .
. . . .
.
.
7-36
7-37
この章について
データベース管理者は、管理者用のユーザ アカウントでデータベースにアクセスす
ることができます。ほかのユーザにもアクセス権を与えるには、データベースに接
続する権限と、データベースで処理操作を実行する権限を与える必要があります。
セキュリティを維持するため、どのユーザがデータベースに接続でき、どのような
データベース操作を実行できるかを決定します。各データベースにユーザを登録
し、パスワードと適切なアクセス権を与えることにより、セキュリティを管理しま
す。
この章では、データベースのアクセスとセキュリティについて説明します。
■
■
■
■
■
データベース ユーザの追加
システム ロールによるアクセス権の付与
データベース オブジェクト特権の付与
ロールに基づくセキュリティでのアクセス権の設定
パスワードのセキュリティ管理
データベース ユーザの追加
LAN に接続したクライアント アプリケーションからデータベースにアクセスする
ユーザには、オペレーティング システムのアカウントを作成する必要はありませ
ん。ただし、RISQL エントリ ツールまたは RISQL レポータからデータベースにロー
カルでアクセスするユーザには、オペレーティング システムのアカウントを作成し
て、システムにログインするためのアクセス権を与える必要があります。
クライアント ツール、RISQL エントリ ツール、RISQL レポータからユーザがデー
タベースにアクセスできるようにするには、SQL の GRANT 文でデータベースのア
クセス権を付与する必要があります。
データベースのアクセス権とセキュリティ
7-3
オペレーティング システムのアカウントの作成
オペレーティング システムのアカウントの作成
UNIX
IBM Red Brick Warehouse をインストールし、データベースにユーザを追加する準備
ができたら、以下を確認してください。
■
■
■
各ユーザのパスに、redbrick_dir/bin ディレクトリが存在する。
環境変数 RB_CONFIG および RB_HOST が正しく初期化され、各ユーザが
アクセスできる。
環境変数 RB_PATH が正しく設定され、各ユーザがアクセスできる ( 単一
データベース環境の場合 ) か、または rbw.config ファイルに各ウェアハウ
スのデータベース論理名が設定されている。
Korn シェルを用いるユーザ アカウントでパスと環境変数を profile ファイルで設定
する方法を示します。
...
PATH=$PATH:/usr/<redbrick_dir>/bin;export PATH
RB_CONFIG=/usr/<redbrick_dir>; export RB_CONFIG
RB_HOST=RB_HOST; export RB_HOST
...
♦
Windows
IBM Red Brick Warehouse をインストールし、データベースにユーザを追加する準備
ができたら、以下を確認してください。
■
■
■
各ユーザのパスに、redbrick_dir¥bin ディレクトリが存在します。
redbrick_dir¥bin ディレクトリは、インストール時にシステム パスに追加
されるため、必ずユーザのパスに存在します。
<HKEY_LOCAL_MACHINE>¥<SOFTWARE>¥RedBrick¥
RedBrickWarehouse¥<DefaultServer> にある、IBM Red Brick Warehouse
サービスの Windows レジストリに以下の環境変数が設定されます。
❑ RB_CONFIG
❑ RB_EXE
❑ RB_HOST
❑ RB_PATH
環境変数 RB_HOST は、ユーザの環境または Windows レジストリに設定さ
れます。♦
上記の環境変数の詳細は、第 2 章「基本概念」を参照してください。
RISQL エントリ ツールと RISQL レポータのユーザ アカウントには、オペレーティ
ング システム上の特別な許可や特権は不要です。これらのツールからデータベース
にアクセスする詳しい方法は、『RISQL Entry Tool and RISQL Reporter User’s Guide』
を参照してください。
7-4 Administrator’s Guide
データベース アクセス権の付与
データベース アクセス権の付与
クライアント ツール、RISQL エントリ ツール , RISQL レポータのいずれかからデー
タベースに接続するデータベース ユーザにデータベースのアクセスを与えるには、
SQL の GRANT ( 権限とロール ) コマンドを使用します。
ヒント：Microsoft Access や Visual Basic などの ODBC クライアント アプリケーショ
ンによっては、システムの ODBC アプリケーション ユーザごとに SQL の GRANT
文を使用して、リソース アクセス権を付与することが必要になる場合があります。
新規ユーザをデータベースに追加する手順
1.
2.
3.
4.
そのユーザがシステム アカウントを持っているか、クライアント ツール
を通じてアクセスできることを確認します。
データベース管理者 ( または DBA システム ロールのメンバーか、
USER_MANAGEMENT タスク権限を持つユーザ ) として、RISQL セッショ
ンを起動します。
SQL の GRANT CONNECT 文を使い、ユーザ名をデータベースに追加して
パスワードを割り当てます。CONNECT システム ロールは、データベース
への接続、自分のパスワードの変更、PUBLIC マクロの使用、PUBLIC
テーブルへのアクセスをユーザに許可します。CONNECT システム ロール
には、これらのタスクが含まれています。
どのデータベース権限をユーザに与えるかを決定し、GRANT 文によって
適切なシステム ロールのメンバーにすることで、オブジェクト特権を割り
当て、ロールに必要な特権を間接的に与えます。
これらのタスクについては、7-7 ページ「システム ロールによるアクセス
権の付与」、7-9 ページ「データベース オブジェクト特権の付与」、
7-11 ページ「ロールに基づくセキュリティでのアクセス権の設定」を参照
してください。
データベース ユーザをデータベースから削除するには、REVOKE CONNECT 文を使
用します。
GRANT、REVOKE、CREATE ROLE の各文の詳細については、『SQL Reference
Guide』を参照してください。
データベースのアクセス権とセキュリティ
7-5
パスワードの変更
例
以下の GRANT CONNECT 文は、データベース ユーザ名 drew を作成し、パスワー
ド instructor を割り当てます。
grant connect to drew with instructor ;
ユーザ drew は、データベースへの接続、自分のパスワードの変更、PUBLIC マクロ
の使用、PUBLIC テーブルへのアクセスができるようになります。ほかの操作を実
行するためには、ユーザ drew は、RESOURCE システム ロール、DBA システム
ロール、オブジェクト特権のいずれかを取得する必要があります。
以下の REVOKE CONNECT 文は、drew をデータベースから削除します。
revoke connect from drew;
パスワードの変更
GRANT CONNECT 文は、データベース ユーザが自分のパスワードを変更したり、
データベース管理者がほかのユーザのパスワードを変更するのに使用します。パス
ワードを変更するには、データベース ユーザ名を指定し、新規パスワードを入力し
ます。
パスワードには、
『SQL Reference Guide』で説明されている有効なデータベース識別
子かリテラルを指定できます。構成ファイルにパスワード パラメータを設定する
と、パスワードにオプションの制約を追加できます。詳細は、7-26 ページ「パス
ワードのセキュリティ管理」を参照してください。
例
以下の GRANT CONNECT 文は、ユーザ drew のパスワードを se2cure に変更します。
この文は、drew またはデータベース管理者が実行できます。
grant connect to drew with se2cure ;
7-6 Administrator’s Guide
システム ロールによるアクセス権の付与
システム ロールによるアクセス権の付与
IBM Red Brick Warehouse データベースには、3 種類のシステム ロールが事前に設定
されています。
■
■
■
CONNECT システム ロールは、データベースへの接続、自分のパスワード
の変更、PUBLIC マクロの使用、PUBLIC テーブルへのアクセスをユーザ
に許可します。データベースに追加されたユーザは、CONNECT システム
ロールのメンバーになります。
RESOURCE システム ロールは、CONNECT システム ロールの権限に加え、
データベース オブジェクトの作成とその変更や削除、およびアクセス権の
付与をユーザに許可します。
DBA システム ロールは、RESOURCE および CONNECT システム ロールの
権限に加え、データベースの全オブジェクトへのアクセスと変更、データ
ベースの構造とセキュリティに影響を与える操作をユーザに許可します。
DBA、RESOURCE、CONNECT の権限
オブジェクト特権とは別に、DBA、RESOURCE、CONNECT システム ロールのメ
ンバーに許可されるタスクを、以下に示します。
システム ロール
許可されるタスク
DBA
Resource
Connect
システム ロールの
GRANT/REVOKE
あり
インデックスなし
インデッ
クスなし
データベース オブジェクトの
CREATE
あり
あり
インデッ
クスなし
データベース オブジェクトの
ALTER
あり
あり ( オブジェクト作
成者のみ )
インデッ
クスなし
データベース オブジェクトの
DROP
あり
あり ( オブジェクト作
成者のみ )
インデッ
クスなし
データの SELECT
あり
あり ( オブジェクト作
成者のみ )
インデッ
クスなし
データの修正
あり
あり ( オブジェクト作
成者のみ )
インデッ
クスなし
(１/２)
データベースのアクセス権とセキュリティ
7-7
DBA および RESOURCE システム ロールの付与と取り消し
システム ロール
許可されるタスク
DBA
Resource
Connect
オブジェクト アクセス権の
GRANT/REVOKE
あり
あり ( オブジェクト作
成者のみ )
インデッ
クスなし
データベースの LOCK
あり
インデックスなし
インデッ
クスなし
データベースの UPGRADE
あり
インデックスなし
インデッ
クスなし
EXPORT データ
あり
インデックスなし
インデッ
クスなし
データベースの REORG
あり
あり ( テーブル作成者
のみ )
インデッ
クスなし
オフライン ロードの実行
あり
( テーブル作成者が自
分の所有するセグメン
トにのみ )
インデッ
クスなし
(２/２)
ロールに基づくセキュリティ機能、システム ロールのタスクを分割して新しいロー
ルを作成する方法の詳細は、7-11 ページ「ロールに基づくセキュリティでのアクセ
ス権の設定」を参照してください。
DBA および RESOURCE システム ロールの付与と取
り消し
DBA システム ロールのメンバーは、GRANT 文により、DBA および RESOURCE シ
ステム ロールをほかのデータベース ユーザに付与することができます。
RESOURCE または DBA システム ロールを付与されたユーザは、各ロールに割り当
てられたタスクをデータベースで実行できるようになります。
DBA システム ロールのメンバーは、REVOKE ( 権限とロール ) 文により、DBA と
RESOURCE システム ロールをいつでもユーザから取り消すことができます。
GRANT 文と REVOKE 文の詳細については、
『SQL Reference Guide』を参照してくだ
さい。
7-8 Administrator’s Guide
データベース オブジェクト特権の付与
例
以下の GRANT 文は、CONNECT システム ロールのメンバーである drew に、
RESOURCE システム ロールを付与します。データベース ユーザ drew は、データ
ベース オブジェクトの作成、オブジェクトへのアクセスと変更ができるようになり
ます。
grant resource to drew ;
以下の REVOKE 文は、bob から DBA システム ロールを取り消します。
revoke dba from bob ;
データベース オブジェクト特権の付与
オブジェクト特権は、テーブルなどのデータベース オブジェクトからのデータの選
択や、データの修正をユーザに許可するもので、以下の 5 つがあります。
■
SELECT
■
INSERT
■
UPDATE
■
DELETE
■
ALL PRIVILEGES
DBA システム ロールのメンバー ( または RESOURCE のメンバーであるオブジェク
トの作成者 ) は、GRANT 文により、オブジェクト特権をデータベース ユーザに付
与できます。オブジェクト特権は、指定した任意のユーザか、PUBLIC を指定して
全ユーザに付与することができます。オブジェクト特権をユーザに付与する前に、
そのユーザに CONNECT システム ロールを与え、パスワードを割り当てます。オブ
ジェクト特権は、REVOKE 文によりいつでも取り消すことができます。
データベースのアクセス権とセキュリティ
7-9
データベース オブジェクト特権の付与
以下に、DBA システム ロールのメンバー、オブジェクトの作成者、オブジェクト
特権を与えられたユーザ、すべてのユーザのそれぞれに許可されたデータベース オ
ブジェクトに対する操作をまとめた表を示します。
ユーザ
許可されたオブジェクト
特権
DBA
作成者 1
被付与者
PUBLIC
オブジェクトの SELECT
あり
あり
あり
インデックス
なし
オブジェクトへの INSERT
あり
あり
あり 2
インデックス
なし
オブジェクトの UPDATE
あり
あり
あり
インデックス
なし
オブジェクトからの
DELETE
あり
あり
あり
インデックス
なし
パブリック マクロの使用
あり
あり
適用せず
あり
1
RESOURCE システム ロールのメンバーは、自分が作成したテーブルに対するすべてのオブ
ジェクト特権を付与されます。
2
行を挿入するユーザは、そのオブジェクトに対する INSERT 特権と SELECT 特権の両方が必要
です。
GRANT 文 と REVOKE 文の詳細については、
『SQL Reference Guide』を参照してく
ださい。
例
RESOURCE システム ロールを持っている curly が、自分が作成したテーブル t1 に
対する SELECT 特権を、CONNECT システム ロールを持っている moe に付与する例
を示します。
grant select on t1 to moe ;
7-10 Administrator’s Guide
ロールに基づくセキュリティでのアクセス権の設定
ロールに基づくセキュリティでのアクセス権の
設定
ロールによるセキュリティ機能では、あらかじめ定義されたシステム ロールよりき
め細かく柔軟にユーザやユーザの権限を管理することが可能になります。ユーザ定
義のロールによるセキュリティ機能は、事前に設定された RESOURCE と DBA シス
テム ロールに加え、タスク権限を個別に付与したり、タスクを組み合わせて新しい
ロールを設定したり、ユーザ定義のロールでデータベース ユーザをグループ分けす
ることができます。
ユーザが作成するロールは、以下の項目を任意に組み合わせて構成します。
■
■
■
■
7-12 ページの表に示すタスク権限
7-9 ページ「データベース オブジェクト特権の付与」で説明するオブジェ
クト特権
データベース ユーザ
その他のロール
作成したロールは、現在そのロールのメンバーでないユーザに付与することができ
ます。被付与者はロールのメンバーになり、そのロールのすべての権限と特権を取
得します。タスク権限、オブジェクト特権、ユーザ、ほかのロールを付与または取
り消して、ロールの内容を変更することができます。
ロールを与えられたユーザは、そのロールの直接のメンバーになります。あるロー
ル (role1) をほかのロール (role2) に付与すると、2 番目のロール (role2) は付与された
ロール (role1) の間接的なメンバーになります。
通常は、なるべく RESOURCE システム ロール、DBA システム ロール、オブジェク
ト特権だけを使用し、データベース管理操作とセキュリティにユーザ定義のロール
の柔軟性が適している場合のみ、ユーザ定義のロールを作成、使用してください。
ここでは、ロールに基づくセキュリティ機能に関する以下の事項について説明しま
す。
■
■
■
■
■
■
■
■
タスク権限の一覧と内容
ロール機能の説明とロールの柔軟性を示す例
ロールの作成方法
ユーザとロールにタスク権限を付与する方法
ロールを付与する方法
ロールにオブジェクト特権を付与する方法
タスク権限、オブジェクト特権、ロールを取り消す方法
ロールの権限とメンバーを管理する方法
データベースのアクセス権とセキュリティ 7-11
タスク権限
タスク権限
以下に、DBA システム ロールに定義されたタスク権限を示します。
タスク権限
定義
ACCESS_ADVISOR_INFO
Advisor システム テーブルを検索することができます。Advisor の詳細
については、『IBM Red Brick Vista User’s Guide』を参照してください。
ACCESS_ANY
すべてのデータベース オブジェクトからデータを検索し、システム
テーブルのプライベート マクロなどのプライベート ユーザ情報にアク
セスできます。
ACCESS_SYSINFO
動的統計テーブル (DST) にある、データベース動作の統計を検索する
ことができます。動的統計テーブル (DST) の詳細については、
8-6 ページ「動的統計テーブルによるデータベース動作の監視」を参
照してください。
ALTER_ANY
列、インデックス、マクロ、セグメント、シノニム、テーブル、
ビューを変更することができます。
ALTER_SYSTEM
ALTER SYSTEM コマンドを実行し、データベース管理操作を実行する
ことができます。
CREATE_ANY
すべてのユーザの資源を使用したオブジェクトを作成することができ
ます。ほかのユーザのテーブルにインデックスを作成したり、ほかの
ユーザのセグメントに格納されるテーブルを作成できます。
DROP_ANY
すべてのユーザが作成したオブジェクトを削除できます。
EXPORT
EXPORT ステートメントを使用して任意のクエリの結果をユーザ指定
ファイルにエクスポートする権限を付与することができます。これ
は、基本的には DBA、およびシステム管理者のための機能で、一般の
ユーザには関係ありません。この権限があると、サーバが設定されて
いるユーザ ( 通常 redbrick) として、データベース ホスト システムに
ファイルを作成できます。
GRANT_TABLE
データベース ユーザおよびロールに、オブジェクト特権を付与するこ
とができます。
IGNORE_QUIESCE
静止データベースのオブジェクトにアクセスできます。データベース
が静止状態の時に、データのロードや管理操作ができます。
LOCK_DATABASE
データベースをロックすることができます。
MODIFY_ANY
データの挿入、更新、削除、ロードができます。
(１/２)
7-12 Administrator’s Guide
タスク権限
タスク権限
定義
OFFLINE_LOAD
どのセグメントでもオフライン ロードの作業セグメントとして使用す
ることができます。オフライン ロード後はセグメントを同期させるこ
とができます。
PUBLIC_MACROS
PUBLIC マクロの作成と削除ができます。
REORG_ANY
テーブルとインデックスの再編成ができます。
ROLE_MANAGEMENT
ロールの作成、削除、付与、取り消し、変更ができます。
UPGRADE_DATABASE
データベースのアップグレードができます。
USER_MANAGEMENT
GRANT CONNECT コマンドを使用して、データベース ユーザを作成
したり、パスワードを変更したりできます。
REVOKE CONNECT コマンドを使用して、データベース ユーザを削除
できます。
ALTER USER または GRANT CONNECT を使用して、ユーザ セッショ
ンのデフォルト優先順位を指定できます。
(２/２)
以下の表は、RESOURCE システム ロールに定義されたタスク権限を示します。
タスク権限
定義
ALTER_OWN
自分の作成したインデックス、セグメント、テーブルを変更できま
す。
ALTER_TABLE_INTO_ANY
自分の作成したテーブルをほかのユーザのセグメントに変更できま
す。
CREATE_OWN
自分の作成したオブジェクト ( インデックス、プライベート マクロ、
セグメント、シノニム、テーブル、ビュー ) を作成できます。
DROP_OWN
自分の作成したオブジェクトを削除できます。
GRANT_OWN
自分の作成したオブジェクトに対するオブジェクト特権を、ほかの
ユーザに付与することができます。
TEMP_RESOURCE
テンポラリ テーブルを作成できます。
ヒント：システム ロールは変更できないため、DBA や RESOURCE システム ロー
ルにタスク権限またはオブジェクト特権を付与することはできません。ただし、
ユーザ定義のロールにシステム ロールを付与することは可能です。
データベースのアクセス権とセキュリティ 7-13
ロール権限
GRANT ( 権限とロール ) 文と ALTER SYSTEM 文の詳細については、
『SQL Reference
Guide』を参照してください。
ロール権限
データベース管理者は、システム ロールに定義された GRANT 権限と REVOKE 権
限に加え、以下のロールに基づいたセキュリティ機能を使用することができます。
■
任意のデータベース ユーザへのタスク権限の付与。例を示します。
grant lock_database to db_user ;
■
ユーザ定義のロールの作成。例を示します。
Create role table_select_role ;
■
ユーザ定義のロールに対するオブジェクト特権の付与。そのロールの全メ
ンバーが特権を取得します。例を示します。
grant select on period to table_select_role ;
■
ユーザ定義のロールに対するタスク権限の付与。そのロールの全メンバー
がタスクを実行できるようになります。例を示します。
grant upgrade_database to db_management_role ;
■
任意のデータベース ユーザに対するユーザ定義のロールの付与。そのユー
ザは、そのロールの直接のメンバーになります。ユーザ定義のロールは、
ユーザ、タスク権限、オブジェクト特権、ほかのロールを組み合わせて構
成できます。空のロールも作成できます。例を示します。
grant table_select_role to db_user1, db_user2,
db_user3 ;
■
ほかのユーザ定義のロールへのユーザ定義ロールの付与。ユーザ定義の
ロールは、ユーザ、タスク権限、オブジェクト特権、ほかのロールを組み
合わせて構成できます。例を示します。
grant table_select_role to marketing_role ;
■
marketing_role のメンバーは、table_select_role の間接的なメンバーにな
り、その権限をすべて取得します。
ユーザ定義のロールに対するシステム ロールの付与。例を示します。
grant resource to marketing ;
marketing ロールの全メンバーは、RESOURCE システム ロールの間接的な
メンバーになり、RESOURCE システム ロールのすべてのタスクを実行で
きるようになります。
7-14 Administrator’s Guide
ロールの作成
■
ユーザ定義のロールからのオブジェクト特権の取り消し。例を示します。
■
ユーザ定義のロールまたはデータベース ユーザからのタスク権限の取り消
し。例を示します。
revoke select on period from table_select_role ;
revoke upgrade_database from db_management_role ;
■
ユーザ定義のロールの削除。例を示します。
drop role table_select_role ;
ロールの作成
ロールを作成し、そのロールをユーザやほかのロールに付与するには、CREATE
ROLE 文を使用します。CREATE ROLE 文に指定したユーザは、そのロールの直接
のメンバーになります。1 人のデータベース ユーザが直接メンバーになれるロール
は、16 個までです。
作成したロールにタスク権限やほかのロールを付与したり、ユーザやほかのロール
に付与するには、GRANT ( 権限とロール ) 文を使用します。
オブジェクト特権のロールへの付与は、GRANT ( 特権 ) 文を使用します。
CREATE ROLE 文と GRANT 文の詳細については、『SQL Reference Guide』を参照し
てください。
例
以下の CREATE ROLE 文は、security_management ロールを作成し、chris と judy を
直接のメンバーとして指定します。
create role security_management for chris, judy ;
データベースのアクセス権とセキュリティ 7-15
タスク権限の付与
タスク権限の付与
データベース ユーザやユーザ定義のロールにタスク権限を付与するには、GRANT (
権限とロール ) 文を使用します。タスク権限を付与されたユーザは、そのタスクを
実行できるようになります。そのロールの直接のメンバーと間接的なメンバーは、
付与されたタスクを実行できます。
例
以下の GRANT 文は、maria、john、joe の各ユーザがデータベースのアップグレー
ドとロックを行えるようにします。
grant upgrade_database, lock_database to maria, john, joe ;
ユーザ グループのロールを作成し、タスク権限を付与する例を示します。
1.
chris と judy の各ユーザを直接のメンバーとする security_management
ロールを作成します。
create role security_management for chris, judy ;
2.
USER_MANAGEMENT、GRANT_TABLE、ROLE_MANAGEMENT の各タ
スク権限を security_management ロールに付与します。
grant user_management, grant_table, role_management
to security_management ;
ユーザ chris および judy は、security_management ロールの直接メンバーになり、
データベース ユーザの管理、オブジェクト特権の付与、ロールの管理ができます。
必要に応じて、security_management ロールをほかのユーザやほかのロールにも付
与できます。
ロールへのオブジェクト特権の付与
ユーザ定義のロールにオブジェクト特権を付与するには、GRANT 文を使用します。
オブジェクト特権をロールに付与すると、そのロールの直接のメンバーと間接的な
メンバーがその特権を取得します。ユーザにオブジェクト特権を付与する方法と、
オブジェクト特権の一覧は、7-9 ページ「データベース オブジェクト特権の付与」
を参照してください。
GRANT ( 特権 ) 文の詳細については、『SQL Reference Guide』を参照してください。
例
table_select と marketing という 2 つのロールを作成し、4 つのテーブルに対する
SELECT ( オブジェクト特権 ) を table_select ロールに付与する例を示します。
7-16 Administrator’s Guide
ロールへのオブジェクト特権の付与
空のロールをデータベース ユーザに付与すると、そのユーザはロールのメンバーに
なりますが、取得するタスクや特権はありません。ユーザを指定してロールを作成
しておくと、ユーザをグループ分けし、タスク権限やオブジェクト特権を個別にま
たはロールとして、そのグループのユーザに一括して付与できます。たとえば、複
数のデータベース テーブルに対する SELECT 特権を、マーケティング部門のメン
バーに割り当てるとします。その場合は次の手順に従います。
1.
2 つのロールを作成します。たとえば、table_select と marketing を作成し
ます。
create role table_select ;
create role marketing ;
2.
table_select ロールに対し、オブジェクト特権を付与します。
grant
grant
grant
grant
3.
select
select
select
select
on
on
on
on
period to table_select ;
product to table_select ;
market to table_select ;
sales to table_select ;
ユーザ グループに対し、marketing ロールを付与します。
grant marketing to db_user1, db_user2, db_user3,
db_user4 ;
4.
marketing ロールに対し、table_select ロールを付与します。
grant table_select to marketing ;
marketing ロールのメンバーは、table_select ロールの間接的なメンバーになり、
Period、Product、Sales の各テーブルにアクセスできます。
図 7-1
Table_Select ロール
period に対する SELECT 特権
Marketing ロール
table_select ロール
の間接付与
product に対する SELECT 特権
market に対する SELECT 特権
sales に対する SELECT 特権
1 つの GRANT 文で、marketing ロールに新入社員を追加し、そのロールの全権限を
与えることができます。
データベースのアクセス権とセキュリティ 7-17
ロールの付与
ロールの付与
データベース ユーザやユーザ定義ロールにロールを付与するには、GRANT 文を使
用します。ロールを付与されたユーザは、そのロールの直接のメンバーになりま
す。そのロールに付与されたすべてのタスク権限とオブジェクト特権を使用できま
す。1 人のデータベース ユーザが直接メンバーになれるロールは、16 個までです。
ユーザ定義のロールにロールを付与すると、ユーザ定義のロールの全メンバーが、
付与されたロールの間接的なメンバーになり、そのロールのすべての権限を取得し
ます。1 人のデータベース ユーザが間接的なメンバーになれるロールの数には制限
がありません。
ただし、以下のことはできません。
■
■
■
システム ロールにロールを付与すること。
ただし、ユーザ定義のロールにシステム ロールを付与することは可能。
ロールをそのロール自身に付与すること。
ループするロールの作成。
たとえば、Role1 を Role2 に付与する場合、Role2 を Role1 に付与すること
はできません。
ユーザやほかのロールにロールを付与する際は、注意が必要です。どのユーザが、
どの権限を持っているかを確認してください。ロールにほかのロールを付与した場
合は、直接のメンバーだけでなく間接的なメンバーも把握しておかなければなりま
せん。ロールのメンバー、タスク権限、オブジェクト特権の管理は、7-23 ページ
「ロールの権限とメンバーの監視」に述べるシステム テーブルを使って行います。
GRANT ( 権限とロール ) 文の詳細については、
『SQL Reference Guide』を参照してく
ださい。
7-18 Administrator’s Guide
ロールの付与
例
タスク権限をユーザ定義のロールに付与し、そのロールをユーザに付与する例を示
します。データベースのアップグレードを行う権限を、データベース ユーザに付与
するとします。新規のロールに必要なタスク権限だけを付与し、そのロールのメン
バー権をユーザに与えます。
1.
database_management というロールを作成します。
create role database_management ;
2.
DBA タスク権限の一部 ( この例では、LOCK_DATABASE および
UPGRADE_DATABASE) を database_management ロールに付与します。
grant lock_database upgrade_database to
database_management ;
3.
作成したロールを、そのタスクを担当するユーザに付与します。
grant database_management to db_user ;
ユーザ db_user は、database_management ロールのメンバーになり、データベース
のロックとアップグレードができるようになります。
図 7-2
database_management
db_user
ロールの間接的な
メンバー権
LOCK_DATABASE
UPGRADE_DATABASE
database_management ロールに割り当てられているタスクが多すぎて一人のユーザ
では処理しきれない場合、1 つの GRANT 文で、そのロールのすべての権限をほか
のユーザにも付与することができます。
データベースのアクセス権とセキュリティ 7-19
ロールの付与
例
以下の例では、marketing ロールを作成してマーケティング部門のユーザをグルー
プ化し、object_management ロールを作成してオブジェクト管理タスクをグループ
化し、object_management ロールを marketing ロールに付与する方法を示します。
marketing ロールの全メンバーが、object_management ロールの間接的なメンバー
になります。
1.
ロール marketing を作成し、ユーザ sudhir、nasi、cody をロールの直接の
メンバーにします。
create role marketing for sudhir, nasi, cody ;
2.
ロール object_management を作成します。
create role object_management ;
3.
object_management ロールにタスク権限を付与します。
grant alter_any, public_macros, access_any,
modify_any,drop_any, create_any to
object_management ;
4.
marketing ロールに object_management ロールを付与します。sudhir、
nasi、cody の各ユーザが object_management ロールの間接的なメンバーに
なり、このロールに付与されたすべてのタスクを実行できるようになりま
す。
grant object_management to marketing ;
例
ロールの間接的なメンバー権という概念を説明します。データベースに 3 つのロー
ルが作成され、次のように直接のメンバーとタスク権限が設定されているとしま
す。
Role2 のメンバーである Brian と Hedy は、データベースのアップグレードとテーブ
ルの再編成を行うことができます。Role2 に Role1 を付与すると、Brian と Hedy は
Role1 の間接的なメンバーになり、オブジェクトの作成と修正もできるようになり
ます。しかし Kirsten と Susan が、データベースをアップグレードしたり、テーブル
を再編成することはできません。
Role3 のメンバーである Emily と Elena は、すべてのデータベース オブジェクトにア
クセスし、変更することができます。Role3 に Role2 を付与すると、Emily と Elena
は Role2 の間接的なメンバーになります。Role2 のメンバーとして、Role1 の間接的
なメンバーにもなります。Emily と Elena は、Role3 のタスクに加え、データベース
オブジェクトの作成および修正、ならびにデータベースのアップグレードと再編成
もできるようになります。
7-20 Administrator’s Guide
タスク権限、オブジェクト特権、ロールの取り消し
図 7-3
Role1
メンバー: Kirsten
Role2
メンバー: Brian
Susan
タスク :
ロール メンバーと
タスク権限
Hedy
CREATE_ANY
MODIFY_ANY
タスク : UPGRADE_DATABASE
REORG_ANY
Role3
メンバー: Emily
Elena
タスク : ACCESS_ANY
ALTER_ANY
オブジェクトの作成を Emily に禁止する場合、CREATE_ANY タスク権限を Emily か
ら取り消すだけでは、目的は達せられません。Emily がこのタスク権限を取得した
のは、Role1 のメンバーになったからです。このタスクを禁止する方法は 4 種類あ
ります。
■
■
■
■
Role3 を Emily から取り消す。Emily はすべてのタスクを実行できなくな
る。
Role2 を Role3 から取り消す。Role3 から Role1 へのリンクが断ち切られ
る。
Role1 を Role2 から取り消す。Role2 の直接のメンバーと間接的なメンバー
は、Role1 のタスクを実行できなくなる。
CREATE_ANY タスク権限を Role1 から取り消す。
タスク権限、オブジェクト特権、ロールの取り消し
タスク権限とロールを取り消すには REVOKE ( 権限とロール ) 文を使用し、オブジェ
クト特権を取り消すには REVOKE ( 特権 ) 文を使用します。ユーザから権限を削除
するには、その権限を含むすべてのタスクと特権を、そのユーザから取り消さなけ
ればなりません。たとえば、あるタスク権限と、そのタスク権限を含むロールがユー
ザにある場合は、そのタスク権限をユーザから取り消すと同時に、そのロールをユー
ザから取り消すかそのロールからそのタスク権限を取り消す必要があります。
システム ロールからタスク権限を取り除くことはできません。システム ロールは
削除できません。
REVOKE ( 権限とロール ) 文と REVOKE ( 特権 ) 文の詳細については、『SQL
Reference Guide』を参照してください。
データベースのアクセス権とセキュリティ 7-21
タスク権限、オブジェクト特権、ロールの取り消し
例
複数の方法で付与されたタスク権限を、ユーザから完全に取り消す例を示します。
ユーザ Ken は、UPGRADE_DATABASE タスク権限を直接付与され、
UPGRADE_DATABASE タスク権限を持つ database_management ロールも付与され
ています。
Ken のデータベース アップグレード権限を RBW_USERAUTH テーブルで確認しま
す。
select grantee, grantor, upgrade_database
from rbw_userauth ;
GRANTEE
GRANTOR
UPGR
DATABASE_MANAGEMENT
SYSTEM
Y
KEN
DBA
Y
UPGRADE_DATABASE タスク権限を ken から取り消します。
revoke upgrade_database from ken ;
ken がデータベースをアップグレードする権限をまだ持っていないかを確認するた
め、RBW_USERAUTH テーブルを再度確認します。
select grantee, grantor, upgrade_database
from rbw_userauth ;
GRANTEE
GRANTOR
UPGR
DATABASE_MANAGEMENT
SYSTEM
Y
KEN
SYSTEM
R
上記の結果で R は、ロールを通じて ken がアップグレード権限をまだ持っているこ
とを示します。このため、database_management ロールを ken から取り消します。
revoke database_management from ken ;
再び RBW_USERAUTH テーブルを確認します。ken が、データベースをアップグ
レードできなくなったことがわかります。
select grantee, grantor, upgrade_database
from rbw_userauth ;
GRANTEE
GRANTOR
UPGR
DATABASE_MANAGEMENT
SYSTEM
Y
ken が複数のロールに所属している場合や、そのタスク権限が複数のロールに付与
されている場合は、どのロールを通じて ken がタスク権限を取得したかを確認し、
そのロールから彼のメンバー権を削除するか、またはタスク権限を削除します。
7-22 Administrator’s Guide
ロールの権限とメンバーの監視
database_management ロールを ken から取り消さずに、UPGRADE_DATABASE を
database_management ロールから取り消すこともできます。どちらの方法でも、
ken はタスクを実行できなくなります。ただし、ロールからタスクを取り消すと、
そのロールのすべてのメンバーがそのタスクを実行できなくなります。
ヒント：ロールをデータベースから削除するには、DROP ROLE 文を使用します。
ロールを削除しても、そのロールのタスクの一部に対する間接的なタスク権限が、
ロールのメンバーに残される場合があります。ロールの削除に関する詳細は、
9-102 ページ「ロール」を参照してください。DROP ROLE 文の詳細については、
『SQL Reference Guide』を参照してください。
ロールの権限とメンバーの監視
ユーザに付与されたタスク権限、オブジェクト特権、ロールを確認するには、シス
テム テーブルを検索します。以下の表は、クエリで確認できるシステム テーブル
の一覧です。
システム テーブル
情報
RBW_ROLES
データベースに存在するロール
RBW_ROLE_MEMBERS
各ロールのメンバー
RBW_USERAUTH
各ユーザと各ロールのタスク権限
RBW_TABAUTH
各ユーザと各ロールのオブジェクト特権
以下に、システム テーブルを検索してデータベースのアクセス権を確認する例を示
します。
例
このステートメントは、データベースに作成されたすべてのユーザ定義のロールの
一覧を表示します。
select name, creator
from rbw_roles
order by name ;
NAME
DATABASE_MANAGEMENT
MARKETING
OBJECT_MANAGEMENT
SECURITY_MANAGEMENT
TABLE_SELECT
CREATOR
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
データベースのアクセス権とセキュリティ 7-23
ロールの権限とメンバーの監視
次の文は、データベースのすべてのロールと、各ロールのメンバーの一覧を表示し
ます。USERNAME 列には、ROLENAME 列に示すロールのメンバーになっている
すべてのユーザとロールが表示されます。INDIRECT 列には、そのユーザとロール
が間接的なメンバー (Y)、直接のメンバー (N) のどちらであるかが表示されます。
select rolename, username, indirect
from rbw_role_members
order by rolename, username ;
ROLENAME
DATABASE_MANAGEMEN
MARKETING
MARKETING
MARKETING
OBJECT_MANAGEMENT
OBJECT_MANAGEMENT
OBJECT_MANAGEMENT
OBJECT_MANAGEMENT
SECURITY_MANAGEMEN
SECURITY_MANAGEMEN
USERNAME
JOHN
CODY
NASI
SUDHIR
CODY
MARKETING
NASI
SUDHIR
CHRIS
JUDY
INDI
N
N
N
N
Y
N
Y
Y
N
N
次の文は、データベースのすべてのユーザとロール、各ユーザと各ロールのタスク
権限の一覧を表示します。ユーザまたはロールが各タスク権限を直接取得したか
(Y)、ロールの直接メンバーとして取得したか (R)、ロールの間接メンバーとして取
得したか (I) も表示されます。
select grantee, dbaauth, resauth, user_management,
grant_table, role_management, alter_any, public_macros,
access_any, modify_any, drop_any, create_any,
lock_database, upgrade_database,
alter_table_into_any,create_own, alter_own, grant_own,
isrole
from rbw_userauth
order by grantee ;
GRANTE
DBAA RESA USER GRAN ROLE
UPGR ALTE CREA ALTE GRAN ISRO
CHRIS
N N R R R N N N
CODY
N N N N N I I I
DATABASE_M
N N N N N N N N
JOE
N N N N N N N N
JOHN
N N N N N N N N
JUDY
N N R R R N N N
MARIA
N N N N N N N N
MARKETING
N N N N N R R R
NASI
N N N N N I I I
OBJECT_MAN
N N N N N Y Y Y
SECURITY_M
N N Y Y Y N N N
SUDHIR
N N N N N I I I
SYSTEM
Y N Y Y Y Y Y Y
TABLE_SELE
N N N N N N N N
7-24 Administrator’s Guide
ALTE PUBL ACCE MODI DROP
N
I
N
N
N
N
N
R
I
Y
N
I
Y
N
N
I
N
N
N
N
N
R
I
Y
N
I
Y
N
N
I
N
N
N
N
N
R
I
Y
N
I
Y
N
N
N
Y
N
R
N
N
N
N
N
N
N
Y
N
N
N
Y
Y
Y
N
Y
N
N
N
N
N
Y
N
N
N
Y
Y
Y
N
Y
N
N
N
N
N
Y
N
N
N
N
N
N
N
N
N
N
N
N
N
Y
N
N
N
N
N
N
N
N
N
N
N
N
N
Y
N
CREA LOCK REST
N
N
N
N
N
N
N
N
N
N
N
N
Y
N
N
N
N
N
N
N
N
N
N
N
N
N
Y
N
N
N
Y
N
N
N
N
Y
N
Y
Y
N
N
Y
ロールの権限とメンバーの監視
DBA_AUTH 列と RES_AUTH 列は、ユーザまたはロールが DBA または RESOURCE
システム ロールを付与されているかどうかを表示します。ISROLE 列は、付与の対
象が、ロールであるか (Y)、ユーザであるか (N) を表示します。
タスク権限の列には、以下に示すいずれかの値が表示されます。
値
意味
N
ユーザまたはロールはタスク権限を持っていない。
Y
ユーザまたはロールはタスク権限を直接取得している。
R
ユーザまたはロールは、ロールの直接のメンバーとしてタスク権限を
取得している。
I
ユーザまたはロールは、ロールの間接的なメンバーとしてタスク権限
を取得している。つまり、そのユーザは、そのタスク権限を持つロー
ルを付与されたロールのメンバーである。
次の文は、データベースのすべてのユーザとロール、オブジェクト特権の一覧を表
示します。
select grantee, grantor, tname, selauth, insauth, delauth,
updauth
from rbw_tabauth
order by grantee ;
GRANTEE
MARIA
TABLE_SELECT
TABLE_SELECT
TABLE_SELECT
TABLE_SELECT
GRANTOR
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
TNAME
PRODUCT
SALES
PERIOD
PRODUCT
MARKET
SELA
N
Y
Y
Y
Y
INSA
Y
N
N
N
N
DELA
N
N
N
N
N
UPDA
N
N
N
N
N
データベースのアクセス権とセキュリティ 7-25
パスワードのセキュリティ管理
パスワードのセキュリティ管理
パスワード セキュリティ機能を使うと、データベース管理者 ( または
USER_MANAGEMENT タスク権限を持っているユーザ ) はデータベース パスワード
の期限と文字を制御できます。この機能の制御には、rbw.config ファイルのパス
ワード パラメータを使用します。パスワード パラメータの設定により、以下を制
御できます。
■
■
■
■
■
■
パスワードの有効期限を設定する。
パスワードの有効期限が近いことを、ユーザに警告するメッセージの表示
時期を設定する。
古いパスワードの再使用を制限し、同じパスワードを繰り返し使用するこ
とを禁止する。
古いパスワードの変更頻度を制限する。
有効なパスワードの文字の組み合わせと長さを制御する。
ユーザがデータベースへの接続に失敗した場合、許容される入力ミスの連
続回数を制限する。
データベース管理者は、使用サイトやデータベース環境に合わせて必要なパラメー
タだけを設定し、適切なパスワード セキュリティ機能を導入することができます。
初期のユーザ パスワードは、データベース管理者 ( または USER_MANAGEMENT
タスク権限を持っているユーザ ) が GRANT CONNECT 文で作成します。データ
ベースを長期間にわたって使用するユーザは、パスワード パラメータの設定に従っ
て、GRANT CONNECT 文により自分のパスワードを変更しなければなりません。
GRANT CONNECT 文については、『SQL Reference Guide』を参照してください。
次の表は、パスワード パラメータと各パラメータの機能をまとめたものです。
パスワード パラメータ
説明
EXPIRATION_DAYS
パスワードの最大有効日数。パスワードを定期的に変更させる
ため。
EXPIRATION_WARNING_DAYS
パスワードの有効期限が切れることを示す警告メッセージを何
日前に通知するかを設定。
RESTRICT_PREVIOUS
同じパスワードを再使用するまでに、パスワードを変更しなけ
ればならない回数を設定。違うパスワードを使用させるため。
CHANGE_MINIMUM_DAYS
次にパスワードを変更するまでの、必要最低日数を指定。ユー
ザが短期間に何度もパスワードを変更して、
PASSWORD_RESTRICT_PREVIOUS の制限を回避するのを禁止
するため。
7-26 Administrator’s Guide
パスワードの強制変更
パスワード パラメータ
説明
MINIMUM_LENGTH
パスワードの必要最少文字数。
ALLOW_LOGNAME
パスワードの一部にユーザのログイン名を使用することを許可。
CHANGE_INITIAL
最初のログイン時の、ユーザ初期パスワードの強制変更。
COMPLEX_NUMERIC
変更前後のパスワードで、単一の数値以外の部分にも変更点が
必要。
COMPLEX_NUM_ALPHA
パスワードのアルファベット文字 (A ∼ Z、a ∼ z) の必要最少数。
COMPLEX_NUM_NUMERICS
パスワードの数字 (0 ∼ 9) の必要最少数。
COMPLEX_NUM_PUNCTUATION
パスワードの句読文字 (!@#$%& など ) の必要最少数。
LOCK_FAILED_ATTEMPTS
データベースへの接続に失敗した場合に、ユーザ アカウントを
ロックするまでに許容される入力ミスの最大回数。
LOCK_PERIOD_HOURS
入力ミスの許容回数を超えた場合に、ユーザ アカウントをロッ
クする時間。
パスワードの強制変更
rbw.config ファイルのパラメータ PASSWORD EXPIRATION_DAYS を設定すると、
ユーザにパスワードを定期的に変更させることができます。パスワードの有効期限
を日数で指定し、期限が切れるとユーザ アカウントを無効にします。ユーザは、
GRANT CONNECT 文で期限内にパスワードを変更し、期限切れになるのを防がな
ければなりません。
構文
パスワードの有効期限を指定するには、次の構文による設定を rbw.config ファイル
に記述します。
PASSWORD
EXPIRATION_DAYS
<num_days>
データベースのアクセス権とセキュリティ 7-27
パスワードの強制変更
<num_days>
パスワードの有効期限が切れるまでの日数を指定します。0 ∼ 512 の
整数でなければなりません。デフォルトは 0 で、最少文字数には制
限がなくなります。パスワードを変更する必要がないということで
す。パスワードの期日を確認するには、RBW_USERAUTH システム
テーブルの PASSWORD_TS 列の基準値に <num_days> の値を加算し
ます。
使用上の注意
■
■
■
パスワードを変更するまでの必要最低日数を指定するパラメータ
PASSWORD CHANGE_MINIMUM_DAYS が設定されていなければ、ユーザ
は、期日前にいつでもパスワードを変更することができます。
PASSWORD EXPIRATION_DAYS と PASSWORD
CHANGE_MINIMUM_DAYS の両方が設定されている場合は、必要最低日
数が経過した後、期限が切れる前にパスワードを変更しなければなりませ
ん。PASSWORD CHANGE_MINIMUM_DAYS の詳細については、7-31 ペー
ジ「パスワード変更頻度の制限」を参照してください。
アカウントが無効になったユーザは、データベース管理者 ( または
USER_MANAGEMENT タスク権限を持っているユーザ ) が、GRANT
CONNECT 文で新規パスワードを割り当てるまで、データベースに接続で
きません。
アカウントが無効になると、RBW_USERAUTH システム テーブルに示さ
れているユーザの状態が、有効から無効に変わります。データベース管理
者が新規パスワードを割り当てると、ユーザの状態は有効に戻ります。
RBW_USERAUTH テーブルのユーザ アカウントを確認するには、以下の
ように入力します。
select grantee, expired
from rbw_userauth
where grantee = '<user_name>' ;
7-28 Administrator’s Guide
パスワード期限切れの警告
パスワード期限切れの警告
パラメータ PASSWORD EXPIRATION_WARNING_DAYS を設定すると、期限が切れ
る前にパスワードを変更するようにユーザに警告することができます。パスワード
の有効期限が切れる何日前に、警告メッセージを通知するかを設定します。警告
メッセージは、ユーザがデータベースに接続するたびに表示されます。
構文
パスワードの警告時期を指定するには、次の構文による設定を rbw.config ファイル
に記述します。
PASSWORD
<num_days>
EXPIRATION_WARNING_DAYS
<num_days>
パスワードの有効期限が切れる何日前に、警告メッセージを通知す
るかを設定します。0 ∼ 512 の整数でなければなりません。デフォル
トは 0 で、警告メッセージは表示されません。
使用上の注意
■
■
パラメータ PASSWORD EXPIRATION_DAYS の値は、パラメータ
PASSWORD EXPIRATION_WARNING_DAYS の値より大きくなければなり
ません。そうでなければパラメータ PASSWORD
EXPIRATION_WARNING_DAYS が無視され、パスワードの期日が警告時
期になります。その場合は、ユーザがデータベースに接続するたびに警告
メッセージが表示されます。
パラメータ PASSWORD EXPIRATION_DAYS を設定しなかった場合は、パ
ラメータ PASSWORD EXPIRATION_WARNING_DAYS は無視されます。
データベースのアクセス権とセキュリティ 7-29
パスワード再使用の制限
例
rbw.config ファイルのエントリが、以下のようになっているとします。
PASSWORD EXPIRATION_DAYS 30
PASSWORD WARNING_DAYS 5
ユーザは、30 日以内にパスワードを変更しなければなりません。パスワードの有効
期限中 26 日目から 30 日目までは、データベースに接続するたびにパスワードの期
限が近いことを警告するメッセージが表示されます。
パスワード再使用の制限
パスワードの再使用を制限するには、rbw.config ファイルのパラメータ PASSWORD
RESTRICT_PREVIOUS を設定します。一度使用したパスワードを再使用するまで
に、パスワードを変更しなければならない回数を設定します。
構文
パスワードの再使用を制限するには、次の構文による設定を rbw.config ファイルに
記述します。
PASSWORD
<num_passwords>
7-30 Administrator’s Guide
RESTRICT_PREVIOUS
<num_passwords>
一度使用したパスワードを再使用するまでに、パスワードを変
更しなければならない回数を設定します。0 ∼ 128 の整数でな
ければなりません。デフォルトは 0 で、古いパスワードの再使
用に関する制限がなくなります。たとえば、このパラメータを
5 に設定すると、パスワードを 5 回変更しないと、前のパス
ワードを再使用することができません。
パスワード変更頻度の制限
使用上の注意
■
■
前と同じパスワードを使用するために、ユーザが短期間に何度もパスワー
ドを変更しないようにするには、パラメータ PASSWORD
CHANGE_MINIMUM_DAYS を設定します。
データベース管理者 ( または USER_MANAGEMENT タスク権限を持ってい
るユーザ ) は自分のパスワードについて PASSWORD
RESTRICT_PREVIOUS による制限を受けますが、ほかのユーザには前のパ
スワードをいつでも割り当てることができます。
パスワード変更頻度の制限
パスワードの変更頻度を制限するには、rbw.config ファイルのパラメータ
PASSWORD CHANGE_MINIMUM_DAYS を設定します。ここで、パスワードを変更
するまでの必要最低日数を指定します。
構文
パスワードの変更頻度を制限するには、次の構文による設定を rbw.config ファイル
に記述します。
PASSWORD
<num_days>
CHANGE_MINIMUM_DAYS
<num_days>
次にパスワードを変更するまでの、必要最低日数を指定します。0
∼ 128 の整数でなければなりません。デフォルトは 0 で、パスワー
ドの変更頻度には制限がなくなります。
例
rbw.config ファイルのエントリが、以下のようになっているとします。
PASSWORD EXPIRATION_DAYS 60
PASSWORD RESTRICT_PREVIOUS 5
PASSWORD CHANGE_MINIMUM_DAYS 20
ユーザは、60 日以内にパスワードを変更しなければなりません。パスワードは 5 回
以上変更しないと、前と同じものを使用できません。パスワードの変更後は、最低
20 日経過しないと再び変更できません。
データベースのアクセス権とセキュリティ 7-31
パスワードでのログイン名の使用制限
パスワードでのログイン名の使用制限
rbw.config ファイルのパラメータ PASSWORD ALLOW_LOGNAME を設定して、パ
スワードでのユーザ ログイン名の使用を制限できます。このパラメータは、次の構
文により設定します。
PASSWORD
ALLOW_LOGNAME
ON
OFF
最初のログイン時での初期パスワードの強制変更
rbw.config ファイルのパラメータ PASSWORD CHANGE_INITIAL を設定して、ユー
ザの最初のログイン時に初期パスワードの変更を強制することができます。このパ
ラメータは、次の構文により設定します。
PASSWORD
CHANGE_INITIAL
OFF
ON
ユーザ初期パスワードの即時変更を求めるには、このパラメータの設定を ON に変
更します。
変更前後のパスワードに関する強制
古いパスワードの数値部分だけの変更を認めないためには、パラメータ
PASSWORD COMPLEX_NUMERIC とパラメータ PASSWORD
RESTRICT_PREVIOUS を設定します。
パラメータ PASSWORD COMPLEX_NUMERIC は、古いパスワードの 1 つまたは複
数の数値以外の部分を変更する必要があるかを設定します。このパラメータは次の
構文により、rbw.config ファイルで設定します。
PASSWORD
COMPLEX_NUMERIC
OFF
ON
7-32 Administrator’s Guide
変更前後のパスワードに関する強制
ユーザに古いパスワードの数値の 1 つ以上を必ず変更させるには、このパラメータ
とパラメータ PASSWORD RESTRICT_PREVIOUS を組み合わせて設定することが必
要です。パラメータ RESTRICT_PREVIOUS を指定しないと、デフォルト値の 0 が
設定され、古いパスワードの再作成に関する制約がなくなります。
データベース管理者 ( または USER_MANAGEMENT タスク権限を持っているユー
ザ ) は自分のパスワードについて PASSWORD COMPLEX_NUMERIC による制限を
受けますが、ほかのユーザには前のパスワードをいつでも割り当てることができま
す。
例
rbw.config ファイルのエントリが、以下のようになっているとします。
PASSWORD ALLOW_LOGNAME OFF
ユーザは、自分のログイン名をパスワードの一部として使用できません。したがっ
て、以下の GRANT CONNECT 文が owen から出されると、エラー メッセージが返
されます。
grant connect to owen with 'pw2owen1' ;
** ERROR ** (1043) New password for user owen must not contain the
login name.
rbw.config ファイルのエントリが、以下のようになっているとします。
PASSWORD RESTRICT_PREVIOUS 4
PASSWORD COMPLEX_NUMERIC ON
また、user1 と user2 が以下の GRANT CONNECT 文を実行して、有効なパスワード
を作成するとします。
grant connect to user1 with 'sample1' ;
grant connect to user2 with 'other1samp2' ;
ユーザはパスワードを変更する場合、古いパスワードの数値を置き換えるだけでは
なく、ほかの部分も変更する必要があります。したがって、user1 と user2 からそれ
ぞれ出される以下の GRANT CONNECT 文では、パスワードの変更前後で数値の部
分しか変わっていないため、エラー メッセージが返されます。
grant connect to user1 with 'sample3' ;
grant connect to user2 with 'other2samp4' ;
ただし DBA で上記の GRANT 文を実行すると、正常に終了します。
データベースのアクセス権とセキュリティ 7-33
パスワードの文字の組み合わせと長さの指定
パスワードの文字の組み合わせと長さの指定
パラメータ PASSWORD MINIMUM_LENGTH と、パスワードの文字を指定するパラ
メータを使用すると、複雑で安全なパスワードをユーザに作成させることができま
す。
パラメータ PASSWORD MINIMUM_LENGTH は、パスワードの必要最少文字数を指
定し、文字を指定するパラメータは、アルファベット文字、数字、句読文字 ( 文字、
数字、空白以外の印刷文字 ) の必要最少数を指定します。文字を指定するパラメー
タは次のとおりです。
PASSWORD COMPLEX_NUM_ALPHA
PASSWORD COMPLEX_NUM_NUMERICS
PASSWORD COMPLEX_NUM_PUNCTUATION
構文 : MINIMUM_LENGTH
パスワードの必要最少文字数を指定するには、次の構文による設定を rbw.config
ファイルに記述します。
PASSWORD
MINIMUM_LENGTH
<num_characters>
<num_characters>
パスワード当たりの必要最少文字数を指定します。0 ∼ 128 の
整数でなければなりません。デフォルトは 0 で、最少文字数に
は制限がなくなります。
構文 : COMPLEX_NUM_ALPHA
パスワードに使用するアルファベット文字の必要最少数を指定するには、次の構文
による設定を rbw.config ファイルに記述します。
PASSWORD
COMPLEX_NUM_ALPHA
<num_alpha>
7-34 Administrator’s Guide
<num_alpha>
パスワードに使用するアルファベット文字の必要最少数を指定しま
す。0 ∼ 42 の整数でなければなりません。デフォルトは 0 で、最
少文字数には制限がなくなります。
パスワードの文字の組み合わせと長さの指定
構文 : COMPLEX_NUM_NUMERICS
パスワードに使用する数字の必要最少数を指定するには、次の構文による設定を
rbw.config ファイルに記述します。
PASSWORD
COMPLEX_NUM_NUMERICS
<num_numerics>
<num_numerics>
パスワードに使用する数字の必要最少数を指定します。0 ∼ 42
の整数でなければなりません。デフォルトは 0 で、最少文字数
には制限がなくなります。
構文 : COMPLEX_NUM_PUNCTUATION
パスワードに使用する句読文字の必要最少数を指定するには、次の構文による設定
を rbw.config ファイルに記述します。
PASSWORD
COMPLEX_NUM_PUNCTUATION
<num_punctuation>
<num_punctuation>
パスワードに使用する句読文字の必要最少数を指定します。
0 ∼ 42 の整数でなければなりません。デフォルトは 0 で、最
少文字数には制限がなくなります。
使用上の注意
■
■
パスワードの文字を指定するパラメータを使用すれば、パラメータ
PASSWORD MINIMUM_LENGTH は使用しなくてもかまいません。文字を
指定するパラメータの設定値を合計したものが、必要最少文字数になりま
す。
必要最少文字数を指定する場合は、文字を指定するパラメータの合計値よ
り大きな値を指定しなければなりません。そうでなければ、文字を指定す
るパラメータの合計値が必要最少文字数になります。
データベースのアクセス権とセキュリティ 7-35
接続失敗によるユーザ アカウントのロック
例
rbw.config ファイルのエントリが、以下のようになっているとします。
PASSWORD
PASSWORD
PASSWORD
PASSWORD
COMPLEX_NUM_ALPHA 4
COMPLEX_NUM_NUMERICS 2
COMPLEX_NUM_PUNCTUATION 2
COMPLEX_MINIMUM_LENGTH 10
新規パスワードは 10 文字以上とし、アルファベット文字が 4 つ以上、数字が 2 つ以
上、句読文字が 2 つ以上含まれていなければなりません。以下の GRANT
CONNECT 文のパスワードは有効です。
grant connect to craig with 'dbs1are2fun$%' ;
grant connect to james with 'sq67lis%fu*%' ;
以下の GRANT CONNECT 文ではエラー メッセージが表示されます。上記の設定に
より、パスワードが無効になるためです。
grant connect to maria with dbuser ;
grant connect to prema with perfor12mance ;
接続失敗によるユーザ アカウントのロック
パラメータ PASSWORD LOCK_FAILED_ATTEMPTS を設定すると、パスワード入力
ミスの回数を制限することができます。データベースへの接続失敗により、ユーザ
アカウントがロックされるまでの入力ミスの連続回数を指定します。データベース
との接続が成功すると、そのユーザの失敗回数がリセットされます。
構文
パスワード入力ミスの回数を制限するには、次の構文による設定を rbw.config ファ
イルに記述します。
PASSWORD
LOCK_FAILED_ATTEMPTS
<num_attempts>
7-36 Administrator’s Guide
<num_attempts>
データベースへの接続失敗により、ユーザ アカウントがロック
されるまでの入力ミスの連続回数を指定します。0 ∼ 128 の整数
でなければなりません。デフォルトは 0 で、入力ミスの回数には
制限がなくなります。
接続失敗によるユーザ アカウントのロック
接続を禁止する時間の指定
アカウントをロックする時間は、パラメータ PASSWORD LOCK_PERIOD_HOURS
で指定することができます。入力ミスの許容回数を超えると、そのユーザ アカウン
トによる接続が禁止される時間を指定します。設定した時間が経過すると、同じパ
スワードを使ってデータベースに接続できるようになります。
構文
接続を禁止する時間を指定するには、次の構文による設定を rbw.config ファイルに
記述します。
PASSWORD
LOCK_PERIOD_HOURS
<num_hours>
<num_hours>
入力ミスの許容回数を超えた場合に、ユーザ アカウントをロックす
る時間を指定します。0 ∼ 128 の整数でなければなりません。デ
フォルトは 0 で、ロックする時間の制限がなくなります。0 に設定
し、アカウントがロックされた場合は、データベース管理者 ( また
は USER_MANAGEMENT タスク権限を持っているユーザ ) が新規パ
スワードを割り当てなければなりません。
ロックされたアカウントの状態
アカウントがロックされたユーザは、データベース管理者が新規パスワードを割り
当てるか、PASSWORD LOCK_PERIOD_HOURS に設定した時間が経過するまで
データベースに接続できません。
アカウントがロックされると、RBW_USERAUTH システム テーブルに示されてい
るユーザの状態が、有効からロックに変わります。データベース管理者が新規パス
ワードを割り当てると、ユーザの状態は有効に戻ります。ユーザの状態を
RBW_USERAUTH テーブルで確認するには、以下のクエリを実行します。
select grantee, locked
from rbw_userauth
where grantee = 'user_name' ;
データベースのアクセス権とセキュリティ 7-37
第8章
組織におけるデータベース
運用の管理
データベース動作を管理するためのタスク権限
.
.
.
.
.
.
.
.
8-4
.
.
.
.
.
.
.
.
8-4
動的統計テーブルによるデータベース動作の監視
Read と Write の統計値 . . . . . . . .
Read 回数の定義 . . . . . . . . .
Write 回数の定義 . . . . . . . . .
プラットフォームへの従属性 . . . .
.
.
.
.
.
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
. .
8-6
8-7
8-7
8-9
8-9
データベース動作の制御
. . . . . . . .
データベースを静止状態にする . . . . .
データベースを稼働状態にする . . . . .
累積統計値のリセット . . . . . . . .
ユーザ コマンドの取り消し . . . . . .
ユーザ セッションの終了 . . . . . . .
現在のセッションでのユーザ優先順位の変更
.
.
.
.
.
.
.
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
. .
. .
. .
. .
8-9
8-10
8-10
8-11
8-11
8-11
8-12
管理デーモン プロセス . . . . . .
統計データの収集期間 . . . . .
DST の更新間隔 . . . . . . .
. . . .
. . . .
. . . .
. . . . .
. . . . .
. . . . .
. .
. .
. .
8-12
8-14
8-14
イベントのロギング . . . .
ロギングのサブシステム .
ログ デーモン . . . .
ログ ビューア . . . .
イベント ログ メッセージ .
イベントの重要度 . .
イベントのカテゴリ .
監査イベント . . . .
エラー イベント . . .
オペレーション イベント
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-15
8-16
8-16
8-17
8-21
8-21
8-22
8-22
8-22
8-23
管理データベース .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
スキーマ イベント . . . . . .
一般利用イベント . . . . . .
ログファイル . . . . . . . . .
ロギング機能の環境設定 . . . . .
起動状態の設定 . . . . . . .
ログ ファイルのロケーション指定 .
ログ ファイルの最大サイズ指定 .
ログのフィルタ レベルの設定 . .
ロギング動作の制御 . . . . . .
ロギングの開始 . . . . . . .
ロギングの停止 . . . . . . .
ログ ファイルの切り換え . . . .
ログのフィルタ レベルの変更 . .
ログ デーモンの終了 . . . . .
クエリのロギング . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-23
8-23
8-24
8-25
8-25
8-25
8-26
8-27
8-27
8-28
8-28
8-28
8-28
8-28
8-29
Advisor ロギングの制御 . . . . . . .
Advisor ログ ファイル . . . . . .
Advisor のログ項目 . . . . . . .
Advisor ログの開始と停止 . . . . .
ADMIN ADVISOR_LOGGING . .
ALTER SYSTEM . . . . . . .
ADMIN ADVISOR_LOG_ DIRECTORY
ADMIN ADVISOR_LOG_MAXSIZE . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
8-29
8-29
8-30
8-31
8-31
8-32
8-32
8-33
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-34
8-35
8-35
8-37
8-38
8-38
8-38
8-39
8-39
8-40
8-40
8-40
8-41
8-41
アカウンティング . . . . . . . . . . . . .
アカウンティング プロセス . . . . . . . .
アカウンティング レコードのフォーマット . . .
アカウンティング ファイル . . . . . . . .
アカウンティングの環境設定 . . . . . . . .
起動状態の設定 . . . . . . . . . . .
アカウンティング ファイルのロケーション指定
アカウンティング ファイルの最大サイズ指定 .
アカウンティング モードの設定 . . . . .
アカウンティングの制御 . . . . . . . . .
アカウンティングの開始 . . . . . . . .
アカウンティングの停止 . . . . . . . .
アカウンティング ファイルの切り換え . . .
アカウンティング モードの変更 . . . . .
8-2 Administrator’s Guide
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
この章について
この章では、IBM Red Brick Warehouse のリソースの監視と制御に関連するタスクに
ついて説明します。以下について説明します。
■
■
■
■
■
■
■
データベース動作を管理するためのタスク権限
管理データベース
動的統計テーブルによるデータベース動作の監視
データベース動作の制御
管理デーモン プロセス
イベントのロギング
Advisor ロギングの制御
全社的なデータベース管理にはさまざまなタイプがありますが、以下のような共通
の特徴があります。
■
■
■
■
■
複数のプラットフォームに、複数の Red Brick Warehouse がインストールさ
れている。
複数のデータベースにデータを複製する。
データベースにアクセスするユーザ数が比較的多い。
データベースにアクセスするユーザの技術水準が様々。
異なる部門のユーザがデータベースにアクセスする。
データベース管理には以下のようなものがあります。
■
■
■
データベース資源 (CPU 稼働時間、データベース テーブル、ディスクの入
出力など ) の競合の監視と制御
利用者による経費負担のためのユーザや部門ごとのデータベースの使用率
の統計
複数データベースのテーブル間におけるデータのコピー
データベース サーバ間におけるデータの移動については、『RISQL Entry
Tool and RISQL Reporter User’s Guide』で、コピー管理ユーティリティである
rb_cm についての説明を参照してください。
データベース管理者は、ユーザのデータベース操作、セッション、各セッションか
ら実行されるクエリ、資源の競合、システムの誤使用、資源を消費しているクエリ
の識別などデータベース動作の制御を監視する必要があります。
組織におけるデータベース運用の管理
8-3
データベース動作を管理するためのタスク権限
データベース動作を管理するためのタスク権限
データベース動作の監視と制御を行うユーザは、ACCESS_SYSINFO と
ALTER_SYSTEM という 2 つのタスク権限を持っている必要があります。これらの
権限は、DBA システム ロールに含まれています。タスク権限の詳細は、第 7 章
「データベースのアクセス権とセキュリティ」を参照してください。
ACCESS_SYSINFO 権限を持っているユーザは、自分が現在接続しているデータ
ベースの動作を監視できます。ALTER_SYSTEM 権限を持っているユーザは、自分
が現在接続しているデータベースの動作を制御できます。
管理データベース
データベース管理者は、管理データベースを使用して、組織内の全データベースの
監視と制御を行います。IBM Red Brick Warehouse 管理データベースを作成するオプ
ションを指定できます。IBM では、管理データベースの作成を推奨しています。オ
プションを指定すると、admin_db のサブディレクトリに管理データベースが作成
されます。
このデータベースは管理のみを目的としています。システム テーブルを格納するだ
けのデータベースであり、セグメントや通常のテーブルを作成することはできませ
ん。管理データベースには、以下の機能があります。
■
■
管理データベースに対する ACCESS_SYSINFO 権限を持ち、管理データ
ベースに接続しているユーザは、すべてのデータベースに関するデータ
ベース動作の統計を取得できます。
管理データベースに対する ALTER_SYSTEM 権限を持ち、管理データベー
スに接続しているユーザは、すべてのウェアハウス データベースに対する
管理操作を実行できます。
次の図は、管理データベースの役割を示したものです。
8-4 Administrator’s Guide
管理データベース
図 8-1
管理データベースの役割
接続
監視と制御
データベース
1
Admin
database
接続
DBA
接続
監視と制御
データベース
2
監視と制御
DBA
管理 DBA
接続
監視と制御
データベース
3
DBA
IBM Red Brick Warehouse 環境
組織におけるデータベース運用の管理
8-5
動的統計テーブルによるデータベース動作の監視
動的統計テーブルによるデータベース動作の監
視
データベース サーバ内の各アクティブ データベースに関する動作の統計値は、動
的統計テーブル (DST) を検索して参照できます。データベース管理者は、DST を検
索することでデータベースを監視できます。DST は一時的な格納領域です。つま
り、ディスクではなくメモリに格納され、定期的に更新されます。DST はディスク
には存在しませんが、RBW_TABLES システム テーブルにエントリがあります。こ
れらのエントリを使い、DST へのクエリをフロントエンド ツールから実行できま
す。動的統計テーブルには、以下のものがあります。
■
■
■
■
■
DST_DATABASES
DST_USERS
DST_SESSIONS
DST_COMMANDS
DST_LOCKS
列名と各テーブルの説明については、付録 C「システム テーブルと動的統計テーブ
ル」を参照してください。
接続中のデータベースに ACCESS_SYSINFO 権限を持っているユーザは、そのデー
タベースに関連した DST の行を参照できます。管理データベースに
ACCESS_SYSINFO 権限を持ち管理データベースに接続しているユーザは、管理
デーモンが監視している全データベースの DST 情報を参照することができます。
管理デーモンには、管理デーモンの起動後に 1 回以上アクセスされたデータベース
の情報と、1 回以上データベースにアクセスしたデータベース ユーザの情報だけが
保持されます。管理デーモンの詳細は、8-12 ページ「管理デーモン プロセス」を参
照してください。
ヒント：DST の列から管理用のビューを設定することもできます。
8-6 Administrator’s Guide
Read と Write の統計値
Read と Write の統計値
一般に DST には、以下の入出力に関する統計値が格納されます。
■
■
■
キャッシュの Read 回数と Write 回数
論理 Read 回数と論理 Write 回数
物理 Read 回数と物理 Write 回数
これらは、重要ですが誤った解釈をされやすい統計値です。これらの統計値の定義
を以下に説明します。
Read 回数の定義
セッションでデータの読み取りまたは書き込み操作を実行する場合、ローカルバッ
ファキャッシュのブロックを見るたびに、データベース サーバはキャッシュの
Read 回数を 1 つ増やします。セッションでデータを書き込む場合、書き込み操作を
実行するためには、あらかじめデータベース サーバはキャッシュの中のブロックか
らデータを読み取る必要があります。このためキャッシュの Read 回数は、書き込
み操作によっても値が増えます。
これらの統計値の定義を以下に説明します。データを読み込むセッションは、その
データのロケーション ( 特定のブロック ) を判定し、そのブロックをロックします。
データベース サーバ プロセスは、要求されたブロックがローカル バッファ キャッ
シュに存在するかどうかを確認します。存在する ( キャッシュにすでに読み込まれ、
セッションで利用できる ) 場合は、ブロックがロックされ、キャッシュの Read 回数
が 1 増えます。その後、ロックされたブロックから個々の行が読み込まれても、
キャッシュの Read 回数は変わりません。この統計値は、ブロックの Read 要求だけ
をカウントするからです。要求されたブロックがローカル バッファ キャッシュに
存在しない場合は、論理 Read 要求をセッションが出し、論理 Read 回数が増えま
す。
論理 Read とは、データのブロックを読み込むためにオペレーティング システムを
呼び出すことです。そのデータがオペレーティング システムのバッファに存在する
と、ディスクの物理 Read は不要になります。データがオペレーティング システム
のバッファに存在しないと、オペレーティング システムはディスクから読み込みを
行うため、物理 Read 回数が増えます。
組織におけるデータベース運用の管理
8-7
Read と Write の統計値
以下に、キャッシュの Read、論理 Read、物理 Read のカウントを示します。
図 8-2
Read 統計値の記録方法
サーバの制御
ローカル バッファ
キャッシュ
オペレーティング システムの制御
オペレーティング
システムのバッファ
キャッシュ
ディスク
ブロック
Read 要求
キャッシュ Read
回数が 1 増える
論理 Read 回数が
2 増える
物理 Read 回数が
1 増える
キャッシュの Read と論理 Read の回数を合計した値が、ブロック Read 要求数になり
ます。ブロック Read 要求数に対するキャッシュ Read 要求数が、キャッシュ バッ
ファのヒット率です。
ヒント：システム テーブルの読み込みでは、ローカル バッファ キャッシュが使用
されないため Read 統計は記録されませんが、全体に占める比率が低いので、総合
的なキャッシュ ヒット比率にはあまり影響がありません。
8-8 Administrator’s Guide
データベース動作の制御
Write 回数の定義
書き込みを行うプロセスは、対象のメモリ ブロックをロックしようとします。次の
ケースについて考えてみます。
■
■
■
ブロックが、ローカル バッファ キャッシュに存在しない場合 : データベー
ス サーバはディスクからブロックを読み込む必要があり、データベース
サーバ プロセスは書き込みからブロックをロックできます。このブロック
への書き込みを終了すると、データベース サーバはそのブロックをディス
クに書き戻すため、論理 Write 回数が 1 増えます。
ブロックがローカル バッファ キャッシュに存在し、まだ書き込まれてい
ない場合 : データベース サーバ プロセスは、書き込みからブロックをロッ
クできます。また、データベース サーバは最終的にそのブロックをディス
クに書き戻す必要があるため、論理 Write 回数が 1 増えます。
ブロックがローカル バッファ キャッシュにあり、使用済みの場合、すで
にブロックは書き込まれています。データベース サーバ プロセスは、そ
のブロックをロックして書き込むことができます。すでに実行されていた
書き込みにより、論理 Write 回数がカウントされているため、論理 Write 回
数は変わりません。キャッシュの Write 回数が 1 増えます。
プラットフォームへの従属性
通常オペレーティング システムは、論理 Read や論理 Write に対して、ディスクへの
物理 Read または物理 Write も行います。ただし、オペレーティング システムは物理
I/O データを保持するため、これらの統計が利用できるかどうかはプラットフォー
ムにより異なります。
データベース動作の制御
データベース動作を制御するには、ALTER SYSTEM 文を使用します。
ALTER_SYSTEM 権限を持っているユーザは、ALTER SYSTEM 文を実行すれば、接
続中のデータベースの利用を制御できます。管理データベースの ALTER_SYSTEM
アクセス権を持ち、管理データベースに接続しているユーザは、ALTER SYSTEM
文を使用すれば、ウェアハウス内の全データベースの使用を制御できます。
組織におけるデータベース運用の管理
8-9
データベースを静止状態にする
必要な権限を持つユーザが、ALTER SYSTEM 文によって実行できる操作は、次の
とおりです。
■
■
■
■
■
■
データベースを制止状態にする
データベースを稼働状態にする
累積統計値のリセット
ユーザ コマンドの取り消し
ユーザ セッションの終了
現在のセッションでのユーザ優先順位の変更
以下の節では、上記の各操作について説明します。ALTER SYSTEM 文については
は、『SQL Reference Guide』を参照してください。
データベースを静止状態にする
ALTER SYSTEM QUIESCE DATABASE 文を使うと、データベースを静止状態にする
ことができます。制止状態のデータベースに対しては、新規セッションを起動した
り、既存セッションが新規にコマンドを実行することはできません。現在実行中の
コマンドは完了できます。
この文は、rbwapid デーモン プロセスを停止する準備として使用します。制止状態
は、ディスク ドライブのメンテナンスなどの保守作業にも使用します。
重要 : IGNORE_QUIESCE タスクのアクセス権を持っているユーザは、静止状態
のデータベースで作業を行うことができ、その間、ほかのユーザからの ALTER
SYSTEM QUESCE DATABASE 文は受け付けません。DBA システム ロールのメン
バーである全ユーザは、自動的に IGNORE_QUIESCE タスク権限を持っています。
データベースを稼働状態にする
データベースを通常の稼働状態にするには、ALTER SYSTEM RESUMEDATABASE
文を使用します。
RESUME DATABASE 句は、既存セッションから ( 静止データベースでは新規セッ
ションを起動できないため )、または管理データベースに ALTER SYSTEM 権限を持
ち、管理データベースに接続しているユーザが実行しなければなりません。
8-10 Administrator’s Guide
累積統計値のリセット
累積統計値のリセット
データベースの DST 統計値を 0 にリセットするには、ALTER SYSTEM RESET
STATISTICS 文を使用します。
ユーザ コマンドの取り消し
ALTER SYSTEM CANCEL USER COMMAND 文を使うと、ユーザのセッションで現
在実行中の文を取り消すことができます。現在実行中のコマンドは、以下のセッ
ションについても取り消すことができます。
■
■
あるデータベースのあるユーザの全セッション
あるデータベースの全ユーザの全セッション
管理データベースに対する ALTER_SYSTEM 権限を持っているユーザは、以下の
セッションで現在実行中の文も取り消すことができます。
■
■
全データベースのあるユーザの全セッション
全データベースの全ユーザの全セッション
コマンドを実行していないセッションでは、ALTER SYSTEM CANCEL COMMAND
文は無視されます。
ユーザ セッションの終了
ユーザのセッションを終了させるには、ALTER SYSTEM CLOSE USER SESSION 文
を使用します。以下のセッションも終了させることができます。
■
■
あるデータベースのあるユーザの全セッション
あるデータベースの全ユーザの全セッション
管理データベースに対する ALTER_SYSTEM 権限を持っているユーザは、以下の
セッションも終了させることができます。
■
■
全データベースのあるユーザの全セッション
全データベースの全ユーザの全セッション
このオプションを使ってセッションを終了させると、現在実行中のコマンドは取り
消され、オペレータによりセッションが終了したことを通知するメッセージが各
セッションに送信されます。
組織におけるデータベース運用の管理
8-11
現在のセッションでのユーザ優先順位の変更
現在のセッションでのユーザ優先順位の変更
ALTER SYSTEM CHANGE USER PRIORITY 文を使うと、ユーザのセッションの優先
順位を変更することができます。優先順位は、以下のセッションについても変更で
きます。
■
■
あるデータベースのあるユーザの全セッション
あるデータベースの全ユーザの全セッション
管理データベースに対する ALTER_SYSTEM 権限を持っているユーザは、以下の
セッションの優先順位も変更することができます。
■
■
全データベースのあるユーザの全セッション
全データベースの全ユーザの全セッション
ユーザ優先順位の変更は、指定したセッションについて即時に有効になり、
DST_SESSIONS テーブルの PRIORITY 列に反映されます。ただし、この変更はセッ
ションが終了すると無効になります。そのユーザが新規セッションを次に起動した
時は、変更前の優先順位に戻ります。ユーザの優先順位を変更するには、『SQL
Reference Guide』で説明している ALTER USER を使用します。
UNIX
ユーザ優先順位をサポートするには、UNIX の renice コマンドを実行できるプラッ
トフォームを使用してください。構成パラメータ ADMIN RENICE_COMMAND に
renice スクリプトの絶対パスを指定してください。♦
管理デーモン プロセス
デーモン プロセスは、ALTER SYSTEM 文にしたがい DST の統計値を収集します。
管理デーモン プロセス (rbwadmd) は、ウェアハウス デーモン プロセス (rbwapid)
とログ デーモン プロセス (rbwlogd) の起動と同時に起動されます。
停止中の管理デーモンを再起動する方法の詳細は、9-96 ページ「UNIX でのデータ
ベース サーバの監視と制御」または 9-99 ページ「Windows でのデータベース サー
バの監視と制御」を参照してください。
8-12 Administrator’s Guide
管理デーモン プロセス
管理デーモンは、TMU プロセスとデータベース サーバ プロセスから統計値を収集
し、データベース サーバ プロセスに DST データを返します。次の図は、管理デー
モンとほかのデータベース プロセス間の統計データの流れを示しています。
図 8-3
rbwadmd とほかのデータベース プロセス間の統計データの流れ
統計値
統計値
rb_tmu
rbwadmd
rbwsvr
DST データ
サーバ プロセス
管理デーモンは、データベース サーバ プロセスから ALTER SYSTEM 文を受け取
り、TMU プロセスやほかのサーバ プロセスに対して適切な管理動作を実行します。
以下の図は、管理デーモンとほかのサーバ プロセス間の ALTER SYSTEM による制
御の流れを示しています。
図 8-4
ALTER SYSTEM による制御の流れ
管理動作
管理動作
rb_tmu
rbwadmd
ALTER SYSTEM
文
rbwsvr
サーバ プロセス
組織におけるデータベース運用の管理 8-13
統計データの収集期間
統計データの収集期間
データベース動作に関する統計値の収集は、管理デーモンの起動と同時に開始さ
れ、このプロセスが終了するまで続けられます。データベースの統計値をリセット
しないかぎり、管理デーモンが動作している間が収集期間になります。
管理デーモンを終了すると、動的統計テーブルに格納されている統計値は、すべて
消失します。
管理デーモンは、管理デーモン (UNIX) または Red Brick Warehouse サービス
(Windows) の起動後に 1 回以上アクセスされたデータベースについてのみ統計値を
収集します。同様に、管理デーモンは、管理デーモンの起動後に 1 回以上データ
ベースにアクセスしたデータベース ユーザについてのみ統計値を収集します。
ある ( またはすべての ) データベースの全統計値を 0 にリセットするには、ALTER
SYSTEM RESET STATISTICS 文を使用します。
DST の更新間隔
動的統計テーブルを更新する最大間隔を設定するには、構成パラメータ ADMIN
REPORT_INTERVAL と SET REPORT_INTERVAL コマンドを使用します。この間隔
は +/- 1 分の誤差しかなく、同時実行時はさらに誤差が小さくなります。
状態の変更を要求するコマンド、または、ロックを要求、取得、解除するセッショ
ンがあると必ず、データベース サーバは動的統計テーブルに更新データを送りま
す。コマンドの実行状態には、接続、アイドル、実行、コンパイル、演算、結果行
の抽出、ソート、インデックスの作成、挿入などがあります。これらのイベントの
間隔が、パラメータ ADMIN REPORT_INTERVAL の設定値を超えると、動的統計
テーブルが自動的に更新されます。セッションの間、ADMIN REPORT_INTERVAL
値を優先するには、SET REPORT_INTERVAL コマンドを使用します。
8-14 Administrator’s Guide
イベントのロギング
構文
ADMIN REPORT_INTERVAL を設定するには、rbw.config ファイルにエントリを追
加します。このパラメータを設定する構文は次のとおりです。
ADMIN REPORT_INTERVAL
<integer>
<integer> の値は、分単位で指定します。
セッションの DST の更新間隔を設定するには、次の構文で SET
REPORT_INTERVAL コマンドを実行します。
SET REPORT_INTERVAL
<integer>
;
構成パラメータを設定するか、セッションに対する SET REPORT_INTERVAL コマ
ンドを発行することで、DST の更新間隔を 0 に設定すると、統計値を収集しませ
ん。
イベントのロギング
全社的なシステムでは、異なる部門から多数のユーザが同じ IBM Red Brick
Warehouse データベースにアクセスすることがあります。このような環境では、一
般利用イベント、オペレーション イベント、監査イベントなどのシステム イベン
トを記録しておくと便利です。イベント ロギング機能は上記の情報を提供し、シス
テムが適正に利用されていることの確認や、エラー状態の診断に役立てることがで
きます。
イベント ロギング機能は、各種のデータベース サーバ イベント ( 監査イベント、エ
ラー状態、管理操作、スキーマ変更、エンド ユーザ操作など ) の記録を生成し、
ディスクに格納します。ログはリアルタイムに表示できますが、特定の間隔 (1 日ご
となど ) を指定してシステム履歴データを分析することもできます。
組織におけるデータベース運用の管理 8-15
ロギングのサブシステム
ロギングのサブシステム
イベント ロギング機能は別のサブシステムであるロギングのサブシステムで処理さ
れます。ロギングのサブシステムで処理されます。ロギング機能の環境設定このサ
ブシステムは、ログ デーモンとログ ビューアで構成されます。
ログ デーモン
ログ デーモン プロセス (rbwlogd) は、各種イベントの発生時に Red Brick Warehouse
プロセスが出すログ要求メッセージを処理します。
UNIX では、ログ デーモンは、ウェアハウス デーモン (rbwapid) の起動時に、ウェ
アハウス デーモンによって起動されます。Windows では、ログ プロセスは、Red
Brick Warehouse サービスの起動時に、ウェアハウス スレッド (rbw.exe) によって起
動されます。どのデータベース サーバ プロセスも、ログ要求メッセージをログ
デーモンに送信できます。
たとえば、rb_tmu プロセスからのロード開始メッセージや、rbwapid プロセスから
のデータベース サーバの異常停止メッセージを受けます。ログ要求メッセージを出
したウェアハウス プロセスは、ログ デーモンが受信したことを確認しません。こ
れは、性能が低下しないように、データベース サーバとログ デーモン間の通信を
一方通行にしてあるからです。たとえば、ユーザがテーブルを削除すると、その
ユーザのデータベース サーバ プロセスはログ デーモンにメッセージを送り、処理
を続行します。次の図は、ログ デーモンの役割を示したものです。
図 8-5
ログ デーモン
ログ要求
メッセージ
ログ デーモン
(rbwlogd)
ファイルへの
ログ書き込み
ログ ファイル
ウェアハウス プロセス
(rbwapid、rbwsvr、rb_tmu など )
データベース サーバ プロセスからログ要求メッセージを受けたログ デーモンは、
タイムスタンプを追加し、メッセージの内容をログ ファイルに書き込みます。書き
込み可能な状態のログ ファイルは、1 度に 1 つしかありません。イベントをロギン
グしていない時は、アクティブ ログ ファイルがありません。ディスクの使用領域
が構成パラメータ ADMIN LOG_MAXSIZE で設定された制限値に達すると、ログ
デーモンがファイルを閉じ、新規ファイルを初期化します。詳細は、8-24 ページ
「ログファイル」を参照してください。
8-16 Administrator’s Guide
ロギングのサブシステム
ログ ビューア
ログの内容を参照するには、ログ ビューア ユーティリティを使用します。ログ
デーモンは、ログ メッセージに含まれるパラメータ値をログ ファイルに書き込み
ますがすべてのメッセージ テキストを書き込むわけではありません。メッセージの
テキストは、メッセージ基本ファイルにテンプレートとして格納されています。ロ
グ ビューアは、対応するメッセージ テンプレートと、ログ ファイルに格納されて
いるパラメータ値を組み合わせ、文章にして出力します。このメッセージは、標準
出力に表示されるか、ファイルに書き込まれます。メッセージ パラメータの詳細
は、8-21 ページ「イベント ログ メッセージ」を参照してください。
図 8-6
ログ ビューア
ログ ビューア
ログ ファイル
標準出力に
メッセージを表示
メッセージ基本ファイル
ログ ビューアの実行ファイル名は、UNIX では rbwlogview、Windows では logdview
です。ログ ファイルの Read アクセス権を持っているユーザは、ログ ビューアを
使ってイベント メッセージを参照することができます。ログ ファイルの所有者は、
redbrick アカウントです。
組織におけるデータベース運用の管理 8-17
ロギングのサブシステム
コマンドの構文は次のとおりです。
<rbwlogview> [-a] [-t] [-e] [-f] [-p <pid>]
[-d <database> [[-d <database>] ...]]]
[-i <sourceid> [[-i <sourceid>] ...]]]
[-c [a][e][o][s][u]]
[-s [a][r][u]]
[<logfile> [[<logfile>] ...]]
UNIX
♦
<logdview> [-a] [-t] [-e] [-f] [-p <pid>]
[-d <database> [[-d <database>] ...]]]
[-i <sourceid> [[-i <sourceid>] ...]]]
[-c [a][e][o][s][u]]
[-s [a][r][u]]
[<logfile> [[<logfile>] ...]]
Windows
♦
オプション
説明
-a
書き込み中のログ ファイルを指定します。このオプションを使用
した場合は、<logfile> を指定することはできません。
-t
見出しを略記する terse 出力フォーマットを指定します。
-e
書き込み中のログ ファイル (-a) または指定されているログ ファイ
ル (<logfile>) の継続表示を指定します。新規レコードは、指定の
ファイルに書き込まれるとともに標準出力にも表示されます
(UNIX の tail コマンドと同様 )。
このオプションは、前に -a を指定するか、後に <logfile> を指定す
る必要があります。
-f
書き込み中のログ ファイル (-a) または指定されているログ ファイ
ル (<logfile>) の継続表示を指定します。すでに記録されているレ
コードが表示された後、新規レコードがファイルに書き込まれる
とともに標準出力にも表示されます (UNIX の tail コマンドと同
様 )。
このオプションは、前に -a を指定するか、後に <logfile> を指定す
る必要があります。
-p <pid>
指定した ID を持つプロセスから発生したログ レコードのみを表示
します。
-d <database>
指定したデータベースにアクセスしているプロセスから発生した
ログ レコードのみを表示します。複数のデータベースを指定でき
ます。
(１/２)
8-18 Administrator’s Guide
ロギングのサブシステム
オプション
説明
-i <sourceid>
指定した <sourceid> (rb_tmu など ) のプロセスから発生したログ レ
コードのみを表示します。
-c
指定したカテゴリのイベントだけを表示します。a ( 監査 )、e ( エ
ラー )、o ( オペレーション )、s ( スキーマ )、u ( 一般 ) から、複数
のカテゴリを選択できます。イベント カテゴリの詳細について
は、8-22 ページ「イベントのカテゴリ」を参照してください。
-s
指定した重要度のイベントだけを表示します。u ( 緊急 )、a ( 警
告 )、r ( 通常 ) から、複数のカテゴリを選択できます。イベントの
重要度については、8-21 ページ「イベントの重要度」を参照して
ください。
<logfile>
読み込むログ ファイルを指定します。複数のファイルを指定でき
ます。その場合は、ログ デーモンが保存した順序で読み込まれま
す。ログ ファイルの詳細については、8-24 ページ「ログファイ
ル」を参照してください。
(２/２)
使用方法
ログ ビューアの入力ファイルには、複数の終了したログ ファイルか、書き込み中
のログ ファイルを指定してください。指定がなければ、標準入力になります。-a
オプションを指定すると、書き込み中のログ ファイルが入力ファイルになります。
終了したログ ファイルと -a オプションの両方を指定することはできません。
ログ ビューア プログラムとフロントエンド インタフェースを組み合わせ、標準出
力へ書き込むことができます。たとえば、次のコマンドの出力先を、グラフィカル
ユーザ インタフェースのプログラムにリダイレクトすることができます。
オペレーティング
システム
コマンド
UNIX
rbwlogview -a -e
Windows
logdview -a -e
組織におけるデータベース運用の管理 8-19
ロギングのサブシステム
UNIX
例
以下のコマンドは、rbwlog.HOST.950621.101053 という名前の終了したログ ファイ
ルのレコードを表示します。SUPPORT データベースの SCHEMA カテゴリのログ
レコードだけが表示されます。
% rbwlogview -d SUPPORT -c s rbwlog.HOST.950621.101053
Jun 21 08:59:12 rbwsvr[20158] DB:SUPPORT SCH300R:CREATE TABLE D1
completed successfully.
Jun 21 08:59:13 rbwsvr[20158] DB:SUPPORT SCH300R:CREATE SYNONYM
S2 completed successfully.
...
次のコマンドは、すべてのデータベース サーバ イベントを、ロギングするととも
に標準出力に表示します。
% rbwlogview -a -e
Jun 21 15:50:46 rbwapid[20500] OPE077R:Server process PID:6603
started for userid:"redbrick"
Jun 21 15:50:59 rbwsvr[6603] DB:AROMA_DB SCH300R:CREATE TABLE
SNOOZE completed successfully.
Windows
例
以下のコマンドは、rbwlog.HOST.950621.101053 という名前の終了したログ ファイ
ルのレコードを表示します。SUPPORT データベースの SCHEMA カテゴリのログ
レコードだけが表示されます。
c:¥> logdview -d SUPPORT -c s rbwlog.HOST.950621.101053
Jun 21 08:59:12 rbwsvr[20158] DB:SUPPORT SCH300R:CREATE TABLE D1
completed successfully.
Jun 21 08:59:13 rbwsvr[20158] DB:SUPPORT SCH300R:CREATE SYNONYM
S2 completed successfully.
...
次のコマンドは、すべてのデータベース サーバ イベントを、ロギングするととも
に標準出力に表示します。
c:¥> logdview -a -e
Jun 21 15:50:46 rbwapid[20500] OPE077R:Server process PID:6603
started for userid:"redbrick"
Jun 21 15:50:59 rbwsvr[6603] DB:AROMA_DB SCH300R:CREATE TABLE SNOOZE
completed successfully.
8-20 Administrator’s Guide
イベント ログ メッセージ
イベント ログ メッセージ
データベース サーバ プロセスによって発行されるログ メッセージには、以下のパ
ラメータがあります。
■
■
■
メッセージ カテゴリ
メッセージ番号
メッセージの重要度
いくつかのログ メッセージには、固有のパラメータが追加されます。たとえば、
ユーザがテーブルを削除すると、メッセージ カテゴリ、メッセージ番号、メッセー
ジの重要度、追加のパラメータ <table_name> を持つメッセージが生成されます。ロ
グ プロセスは、各パラメータを可変長レコードとしてログ ファイルに書き込みま
す。
ログ ビューアが表示するメッセージのフォーマットは、次のようになっています。
<CCC###S>: メッセージ テキスト
先頭の 3 文字 (<CCC>) はメッセージ カテゴリ、3 桁の数字 (<###>) はメッセージ番
号、6 桁目の文字 (<S>) はメッセージの重要度を表します。6 桁コードの後には、
メッセージのテキストが続きます。たとえば、次のようになります。
OPE081A:New accounting level is WORKLOAD
イベントの重要度
イベントは、重要度に応じて次のいずれかに分類されます。
■
ROUTINE
■
ALERT
■
URGENT
最低レベルは ROUTINE、最高レベルは URGENT です。
組織におけるデータベース運用の管理 8-21
イベント ログ メッセージ
イベントのカテゴリ
ログに記録されるイベントは、以下のカテゴリに分類されます。
■
AUDIT ( 監査 )
■
ERROR
■
OPERATIONAL ( オペレーション )
■
SCHEMA ( スキーマ )
■
USAGE
各イベントのカテゴリには、ログを記録する最低重要度を指定できます。たとえ
ば、ERROR イベントの最低重要度を ALERT にすると、重要度が ALERT と
URGENT の ERROR イベントだけがログされます。イベントのカテゴリの最低重要
度を指定するには、ALTER SYSTEM CHANGE LOGGING LEVEL 文を使うか、構成
ファイルのパラメータを直接設定します。ログの重要度の設定方法は、8-27 ページ
「ログのフィルタ レベルの設定」を参照してください。
監査イベント
監査イベントは、セキュリティとアクセスの制御に関連したイベントです。ロー
ル、アクセス権、パスワード保護などの設定に変更があると、AUDIT イベントが発
生します。監査イベントのデフォルト最低重要度は ALERT です。
AUDIT イベントの例を示します。
AUD011A:User smith supplied incorrect password.
エラー イベント
エラー イベントは、エラーや例外を発生させるユーザ操作や、データベース サー
バ システム環境の変更を示すものです。エラー イベントのデフォルト最低重要度
は ROUTINE です。
ERROR イベントの例を示します。
ERR717R:Pipe command not allowed with tape output.
8-22 Administrator’s Guide
イベント ログ メッセージ
オペレーション イベント
オペレーション イベントは、コンポーネントの起動や停止、動作状態の変更など、
データベース管理者 ( または DBA システム ロールのメンバーであるユーザ ) の管理
操作を示すものです。デフォルト最低重要度は ALERT です。
OPERATIONAL イベントの例を示します。
OPE081A:New accounting level is WORKLOAD.
スキーマ イベント
スキーマ イベントは、データベース構造の物理的変更 (PSU やセグメントの作成や
削除 )、データベース構造の論理的変更 ( すべての DDL 文 ) を示すイベントです。
デフォルト最低重要度は ROUTINE です。
SCHEMA イベントの例を示します。
SCH300R:CREATE TABLE SALES completed successfully.
一般利用イベント
一般利用イベントは、LOAD DATA 文、UNLOAD 文、すべての DML 文 (SELECT 文
など ) を含むエンド ユーザ操作です。デフォルト最低重要度は ALERT です。
USAGE イベントの例を示します。
USA302R:LOAD DATA into SALES completed.
USAGE ROUTINE イベントを設定すると、Red Brick Warehouse が処理するすべての
SQL クエリがログに記録されます。この設定は、クエリ ツールをデバックする際に
役立ちます。すべての SQL クエリがログに記録されるため、システムの使用状況
によってはログ ファイルが急速に拡大することがあります。
組織におけるデータベース運用の管理 8-23
ログファイル
ログファイル
ログ デーモンは、ログ レコードをログ ファイルに書き込みます。書き込み中の
ファイルのサイズが、構成パラメータ ADMIN LOG_MAXSIZE の設定値を超える
と、そのファイルは終了し、新規のログ ファイルが作成されます。ログ ファイル
は、ロギング プロセスを終了した時点で閉じます。次にロギングを起動した時は、
新規のログ ファイルが作成されます。このように複数のログ ファイルが累積され
ていきます。ファイルにはヘッダ情報やトレーラ情報がないため、各ファイルを作
成順に結合して処理することができます。
アクティブなログ ファイルと終了したログ ファイルは、以下の命名規則に従いま
す。
オペレーティング シ
ステム
コマンド
UNIX
rbwlog.<daemon_name>.active
rbwlog.<daemon_name>.<datetime_stamp>
Windows
rbwlog.<service_name>.active
rbwlog.<service_name>.<datetime_stamp>
終了したファイル名の <datetime_stamp> サフィックスは、ログ デーモンがファイ
ルを閉じた日付と時間を示します。
これらのファイルのデフォルト ロケーションは、$RB_CONFIG/logs ディレクトリ
(UNIX) または %RB_CONFIG%¥logs ディレクトリ (Windows) です。別のロケー
ションを指定するには、パラメータ ADMINLOG_DIRECTORY を設定します。すべ
てのログ ファイルの所有者は、redbrick アカウントです。
古くなったログ ファイルは、自動的に削除されません。データベース管理者は、古
いファイルを定期的に削除するスクリプトを作成するか、手動で削除してくださ
い。
警告 : 古いログ ファイルを削除しないと、ファイルが増え続け、ディスク領域が
不足します。また、ADMIN LOG_MAXSIZE の値を指定しておかないと、ディスク
領域がなくなるまで、1 つのログ ファイルだけに書き込みを続けます。
8-24 Administrator’s Guide
ロギング機能の環境設定
ロギング機能の環境設定
ロギング機能の環境設定を行うには、rbw.config ファイルの各種構成パラメータを
設定します。
起動状態の設定
パラメータ ADMIN LOGGING は、ログ デーモンを起動した時の動作を設定します。
このパラメータを設定する構文は次のとおりです。
ADMIN LOGGING
ON
OFF
パラメータ ADMIN LOGGING を ON にすると、ログ デーモンを起動すると同時に、
初期ログ ファイルを作成し、イベントのロギングを開始します。OFF にするとログ
デーモンを起動しても、何の動作も行われません。
ヒント：ログ デーモンの動作中、ロギングを開始するには ALTER SYSTEM START
LOGGING 文を、ロギングを停止するには ALTER SYSTEM STOP LOGGING 文を使
用します。
ログ ファイルのロケーション指定
パラメータ ADMIN LOG_DIRECTORY は、ログ デーモンが作成するログ ファイル
の格納先ディレクトリを指定します。このパラメータを設定する構文は次のとおり
です。
ADMIN LOG_DIRECTORY
<pathname>
<pathname> 変数は、絶対パスでも相対パスでもかまいません。相対パスは、環境変
数 RB_CONFIG が指定するディレクトリに対する相対パスです。パラメータ
ADMIN LOG_DIRECTORY を設定しないと、$RB_CONFIG/logs (UNIX) または
%RB_CONFIG%¥logs (Windows) がデフォルトのログ ディレクトリになります。
組織におけるデータベース運用の管理 8-25
ロギング機能の環境設定
ログ ファイルの最大サイズ指定
パラメータ ADMIN LOG_MAXSIZE は、ログ ファイルの最大サイズを指定します。
このパラメータを設定する構文は次のとおりです。
ADMIN LOG_MAXSIZE
<integer>
<integer>K
<integer>M
ログ ファイルが、このパラメータで指定されたサイズを超えると、ログ デーモン
により、ファイルが閉じられ、同じディレクトリにアクティブ ファイルが新たに作
成されます。<integer> に指定する整数の単位は、次のようになります。
■
■
■
K も M も指定しない場合は、バイト
K を指定した場合は、KB (1,024 バイト )
M を指定した場合は、MB (1,048,576 バイト )
K や M の指定は数値の直後に入力し、空白がないようにしてください。
パラメータ ADMIN ADVISOR_LOG_MAXSIZE の最小値は、10KB (10,240 バイト )
です。
警告 : このパラメータを設定しない、あるいは 0 または負数に設定すると、ログ
ファイルの最大サイズに制限がなくなります。ログ ディレクトリに利用できるディ
スク領域がなくなるまで、ログ ファイルが拡大し続けます。
8-26 Administrator’s Guide
ロギング機能の環境設定
ログのフィルタ レベルの設定
別個の構成パラメータにより、ログのフィルタ レベルが、メッセージ カテゴリご
とに 1 つ設定されます。ログのフィルタ レベルは、各カテゴリのイベントをログに
記録する最低重要度を示します。これらのパラメータを設定する構文は次のとおり
です。
ADMIN LOG_AUDIT_LEVEL
ROUTINE
ADMIN LOG_ERROR_LEVEL
ALERT
ADMIN LOG_OPERATIONAL_LEVEL
URGENT
ADMIN LOG_SCHEMA_LEVEL
ADMIN LOG_USAGE_LEVEL
ヒント：ウェアハウスの動作中は、ALTER SYSTEM CHANGE LOGGING LEVEL 文
により、各カテゴリのフィルタ レベルを変更することができます。
ロギング動作の制御
ロギングの動作は、ALTER SYSTEM コマンドで制御することができます。ALTER
SYSTEM コマンドは、以下の操作を行います。
■
■
■
■
■
ロギングの開始
ロギングの停止
ログ ファイルの切り換え
ログのフィルタ レベルの変更
ログ デーモンの終了
ヒント：ALTER SYSTEM 文を実行するには、ログ デーモンを起動しておく必要が
あります。上記の操作を行う ALTER SYSTEM 文を実行しても何も起こらない場合
は、ログ デーモンが動作中であることを確認してください。
ALTER SYSTEM 文の詳細については、『SQL Reference Guide』を参照してください。
組織におけるデータベース運用の管理 8-27
ロギング機能の環境設定
ロギングの開始
ロギングを開始するには、ALTER SYSTEM START LOGGING 文を使用します。ロ
ギングを開始すると、ログ デーモンが以下を実行します。
■
■
ログ ファイルの作成
データベース サーバ プロセスからのログ要求メッセージの受信およびロ
グ ファイルへの対応するログ レコードの書き込み
ロギングがすでに実行中の場合は、このコマンドは無視されます。
ロギングの停止
ALTER SYSTEM STOP LOGGING 文は、ロギングを停止し、書き込み中のログ ファ
イルを終了します。ログ デーモンは動作し続けるため、いつでもロギングを再開で
きます。ロギングの停止中は、このコマンドは無視されます。
ログ ファイルの切り換え
ALTER SYSTEM SWITCH LOGGING FILE 文を使用すると、アクティブ ログ ファイ
ルが閉じられ、アクティブ ログ ファイルが新たに作成され、その新規ファイルへ
のロギングが再開されます。ロギングが停止していると、このコマンドは無視され
ます。
ログのフィルタ レベルの変更
各カテゴリのログ重要度のフィルタ レベルを変更するには、ALTER SYSTEM
CHANGE LOGGING LEVEL 文を使用します。どのログ カテゴリも任意の重要度レ
ベルに変更できます。変更は、即時に有効になります。
ログ デーモンの終了
ログ デーモン プロセス (rbwlogd) を終了するには、ALTER SYSTEM TERMINATE
LOGGING DAEMON 文を使用します。ログ デーモンは、すべての書き込み中の
ファイル ( ログ ファイルとアカウント ファイルの両方 ) を閉じて保存し、終了しま
す。アカウント ファイルとアカウンティング機能の詳細については、8-34 ページ
「アカウンティング」を参照してください。
8-28 Administrator’s Guide
クエリのロギング
クエリのロギング
クエリに使用する SQL 文は、ログ ファイルの USAGE ROUTINE イベントとしてロ
グに記録されます。クエリのログを有効にするには、次のコマンドを入力します。
RISQL> alter system change logging level usage routine;
クエリのログを有効にするには、あらかじめログ デーモンを実行してください。
SQL のログを有効にすると、サーバ プロセスが処理するすべてのクエリがログ
ファイルに書き込まれます。システムの稼働状況により、ログ ファイルがすぐに
いっぱいになる可能性があります。クエリのログを有効にする場合には、ログ ファ
イルのディスク領域を十分に確保してください。
ALTER SYSTEM 文の詳細については、『SQL Reference Guide』を参照してください。
Advisor ロギングの制御
Vista Advisor には、専用のログ ファイルがあります。この節では、Advisor ロギング
を制御するコマンドを説明します。Advisor の使用方法の詳細については、『IBM
Red Brick Vista User’s Guide』を参照してください。
ヒント：Advisor ログは rbwlogview ユーティリティ (UNIX) または logdview ユー
ティリティ (Windows) で読み込むことはできません。Advisor ログ ファイルは、
Advisor システム テーブルの検索時に読み込まれます。
Advisor ログ ファイル
ログ デーモンは、ログ レコードをアクティブな Advisor ログ ファイルに記録しま
す。書き込み中のファイルのサイズが、構成パラメータ ADMIN
ADVISOR_LOG_MAXSIZE の設定値を超えると、そのファイルは終了し、新規のロ
グ ファイルが作成されます。ログ ファイルは、ロギング プロセスを終了した時点
で閉じます。次にロギングを起動した時は、新規のログ ファイルが作成されます。
このように複数のログ ファイルが累積されていきます。
組織におけるデータベース運用の管理 8-29
Advisor のログ項目
アクティブなログ ファイルと終了したログ ファイルは、以下の命名規則に従いま
す。
オペレーティング
システム
コマンド
UNIX
rbwadvlog.<daemon_name>.active
rbwadvlog.<daemon_name>.<datetime_stamp>
Windows
rbwadvlog.<service_name>.active
rbwadvlog.<service_name>.<datetime_stamp>
終了したファイル名の <datetime_stamp> サフィックスは、ログ デーモンがファイ
ルを閉じた日付と時間を示します。
これらのファイルのデフォルト ロケーションは、$RB_CONFIG/logs ディレクトリ
(UNIX) または %RB_CONFIG%¥¥logs ディレクトリ (Windows) です。別のロケー
ションを指定するには、構成パラメータ ADMIN ADVISOR_LOG_DIRECTORY を設
定します。すべてのログ ファイルの所有者は、redbrick アカウントです。
古くなったログ ファイルは、自動的に削除されません。データベース管理者は、古
いファイルを定期的に削除するスクリプトを作成するか、手動で削除してくださ
い。
警告 : 古いログ ファイルを削除しないと、ファイルが増え続け、ディスク領域が
不足します。また、ADMIN LOG_MAXSIZE の値を指定しておかないと、ディスク
領域がなくなるまで、1 つのログ ファイルだけに書き込みを続けます。
Advisor のログ項目
Advisor ログは、以下の情報をログ記録します。
情報
説明
タイムスタンプ
メッセージがログ記録された日付と時刻を示し
ます。
データベース名
使用中のデータベースの名前を示します。
基本テーブル識別番号
事前計算ビューの作成に使用された基本テーブ
ルを識別する整数。
クエリへの応答に使用された
ビューの識別番号
クエリへの応答に使用された事前計算ビューを
識別する整数。
(１/２)
8-30 Administrator’s Guide
Advisor ログの開始と停止
情報
説明
ロールアップ情報
ビューの GROUP BY に指定した列のサブセッ
トを問い合わせるクエリ、または詳細度の低い
グラニュラリティのディメンジョンの属性を問
い合わせるクエリに応答するために、ビューが
参照された回数を示す整数。
クエリおよびクエリ内の集約ブ
ロックごとの処理時間
クエリの集約部分の実行にかかった合計時間を
示す整数。
集約ブロックの SQL テキスト
候補ビューの定義を表します。
(２/２)
Advisor ログの開始と停止
Advisor のロギングを開始または停止するには、パラメータ ADMIN
ADVISOR_LOGGING または ALTER SYSTEM 文を使います。
ADMIN ADVISOR_LOGGING
rbw.config ファイルの パラメータ ADMIN ADVISOR_LOGGING が、Advisor ログの
起動状態を決定します。このパラメータを ON に設定すると、ログ デーモンの開始
時にログ ファイルが作成されます。OFF に設定すると、ログ ファイルは作成され
ず、データはログ記録されません。デフォルト設定は OFF です。
ログ ファイルを作成するために ADMIN ADVISOR_LOGGING が ON に設定されて
おり、かつ OPTION ADVISOR_LOGGING が ON に設定されている場合は、事前計
算ビューが使用される場合および候補ビューが生成される場合に、ログ レコードが
記録されます。
組織におけるデータベース運用の管理 8-31
ADMIN ADVISOR_LOG_ DIRECTORY
構文
パラメータ ADMIN ADVISOR_LOGGING_ の構文は次のとおりです。
ADMIN ADVISOR_LOGGING
OFF
ON
ON/OFF
システム起動時に Advisor ログ ファイルを作成するかどうかを指定し
ます。このパラメータを ON に設定すると、ログ デーモンの開始時に
ログ ファイルが作成されます。OFF に設定すると、ログ ファイルは作
成されず、データはログ記録されません。
ALTER SYSTEM
ALTER SYSTEM 操作は、データベースの動作および各種の管理操作を制御します。
Advisor のロギングの動作を制御する ALTER SYSTEM 文は、ADVISOR_LOGGING
文および ALTER SYSTEM SWITCH ADVISOR_LOG FILE 文の 2 つです。詳細につい
ては、『SQL Reference Guide』を参照してください。
ADMIN ADVISOR_LOG_ DIRECTORY
ADMIN ADVISOR_LOG_DIRECTORY rbw.config ファイル パラメータは、ログ ファ
イルを格納するディレクトリを指定します。
パラメータ ADMIN ADVISOR_ LOG_DIRECTORY を設定する構文は次のとおりで
す。
ADMIN ADVISOR_LOG_ DIRECTORY
<pathname>
<pathname> 変数は、ログ ファイルを作成するディレクトリを指定します。
<pathname> は、既存のディレクトリを指定する必要があります。指定は、絶対パス
でも相対パスでもかまいません。相対パスは、環境変数 RB_CONFIG が指定する
ディレクトリに対する相対パスです。構成パラメータを指定しないと、
$RB_CONFIG/logs (UNIX) または %RB_CONFIG%¥logs (Windows) がデフォルトの
ログ ディレクトリになります。
8-32 Administrator’s Guide
ADMIN ADVISOR_LOG_MAXSIZE
ADMIN ADVISOR_LOG_MAXSIZE
パラメータ ADMIN ADVISOR_LOG_MAXSIZE は、Advisor ログ ファイルの最大サ
イズを指定します。このパラメータを設定する構文は次のとおりです。
ADMIN ADVISOR_LOG_MAXSIZE
<integer>
<integer>K
integerK
<integer>M
<integer>,
<integer>K,
<integer>M
ログ ファイルがパラメータ ADVISOR_LOG_MAXSIZE の設定値を超
えると、ログ デーモンがファイルを閉じ、同じディレクトリに新規
ファイルを作成します。<integer> に指定する整数の単位は、次のよう
になります。
■
■
■
K も M も指定しない場合は、バイト
K を指定した場合は、KB (1,024 バイト )
M を指定した場合は、MB (1,048,576 バイト )
K や M の指定は数値の直後に入力し、空白がないようにしてくださ
い。パラメータ ADMIN ADVISOR_LOG_MAXSIZE の最小値は、
10KB(10,240 バイト ) です。
警告 : このパラメータを設定しない、あるいは 0 または負数に設定すると、
Advisor ログ ファイルの最大サイズに制限がなくなります。ログ ディレクトリに利
用できるディスク領域がなくなるまで、ログ ファイルが拡大し続けます。
組織におけるデータベース運用の管理 8-33
アカウンティング
アカウンティング
アカウンティングは、通常、個々のユーザが生成するデータベース ワークロードを
算出する手段を得るのに役立ちます。たとえば、データベースの使用量に応じた利
用者による経費負担を導入するような場合です。この章のアカウンティング機能を
使用すると、各ユーザが生成するデータベース ワークロードが記録されます。
アカウンティング機能は、基本的なデータベース ワークロードを構成するデータ
ベース サーバの動作を記録し、ディスクに格納します。アカウンティング レコー
ドは、データベース サーバ プロセス (rbwsvr) または TMU プロセス (rb_tmu) が、以
下のいずれかの操作を完了した時に生成されます。
■
■
■
1 回の DML 操作
1 つのクエリ
1 回のロード操作
アカウンティング機能には、ジョブ アカウンティングとワークロード アカウン
ティングという 2 種類のモードがあります。これらは、収集するデータの詳細レベ
ルが異なります。
ジョブ アカウンティングでは、ある操作が使用した資源のサマリを記録します。
CPU の稼働時間や経過時間などの統計値です。ジョブ アカウンティングの目的は、
原価計算や利用者による経費負担の根拠としてデータベース ユーザ生成の作業を算
出することです。
ワークロード アカウンティングでは、ジョブ アカウンティングの情報に加え、詳
細情報を記録したレコードが生成されます。ワークロード アカウンティングの主な
目的は、顧客サポートによるシステム分析です。
アカウンティング レコードを直接表示することはできません。アカウンティング
レコードを読み込み、データ ( ユーザの使用料など ) を算出するプログラムが必要
になります。UNIX の redbrick_dir/util/readacct ディレクトリには、アカウンティン
グ レコードを処理するサンプル プログラムがあります。詳細については、この
ディレクトリの README ファイルを参照してください。
8-34 Administrator’s Guide
アカウンティング プロセス
アカウンティング プロセス
アカウンティングは、ログ デーモン (rbwlogd) が実行します。アカウンティング レ
コードを生成するプロセスは、イベント ログ レコードを生成するプロセスと基本
的に同じです。rbwsvr、rb_tmu、rb_ptmu のいずれかのプロセスは、基本的な作業
を完了すると、ログ デーモンにアカウンティング要求メッセージを送ります。ログ
要求メッセージを出したプロセスは、ログ デーモンが受信したことを確認しませ
ん。性能への影響を最小限にするため、生成プロセスとログ デーモンの間のすべて
の通信が、生成プロセスからログ デーモンへの一方通行にされているからです。
図 8-7
UNIX におけるアカウンティング プロセス
アカウンティング
要求メッセージ
データベース サーバ プロセス
(rbwsvr、rb_tmu、rb_ptmu)
rbwlogd
アカウンティング
レコードがディス
クに書き込まれる
アカウンティング
ファイル
rbwsvr、rb_tmu、rb_ptmu のいずれかのプロセスからアカウンティング要求メッ
セージを受信すると、ログ デーモンはタイムスタンプを追加し、メッセージの内容
を自己記述型の可変長レコードとしてログ ファイルに書き込みます。
アカウンティング レコードのフォーマット
アカウンティング レコードは、自己記述型データ ストリーム (SDDS) フォーマット
で書き込まれます。このフォーマットでは、各レコードは可変長レコードであり、
次の要素で構成されます。
1.
2.
3.
レコードのバイト数を示す 2 進整数。
ジョブ アカウンティング レコードか、ワークロード アカウンティング レ
コードかを示すバイナリのフィールド。
タグ、タイプ、および長さヘッダを持つ一連の符号の値。
これらの値は、実際のアカウンティング データを表します。
組織におけるデータベース運用の管理 8-35
アカウンティング レコードのフォーマット
以下の表で、アカウンティング データ内の各属性 ( つまり、パラメータ LA) のデー
タ型を識別し、その使用方法を記載します。
パラメータ
データ型
説明
LA_USER_NAME
SDDT_CHAR
データベース ユーザ名
LA_SERVER_NAME
SDDT_INT4
ウェアハウス サーバ名 ( 環境変数
RB_HOST に設定された値 )
LA_DB_NAME
SDDT_CHAR
データベースの論理名
LA_ELAPSED_TIME
SDDT_INT4
経過時間 (1/100 秒単位 )
LA_USRTIME
SDDT_INT4
ユーザ CPU 時間 (1/100 秒単位）
LA_SYSTIME
SDDT_INT4
システム CPU 時間 (1/100 秒単位 )
LA_IOREAD
SDDT_INT4
論理 Read 回数
LA_IOWRITE
SDDT_INT4
論理 Write 回数
LA_COMMAND_VERB
SDDT_CHAR
コマンドの最初の 1 つまたは 2 つの
トークン ( キーワード )
LA_MEMORY_USED
SDDT_INT4
コマンドが使用しているメモリの量
(KB 単位 )
LA_SPILL_COUNT
SDDT_INT4
操作で使用されるスピル ファイル
( 一時的なファイル ) の数
LA_CHILD_COUNT
SDDT_INT4
呼び出される子プロセスの数
LA_SEL_ROWCNT
SDDT_INT4
SELECT 文の行数
LA_TMU_ROWCNT
SDDT_INT4
TMU LOAD 操作の行数
LA_SOURCEID
SDDT_CHAR
文を実行したソース コンポーネント
の ID
LA_PID
SDDT_CHAR
文を実行したコンポーネントのプロ
セス ID またはスレッド ID
LA_SQL_TEXT
SDDT_CHAR
SQL 文の最初の 256 文字
この表に記載されているパラメータは、アカウンティング ファイル (rbwacct) に固
有です。これらのパラメータは、ログ ファイル (rbwlog) には指定されません。
8-36 Administrator’s Guide
アカウンティング ファイル
アカウンティング レコード フォーマットの詳細は、redbrick_dir/util/readacct ディ
レクトリにある README ファイルと、アカウンティング レコードを処理するサン
プル プログラムを参照してください。
アカウンティング ファイル
ログ デーモンは、アカウンティング レコードを書き込み中のアカウンティング
ファイルに記録します。このファイルのサイズが、構成パラメータ ADMIN
ACCT_MAXSIZE の設定値を超えると、ファイルは閉じられ、新規のファイルが作
成されます。アカウンティング ファイルは、アカウンティング プロセスを終了し
た時も終了します。次にアカウンティングを起動した時は、新規のアカウンティン
グ ファイルが作成されます。このように複数のアカウンティング ファイルが累積
されていきます。ファイルにはヘッダ情報やトレーラ情報がないため、各ファイル
を作成順に結合して処理することができます。
書き込み中のアカウンティング ファイルと終了したアカウンティング ファイルは、
以下の命名規則に従います。
オペレーティング
システム
コマンド
UNIX
rbwacct.<daemon_name>.active
rbwacct.<daemon_name>.<datetime_stamp>
Windows
rbwacct.<service_name>.active
rbwacct.<service_name>.<datetime_stamp>
終了したファイル名の <datetime_stamp> サフィックスは、ログ デーモンがファイ
ルを閉じた日付と時間を示します。
これらのファイルのデフォルト ロケーションは、$RB_CONFIG/logs (UNIX) または
%RB_CONFIG%¥logs ディレクトリ (Windows) です。別のロケーションを指定する
には、構成パラメータ ADMIN ACCT_DIRECTORY を設定します。すべてのアカウ
ンティング ファイルの所有者は、redbrick アカウントです。
古くなったアカウンティング ファイルは、自動的に削除されません。データベース
管理者は、古いファイルを定期的に削除するスクリプトを作成するか、手動で削除
してください。
警告 : 古いアカウンティング ファイルを削除しないと、ファイルが増え続け、
ディスク領域が不足します。また、ADMIN ACCT_MAXSIZE の値を指定しておかな
いと、ディスク領域がなくなるまで、1 つのアカウンティング ファイルだけに書き
込みを続けます。
組織におけるデータベース運用の管理 8-37
アカウンティングの環境設定
アカウンティングの環境設定
アカウンティング機能の環境設定を行うには、rbw.config ファイルのパラメータを
設定します。
起動状態の設定
パラメータ ADMIN ACCOUNTING は、アカウンティング機能の起動時の動作を設
定します。このパラメータを設定する構文は次のとおりです。
ADMIN ACCOUNTING
ON
OFF
パラメータ ADMIN ACCOUNTING を ON に設定すると、ログ デーモンを起動する
と同時に、新規のアカウンティング ファイルが作成され、アカウンティング レ
コードの記録が開始されます。OFF にすると、ログ デーモンが起動しても、何の動
作も行われません。
ヒント：ログ デーモンの動作中に、アカウンティングを開始または停止
することができます。開始するには ALTER SYSTEM START ACCOUNTING
文を使用し、停止するには ALTER SYSTEM STOP ACCOUNTING 文を使用します。
アカウンティング ファイルのロケーション指定
パラメータ ADMIN ACCT_DIRECTORY は、ログ デーモンが作成するアカウンティ
ング ファイルの格納先ディレクトリを指定します。このパラメータを設定する構文
は次のとおりです。
ADMIN ACCT_DIRECTORY
<pathname>
<pathname> 値は、絶対パスでも相対パスでもかまいません。相対パスは、環境変数
RB_CONFIG が指定するディレクトリと相対的に解釈されます。パラメータ
ADMIN ACCT_DIRECTORY を設定しないと、$RB_CONFIG/logs (UNIX) または
%RB_CONFIG%¥logs (Windows) がデフォルトのログ ディレクトリになります。
8-38 Administrator’s Guide
アカウンティングの環境設定
アカウンティング ファイルの最大サイズ指定
パラメータ ADMIN ACCT_MAXSIZE は、アカウンティング ファイルの最大サイズ
を指定します。このパラメータを設定する構文は次のとおりです。
ADMIN ACCT_MAXSIZE
<integer>
<integer>K
<integer>M
アカウンティング ファイルが、このパラメータで指定されたサイズを超えると、ロ
グ デーモンにより、ファイルが閉じられ、同じディレクトリにアクティブ ファイ
ルが新たに作成されます。<integer> に指定する整数の単位は、次のようになりま
す。
■
■
■
K も M も指定しない場合は、バイト
K を指定した場合は、KB (1,024 バイト )
M を指定した場合は、MB (1,048,576 バイト )
K や M の指定は数値の直後に入力し、空白がないようにしてください。パラメータ
ADMIN ADVISOR_LOG_MAXSIZE の最小値は、10KB (10,240 バイト ) です。
警告 : このパラメータを設定しない、あるいは 0 または負数に設定すると、アカウ
ンティング ファイルの最大サイズに制限がなくなります。アカウンティング ディ
レクトリに利用できるディスク領域がなくなるまで、ファイルが拡大し続けます。
アカウンティング モードの設定
パラメータ ADMIN ACCT_LEVEL で設定するアカウンティング モードは、ジョブ
またはワークロードです。このパラメータを設定する構文は次のとおりです。
ADMIN ACCT_LEVEL
JOB
WORKLOAD
組織におけるデータベース運用の管理 8-39
アカウンティングの制御
データベース サーバがジョブ アカウンティングとワークロード アカウンティング
のいずれを実行しているかによって、アカウンティング ファイルに収集するデータ
の詳細レベルが異なります。ジョブ アカウンティングはデフォルトで、基本的な資
源の使用量を記録します。ワークロード アカウンティングでは、各イベントの詳細
情報も記録し、ワークロード アカウンティングでは、アカウンティング ファイル
が急速に大きくなることがあります。アカウンティングの詳細レベルは ALTER
SYSTEM CHANGE ACCOUNTING LEVEL 文を使用して、データベースの動作中で
も変更することができます。
アカウンティングの制御
ALTER SYSTEM コマンドを使うと、データベースの動作中にアカウンティング動
作を制御することができます。ALTER SYSTEM コマンドは、以下の操作を行いま
す。
■
■
■
■
アカウンティングの開始
アカウンティングの停止
アカウンティング ファイルの切り換え
アカウンティング モードの変更
ALTER SYSTEM 文の詳細については、『SQL Reference Guide』を参照してください。
アカウンティングの開始
アカウンティングを開始するには、ALTER SYSTEM START ACCOUNTING 文を使
用します。アカウンティングを開始すると、ログ デーモンが以下を実行します。
■
■
アカウンティング ファイルを作成します。
データベース プロセスからのアカウンティング要求メッセージを受信し、
対応するアカウンティング レコードをファイルに書き込みます。
アカウンティングがすでに実行中の場合は、このコマンドは無視されます。
アカウンティングの停止
ALTER SYSTEM STOP ACCOUNTING 文は、アカウンティングを停止し、アクティ
ブ アカウンティング ファイルを閉じます。ログ デーモンは動作し続けるため、い
つでもアカウンティングを再開できます。アカウンティングの停止中は、このコマ
ンドは無視されます。
8-40 Administrator’s Guide
アカウンティングの制御
アカウンティング ファイルの切り換え
ALTER SYSTEM SWITCH ACCOUNTING FILE 文は、アクティブ アカウンティング
ファイルを閉じ、新規アカウンティング ファイルの作成、アカウンティングの再
開、新規ファイルへのアカウンティング レコードの書き込みを行います。アカウン
ティングの停止中は、このコマンドは無視されます。
アカウンティング モードの変更
ジョブ アカウンティングとワークロード アカウンティングのモードを切り換える
には、ALTER SYSTEM CHANGE ACCOUNTING LEVEL 文を使用します。変更は、
即時に有効になります。
組織におけるデータベース運用の管理 8-41
第9章
データ ウェアハウスのメン
テナンス
テーブルとデータベースのロック . . . . . . . . . . . . .
テーブルとデータベースの手動ロック . . . . . . . . . .
READER PRIORITY オプション . . . . . . . . . . . . .
テーブル ロックの種類 . . . . . . . . . . . . . . . .
ロックとセグメント . . . . . . . . . . . . . . . . .
テーブルやデータベースの明示的なロック . . . . . . . . .
データベース サーバや TMU のロックの待機動作の指定 . . . .
No-Wait . . . . . . . . . . . . . . . . . . . .
デッドロック . . . . . . . . . . . . . . . . . .
バージョン管理されたトランザクションのアイソレーション レベル
9-6
9-6
9-7
9-7
9-9
9-9
9-10
9-11
9-11
9-12
テーブルとインデックスの情報の取得 . . . . . . . .
CHECK TABLE でのセグメント統計 . . . . . . .
テーブル構造の検査と修復 . . . . . . . . . .
CHECK INDEX サイズおよびコンフィグレーション情報
B-TREE インデックスのサイズおよび領域情報 . .
B-TREE インデックスの環境設定情報 . . . . .
STAR インデックスのサイズおよび領域情報 . . .
STAR インデックスの環境設定情報 . . . . . .
TARGET インデックスの CHECK INDEX 出力 . .
TARGET インデックスのサイズおよび領域情報 . .
TARGET インデックスの環境設定情報 . . . . .
インデックス破損のチェック . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
9-13
9-14
9-17
9-17
9-18
9-21
9-22
9-24
9-26
9-28
9-30
9-31
. .
. .
. .
. .
. .
. .
9-32
9-32
9-33
9-34
9-35
9-36
テーブルやインデックスのデータの増加の監視
.
STAR インデックス . . . . . . . . . .
MAXSIZE 列 . . . . . . . . . . . .
USED 列 . . . . . . . . . . . . . .
. . . . . . . . . . .
TOTALFREE 列
シュード列 . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
freespace フィールド . . . . . .
セグメントへの領域の割り当て方法
MAXSIZE の動的調整 . . . .
.
.
.
.
.
.
.
.
.
セグメントの変更 . . . . . . . . . . .
ALTER SEGMENT の使用 . . . . . . .
アクティブなユーザがいないことの確認 . .
セグメントのアタッチと切り離し . . . .
シングル セグメント テーブルまたは
インデックスへのセグメントのアタッチ
セグメント範囲の指定 . . . . . . . .
セグメントのオフライン / オンライン . . .
セグメントのクリア . . . . . . . . .
セグメント名の変更 . . . . . . . . .
セグメントからの格納領域の解放と削除 . .
PSU サイズの変更 . . . . . . . . . .
セグメント全体の移動 . . . . . . . .
PSU のロケーション変更 . . . . . . .
セグメントの検証 . . . . . . . . . .
セグメントの強制復旧 . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-37
9-39
9-40
. . .
. . .
. . .
. . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
9-42
9-42
9-43
9-44
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
9-45
9-48
9-49
9-49
9-49
9-50
9-54
9-55
9-55
9-55
9-56
.
定期的に更新されるデータベースのメンテナンス方法 .
データ セグメントおよびインデックス セグメントの
ロールオフと再使用 . . . . . . . . . . .
新規セグメントの追加 . . . . . . . . . . .
古いデータの削除 . . . . . . . . . . . . .
.
.
9-56
. . . .
. . . .
. . . .
.
.
.
9-57
9-63
9-67
破損したセグメントの復旧 .
.
.
.
9-69
光ディスクの管理 . . . . . . . . . . . . . . . . . .
光ディスクの割り当て . . . . . . . . . . . . . . .
光ディスク上のセグメントへのアクセス動作 . . . . . . .
光ディスク上のセグメントでのインデックス選択方法の指定 .
.
.
.
.
9-71
9-72
9-73
9-74
テーブルの変更 . . . . . . . . . . . . . . . . .
列の追加と削除 . . . . . . . . . . . . . . .
列名の変更 . . . . . . . . . . . . . . . . .
列のデフォルト値の変更 . . . . . . . . . . . .
MAXSEGMENTS 値と MAXROWS PER SEGMENT 値の変更
参照整合性を維持する削除動作の変更 . . . . . . .
.
.
.
.
.
.
9-75
9-76
9-76
9-76
9-77
9-77
9-2 Administrator’s Guide
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
列のデータ型の変更 . . . . . . .
フォーリン キーの追加と削除 . . . .
VARCHAR 列のフィル ファクタの変更 .
SERIAL 列の開始値とステップ値の変更
中断した ALTER TABLE 操作からの復旧
テーブルの復旧 . . . . . . . .
中断 : 原因と防止 . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
データベースのコピーと移動 . . . . . . . .
互換性 . . . . . . . . . . . . . .
絶対パスと相対パス . . . . . . . . .
相対パスだけを使用したデータベースのコピー
絶対パスを使用したデータベースのコピー .
相対パスだけを使用したデータベースの移動 .
絶対パスを使用したデータベースの移動 . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
rbw.config ファイルのエントリと SET コマンドのパラメータ
構成ファイルの修正 . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9-78
9-78
9-79
9-79
9-80
9-80
9-81
. .
. .
. .
. .
. .
. .
. .
9-82
9-82
9-82
9-84
9-84
9-85
9-85
.
.
. 9-86
. 9-87
データベース サーバの監視と制御 . . . . . .
UNIX でのデータベース サーバの監視と制御 .
デーモン プロセス . . . . . . . . .
Findserver ユーティリティ . . . . . .
ログ ファイル . . . . . . . . . .
Windows でのデータベース サーバの監視と制御
データベース サービス スレッド . . . .
ログ ファイル . . . . . . . . . .
. .
. .
. .
. .
. .
. .
. .
. .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . 9-96
. . 9-96
. . 9-96
. . 9-97
. . 9-98
. . 9-99
. . 9-99
. . 9-100
バージョン情報の確認 .
.
.
.
.
.
.
.
.
. 9-100
データベース オブジェクトとデータベースの削除
データベース オブジェクトの削除 . . . .
インデックス . . . . . . . . . .
階層構造 . . . . . . . . . . . .
マクロ . . . . . . . . . . . . .
ロール . . . . . . . . . . . . .
セグメント . . . . . . . . . . .
シノニム . . . . . . . . . . . .
テーブル . . . . . . . . . . . .
ビュー . . . . . . . . . . . . .
データベースの削除 . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 9-101
. 9-101
. 9-102
. 9-102
. 9-102
. 9-102
. 9-103
. 9-103
. 9-103
. 9-104
. 9-105
.
.
.
.
.
.
.
.
データ ウェアハウスのメンテナンス
9-3
9-4 Administrator’s Guide
この章について
この章では、ユーザの要求やデータベースの変更に応じた、データ ウェアハウスの
メンテナンスについて説明します。新しいデータをロードする以外に変更がない
データベースでは、必要な保守作業は最小限ですみます。次にロードする入力デー
タを格納する十分な領域が、デフォルト セグメントと名前付きセグメントにあるこ
とを確認するだけです。データベースの復旧が必要な場合は、元の入力データ ファ
イルを使用して復元できます。
インクリメンタル ロード操作、あるいは INSERT、UPDATE、DELETE 文によって
データベースが更新される場合は、ユーザの要求やウェアハウス環境の変更に対応
するメンテナンスに加え、データベースの拡大に対応するメンテナンスも必要にな
ります。更新されるデータベースは、データの定期的なバックアップも必要になり
ます。バックアップ操作については、『Table Management Utility Reference Guide』を
参照してください。
この章では、以下について説明します。
■
■
■
■
■
■
■
■
■
■
■
■
■
■
テーブルとデータベースのロック
テーブルとインデックスの情報の取得
テーブルやインデックスのデータの増加の監視
セグメントへの領域の割り当て方法
セグメントの変更
定期的に更新されるデータベースのメンテナンス方法
破損したセグメントの復旧
光ディスクの管理
テーブルの変更
データベースのコピーと移動
構成ファイルの修正
データベース サーバの監視と制御
バージョン情報の確認
データベース オブジェクトとデータベースの削除
データ ウェアハウスのメンテナンス
9-5
テーブルとデータベースのロック
テーブルとデータベースのロック
データベースの整合性を維持するため、データの修正操作は中断なしに完了させな
ければなりません。修正 ( 書き込み ) が完了するまでは、ほかの読み込み操作や書
き込み操作を禁止する必要があります。データベースの整合性維持に必要になる
と、ロックが自動的にかけられます。TMU の操作では、TMU がテーブルとデータ
ベースを自動的にロックします。修正するテーブルには Write ロックがかけられ、
参照整合性の確認に使用されるテーブルには、Read ロックがかけられます。バー
ジョン ログのクリーニングなど、そのほかの操作では手動ロックが必要です。
テーブルとデータベースの手動ロック
手動ロックを使用すると、テーブルまたはデータベースに対する一連の操作が可能
になります。
LOCK を使ってユーザが手動でロックできるのは、1 度に 1 つのオブジェクト ( テー
ブルまたはデータベース ) だけです。別のオブジェクトをロックするには、現在
ロックしているオブジェクトのロックを解除しなければなりません。ただし、シス
テムがかける暗黙的なロックには制限がなく、クエリやコマンドの処理に必要な数
のロックがかけられます。
LOCK DATABASE 文は、2 種類のデータベース ロック オプションをサポートしてい
ます。
■
■
WRITE : データベースをロックし、ほかからのデータベースへのアクセス
をすべて禁止します。WRITE は、LOCK DATABASE 文のデフォルト オプ
ションです。
READ : データベースをロックし、更新を禁止しますが、Read ロックを使
用する並行クエリは許可します。Read ロックはバキューム クリーニング
に影響を与えません。バージョン管理されたデータベースをバックアップ
するときは、Read ロックが適しています。データベースのバックアップ方
法の詳細については、6-24 ページ「バックアップと復旧」を参照してくだ
さい。
LOCK 文に関する詳細については、
『SQL Reference Guide』を参照してください。
9-6 Administrator’s Guide
READER PRIORITY オプション
READER PRIORITY オプション
ロックが付与される順序は rbw.config ファイルの READER_PRIORITY オプションに
よって制御されます。デフォルトでは、このオプションが ON に設定されるため、
Write ロックよりも Read ロックが優先されます。たとえば、あるユーザがテーブル
に Read ロックをかけているときに、別のユーザが同じテーブルに Read ロックを要
求した場合、その要求はただちに許可されます。3 人目のユーザがそのテーブルに
Write ロックを要求しても、その影響を受けません。
これは、ほとんどの意思決定支援アプリケーションに適した動作ですが、大量のク
エリのロードにより、DDL の並行操作に著しい遅延が生じる可能性があります。
データベースの Read ロックに対する新規の要求は、それぞれデータベースの Write
ロックに対する要求より優先されるからです。クエリが実行されるとき、クエリは
システム テーブルに対してデータベース レベルのロックを取得する必要がありま
す。このロックは、個々のテーブルがロックされるまで解除されません。
データベースがオンラインのときに、DDL 操作やロードなどの動作を必要とするア
プリケーションに対し、READER_PRIORITY を OFF に設定すると、クエリ優先
ロックが無効になります。ロックする順序に従って、操作がロックされます。クエ
リの Read ロックが優先されることはありません。データベースがオンラインのと
きに実行する必要がある DDL 操作で遅延の問題が日常的に発生する場合を除き、
IBM では OPTION READER_PRIORITY を ON のままにして、データベースへの書き
込み操作よりも高い優先順位をクエリに与えることをお勧めします。
テーブル ロックの種類
テーブルにどの種類のロックがかかっているかを確認するには、DST_LOCKS テー
ブルの TYPE 列を検索します。
バージョン管理されていないデータベースに対して、IBM Red Brick Warehouse は読
み込み専用 (RO) ロックと書き込みブロック (WB) ロックを提供します。
バージョン管理されたデータベースに対しては、Red Brick で追加のロックが提供さ
れます。Read ロックは、テーブルをロックして読み込みアクセス専用にします。こ
のテーブルは複数のユーザが同時に読み込めますが、書き込みはできません。この
操作によって、ユーザのトランザクションは整合性のあるビューにアクセスできま
す。Write ロックでは、テーブルがロックされている間、ほかのユーザによる各レ
ベルでの読み込みアクセスが可能です。
異なる種類の Read ロックや Write ロックがあるのは、同時トランザクションを禁止
( ブロッキング ) するものから、1 つのテーブルの各バージョンで読み込みトランザ
クションが実行されている間に、同じテーブルまたはプライマリ キーとフォーリン
キーの関係にあるテーブルへの書き込みトランザクションを認めるものまで、異な
る同時実行レベルをデータベースに設定できるようにするためです。
データ ウェアハウスのメンテナンス
9-7
テーブル ロックの種類
同時実行性能を高めるため、スキーマ ロックはデータベース レベルのロックでは
なく、テーブル レベルのロックを行えます。
次の表は、ロックの種類の定義と説明をまとめたものです。
ロックの
種類
定義
適用対象のトランザクション
RO
Read-Only
テーブルでのブロッキング トランザクション以外の
読み込みと書き込みトランザクションを認める、読
み込みトランザクション
RK
Read-Key
ほかのトランザクションによるテーブルのプライマ
リ キー値の変更を禁じる、読み込みトランザクショ
ン
RD
Read-Data
テーブルへの書き込みトランザクションをすべて禁
じる、読み込みトランザクション
WD
Write-Data
データベースの既存のプライマリ キー値を変更しな
い、書き込みトランザクション ( たとえば、キー列以
外の列の INSERT または UPDATE)
バージョン管理されたデータベースのみ
WK
Write-Key
データベースの既存のプライマリ キー値を変更する、
書き込みトランザクション ( たとえば、キー列の
DELETE または UPDATE)
バージョン管理されたデータベースのみ
WB
Write-Blocking
テーブルへのほかの読み込みトランザクションや書
き込みトランザクションをすべて禁じる、書き込み
トランザクション
RS
Read-Schema
READER_PRIORITY を OFF に設定した場合にのみ使
用します。9-7 ページ「READER PRIORITY オプショ
ン」を参照してください。
WS
Write-Schema
READER_PRIORITY を OFF に設定した場合にのみ使
用します。9-7 ページ「READER PRIORITY オプショ
ン」を参照してください。
次の表は、各種のロック間の相互関係を示しています。
Read-Schema と Write-Schema は、ほかのロックとの相互関係がないのでこの表には
記載されていません。
9-8 Administrator’s Guide
ロックとセグメント
影付きの部分は、ロックの組み合わせでのブロッキング トランザクション ( バー
ジョニングのないトランザクション ) を示しています。影のない部分は同時実行ト
ランザクション ( バージョン管理されたトランザクション ) です。
RO
RK
RD
WD
WK
WB
RO
C
C
C
C
C
B
RK
C
C
C
C
B
B
RD
C
C
C
B
B
B
WD
C
C
B
B
B
B
WK
C
B
B
B
B
B
WB
B
B
B
B
B
B
ロックとセグメント
セグメント単位で明示的にロックをかけることはできません。テーブルがロックさ
れると、その中のすべてのオンライン セグメントへのアクセスもロックされます。
オフライン セグメントには、そのセグメントに対する操作の実行と同時に、必要な
ロックが自動的にかけられます。たとえば、オフライン セグメントにロード操作を
行うと、そのセグメントに Write ロックが自動的にかけられ、ほかのロード操作や
リストア操作が禁止されます。オフライン セグメントのテーブルには Read ロック
が自動的にかけられ、操作中にそのセグメントがドロップされたり変更されるのを
禁止します。
テーブルやデータベースの明示的なロック
必要に応じて、データベースに Read ロックをかけたり、テーブルまたはデータ
ベースに Write ロックをかけることができます。
データベースをバックアップするときは、そのデータベースを Read ロックする必
要があります。Read ロックした場合、クエリは実行できますが、更新は禁止されま
す。
データ ウェアハウスのメンテナンス
9-9
データベース サーバや TMU のロックの待機動作の指定
以下の場合は、テーブルをあらかじめ Write ロックしておくと便利です。
■
■
1 つのテーブルを連続して修正する場合
すべての修正が完了するまでほかのユーザがアクセスできないように、そ
のテーブルをロックします。
削除操作を開始する前に、LOCKFOR DELETE によって関連テーブルを
ロックし、参照整合性に必要なアクセスを確保します。
必要なロックはすべて自動的にかかりますが、テーブルを手動でロックし
て、複数の DELETE 操作中にほかのユーザがアクセスできないようにして
おくと、DELETE 操作が早く完了します。ON DELETE 句の機能とロック
されるテーブルに関する詳細については、5-23 ページ「ON DELETE によ
る参照整合性の維持」を参照してください。
リストア操作のように、データベース全体に関わる操作を実行する場合は、データ
ベースを Write ロックします。データベース ロックは LOCK DATABASE 文によって
かけられ、UNLOCK DATABASE 文が実行されるまでは、データベース全体 ( シス
テム テーブルを含むすべてのテーブル ) について、ほかのユーザによる読み込みと
修正が禁止されます。データベースをロックすると、システム テーブルもロックさ
れるため、データベースのロックが解除されるまではシステム テーブルにアクセス
する操作もできません。
このほか、以下の場合もデータベースを Write ロックしておくと便利です。
■
■
複数の ALTER TABLE 文を連続的に実行し、ほかのユーザが操作を割り込
ませないようにしたい場合
ALTER SEGMENT 操作など、システム テーブルに影響する操作を実行す
る場合
データベース サーバや TMU のロックの待機動作の
指定
データベース サーバ、または TMU の処理は、Read ロックされているテーブルや
データベースを検出した場合のデフォルトの動作として、ロックを取得できるまで
待機します。処理が待機する方法は、READER_PRIORITY オプションの設定によっ
て異なります。NO WAIT オプションの設定も、動作に影響を与えます。待機によっ
てデッドロックが発生した場合は、パラメータ ALLOW_POSSIBLE_DEADLOCK を
設定しない限り、操作は失敗します。
9-10 Administrator’s Guide
データベース サーバや TMU のロックの待機動作の指定
No-Wait
ロックの動作を変更して、処理を待機させる代わりに、テーブルやデータベースが
ロックされているために、データベース サーバ、または TMU の操作に失敗したこ
とを知らせるメッセージが表示されるようにできます。
重要 : IBM では、バージョン管理されたデータベースに対して、NO WAIT オプ
ションの使用を推奨していません。
TMU のロック時の動作を変更するには、TMU のコントロール ファイルに TMU の
SET LOCK NO WAIT コマンドを入力します。詳細については、『Table Management
Utility Reference Guide』を参照してください。
ALTER SEGMENT、INSERT、UPDATE、DELETE などのデータベース サーバ処理
を実行するために、動作を NO WAIT に変更するには、以下の方法があります。
■
■
■
SET LOCK 文を使用し、接続中のセッションについて対話形式で変更
ユーザの .rbwrc ファイルに SET コマンドを記述し、そのユーザのすべて
のデータベース サーバ セッションについて一括変更
データベース サーバの .rbwrc ファイルですべてのデータベース サーバ
セッションについて一括変更
デッドロック
既存ロックの解除を待機すると、デッドロックが発生する可能性がある場合は、
データベース サーバはロック要求を拒否し、ロック要求者にすぐに制御を返しま
す。デッドロックの危険があっても、WAIT オプションに従って待機させたい場合
は、以下の行を rbw.config ファイルに挿入してください。
OPTION ALLOW_POSSIBLE_DEADLOCK ON
このオプションを ON に設定してデッドロックが発生した場合は、システム コマン
ドにより、デッドロックが発生したすべてのプロセスを強制終了してください。こ
のパラメータのデフォルト値は OFF です。
デッドロックが発生するのは、LOCK TABLE 文、または LOCK DATABASE 文を使
用した場合だけです。データベース サーバや TMU による自動ロック操作からは発
生しません。データベース サーバは、デッドロックが発生する前にエラー メッ
セージを返します。
データ ウェアハウスのメンテナンス
9-11
バージョン管理されたトランザクションのアイソレーション レベル
バージョン管理されたトランザクションのアイソレー
ション レベル
バージョン管理された SQL トランザクションでは、SERIALIZABLE モードと
REPEATABLE READ モードという 2 つのユーザ制御のアイソレーション レベルを利
用できます。アイソレーション レベルとは、トランザクションの実行時間中に利用
可能な同時実行のレベルのことです。利用されるレベルに応じて、異なる Read
ロックがテーブルにかけられ、異なるレベルのテーブルへのアクセス権が実現され
ます。ロックの種類に関する詳細については、9-7 ページ「テーブル ロックの種類」
を参照してください。
SERIALIZABLE は、最も制約的なモードです。そのほかのバージョン管理されたト
ランザクションは、別のテーブルを変更する別のトランザクションによって、ロッ
クされたテーブルを読み込むことはできません。このため、新しいバージョン管理
されたトランザクションは、テーブルの最新バージョンが別のテーブルの更新に利
用される前に、それを読み取るようになります。
REPEATABLE READ は、より制約の小さいモードです。バージョン管理されたトラ
ンザクションは、別のテーブルを変更する別のトランザクションにより、ロックさ
れたテーブルの古いバージョンを読み込むことができます。このため、新しいバー
ジョン管理トランザクションは、テーブルの古いバージョンを利用して処理を続行
することが可能となります。したがって、新しいトランザクションを早く実行でき
ますが、テーブルの最新バージョンが別のテーブルの更新に利用されることは保証
されません。
アイソレーション レベルは SET TRANSACTION ISOLATION LEVEL 文、および
rbw.config ファイルのパラメータ OPTION TRANSACTION_ISOLATION_LEVEL を使
用して制御できます。デフォルトのレベルは SERIALIZABLE です。この文の詳細
については、『SQL Reference Guide』を参照してください。
例
2 つのアイソレーション レベルの違いを示すために、1 億行を持った顧客 (Customer)
テーブルを使用するアプリケーションがあるとします。そのテーブル上にあるバー
ジョン管理されたトランザクション (TMU の LOAD 操作 ) が、名字が「A」で始ま
る新規顧客の追加をたった今開始したとします。このトランザクションは完了まで
に約 15 分かかることがわかっています。
9-12 Administrator’s Guide
テーブルとインデックスの情報の取得
ここで上司から緊急の電話が入り、名字が「S」で始まる全顧客を得意先 (Preferred
Customer) テーブルに追加するように指示されたとします。この得意先テーブルは、
同じデータベース上に存在しますが、顧客テーブルに対するプライマリ キー /
フォーリン キー関係がまったくありません。上司はこの作業を 10 分以内に完了す
るように求めています。このような操作を実行する SQL の INSERT 文は次のとおり
です。
insert into preferred_customer
select last_name, first_name, id, address from customer
where last_name like 'S%'
group by last_name, first_name, id, address
order by last_name, first_name;
上記のトランザクションを SERIALIZABLE モードで実行するには、先に LOAD 操
作を完了する必要があります。トランザクションが待機しなければならないのは、
このトランザクションが、現在更新中のテーブルのデータを別のテーブルの更新に
使用しているからです。ただし、このトランザクションでは、現在更新中のデータ
が全く使用されないことは明らかです。トランザクションの対象は名字が「S」か
ら始まる顧客であり、更新中のデータは名字が「A」から始まる顧客だけだからで
す。
したがって、INSERT 文を実行する前に、次のステートメントを実行し、トランザ
クションを REPEATABLE READ モードで実行します。
set transaction isolation level repeatable read;
次にクエリを実行すれば、クエリは待機することなく実行されます。
上記の例で、LOAD 操作が、名字が「A」で始まる姓を持つ顧客ではなく「S」で始
まる新規顧客を追加中で、REPEATABLE READ モードで INSERT 操作が実行された
場合は、予期した結果が得られないことがあります。この INSERT 操作が実行した
最新の変更は反映されません。
テーブルとインデックスの情報の取得
CHECK TABLE 文を使用すると、次の処理ができます。
■
■
■
行カウントなど、テーブルのセグメント統計の取得
テーブル格納域のデータ構造に破損がないかどうかの検査
テーブル格納域のデータ構造の破損箇所の修復
環境設定およびサイズの情報を取得し、インデックスに破損がないかどうか検査す
るには、CHECK INDEX 文を使用します。
データ ウェアハウスのメンテナンス 9-13
CHECK TABLE でのセグメント統計
CHECK TABLE でのセグメント統計
VERBOSE オプションを指定した場合、次のセグメント統計が CHECK TABLE 文に
よって出力ファイルに生成されます。CHECK TABLE で取得できるセグメント統計
の説明は、5-31 ページ「CHECK TABLE 文の VERBOSE オプション」を参照してく
ださい。
CHECK TABLE
セグメント統計
フィールド
説明
active rows
セグメント内にある行の数。
deleted rows
セグメントから削除された行の数。
total blocks
セグメント内の 8KB ブロックの数。
free blocks
データ行が現在格納されていないブロックの数。
storage reclen
VARCHAR 列のフィル ファクタに基づいて決定されるレ
コード長 ( 単位 : バイト )。この値を算出するには、
5-26 ページ「例 1: 1 ブロックあたりの行数に対する
VARCHAR フィル ファクタの影響」で一般的な行サイズ
の式を参照してください。
average reclen
セグメント内のレコード ( 行 ) の実際の平均サイズ ( 単位 :
バイト )。行に VARCHAR 列が 1 つでも格納されていると、
平均行サイズは、storage reclen の値とは異なります。
indirect rows
最初にロード、または挿入されたページとは違うページに
ある行の数。このような間接行が発生するのは、
VARCHAR 列の更新により生成された長い行を格納するた
めのページで領域が不足している場合です。
max reclen
すべての VARCHAR 列に最大長の文字列が格納されてい
る場合の行長 ( 単位 : バイト )。
longest rec
セグメント内の実際の最大行長 ( 単位 : バイト )。
min reclen
すべての VARCHAR 列が、NULL または空の場合の行長
( 単位 : バイト )。
shortest rec
セグメント内の実際の最小行長 ( 単位 : バイト )。
freespace
セグメント内の割り当て済みブロックでの未使用領域のバ
イト数。9-38 ページ「例 : CHECK TABLE の出力における
freespace セグメント統計」を参照してください。
(１/２)
9-14 Administrator’s Guide
CHECK TABLE でのセグメント統計
CHECK TABLE
セグメント統計
フィールド
説明
rows/block
VARCHAR 列のフィル ファクタに基づいて、データベー
ス サーバがブロックあたりに割り当てる行番号の数。こ
の値を算出するための式については、5-24 ページ「データ
ベース サーバにおける VARCHAR フィル ファクタの 機
能」を参照してください。
unused rowids
現在使用されていない行番号の数。
unusable freespace
割り当てられた行番号がすべて使用されており、標準行サ
イズ以上の空き容量があるブロックの、空き容量 ( 単位 :
バイト )。に示されているように、フィル ファクタの値が
実際の行サイズよりも高く設定されている場合、0 以外の
値がこのフィールドに表示されます。
(２/２)
例 : VERBOSE オプションを指定した CHECK TABLE でのセグメント統計
この例では、Aroma データベースの Sales テーブルについて、VERBOSE オプショ
ンを指定した CHECK TABLE 文を示します。
RISQL> check table sales
> directory ’/qa/local/sct-pubs/varchar-aroma/’
> verbose;
INFORMATION
Table:11 Segment:21 is ok
Table:11 Segment:22 is ok
No inconsistencies were detected.
Sales テーブルは 2 つのセグメントで構成されているので、CHECK TABLE 文は 2 つ
の出力ファイルを生成します。前述の CHECK TABLE 文の出力ファイル名は、テー
ブル番号およびセグメント番号ではじまります。次に例を示します。
chk_11_21_rep.19990908.184731.25596
chk_11_22_rep.19990908.184731.25599
図 9-1 は、Sales テーブルに対して、VERBOSE オプションを指定した CHECK
TABLE 文により、生成される出力ファイルの内容を示しています。
データ ウェアハウスのメンテナンス 9-15
CHECK TABLE でのセグメント統計
図 9-1
VERBOSE オプションを指定した CHECK TABLE からの 2 つの出力ファイルの内容
RISQL> !more chk_11_21_rep.19990923.135804.19354
------- Checking Table ------Table name:SALES
Table revision no:NULL
Segment name:DAILY_DATA1
-----------------------------Validating physical storage structure for segment...
Finished checking segment physical structure.
Validating row structure for segment...
Expecting:34577 active rows in segment
Scanning all active blocks.Total data blocks:131...
Segment statistics:
active rows:34577, deleted rows:0, total blocks:132, free blocks:0
rows/block:264, storage reclen:29, average reclen:29, indirect rows:0
max reclen:29, longest rec:29, min reclen:29, shortest rec:29
freespace:741, unused RowIDs:7, unusable freespace:0
Finished checking segment row structure.
RISQL> !more chk_11_22_rep.19990923.135804.19356
------- Checking Table ------Table name:SALES
Table revision no:NULL
Segment name:DAILY_DATA2
-----------------------------Validating physical storage structure for segment...
Finished checking segment physical structure.
Validating row structure for segment...
Expecting:35364 active rows in segment
Scanning all active blocks.Total data blocks:134...
Segment statistics:
active rows:35364, deleted rows:0, total blocks:135, free blocks:0
rows/block:264, storage reclen:29, average reclen:29, indirect rows:0
max reclen:29, longest rec:29, min reclen:29, shortest rec:29
freespace:908, unused RowIDs:12, unusable freespace:0
Finished checking segment row structure.
9-16 Administrator’s Guide
テーブル構造の検査と修復
この例では、テーブルに VARCHAR 列がないため、CHECK TABLE の出力では
storage reclen、average reclen、max reclen、longest rec、min reclen、および shortest
rec のセグメント統計が同じ値になっています。
rows/block フィールドの値は、データベース サーバが、次の式を使用して算出する
ブロックあたりの行数と同じです。
rows per block
= floor((block size - overhead) / (row size + overhead))
= floor((8192 - 4) / (29 + 2))
= 264
= CHECK TABLE rows/block:264
freespace フィールドの値は、既存の割り当て済みブロックの未使用バイト数です。
詳細については、9-37 ページ「freespace フィールド」を参照してください。
CHECK TABLE のセグメント統計を使用して、VARCHAR 列のフィル ファクタの効
果を確かめる方法については、5-31 ページ「CHECK TABLE 文の VERBOSE オプ
ション」を参照してください。
テーブル構造の検査と修復
FIX オプションを指定した場合、破損したセグメントが CHECK TABLE 文によって
検出されると、そのセグメントは「破損」とマークされます。破損箇所の修復後、
ALTER SEGMENT...VERIFY 文を使用して、セグメントが修復されていることを確
認し、セグメントを「正常」とマークします。この手順を完了してから、もう一度
テーブルに対して CHECK TABLE 文を使用します。
警告 : FIX オプションを指定して CHECK TABLE 文を使用する前に、データベース
の最新のバックアップが作成されていることを確認し、弊社テクニカル サポートに
ご連絡いただくことをお勧めします。
CHECK INDEX サイズおよびコンフィグレーション情
報
CHECK INDEX の出力はインデックスの種類によって多少異なります。
■
B-TREE インデックス
詳細については、9-18 ページ「B-TREE インデックスのサイズおよび領域
情報」および 9-21 ページ「B-TREE インデックスの環境設定情報」を参照
してください。
データ ウェアハウスのメンテナンス 9-17
CHECK INDEX サイズおよびコンフィグレーション情報
■
STAR インデックス
CHECK INDEX サマリ出力ファイルには、STAR インデックスで参照され
る各テーブルの構成情報が記録されます。詳細については、9-24 ページ
「STAR インデックスの環境設定情報」を参照してください。9-22 ページ
「STAR インデックスのサイズおよび領域情報」では、B-TREE インデック
スに類似した領域情報を説明しています。
■ TARGET インデックス
9-26 ページ「TARGET インデックスの CHECK INDEX 出力」で説明されて
いるとおり、1 つの TARGET インデックスは内部的には 3 つの B-TREE イ
ンデックスから構成されています。9-28 ページ「TARGET インデックスの
サイズおよび領域情報」では、CHECK INDEX が表示する TARGET イン
デックスの統計情報について説明しています。
B-TREE インデックスのサイズおよび領域情報
この例では、Aroma データベースの Sales テーブルにある BTREE_SALES_IDX イ
ンデックスについて、VERBOSE オプションを指定した CHECK TABLE 文を示しま
す。
RISQL> check index BTREE_SALES_IDX
directory '/qa/local/virginia' verbose;>
INFORMATION
Index:22 Segment:58 is ok
Report File:/qa/local/virginia/chk_0_58_rep.20020604.074848.22361
Index:22 Segment:59 is ok
Report File:/qa/local/virginia/chk_0_59_rep.20020604.074848.22362
Index validation succeeded
Summary File:
/qa/local/virginia/chk_0_Summary_rep.20020604.074848.17412
CHECK INDEX 文により、各セグメントに対する出力ファイルとサマリファイルが
作成されます。次の例にあるように、各セグメントの出力ファイル名は、0 とセグ
メント番号ではじまります。
chk_0_58_rep.20020604.074848.22361
chk_0_59_rep.20020604.074848.22362
9-18 Administrator’s Guide
CHECK INDEX サイズおよびコンフィグレーション情報
図 9-2 は、B-TREE インデックスの先頭セグメントに関する CHECK INDEX 出力
ファイルの内容です。
図 9-2
B-TREE インデックスの先頭セグメントに関する CHECK INDEX 出力
114 nala % more
chk_0_58_rep.20020604.074848.22361
Checking Index Segment
Index name:BTREE_SALES_IDX
Index revision number:NULL
-----------------------------Validating index...
BTree index of type:IX_COMPOSITE
Keysize:
8
Unique:
0
Nulls:
0
Number of variable length cols:
Index is stored in 2 segments.
Entries per page:
583
Fill factor:
1.000000
Offset to children:
4664
Nulls are not allowed in this index.
DESCRIBE オプション
で表示される情報は
これだけです。
0
Composite types (2):
0) Type:IX_INT4
1) Type:IX_INT4
Validating 0th segment
-----------------------------------------------Validating segment LOCAL_BTREE1...
Root block:
3
Index depth:
1
Average entries in leaf nodes : 576.283333
Average entries in inner nodes : 60.000000
Total leaf entries
Total Inner entries
: 34577
: 60
この情報は、
VERBOSE オプションに
より表示されます。
Total non-null rows indexed
Total leaf nodes: 60
Total inner nodes: 1
: 34577
この情報は、
VERBOSE オプションに
より表示されます。
Segment is ok
データ ウェアハウスのメンテナンス 9-19
CHECK INDEX サイズおよびコンフィグレーション情報
VERBOSE オプションを指定した場合、CHECK INDEX 文によって、9-19 ページ図
9-2 に記載されている出力の最下部近くにあるインデックス サイズと領域情報が出
力ファイルに生成されます。CHECK INDEX で DESCRIBE オプションを指定する
と、これら 4 行の情報は表示されなくなります。
CHECK INDEX のサイズおよび領域情報は、次のように、RBW_SEGMENTS シス
テム テーブルと RBW_STORAGE システム テーブルの情報に関連しています。
■
■
Total leaf entries 値 34577 はこのインデックス セグメントに対応するデー
タ セグメントの行番号 (RBW_SEGMENTS の ROWCOUNT 値 ) に等しく
なります。
Total leaf nodes と Total inner nodes の値は、8KB ブロックの合計値です。
次の計算式は、LOCAL_BTREE1 セグメントが占有する領域の大きさを
表します。
Space used = (Total leaf nodes + Total inner nodes) * 8 kilobytes
= (60 + 1)* 8 kilobytes
= 488 kilobytes
RBW_STORAGE システム テーブルの USED 列は、これまでの PSU の割り
当て量を示します。この USED 値は、インデックス作成により、分割とメ
タデータのために余分なブロックが追加されるので、通常、CHECK
INDEX の出力から計算された容量よりも大きくなります。この例では、
USED の値 496 は計算された値 488 よりも大きくなっています。これは、
USED の値には、メタデータ用に 8KB のブロックが 1 つ含まれているから
です。
RISQL> select substr(seg.name, 1,17) as segname, pseq, used,
>
>
>
>
totalfree, rowcount
from rbw_segments seg, rbw_storage sto
where tname = 'SALES' and seg.name = sto.segname
order by seg.name;
SEGNAME
PSEQ
DAILY_DATA1
2
DAILY_DATA1
1
DAILY_DATA2
2
DAILY_DATA2
1
DEFAULT_SEGMENT_2
1
LOCAL_BTREE1
1
LOCAL_BTREE2
1
SALES_STAR_SEG1
1
SALES_STAR_SEG2
1
SALES_TARGET_IX1
1
SALES_TARGET_IX2
1
9-20 Administrator’s Guide
USED
32
1024
56
1024
1800
496
504
424
432
56
56
TOTALFREE
992
992
968
968
2095344
528
520
600
592
968
968
ROWCOUNT
34577
34577
35364
35364
NULL
NULL
NULL
NULL
NULL
NULL
NULL
CHECK INDEX サイズおよびコンフィグレーション情報
B-TREE インデックスの環境設定情報
CHECK INDEX 文は、インデックスの環境設定情報をレポートします。DESCRIBE
オプションを使用すると、インデックスを検証しなくても、この環境設定情報を表
示することができます。9-19 ページ図 9-2 にある CHECK INDEX 出力には次の環境
設定情報が表示されています。
■
■
■
■
■
■
B-TREE インデックスのキーサイズは 8 バイトである
このインデックスは 2 つのセグメントに格納されている
1 ページ (8KB ブロック ) に 583 エントリ入るが、インデックスがいっぱい
になっていないので、各リーフ ノードには平均 576.28 エントリしか入って
いない
フィル ファクタは 100% である
NULL 値は、この BTREE_SALES_IDX インデックスでは使用できない
このインデックスは複合 ( 複数列 ) インデックスで、各列のデータ型は
INTEGER である
図 9-3 にある CHECK INDEX サマリ ファイルには、次の環境設定情報が表示されて
います。
■
■
B-TREE インデックスで定義されている列名
テーブルにある行の総数
図 9-3
B-TREE インデックスの CHECK INDEX サマリ出力ファイル
116 nala % more chk_0_Summary_rep.20020604.074848.17412
Checking overall index
Index name:BTREE_SALES_IDX
Index revision number:NULL
-------------------------------------------NO.
--0
1
COLUMN NAME
--------------------------------CLASSKEY
PRODKEY
DESCRIBE
オプションで表示
される情報は
これだけです。
Total data row(s) in this table
: 69941
Total data row(s) indexed on this table: 69941
データ ウェアハウスのメンテナンス 9-21
CHECK INDEX サイズおよびコンフィグレーション情報
STAR インデックスのサイズおよび領域情報
この例では、Aroma データベースの Sales テーブルにある SALES_STAR_IDX イン
デックスについて、VERBOSE オプションを指定した CHECK INDEX 文を示します。
RISQL> check index SALES_STAR_IDX
directory '/qa/local/virginia' verbose;>
INFORMATION
Index:20 Segment:31 is ok
Report File:/qa/local/virginia/chk_0_31_rep.20020530.131423.28183
Index:20 Segment:37 is ok
Report File:/qa/local/virginia/chk_0_37_rep.20020530.131423.28184
Index validation succeeded
Summary File:
/qa/local/virginia/chk_0_Summary_rep.20020530.131423.20002
SALES_STAR_IDX インデックスは 2 つのセグメントで構成されているので、
CHECK INDEX 文は出力ファイルを 2 つとサマリ ファイルを 1 つ生成します。
CHECK TABLE 文の出力ファイル名は、0 およびセグメント番号ではじまります。
次に例を示します。
chk_0_31_rep.20020530.131423.28183
chk_0_37_rep.20020530.131423.28184
9-22 Administrator’s Guide
CHECK INDEX サイズおよびコンフィグレーション情報
図 9-4 は、STAR インデックスの先頭セグメントに関する CHECK INDEX 出力ファ
イルの内容です。
図 9-4
STAR インデックスの先頭セグメントに関する CHECK INDEX 出力
120 nala % more chk_0_31_rep.20020530.131423.28183
Checking Index Segment
Index name:SALES_STAR_IDX
Index revision number:NULL
-----------------------------Validating index...
STAR index of type:IX_BYTE_STRING
Keysize:
6
Unique:
1
Nulls:
0
Number of variable length cols:
Index is stored in 2 segments.
Entries per page:
681
Fill factor:
1.000000
Offset to children:
4086
Nulls are not allowed in this index.
DESCRIBE オプションで
表示される情報はこれだ
けです。
0
Validating 0th segment
-----------------------------------------------Validating segment SALES_STAR_SEG1...
Root block:
3
Index depth:
1
Average entries in leaf nodes : 677.980392
Average entries in inner nodes : 51.000000
Total leaf entries
Total Inner entries
: 34577
: 51
この情報は、
VERBOSE オプションにより
表示されます。
Total non-null rows indexed
Total leaf nodes: 51
Total inner nodes: 1
: 34577
この情報は、
VERBOSE オプションにより
表示されます。
Segment is ok
VERBOSE オプションを使用した場合、CHECK INDEX によって、図 9-4 に記載さ
れている出力の最下部近くに、次のサイズ情報が表示されます。
■
インデックス エントリ (leaf と inner) の総数
上記の出力では、SALES_STAR_SEG1 インデックス セグメントに 34577 エ
ントリ存在することが表示されています。
データ ウェアハウスのメンテナンス 9-23
CHECK INDEX サイズおよびコンフィグレーション情報
■
leaf node または inner node として使用されている 8KB ブロックの総数
次の計算式は、SALES_STAR_SEG1 セグメントが占有する領域の大きさ
を表します。
Space used = (Total leaf nodes + Total inner nodes) * 8 kilobytes
= 52 * 8 kilobytes
= 416 kilobytes
この計算結果 416KB は、RBW_STORAGE システム テーブルにある
USED の値 424 よりも少なくなっています。これは、USED の値にはメタ
データ用の 8KB ブロックが 1 つ含まれているからです。
RISQL> select substr(seg.name, 1,18) as segname, pseq, maxsize,
>
initsize, extendsize,used
>
from rbw_segments seg, rbw_storage sto
>
where tname = 'SALES' and seg.name = sto.segname
>
order by seg.name;
SEGNAME
PSEQ
MAXSIZE
INITSIZE
EXTENDSIZE USED
...
SALES_STAR_SEG1
1
1024
104
104
424
SALES_STAR_SEG2
1
1024
104
104
432
STAR インデックスの環境設定情報
図 9-4 にある STAR インデックスの CHECK INDEX 出力には、図 9-2 にある B-TREE
インデックスの出力と同じような環境設定情報が表示されています。図 9-5 にある
CHECK INDEX サマリ ファイルには、インデックスで定義されている各フォーリン
キーに関する次の環境設定情報が表示されています。
■
MAXSEGMENTS
■
MAXROWS PER SEGMENT
■
列名
9-24 Administrator’s Guide
CHECK INDEX サイズおよびコンフィグレーション情報
図 9-5
STAR インデックスの CHECK INDEX サマリ出力ファイル
122 nala % more chk_0_Summary_rep.20020530.131423.20002
Checking overall index
Index name:SALES_STAR_IDX
Index revision number:NULL
---------------------------------------------------MAXROWS values used to build this index:
Constraint:SALES_DATE_FKC
NO.
--0
MAX SEGMENTS
-----------1
MAXROWS PER SEGMENT
------------------2500
COLUMN NAME
-----------PERKEY
Constraint:SALES_PRODUCT_FKC
NO.
--0
MAX SEGMENTS
-----------1
MAXROWS PER SEGMENT
------------------2500
1
1
2500
COLUMN NAME
-----------CLASSKEY
PRODKEY
DESCRIBE
オプションで
表示される情報は
これだけです。
Constraint:SALES_STORE_FKC
NO.
--0
MAX SEGMENTS
-----------1
MAXROWS PER SEGMENT
------------------2500
COLUMN NAME
-----------STOREKEY
Constraint:SALES_PROMO_FKC
NO.
--0
MAX SEGMENTS
-----------1
MAXROWS PER SEGMENT
------------------2500
COLUMN NAME
-----------PROMOKEY
Total data row(s) in this table
: 69941
Total data row(s) indexed on this table: 69941
データ ウェアハウスのメンテナンス 9-25
CHECK INDEX サイズおよびコンフィグレーション情報
TARGET インデックスの CHECK INDEX 出力
この例では、Aroma データベースの Sales テーブルにある PROD_PER_SALES_IX
インデックスに対して、VERBOSE オプションを指定した CHECK TABLE 文を示し
ます。
RISQL> check index PROD_PER_SALES_IX
directory '/qa/local/virginia' verbose;
INFORMATION
Index:21 Segment:38 is ok
Report File:/qa/local/virginia/chk_0_38_rep.20020530.130747.25523
Index:21 Segment:40 is ok
Report File:/qa/local/virginia/chk_0_40_rep.20020530.130747.25524
Index validation succeeded
Summary File:
/qa/local/virginia/chk_0_Summary_rep.20020530.130747.20002
1 つの TARGET インデックスは内部的には次の B-TREE インデックスから構成され
ています。
■
■
■
9-26 Administrator’s Guide
ドメイン ビット インデックス
このインデックスには、ドメイン値 1 つにつき 1 つのエントリが含まれま
す。キーはドメイン値です。
RLA (Row List Array) ビット インデックス
このインデックスは、行情報を持つサブブロックをポイントします。キー
はドメイン値と行 ID です。
NULL ビット インデックス
このインデックスは、行に関する行情報を持つサブブロックをポイントし
ます。
CHECK INDEX サイズおよびコンフィグレーション情報
図 9-6 は、TARGET インデックスの先頭セグメントに関する CHECK INDEX 出力
ファイルの一部です。この部分には、B-TREE インデックスの CHECK INDEX 出力
に類似した DOMAIN ビット インデックス情報が表示されています。
図 9-6
TARGET インデックスの先頭セグメントに関する CHECK INDEX 出力 ( その 1)
106 nala % more chk_0_38_rep.20020530.130747.25523
Checking Index Segment
Index name:PROD_PER_SALES_IX
Index revision number:NULL
-----------------------------Column Name is PROMOKEY
Representation is BVI_HYBRID
TARGET INDEX
情報
DESCRIBE オプ
ションで表示さ
れる情報はこれ
だけです。
Domain Bit Index
-----------------Validating index...
BTree index of type:IX_INT4
Keysize:
4
Unique:
0
Nulls:
0
Number of variable length cols:
Index is stored in 2 segments.
Entries per page:
817
Fill factor:
1.000000
Offset to children:
3268
Nulls are not allowed in this index.
0
Validating 0th segment
-----------------------------------------------Validating segment SALES_TARGET_IX1...
Root block:
1
Index depth:
0
Average entries in leaf nodes : 146.000000
Average entries in inner nodes : 0.000000
Total leaf entries
Total Inner entries
: 146
: 0
Total non-null rows indexed
Total leaf nodes: 1
Total inner nodes: 0
: 34577
この情報は、VERBOSE
オプションにより表示さ
れます。
この情報は、VERBOSE
オプションにより表示さ
れます。
データ ウェアハウスのメンテナンス 9-27
CHECK INDEX サイズおよびコンフィグレーション情報
TARGET インデックスのサイズおよび領域情報
TARGET インデックスでは、CHECK INDEX に、DOMAIN ビット、RLA ビット、
および NULL ビット インデックスのサイズと容量に関する情報が表示されます。図
9-7 はこの統計情報のサンプルです。
図 9-7
TARGET インデックス セグメントに関する CHECK INDEX 統計情報
Statistical Information
----------------------Total no. of Domain blocks used : 1
Average space usage in Domain blocks :18.017578 percent
Total no. of RLA blocks used : 1
Average space usage in RLA blocks :28.710938 percent
Total no. of NULL blocks used : 0
Total no. of data blocks used : 3
Total no. of data subblocks used : 146
Total data size : 3573
Average space usage in data blocks :67.903646 percent
Segment Domain Size is 146
Segment Size is 34577
Table Size is 69941
Null Vector Size is 0
Segment is ok
各ブロックは 8KB です。次の計算式は、SALES_TARGET_IX1 セグメントが占有
する領域の大きさを表します。
Space used = ( Num Domain blocks + Num RLA blocks + Num Null blocks
+ Num data blocks ) * 8 kilobytes
= ( 1 + 1 + 0 + 3 ) * 8 kilobytes
= 5 * 8 kilobytes
= 40 kilobytes
9-28 Administrator’s Guide
CHECK INDEX サイズおよびコンフィグレーション情報
ここで CHECK INDEX 統計から計算された領域の値 40 は、セグメント
SALES_TARGET_IX1 の RBW_STORAGE システム テーブルの USED 値 56 よりも
小さくなっています。これは、USED 値には、インデックス作成とメタデータのた
めに使用される 8KB ブロックが追加されているためです。TARGET インデックス
を最適化せずに作成すると、インデックスを分割するために、さらにブロックが追
加されます。
RISQL> select substr(seg.name, 1,17) as segname, pseq, used,
>
totalfree, rowcount
>
from rbw_segments seg, rbw_storage sto
>
where tname = 'SALES' and seg.name = sto.segname order by seg.name;
SEGNAME
PSEQ
USED
TOTALFREE
ROWCOUNT
...
SALES_TARGET_IX1
1
56
968
NULL
SALES_TARGET_IX2
1
56
968
NULL
次の表は、TARGET インデックスのために CHECK INDEX により作成される統計
フィールドについてまとめたものです。
CHECK INDEX
統計フィールド
説明
Total no. of Domain
blocks used
TARGET インデックスのドメイン B-TREE に存在する 8KB
ブロックの数。
Average space usage in
Domain blocks
TARGET インデックスのドメイン ビット インデックスで
使用される領域の割合 ( 単位 : %)。
Total no. of RLA
blocks used
TARGET インデックスの RLA B-TREE に存在する 8KB ブ
ロックの数。
Average space usage in
RLA blocks
TARGET インデックスの RLA ビット インデックスで使用
される領域の割合 ( 単位 : %)。
Total no. of NULL
blocks used
TARGET インデックスの NULL B-TREE に存在する 8KB
ブロックの数。
Average space usage in
NULL blocks
NULL が使用できる場合に、TARGET インデックスの
NULL ビット インデックスで使用される領域の割合
( 単位 : %)。
Total no. of data blocks
used
サブブロックを含む 8KB ブロックの総数。
(１/２)
データ ウェアハウスのメンテナンス 9-29
CHECK INDEX サイズおよびコンフィグレーション情報
CHECK INDEX
統計フィールド
説明
Total no. of data
subblocks used
1 つのデータ ブロックは、行ポインタを含む複数のサブブ
ロックから構成されます。サブブロックの数は、TARGET
インデックスの格納域の表現形式と、サブブロック 1 つあ
たりの行数によって異なります。
Average space usage in
data blocks
1 つのデータ ブロックで使用される領域の割合 ( 単位 : %)。
Segment Domain Size
is
インデックス付けされた列の一意の値の数。
Segment Size is
このインデックス セグメントでインデックス付けされた
行数。
Table Size is
テーブルにある行の総数。
Null Vector Size is
インデックス付けされた列にある NULL 値の数。
(２/２)
TARGET インデックスの環境設定情報
CHECK INDEX 文レポートには、TARGET インデックスについて、B-TREE イン
デックスや STAR インデックスと同じような環境設定情報が表示されています。
9-27 ページ図 9-6 にある CHECK INDEX 出力には、次のように、
PROD_PER_SALES_IX TARGET インデックス固有の環境設定情報が表示されてい
ます。
■
■
■
9-30 Administrator’s Guide
列名は PROMOKEY である
表現形式は BVI_HYBRID である
1 ページ (8KB ブロック ) に 817 エントリ入るが、インデックスがいっぱい
になっていないので、リーフ ノードには 146 エントリしか入っていない
インデックス破損のチェック
図 9-8 にある CHECK INDEX サマリ ファイルには、TARGET インデックスにあるド
メイン値の総数 (302) が含まれています。
図 9-8
TARGET インデックスの CHECK INDEX サマリ出力ファイル
Checking overall index
Index name:PROD_PER_SALES_IX
Index revision number:NULL
---------------------------------------------------NO.
--0
COLUMN NAME
--------------------------------PROMOKEY
Total Domain values in this table
: 302
Total data row(s) in this table
: 69941
Total data row(s) indexed on this table: 69941
TARGET
INDEX 情報
インデックス破損のチェック
VALIDATE オプションを指定した場合、CHECK INDEX 文によって、テーブル行の
キーとインデックスのキーが比較され、これらが一致するかどうかが確認されま
す。
VALIDATE オプションにキーワード FULL をつけて指定すると、CHECK INDEX 操
作でも、各インデックス エントリが一意の行をポイントし、テーブルにある行すべ
てが、1 つのインデックス エントリによってポイントされていることが確認されま
す。
CHECK INDEX に FULL VALIDATE オプションをつけた場合、構成パラメータ
INDEX_TEMPSPACE_THRESHOLD の値が使用されます。このパラメータを設定す
る際の注意事項については、4-47 ページ「THRESHOLD 値」を参照してください。
データ ウェアハウスのメンテナンス 9-31
テーブルやインデックスのデータの増加の監視
テーブルやインデックスのデータの増加の監視
テーブルやインデックスのデータの増加にしたがい、必要な領域を確保しなければ
なりません。都合の悪いときにデータベースの領域が不足することがないように、
データの増加状況を監視して、実際の増加量を空き領域と比較し、必要に応じて新
規セグメントや PSU を追加してください。セグメントの領域が不足すると、エラー
メッセージが表示されます。
セグメントの領域不足によるエラーが発生したときは、以下のような操作を行いま
す。
■
■
ALTER SEGMENTCHANGE MAXSIZE オプションを使用して、最後の PSU
の MAXSIZE 値を大きくします。
ALTER SEGMENT...ADD STORAGE オプションを使用し、新規の PSU をセ
グメントに追加します。
重要 : ファイル システムの空き容量がなくなった場合は、ファイル システムに空
き領域を作らないと、データをセグメントに追加できません。
テーブルやインデックスのデータの増加状況を監視するには、RBW_SEGMENTS
テーブル (TNAME または INAME、NPSUS、および TOTALFREE、ROWCOUNT の
各列 ) と RBW_STORAGE テーブル (SEGNAME、MAXSIZE、および USED の各
列 ) の情報を使用します。デフォルト セグメントのデータは必要に応じて増加しま
すが、ファイル システムの容量によって制限されます。
STAR インデックス
STAR インデックスは、参照先テーブルの最大行数に応じたサイズで作成されます。
参照先テーブルの最大行数は、パラメータ MAXROWS PER SEGMENT 、およびパ
ラメータ MAXSEGMENTS の値に基づいて算出されます。これらのパラメータの値
の変更により、STAR インデックスの作成時よりも最大行数が多くなると、その
テーブルの STAR インデックスが無効になることがあります。その場合は、REORG
コマンドで再作成するか、インデックスを削除してから再作成する必要があるとい
うメッセージが表示されます。STAR インデックス サイズの増加については、
4-58 ページ「テーブル データの増加への対応」を参照してください。
参照先テーブルを作成する際は、予想される最大サイズを正しく反映した値を
MAXROWS PER SEGMENT と MAXSEGMENTS に設定し、参照先テーブルの拡大に
備えて十分な領域を STAR インデックスに確保してください。
9-32 Administrator’s Guide
MAXSIZE 列
無効な STAR インデックスがあるというエラー メッセージが表示された場合は、
REORG 操作によってその STAR インデックスを再作成するか、インデックスを削
除してから STAR インデックスを再作成し、テーブルの拡大に対応したサイズにし
てください。デフォルト セグメントに空き領域があれば、REORG コマンドでイン
デックスを再作成することができます。STAR インデックスを格納しているセグメ
ントの空き領域がない場合は、ALTER SEGMENT コマンドによって利用可能な領域
を増やすか、スペースを増やすか、追加セグメントを作成してインデックスにア
タッチしてから、REORG 操作を実行してください。
MAXSIZE 列
PSU は、IBM Red Brick Warehouse が使用するディスク領域の最小割り当て単位であ
る 8KB (8192 バイト ) ごとにブロック化されています。RBW_STORAGE システム
テーブルの MAXSIZE 列は、セグメントの PSU ( ファイル ) の最大サイズを KB 単
位で指定します。MAXSIZE 列と INITSIZE 列の値は、CREATE SEGMENT 文の
MAXSIZE と INITSIZE の値と一致しません。その理由は、次のとおりです。
■
■
■
MAXSIZE 列の入力値は、8KB の倍数に切り上げられます。
先頭ファイルの最小サイズはつねに 2 ブロック、つまり 16KB です。
PSU が MAXSIZE 値に達する前にファイル システムの空き領域がなくなる
場合は、MAXSIZE の値が動的に調整されます。詳細については、
9-40 ページ「MAXSIZE の動的調整」を参照してください。
例
次の文は、mkt1 と mkt2 という 2 つの PSU で構成されるセグメントを作成します。
create segment mkt
storage 'mkt1' maxsize 38 initsize 16 extendsize 8,
storage 'mkt2' maxsize 30;
RBW_STORAGE テーブルには、最大サイズが 40KB の mkt1、最大サイズが 32KB
の mkt2 が登録されます (8KB の倍数に切り上げられるため )。
RBW_STORAGE テーブルの MAXSIZE 列は、ファイル サイズの上限を示します。
PSU が最大サイズになる前に、そのファイル システムの空き領域がなくなり、セグ
メントの次の PSU に空き領域がある場合は、その PSU の MAXSIZE 値が現在のサ
イズに削減され、利用可能な領域を持つ次の PSU に格納先が切り換えられます。
データ ウェアハウスのメンテナンス 9-33
USED 列
USED 列
RBW_STORAGE システム テーブルの USED 列は、これまでの PSU の割り当て量、
すなわち PSU がこれまでに使用した領域の最大容量を示します。この値は、ALTER
SEGMENT 文の CHANGE MAXSIZE オプションで MAXSIZE を変更する場合の下限
も示しています。
USED の値は、必ずしも PSU で使用された領域の容量を示しているとは限りませ
ん。USED の領域の一部が、実際には内部未使用格納域リスト上に存在することも
あるからです。使用されたブロックに、どれだけの未使用領域が残っているかを調
べるには、9-37 ページ「freespace フィールド」の説明に従って、VERBOSE オプ
ションを指定して、CHECK TABLE 文を使用します。
例 : RBW_STORAGE の MAXSIZE 列と USED 列
次の例では、Aroma データベースの Sales テーブルに対して、RBW_STORAGE シ
ステム テーブルの MAXSIZE 列と USED 列の値を示します。
RISQL> select segname,segid,pseq,maxsize,initsize,extendsize,used
> from rbw_storage where segid = 21;
SEGNAME
SEGID PSEQ MAXSIZE INITSIZE EXTENDSIZE
DAILY_DATA1
21
1
1024
104
104
DAILY_DATA1
21
2
1024
104
104
USED
1024
32
RISQL> select segname, segid, maxsize, initsize, extendsize, used
> from rbw_storage where segid = 22;
SEGNAME
SEGID PSEQ MAXSIZE INITSIZE EXTENDSIZE
DAILY_DATA2
22
1
1024
104
104
DAILY_DATA
22
2
1024
104
104
RISQL>
USED
1024
56
USED 列からわかるように、DAILY_DATA1 セグメントと DAILY_DATA2 セグメン
トの 1 つめの PSU は 1024KB という MAXSIZE の値に達しています。2 つめの PSU
は各セグメントに割り当てられています。
9-34 Administrator’s Guide
TOTALFREE 列
TOTALFREE 列
RBW_SEGMENTS システム テーブルの TOTALFREE 列は、セグメントがインデッ
クスとテーブルのどちらに関連付けられているかにかかわらず、そのセグメントが
利用できる未使用領域の合計を示します。この値は、セグメントが最大サイズまで
拡大できる十分な領域がファイル システムにあると仮定しています。
テーブルの場合、テーブルから行が削除されていなければ、RBW_STORAGE の
MAXSIZE から USED を差し引いた領域と、そのテーブルに関連付けられたセグメ
ントの RBW_SEGMENTS の TOTALFREE の領域が等しくなります。9-35 ページ
「例 : RBW_SEGMENTS の TOTALFREE 列」を参照してください。
IBM Red Brick Warehouse は、行単位で領域を再利用します。テーブルから行が削除
された場合、次にテーブルに追加された行は、最後に削除された行の場所に格納さ
れます。したがって、1 つのセグメントにある複数の行をテーブルから削除すると、
削除された行が格納されていた領域が、そのセグメントの未使用領域になります。
TOTALFREE の値は、行の削除によって解放された領域ではなく、まだ使用されて
いない領域だけをカウントします。多数の行をテーブルから削除すると、
TOTALFREE の値以上の領域が利用できる場合があります。
使用されたブロックに、どれだけの未使用領域が残っているかを調べるには、
9-37 ページ「freespace フィールド」の説明に従って、VERBOSE オプションを指定
した CHECK TABLE 文を使用します。
例 : RBW_SEGMENTS の TOTALFREE 列
次のクエリでは、Aroma データベースの Sales テーブルに対する、
RBW_SEGMENTS システム テーブルの TOTALFREE 列を取得します。
RISQL> select name, tname, npsus, ncols, id, totalfree
> from rbw_segments where tname = 'SALES';
NAME
DAILY_DATA1
DAILY_DATA2
DEFAULT_SEGMENT_23
TNAME
SALES
SALES
SALES
NPSUS
2
2
1
NCOLS
1
1
1
ID
21
22
23
TOTALFREE
992
968
2096304
INAME
NULL
NULL
SALES_STAR_IDX
9-34 ページ「例 : RBW_STORAGE の MAXSIZE 列と USED 列」は、Sales テーブルの
これらの値が Aroma データベースから得られたことを表しています。次の式は、
行が削除されていないことを示しています。
UNALLOCATED SPACE =
=
=
=
MAXSIZE - USED
1024 - 32
992 kilobytes
TOTALFREE
データ ウェアハウスのメンテナンス 9-35
シュード列
シュード列
IBM Red Brick Warehouse データベースのユーザ テーブルには、RBW_ROWNUM、
RBW_SEGID、RBW_SEGNAME という 3 つの シュード列 があります。シュード
列はシステム テーブルに領域を取らず、ブロックのヘッダに格納されているデータ
を取得して、この情報を列のフォーマットで表示するものです。テーブルのサイズ
の算出に、シュード列を含めてはいけません。
項目リストにシュード列のあるクエリを実行した場合、そのシュード列はクエリ結
果に列として書き込まれます。したがって、これらの列はクエリ結果に対する格納
領域の計算に含まれることになります。
シュード列
データ型
説明
RBW_ROWNUM
INTEGER
セグメントを構成する各行の行番号が格納さ
れます。セグメントの先頭行の番号は 0 です。
行のカウントは、どのセグメントも 0 から始
まるため、複数セグメントの場合は、
RBW_ROWNUM の値が同じ行が複数ありま
す。
RBW_SEGID
SMALLINT
指定した行の相対セグメント ID が格納されま
す。先頭に近いセグメントほど、値が小さく
なります。この値は、RBW_SEGMENTS シス
テム テーブルの LOCAL_ID 列の値と一致しま
す。RBW_SEGID シュード列の値は、連続し
ているとはかぎりません。この値の相対順序
により、セグメントの相対順序がわかります。
RBW_SEGNAME
CHAR(129)
指定した行データの格納先セグメント名が格
納されます。
9-36 Administrator’s Guide
freespace フィールド
例
Aroma データベースの Sales テーブルへのクエリにより、RBW_ROWNUM、
RBW_SEGID、RBW_SEGNAME の各シュード列の値を検索した例を示します。
RISQL> select rbw_rownum, substr(rbw_segname, 1, 20)
> as RBW_SEGNAME, rbw_segid, dollars
> from sales where rbw_rownum < 4;
RBW_ROWNUM
0
1
2
3
0
1
2
3
RISQL>
RBW_SEGNAME
DAILY_DATA1
DAILY_DATA1
DAILY_DATA1
DAILY_DATA1
DAILY_DATA2
DAILY_DATA2
DAILY_DATA2
DAILY_DATA2
RBW_SEGID
0
0
0
0
1
1
1
1
DOLLARS
34.00
60.75
270.00
36.00
348.00
123.25
121.50
56.00
この例では、RBW_ROWNUM シュード列の値 0、1、2、3 に 2 行が対応していま
す。片方は DAILY_DATA1 セグメントに格納され、もう片方は DAILY_DATA2 セグ
メントに格納されています。
freespace フィールド
VERBOSE オプションを指定した CHECK TABLE 文による出力の freespace フィール
ドには、テーブル内の既存の割り当て済みブロックで使用されているバイト数が表
示されます。セグメント内の未使用領域の値をさらに正確に求めるには、この
freespace の値を RBW_SEGMENTS システム テーブルの TOTALFREE 列に追加し
ます。
データ ウェアハウスのメンテナンス 9-37
freespace フィールド
例 : CHECK TABLE の出力における freespace セグメント統計
次の例では、Aroma データベースの Sales テーブルに対し、CHECK TABLE の出力
における freespace フィールドの値と、RBW_SEGMENTS システム テーブルの
TOTALFREE 列の値を示します。
Segment statistics:
active rows:34577, deleted rows:0, total blocks:132, free blocks:0
rows/block:264, storage reclen:29, average reclen:29, indirect rows:0
max reclen:29, longest rec:29, min reclen:29, shortest rec:29
freespace:741, unused RowIDs:7, unusable freespace:0
Segment statistics:
active rows:35364, deleted rows:0, total blocks:135, free blocks:0
rows/block:264, storage reclen:29, average reclen:29, indirect rows:0
max reclen:29, longest rec:29, min reclen:29, shortest rec:29
freespace:908, unused RowIDs:12, unusable freespace:0
この例では、1 つめのセグメントの <freespace> フィールドの値は 741 バイトです。
次の式は、この <freespace> の値が割り当て済み領域での未使用バイト数であること
を示しています。
space allocated per block
= ((storage reclen +overhead)* rows/block) + overhead
= ((29 + 2)* 264) + 4
= 8188 bytes / block
space allocated in segment 1
= bytes allocated per block * number of blocks
= 8188 * 131
= 1072628 bytes allocated per segment
actual space used = active rows * (average reclen +overhead)
= 34577 * (29 + 2)
= 1071887 bytes used in segment 1
freespace = space allocated per segment - actual space used
= 1072628 - 1071887
= 741 bytes
9-35 ページ「例 : RBW_SEGMENTS の TOTALFREE 列」には、Aroma データベース
の Sales テーブルに対する TOTALFREE の値が 992KB であることが示されていま
す。次の式を使用して、Sales テーブルの 1 つめのセグメントの未使用領域の合計を
算出します。
total unused space = TOTALFREE + freespace
= 992 kilobytes + 741 bytes
= 992.72 kilobytes
9-38 Administrator’s Guide
セグメントへの領域の割り当て方法
セグメントへの領域の割り当て方法
セグメントの領域が不足するのは、利用可能な領域がすべて割り当てられ、
RBW_SEGMENTS システム テーブルの TOTALFREE 列の値が 0 になった時です。
ファイル システムの空き容量がないために PSU の領域が不足した場合は、パラ
メータ PSU MAXSIZE の値が、現在のファイル サイズまで動的に削減されます。ほ
かのファイル システムにある次の PSU に空き領域があれば、ロード操作や挿入操
作は続行されます。
PSU は、RBW_STORAGE テーブルの PSEQ 列の順序番号に従い、定義順に使用さ
れます。現在書き込み中の PSU をカレント PSU といいます。PSU の領域を拡張で
きるのは、その PSU のセグメントがまだテーブルやインデックスに割り当てられて
いない場合、そして PSU がカレント PSU または後続の PSU である場合です。つま
り、使用中の PSU より前の PSU の領域を拡張することはできません。しかし、セ
グメント末尾で行を削除し、ALTER SEGMENT RELEASE STORAGE コマンドを使
用して領域を開放する場合は、最後の空の PSU を削除できます。その後、これまで
の PSU の MAXSIZE を変更することができます。
セグメントと PSU の作成時は、INITSIZE で指定した各 PSU の初期サイズが割り当
てられます。格納領域は、必要になるまで拡張されません。このため、PSU がパラ
メータ MAXSIZE で指定された最大サイズに達する前に、ファイル システムの空き
容量がなくなることがあります。その場合データベース サーバは、自動的に次の
PSU の利用可能な領域を確認します。つまり、割り当て済みの INITSIZE の領域に
未使用領域があるか、ほかのファイル システムに空き領域があるかを確認します。
利用可能な領域がある PSU が見つかると、最大サイズに達していない PSU の
MAXSIZE を現在のサイズに変更し、空き容量のないファイル システムにある未使
用 PSU の MAXSIZE を、各 PSU の INITSIZE サイズに変更します。その後、次の利
用可能な領域がある次の PSU からデータの書き込みを再開し、空き容量のないファ
イル システムと使用中の PSU を通知する警告メッセージを表示します。
セグメントに利用可能な領域がある後続の PSU がない場合は、領域不足エラーによ
り操作が中止され、MAXSIZE は変更されません。
データ ウェアハウスのメンテナンス 9-39
セグメントへの領域の割り当て方法
MAXSIZE の動的調整
MAXSIZE 値の動的な調整が行われた場合は、そのセグメントと PSU に以下の条件
が適用されます。
■
■
■
変更後の MAXSIZE の値は、RBW_STORAGE テーブルの MAXSIZE 列と
USED 列、および RBW_SEGMENTS テーブルの TOTALFREE 列に反映さ
れます。
動的にサイズが調整された PSU は、同一のテーブルまたはインデックスに
アタッチしている間は、( 手動か動的かに関わらず ) 再びサイズを変更す
ることはできません。領域が不足しているファイル システムに、利用可能
な空き領域ができた場合は、そのときのカレント PSU の後続の PSU に割
り当てることができます。
テーブルが削除され、それに関連するセグメントが残っている場合は、す
べての PSU の有効サイズを MAXSIZE 値に戻してから動的調整が行われま
す。
例
PSU が最大サイズになる前にファイル システムの空き容量が不足した場合、セグメ
ントのカレント PSU と後続 PSU の MAXSIZE がどのように調整されるかを示しま
す。
あるテーブルのセグメントは、ディスク d1 および d2 の複数のファイル システム上
にある、複数の PSU p1、p2、p3、p4 で構成されているとします。PSU p1 が最大サ
イズになり PSU p2 ( カレント PSU) にデータ書き込み中に、ディスク d1 のファイル
システムが一杯になったとします。PSU p2 が使用しているのは、680 ブロックのう
ちの 620 ブロックで、PSU p3 はまだ空です。データベース サーバは、PSU p2 の
MAXSIZE を 620 に、PSU p3 の MAXSIZE を 120 (INITSIZE の値 ) に自動調整しま
す。そして、空き容量のないファイル システムにある、INITSIZE が割り当てられ
ているブロック ( この場合は PSU p3) にデータを書き込みます。その後は、利用可
能な領域があるファイル システム上の次の PSU ( この場合はディスク d2 上の PSU
p4) に格納先を切り換えます。
9-40 Administrator’s Guide
セグメントへの領域の割り当て方法
次の図と表は、この例を示したものです。
図 9-9
PSU のサイズ変更
ディスク d1
ディスク d2
凡例
使用済み
スペースの割り当てなし
利用可能なスペース
PSU p1
PSU p4
PSU p2
PSU p3
この例で MAXSIZE は、次の表に示されているように、動的に減少されています。
PSU
INITSIZE
EXTENDSIZE
元の MAXSIZE
調整後の MAXSIZE
p1
120
100
680
変更なし
p2
120
100
680
620
p3
120
100
680
120
p4
300
150
750
変更なし
カレント PSU の前にある領域は拡張できないため、あとからディスク d1 のファイ
ル システムに空き領域ができても、PSU p2 と PSU p3 が現行のテーブルまたはイン
デックスにアタッチしている間は、その領域は PSU p2 と PSU p3 には使用されませ
ん。
ただし、ディスク d2 の PSU p4 がカレント PSU であり、ディスク d1 のファイル シ
ステムに PSU p5 が存在している場合は、ディスク d2 にできた空き領域を PSU p5 (
または、セグメント格納指定において PSU p4 の後ろにある PSU か、PSU p4 の定義
後に ALTER SEGMENT 文で追加した PSU) に使用することができます。この場合
は、次の図のようになります。
データ ウェアハウスのメンテナンス 9-41
セグメントの変更
図 9-10
ディスク間の領域の使用
ディスク d1
ディスク d2
凡例
PSU p1
PSU p4
使用済み
スペースの割り当てなし
利用可能なスペース
PSU p2
PSU p3
PSU p5
セグメントの変更
セグメントを利用すると、データやインデックスを複数のドライブに分散し、一部
のセグメントをオフラインにしたり完全に削除しても、テーブルをアクセス可能な
状態にしておくことができます。
ALTER SEGMENT の使用
セグメントについては、以下の操作を行うことができます。
■
■
■
■
■
9-42 Administrator’s Guide
テーブルやそのインデックスでのセグメントのアタッチや切り離し。テー
ブルの拡大に応じた新規セグメントの追加や、データが古くなったセグメ
ントの削除ができます (ATTACH、DETACH)。
データのロード先セグメント、またはテーブルやインデックスから切り離
すセグメントのオフライン化や、データをロードしたセグメント、または
バックアップからリストアしたセグメントのオンライン化 (OFFLINE、
ONLINE)。
セグメントのすべてのデータの削除。セグメントは再利用できるようにア
タッチされたままとなります (CLEAR)。
セグメントの新規範囲の指定。セグメント間でのデータの分散方法を変更
したり、隣り合わないセグメントに領域の値を移動したりします
(RANGE、RANGE MOVE)。
テーブルの拡大に応じた、新規 PSU の追加 (ADD STORAGE)。
アクティブなユーザがいないことの確認
■
■
■
■
■
■
■
セグメントに割り当てられているが使用されていない領域を解放するか、
セグメントから PSU を削除して、オペレーティング システムに格納領域
を返します (RELEASE STORAGE、DROP LAST STORAGE)。
PSU の最大サイズ、拡張サイズ、またはパスの変更。セグメントの拡大を
制御し、必要に応じて移動できます (CHANGE MAXSIZE、CHANGE
EXTENDSIZE)。
PSU のパスを変更します。または、必要に応じて、セグメント全体を別の
場所に移動します (CHANGE PATH、MIGRATE TO)。
セグメント名の変更。識別しやすい名前にします (RENAME)。
セグメント化の基準列の指定。最初に単一のデフォルト セグメントに作成
されたため、セグメント化の基準となる列で定義されていないテーブルや
インデックスをセグメント化できます (SEGMENT BY)。
セグメントを構成する PSU に対する物理的な破損の検証と、セグメントが
破損している場合の原因の解明 (VERIFY)。
「damaged ( 破損 )」とマークされていたが修復されたセグメントの、正常
状態への強制的な変更 (FORCE INTACT)。
セグメントを変更するユーザは、DBA システム ロールのメンバーか、セグメント
の作成者でなければなりません。
アクティブなユーザがいないことの確認
ALTER SEGMENT 文を使用する前に、ALTER SEGMENT 操作の対象となるオブ
ジェクトにアクセスしているユーザがいないことを確認します。データベースに誰
もログオンしていないことが確認されていない場合、LOCK DATABASE 文、または
ALTER SEGMENT QUIESCE 文のどちらかを使用します。データベースのオブジェ
クトにユーザがアクセスしていると、ALTER SEGMENT 操作に失敗することがあり
ます。
ほかのユーザがアクセスできないように LOCK DATABASE 文を使用してデータ
ベースをロックし、作業を完了してから、UNLOCK DATABASE 文でロックを解除
します。次に例を示します。
lock database;
alter segment ...;
unlock database;
データベースを完全にロックしたくない場合は、ALTER SEGMENT QUIESCE 文を
使用して新規コマンドをすべて一時停止し、作業を完了してから、データベースで
の処理操作を再開します。次に例を示します。
alter system quiesce;
alter segment ...;
alter system resume;
データ ウェアハウスのメンテナンス 9-43
セグメントのアタッチと切り離し
以下の節では、ALTER SEGMENT 文で実行できる操作について説明します。構文の
説明と詳細については、『SQL Reference Guide』を参照してください。
セグメントのアタッチと切り離し
テーブルのサイズが増減したり、検索条件が変化した場合は、必要に応じてテーブ
ルやインデックスにセグメントをアタッチしたり、切り離すことができます。ハッ
シュによってセグメント化されているテーブルは、セグメントをアタッチすること
はできません。
アタッチするセグメントは、あらかじめ作成しておかなければなりません。名前付
きセグメントは CREATE SEGMENT 文で作成し、デフォルト セグメントは CREATE
TABLE 文、または CREATE INDEX 文で作成します。新たにアタッチさせたセグメ
ントは、自動的に ONLINE になります。
テーブルにセグメントをアタッチする場合は、セグメント化の基準列のデータ型に
より有効な値の範囲を指定しなければなりません。
B-TREE または TARGET インデックスにセグメントをアタッチするには、以下のい
ずれかの方法を使用します。
■
■
ローカル インデックスでは、RANGE LIKE SEGMENT 句にデータ セグメ
ント名を指定します。どのような場合にこの句を使用するかについては、
9-45 ページ「シングル セグメント テーブルまたはインデックスへのセグ
メントのアタッチ」の例を参照してください。
ローカル以外のインデックスについては、セグメント化の基準列のデータ
型により有効な値の範囲を指定しなければなりません。
STAR インデックスにセグメントをアタッチする場合、範囲指定は任意です。指定
する場合は、参照先 ( ディメンジョン ) テーブルのセグメント化の基準列のセグメ
ント名と行データ ID (RBW_ROWNUM シュード列 ) に基づいて指定します。参照
先テーブルのセグメント化の基準列は CREATE TABLE 文で定義します。
セグメントを切り離すと、テーブルやインデックスからセグメントが削除され、そ
のセグメントの行データとインデックスのエントリがすべて削除されます。ユーザ
作成セグメントは削除されませんが、空のままとなり、別のオブジェクトに再ア
タッチできます。デフォルト セグメントの場合は、セグメントも削除されます。
セグメント範囲の先頭から末尾へセグメントを移動する ( データベースの古いデー
タを削除し、そのセグメントを新規データに使用する ) 場合は、次の方法のいずれ
かを使用します。
■
■
9-44 Administrator’s Guide
キーワード MOVE を使用して、セグメント範囲の位置を移動します。詳細
については、9-60 ページ の手順を参照してください。
セグメントを切り離し、新しい範囲指定にアタッチします。詳細について
は、9-57 ページ の手順を参照してください。
シングル セグメント テーブルまたはインデックスへのセグメントのアタッチ
シングル セグメント テーブルまたはインデックスへ
のセグメントのアタッチ
1 つのセグメントに格納され、作成時にセグメント化の基準列を指定しなかった
テーブルやインデックスについては、新規セグメントをアタッチする前にセグメン
ト化基準列を指定してください。たとえば、line_items テーブルに別のセグメント
をアタッチし、その STAR インデックスに対応するセグメントをアタッチするとし
ます。. 次の例にある CREATE 文では、line_items テーブルが 1 つのデフォルト セグ
メントに配置され、line_items_star_idx STAR インデックスが別のデフォルト セグ
メントに配置されています。
create table line_items (
order_no integer not null,
line_item integer not null,
perkey integer not null,
classkey integer not null,
prodkey integer not null,
receive_date date not null,
quantity integer not null,
price dec(7,2) not null,
primary key (order_no, line_item),
constraint line_order_fkc foreign key (order_no)
references orders (order_no),
onstraint line_period_fkc foreign key (perkey)
references period (perkey),
constraint line_product_fkc foreign key (classkey, prodkey)
references product (classkey, prodkey))
maxrows per segment 2000;
create star index line_items_star_idx on line_items
(line_order_fkc, line_period_fkc, line_product_fkc);
データ ウェアハウスのメンテナンス 9-45
シングル セグメント テーブルまたはインデックスへのセグメントのアタッチ
1 つのセグメント テーブルまたはインデックスに対する別セグメントのア
タッチ
1.
このテーブルで MAXSEGMENTS の値がデフォルトの 1 に定義されている
場合、まずテーブルを変更して、より大きな値を指定する必要がありま
す。
alter table line_items change maxsegments 2;
2.
テーブル用に新たにセグメントを作成します。
create segment line_items_seg2
storage 'line_items_seg2_psu1'
maxsize 1024
initsize 100
extendsize 100;
3.
テーブルのデフォルト セグメント名を取得します。
select substr(name, 1,20) as name,
substr(tname,1,17) as tname,
substr(iname, 1,22) as iname, NPSUS
from rbw_segments
where tname = 'INE_ITEMS';
NAME
TNAME
INAME
NPSUS
DEFAULT_SEGMENT_19
LINE_ITEMS
NULL
1
DEFAULT_SEGMENT_20
LINE_ITEMS
LINE_ITEMS_PK_IDX
1
DEFAULT_SEGMENT_36
LINE_ITEMS
LINE_ITEMS_STAR_IDX 1
4.
既存のセグメントを変更して、セグメント化の基準となる列を指定しま
す。
このテーブルは 1 つのセグメントに格納され、作成時にセグメント化の基
準列が指定されていないため、新規セグメントをアタッチする前にセグメ
ント化基準列を指定してください。
alter segment default_segment_19 of table line_items
segment by order_no;
9-46 Administrator’s Guide
シングル セグメント テーブルまたはインデックスへのセグメントのアタッチ
5.
新規セグメントを指定するための範囲を取得します。
select distinct(order_no) from line_items;
3600
...
3624
たとえば、先頭のセグメントには最初から 25 個の注文番号、2 つめのセグ
メントにはその次の 25 個の注文番号を入れるとします。
Segment 1 range (3600:3625)
Segment 2 range (3625:3650)
セグメントには開始地点の境界値は含まれますが、終了地点の境界値は含
まれません。したがって、先頭セグメントには値 3600 から 3624 までが、
2 つめのセグメントには 3625 から 3649 までの値が含まれます。しかし、
セグメント範囲を定義する場合は、先頭セグメントについては min、最終
セグメントについては max を値に指定する必要があります。
6.
seg1
seg2
min:3625
3625:max
新規インデックス セグメントをインデックスにアタッチします。
alter segment line_items_seg2 attach to table line_items
range (3625:max);
Line_items テーブルでは、新規セグメントの範囲に行が含まれていてはい
けません。含まれている場合、アタッチ操作でデータの移動が必要になる
というエラー メッセージが表示されます。
7.
テーブルのデフォルト セグメントの名前を、よりわかりやすい名前に変更
します。新たにアタッチされたセグメントに類似した名前を使用してくだ
さい。
alter segment default_segment_19 of table line_items
rename line_items_seg1;
警告 : デフォルト セグメント名を変更しても、動作は変わりません。テーブルを
削除すると、このセグメントも削除されます。
データ ウェアハウスのメンテナンス 9-47
セグメント範囲の指定
8.
テーブルにある既存のインデックスもセグメント化する必要がある場合
は、次の手順に従って操作します。
a. 新規インデックス セグメントを作成する
create segment lisi_seg2
>
storage 'line_items_star_psu2'
>
maxsize 512
>
initsize 50
>
extendsize 50;
b.
新規インデックス セグメントをアタッチする
alter segment lisi_seg2
attach to index line_items_star_idx range like
segment line_items_seg2;
この例では、インデックス セグメントが、新たにアタッチされたテー
ブル セグメントと同じ範囲にアタッチされるように、RANGE LIKE
SEGMENT 句が指定されています。
c.
インデックスのデフォルト セグメントの名前を、よりわかりやすい名
前に変更し、新たにアタッチされたインデックス セグメントに類似し
た名前を使用してください。
alter segment default_segment_36
of index line_items_star_idx rename line_items_seg1;
警告 : デフォルト セグメント名を変更しても、動作は変わりません。インデック
スを削除すると、このセグメントも削除されます。
セグメント範囲の指定
セグメントのデータ値または行データ ID の範囲を変更し、セグメントに格納され
るデータやインデックス エントリの範囲を変更することができます。テーブルやイ
ンデックスのセグメント範囲に不連続や重複を生じさせたり、既存の行データやイ
ンデックス エントリをほかのセグメントに移動させるような範囲の変更はできませ
ん。
テーブルやインデックスのセグメント範囲を移動するには、このセグメントのデー
タ値や行データ ID に対する新しい範囲を指定します。ALTER SEGMENT 文で使用
されている RANGE MOVE 句の例については、9-57 ページ「データ セグメントおよ
びインデックス セグメントのロールオフと再使用」を参照してください。
9-48 Administrator’s Guide
セグメントのオフライン / オンライン
セグメントのオフライン / オンライン
オフラインにしたセグメントは一時的に使用できなくなりますが、テーブルのほか
の部分は利用できます。オフライン モードは、データのロードや破損したセグメン
トのリストアを実行しながら、テーブルの残りの部分をユーザに引き続き利用させ
る場合に使用します。切り離すセグメントは、オフラインにしておかなければなり
ません。
テーブルやインデックスが部分的に利用不能な場合のユーザへの影響は、rbw.config
ファイルの SET PARTIAL AVAILABILITY オプションで制御できます。セグメント
の部分利用の詳細については、2-13 ページ「テーブルとインデックスの部分的な利
用」を参照してください。
オフラインのセグメントを更新したあとは、テーブル、またはインデックスの残り
の部分とセグメント ( データおよびインデックスの構造体 ) を同期させる必要があ
ります。そのためには TMU の SYNCH コマンドを使用します。SYNCH コマンドに
関する詳細については、『Table Management Utility Reference Guide』を参照してくだ
さい。
ヒント：テーブルやインデックスの全セグメントをオフラインにすることはでき
ません。最低 1 つのセグメントはオンラインにしておきます。つまり、複数セグメ
ントのテーブルやインデックスの最後のオンライン セグメント、あるいはセグメン
トが 1 つだけのテーブルやインデックスのセグメントをオフラインにすることはで
きません。
セグメントのクリア
データ セグメントをクリアすると、そのセグメントの全データと、そのデータを参
照するインデックスのエントリが削除されます。クリアできるのは、複数のデータ
セグメントからなるテーブルにアタッチしているセグメントだけです。インデック
ス セグメントはクリアできません。
集約保守が有効になっている場合、セグメントがクリアされると、事前計算ビュー
がすべて更新されるか、または再構築されます。集約保守の詳細については、
『IBM Red Brick Vista User’s Guide』を参照してください。
セグメント名の変更
テーブルやインデックスにアタッチまたは切り離されている、名前付きセグメント
とデフォルト セグメントの名称を変更することができます。セグメント名を変更す
る主な理由は、識別しやすい適切な名前を付けるためです。
データ ウェアハウスのメンテナンス 9-49
セグメントからの格納領域の解放と削除
セグメントからの格納領域の解放と削除
セグメントの末尾に未使用の領域が含まれている場合、次の ALTER SEGMENT 文
オプションの 1 つを使用して、この領域をオペレーティング システムに返すことが
できます。
■
■
RELEASE STORAGE
RELEASE STORAGE オプションを使用し、セグメントの末尾にある、行が
削除された領域を解放します。
DROP LAST STORAGE
DROP LAST STORAGE オプションを使用し、セグメントにある最後の空の
PSU を削除します。
重要 : 最後の PSU で行を削除したが、領域がまだ論理的には使用中である場合、
PSU を削除する前に、まず、RELEASE STORAGE オプションを使って領域を解放す
る必要があります。手順については、9-50 ページ「格納領域のセグメントからの解
放と削除」を参照してください。
たとえば、Sales テーブルは 2 つのセグメントで構成されていますが、2 つめのセグ
メントのデータが必要ないとします。別のアプリケーションで使用できるように
ディスク領域を解放する必要がありますが、後で使用できるように必要最小限の領
域を割り当ててセグメントを残したいと思います。この場合、次の手順に従って操
作します。
格納領域のセグメントからの解放と削除
1.
このセグメントのデータを削除します。
RISQL> delete from sales where perkey > 415;
** INFORMATION ** (211) Deleted 35270 rows from SALES.
2.
CHECK TABLE を実行して、テーブルの物理的な完全性を検証します。
RISQL> check table sales
directory'/qa/local/virginia/check_results/' verbose;
CHECK TABLE の実行メッセージに、次の行が表示されていることを確認
します。
No inconsistencies were detected.
9-50 Administrator’s Guide
セグメントからの格納領域の解放と削除
3.
セグメントに空き領域が存在するかどうかを判断します。
a. CHECK TABLE 文からの出力にある Segment statistics セクションの free
blocks フィールドを確認します。
Segment statistics:
active rows:94, deleted rows:0, total blocks:135, free blocks:118
rows/block:264, storage reclen:29, average reclen:29, indirect rows:0
max reclen:29, longest rec:29, min reclen:29, shortest rec:29
freespace:128034, unused RowIDs:4130, unusable freespace:0
この統計では、free blocks フィールドには 118 という値が表示されて
います。また、active rows フィールドを見ると、このセグメントには
まだ 94 行残っていることがわかります。しかし、セグメントの末尾
に 94 行のアクティブ行が 1 つでも残っていたら、118 ブロックの一部
は解放できません。
b.
rbw_storage システム テーブルの used 列をクエリして、論理的に使用
されているスペースがまだ残っているかどうかを確認します。
RISQL> select substr(seg.name, 1,17) as segname, pseq,
used, totalfree, rowcount
from rbw_segments seg, rbw_storage sto
where tname = 'SALES' and seg.name = sto.segname and
usage = 'TABLE'
order by seg.name;
SEGNAME
PSEQ
USED
TOTALFREE
ROWCOUNT
DAILY_DATA1
1
1024
992
34577
DAILY_DATA1
2
32
992
34577
DAILY_DATA2
1
1024
984
94
DAILY_DATA2
2
40
984
94
used 列を見ると、2 番目のセグメント daily_data2 では、まだ 1064KB
(PSU1 で 1024KB 、PSU2 で 40KB ) が使用中であることがわかります。
また、rowcount 列を見ると、2 番目のセグメントには、まだ、94 行
残っていることがわかります。
データ ウェアハウスのメンテナンス 9-51
セグメントからの格納領域の解放と削除
セグメントの末尾から削除された行によって占有されていた領域を解放し
ます。
4.
RISQL> alter segment DAILY_DATA2 of table sales release
> storage;
a.
クエリと 手順 3 の CHECK TABLE 出力から、2 つめのセグメントには
まだ 94 行残っていることがわかりますが、これらの行が PSU の末尾
にあるため、格納領域を十分に解放できない可能性があります。この
場合、ALTER SEGMENT RELEASE STORAGE 文の後で次のメッセー
ジのいずれかが表示されます。
** ERROR ** (6402) RELEASE STORAGE を実行できません。
セグメントに解放できる領域がありません。
この 6402 メッセージは、セグメントの末尾にまだアクティブ行が含
まれている場合に表示されます。
** WARNING ** (6403) 解放されたブロックの割合 : 0.74%。
b.
この 6403 メッセージは、解放操作で、セグメントの末尾にある 8KB
のブロックが最低でも 1 つは解放できた場合に表示されます。
2 つめのセグメントから行がすべて削除され、末尾に 1 行も残ってい
ない場合は、さらに領域を解放することができます。たとえば、セグ
メント DAILY_DATA2 にある残りの 94 行を削除すると、CHECK
TABLE 出力の Segment Statistics セクションには、アクティブ行は 0 で
あると表示されます。
Segment statistics:
active rows:0, deleted rows:0, total blocks:134, free blocks:118
rows/block:264, storage reclen:29, average reclen:NaN, indirect rows:0
max reclen:29, longest rec:0, min reclen:29, shortest rec:8186
freespace:122760, unused RowIDs:3960, unusable freespace:0
しかし、rbw_storage システム テーブルの used 列には、論理的にはま
だ 1064KB が使用されていると表示されています。
RISQL> select substr(seg.name, 1,17) as segname, pseq,
used, totalfree, rowcount
from rbw_segments seg, rbw_storage sto
where tname = 'SALES' and seg.name = sto.segname and
usage = 'TABLE'
order by seg.name;
SEGNAME
PSEQ
USED
TOTALFREE
ROWCOUNT
DAILY_DATA1
1
1024
992
34577
DAILY_DATA1
2
32
992
34577
DAILY_DATA2
1
1024
984
0
DAILY_DATA2
2
40
984
0
次の例では、release storage 操作によりさらに格納領域が解放されます。
RISQL> alter segment DAILY_DATA2 of table sales release storage;
** WARNING ** (6403) 解放されたブロックの割合 : 98.51 %
9-52 Administrator’s Guide
セグメントからの格納領域の解放と削除
5.
手順 4b で行った RELEASE STORAGE 操作の効果を確認します。
a. CHECK TABLE を実行します。
RISQL> check table sales
directory'/qa/local/virginia/check_results/' verbose;
次の CHECK TABLE の出力には、データ ブロックがすべて解放された
ことが現れています。このことは、free blocks フィールドの値が 0 で
あること、segment statistics の真上にある行にある Total data blocks
フィールドの値が 0 であることからわかります。total blocks フィール
ドには、それぞれのセグメントに存在するコントロール ブロックの数
1 が含まれています。
19 nala % more chk_11_22_rep.20020127.180113.15692
Checking Table
...
Expecting:0 active rows in segment
Scanning all active blocks.Total data blocks:0...
Segment statistics:
active rows:0, deleted rows:0, total blocks:1, free blocks:0
rows/block:264, storage reclen:29, average reclen:NaN, indirect rows:0
max reclen:29, longest rec:0, min reclen:29, shortest rec:8186
freespace:0, unused RowIDs:0, unusable freespace:0
b.
rbw_storage システム テーブルの used 列を見ると、論理的に使用され
ているスペースがもう残っていないことが確認できます。used 列を見
ると、セグメント daily_data2 の 2 番目の PSU には 0KB が含まれ、最
初の PSU で使用されているのは、コントロール ブロック用の 8KB だ
けであることがわかります。
RISQL> select substr(seg.name, 1,17) as segname, pseq,
used, totalfree, rowcount
from rbw_segments seg, rbw_storage sto
where tname = 'SALES' and seg.name = sto.segname and
usage = 'TABLE'
order by seg.name;
SEGNAME
PSEQ
USED
TOTALFREE
ROWCOUNT
DAILY_DATA1
1
1024
992
34577
DAILY_DATA1
2
32
992
34577
DAILY_DATA2
1
8
2040
0
DAILY_DATA2
2
0
2040
0
データ ウェアハウスのメンテナンス 9-53
PSU サイズの変更
6.
手順 4 で大量の領域を解放した場合、最後の PSU を daily_data2 セグメン
トから削除できます。
RISQL> alter segment DAILY_DATA2 of table sales release storage;
** WARNING ** (6403) 解放されたブロックの割合 : 98.51%
RISQL> alter segment DAILY_DATA2 of table sales drop last storage;
次のクエリから、最初の PSU だけが daily_data2 セグメントに残っていて、
totalfree 列に残っている領域は手順 5b の時よりも少ないことがわかりま
す。
RISQL> select substr(seg.name, 1,17) as segname, pseq, used,
> totalfree, rowcount
> from rbw_segments seg, rbw_storage sto
> where tname = 'SALES' and seg.name = sto.segname and
>
usage = 'TABLE'
> order by seg.name;
SEGNAME
PSEQ
USED
TOTALFREE
ROWCOUNT
DAILY_DATA1
1
1024
992
34577
DAILY_DATA1
2
32
992
34577
DAILY_DATA2
1
8
1016
0
しかし、手順 3 で十分な領域が解放されなかった場合、次のエラーが表示
されます。
RISQL> alter segment DAILY_DATA2 of table sales release storage;
** WARNING ** (6403) 解放されたブロックの割合 : 0.74%
RISQL> alter segment DAILY_DATA1 of table sales drop last storage;
** ERROR ** (6405) PSU
'/qa/local/virginia/aroma/sales_small_psu2'
には使用中のブロック、または未解放のブロックがあるため、削除できません。
PSU サイズの変更
PSU の MAXSIZE と EXTENDSIZE 値を変更し、データベース テーブル、インデッ
クス、検索条件の変化に対応した効率的なディスク管理を行うことができます。た
とえば、セグメントの領域が不足した場合、セグメントの最後の PSU の MAXSIZE
を変更し、領域を拡張することができます。
セグメントの作成時に割り当てられるディスク領域の初期サイズは、パラメータ
INITSIZE で指定します。INITSIZE のデフォルト値は 16KB です。拡張領域は、PSU
にデータが格納されるときにのみデータベース サーバによって割り当てられ、
EXTENDSIZE で指定した増分の単位 (8 の倍数に切り上げ ) ずつ拡張されます。
EXTENDSIZE のデフォルトは 8KB です。ファイル システムに空き容量があるかぎ
り、PSU は、MAXSIZE の値まで拡大されます。ファイル システムの空き容量がな
くなった場合は、9-33 ページで説明したように、MAXSIZE の値が動的に変更され
ます。
9-54 Administrator’s Guide
セグメント全体の移動
セグメント全体の移動
セグメント全体を別のロケーション ( ディスクから別のディスク、ディスクから光
ディスク、光ディスクからディスクなど ) に移動するには、ALTER SEGMENT ...
MIGRATE TO 文を使用します。ALTER SEGMENT の構文と MIGRATE TO 句の詳細
については、『SQL Reference Guide』を参照してください。
PSU のロケーション変更
データベース テーブル、インデックス、検索条件の変化に対応して PSU のロケー
ションを変更し、ディスク領域を効率的に管理することができます。
PSU のロケーションを変更するには、オペレーティング システムの移動コマンドか
コピー コマンドにより、別の物理ロケーションに移動 ( ファイル名を変更 ) します。
そして、CHANGE PATH オプションによって RBW_STORAGE システム テーブルを
更新して、新しいロケーションを反映させます。これらの操作の実行順序は特に決
まっていません。ファイルを移動してから RBW_STORAGE を更新しても、その反
対でもかまいませんが、操作中は関連テーブルをロックし、ユーザのアクセスを禁
止する必要があります。複数の PSU を移動するときは、データベース全体をロック
し、RBW_STORAGE の更新が完了するまで、処理中の PSU にユーザがアクセスで
きないようにします。
ファイルを移動するときは注意が必要です。特に、ファイル名が似ている同じサイ
ズのファイルを移動する場合は、パスとオブジェクトが正しく対応していないと、
システムが破損する可能性があります。誤ってオブジェクトのパスを変更した場合
は、TMU の実行前か、そのオブジェクトの修正 (INSERT、UPDATE、DELETE) 前
であれば、正しいパスで CHANGE PATH オプションを実行し直して、前の操作を取
り消すことができます。
CHANGE PATH 操作は、絶対パスが含まれるテーブルやデータベースを移動または
コピーする際にも必要です。たとえば、データベースでテーブルを移動する場合、
そのテーブルを構成するすべての PSU を新しいロケーションにコピーし、
CHANGE PATH オプションにより、移動した各 PSU の新規パスを指定します。
セグメントの検証
ALTER SEGMENT...VERIFY オプションを使うと、セグメントが破損している ( アク
セス不能な PSU がある ) かどうかを検証し、破損の原因を解明できます。破損箇所
の修復後、復旧処理の一部として VERIFY オプションを使用し、セグメントが修復
されて PSU にアクセスできることを確認します。VERIFY オプションは実際に破損
を修復したり、セグメントをオンラインにはしません。
データ ウェアハウスのメンテナンス 9-55
セグメントの強制復旧
セグメントの強制復旧
軽度または一時的なエラーにより、セグメントが「破損」とマークされ、物理的な
破損がないのに PSU がアクセスできない場合があります。たとえば、UNIX 上で、
クエリの実行時にファイル システムがマウントされていない場合や、一時的な NFS
エラーが発生した場合は、実際に損傷がなくても、アクセス不能なセグメントが
「破損」とマークされます。
PSU が物理的に完全であることが確実な場合は、FORCE INTACT オプションによ
り、セグメントを強制的に「正常」とマークすることができます。このオプション
は、RBW_SEGMENTS テーブルの INTACT 列を更新して利用不能なセグメントを
「正常」とマークしますが、PSU の物理的損傷の有無は検証しません。PSU の物理
的損傷の検証には VERIFY オプションを使用しますが、実行時間は長くなります。
警告 : FORCE INTACT オプションは、セグメントに異常がないことがわかってい
る場合のみ使用してください。不確かな場合は、VERIFY オプションを使用してく
ださい。
定期的に更新されるデータベースのメンテナン
ス方法
この節では、定期的に更新するデータの 2 つの管理方法について説明します。
■
■
古いセグメントをロールオフし、新しいデータで再使用
新規セグメントを作成し、データベースに追加
この例は、5-41 ページ「定期的に更新されるデータベースの作成」にある例の続き
です。次の図は、この例に使用する各テーブルを示したものです。
Sales テーブル
Period テーブル
Perkey
Month
Year
Quarter
Tri
9-56 Administrator’s Guide
Product テーブル
Prodkey
Prod_desc
Brand
Size
Market テーブル
Mktkey
Mktkey
Market_desc
Market_des
District
c
Region
District
Region
Perkey
Prodkey
Mktkey
Dollars
Weight
データ セグメントおよびインデックス セグメントのロールオフと再使用
2002 年の第 1 四半期にデータベースが作成され、8 つの四半期 (2000 年および 2001
年の全四半期 ) のデータ、ならびに毎週更新される当四半期のデータがロードされ
ているとします。この例で使用されている CREATE 文については、5-41 ページ「定
期的に更新されるデータベースの作成」を参照してください。
現在は、2002 年第 2 四半期の開始直前で、タスクは 2 つです。
■
■
第 2 四半期が開始する前に、2002 年第 2 四半期のデータを格納する新規セ
グメントを追加します。
第 2 四半期の開始後に、2000 年第 1 四半期のデータを削除します。
ヒント：最も過去の四半期のデータを削除する準備ができたら、このセグメント
を保存するか、削除するかを決める必要があります。セグメントを保存しておく
と、このセグメントをテーブルから切り離し、使用したいところに再度アタッチし
て、再利用することができます。セグメントを削除した場合、このセグメントが必
要になったときは、別のセグメントを作成する必要があります。
データ セグメントおよびインデックス セグメントの
ロールオフと再使用
データベースが、常に 9 四半期分のデータを保持するとします。これは、2002 年第
2 四半期のデータを追加するときに 2000 年第 1 四半期のデータを削除しても良いと
いうことです。この節では、s_1q00 データ セグメントおよび star_1q00 インデック
ス セグメントを、2002 年第 2 四半期のデータ エントリおよびインデックス エント
リで再使用する手順を 2 つ示します。
■
■
セグメントを切り離し、次の四半期の新規範囲に入っている値にアタッチ
します。
セグメント範囲を、次の四半期の新規範囲に移動します。
これらの手順は、5-41 ページ「定期的に更新されるデータベースの作成」で説明さ
れているように、データとインデックスが両方とも同様にセグメント化されている
場合のみ有効です。
セグメントを切り離し、次の四半期の新規範囲に入っている値にアタッチ
するには
1.
2.
そのデータを保存しておきたい場合は、TMU を使ってファイルまたは
テープにセグメントをアンロードします。
最も古いデータが格納されているセグメントをオフラインにします。
RISQL> alter segment s_1q00 of table sales offline;
データ ウェアハウスのメンテナンス 9-57
データ セグメントおよびインデックス セグメントのロールオフと再使用
3.
次のステートメントのいずれかを使用して、テーブルからセグメントを切
り離します。この操作を行うとセグメントからすべてのデータが削除され
るので、データが本当に必要ないことを確認するか、上記の手順 1 でこの
データを保存してください。
■ 次のステートメントでは、テーブルセグメントの全ての行と、イン
デックスセグメントで一致するエントリーを削除します。
RISQL> alter segment s_1q00 of table sales detach;
■
次のステートメントでは、テーブルセグメントの全ての行と、指定さ
れたセグメントのみの一致するエントリーを削除します。
RISQL> alter segment s_1q00 of table sales detach
override fullindexcheck on segments (star_1q00);
OVERRIDE FULLINDEXCHECK 句は、s_1q00 データ セグメントに対
応するすべてのインデックス エントリが star_1q00 インデックス セグ
メントに格納されている場合に、DETACH 操作を最適化します。デー
タとインデックスのセグメント化が異なる場合、エラー メッセージが
表示されます。OVERRIDE FULLINDEXCHECK 句を省略すると、
DETACH 操作により、インデックス セグメントがすべてスキャンさ
れ、インデックスの別のセグメントにあるインデックス エントリがす
べて削除されたかどうかが確認されます。
s_1q00 セグメントに格納されているデータが、データベースから削除され
ました。このセグメントはテーブルから切り離されましたが、空のセグメ
ントとして存在し、再使用できます。次のセグメントの下限である s_2q00
が自動的に最低限度の値に変更され、この結果、範囲は次のようになりま
す。
min:DATE'2000-07-01'
4.
最も古いデータに対応するインデックス セグメントをオフラインにしま
す。
RISQL> alter segment star_1q00 of index sales_star offline;
5.
インデックスからインデックス セグメントを切り離します。
RISQL> alter segment star_1q00 of index sales_star detach;
6.
手順 3 の detach table セグメントにより、インデックス セグメントから対応
するエントリがすべて削除されます。したがって、このインデックス セグ
メントは空になるので、無効マークをつける必要はありません。
古いデータ セグメントの名前を変更します。このデータ セグメントには
2002 年第 2 四半期のデータが格納されることになります。
RISQL> alter segment s_1q00 rename s_2q02;
9-58 Administrator’s Guide
データ セグメントおよびインデックス セグメントのロールオフと再使用
7.
古いインデックス セグメントの名前を変更します。
RISQL> alter segment star_1q00 rename star_2q02;
8.
9.
必要に応じてテーブル セグメントとインデックス セグメントを変更しま
す。たとえば、PSU の最大サイズやパスを変更したり、新しい PSU をセグ
メントに追加します。
先頭ディメンジョン テーブルをあらかじめロードしておかなかった場合
は、Period テーブルを変更し、新しい四半期 (2002 年の第 2 四半期 ) 用に
行を追加します。
ヒント：IBM では、将来使用する予定のある行を持つ先頭ディメンジョン テーブ
ルをあらかじめロードしておくことをお勧めします。
Period テーブルには、新しい四半期の日付が格納されなければなりませ
ん。そうでない場合は、Sales テーブルに挿入した新しい行は、参照整合
性違反のため無効になります。Period テーブルの INSERT 文の例は次のと
おりです。
RISQL> insert into period values
(DATE'2002-04-01', 'APR', 2002, 2, 1);
...
RISQL> insert into period values
(DATE'2002-05-01', 'MAY', 2002, 2, 2);
...
RISQL> insert into period values
(DATE'2002-06-01', 'JUN', 2002, 2, 2);
...
TMU を使用して、2002 年の 第 2 四半期のデータを Period テーブルに登録
することもできます。例については、9-60 ページ「新しい期間に範囲を移
動するには」のステップ 5 を参照してください。
10.
11.
ディメンジョン テーブルから選択して、セグメント値が連続する行番号を
持つことを確認し、アタッチのための行番号を取得します。
名前を変更したデータ セグメントをテーブルにアタッチします。
RISQL> alter segment s_2q02 attach to table sales
range (DATE'2002-04-01':DATE'2002-07-01');
s_max セグメントの範囲は、自動的に次のように変更されます。
DATE'2002-07-01':max
アタッチしたセグメントは、自動的にオンラインになります。
データ ウェアハウスのメンテナンス 9-59
データ セグメントおよびインデックス セグメントのロールオフと再使用
12.
名前を変更したデータ セグメントをテーブルにアタッチします。
RISQL> alter segment star_2q02 attach to index sales_star
range (821:899);
13.
STAR インデックスの値は参照されているテーブルの行 ID なので、イン
デックス セグメントをアタッチするには、ALTER SEGMENT 文の RANGE
句に行 ID を指定する必要があります。
これで、TMU または SQL INSERT 文を使って、Sales テーブルに 2002 年第
2 四半期のデータを登録し、対応するインデックス エントリを作成する準
備ができました。
新しい期間に範囲を移動するには
1.
2.
そのデータを保存しておきたい場合は、TMU を使ってファイルまたは
テープにセグメントをアンロードします。
古いデータ セグメントの名前を変更します。このデータ セグメントには
2002 年第 2 四半期のデータが格納されています。
RISQL> alter segment s_1q00 rename s_2q02;
3.
古いインデックス セグメントの名前を変更します。
RISQL> alter segment star_1q00 rename star_2q02;
RISQL> alter segment target_mkt_1q00 rename target_mkt_2q02;
4.
5.
必要に応じてテーブル セグメントとインデックス セグメントを変更しま
す。たとえば、PSU の最大サイズやパスを変更したり、新しい PSU をセグ
メントに追加します。
先頭ディメンジョン テーブルをあらかじめロードしておかなかった場合
は、Period テーブルを変更し、新しい四半期 (2002 年の第 2 四半期 ) 用に
行を追加します。
ヒント：IBM では、将来使用する予定のある行を持つ先頭ディメンジョン テーブ
ルをあらかじめロードしておくことをお勧めします。
Period テーブルには、新しい四半期の日付が格納されなければなりませ
ん。そうでない場合は、Sales テーブルに挿入した新しい行は、参照整合
性違反のため無効になります。
9-60 Administrator’s Guide
データ セグメントおよびインデックス セグメントのロールオフと再使用
Period テーブルをロードするには、TMU load ジョブをセットアップし、実
行します。TMU コントロール ファイルのサンプル period.next.load とデー
タ ファイルのサンプル period.next.txt は次のとおりです。
::::::::::::::
period.next.load
::::::::::::::
load data
inputfile '/aroma/period.next.txt'
append
discardfile '/discards/period_discards'
discards 10
into table period (
perkey position(2:11) date 'YYYY-MM-DD',
month
position(13:17) character,
year
position(18:28) integer external,
quarter position(30:40) integer external,
tri
position(42:52) integer external);
::::::::::::::
period.next.txt
::::::::::::::
2000-04-01 APR 00000002000 00000000002 00000000001
2000-04-02 APR 00000002000 00000000002 00000000001
2000-04-03 APR 00000002000 00000000002 00000000001
2000-04-04 APR 00000002000 00000000002 00000000001
2000-04-05 APR 00000002000 00000000002 00000000001
2000-04-06 APR 00000002000 00000000002 00000000001
2000-04-07 APR 00000002000 00000000002 00000000001
2000-04-08 APR 00000002000 00000000002 00000000001
2000-04-09 APR 00000002000 00000000002 00000000001
2000-04-10 APR 00000002000 00000000002 00000000001
...
次のサンプル TMU コマンドは Period テーブルをロードします。
rb_tmu /qa/local/virginia/aroma_vjp/period.next.load username password
TMU の詳細については、
『Table Management Utility Reference Guide』を参照
してください。
データ ウェアハウスのメンテナンス 9-61
データ セグメントおよびインデックス セグメントのロールオフと再使用
6.
名前を変更したデータ セグメントをテーブルに移動します。
RISQL> alter segment s_2q02 of table sales
range (DATE'2002-04-01':DATE'2002-07-01') move;
RANGE MOVE 句はまず、切り離し処理を行ってセグメントを消去し、隣
のセグメントの範囲 s_2q00 を次の値に変更します。
min :DATE'2001-07-01'
その後、切り離されたセグメントが再度アタッチされ、隣り合うセグメン
トの範囲 s_max が再調整されます。
s_2q02
s_max
DATE'2002-04-01':DATE'2002-07-01'
DATE'2002-07-01':max
テーブル セグメントの範囲を移動すると、RANGE MOVE 操作により、自
動的に対応するローカル インデックス セグメントの範囲が移動されます。
次の rbw_segments のクエリからの抜粋には、5-44 ページから 5-46 ページ
の 図 5-6 から 図 5-8 で作成したセグメント範囲の値を移動した結果が表示
されています。
RISQL> select substr(name, 1,17) as segname, npsus,
>
substr(minkey,1,5) as minkey, substr(maxkey,1,5) as maxkey,
>
totalfree, substr(iname, 1,17) as idxname,
>
substr(usage, 1,5) as usage, rowcount
>
from rbw_segments where tname = 'SALES' order by name;
SEGNAME
NPSUS MINKE MAXKE TOTALFREE IDXNAME
USAGE ROWCOUNT
s_2q02
2 20020 20020
2040 NULL
TABLE
0
s_2q00
2
MIN 20000
1528 NULL
TABLE
16871
s_3q00
2 20000 20001
1504 NULL
TABLE
17551
s_4q00
2 20001 20011
1456 NULL
TABLE
19138
...
star_1q00
1
MIN DEFAU
808 SALES_STAR_IDX
INDEX
NULL
star_2q00
1 DEFAU DEFAU
808 SALES_STAR_IDX
INDEX
NULL
star_3q00
1 DEFAU DEFAU
800 SALES_STAR_IDX
INDEX
NULL
star_4q00
1 DEFAU
MAX
776 SALES_STAR_IDX
INDEX
NULL
...
target_mkt_2q02 1
822
MAX
992 PERKEY_SALES_TIX INDEX
NULL
target_mkt_2q00 1
MIN
181
920 PERKEY_SALES_TIX INDEX
NULL
target_mkt_3q00 1
181
273
912 PERKEY_SALES_TIX INDEX
NULL
target_mkt_4q00 1
273
365
912 PERKEY_SALES_TIX INDEX
NULL
...
前述のクエリの出力にある TOTALFREE 列を見ると、移動したセグメン
ト s_2q02 と target_mkt_2q02 がクリアされたことがわかります。これは、
セグメントの空き容量が移動前よりも大きくなり ( それぞれ、2040 と
992)、ROWCOUNT 列には s_2q02 の値が 0 と表示されているからです。
9-62 Administrator’s Guide
新規セグメントの追加
7.
名前を変更した STAR インデックス セグメントをテーブルに移動します。
RISQL> alter segment star_2q02 of index sales_star
range (821:899) move;
8.
これで、TMU または SQL INSERT 文を使って、Sales テーブルに 2002 年第
2 四半期のデータを登録し、対応するインデックス エントリを作成する準
備ができました。
新規セグメントの追加
2002 年第 2 四半期末には、s_3q02 セグメントと s_max セグメントとの間に新規セグ
メントを追加し、次の四半期のデータを格納する準備をします。未使用の利用可能
なセグメントがないため、セグメントを作成し、Sales テーブルにアタッチする必
要があります。2002 年第 3 四半期のデータを入力すると、作成した新規セグメント
に格納されます。
最も古い四半期のセグメントを削除した場合のように、利用可能なセグメントがあ
る場合は、新規セグメントを作成する必要はなく、再使用できます。
1.
s_3q02 という名前の新規セグメントを作成します。
create segment s_3q02
storage '/disk10/s1' maxsize 200,
storage '/disk10/s2' maxsize 200,
storage '/disk10/s3' maxsize 200;
UNIX
♦
create segment s_3q02
storage 'c:¥disk10¥s1' maxsize 200,
storage 'c:¥disk10¥s2' maxsize 200,
storage 'c:¥disk10¥s3' maxsize 200;
Windows
♦
2.
Period テーブルに Perkey のエントリを追加し、2002 年第 3 四半期のデー
タを作成します。この作業を省略すると、新しい四半期のデータをロード
した時に参照整合性エラーが発生します。例を示します。
insert into period values
(DATE'2002-07-01', 'JULY', 2002, 3, 2);
...
insert into period values
(DATE'2002-08-01', 'AUG', 2002, 3, 2);
...
insert into period values
(DATE'2002-09-01', 'SEPT', 2002, 3, 3);
...
データ ウェアハウスのメンテナンス 9-63
新規セグメントの追加
3.
s_3q02 セグメントを Sales テーブルにアタッチし、2002 年第 3 四半期の
データ範囲を指定します。
alter segment s_3q02 attach to table sales
range (DATE'2002-07-01':DATE'2002-10-01');
s_max セグメントの範囲は、自動的に次のように変更されます。
DATE'2002-10-01':max
4.
アタッチしたセグメントは、自動的にオンラインになります。
star_3q02 という名前で新規インデックス セグメントを作成します。
create segment star_3q02
storage '/disk10/star1' maxsize 200,
storage '/disk10/star2' maxsize 200,
storage '/disk10/star3' maxsize 200;
UNIX
♦
create segment star_3q02
storage 'c:¥disk10¥star1' maxsize 200,
storage 'c:¥disk10¥star2' maxsize 200,
storage 'c:¥disk10¥star3' maxsize 200;
Windows
♦
5.
新規インデックス セグメントを STAR インデックスにアタッチします。
新規セグメントをアタッチするには、次のセグメント仕様の 1 つを使用し
ます。
alter segment star_3q02 attach to index sales_star
range (899:992);
alter segment star_3q02 attach to index sales_star
range like segment (s_3q02);
6.
UNIX
ローカル TARGET インデックスすべてに対して新規セグメントを作成しま
す。次の例は、ある TARGET インデックスに target_mkt_3q02 という新し
いインデックス セグメントを作成する方法です。
create segment target_mkt_3q02
storage '/disk10/target_mkt1' maxsize 200,
storage '/disk10/target_mkt2' maxsize 200,
storage '/disk10/target_mkt3' maxsize 200;
♦
Windows
create segment target_mkt_3q02
storage 'c:¥disk10¥target_mkt1' maxsize 200,
storage 'c:¥disk10¥target_mkt2' maxsize 200,
storage 'c:¥disk10¥target_mkt3' maxsize 200;
♦
9-64 Administrator’s Guide
新規セグメントの追加
7.
新規ローカル インデックス セグメントを TARGET インデックスにアタッ
チします。
alter segment target_mkt_3q02 attach to
index sales_target_mktkey
range like segment (s_3q02);
データと同じセグメント範囲にアタッチできるのは、ローカルとして定義
された TARGET または B-TREE インデックスだけです。
データ ウェアハウスのメンテナンス 9-65
新規セグメントの追加
Sales テーブルの新しいセグメント範囲は、次の図のようになります。
図 9-11
Sales テーブルの新しいセグメント範囲
Sales
s_2q00
min:DATE'2000-07-01'
s_3q00
DATE'2000-07-01:DATE'2001-10-01'
s_4q00
DATE'2000-10-01':DATE'2000-01-01'
s_1q01
DATE'2001-01-01':DATE'2001-04-01'
s_2q01
DATE'-04-072001':DATE'2001-10-01'
s_3q01
DATE'-07-072001':DATE'2001-10-01'
s_4q01
DATE'2001-10-01':DATE'2002-01-01'
s_1q02
DATE'2002-01-01':DATE'2002-04-01'
s_2q02
DATEí2002-04-01':DATEí2002-07-01'
s_3q02
DATE'2002-07-01':DATE'2002-10-01'
s_max
DATE'2002-07-01':max
新規セグメント
このセグメントの
下限が変更され、
上限は変わらない。
これで、新規セグメントにデータをロードできるようになります。標準のロード
か、オフライン ロードが使用できます。
9-66 Administrator’s Guide
古いデータの削除
古いデータの削除
最も古い四半期のデータを削除する必要があります。つまり、s_2q00 セグメントに
格納されている 2000 年第 2 四半期のデータです。
データの削除
1.
2.
そのデータを保存しておきたい場合は、TMU を使ってファイルまたは
テープにセグメントをアンロードします。
s_2q00 セグメントをオフライン モードにします。
alter segment s_2q00 of table sales offline;
3.
これらのステートメントのいずれかを使用して、s_2q00 セグメントを切り
離します。
alter segment s_2q00 of table sales detach;
alter segment s_2q00 of table sales detach
override fullindexcheck on segments (star_2q00);
OVERRIDE FULLINDEXCHECK を使用する場合の注意については、
9-57 ページ「データ セグメントおよびインデックス セグメントのロール
オフと再使用」を参照してください。
s_2q00 セグメントに格納されているデータが、データベースから削除され
ました。このセグメントはテーブルから切り離されましたが、空のセグメ
ントとして存在し、再使用できます。次のセグメント s_3q00 の範囲が自動
的に変更され、切り離したセグメントの下限まで拡張されます。
min:DATE'2000-10-01'
4.
star_2q00 インデックス セグメントを切り離します。
alter segment star_2q00 of index sales_star detach;
5.
これらのセグメントは、再使用できるように保存しても、DROP 文で削除
してもかまいません。
drop segment s_2q00;
drop segment star2q00;
新しい範囲は、次のようになります。
データ ウェアハウスのメンテナンス 9-67
古いデータの削除
図 9-12
Sales テーブルのセグメントとデータの範囲
Sales
s_3q00
min:DATE'2000-10-01'
s_4q00
DATE'2000-10-01':DATE'2001-01-01'
s_1q01
DATE'2001-01-01':DATE'2001-04-01'
s_2q01
DATE'-04-072001':DATE'2001-10-01'
s_3q01
DATE'-07-072001':DATE'2001-10-01'
s_4q01
DATE'2001-10-01':DATE'2002-01-01'
s_1q02
DATE'2002-01-01':DATE'2002-04-01'
s_2q02
DATE'2002-04-01':DATEí2002-07-01'
s_3q02
DATE'2002-07-01':DATE'2002-10-01'
s_max
DATE'2002-10-01':max
9-68 Administrator’s Guide
s_2q00 がテーブルから切り離され、
データベースから削除されます。
次のセグメントは最小範囲を示します。
破損したセグメントの復旧
破損したセグメントの復旧
テーブルやインデックスの操作中に、セグメントが破損しているというメッセージ
が表示されたり、ALTER SEGMENT...VERIFY 文によって破損したセグメントが検
出される場合があります。破損個所がセグメント内の PSU にあると、PSU へ最初に
アクセスしたときに、PSU、セグメント、テーブル、またはインデックスも破損状
態に設定されます。
PSU の不良により、RBW_STORAGE システム テーブルが「破損」とマークされる
のは、以下の理由によります。
■
■
■
ファイルが見つからない。
パーミッションが不十分。
PSU を開いて読み込もうとしたときに、入出力エラーなどのオペレーティ
ング システム エラーが発生したため。ハードウェア障害によりデータ
ベースが破損している場合があります。
一時的な性質の NFS エラーはネットワークへのロードが原因です。このタイプのエ
ラーでは一般にデータベースの破損はありません。
セグメントが破損した場合、破損したセグメントがオンラインの間、テーブルやイ
ンデックスにはアクセスできません。複数のセグメントから構成されるテーブルや
インデックスの場合は、破損したセグメントがあっても、部分的なアクセスは可能
です。破損したセグメントをオフラインにし、破損を修復してください。
破損したセグメントを修復する際は、不良セグメントと原因を特定し、不良箇所を
修復した後で、復旧処理をしてください。
データ ウェアハウスのメンテナンス 9-69
破損したセグメントの復旧
破損したセグメントの修復手順は、次のとおりです。
1.
異常があるセグメントを判定します。
破損したセグメントは、エラー メッセージから判定できます。メッセージ
が表示されなかった場合は、システム テーブルで確認してください。
RBW_TABLES、RBW_INDEXES、RBW_SEGMENTS の各システム テー
ブルには、INTACT という列があります。INTACT 列の値が N の場合は、
テーブル、インデックス、セグメントのいずれかが不良であることを示し
ます。
破損したテーブルまたはインデックスを見つけるには、次のクエリを実行
します。
select name, intact from rbw_tables where intact = 'N';
select name, intact from rbw_indexes where intact ='N';
破損したセグメントを見つけるには、次のようなクエリを実行します。
select name, tname, iname, intact from rbw_segments
where intact = 'N';
2.
PSU に異常がなく、軽度または一時的なエラーによって「破損」とマーク
されたのであれば、( オンライン セグメントとオフライン セグメントの両
方に ) ALTER SEGMENT...FORCE INTACT 文を実行し、セグメントとテー
ブルまたはインデックスを「正常」とマークすることができます。
alter segment <seg_name> of table <table_name> force intact;
alter segment <seg_name> of index <index_name> force intact;
3.
4.
この文は PSU のアクセスや完全性を検証しませんが、PSU に異常がないこ
とが確実な場合は、時間のかかる検証作業を省略できます。
FORCE INTACT オプションを使用した場合は、ステップ 7 に進んでくださ
い。それ以外の場合は、次のステップ 3 に進んでください。
破損したセグメントが、複数セグメントの一部であれば、そのセグメント
をオフラインにして、テーブルやインデックスを部分的に利用できるよう
にするかどうかを決定します。
ALTER SEGMENT...VERIFY 文を使用して、不良の原因を解明します。
alter segment <seg_name> of table <table_name> verify;
alter segment <seg_name> of index <index_name> verify;
5.
9-70 Administrator’s Guide
ALTER SEGMENT...ONLINE 文は、VERIFY オプションと同じ検証タスク
を実行して、同じ情報を返しますが、すでにオンラインであるセグメント
には使用できません。
不良の原因が判明したら、修復処理を行います。PSU ファイルへのアクセ
ス権が不十分である、またはファイルの格納先ディレクトリが誤っている
などが原因の場合は簡単に修復できます。修復が困難または不可能な場合
は、バックアップからのセグメントのリストアか、データベース全体のリ
ストアが必要になることもあります。
光ディスクの管理
6.
7.
ALTER TABLE...VERIFY 文によって不良箇所の修復を確認します。
そのセグメントがオフラインの場合は、ALTER SEGMENT...ONLINE 文に
よって ONLINE にします。
光ディスクの管理
光ディスクは、テープより高速で磁気ディスクより安価な、直接アクセスが可能な
二次格納領域を提供します。光ディスクを使用すると、どれだけのデータをいつま
で格納するかについて、さらに柔軟に判断できるようになります。光ディスクに格
納したデータには、磁気ディスクのデータと同じ方法でアクセスします。アクセス
時間はかかりますが、コストは大幅に低減します。光ディスクは、テープに保存す
るものよりアクセスの頻度が多く、高価な磁気ディスクに格納するものよりアクセ
ス頻度の低いデータを格納するのに適しています。
光ディスクはアクセス時間が長いので、クエリや特定のコマンドが光ディスク上の
データやインデックスを処理対象とするかどうかを指定できます。また、オフライ
ン セグメントの処理と同様に、最適なインデックスを選択する際に、光ディスクに
ある STAR インデックスを考慮するかどうかも指定できます。
データ ウェアハウスのメンテナンス 9-71
光ディスクの割り当て
ここでは、光ディスクについてサポートされる、以下の機能を説明します。
■
■
■
■
光ディスクの割り当て
各種媒体間のセグメントの移動
行データやインデックスが光ディスクに格納されている場合のアクセス動
作の指定 ( パラメータ OPTICAL_AVAILABILITY)
インデックスの選択時に、光ディスクに格納されている STAR インデック
スを考慮するかどうか ( パラメータ IGNORE_OPTICAL_INDEXES) の指定
光ディスクの割り当て
1 つのセグメント全体または特定の PSU を光ディスクに配置するには、光ディスク
へのパスを CREATE SEGMENT 文、または ALTER SEGMENT 文に指定します。
セグメントに光ディスクのプロパティを割り当てるには、OPTICAL ON オプション
を挿入します。
alter segment daily_data1 of table sales optical on;
光ディスクに格納された PSU があるセグメントは、光セグメントと見なされます。
特定のセグメントが光ディスク上のセグメントかどうかを判断するには、セグメン
ト名またはセグメント ID を指定して、RBW_SEGMENTS システム テーブルの
OPTICAL 列の値をチェックします。
select optical from rbw_segments where name = '<seg_name>';
光ディスク上のセグメントの有無を確認するには、RBW_SEGMENTS システム
テーブルを検索します。
select name, id from rbw_segments where optical = 'Y';
9-72 Administrator’s Guide
光ディスク上のセグメントへのアクセス動作
光ディスク上のセグメントへのアクセス動作
OPTICAL_AVAILABILITY オプションは、rbw.config ファイルのエントリ、または
SET コマンドで設定できます。光ディスク上のセグメントに格納されたデータまた
はインデックスにアクセスするクエリやコマンドの動作は、
OPTICAL_AVAILABILITY オプションの設定と、そのクエリやコマンドに読み込み
および書き込み操作が含まれているかどうかに依存します。このオプションの影響
を受ける SQL 文は、次のとおりです。
■
■
読み込み操作 : SELECT 文および TMU の UNLOAD 文
書き込み操作 :
❑ ALTER TABLE 文および DROP TABLE 文
❑ CREATE INDEX 文および ALTER INDEX 文
❑ ALTER SEGMENT 文
❑ INSERT 文、UPDATE 文、DELETE 文
❑ TMU の LOAD DATA 文および REORG 文
光ディスク上のセグメントに対するアクセス動作を設定、または確認するには、次
のようなクエリにより RBW_OPTIONS テーブルの OPTICAL_AVAILABILITY エン
トリを調べます。
select substr(option_name, 1, 30), substr(value, 1, 12)
from rbw_options
where option_name like 'OPTICAL%'
and username = CURRENT_USER;
OPTICAL_AVAILABILITY
WAIT_NONE
すべてのセッションの光ディスク上のセグメントに対するアクセス動作を設定する
には、rbw.config ファイルに次のように記述します。
OPTION OPTICAL_AVAILABILITY INFO
特定のセッションのクエリ動作を指定するには、SET コマンドを実行します。SET
コマンドの構文は次のとおりです。
set optical availability error
光ディスクへのアクセス動作に関する設定の詳細なリストは、『SQL Reference
Guide』を参照してください。
データ ウェアハウスのメンテナンス 9-73
光ディスク上のセグメントでのインデックス選択方法の指定
光ディスク上のセグメントでのインデックス選択方法
の指定
クエリに最適なインデックスを選択する際に、光ディスクに格納されている PSU の
インデックスを考慮するかどうかは、IGNORE_OPTICAL_INDEXES オプションで
指定します。クエリが処理されるときに、光ディスク内のあるインデックスへのア
クセスが、エラー メッセージ、または警告メッセージに表示されたが、ほかのイン
デックスは、最適化の程度が劣っているけれど、完全に利用可能であることがわ
かっているとします。このような場合、IGNORE_OPTICAL_INDEXES オプション
を設定すると、光ディスクに格納されていないインデックスを強制的に使用できま
す。
ヒント：通常、使用頻度の高いインデックスは光ディスク上のセグメントには格
納しません。低速の光デバイスにインデックスを格納すると、インデックスを使う
意味がなくなります。
インデックスの選択時に、光ディスク上のセグメントが考慮されるかを確認するに
は、RBW_OPTIONS システム テーブルの IGNORE_OPTICAL_INDEXES エントリ
を確認します。
select substr(option_name, 1, 30), substr(value, 1, 12)
from rbw_options
where option_name like 'IGNORE_OPTICAL%'
and username = CURRENT_USER;
IGNORE_OPTICAL_INDEXES
OFF
すべてのセッションで光ディスク上のセグメントのインデックスを使用させるに
は、次の構文による設定を rbw.config ファイルに記述します。
OPTION IGNORE _OPTICAL_INDEXES OFF
現在のセッションで光ディスク上のセグメントのインデックスを使用するかどうか
は、SET コマンドで指定します。
set ignore optical indexes off;
デフォルト設定は ON です。
9-74 Administrator’s Guide
テーブルの変更
テーブルの変更
ALTER TABLE 文は、以下の操作に使用できます。
■
■
■
■
■
■
■
■
列の追加または削除
列名の変更
列デフォルト値の変更
テーブルの最大行数 (MAXROWS PER SEGMENT および MAXSEGMENTS)
の変更
削除操作の際の参照整合性を維持する動作の変更
フォーリン キーの追加または削除
VARCHAR 列のフィル ファクタの変更
SERIAL 列の開始値およびステップ値の変更
IBM では、ALTER TABLE コマンドを実行する際は、コマンドの対象となるテーブ
ルと関連するインデックスのバックアップをとるよう推奨しています。また、
ALTER TABLE 操作でテーブルを変更する場合は、変更を CREATE TABLE 文に反映
させ、必要に応じてテーブルを最初から作成し直すことができるようにしておいて
ください。
以下の節では、ALTER TABLE で実行できる操作と、ALTER TABLE の操作が中断し
た場合の復旧方法を説明します。このステートメントの構文の詳細については、
『SQL Reference Guide』を参照してください。
警告 : ALTER TABLE 文は、変更したテーブルを新規セグメントに書き込む IN セ
グメント オプションを使用して、実行するのが最適です。IN_PLACE オプションは
テーブルを同じセグメントに書き込み直します。操作が失敗した場合には、テーブ
ルは混乱状態で取り残されてしまいます。テーブルが大きくてディスク領域が足り
ない場合など、テーブルを元の格納場所で変更するときは、バックアップ コピーを
作成してから操作を実行してください。
データ ウェアハウスのメンテナンス 9-75
列の追加と削除
列の追加と削除
1 つの ALTER TABLE 文で、複数の列を追加または削除できます。
ALTER TABLE...ADD COLUMN で追加した新規列は、テーブルの最後に追加されま
す。複数の列を追加すると、指定した順に追加されます。テーブルに列を追加して
も、ビューには反映されません。ビューの列参照名は、ビューの作成時に解決され
ているからです。
ALTER TABLE...DROP COLUMN で列を削除すると、そのデータがテーブルから削
除されます。この操作を取り消すことはできません。プライマリ キー、フォーリン
キー、インデックス キーを構成する列、あるいはビューが参照している列は削除で
きません。
列を追加、または削除する場合、テーブルの既存のロケーションで変更を指定する
か (IN PLACE)、変更されたテーブルが作成される別のロケーション ( 任意の数のセ
グメント ) を指定できます。ほかのセグメントに再作成すると、修正の完了と同時
に元のテーブルが削除されます。別のロケーションにテーブルを作成すると、操作
が中断されても簡単に復旧できるという利点がありますが、2 つのテーブルを格納
する領域が必要になります。どちらの場合も、変更されたテーブルを格納するだけ
の十分な領域が必要です。
列名の変更
列名を変更するには、ALTER TABLE...ALTER COLUMN...RENAME 文を使用しま
す。新しい列名は、テーブルで一意にしてください。
列のデフォルト値の変更
列のデフォルト値を変更するには、ALTER TABLE...ALTER
COLUMN...SETDEFAULT 文を使用します。デフォルト値とは、入力データが空ま
たは有効な入力値でない場合に列に代入される値のことです。このデフォルト値
は、TMU の Automatic Row Generation オプションにも使用されます。
Automatic Row Generation オプションの詳細については、『Table Management Utility
Reference Guide』を参照してください。
9-76 Administrator’s Guide
MAXSEGMENTS 値と MAXROWS PER SEGMENT 値の変更
MAXSEGMENTS 値と MAXROWS PER SEGMENT
値の変更
MAXSEGMENTS と MAXROWS PER SEGMENT は、1 つのテーブルの最大行数を指
定するパラメータです。これらの値は、STAR インデックスの作成および STAR イ
ンデックスのセグメント化の検証に使用されます。行やセグメントの追加により、
MAXSEGMENTS と MAXROWS PER SEGMENT で指定した最大数を超える場合は、
ALTER TABLE 文を使用してこれらのパラメータの値を大きくしてください。
テーブルがデフォルト セグメントにあると、行の追加に応じてセグメントが拡張さ
れます。名前付きセグメントにある場合は、MAXSEGMENTS と
MAXROWS PER SEGMENT の値を変更する前に、RBW_TABLES システム テーブ
ルでテーブルに対応する MAXSIZE_ROWS の値を確認してください。変更後の
MAXSEGMENTS と MAXROWS PER SEGMENT の積が、MAXSIZE_ROWS の値より
大きいと、変更後の最大行数に達する前に、テーブルがセグメントのサイズを超え
てしまいます。この場合は、ALTER SEGMENT 文を使用して、セグメントの
MAXSIZE を変更してください。
これらのパラメータの設定方法と、セグメントの最大行数に関連したエラーの原因
に関する詳細については、5-22 ページ「MAXSEGMENTS オプションと MAXROWS
PER SEGMENT オプションの設定」を参照してください。
参照整合性を維持する削除動作の変更
テーブルの参照整合性を維持する方法を変更するには、ALTER TABLE...ALTER
COLUMN...ON DELETE 文を使用します。テーブルのフォーリン キーがほかのテー
ブルを参照する場合は、ON DELETE 句によって次のどちらかを指定できます。
■
■
参照先テーブルからの削除をすべての参照元テーブルに反映させるカス
ケード デリート
参照先テーブルと参照元テーブルのどちらについても削除をしない、リス
トリクト デリート
参照整合性とカスケード デリートの詳細については、2-40 ページ「データの削除と
カスケード デリート」を参照してください。
データ ウェアハウスのメンテナンス 9-77
列のデータ型の変更
列のデータ型の変更
列のデータ型を、TINYINT 列から SMALLINT、外部数値データ型から日付データ
型などに変更する必要がある場合があります。
CHAR 列の値の長さが一定していない場合は、データ型を VARCHAR に変更すると
格納領域を縮小できます。VARCHAR 列を使用すると格納領域は小さくなります
が、VARCHAR 列を更新する場合に新規の行が古い行より長ければ、格納の効率が
低下することがあり、その結果、その行への後続のアクセスに時間がかかるように
なります。CHAR データ型は、頻繁に更新される列に使用するようにします。
ヒント：VARCHAR 列のヘッダは CHAR 列のヘッダより 2 バイト長くなります。
VARCHAR は短い列 (6 バイト以下 )、または電話番号のフィールドのように同じ長
さのデータが格納される列には使用すべきではありません。
列のデータ型を変更するには、以下のようにします。
1.
2.
3.
4.
ALTER TABLE 文を使用し、新しいデータ型の列を追加します。テーブル
に使用されていない一意な列名を割り当ててください。
UPDATE 文を使用し、変更する列のデータを新規列にコピーします。
ALTER TABLE 文を使用し、コピー元の列を削除します。
ALTER TABLE 文を使用し、新規列の名前を変更します。
フォーリン キーの追加と削除
参照先テーブルをスキーマに追加したり、スキーマから削除することがあります。
このような操作が行われる理由は数多くあります。たとえば、営業部門の再編成に
より、売上データベースに新しい地域テーブルを追加する必要が生じたり、企業合
併により新製品を扱うことになったため、新しいテーブルが必要になることもあり
ます。追加した新規テーブルを、フォーリン キーによって既存テーブルと関連付け
たい場合は、ALTER TABLE...ADD FOREIGN KEY 操作を既存テーブルで行います。
この文では、テーブルに新しい制約名を追加することもできます。複数列フォーリ
ン キーには必ず重複しない制約名を指定してください。
フォーリン キーを追加するためには、以下の条件を満たす必要があります。
■
■
■
■
■
■
9-78 Administrator’s Guide
参照先テーブルが存在すること
参照先テーブルにプライマリ キー インデックスが存在すること ( このイン
デックスはテーブルの作成時に自動的に作成されます )
フォーリン キーを表す列名が存在すること
列が NOT NULL に設定されていること
参照先列のデータ型とサイズが、参照先テーブルのプライマリ キー列の
データ型とサイズに一致していること
データが参照整合性に違反しないこと
VARCHAR 列のフィル ファクタの変更
フォーリン キーを追加する時にデータが存在している場合は、そのデータの参照整
合性がチェックされます。参照整合性に違反していると、エラーの表示とともに
ALTER TABLE 操作が中止され、テーブルは元の状態に戻されます。大規模なテー
ブルの場合は、参照整合性のチェックに時間がかかることがあります。
同様に、参照先テーブルが不要になり、このテーブルと、テーブルへのフォーリン
キー参照を両方とも削除するとします。ALTER TABLE...DROP CONSTRAINT 操作
を既存テーブルで行います。フォーリン キー制約に STAR インデックスがあると、
ALTER TABLE 文は失敗します。
ALTER TABLE 文の詳細な構文と使用方法は、『SQL Reference Guide』を参照してく
ださい。
VARCHAR 列のフィル ファクタの変更
VARCHAR 列のフィル ファクタを調整するには、ALTER TABLE CHANGE
FILLFACTOR 文を実行します。この SQL 文は、ALTER TABLE 文を実行して列を追
加、または削除し、新規のフィル ファクタでテーブル全体が書き換えられるまでは
有効になりません。
詳細については、5-24 ページ「VARCHAR 列フィル ファクタの設定」を参照してく
ださい。
SERIAL 列の開始値とステップ値の変更
SERIAL 列の開始値とステップ値を変更するには、ALTER TABLE...ALTER
COLUMN...SET SERIAL 文を使用します。新しい開始値 (START) または新しいス
テップ値 (STEP) を指定できます。
開始値を変更すると、現在の最大シリアル値 ( システムが内部に格納 ) は、新しい
開始値から現在のステップ値を差し引いた値に変化します。
警告 : 新しい開始値が、テーブル内の現在の最大シリアル値よりも小さい場合、
自動的に生成されたシリアル値は一意なものでなくなります。
ステップ値を変更した場合、現在の最大シリアル値は変化しません。
開始値とステップ値の両方を変更する場合は、シリアル値が正しく生成されるよ
う、ステップ値を先に変更します。
データ ウェアハウスのメンテナンス 9-79
中断した ALTER TABLE 操作からの復旧
中断した ALTER TABLE 操作からの復旧
ALTER TABLE 操作は完了前に中断される場合があります。復旧方法はいくつかあ
りますが、どの方法を選択するかは、中断の原因とテーブルの変更に IN PLACE オ
プションを使用していたかどうかに依存します。
テーブルの復旧
中断の原因を確認後、中断時のテーブルの状態に応じて以下の復旧方法からいずれ
かを選択してください。
■
■
■
RESUME により変更操作を再開し、完了させます。ALTER TABLE 操作が
かなり処理された後に中断された場合に適しています。
テーブルを元の状態に戻し、同じ ALTER TABLE 文を再実行します。あま
り ALTER TABLE 操作が進まないうちに中断された場合に選択します。た
だし、IN PLACE オプションを使用していた場合は、テーブルを元に戻す
ことはできません。RESUME で操作を再開するか、RESTORE によりバッ
クアップからテーブルをリストアしてください。
バックアップからは、データベース全体をリストアしても、テーブルを格
納しているセグメントだけをリストアしてもかまいません。バックアップ
が最新の状態であれば、ALTER TABLE 文が実行される前の状態にテーブ
ルがリストアされます。最新のバックアップでない場合は、テーブルの状
態が再現されない場合があります。
警告 : IN PLACE オプションを使用してテーブルを変更する場合は、現在のデータ
ベースのバックアップを取ってから、ALTER TABLE 文を実行してください。
9-80 Administrator’s Guide
中断した ALTER TABLE 操作からの復旧
中断 : 原因と防止
中断の原因を次に示します。
■
■
■
特権の違反
特権の違反による中断を防止するには、操作を実行するユーザがファイル
システムの読み込み / 書き込みに必要な特権と、必要なデータベース権限
およびオブジェクト特権を持っていることを確認します。
領域不足エラー
ALTER TABLE 文は、操作に必要な領域を算出します。算出した所要量と、
セグメントに設定された最大領域 ( 各 PSU の MAXSIZE 値を合計した値 )
を比較し、所要量よりも設定値が少ない場合は操作を開始しません。
領域不足エラーによる中断を防止するには、変更するテーブルに必要な領
域を正確に見積り、その領域が実際に利用できることを確認してから
ALTER TABLE 文を実行してください。
領域不足エラーを防止するには、次の点を考慮します。
❑ 定義された最大領域が必ずしも領域に割り当てられるわけではありま
せん。ALTER TABLE 文の計算結果が十分な領域があると示していて
も、実際には一部の領域を利用できないことがあります。セグメント
の作成時には、実際には各 PSU の INITSIZE に指定された領域だけが
割り当てられます。
❑ VARCHAR 列のフィル ファクタはデータベース管理者の見積りによっ
て設定されるため、VARCHAR 列を持つテーブルを格納するセグメン
トの MAXSIZE を設定するときは、超過した場合を考えて領域に余裕
を持たせるようにします。
キャンセル (CTRL-C) コマンド、キル コマンド、システム クラッシュ、電
源不良
これらの原因による中断を防止するのは容易ではありません。不測の事態
が発生することは避けられませんが、予想外の事態にも対応できる体制を
整えてください。システムのバックアップは定期的に行ってください。重
度の障害が発生しても円滑に復旧できるよう、システムのリストア手順を
確立しておくことが必要です。長時間の LOAD 操作のキャンセルは、特に
オペレーティング システムのユーティリティ (UNIX の kill -9 や Windows の
pview など ) を使用した強制的なキャンセルが必要な場合など、どうして
も必要な場合を除いて、行わないようにしてください。このような操作を
行うと、データが整合性のない状態のままになることがあります。
データ ウェアハウスのメンテナンス 9-81
データベースのコピーと移動
データベースのコピーと移動
研修やテストなどのためにデータベースをコピーしたり、別のロケーションに移動
するには、SQL 文、オペレーティング システム、および TMU の各コマンドを組み
合わせる方法があります。
rb_cm ユーティリティを使用すると、データベース間で簡単にデータを移動できま
す。IBM Red Brick Warehouse の異なるバージョンの間で移動するための rb_cm ユー
ティリティは、データが TMU EXTERNAL 形式で転送される場合のみサポートされ
ます。rb_cm ユーティリティの詳細については、
『Table Management Utility Reference
Guide』を参照してください。
警告 : データベースの移動はバージョン ログを使用せずに実行するのが安全です。
データベースにバージョン ログが格納されている場合は、削除してからデータベー
スを移動し、その後再作成します。
互換性
データベースを作成したプラットフォームによっては、同じプラットフォーム上の
ロケーションにしかコピーできない場合があります。たとえば、Solaris プラット
フォームで作成したデータベースは、HP 9000 プラットフォームにコピーまたは移
動することはできず、その逆もできません。32 ビット バージョンの Red Brick サー
バで構築したデータベースは、同じプラットフォームの 64 ビット バージョンにコ
ピーできます。バージョン 6.2 以前の Red Brick サーバでは、32 ビットと 64 ビット
の間に互換性はありません。32 ビットと 64 ビットの互換性がサポートされていな
い Red Brick サーバで作成された、32 ビット バージョン データベースの移動につい
ては、『Installation and Configuration Guide』を参照してください。
異種プラットフォーム間でデータベースをコピーまたは移動する場合は、TMU の
UNLOAD...EXTERNAL 操作を使用してください。元のデータと、UNLOAD
EXTERNAL 操作で生成された CREATE TABLE 文と LOAD DATA 文を使用して、移
動先プラットフォーム上でデータベースを再構築してください。
絶対パスと相対パス
システム テーブルに格納されているパスは、絶対パスまたは相対パスなので、ファ
イルを別のロケーションにコピーしただけでは、パスが元のデータベースではなく
コピーを示すようになるとは限りません。絶対パスは、UNIX の場合はスラッシュ
(/) で、Windows の場合は円記号 (¥) で始まります。スラッシュで始まらないパスは、
すべて相対パスです。データベース サーバは、環境変数 RB_PATH を基準として相
対パスを作成します。RB_PATH が明示的に設定されていない場合は、rbw.config
ファイルのデータベース論理名によって暗黙的に定義されます。
9-82 Administrator’s Guide
絶対パスと相対パス
以下の条件が両方とも真であれば、システム テーブルには相対パスが格納されてい
ます。
■
■
データベースに存在するすべての PSU のパスが CREATE SEGMENT 文で相
対パスで指定されている。
rbw.config ファイルの OPTION DEFAULT_DATA_SEGMENT および OPTION
DEFAULT_INDEX_SEGMENT エントリで指定したロケーションが、相対
パスで指定されている。
逆に、以下のどちらかの条件が真であれば、システム テーブルには絶対パスも格納
されています。
■
■
CREATE SEGMENT 文のどの PSU にも、相対パスでないパスが指定されて
いる。
OPTION DEFAULT_DATA_SEGMENT と OPTION
DEFAULT_INDEX_SEGMENT のどちらかに、相対パスでないパスが指定
されている。
データベースで絶対パスを使用しているかどうかを確認する方法を、次に示しま
す。
select segname, pseq, location from rbw_storage
where substr(location, 1, 1) = '/';
UNIX
♦
select segname, pseq, location from rbw_storage
where substr(location, 1, 2) = ':'
and (substr(location, 1, 3) = '¥' ;
Windows
♦
このステートメントは、絶対パスを使用しているすべての PSU の名前を返します。
コピーまたは移動するデータベースに絶対パスが使用されているかどうかを確認
し、以下の手順に従ってコピーまたは移動を行ってください。
データ ウェアハウスのメンテナンス 9-83
相対パスだけを使用したデータベースのコピー
相対パスだけを使用したデータベースのコピー
相対パスだけを使用したデータベースは、簡単にコピーできます。
1.
2.
3.
4.
移動先のロケーションにデータベースを格納する十分な領域があり、その
ロケーションに対する書き込み許可を redbrick ユーザが持っていることを
確認します。
redbrick ユーザとして、データベースの新規ディレクトリを新規ロケー
ションに作成します。
既存データベース ディレクトリの内容を、新規ディレクトリにコピーしま
す。
コピーしたデータベースの論理名を、rbw.config ファイルに追加します。
絶対パスを使用したデータベースのコピー
絶対パスが使用されているデータベースの場合は、以下に示すどちらかの方法でコ
ピーしてください。
方法 1
この方法は、ファイル名やパスの入力ミスによるデータベースの破壊などが起きに
くい方法です。
1.
2.
3.
4.
5.
6.
TMU の UNLOAD_EXTERNAL コマンドを使い、データベースのレコード
をテープまたはディスクにアンロードします (TMU は、テーブルの再作成
とデータの再ロードに必要な CREATE TABLE、CREATE INDEX、LOAD
DATA 文も作成します )。
移動先のロケーションにデータベースを格納する十分な領域があり、その
ロケーションに対する書き込み許可を redbrick ユーザが持っていることを
確認します。
redbrick ユーザとして、データベースの新規ディレクトリを新規ロケー
ションに作成します。
ステップ 1 で生成された CREATE TABLE 文と CREATE INDEX 文を使い、
テーブルおよびインデックスを新規ディレクトリに再作成します。
ステップ 1 で生成された LOAD DATA 文を使い、新規テーブルにデータを
ロードします。
コピーしたデータベースの論理名を、rbw.config ファイルに追加します。
ヒント：rb_cm ユーティリティを使ってコピーすることもできます。rb_cm ユー
ティリティは、UNLOAD の出力データを LOAD の入力データとしてパイプし、
ネットワークを介してテーブルのデータを移動できるため、テープやディスクへの
書き込みが不要になります。rb_cm ユーティリティの詳細については、『Table
Management Utility Reference Guide』を参照してください。
9-84 Administrator’s Guide
相対パスだけを使用したデータベースの移動
方法 2
この方法は、パスの入力を間違えやすいので注意してください。
1.
2.
3.
4.
5.
6.
移動先のロケーションにデータベースを格納する十分な領域があり、その
ロケーションに対する書き込み許可を redbrick ユーザが持っていることを
確認します。
redbrick ユーザとして、データベースの新規ディレクトリを新規ロケー
ションに作成します。
すべてのファイルを、既存データベースのディレクトリから新規ディレク
トリにコピーします。
絶対パスを持つすべてのファイルを新規ディレクトリにコピーします。
DBA 権限を持つデータベース ユーザか、セグメントの作成者として、
ALTER SEGMENT...CHANGE PATH 文により、絶対パスを持つ各セグメン
トのパスを新規パス ( コピー先のパス ) に変更します。
コピーしたデータベースの論理名を、rbw.config ファイルに追加します。
相対パスだけを使用したデータベースの移動
相対パスだけを使用したデータベースは、簡単に移動できます。
1.
2.
3.
4.
移動先のロケーションにデータベースを格納する十分な領域があり、その
ロケーションに対する書き込み許可を redbrick ユーザが持っていることを
確認します。
redbrick ユーザとして、データベースの新規ディレクトリを新規ロケー
ションに作成します。
すべてのファイルを既存データベース ディレクトリから新規ディレクトリ
にコピーし、元のファイルを削除します。
rbw.config ファイルのデータベース論理名を、新規ロケーションに変更し
ます。
絶対パスを使用したデータベースの移動
絶対パスが使用されているデータベースの場合は、次のどちらかの方法で移動しま
す。
1.
2.
移動先のロケーションにデータベースを格納する十分な領域があり、その
ロケーションに対する書き込み許可を redbrick ユーザが持っていることを
確認します。
redbrick ユーザとして、データベースの新規ディレクトリを新規ロケー
ションに作成します。
データ ウェアハウスのメンテナンス 9-85
rbw.config ファイルのエントリと SET コマンドのパラメータ
3.
4.
5.
6.
7.
cp コマンドを使い、すべてのファイルを既存データベース ディレクトリ
から新規ディレクトリにコピーし、元のファイルを削除します。
絶対パスを持つファイルを現在のロケーションに残しておく場合は、ス
テップ 7 に進んでください。
絶対パスを持つファイルを新規ロケーションに移動する場合は、既存ロ
ケーションから新規ロケーションに各ファイルをコピーし、元のファイル
を削除します。
ステップ 5 で移動した各ファイルについて、DBA 権限を持つデータベース
ユーザか、そのファイルを格納しているセグメントの作成者として、
ALTER SEGMENT...CHANGE PATH コマンドにより、パスを新規ロケー
ションに変更します。
rbw.config ファイルのデータベース論理名を、新規ロケーションに変更し
ます。
rbw.config ファイルのエントリと SET コマン
ドのパラメータ
rbw.config ファイル、または SET コマンドのどちらかを使用して、多くのパラメー
タを設定することができます。rbw.config ファイルのエントリは、データベース
サーバの全セッションに影響を与え、SET コマンドはコマンドを実行したセッショ
ンにのみ適用されます。SQL 文を入力できればどこからでも、対話式にほとんどの
SET コマンドを入力することができます。ウェアハウス ファイル、データベース
ファイル、ユーザの .rbwrc ファイルにも、SET コマンドを入力することができま
す。TMU の SET コマンドは、目標動作の TMU コントロール ファイルに入力しま
す。
rbw.config ファイルに入力した値は、rbwrc ファイルを読み込む前、または TMU の
実行前に処理されるため、.rbwrc ファイルの設定および TMU のコントロール ファ
イルの設定が、rbw.config の設定に優先します。
RBW_OPTIONS システム テーブルには、チューニング可能な全パラメータと現在
の設定値が格納されています。このテーブルは、ユーザ セッション中に SET コマ
ンドで値が変更されると更新されます。
ヒント：この章に示す SET コマンドの構文ダイアグラムでは、終端記号にセミコ
ロン (;) を使用しています。これは、TMU、RISQL エントリ ツール、RISQL レポー
タでは入力が必須ですが、セミコロンを必要としない SQL 入力ツールもあります。
9-86 Administrator’s Guide
構成ファイルの修正
構成ファイルの修正
rbw.config 構成ファイルが、データベース サーバ ソフトウェアのインストール時
に、インストール手順で入力した情報に基づいて作成されます。この情報をデータ
ベース サーバと TMU が使用します。
redbrick ユーザは、サイトの状況の変化に応じて、標準テキスト エディタを使用し
て rbw.config ファイルを編集できます。このファイルの変更は、ファイルを使用す
る各プロセスに影響します。
ヒント：rbw.config ファイルの TUNE で始まるパラメータは、性能に影響を与えま
す。OPTION で始まるパラメータは、サーバの動作に影響を与えます。
rbw.config ファイルの内容と例、SQL 文、または TMU の SET コマンドで設定でき
るパラメータは、付録 B「構成ファイル」を参照してください。
UNIX
その他の必要な操作を確認するには、次の表を参照してください。
変更する項目
必要な操作
SERVER
SHMEM
ウェアハウス デーモンを停止し、再
起動します。ウェアハウス デーモン
の動作中は変更しないでください。
MAX_SERVERS
MAX_ACTIVE_DATABASES
PROCESS_CHECKING_INTERVAL
■ ウェアハウス デーモンを停止しま
す。
■ ipcrm を使用して優先メモリ セグ
メントを削除するか、再起動を行
います。このステップが必要にな
るのは、重大なエラーの発生後の
みです。
■ ウェアハウス デーモンを再起動し
ます。
CLEANUP_SCRIPT
LOGFILE_SIZE
REMOTE_TMU_LISTENER
QUERYPROCS
TOTALQUERYPROCS
ADMIN ADVISOR_LOGGING
READER_PRIORITY
■ ウェアハウス デーモンを停止し、
再起動します。ウェアハウス デー
モンの動作中は変更しないでくだ
さい。
■ ipcrm を使用して優先メモリ セグ
メントを削除するか、再起動を行
います。このステップが必要にな
るのは、重大なエラーの発生後の
みです。
(１/５)
データ ウェアハウスのメンテナンス 9-87
構成ファイルの修正
変更する項目
必要な操作
SERVER_NAME
MESSAGE_DIR
LOCALE
変更しないでください。
INTERVAL
データベース サーバ監視デーモン
(rbw.servermon) を停止し、再起動し
ます。
PERFORMANCE_MONITOR_
MAXOPERATORS
パフォーマンス監視デーモン
(rbwpmond) を停止し、再起動しま
す。
PERFORMANCE_MONITOR_
MAXSESSIONS
BAR_XBSA_LIB
新規ライブラリに対応する格納域マ
ネージャをインストールし、設定し
ます。
BAR_SM_USER
指定されたユーザが格納域マネー
ジャに登録されていない場合は、こ
のユーザを格納域マネージャに登録
してください。
(２/５)
9-88 Administrator’s Guide
構成ファイルの修正
変更する項目
必要な操作
ARITHABORT
COUNT_RESULT
CHECK_TABLE_INDEX_DIRECTORY
CHECK_REPORT_FILE_PERMISSIONS
CROSS_JOIN
EXPORT_DEFAULT_PATH
EXPORT_DELIMITER
EXPORT_MAX_FILE_SIZE
FILE_GROUP
FIRST_DAYOFWEEK
GRANT_TEMP_RESOURCE_TO_ALL
GROUP
INFO_MESSAGE_LIMIT
RBW_LOADINFO_LIMIT
IGNORE_OPTICAL_INDEXES
OPTICAL_AVAILABILITY
ROWCOUNT
ROWS_PER_SCAN_TASK
ROWS_PER_FETCH_TASK
ROWS_PER_JOIN_TASK
ROWS_PER_TARGETJOIN_TASK
FORCE_SCAN_TASKS
FORCE_FETCH_TASKS
FORCE_JOIN_TASKS
FORCE_TARGETJOIN_TASKS
FORCE_HASHJOIN_TASKS
FORCE_AGGREGATION_TASKS
PARTIONED_PARALLEL_AGGREGATION
PARALLEL_SET_OPERATION
TARGETJOIN_LOCAL_PREDICATES
OLAP_APPROXIMATE_NUMERIC_FAST_
COMPUTATION
ALLOW_POSSIBLE_DEADLOCK
DEFAULT_DATA_SEGMENT
DEFAULT_INDEX_SEGMENT
DEFAULT_SEGMENT_SIZE
DEFAULT_PSU_EXTEND_SIZE
TEMPORARY_DATA_SEGMENT
TEMPORARY_INDEX_SEGMENT
操作は不要です。変更は、起動中の
データベース サーバ プロセスには
反映されませんが、新規プロセスに
は反映されます。
(３/５)
データ ウェアハウスのメンテナンス 9-89
構成ファイルの修正
変更する項目
必要な操作
OPTION ADVISOR_LOGGING
PRECOMPUTED_VIEW_QUERY_
REWRITE
UNIFORM_PROBABILITY_FOR_ADVISOR
USE_INVALID_PRECOMPUTED_VIEWS
ADVISOR_MAXIMUM_CANDIDATE_
VIEWS
PRECOMPUTED_VIEW_MAINTENANCE
PRECOMPUTED_VIEW_MAINTENANCE_
ON_ERROR
RANDOM_SAMPLE_MARGIN
ADVISOR_SAMPLE_SIZE
SEGMENTS
IGNORE_PARTIAL_INDEXES
PARTIAL_AVAILABILITY
PERFORMANCE_MONITOR_COMMANDS
QUERY_MEMORY_LIMIT
パラメータ QUERY_TEMPSPACE
操作は不要です。起動中のデータ
ベース サーバ プロセスには変更は
反映されませんが、新規プロセスに
は反映されます。
RESULT_BUFFER
RESULT_BUFFER_FULL_ACTION
VERSIONING
TRANSACTION_ISOLATION_LEVEL
IDLE_TIMEOUT
操作は不要です。起動中のセッショ
ンには変更が反映されませんが、新
規セッションには反映されます。
(４/５)
9-90 Administrator’s Guide
構成ファイルの修正
変更する項目
必要な操作
TMU_ROW_MESSAGES
TMU_BUFFERS
TMU_OPTIMIZE
TMU_CONVERSION_TASKS
TMU_INDEX_TASKS
TMU_SERIAL_MODE
AUTOROWGEN
TMU_VERSIONING
TMU_COMMIT_RECORD_INTERVAL
TMU_COMMIT_TIME_INTERVAL
TMU_MAX_TASKS
TMU_INPUT_TASKS
TMU_MMAP_LIMIT
XML_MAX_TASKS
XML_TEMP_SPACE
操作は不要です。起動中の TMU プ
ロセスには変更は反映されません
が、新規プロセスには反映されま
す。
BAR_UNIT_SIZE
BARTAPE
操作は不要です。起動中のバック
アップ セッションと復旧セッション
(TMU プロセス ) には変更は反映さ
れませんが、新規プロセスには反映
されます。
パラメータ FILLFACTOR
パラメータ INDEX_TEMPSPACE
パラメータ PASSWORD
操作は不要です。起動中のデータ
ベース サーバ プロセスと TMU プロ
セスには変更は反映されませんが、
新規プロセスには反映されます。
パラメータ ADMIN
REPORT_INTERVAL
操作は不要です。起動中のデータ
ベース サーバ プロセスと TMU プロ
セスには変更は反映されませんが、
新規プロセスには反映されます。
パラメータ ADMIN ( その他 )
ウェアハウス デーモンを停止して再
起動するか、ALTER SYSTEM 文を
使用してロギング プロセスおよび管
理プロセスを再起動します。
(５/５)
♦
データ ウェアハウスのメンテナンス 9-91
構成ファイルの修正
Windows
その他の必要な操作を確認するには、次の表を参照してください。
変更する項目
必要な操作
SERVER
MAX_SERVERS
CLEANUP_SCRIPT
LOGFILE_SIZE
REMOTE_TMU_LISTENER
QUERYPROCS
TOTALQUERYPROCS
ADMIN ADVISOR_LOGGING
UNIFIED_LOGON
MAX_ACTIVE_DATABASES
PROCESS_CHECKING_INTERVAL
READER_PRIORITY
コントロールパネルか
らウェアハウス サービ
スを停止し、再起動し
ます。ウェアハウス
サービスの動作中は変
更しないでください。
SERVER_NAME
MESSAGE_DIR
LOCALE
インストール時に設定
します。変更しないで
ください。
PERFORMANCE_MONITOR_MAXOPERATORS
パフォーマンス監視
デーモン (rbwpmond)
を停止し、再起動しま
す。
PERFORMANCE_MONITOR_MAXSESSIONS
BAR_XBSA_LIB
新規ライブラリに対応
する格納域マネージャ
をインストールし、設
定します。
BAR_SM_USER
指定されたユーザが格
納域マネージャに登録
されていない場合は、
このユーザを格納域マ
ネージャに登録してく
ださい。
IDLE_TIMEOUT
操作は不要です。起動
中のセッションには変
更が反映されません
が、新規セッションに
は反映されます。
(１/４)
9-92 Administrator’s Guide
構成ファイルの修正
変更する項目
必要な操作
ARITHABORT
ALLOW_POSSIBLE_DEADLOCK
COUNT_RESULT
CHECK_TABLE_INDEX_DIRECTORY
CHECK_REPORT_FILE_PERMISSIONS
CROSS_JOIN
DEFAULT_DATA_SEGMENT
DEFAULT_INDEX_SEGMENT
DEFAULT_SEGMENT_SIZE
DEFAULT_PSU_EXTEND_SIZE
UNIFORM_PROBABILITY_FOR_ADVISOR
EXPORT_DEFAULT_PATH
EXPORT_DELIMITER
EXPORT_MAX_FILE_SIZE
FIRST_DAYOFWEEK
GRANT_TEMP_RESOURCE_TO_ALL
GROUP
ROWCOUNT
INFO_MESSAGE_LIMIT
RBW_LOADINFO_LIMIT
IGNORE_OPTICAL_INDEXES
OPTICAL_AVAILABILITY
FILE_GROUP
ROWS_PER_SCAN_TASK
ROWS_PER_FETCH_TASK
ROWS_PER_JOIN_TASK
ROWS_PER_TARGETJOIN_TASK
FORCE_SCAN_TASKS
FORCE_FETCH_TASKS
FORCE_JOIN_TASKS
FORCE_HASHJOIN_TASKS
FORCE_TARGETJOIN_TASKS
FORCE_AGGREGATION_TASKS
PARTIONED_PARALLEL_AGGREGATION
PARALLEL_SET_OPERATION
TARGETJOIN_LOCAL_PREDICATES
OLAP_APPROXIMATE_NUMERIC_FAST_
COMPUTATION
TEMPORARY_DATA_SEGMENT
TEMPORARY_INDEX_SEGMENT
操作は不要です。起動
中のデータベース サー
バ スレッドには変更は
反映されませんが、新
規スレッドには反映さ
れます。
(２/４)
データ ウェアハウスのメンテナンス 9-93
構成ファイルの修正
変更する項目
必要な操作
OPTION ADVISOR_LOGGING
PRECOMPUTED_VIEW_QUERY_REWRITE
USE_INVALID_PRECOMPUTED_VIEWS
ADVISOR_MAXIMUM_CANDIDATE_
VIEWS
PRECOMPUTED_VIEW_MAINTENANCE
PRECOMPUTED_VIEW_MAINTENANCE_ON_ERROR
RANDOM_SAMPLE_MARGIN
ADVISOR_SAMPLE_SIZE
SEGMENTS
IGNORE_PARTIAL_INDEXES
PARTIAL_AVAILABILITY
PERFORMANCE_MONITOR_COMMANDS
QUERY_MEMORY_LIMIT
QUERY_TEMPSPACE パラメータ
RESULT_BUFFER
RESULT_BUFFER_FULL_ACTION
VERSIONING
TRANSACTION_ISOLATION_LEVEL
UNIFORM_PROBABILITY_FOR_ADVISOR
操作は不要です。起動
中のデータベース サー
バ スレッドには変更は
反映されませんが、新
規スレッドには反映さ
れます。
TMU_ROW_MESSAGES
TMU_BUFFERS
TMU_OPTIMIZE
TMU_CONVERSION_TASKS
TMU_INDEX_TASKS
TMU_SERIAL_MODE
AUTOROWGEN
TMU_VERSIONING
TMU_COMMIT_RECORD_INTERVAL
TMU_COMMIT_TIME_INTERVAL
TMU_MAX_TASKS
TMU_INPUT_TASKS
TMU_MMAP_LIMIT
XML_MAX_TASKS
XML_TEMP_SPACE
操作は不要です。起動
中の TMU プロセスに
は変更は反映されませ
んが、新規プロセスに
は反映されます。
BAR_XBSA_LIB
新規ライブラリに対応
する格納域マネージャ
をインストールし、設
定します。
(３/４)
9-94 Administrator’s Guide
構成ファイルの修正
変更する項目
必要な操作
BAR_SM_USER
指定されたユーザが格
納域マネージャに登録
されていない場合は、
このユーザを格納域マ
ネージャに登録してく
ださい。
パラメータ FILLFACTOR
パラメータ INDEX_TEMPSPACE
パラメータ PASSWORD
操作は不要です。起動
中のデータベース サー
バ スレッドと TMU プ
ロセスには変更は反映
されませんが、新規ス
レッドと新規プロセス
には反映されます。
パラメータ ADMIN
REPORT_INTERVAL
操作は不要です。変更
は、起動中のスレッド
には反映されません
が、新規スレッドには
反映されます。
パラメータ ADMIN ( その他 )
コントロール パネルか
らウェアハウス サービ
スを停止して再起動す
るか、ALTER
SYSTEM 文を使用して
ロギング スレッドおよ
び管理スレッドを再起
動します。
(４/４)
♦
RBW_OPTIONS システム テーブルには、変更可能な全パラメータの現在の設定値
が格納されています。このテーブルは、SET コマンドによってセッション時に値を
変更した場合、または DBA で rbw.config ファイルを編集した場合に更新されます。
テーブルに表示される値は、現在のセッションに適用される値です。詳細について
は、付録 C「システム テーブルと動的統計テーブル」を参照してください。
データ ウェアハウスのメンテナンス 9-95
データベース サーバの監視と制御
データベース サーバの監視と制御
IBM Red Brick Warehouse には、ウェアハウス デーモンおよびデータベース サーバ
プロセスの監視と制御に役立つ各種ツールが組み込まれています。ログ ファイルの
USAGE ROUTINE イベントを使うと、クエリを監視することもできます。以下の節
ではこれらの監視用ツールについて説明します。その他の監視、および制御の機能
の説明は、第 8 章「組織におけるデータベース運用の管理」を参照してください。
UNIX
UNIX でのデータベース サーバの監視と制御
この節では、データベース サーバ デーモン プロセスの監視と制御の方法、ユーザ
セッションの監視方法、およびデータベース プロセスの監視におけるログ ファイ
ルの使用方法について説明します。
デーモン プロセス
IBM Red Brick Warehouse デーモン プロセス (rbwapid、rbwlogd、rbwadmd) の監視
と制御には、次のスクリプトを使用します。スクリプト、またはこれらを呼び出す
ユーザ定義のスクリプトを実行するには、環境変数 RB_CONFIG に rbw.config ファ
イルが格納されているディレクトリへのパスを設定する必要があります。
スクリプト
説明
rbw.start
rbwapid、rbwlogd、rbwadmd の各デーモンをバックグラウンド プロ
セスとして起動します。rbw.start を実行するには、redbrick ユーザ
としてログインする必要があります。
<redbrick_dir>/bin/rbw.start <config_path> <RB_HOST>
rbw.show
アクティブな rbwapid、rbwlogd、rbwadmd の各デーモンと、関連し
たデータベース サーバ プロセスに関する情報を表示します。
<redbrick_dir>/bin/rbw.show
rbw.stop
rbwapid、rbwlogd、rbwadmd の各デーモンを停止します。rbw.stop
を実行するには、redbrick のユーザとしてログインする必要があり
ます。
<redbrick_dir>/bin/rbw.stop <RB_HOST>
各スクリプトの実行方法と、自動起動の詳細については、『Installation and
Configuration Guide』を参照してください。
9-96 Administrator’s Guide
UNIX でのデータベース サーバの監視と制御
ウェアハウス デーモンが動作中に rbwapid または rbwlogd が停止した場合、停止し
たデーモンの名前をコマンド ラインで入力すると、そのデーモンがウェアハウス
デーモンにより再起動されます。
ウェアハウス デーモンが動作中に管理デーモンが停止した場合、/redbrick/bin ディ
レクトリから rbwadmd 実行可能ファイルを実行して、別に管理デーモンを再起動
します。
管理デーモンを停止させるには、ALTER SYSTEM TERMINATE ADMIN DAEMON
文を使用します。
Findserver ユーティリティ
rbw.findserver (Findserver) ユーティリティを使用すると、特定ユーザのセッション
や、すべてのアクティブなセッションに関する情報を検索することができます。見
つかった各セッションについて、Findserver ユーティリティは次の情報を表示しま
す。
■
■
■
■
ユーザ名
データベース パス
データベース サーバのプロセス ID
ユーザ セッションの開始日時
rbw.findserver プログラムはデータベース サーバ 監視デーモン rbw.servermon とと
もに動作します。Findserver ユーティリティが有効になっている場合、rbw.start ス
クリプトにより rbw.servermon デーモンが自動的に開始され、rbwapid デーモンの
実行中は必ず実行されるようになります。監視デーモンはバックグラウンドで動作
し、アクティブなデータベース サーバ セッションに関する情報をプライベートに
記録します。
起動された rbw.servermon デーモンは、rbwapid デーモンが動作している間は動作
し続けます。rbwapid デーモンが停止すると、rbw.servermon デーモンも次に予定
されている監視ログ ファイルのメンテナンス更新のときに停止します。メンテナン
スの予定は INTERVAL 値によって決定されます。rbw.stop ユーティリティを使って
rbwapid デーモンを停止することもできます。
Findserver の有効化
データベース サーバの監視と Findserver ユーティリティを有効にするには、次の設
定を rbw.config ファイルに記述します。
RBWMON INTERVAL <n>
キーワード RBWMON を使用すると、データベース サーバの監視が有効になりま
す。パラメータ INTERVAL には、監視ログ ファイルを更新する間隔を秒数 (<n>) で
指定します。推奨値は 120 秒です。
データ ウェアハウスのメンテナンス 9-97
UNIX でのデータベース サーバの監視と制御
キーワード RBWMON を rbw.config ファイルに入力しないと、データベース サーバ
の監視は行われず、rbw.findserver ユーティリティも機能しません。キーワード
RBWMON は追加しなければなりません。インストール スクリプトで自動的に追加
されることはありません。
Findserver の使用
rbw.findserver プログラムを redbrick ユーザとして実行し、環境変数 RB_CONFIG
を正しく設定する必要があります。次の構文で起動します。
rbw.findserver [<db_username>]
<db_username> を指定すると、そのユーザのセッションだけが一覧表示されます。
<db_username> を省略すると、すべてのアクティブなセッションが一覧表示されま
す。
ログ ファイル
redbrick ディレクトリにあるログ ファイルを使用すると、各種のデータベース プロ
セスを監視できます。
ファイル
説明
install.log
ソフトウェアの識別番号とデータベース サーバのインストール日
付を記録するファイル。
rbwapid.log
構成情報と、各ウェアハウス デーモンの起動と停止に関する情報
を記録するファイル。ファイルのサイズは、rbw.config ファイルの
パラメータ LOGFILE_SIZE によって制限されます。
rbwacct
rbwlog
<redbrick_dir>/logs ディレクトリにある、動作の詳細とアカウン
ティング情報を記録する 2 進フォーマットの非テキスト ファイル。
IBM テクニカル サービスでもこれらのファイルを使用します。
ログ ファイルに関する詳細については、8-15 ページ「イベントのロギング」を参照
してください。
Vista Advisor 関連のログ ファイルもあります。Advisor ログ ファイルに関する詳細
については、8-29 ページ「Advisor ログ ファイル」を参照してください。
9-98 Administrator’s Guide
Windows でのデータベース サーバの監視と制御
Windows
Windows でのデータベース サーバの監視と制御
IBM Red Brick Warehouse サービスは、データベース サーバのインストール時にイン
ストール プロセスによって自動的に作成されます。その後は、[ コントロール パネ
ル ] の [ サービス ] アイコンからウェアハウス サービスの起動と停止を行えます。
データベース サービス スレッド
サービスが実行されているかぎり、すべてのスレッドも実行されています。
rbwshow.exe スクリプトを使用すると、ホスト名、アクティブな接続の数、および
稼働中のデータベース数を閲覧できます。その他の監視、および制御の機能の説明
は、第 8 章「組織におけるデータベース運用の管理」を参照してください。
Red Brick データベース サービスを停止するには
1.
2.
3.
ALTER SYSTEM QUIESCE 文を使用して、新規接続やコマンドが実行され
ることを防ぎます。
rbwshow.exe スクリプトを使用して、アクティブな接続が存在するかどう
かを確認します。
アクティブな接続が存在しなければ、[ コントロール パネル ] の [ サービ
ス ] アイコンを使用して、データベース サービスを停止します。
管理スレッドを停止させるには、ALTER SYSTEM TERMINATE ADMIN DAEMON
文を使用します。
警告 : データベース サービスを再起動する前に、ログ ビューア ユーティリティ
(logdview) を終了します。ログ ビューアが終了していないと、ログ デーモンが現行
のアクティブ ログ ファイルを使用し続け、ファイルごとの制限は無効になります。
スレッドが停止したときは、コントロールパネルを使用してサービスを再起動しま
す。何らかの理由で IBM Red Brick Warehouse サービスが削除された場合は、インス
トールを実行して新規サービスを自動的に作成するか、レジストリ エディタと
rbwservice ユーティリティを使って新規サービスを手動で作成します。詳細につい
ては、『Installation and Configuration Guide』を参照してください。
データ ウェアハウスのメンテナンス 9-99
バージョン情報の確認
ログ ファイル
redbrick ディレクトリにある各種のログ ファイルを使用すると、Red Brick とそのス
レッドを監視できます。
ファイル
説明
rbwapid.log
コンフィグレーション情報と、各サービスとスレッドの起動と停
止に関する情報を記録するファイル。ファイルのサイズは、
rbw.config ファイルのパラメータ LOGFILE_SIZE によって制限さ
れます。
rbwacct rbwlog
動作の詳細とアカウンティング情報を記録します。ファイルは
<redbrick_dir>¥logs ディレクトリにあり、弊社テクニカル サービ
スでもこれらのファイルを使用します。logdview ユーティリティ
を使用して rbwlog ファイルを読むことができます。
rbwexcept.log
ソフトウェアの例外処理を記録します。このファイルはデバッグ
にのみ使用します。
ログ ファイルに関する詳細については、8-15 ページ「イベントのロギング」を参照
してください。
Vista Advisor 関連のログ ファイルもあります。Advisor ログ ファイルに関する詳細
については、8-29 ページ「Advisor ログ ファイル」を参照してください。
バージョン情報の確認
IBM テクニカル サポートに連絡する場合は、IBM Red Brick Warehouse ソフトウェア
のバージョン情報を確認してください。
データベース サーバのバージョン情報は、以下の方法で確認できます。
■
■
■
rbwapid.log ファイルを参照します。
バージョンは、起動時刻に続くコンフィグレーション情報の最初に表示さ
れます。
RISQL エントリ ツールまたはRISQL レポータのセッションを起動した時に
表示される著作権に関するメッセージを参照します。
SQL 文を直接入力できるツールから、次の SQL 文を入力します。
select rbw_version from rbw_tables ;
同様のクエリをどのテーブルでも実行できます。テーブルの行ごとに、
バージョン番号が 1 行ずつ表示されるため、行数の少ないテーブルを選択
して実行してください。
9-100 Administrator’s Guide
データベース オブジェクトとデータベースの削除
データベース オブジェクトとデータベースの
削除
ユーザの要求の変化にともない、IBM Red Brick Warehouse の既存データベースから
テーブルを削除したり、データベース全体を削除することが必要になることがあり
ます。ここでは、以下について説明します。
■
■
DROP 文により、データベース オブジェクト ( テーブル、インデックス、
ビュー、シノニム、セグメント、マクロ、ロール、階層構造 ) をデータ
ベースから削除する方法
データベースの削除
ヒント：データベースからユーザを削除するには、REVOKE CONNECT 文を使用
します。
データベース オブジェクトの削除
データベース オブジェクトをデータベースから削除するには、以下の SQL DROP 文
を使用します。
■
DROP INDEX
■
DROP HIERARCHY
■
DROP MACRO
■
DROP ROLE ( ユーザ定義のロールのみ )
■
DROP SEGMENT
■
DROP SYNONYM
■
DROP TABLE
■
DROP VIEW
削除するオブジェクトが、他のオブジェクトから参照される場合は、あらかじめ参
照元オブジェクトを削除してください。たとえば、ビューが参照するテーブルを削
除するには、そのビューを先に削除します。同様に、フォーリン キー参照により、
ファクト テーブルがディメンジョン テーブルを参照する場合は、ファクト テーブ
ルを削除してからディメンジョン テーブルを削除します。
テーブルを削除する場合は、テーブルの列やインデックスをあらかじめ削除する必
要はありません。列をテーブルから削除するには、ALTER TABLE 文を使用します。
構文の詳細については、『SQL Reference Guide』を参照してください。
データ ウェアハウスのメンテナンス
9-101
データベース オブジェクトの削除
インデックス
インデックスをデータベースから削除するには、DROP INDEX 文を使用します。
そのインデックスにアタッチしている名前付きセグメントを削除するかどうかも指
定できます。セグメントを残しておくと、インデックスに関連付けられたテーブル
からそのセグメントが切り離され、再利用できるようになります。セグメントを削
除すると、そのセグメントのすべての PSU も削除されます。デフォルト動作では、
名前付きセグメントは削除されません。デフォルト動作をグローバルに無効にする
にはパラメータ SEGMENTS を rbw.config ファイルに設定します。また、ローカル
に無効にするにはパラメータ SEGMENTS を DROP INDEX 文の特定インデックスに
対して設定します。
デフォルト セグメントは、インデックスを削除すると必ず削除されます。
階層構造
階層構造を削除するには、DROP HIERARCHY 文を使用します。テーブル自身を削
除するには、そのテーブルで定義されている階層構造を削除しておく必要がありま
す。階層構造については、『IBM Red Brick Vista User’s Guide』を参照してください。
マクロ
マクロを削除するには、DROP MACRO 文を使用します。データベースとの接続ま
たはデータベース サーバ セッションを終了すると、テンポラリ マクロも削除され
ます。マクロが削除されると、参照してもそのマクロは展開されません。
キーワード PUBLIC と TEMPORARY を、CREATE MACRO 文の場合と同様に DROP
MACRO 文で使用します。
ロール
事前に定義されたシステム ロールである DBA、RESOURCE、CONNECT は削除で
きません。任意のユーザからロールを取り消すことはできます。
システム ロールに加え、ユーザ定義のロールを設定できます。ユーザ定義ロールを
削除するには、DROP ROLE 文を使用します。ロールを削除すると、ロール名が削
除され、そのロールに付与されたすべてのタスク権限、オブジェクト特権、データ
ベース ユーザ、ロールが取り消されます。そのロールのメンバーはタスクや特権を
失いますが、同じタスクや特権を直接または他のロールによって取得していること
があります。
9-102 Administrator’s Guide
データベース オブジェクトの削除
セグメント
セグメントをデータベースから削除するには、DROP SEGMENT 文を使用します。
DROP SEGMENT 文で削除するセグメントは、あらかじめ ALTER SEGMENT 文でオ
フラインにし、さらに切り離しておきます。
セグメントは、以下の方法でテーブルまたはインデックスを削除すると自動的に削
除されます。
■
■
rbw.config ファイルのオプションとして、またはコマンド ラインの SET コ
マンドに対して、パラメータ SEGMENTS を DROP に設定します。
パラメータ SEGMENTS の設定に関する詳細については、5-19 ページ「セ
グメントの作成と削除および部分的に利用可能なテーブルへのクエリ」を
参照してください。
任意のテーブルまたはインデックスについて、DROP INDEX または DROP
TABLE 文に DROPPING SEGMENTS 句を追加します。
セグメントを削除すると、そのセグメントを構成するすべての PSU も削除されま
す。
シノニム
シノニムを削除するには、DROP SYNONYM 文を使用します。このコマンドは、基
本テーブルには無効です。
不要になったシノニムは、削除できます。シノニムを削除する場合は、そのシノニ
ムを参照するテーブルやビューも削除しておくか、これらテーブルやビューを変更
して、シノニムを参照しないようにしておきます。
テーブル
テーブルをデータベースから削除するには、DROP TABLE 文を使用します。テーブ
ルのインデックスと、そのテーブルを参照する特権やシノニムも削除されます。こ
のコマンドは基本テーブルにのみ使用でき、ビューやシノニムには使用できませ
ん。
テーブルにアタッチしている名前付きセグメントを削除するかどうかも指定できま
す。セグメントを残しておくと、テーブルからそのセグメントが切り離され、再利
用できるようになります。セグメントを削除すると、そのセグメントのすべての
PSU も削除されます。デフォルト動作では、名前付きセグメントは削除されませ
ん。デフォルト動作をグローバルに無効にするにはパラメータ SEGMENTS を
rbw.config ファイルに設定します。また、特定テーブルに対してローカルに無効に
するには DROP TABLE 文を設定します。
デフォルト動作は、rbw.config ファイルのパラメータで変更できます。
データ ウェアハウスのメンテナンス
9-103
データベース オブジェクトの削除
ヒント：削除するテーブルに破損したセグメント (RBW_SEGMENTS システム
テーブルに記録 ) が含まれていると、DROP TABLE...KEEPING SEGMENTS 文はエ
ラーになります。テーブルを削除するには、破損したセグメントを切り離して削除
しておく必要があります。ただし、DROP TABLE...DROPPING SEGMENTS 文は、破
損したセグメントがテーブルに含まれていても正常に実行されます。
テーブルを削除する場合は、そのテーブルまたはそのシノニムを参照するほかの
テーブルおよびビューをあらかじめ削除しておきます。
ビュー
通常のビューまたは事前計算ビューをデータベースから削除するには、DROP
VIEW 文を使用します。ビューを削除しても、基本テーブルには影響がありません。
ビューを削除する前に、それを参照するビューを削除する必要があります。事前計
算ビューの詳細については、『IBM Red Brick Vista User’s Guide』を参照してくださ
い。
9-104 Administrator’s Guide
データベースの削除
データベースの削除
データベースを削除するには、UNIX の rb_deleter ユーティリティまたは Windows
の dbcreate ユーティリティを使用します。このユーティリティを使用すると、デー
タベース サーバがデータベース ディレクトリに作成したデフォルト ファイルも削
除されます。通常、このユーティリティはデータベース管理者が redbrick ユーザと
して実行します。
データベース ディレクトリにあるデフォルトの名前でないファイル ( 名前付きファ
イル )、メイン データベース ディレクトリにないディレクトリおよびセグメントの
ファイルは、ユーティリティでは自動的に削除されません。オペレーティング シス
テムのコマンドにより、手動で削除してください。
データベースを削除する場合は、データベースのテーブルやオブジェクトをあらか
じめ削除する必要はありません。ただし、データベース ディレクトリ以外に格納さ
れるセグメントがデータベースに含まれている場合は、DROPPING SEGMENTS オ
プションを指定した DROP TABLE 文を使うと関連した PSU が自動的に削除される
ので、rm コマンド (UNIX)、または del コマンド (Windows) で手動削除せずにすみま
す。
UNIX
UNIX 上のデータベースを削除する
1.
2.
3.
4.
5.
DBA 権限により、データベースにアクセスします。
次の一方または両方を実行します。
■ データベース ディレクトリ以外に格納される PSU を含むテーブルに
ついて、DROP TABLE...DROPPING SEGMENTS を実行します。
■ RBW_STORAGE システム テーブルを参照して、データベース ディレ
クトリ、DEFAULT_DATA_SEGMENT ディレクトリ、
DEFAULT_INDEX_SEGMENT ディレクトリに格納されていない PSU
がないかを調べます。ファイル名を記録しておき、下記のステップ 4
で使用します。
データベースを終了します。
redbrick ユーザとしてログインします。
rb_deleter を起動します。このユーティリティは $RB_CONFIG/bin ディレ
クトリにあります。システム プロンプトで次のコマンドを入力します。
$ rb_deleter <pathname>
<pathname> は、データベース ディレクトリの絶対パス (/disk1/db_sales_92
など ) です。
データ ウェアハウスのメンテナンス
9-105
データベースの削除
6.
7.
8.
オペレーティング システムのコマンド (rm、rmdir) を使用し、以下を削除
します。
■ データベース ディレクトリに残っているファイルやディレクトリ、お
よびデータベース ディレクトリ
■ メイン データベース ディレクトリにないセグメント ディレクトリお
よび PSU( ステップ 1 参照 )。CREATE SEGMENT 文に指定したディレ
クトリ、ならびに rbw.config ファイルの DEFAULT_DATA_SEGMENT
および DEFAULT_INDEX_SEGMENT に指定されたディレクトリを確
認してください。
■ 作成したプロセスが削除しなかったスピル ファイル ( 一時的なファイ
ル )。rbw.config ファイルの QUERY TEMPSPACE DIRECTORY または
INDEX TEMPSPACE DIRECTORY が指定するディレクトリ、あるいは
コマンド ラインから対話形式で指定したディレクトリに存在する場合
があります。
古いデータベース論理名定義を rbw.config ファイルから削除します。
redbrick ユーザとしてログアウトします。♦
9-106 Administrator’s Guide
データベースの削除
Windows
Windows 上のデータベースを削除する手順は、次のとおりです。
1.
2.
3.
4.
DBA 権限により、データベースにアクセスします。
次の一方または両方を実行します。
■ データベース ディレクトリ以外に格納される PSU を含むテーブルに
ついて、DROP TABLE...DROPPING SEGMENTS を実行します。
■ RBW_STORAGE システム テーブルを参照して、データベース ディレ
クトリ、DEFAULT_DATA_SEGMENT ディレクトリ、
DEFAULT_INDEX_SEGMENT ディレクトリに格納されていない PSU
がないかを調べます。ファイル名を記録しておき、下記のステップ 4
で使用します。
データベースを終了します。
データベースを削除するには、dbcreate ユーティリティと、次の構文を使
用します。
dbcreate -delete { [-d <dirname>] | [ -l <logical_dbname>]}
[-q]
-d <dirname>
削除するデータベースを格納しているディレクトリ
の絶対パス
-l <logical_dbname>
rbw.config ファイルで定義された、削除するデータ
ベースの論理名
-q
各ファイルの削除を確認しない無通知モード
たとえば、システム プロンプトから次のように入力します。
c:¥redbrick_dir¥util¥service: dbcreate -delete -l aroma
5.
6.
オペレーティング システムのコマンド (del、erase、rmdir) を使用し、以下
を削除します。
■ データベース ディレクトリに残っているファイルやディレクトリ、お
よびデータベース ディレクトリ
■ メイン データベース ディレクトリにないセグメント ディレクトリお
よび PSU( ステップ 1 参照 )。CREATE SEGMENT 文に指定したディレ
クトリ、ならびに rbw.config ファイルの DEFAULT_DATA_SEGMENT
および DEFAULT_INDEX_SEGMENT に指定されたディレクトリを確
認してください。
■ 作成したプロセスが削除しなかったスピル ファイル ( 一時的なファイ
ル )。rbw.config ファイルの QUERY TEMPSPACE DIRECTORY または
INDEX_TEMPSPACE_DIRECTORY が指定するディレクトリ、あるい
はコマンド ラインから対話形式で指定したディレクトリに存在する場
合があります。
古いデータベース論理名定義を rbw.config ファイルから削除します。♦
データ ウェアハウスのメンテナンス
9-107
付録
例 データベースの作成
この付録では、IBM Red Brick Warehouse に含まれる Aroma というサン
プル データベースを使用してデータベースの作成方法を説明します。
以下について説明します。
■
■
■
■
■
■
■
■
■
■
Aroma データベースの作成
redbrick ユーザとしてログイン
データベース ディレクトリの作成
データベースの作成
デフォルト パスワードの変更
ユーザ テーブルの作成
LOAD DATA 文の作成
データのロード
データベースの検証
まとめ
Aroma データベースの作成
Aroma データベースの作成
この作成例では、データベース スキーマは設計済みであるとし、スキーマの設定手
順を中心に説明します。この例では、IBM Red Brick Warehouse に付属している
Aroma データベースを使います。Aroma は小規模なデータベースなので、ディメン
ジョン ( 参照先 ) テーブルにデフォルト セグメントを使い、参照元 ( ファクト ) テー
ブル Sales に名前付きセグメントを使っています。実際にデータベースを作成する
際は、ディスク領域の所要量、予想されるデータベースの変更、ロードのパターン
を十分に検討し、名前付きセグメントを使うかどうかを決める必要があります。
基本データベース Aroma には、以下の図に示すように Sales、Class、Product、
Market、Store、Promotion、Period の 7 つのテーブルが含まれています。
図 A-1
Aroma データベースのスキーマ
Class
Product
classkey
class_type
class_desc
classkey
prodkey
prod_name
pkg_type
Store
Market
storekey
mktkey
store_type
store_name
street
city
state
zip
mktkey
hq_city
hq_state
district
region
Sales
perkey
classkey
prodkey
storekey
promokey
quantity
dollars
Period
perkey
date
day
week
month
qtr
year
Promotion
promokey
promo_type
promo_desc
value
start_date
end_date
Aroma データベースの詳細については、『SQL Self-Study Guide』を参照してくださ
い。
A-2 Administrator’s Guide
redbrick ディレクトリと Aroma の入力ファイル
redbrick ディレクトリと Aroma の入力ファイル
Aroma データベースの入力ファイルは、IBM Red Brick Warehouse のインストレー
ション キットに組み込まれています。システム上のディレクトリ
<redbrick_dir>/sample_input (UNIX) または <redbrick_dir>¥SAMPLE_INPUT
(Windows) にこれらの入力ファイルをインストールします。<redbrick_dir> はシス
テム上の IBM Red Brick Warehouse ディレクトリです。
以下に説明する手順では、<redbrick_dir>/sample_input、または
<redbrick_dir>¥SAMPLE_INPUT ディレクトリから、管理者が自分のディレクトリ
に作成した aroma_inputs (UNIX)、または AROMA_INPUTS (Windows) というディ
レクトリに、Aroma の入力ファイルをコピーしています。
<redbrick_dir>¥SAMPLE_INPUT ディレクトリから直接使ってもかまいません。付録
A に示したサンプルをもとに、エディタを使って自分のファイルを作成することも
できます。
データベースの作成手順
Aroma データベースを作成する手順は以下のとおりです。
1.
2.
3.
4.
5.
6.
7.
8.
redbrick ユーザとしてログインします。
新規データベースのディレクトリを作成します (OS のコマンドを使用 )。
データベースを作成します (UNIX では rb_creator、Windows では dbcreate
を使用 )。
データベースのデフォルト パスワードを変更します (RISQL Entry Tool、
GRANT 文を使用 )。
データベースのユーザ テーブルを作成します (RISQL Entry Tool、CREATE
TABLE 文を使用 )。
Table Management Utility (TMU) に使用する LOAD DATA 文を記述したコン
トロール ファイルを作成します ( 任意のエディタ )。
データをデータベースにロードします (rb_tmu スクリプトまたは rb_ptmu
スクリプトを使用 )。
データベースが正常に作成され、ロードされたことを検証します。
以下に各ステップを説明します。
例 : データベースの作成
A-3
redbrick ユーザとしてログイン
redbrick ユーザとしてログイン
redbrick ユーザは IBM Red Brick Warehouse の管理アカウントです。データベースの
作成に伴う管理タスクを実行するには、redbrick ユーザとしてログインしてくださ
い。
UNIX
<redbrick_dir>/bin ディレクトリは redbrick ユーザのパスにある必要があります。
redbrick ユーザとしてログインする
1.
2.
redbrick ユーザとしてログインします。アクセス権が正しく設定されるよ
うに、redbrick ユーザとしてデータベースを作成してください。パスワー
ドがわからない場合は、データベース管理者に問い合わせてください。
<redbrick_dir>/bin ディレクトリがパスにあることを確認します。
$ env
表示された環境変数リストで、PATH のエントリを確認し、
<redbrick_dir>/bin が定義されていることを確かめてください。♦
Windows
redbrick ユーザか Windows 管理者が、dbcreate に対する実行許可を任意のユーザに
付与する方法もあります。<redbrick_dir>¥BIN ディレクトリは redbrick ユーザのパ
スにある必要があります。
redbrick ユーザとしてログインする
1.
2.
redbrick ユーザとしてログインします。パスワードがわからない場合は、
データベース管理者に問い合わせてください。
<redbrick_dir>¥BIN ディレクトリがパスに存在していることを確認しま
す。
c:¥> set
表示された環境変数リストで、PATH のエントリを確認し、
<redbrick_dir>¥BIN が定義されていることを確かめてください。♦
A-4 Administrator’s Guide
データベース ディレクトリの作成
データベース ディレクトリの作成
データベースを作成するロケーションを決め、2 つのディレクトリを作成します。1
つはデータベース用、もう 1 つは入力ファイル用です。作成後、Aroma の入力ファ
イルをコピーします。Aroma のスクリプト、入力ファイル、データベースに必要な
ディスク容量は、約 16MB です。
UNIX
データベースを作成する
1.
redbrick ユーザとして、選択したディレクトリ ( この場合は my_directory)
に移動します。以下のように入力してください。
$ cd my_directory
2.
これは、新規データベースの親ディレクトリになります。
親ディレクトリ ( この場合は my _directory) の下に aroma_db というデータ
ベース ディレクトリを作成します。以下のように入力してください。
$ mkdir aroma_db
3.
以下のように入力し、aroma_db ディレクトリのアクセス権が正しく設定
されていることを確認します。
$ ls -dl aroma_db
アクセス権は、少なくとも以下に示すように redbrick ユーザが読み取り
権、書き込み権および実行権を持っている必要があります。
drwx------ aroma_db
4.
group および other のアクセス権は使用環境により異なりますが、ここでは
重要ではありません。
Aroma の入力ファイルに使用する aroma_inputs というディレクトリを作
成します。以下のように入力してください。
$ mkdir aroma_inputs
5.
入力ファイルを別のディレクトリに作成することにより、各ステップで作
成されるファイルが区別しやすくなります。
以下のように入力し、Aroma の入力ファイルを aroma_inputs ディレクト
リにコピーします。
$ cp <redbrick_dir>/sample_input/aroma* aroma_inputs
♦
例 : データベースの作成
A-5
データベース ディレクトリの作成
Windows
データベースを作成する手順
1.
選択したディレクトリ ( この場合は my _directory) に移動します。以下の
ように入力してください。
c:¥> cd my_directory
2.
これは、新規データベースの親ディレクトリになります。
親ディレクトリ ( この場合は my _directory) の下に aroma_db というデータ
ベース ディレクトリを作成します。以下のように入力してください。
c:¥> mkdir aroma_db
3.
Aroma の入力ファイルに使用する aroma_inputs というディレクトリを作
成します。以下のように入力してください。
c:¥> mkdir aroma_inputs
4.
入力ファイルを別のディレクトリに作成することにより、各ステップで作
成されるファイルが区別しやすくなります。
以下のように入力し、Aroma の入力ファイルを aroma_inputs ディレクト
リにコピーします。
c:¥> copy <redbrick_dir>¥sample_input¥aroma*
aroma_inputs
♦
サンプル データベースのディレクトリおよびファイルは、次のようになっていま
す。
redbrick
— sample_input(UNIX), SAMPLE_INPUT(Windows)
aroma.tmu
aroma_class.txt
aroma_create.risql
aroma_deal.txt
aroma_line_items.txt
aroma_market.txt
aroma_orders.txt
aroma_period.txt
aroma_product.txt
A-6 Administrator’s Guide
aroma_promo.txt
aroma_sales.txt
aroma_store.txt
aroma_supplier.txt
my_directory
—aroma_db
—aroma_inputs
図 A-2
サンプル データ
ベース
データベースの作成
データベースの作成
rb_creator スクリプト (UNIX)、または dbcreate スクリプト (Windows) を使用して新
規データベースを作成します。これにより、システム テーブルが作成されます。
rb_creator や dbcreate は redbrick ユーザとして実行してください。
データベースを作成する手順は次のとおりです。
1.
2.
データベース ディレクトリを格納しているディレクトリに移動します。
オペレーティング
システム
コマンド
UNIX
$ cd my_directory
Windows
c:>¥cd my_directory
次のように入力し、スクリプトを実行します。
$ rb_creator aroma_db
UNIX
任意のテキスト エディタを使い、新規データベースの論理名を rbw.config
ファイルに記述します。この例では、Newaroma が新規データベースの名
前です。
DB NEWAROMA /my_directory/aroma_db
♦
c:>¥ dbcreate -create -d aroma_db -l NEWAROMA
Windows
Newaroma という論理名のデータベースが作成され、次の 1 行が
rbw.config ファイルに記述されます。
DB NEWAROMA c:¥my_directory¥aroma_db
♦
3.
Newaroma にアクセスするには、RISQL Entry Tool、RISQL Reporter、また
は TMU のコマンド行で -d オプションを使用します。環境変数 RB_PATH
がデータベースの論理データベース名に設定されている場合は、-d オプ
ションを省略できます。
redbrick アカウントからログアウトします。
rb_creator または dbcreate スクリプトにより、RB_DEFAULT_IDX、RB _DEFAULT
_INDEXES、RB _DEFAULT_LOCKS、RB _DEFAULTS_SEGMENTS、および
RB_DEFAULT_TABLES の各データベース システム ファイルが aroma_db ディレク
トリに作成されます。
例 : データベースの作成
A-7
デフォルト パスワードの変更
デフォルト パスワードの変更
新規データベースには自動的に system という管理アカウントが作成され、デフォル
トのパスワードが manager に設定されています。セキュリティのために、このパス
ワードを変更 ( この例では cryptic) します。
デフォルトのパスワードは、以下の手順で変更します。
1.
2.
3.
<redbrick_dir>/bin ディレクトリ (UNIX)、または <redbrick_dir>¥bin ディ
レクトリ (Windows) がパスに存在していることを確認します。
データベース論理名とデフォルトのユーザ名およびパスワードを使い、
RISQL Entry Tool を起動します。
オペレーティング
システム
コマンド
UNIX
$ risql -d NEWAROMA system manager
Windows
c:¥> risql -d NEWAROMA system manager
RISQL Entry Tool の起動時に、環境変数 RB_CONFIG が構成ファイル
rbw.config のロケーションを示していなければなりません。詳細について
は、『RISQL Entry Tool and RISQL Reporter User’s Guide』を参照してくださ
い。
以下のように入力し、system のパスワードを manager から cryptic に変更し
ます。
RISQL> grant connect to system with cryptic;
RISQL>
ユーザ テーブルの作成
ユーザ テーブルは、データベース スキーマで設計したテーブルおよび列を定義す
る CREATE TABLE 文を作成し、実行することによって作成されます。この例では
デフォルト セグメント、名前付きセグメント、自動インデックス、ユーザ作成イン
デックスを使用します。ビューやシノニムは使用しません。
A-8 Administrator’s Guide
CREATE TABLE 文
CREATE TABLE 文
Aroma データベースのための CREATE TABLE 文が aroma_create.risql ファイルに含
まれています。以下に、Market、Store、Class、Product、Promotion、Period、お
よび Sales の各テーブルを作成する文を示します。
create table market (
mktkey integer not null,
hq_city char(20) not null,
hq_state char(20) not null,
district char(20) not null,
region char(20) not null,
constraint mkt_pkc primary key (mktkey));
create table store (
storekey integer not null,
mktkey integer not null,
store_type char(10) not null,
store_name char(30) not null,
street char(30) not null,
city char(20) not null,
state char(5) not null,
zip char (10) not null,
constraint store_pkc primary key (storekey),
constraint store_fkc foreign key (mktkey)
references market (mktkey))
maxrows per segment 2500;
create table class (
classkey integer not null,
class_type char (12) not null,
class_desc char(60) not null,
primary key (classkey));
create table product (
classkey integer not null,
prodkey integer not null,
prod_name char(30) not null,
pkg_type char(20) not null,
constraint prod_pkc primary key (classkey, prodkey),
constraint prod_fkc foreign key (classkey)
references class (classkey))
maxrows per segment 2500;
create table promotion (
promokey integer not null,
promo_type integer not null,
promo_desc char(40) not null,
value dec(7,2) not null,
例 : データベースの作成
A-9
CREATE TABLE 文
start_date date not null,
end_date date not null,
primary key (promokey))
maxrows per segment 2500;
create table period (
perkey integer not null,
date date not null,
day character(3) not null,
week integer not null,
month character(5) not null,
qtr character(5) not null,
year integer not null,
primary key (perkey))
maxrows per segment 2500;
create table sales (
perkey integer not null,
classkey integer not null,
prodkey integer not null,
storekey integer not null,
promokey integer not null,
quantity integer not null,
dollars dec(7,2) not null,
constraint sales_pkc primary key
(perkey, classkey, prodkey, storekey, promokey),
constraint sales_date_fkc foreign key (perkey)
references period (perkey),
constraint sales_product_fkc foreign key (classkey,
prodkey)
references product (classkey, prodkey),
constraint sales_store_fkc foreign key (storekey)
references store (storekey),
constraint sales_promo_fkc foreign key (promokey)
references promotion (promokey))
data in (daily_data1, daily_data2)
segment by values of (perkey)
ranges (min:415, 415:max)
maxsegments 2
maxrows per segment 60000;
CREATE TABLE 文を使用するときは以下の点に注意してください。
■
■
■
A-10
Administrator’s Guide
参照先テーブルの CREATE TABLE 文は、そのテーブルを参照するテーブ
ルより前に記述します。
参照先テーブルの CREATE TABLE 文には、MAXROWS PER SEGMENT の
値を指定します。
プライマリ キー列とフォーリン キー列は、NOT NULL と設定します。
CREATE TABLE 文
■
■
■
■
Aroma データベースのすべてのテーブルのすべての列を NOT NULL に指
定すると、階層の作成が容易になります。
テーブルの各列は、格納されるデータとデータ型が一致していなければな
りません。Newaroma では、以下のデータ型を使用しています。
❑ CHARACTER。指定した数の文字を格納します。
❑ INTEGER (4 バイト )。
❑ DECIMAL (7,2)。精度は 7、スケールは 2 (4 バイト ) です。
❑ DATE (3 バイト )。
Sales テーブルには、名前付きセグメントを使用します。
その他のテーブルは、すべてデフォルト セグメントを使用します。
データベースの設計と作成の詳細については、第 4 章「ウェアハウス データベース
の物理設計」、および第 5 章「データベースの作成」を参照してください。
CREATE TABLE 構文とデータ型の詳細については、SQL Reference Guide を参照して
ください。
Newaroma のユーザ テーブルを作成するには、次のようにします。
1.
OS のプロンプトで以下のコマンドを入力し、RISQL Entry Tool を起動しま
す。
risql -d NEWAROMA system
2.
データベース論理名とユーザ名を入力します。
プロンプトに対し、パスワードを入力してください。
(C) Copyright IBM Corp. 1991-2002. All rights reserved.
RISQL Reporter Version 06.20.0000(0)
Please type password:
RISQL>
重要 : パスワードのセキュリティを維持するため、パスワードは、コマンド ライ
ンではなく、パスワード プロンプトに入力してください。
例 : データベースの作成 A-11
CREATE TABLE 文
3.
RISQL Entry Tool から、aroma_create.risql ファイルに記述されている文を
読み込み、実行します。以下のように入力してください。
オペレーティ
ング システム
4.
コマンド
UNIX
RISQL> run
/my_directory/aroma_inputs/aroma_create.risql;
Windows
RISQL> run
¥my_directory¥aroma_inputs¥aroma_create.risql;
ステートメントは、コマンド行から対話形式で入力することもできます
が、編集できるファイルから実行する方が簡単で、入力の誤りも少なくな
ります。
aroma_create.risql スクリプトによってテーブルが作成され、テーブルのプ
ライマリ キーに B-TREE インデックスが自動的に作成されます。さらに、
Sales テーブルのセグメントが作成され、Sales テーブルのプライマリ キー
の B-TREE インデックスがドロップされ、STAR インデックスと TARGET
インデックスが作成されます。以下のステップでは、テーブルが正しく作
成されたことを検証し、今後の管理操作に必要なテーブルおよびインデッ
クスの情報を検索する方法を説明します。
テーブルが作成されたことを検証するには、システム テーブル
RBW_TABLES を検索します。次のような SQL 文を入力してください。
RISQL> select * from rbw_tables where id > 0;
A-12
Administrator’s Guide
CREATE TABLE 文
テーブルが作成された場合は、以下のような結果が表示されます。ほか
に、DATETIME、SEGMENT_BY、PARTIAL、COMMENT の各列が表示
され、行がラップします。
RISQL> select * from rbw_tables where id > 0;
Or
RISQL> select substr(name,1,11)as NAME, type, substr(creator,1,7) as CREATOR, id,
maxsegments, maxrows_per_seg, maxsize_rows, intact from rbw_tables where id > 0;
NAME
DEAL
ORDERS
SALES
PERIOD
SUPPLIER
STORE
PROMOTION
PRODUCT
LINE_ITEMS
CLASS
MARKET
TYPE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
TABLE
CREATOR
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
SYSTEM
5.
ID
6
9
11
8
7
2
5
4
10
3
1
MAXSEGMENTS MAXROWS_PER MAXSIZE_ROW INTA
1
NULL
38797016 Y
1
2000
24641348 Y
2
60000
134640 Y
1
2500
69205488 Y
1
NULL
17563514 Y
1
2500
18087798 Y
1
2500
35127028 Y
1
2500
35127028 Y
1
2000
61079086 Y
1
NULL
27000626 Y
1
NULL
24641348 Y
この実行結果について、次のことに注意してください。
■ ID> 0 を指定したので、システム テーブルが除外されています。
■ MAXROWS PER SEGMENT および MAXSEGMENTS の値は、テーブル
ごとに設定されています。
次のように入力し、インデックスが自動的に作成されていることを検証し
てください。
RISQL> select * from rbw_indexes ;
例 : データベースの作成
A-13
CREATE TABLE 文
インデックスが作成された場合は、以下のような結果が表示されます。ほ
かに、DATETIME、INTACT、PARTIAL、COMMENT の各列が表示され
ます ( 行がラップすることがあります )。
RISQL> select * from rbw_indexes;
Or
RISQL> select substr(name,1,19) as NAME, substr(tname,1,10) as TNAME, type,
substr(cname,1,11) as COLUMN_NAME, substr(creator,1,7) as CREATOR, fillfactor, state
from rbw_indexes;
NAME
TNAME
TYPE
COLUMN_NAME CREATOR FILLFACTOR STATE
MARKET_PK_IDX
MARKET
BTREE
MKTKEY
SYSTEM
100
VALID
STORE_PK_IDX
STORE
BTREE
STOREKEY
SYSTEM
100
VALID
CLASS_PK_IDX
CLASS
BTREE
CLASSKEY
SYSTEM
100
VALID
PRODUCT_PK_IDX
PRODUCT
BTREE
CLASSKEY
SYSTEM
100
VALID
PROMOTION_PK_IDX
PROMOTION BTREE
PROMOKEY
SYSTEM
100
VALID
DEAL_PK_IDX
DEAL
BTREE
DEALKEY
SYSTEM
100
VALID
SUPPLIER_PK_IDX
SUPPLIER
BTREE
SUPKEY
SYSTEM
100
VALID
PERIOD_PK_IDX
PERIOD
BTREE
PERKEY
SYSTEM
100
VALID
ORDERS_PK_IDX
ORDERS
BTREE
ORDER_NO
SYSTEM
100
VALID
LINE_ITEMS_PK_IDX
LINE_ITEMS BTREE
ORDER_NO
SYSTEM
100
VALID
SALES_STAR_IDX
SALES
STAR
PERKEY
SYSTEM
100
VALID
STORE_TGT_IDX
STORE
TARGETS STORE_TYPE SYSTEM
100
VALID
STORE_FK_IDX
STORE
BTREE
MKTKEY
SYSTEM
100
VALID
PRODUCT_FK_IDX
PRODUCT
BTREE
CLASSKEY
SYSTEM
100
VALID
ORDERS_FK1_IDX
ORDERS
BTREE
PERKEY
SYSTEM
100
VALID
ORDERS_FK2_IDX
ORDERS
BTREE
SUPKEY
SYSTEM
100
VALID
ORDERS_FK3_IDX
ORDERS
BTREE
DEALKEY
SYSTEM
100
VALID
LINE_ITEMS_STAR_IDX LINE_ITEMS STAR
ORDER_NO
SYSTEM
100
VALID
インデックスを作成するときは次の点に注意してください。
■ プライマリ キーの B-TREE インデックスは、テーブルの作成時に自動
的に作成されます。
■ ほかのインデックスは、aroma_create.risql ファイルに記述されている
CREATE INDEX 文によって作成されます。
■ Sales テーブル以外のテーブルはそれぞれプライマリ キーの B-TREE
インデックスを持っています。Sales テーブルのプライマリ キー イン
デックスは、aroma_create.risql ファイルによってドロップされていま
す。Sales テーブルは、フォーリン キーに STAR インデックスが作成
されています。Store テーブルは、Store_Type に TARGET インデック
スが作成されています。
A-14
Administrator’s Guide
CREATE TABLE 文
6.
データベース ディレクトリを調べて、作成されたファイルを確認します。
オペレーティ
ング システム
コマンド
UNIX
RISQL>!ls /my_directory/aroma_db ;
Windows
RISQL>!dir /w ¥my_directory¥aroma_db ;
感嘆符 (!) は、UNIX ではシステム シェルを、Windows では MS-DOS シェ
ルを起動するエスケープ記号です。次のような一覧が表示されます。
RB_DEFAULT_IDX
RB_DEFAULT_INDEXES
RB_DEFAULT_LOCKS
RB_DEFAULT_SEGMENTS
RB_DEFAULT_TABLES
dfltseg10_psu1
dfltseg11_psu1
dfltseg12_psu1
dfltseg13_psu1
dfltseg14_psu1
dfltseg15_psu1
dfltseg16_psu1
dfltseg17_psu1
dfltseg18_psu1
dfltseg19_psu1
dfltseg1_psu1
dfltseg20_psu1
dfltseg21_psu1
dfltseg22_psu1
dfltseg23_psu1
dfltseg24_psu1
dfltseg25_psu1
dfltseg26_psu1
dfltseg27_psu1
dfltseg28_psu1
dfltseg2_psu1
dfltseg31_psu1
dfltseg32_psu1
dfltseg3_psu1
dfltseg4_psu1
dfltseg5_psu1
dfltseg6_psu1
dfltseg7_psu1
dfltseg8_psu1
dfltseg9_psu1
sales_psu1
sales_psu2
sales_psu3
sales_psu4
テーブルとインデックスにデフォルト セグメントを使用しないと、
CREATE SEGMENT 文で指定したロケーション ( または rbw.config ファイ
ルで指定したデフォルト ディレクトリ ) に PSU が作成されます。Sales
テーブルの PSU も、このディレクトリにあります。これは、スクリプト実
行時のデフォルト ディレクトリにセグメントを作成するように、aroma
_create.risql ファイルの CREATE SEGMENT 文が指定しているからです。
例 : データベースの作成
A-15
CREATE TABLE 文
7.
次のように入力し、各セグメントがどのテーブルまたはインデックスに所
属しているかを確認できます。
RISQL> select name, tname, iname, NPSUS from
rbw_segments;
次のような結果が表示されます。行がラップすることがあります。
RISQL> select name, tname, iname, npsus from rbw_segments;
Or
RISQL> select substr(name, 1,20) as name, substr(tname,1,17) as tname,
substr(iname, 1,22) as iname, NPSUS from rbw_segments;
NAME
TNAME
INAME
NPSUS
RBW_SYSTEM
NULL
NULL
5
DEFAULT_SEGMENT_1
MARKET
NULL
1
DEFAULT_SEGMENT_2
MARKET
MARKET_PK_IDX
1
DEFAULT_SEGMENT_3
STORE
NULL
1
DEFAULT_SEGMENT_4
STORE
STORE_PK_IDX
1
DEFAULT_SEGMENT_5
CLASS
NULL
1
DEFAULT_SEGMENT_6
CLASS
CLASS_PK_IDX
1
DEFAULT_SEGMENT_7
PRODUCT
NULL
1
DEFAULT_SEGMENT_8
PRODUCT
PRODUCT_PK_IDX
1
DEFAULT_SEGMENT_9
PROMOTION
NULL
1
DEFAULT_SEGMENT_10
PROMOTION
PROMOTION_PK_IDX
1
DEFAULT_SEGMENT_11
DEAL
NULL
1
DEFAULT_SEGMENT_12
DEAL
DEAL_PK_IDX
1
DEFAULT_SEGMENT_13
SUPPLIER
NULL
1
DEFAULT_SEGMENT_14
SUPPLIER
SUPPLIER_PK_IDX
1
DEFAULT_SEGMENT_15
PERIOD
NULL
1
DEFAULT_SEGMENT_16
PERIOD
PERIOD_PK_IDX
1
DEFAULT_SEGMENT_17
ORDERS
NULL
1
DEFAULT_SEGMENT_18
ORDERS
ORDERS_PK_IDX
1
DEFAULT_SEGMENT_19
LINE_ITEMS
NULL
1
DEFAULT_SEGMENT_20
LINE_ITEMS
LINE_ITEMS_PK_IDX
1
DAILY_DATA1
SALES
NULL
2
DAILY_DATA2
SALES
NULL
2
DEFAULT_SEGMENT_23
SALES
SALES_STAR_IDX
1
DEFAULT_SEGMENT_24
STORE
STORE_TGT_IDX
1
DEFAULT_SEGMENT_25
STORE
STORE_FK_IDX
1
DEFAULT_SEGMENT_26
PRODUCT
PRODUCT_FK_IDX
1
DEFAULT_SEGMENT_27
ORDERS
ORDERS_FK1_IDX
1
DEFAULT_SEGMENT_28
ORDERS
ORDERS_FK2_IDX
1
DEFAULT_SEGMENT_29
ORDERS
ORDERS_FK3_IDX
1
DEFAULT_SEGMENT_30
LINE_ITEMS
LINE_ITEMS_STAR_IDX
1
RISQL>
A-16
Administrator’s Guide
LOAD DATA 文の作成
セグメントを作成するときは次の点に注意してください。
■ Sales テーブルを除き、どのテーブルにもデフォルト セグメントが使
用されています。これらのセグメントの名前には、システムによって
自動的に数値サフィックスが割り当てられます。CREATE SEGMENT
文と CREATE TABLE 文は Sales テーブルのセグメントを指定します。
■ 各 PSU に関する詳細は、RBW_STORAGE システム テーブルに格納さ
れています。
LOAD DATA 文の作成
TMU は LOAD DATA 文により入力レコードの各フィールドから入力データを読み込
み、テーブルの対応する列にマッピングします。テーブルごとに、入力ファイルと
レコードのフォーマットおよびテーブル定義に基づいた LOAD DATA 文が 1 つずつ
必要です。この例では、すべての入力データがオペレーティング システムのディス
ク ( テープでない ) ファイルに格納されているとしています。
1 つのコントロール ファイルに複数の LOAD DATA 文を記述しても、テーブルごと
に別のファイルに記述してもかまいません。Aroma データベースの場合は、全ての
テーブルに対応する LOAD DATA 文が、aroma.tmu という 1 つのファイルに記述さ
れています。
この節では、データおよび CREATE TABLE 文、ならびに Newaroma の Period、
Product、Market、Sales の各テーブルに対応する LOAD DATA 文を示します。この
例では、LOAD DATA 文がすでに記述されているファイルを使用しますから、自分
で作成する必要はありません。このファイルの LOAD DATA 文により、入力データ
と CREATE TABLE 文がどのように対応しているかを理解してください。
Period テーブル
Period テーブルの入力データのレコードは、aroma _period.txt ファイルにあり、各
レコードの内容は以下のとおりです。
1*1998-01-01*SA*1*JAN*Q1_98*1998
2*1998-01-02*SU*2*JAN*Q1_98*1998
3*1998-01-03*MO*2*JAN*Q1_98*1998
4*1998-01-04*TU*2*JAN*Q1_98*1998
5*1998-01-05*WE*2*JAN*Q1_98*1998
6*1998-01-06*TH*2*JAN*Q1_98*1998
7*1998-01-07*FR*2*JAN*Q1_98*1998
8*1998-01-08*SA*2*JAN*Q1_98*1998
9*1998-01-09*SU*3*JAN*Q1_98*1998
10*1998-01-10*MO*3*JAN*Q1_98*1998
例 : データベースの作成
A-17
Period テーブル
11*1998-01-11*TU*3*JAN*Q1_98*1998
12*1998-01-12*WE*3*JAN*Q1_98*1998
13*1998-01-13*TH*3*JAN*Q1_98*1998
14*1998-01-14*FR*3*JAN*Q1_98*1998
15*1998-01-15*SA*3*JAN*Q1_98*1998
16*1998-01-16*SU*4*JAN*Q1_98*1998
...
上記は、入力レコードの一部です。
入力データを格納する Period テーブルは、以下の CREATE TABLE 文で定義されて
います。
create table period (
perkey integer not null,
date date not null,
day character(3) not null,
week integer not null,
month character(5) not null,
qtr character(5) not null,
year integer not null,
primary key (perkey))
maxrows per segment 2500;
入力データのレコードを読み込み、Period テーブルの対応する行の列に各フィール
ドをマッピングする LOAD DATA 文は、以下のとおりです。
load data inputfile 'aroma_period.txt'
replace
format separated by '*'
into table period (
perkey integer external (4),
date date 'YYYY-MM-DD',
day char(3),
week integer external (4),
month char(5),
qtr char(5),
year integer external);
Period テーブルの LOAD DATA 文については以下の点に注意してください。
■
■
■
■
A-18
Administrator’s Guide
レコードには、アスタリスク (*) を区切り記号とする区切り記号付き
フォーマットが使用されています。
ロード操作は、REPLACE モードで実行されます。テーブルの既存データ
は、破棄されます。
先頭フィールドはフィールド型が外部整数 (integer external) 型で、長さが
4 文字に設定されており、Period テーブルの Perkey 列に格納されます。
2 番目のフィールドはフィールド型が日付 (date) 型で、年を 4 桁で表し、
月と日を 2 桁ずつで表すフォーマット マスクが設定されています。サブ
フィールドは、ダッシュ (-) で区切られています。
Product テーブル
■
3 番目のフィールドはフィールド型が文字列 (character) 型で、長さが 3 文
字に設定されており、Period テーブルの Day 列に格納されます。
Product テーブル
Product テーブルの入力データのレコードは aroma_product.txt ファイルにあり、各
レコードの内容は以下のとおりです。
1:00:Veracruzano :No pkg
1:01:Xalapa Lapa :No pkg
1:10:Colombiano :No pkg
1:11:Expresso XO :No pkg
1:12:La Antigua :No pkg
1:20:Lotta Latte :No pkg
1:21:Cafe Au Lait:No pkg
1:22:NA Lite :No pkg
1:30:Aroma Roma :No pkg
1:31:Demitasse Ms:No pkg
2:00:Darjeeling Number 1 :No pkg
2:01:Darjeeling Special :No pkg
2:10:Assam Grade A :No pkg
2:11:Assam Gold Blend :No pkg
2:12:Earl Grey:No pkg
上記は、入力レコードの一部です。
入力データを格納する Product テーブルは、以下の CREATE TABLE 文で定義されて
います。
create table product (
classkey integer not null,
prodkey integer not null,
prod_name char(30) not null,
pkg_type char(20) not null,
constraint prod_pkc primary key (classkey, prodkey),
constraint prod_fkc foreign key (classkey)
references class (classkey))
maxrows per segment 2500;
例 : データベースの作成
A-19
Market テーブル
入力データのレコードを読み込み、Product テーブルの対応する行の列に各フィー
ルドをマッピングする LOAD DATA 文は、以下のとおりです。
load data
inputfile 'aroma_product.txt'
replace
format separated by ':'
discardfile 'product.discards'
discards 1
into table product (
classkey integer external(2),
prodkey integer external(2),
prod_name char(30),
pkg_type char(20)) ;
Product テーブルの LOAD DATA 文については以下の点に注意してください。
■
■
■
データ レコードには、コロン (:) を区切り記号とする区切り記号付き
フォーマットが使用されています。
product.discards という名前のファイルに破棄レコードが書き込まれます。
レコードが 1 つ破棄されると、TMU が終了します。
データ型は、character と external だけが使用されています。各フィールド
にはパラメータ length が指定されていますが、区切り記号付きフォーマッ
トのレコードでは無視されます。
Market テーブル
Market テーブルの入力データのレコードは aroma_market.txt ファイルにあり、各
レコードの内容は以下のとおりです。
01*Atlanta*GA*Atlanta*South
02*Miami*FL*Atlanta*South
03*New Orleans*LA*New Orleans*South
04*Houston*TX*New Orleans*South
05*New York*NY*New York*North
06*Philadelphia*PA*New York*North
07*Boston*MA*Boston*North
08*Hartford*CT*Boston*North
09*Chicago*IL*Chicago*Central
10*Detroit*MI*Chicago*Central
11*Minneapolis*MN*Minneapolis*Central
12*Milwaukee*WI*Minneapolis*Central
14*San Jose*CA*San Francisco*West
15*San Francisco*CA*San Francisco*West
16*Oakland*CA*San Francisco*West
17*Los Angeles*CA*Los Angeles*West
19*Phoenix*AZ*Los Angeles*West
上記は、入力レコードの一部です。
A-20
Administrator’s Guide
Market テーブル
上記の入力データを格納する Market テーブルは、以下の CREATE TABLE 文で定義
されています。
create table market (
mktkey integer not null,
hq_city char(20) not null,
hq_state char(20) not null,
district char(20) not null,
region char(20) not null,
constraint mkt_pkc primary key (mktkey));
入力データのレコードを読み込み、Market テーブルの対応する行の列に各フィー
ルドをマッピングする LOAD DATA 文は、以下のとおりです。
load data
inputfile 'aroma_market.txt'
replace
format separated by '*'
discardfile 'market.discards'
discards 1
into table market (
mktkey integer external(2),
hq_city char(20),
hq_state char(2),
district char(13),
region char(7)) ;
Market テーブルの LOAD DATA 文には RECORDLEN 句が指定されていないので、
TMU は改行文字を区切り記号とする可変長レコードを処理することができます。
例 : データベースの作成
A-21
Sales テーブル
Sales テーブル
Sales テーブルの入力データのレコードは aroma_sales.txt ファイルにあり、各レ
コードの内容は以下のとおりです。
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000004
00000000001
00000000002
00000000005
00000000001
00000000001
00000000004
00000000004
00000000002
00000000004
00000000005
00000000004
00000000002
00000000001
00000000006
00000000005
00000000000
00000000012
00000000011
00000000030
00000000022
00000000030
00000000010
00000000010
00000000011
00000000022
00000000000
00000000000
00000000030
00000000010
00000000022
00000000046
00000000012
00000000001
00000000001
00000000001
00000000001
00000000001
00000000001
00000000001
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000002
00000000003
00000000003
00000000003
00000000116
00000000116
00000000116
00000000116
00000000116
00000000116
00000000116
00000000000
00000000000
00000000000
00000000000
00000000000
00000000000
00000000000
00000000000
00000000000
00000000000
上記は、入力レコードの一部です。
A-22
Administrator’s Guide
00000000008
00000000009
00000000040
00000000016
00000000011
00000000030
00000000025
00000000012
00000000014
00000000018
00000000017
00000000013
00000000014
00000000018
00000000011
00000000006
00000000010
000000034.00
000000060.75
000000270.00
000000036.00
000000030.25
000000187.50
000000143.75
000000087.00
000000115.50
000000058.50
000000136.00
000000074.75
000000101.50
000000063.00
000000099.00
000000036.00
000000040.00
Sales テーブル
入力データを格納する Sales テーブルは、以下の CREATE TABLE 文で定義されてい
ます。
create table sales (
perkey integer not null,
classkey integer not null,
prodkey integer not null,
storekey integer not null,
promokey integer not null,
quantity integer not null,
dollars dec(7,2) not null,
constraint sales_pkc primary key
(perkey, classkey, prodkey, storekey, promokey),
constraint sales_date_fkc foreign key (perkey)
references period (perkey),
constraint sales_product_fkc foreign key (classkey,
prodkey)
references product (classkey, prodkey),
constraint sales_store_fkc foreign key (storekey)
references store (storekey),
constraint sales_promo_fkc foreign key (promokey)
references promotion (promokey))
data in (daily_data1, daily_data2)
segment by values of (perkey)
ranges (min:415, 415:max)
maxsegments 2
maxrows per segment 60000;
入力データのレコードを読み込み、Sales テーブルの対応する行の列に各フィール
ドをマッピングする LOAD DATA 文は、以下のとおりです。
load data inputfile 'aroma_sales.txt'
recordlen 86
insert
into table sales (
perkey position(2) integer external(11) nullif(1)='%',
classkey position(14) integer external(11) nullif(13)='%',
prodkey position(26) integer external(11) nullif(25)='%',
storekey position(38) integer external(11) nullif(37)='%',
promokey position(50) integer external(11) nullif(49)='%',
quantity position(62) integer external(11) nullif(61)='%',
dollars position(74) decimal external(12) nullif(73)='%');
例 : データベースの作成
A-23
データのロード
Sales テーブルについては以下の点に注意してください。
■
■
入力データのレコードは固定長フォーマットです。各フィールドの位置は
POSITION 句で指定され、区切り記号はありません。
RECORDLEN 句が指定されており、各レコードの長さが 86 に固定されて
います。各フィールドのサイズ (11+11+11+11+11+11+12)、NULLIF 列ごと
に 1 文字ずつ (1+1+1+1+1+1+1) および改行文字を合計した値はレコード長
(86) と等しくなります。
データのロード
Newaroma のデータをロードするには、LOAD DATA 文が記述されているコント
ロール ファイルを使って TMU を実行します。このデータベースでは、すべての
LOAD DATA 文が 1 つのコントロール ファイル aroma.tmu に記述されています。
Period、Product、Market、Sales の各テーブルに対応する部分は以下のとおりです。
load data inputfile 'aroma_period.txt'
replace
format separated by '*'
into table period (
perkey integer external (4),
date date 'YYYY-MM-DD',
day char(3),
week integer external (4),
month char(5),
qtr char(5),
year integer external);
load data
inputfile 'aroma_product.txt'
replace
format separated by ':'
discardfile 'product.discards'
discards 1
into table product (
classkey integer external(2),
prodkey integer external(2),
prod_name char(30),
pkg_type char(20)) ;
load data
inputfile 'aroma_market.txt'
replace
format separated by '*'
discardfile 'market.discards'
discards 1
into table market (
A-24
Administrator’s Guide
データのロード
mktkey integer external(2),
hq_city char(20),
hq_state char(2),
district char(13),
region char(7)) ;
load data inputfile 'aroma_sales.txt'
recordlen 86
insert
into table sales (
perkey position(2) integer external(11) nullif(1)='%',
classkey position(14) integer external(11) nullif(13)='%',
prodkey position(26) integer external(11) nullif(25)='%',
storekey position(38) integer external(11) nullif(37)='%',
promokey position(50) integer external(11) nullif(49)='%',
quantity position(62) integer external(11) nullif(61)='%',
dollars position(74) decimal external(12) nullif(73)='%');
LOAD DATA 文とコントロール ファイルを使用するときは以下の点に注意してくだ
さい。
■
■
入力ファイル名は、TMU 実行時のデフォルト ディレクトリに対する相対
パスか、絶対パスでなければなりません。
参照先 ( ディメンジョン ) テーブル (Period、Product、Market) は、参照元
( ファクト ) テーブル (Sales) より前にロードします。
例 : データベースの作成
A-25
データのロード
aroma_db データベースにデータをロードする
1.
2.
3.
4.
redbrick ユーザとしてログインします。
ディレクトリがパス <redbrick_dir>/bin (UNIX)、または <redbrick_dir>¥BIN
(Windows) にあることを確認します。
aroma _inputs ディレクトリに移動します。このディレクトリには、
Aroma データベースの各テーブルに対応する LOAD DATA 文が記述されて
いる aroma.tmu ファイルがあります。
次のように入力し、TMU を実行します。
オペレーティ
ング システム
コマンド
UNIX
$ rb_tmu -d /my_directory/aroma_db aroma.tmu
system cryptic
Windows
c:¥> rb_tmu -d ¥my_directory¥aroma_db aroma.tmu
system cryptic
TMU が起動され、次のようなメッセージが表示されます。
A-26
Administrator’s Guide
データのロード
(C) Copyright IBM Corp. 1991-2002.
All rights reserved.
Version 06.20.0000(0)
** INFORMATION ** (366) Loading table MARKET.
** WARNING ** (8023) Any existing rows in tables that reference table MARKET may now be invalid.
** INFORMATION ** (315) Finished file aroma_market.txt. 17 rows read from this file.
** INFORMATION ** (367) Rows:17 inserted.0 updated.0 discarded.0 skipped.
** INFORMATION ** (500) Time = 00:00:00.05 cp time, 00:00:00.59 time, Logical IO count=90, Blk Reads=5,
Blk Writes=29
** INFORMATION ** (366) Loading table PRODUCT.
** WARNING ** (8023) Any existing rows in tables that reference table PRODUCT may now be invalid.
** INFORMATION ** (315) Finished file aroma_product.txt. 59 rows read from this file.
** INFORMATION ** (367) Rows:59 inserted.0 updated.0 discarded.0 skipped.
** INFORMATION ** (500) Time = 00:00:00.05 cp time, 00:00:00.81 time, Logical IO count=125, Blk Reads=1,
Blk Writes=48
** INFORMATION ** (366) Loading table PROMOTION.
** WARNING ** (8023) Any existing rows in tables that reference table PROMOTION may now be invalid.
** INFORMATION ** (352) Row 102 of index PROMOTION_PK_IDX is out of sequence.Switching to standard
optimized index building.Loading continues...
** INFORMATION ** (315) Finished file aroma_promo.txt. 194 rows read from this file.
** INFORMATION ** (513) Starting merge phase of index building PROMOTION_PK_IDX.
** INFORMATION ** (367) Rows:194 inserted.0 updated.0 discarded.0 skipped.
** INFORMATION ** (500) Time = 00:00:00.37 cp time, 00:00:00.90 time, Logical IO count=76, Blk Reads=3,
Blk Writes=36
** INFORMATION ** (366) Loading table PERIOD.
** WARNING ** (8023) Any existing rows in tables that reference table PERIOD may now be invalid.
** INFORMATION ** (315) Finished file aroma_period.txt. 821 rows read from this file.
** INFORMATION ** (367) Rows:821 inserted.0 updated.0 discarded.0 skipped.
** INFORMATION ** (500) Time = 00:00:00.05 cp time, 00:00:00.63 time, Logical IO count=87, Blk Reads=4,
Blk Writes=38
** INFORMATION ** (366) Loading table SALES.
** INFORMATION ** (352) Row 3 of index SALES_STAR_IDX is out of sequence.Switching to standard optimized
index building.Loading continues...
** INFORMATION ** (315) Finished file aroma_sales.txt. 69941 rows read from this file.
** INFORMATION ** (513) Starting merge phase of index building SALES_STAR_IDX.
** INFORMATION ** (367) Rows:69941 inserted.0 updated.0 discarded.0 skipped.
** INFORMATION ** (500) Time = 00:00:03.97 cp time, 00:00:08.63 time, Logical IO count=755, Blk
Reads=736, Blk Writes=699
例 : データベースの作成
A-27
データベースの検証
TMU からのメッセージについては次の点に注意してください。
■
■
テーブルごとに、TMU によって入力ファイルの行数が報告され、inserted、
updated、discarded、skipped に分類されています。この例では、すべての行
が inserted ( 挿入行 ) です。
Aroma データベースのすべてのテーブルがロードされています。
Promotion と Sales テーブルのメッセージには、インデックスの作成時に
ソートされていないデータが TMU によって検出され、standard optimized
モードに切り替えてインデックスの作成を続行したことが示されていま
す。入力データは Sales テーブルの STAR インデックスの先行フォーリン
キー参照の順序に基づいてソートされます。ほかのテーブルのフォーリン
キー参照の順序ではソートされません。
このデータベースをほかのユーザにアクセスさせたい場合は、GRANT コマンドに
よってデータベースのアクセス権を付与してください。また、データベースの論理
名を rbw.config ファイルに設定する必要があります。
データベースの検証
以下のような SELECT 文を入力し、各テーブルが正しく作成されたことを確認して
ください。
RISQL> select * from product where classkey = 1;
データが正しくロードされている場合は、次のような結果が表示されます。
RISQL> select * from
CLASSKEY
PRODKEY
1
1
1
1
1
1
1
1
1
1
RISQL>
A-28
Administrator’s Guide
product where classkey = 1;
PROD_NAME
0 Veracruzano
1 Xalapa Lapa
10 Colombiano
11 Expresso XO
12 La Antigua
20 Lotta Latte
21 Cafe Au Lait
22 NA Lite
30 Aroma Roma
31 Demitasse Ms
PKG_TYPE
No pkg
No pkg
No pkg
No pkg
No pkg
No pkg
No pkg
No pkg
No pkg
No pkg
まとめ
まとめ
データベースの作成手順をまとめると、以下のようになります。
1.
2.
3.
4.
5.
6.
7.
データベースに必要なテーブル、各テーブルの列およびそのデータ型を決
めます。
redbrick ユーザとしてログインし、rb_creator (UNIX) または dbcreate
(Windows) によってデータベースを作成します。データベース論理名を
rbw.config ファイルに追加します。
SQL の CREATE 文を使い、テーブルとインデックスを作成します。
入力データのフォーマット ( すでに存在している場合 ) を確認します。
外部フォーマットのデータをテーブルにマッピングする LOAD DATA 文を
作成します (LOAD DATA 文は 1 つの TMU コントロール ファイルに記述し
て実行しても、テーブルごとに実行してもかまいません )。
redbrick ユーザとして、rb_tmu または rb_ptmu と、コントロール ファイ
ルを使用してデータをロードします。
ユーザにアクセス権を付与します。
例 : データベースの作成
A-29
付録
構成ファイル
IBM Red Brick Warehouse を『Installation and Configuration Guide』に
従ってインストールすると、rbw.config という構成ファイルが
redbrick ディレクトリに作成されます。
付録 B では、構成ファイルに関する参考情報を記載し、以下について
説明します。
■
■
■
rbw.config ファイルの例
構成ファイルの各エントリ
構成パラメータのまとめ
rbw.config ファイルの例
rbw.config ファイルの例
rbw.config ファイルには以下の情報が格納されます。
■
■
■
■
■
■
インストレーション中に入力された指定に基づく構成情報
データベース サーバの動作に影響を与えるオプションのパラメータ
データベース サーバの性能に影響を与えるチューニング パラメータ
ログ記録を調整するロギング パラメータ
ユーザ パスワードの規則を設定するパスワード パラメータ
データベース論理名とデータベースのロケーション
これらのパラメータの多くは、SQL の SET 文または TMU の制御文で設定すること
もできます。
以下に、UNIX と Windows における、IBM Red Brick Warehouse の rbw.config ファイ
ルの例を示します。新たにインストールしたファイルは、通常このようになってい
ますが、実際のファイルは、これと異なる場合があります。このファイルは、イン
ストール スクリプトによって作成されますが、データベース管理者が修正できま
す。rbw.config の <value> で示した値は、実際の値に置き換えられます。Windows で
は、「/」を「¥」で、「/tmp」を「c: ¥temp」で置き換えてください。
B-2 Administrator’s Guide
rbw.config ファイルの例
構成ファイルの変更に関する詳細は、9-87 ページ「構成ファイルの修正」を、各
ファイルのエントリに関する説明は、B-10 ページ「構成ファイルの各エントリ」を
参照してください。
UNIX
Windows
UNIX
###########################################################################
#
# (C) Copyright IBM Corp. 1991-2002. All rights reserved.
#
# IBM Red Brick Warehouse Version 6.20.0
#
#
# This file contains various parameters for the Red Brick Warehouse
# Daemon (rbwapid), Server (rbwsvr), and Table Management Utilities
# (rb_tmu and rb_ptmu)
#♦
# This file contains various parameters for the Red Brick Warehouse
Service.
# (rbwapid, rbwadmd, rbwlogd, rbwsvr threads), and Table Management Utility
# (rb_tmu)
#♦
#
# The notation {ON | OFF} means use either ON, or OFF, etc.
# The default is the first option shown
#
# This config file was created by user: <redbrick>
############################################################################
###
# The following is used for IPC key values.Note that for shared memory
# and semaphores, the key values will range from the IPC key number to
# IPC key + MAX_SERVERS.
<RB_HOST_NAME> SHMEM <IPC_key>
# The following is used to specify the communication port for connections
# to the Red Brick Warehouse rbwapid daemon.
<RB_HOST_NAME> SERVER <host>: <port_number>
♦
# The following value controls the maximum number of concurrent Red Brick
# Warehouse sessions that can be started by the rbwapid daemon.
RBWAPI MAX_SERVERS $num_users
UNIX
Windows
# Daemon Start-up user exit script for cleaning up spill files.
RBWAPI CLEANUP_SCRIPT <redbrick_dir>/bin/rb_sample.cleanup
♦
RBWAPI CLEANUP_SCRIPT <redbrick_dir>¥BIN¥rbclean.bat
# Unified Logon for Windows NT
#RBWAPI UNIFIED_LOGON {OFF | ON}
# On NT, the following value gives the stack size for the server threads
# ZERO gives NT default, other values specified as 100K, 1M, 20 etc.
#RBWAPI STACK_SIZE 0
♦
UNIX
# The following value can be used to specify the location of the Red Brick
# Warehouse server image
RBWAPI SERVER_NAME <redbrick_dir>/bin/rbwsvr
♦
# The following value indicates the maximum size of the logfile.
# Once the daemon writes this many lines into the file, it will rename
構成ファイル
B-3
rbw.config ファイルの例
# it to rbwapid.log_old and a new logfile will be started.
RBWAPI LOGFILE_SIZE 1000
# Process checker daemon checking interval (secs)
#RBWAPI PROCESS_CHECKING_INTERVAL 10
# The maximum number of active databases
#RBWAPI MAX_ACTIVE_DATABASES 30
# Remote TMU Listener {ON | OFF}
# Default always ON unless specified OFF
RBWAPI REMOTE_TMU_LISTENER ON
Windows
UNIX
# Message base details (location and language)
NLS_LOCALE MESSAGE_DIR C:¥RedBrick620¥RBW620¥MESSAGES
♦
NLS_LOCALE MESSAGE_DIR <redbrick_dir>/messages
♦
NLS_LOCALE LOCALE locale
# First day of the week.1=Sunday, 2=Monday, ...7=Saturday
# Use this to override the default first day of the week.
#NLS_LOCALE FIRST_DAYOFWEEK <1-7>
UNIX
# Server Monitor daemon sampling interval (secs)
RBWMON INTERVAL 120
♦
# Automatic referenced table row generation
#OPTION AUTOROWGEN {OFF | ON}
# Divide by zero control
#OPTION ARITHABORT {ON | OFF}
# Deadlock control
#OPTION ALLOW_POSSIBLE_DEADLOCK {OFF | ON}
# Query Priority control.
#OPTION READER_PRIORITY {ON | OFF}
# Enable cross join
#OPTION CROSS_JOIN
{OFF | ON }
# Datatype for COUNT function
#OPTION COUNT_RESULT {INTEGER | DECIMAL | DEC | INT}
# Check index/table report file permissions and location
#OPTION CHECK_REPORT_FILE_PERMISSIONS {SERVER_OWNER | SERVER_GROUP | ALL}
#OPTION CHECK_TABLE_INDEX_DIRECTORY <directory_path>
# Temporary Table creation authorization
#OPTION GRANT_TEMP_RESOURCE_TO_ALL {ON | OFF}
# Generate log records for Advisor?
#OPTION ADVISOR_LOGGING {ON | ON_WITH_CORR_SUB | OFF}
# Assume all precomputed views have been accessed uniformly?
#OPTION UNIFORM_PROBABILITY_FOR_ADVISOR {OFF | ON}
# Automatically rewrite queries using available precomputed views?
#OPTION PRECOMPUTED_VIEW_QUERY_REWRITE {ON | OFF}
B-4 Administrator’s Guide
rbw.config ファイルの例
# Use invalid precomputed views when rewriting queries?
#OPTION USE_INVALID_PRECOMPUTED_VIEWS {OFF | ON}
# Set limit on the number of advisor candidate views to process
#OPTION ADVISOR_MAXIMUM_CANDIDATE_VIEWS 20
# Start DML statement as versioning transaction
#OPTION VERSIONING {OFF | ON}
# The isolation level when accquiring locks for DML statement
#OPTION TRANSACTION_ISOLATION_LEVEL {SERIALIZABLE | REPEATABLE_READ}
# Start TMU operation as versioning transaction
#OPTION TMU_VERSIONING {OFF | ON | RECOVER}
# Defaults for TMU periodic commit
#OPTION TMU_COMMIT_RECORD_INTERVAL { <ROWCOUNT> | OFF }
#OPTION TMU_COMMIT_TIME_INTERVAL { <SECONDS> | OFF }
Windows
UNIX
# EXPORT default directory
#OPTION EXPORT_DEFAULT_PATH c:¥temp
♦
#OPTION EXPORT_DEFAULT_PATH /tmp
♦
# EXPORT field delimiter
#OPTION EXPORT_DELIMITER |
# Bytes per data file for EXPORT command
#OPTION EXPORT_MAX_FILE_SIZE 1K
# Idle timeout for connections in minutes, 0 means feature is disabled
# OPTION IDLE_TIMEOUT 0
###########################################################
# Precomputed View Maintenance section
###########################################################
# Turn automatic precomputed view maintenance ON or OFF
#OPTION PRECOMPUTED_VIEW_MAINTENANCE {ON | OFF}
# Controls the transaction behavior during precomputed view maintenance.
# This applies only with versioning enabled.
#OPTION PRECOMPUTED_VIEW_MAINTENANCE_ON_ERROR {ROLLBACK | INVALIDATE}
###########################################################
#
# TUNE section:Optional tuning & performance parameters
#
###########################################################
# Number of TMU Buffer cache pages
#TUNE TMU_BUFFERS 128
# Tuning parameter for parallel query
#TUNE ROWS_PER_SCAN_TASK 2147483647
#TUNE ROWS_PER_FETCH_TASK 2147483647
#TUNE ROWS_PER_JOIN_TASK 2147483647
#TUNE ROWS_PER_TARGETJOIN_TASK 2147483647
#TUNE QUERYPROCS 0
#TUNE TOTALQUERYPROCS 0
#TUNE FORCE_SCAN_TASKS {OFF | <num_tasks>}
#TUNE FORCE_FETCH_TASKS {OFF | <num_tasks>}
構成ファイル
B-5
rbw.config ファイルの例
#TUNE FORCE_JOIN_TASKS {OFF | <num_tasks>}
#TUNE FORCE_TARGETJOIN_TASKS {OFF | <num_tasks>}
# Define physical disk groups -- the default is
# each PSU is in its own file group
#TUNE FILE_GROUP 1 <path1>
#TUNE FILE_GROUP 1 <path2>
#TUNE FILE_GROUP 2 <path3>
# Maximum amount of parallelism to use on a specific file group
#TUNE GROUP 1 1
#TUNE GROUP 2 1
# Tuning parameter for parallel hybrid hash joins
#TUNE FORCE_HASHJOIN_TASKS {OFF | <num_tasks>}
# Enable parallelism for hybrid hash joins
#TUNE PARALLEL_HASHJOIN {ON | OFF}
# Tuning parameter for parallel aggregation partitioned by GROUP BY columns
#TUNE FORCE_AGGREGATION_TASKS {OFF | <num_tasks>}
# Enable parallelism for aggregation partitioned by the GROUP BY columns
#TUNE PARTITIONED_PARALLEL_AGGREGATION {OFF | ON}
# Enable parallelism for queries that contain UNION, INTERSECT, and EXCEPT
#TUNE PARALLEL_SET_OPERATION {OFF | ON}
# Result buffer configuration
#TUNE RESULT_BUFFER {UNLIMITED | <value>{K|M|G}}
#TUNE RESULT_BUFFER_FULL_ACTION {PAUSE | ABORT}
# Index Fillfactor parameters
#FILLFACTOR PI 100
#FILLFACTOR STAR 100
#FILLFACTOR SI 100
#VARCHAR fillfactor parameters
#FILLFACTOR VARCHAR 10
# Optimized index build parameter
#OPTION TMU_OPTIMIZE {OFF | ON}
Windows
UNIX
# Index Temporary Space parameters
# Always specify THRESHOLD before MAXFILESIZE in this
# configuration file
# Specify multiple DIRECTORYs by having multiple
# TUNE INDEX_TEMPSPACE_DIRECTORY entries
#TUNE INDEX_TEMPSPACE_THRESHOLD 10M
#TUNE INDEX_TEMPSPACE_MAXSPILLSIZE 1G
#TUNE INDEX_TEMPSPACE_DIRECTORY c:¥temp
♦
#TUNE INDEX_TEMPSPACE_DIRECTORY /tmp
♦
# Query Temporary Space parameters
# Always specify QUERY_MEMORY_LIMIT before
# QUERY_TEMPSPACE_MAXSPILLSIZE in this configuration file
# Specify multiple DIRECTORYs by having multiple
# TUNE QUERY_TEMPSPACE_DIRECTORY entries
#TUNE QUERY_MEMORY_LIMIT 50M
#TUNE QUERY_TEMPSPACE_MAXSPILLSIZE 1G
B-6 Administrator’s Guide
rbw.config ファイルの例
Windows
UNIX
#TUNE QUERY_TEMPSPACE_DIRECTORY c:¥temp
♦
#TUNE QUERY_TEMPSPACE_DIRECTORY /tmp
♦
# TMU Row Messages Mode
#TUNE TMU_ROW_MESSAGES {FULL | NONE}
# Default PTMU behavior
#TUNE TMU_SERIAL_MODE { ON | OFF }
# Defaults for PTMU number of tasks used for different operations
#TUNE TMU_CONVERSION_TASKS <no_of_conversion_tasks>
#TUNE TMU_INDEX_TASKS <max_no_index_tasks>
#TUNE TMU_INPUT_TASKS <no_index_tasks>
#TUNE TMU_MAX_TASKS <max_no_tmu_tasks>
# Set limit on TMU memory map space
#TUNE TMU_MMAP_LIMIT <number>{K|M}
# Random Sampling margin (percentile) to be used for inexact random
sampling
#TUNE SAMPLE_MARGIN { <zero_or_positive float> | ON | OFF }
# Sample size (percentile) to be used by advisor for candidate view
analysis.
#TUNE ADVISOR_SAMPLE_SIZE <0.0 to 100.0>
# Process local (non-join) predicates in TargetJoin, if possible
#OPTION TARGETJOIN_LOCAL_PREDICATES {OFF | ON}
# Use fast incremental computation for olap functions on approximate
datatypes
#OPTION OLAP_APPROXIMATE_NUMERIC_FAST_COMPUTATION {ON | OFF}
# the number of XML parallel parsing tasks to be spawned.Default is 1
(serial)
#TUNE XML_MAX_TASKS <no_xml_parsing_tasks>
# directory to place temporary XML spill files.
# if left unset, defaults to directory set by QUERY_TEMPSPACE_DIRECTORY.
#OPTION XML_TEMP_SPACE <temporary_spill_space_for_xml_parsing>
###########################################################
#
# BACKUP/RESTORE section:
#
###########################################################
# size of a bar unit.Default value is 256M.
#TUNE BAR_UNIT_SIZE 256M
UNIX
# logical tape device name mappings.There is no default
# value.This entry is required if TAPE device is used
# for backu/restore.
#BARTAPE dev1 /dev/rmt/0n
♦
#
#
#
#
The following two parameters config the user name
and the XBSA library path of a XBSA storage manager
There are no default values.These two entries are required
if a XBSA storage manager is used for backup/restore.
構成ファイル
B-7
rbw.config ファイルの例
#OPTION BAR_SM_USER redbrick
#OPTION BAR_XBSA_LIB /local/lib/xbsa.lib
###########################################################
#
# DEFAULT section
#
###########################################################
# Max # of rows to return on an unconstrained query (
#DEFAULT ROWCOUNT 0
# Max # of INFORMATION & STATISTICS messages to return
# for one operation.
#DEFAULT INFO_MESSAGE_LIMIT 1000
# Max # of rows pertaining to LOAD information to be
# retained by RB_DEFAULT_LOADINFO
#DEFAULT RBW_LOADINFO_LIMIT 256
###########################################################
#
# SEGMENTS section
#
# Do NOT set default_data_segment or default_index_segment
# if you have multiple databases.See the Warehouse
# Administrator's Guide for additional information
#
###########################################################
# Segment default directories
#OPTION DEFAULT_DATA_SEGMENT <RB_PATH>
#OPTION DEFAULT_INDEX_SEGMENT <RB_PATH>
# Temporary table default segment directories
#OPTION TEMPORARY_DATA_SEGMENT <RB_PATH>
#OPTION TEMPORARY_INDEX_SEGMENT <RB_PATH>
# Keep/drop segments upon DROP table or index
#OPTION SEGMENTS {KEEP | DROP}
# Segment partial availability controls
#OPTION IGNORE_PARTIAL_INDEXES {OFF | ON}
#OPTION PARTIAL_AVAILABILITY {PRECHECK | INFO | WARN | ERROR}
# Optical storage availability controls
#OPTION IGNORE_OPTICAL_INDEXES {OFF | ON}
#OPTION OPTICAL_AVAILABILITY {WAIT_NONE | WAIT_INFO | WAIT_WARN |
SKIP_INFO | SKIP_WARN | ERROR | PRECHECK }
# Default segment expansion controls
#OPTION DEFAULT_SEGMENT_SIZE <number>{K|M|G}
#OPTION DEFAULT_PSU_EXTENDSIZE <number>{K|M|G}
###########################################################
#
# ADMIN section
#
###########################################################
#ADMIN
ACCOUNTING
{ OFF | ON }
#ADMIN
ACCT_DIRECTORY <RB_CONFIG>/logs
#ADMIN
ACCT_MAXSIZE
0
#ADMIN
ACCT_LEVEL
{ JOB | WORKLOAD }
B-8 Administrator’s Guide
rbw.config ファイルの例
UNIX
#ADMIN
#ADMIN
#ADMIN
#ADMIN
#ADMIN
#ADMIN
#ADMIN
#ADMIN
#ADMIN
#ADMIN
♦
LOGGING
{ ON | OFF }
LOG_DIRECTORY
<RB_CONFIG>/logs
LOG_MAXSIZE
0
LOG_AUDIT_LEVEL { ALERT | ROUTINE | URGENT }
LOG_ERROR_LEVEL { ROUTINE | ALERT | URGENT }
LOG_OPERATIONAL_LEVEL { ALERT | ROUTINE | URGENT }
LOG_SCHEMA_LEVEL { ROUTINE | ALERT | URGENT }
LOG_USAGE_LEVEL { ALERT | ROUTINE | URGENT }
REPORT_INTERVAL 1
RENICE_COMMAND <full_path_of_a_renice_command>
# Create Advisor log files at system startup, and log advisor records?
#ADMIN ADVISOR_LOGGING {OFF | ON}
# Advisor logging directory
#ADMIN ADVISOR_LOG_DIRECTORY <RB_CONFIG>/logs
# Advisor log maximum size control
#ADMIN ADVISOR_LOG_MAXSIZE 0
###########################################################
#
# PASSWORD section
#
###########################################################
# Number of days allowed between password changes
#PASSWORD EXPIRATION_DAYS 0
# Number of days before password expires that user will
# begin to be warned that password is about to expire
#PASSWORD EXPIRATION_WARNING_DAYS 0
# Minimum number of days that must pass between
# password changes
#PASSWORD CHANGE_MINIMUM_DAYS 0
# Number of previously used passwords on each account
# against which new passwords will be compared for
# uniqueness
#PASSWORD RESTRICT_PREVIOUS 0
# The following three parameters control the requirements
# for complex passwords.These parameters specify the
# number of characters of the three types that must be
# present in each new password.
#PASSWORD COMPLEX_NUM_ALPHA 0
#PASSWORD COMPLEX_NUM_NUMERICS 0
#PASSWORD COMPLEX_NUM_PUNCTUATION 0
# Minimum required length for new passwords
#PASSWORD MINIMUM_LENGTH 0
# Number of failed login attempts that will result in a
# user account being locked
#PASSWORD LOCK_FAILED_ATTEMPTS 0
# Number of hours an account will remain locked
#PASSWORD LOCK_PERIOD_HOURS 0
# Allow login name to be part of password
#PASSWORD ALLOW_LOGNAME ON
# User must change the initial password during first login session
#PASSWORD CHANGE_INITIAL OFF
# Whether changes to the numerals in password need to be complex
#PASSWORD COMPLEX_NUMERIC OFF
###########################################################
#
構成ファイル
B-9
構成ファイルの各エントリ
# Query Performance Monitor section
#
###########################################################
# maximum number of sessions that can be concurrently monitored
# OPTION PERFORMANCE_MONITOR_MAXSESSIONS 20
# maximum number of commands that can be stored in the
# performance monitor DST tables
# OPTION PERFORMANCE_MONITOR_COMMANDS_LIMIT 100
# maximum number of operators within a query that can be monitored
# OPTION PERFORMANCE_MONITOR_MAXOPERATORS 100
Windows
###########################################################
#
# NETWORK section:Add additional entries as services
#
are created
#
###########################################################
<RB_HOST_NAME> SERVER <host>:<port_number>
♦
UNIX
###########################################################
#
# DATABASE section:Add additional entries as databases
#
are created
#
###########################################################
# Logical database name mappings
DB AROMA <redbrick_dir>/aroma_dir
DB ADMIN <redbrick_dir>/admin_dir
♦
Windows
DB AROMA
DB ADMIN
♦
<redbrick_dir>¥aroma_db
<redbrick_dir>¥admin_db
構成ファイルの各エントリ
この節では、標準の手順によって IBM Red Brick Warehouse をインストールしたとき
に作成されるファイル rbw.config のエントリについて簡単に説明します。
Windows では、環境変数 RB_HOST、RB_CONFIG、RB_PATH はレジストリに定
義され、レジストリ モニタによって管理されます。UNIX では、これらはスタート
アップ ファイルに定義されます。
インストール後に構成ファイルを変更する方法については、9-87 ページ「構成ファ
イルの修正」を参照してください。
B-10
Administrator’s Guide
構成情報
構成情報
ファイルのエントリ
説明
<RB_HOST_NAME> SHMEM
(UNIX)
IPC のキー範囲に使用する基準値を設定します。IPC
キー値の範囲は、SHMEM の値から、SHMEM に
MAX_SERVERS を加算した値までです ( すべてのプ
ラットフォームにあるとはかぎりません )。
デフォルト : 100 ( 基本 16 進整数 )
この範囲のキーはシステムで一意でなくてはなら
ず、システム管理者または IPC キー値の責任者が
IBM Red Brick Warehouse に割り当てる必要がありま
す。
<RB_HOST_NAME> MAPFILE
(UNIX)
共有メモリ マップ ファイルとして使用するファイ
ルを指定します ( すべてのプラットフォームにある
とはかぎりません )。
デフォルト : ./.RB_HOST.mapfile
<RB_HOST_NAME> SERVER
IBM Red Brick Warehouse との接続に使用するすべて
のホスト名とポート番号を設定します。
デフォルト : データベースのインストール時に指定
したホスト名とポート番号
RBWAPI MAX_SERVERS
ウェアハウス デーモン (UNIX) またはウェアハウス
サービス (Windows) がサポートする最大同時接続
( ユーザ ) 数を設定します。
デフォルト : 10 ( 基本 10 進整数 )
パラメータ SHMEM とパラメータ MAX_SERVERS
の値を使用して IPC キーの範囲を計算する方法につ
いては、『Installation and Configuration Guide』を参照
してください。
RBWAPI CLEANUP_SCRIPT
起動時にデーモン (UNIX)、またはウェアハウス
サービス (Windows) が実行するスピル ファイル ( 一
時的なファイル ) のクリーンアップ スクリプトを設
定します。redbrick ディレクトリの bin サブディレ
クトリにサンプル スクリプトが格納されています。
スクリプト名は rb_sample.cleanup (UNIX) または
rbclean.bat (Windows) です。
サンプル スクリプトの詳細については、4-53 ページ
「テンポラリ ファイルの削除」を参照してください。
(１/８)
構成ファイル B-11
構成情報
ファイルのエントリ
説明
RBWAPI UNIFIED_LOGON
(Windows)
ON に設定すると、全データベース ユーザは、必要な
オペレーティング システムのアカウントを持ち、
データベース ディレクトリ内のファイルに対する読
み込みと書き込みの権限を持っていることを、オペ
レーティング システムによって認証される必要があ
ります。
デフォルト : OFF
RBWAPI SERVER_NAME
(UNIX)
データベース サーバのイメージ (rbwsvr) のロケー
ションを指定します。
RBWAPI LOGFILE_SIZE
データベース サーバのログファイル rbwapid.log の
最大行数を指定します。指定した最大行数に達する
と、rbwapid デーモン プロセスによってそのログ
ファイルの名前が rbwapid.log_old に変更され、新し
いログファイルが開始されます。ただし、複数行
メッセージは新旧のログファイルに分割して格納さ
れるため、rbwapid.log ログファイルが最大行数を超
えることもあります。
デフォルト : 1000
RBWAPI PROCESS_CHECKING_INTERVAL
プロセス チェッカ デーモン (rbwpchk) の実行間隔を
確認します。
RBWAPI MAX_ACTIVE DATABASES
アクティブなデータベースの最大数。
RBWAPI REMOTE_TMU_LISTENER
ON に設定すると、サーバがリモート TMU からの要
求に対応できるようになります。このパラメータの
詳細については、
『Table Management Utility Reference
Guide』を参照してください。
デフォルト : ON
NLS_LOCALE MESSAGE_DIR
エラー メッセージに使用するディレクトリを指定し
ます。
デフォルト : ./messages (UNIX) または .¥messages
(Windows)
NLS_LOCALE LOCALE
データベース サーバの言語、地域、ソート順を指定
します。
デフォルト : English-UnitedStates.US-ASCII@Binary
(２/８)
B-12
Administrator’s Guide
構成情報
ファイルのエントリ
説明
NLS_LOCALE FIRST_DAYOF WEEK
週の始まりの曜日を指定します。1 が日曜日、7 が土
曜日です。
RBWMON INTERVAL
(UNIX)
データベース サーバ モニタ デーモン
(rbw.servermon) がデータベース サーバ プロセスを
監視する間隔を指定します。
デフォルト : 120 秒
OPTION AUTOROWGEN
TMU のロード操作中に、参照先テーブルの自動行生
成を切り換えます。
デフォルト : OFF
OPTION ARITHABORT
ゼロ除算エラーの発生時に、算術演算を中止するこ
とを指定します。
OPTION
ALLOW_POSSIBLE_DEADLOCK
デッドロックの可能性がある場合に制御を返すので
はなく、デッドロックが発生してもデータベース
サーバがロックを待機することを指定します。
デフォルト : 設定なし
OPTION READER_PRIORITY
ON に設定した場合は、テーブルの読み取りロック
を要求するクエリのほうが、データベースへの書き
込みを必要とする操作よりも優先権があります。ク
エリが実行されるとき、クエリはシステム テーブル
に対してデータベース レベルのロックを取得する必
要があります。OFF に設定した場合は、一般的なク
エリ優先ロックが無効になります。システム テーブ
ルに対するデータベース レベルのロックを利用しな
くても、テーブル レベルでスキーマ ロックを取得す
ることができます。
デフォルト : ON
OPTION CROSS_JOIN
クロス結合を許すかどうかを指定します。
デフォルト : OFF
OPTION LOCAL_TARGET_PREDICATES
結合以外の述部を TARGETjoin 処理の一部として処
理するかどうかを指定します。
デフォルト : OFF
(３/８)
構成ファイル
B-13
構成情報
ファイルのエントリ
説明
OPTION COUNT_RESULT
COUNT 関数の結果を返すデータ型 ( 整数 (INTEGER)
型、または 10 進数 (DECIMAL) 型 ) を指定します。
テーブルの行数が 232 行を超える場合は、
COUNT_RESULT を 10 進数 (DECIMAL) 型に設定す
る必要があります。
デフォルト : INTEGER
OPTION CHECK_REPORT_FILE_PERMISSIONS
CHECK TABLE 文と CHECK INDEX 文によって生成
されるレポートのファイル アクセス権を設定しま
す。デフォルト値は SERVER_OWNER です。この設
定では redbrick ユーザに読み取りアクセス権と書き
込みアクセス権が与えられます。SERVER_GROUP
は UNIX プラットフォームでだけ有効です。この設
定ではグループに読み取り専用アクセス権が与えら
れます。ALL に設定すると、すべてのユーザに読み
取り専用アクセス権が与えられます。
デフォルト : SERVER_OWNER
OPTION CHECK_TABLE_INDEX_DIRECTORY
CHECK TABLE 文と CHECK INDEX 文によって生成
されるレポート ファイルを格納するディレクトリを
指定します。
デフォルト : なし
OPTION
GRANT_TEMP_RESOURCE_TO_ALL
CONNECT システム ロール権限を持つ全ユーザに、
テンポラリ テーブルおよびインデックスの作成権限
を付与、または取り消します。
デフォルト : ON
(４/８)
B-14
Administrator’s Guide
構成情報
ファイルのエントリ
説明
OPTION ADVISOR_LOGGING
すべてのセッションに対する Advisor クエリ ロギン
グを有効または無効にします。OPTION
ADVISOR_LOGGING 文を有効にするには、
rbw.config ファイルの ADMIN ADVISOR_LOGGING
ON 設定、または ALTER SYSTEM START
ADVISOR_LOGGING 文のいずれかを使用して、
Advisor ロギングを有効にする必要があります。
ON_WITH_CORR_SUB に設定すると、書き換えられた
ほかのクエリとともに相関サブクエリがログに記録
されます。ON に設定すると、相関サブクエリはログ
に記録されません。Informix Vista の場合にだけ有効
です。
戻り値 : ON、OFF、ON_WITH_CORR_SUB
デフォルト : ON
OPTION
UNIFORM_PROBABILITY_FOR_ADVISOR
Advisor システム テーブル クエリの参照数を計算す
るかわりに、Advisor ログ ファイルを精査するかを
設定します。このコマンドを ON に設定すると、基本
テーブルのすべてのビューが同じ回数だけ参照され
たとみなされます。
デフォルト : OFF
OPTION
PRECOMPUTED_VIEW_QUERY_REWRITE
集約クエリ リライト システムを有効または無効にし
ます。
デフォルト : ON
OPTION
USE_INVALID_PRECOMPUTED_VIEWS
ON に設定した場合は、Vista クエリ リライト エンジ
ンのクエリ書き換えに、(SET PRECOMPUTED VIEW
view_name INVALID コマンドまたは詳細テーブルへ
のデータのロードや挿入によって ) 無効とマークさ
れたものを含む、すべての事前計算ビューを使用し
ます。
デフォルト : OFF
Windows では、クエリ処理に使用するスピル ファイ
ル ( 一時的なファイル ) のディレクトリも指定しま
す。デフォルト : c: ¥tmp
(５/８)
構成ファイル
B-15
構成情報
ファイルのエントリ
説明
OPTION ADVISOR_MAXIMUM_
CANDIDATE_VIEWS
1 回の分析処理で生成される候補の最大数を指定し
ます。この設定により、評価対象となる候補の数を
制御して、Advisor による分析の経過時間を短縮でき
ます。
デフォルト : 20
OPTION VERSIONING
バージョニング トランザクションとして、DML 文
を発行します。
OPTION TRANSACTION_ISOLATION_LEVEL
DML 文を実行するためにロックする必要がある場合
の排他レベルを設定します。
OPTION TMU_VERSIONING
バージョニング トランザクションとして、TMU 処
理を開始します。値は ON、OFF、RECOVER です。デ
フォルト値は OFF です。
ON に設定した場合は、バキューム クリーナによって
ターゲット データベースにバージョン ログが書き込
まれます。並列クエリが連続的に有効化される環境
にはこの設定が最適です。
RECOVER に設定した場合は、トランザクション コ
ミットごとにローダによってターゲット データベー
スにバージョン ログが書き込まれます。これは一種
のブロック ロードであり、バージョン ロードの復元
可能性を向上させることができます。テーブルへの
排他アクセスによって大量ロードが毎日行われる場
合には、この設定が最適です。REORG とオフライ
ン ロード操作ではこの設定はサポートされません。
OPTION TMU_COMMIT_RECORD_INTERVAL
次のコミット操作が発生するまでにテーブルにロー
ドされるレコードの数を指定します。この文は、
TMU_VERSIONING の設定が ON または RECOVER
の場合にだけ有効です。
この文を TMU_COMMIT_TIME_INTERVAL 文と組み
合わせて使用した場合、どちらかの条件が満たされ
るとコミットが実行されます。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : OFF
(６/８)
B-16
Administrator’s Guide
構成情報
ファイルのエントリ
説明
OPTION TMU_COMMIT_TIME_INTERVAL
次のコミット操作が発生するまでにテーブルにデー
タがロードされる時間を分単位で指定します。この
文は、TMU_VERSIONING の設定が ON または
RECOVER の場合にだけ有効です。
この文を TMU_COMMIT_RECORD_INTERVAL 文と
組み合わせて使用した場合、どちらかの条件が満た
されるとコミットが実行されます。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : OFF
OPTION EXPORT_DEFAULT_PATH
EXPORT 文でファイルをエクスポートする先のデ
フォルト ディレクトリを指定します。
デフォルト : なし
OPTION EXPORT_DELIMITER
区切り記号付き (DELIMITED) 形式で出力ファイル
を作成する EXPORT 文で使用する区切り記号を指定
します。
デフォルト : |
OPTION EXPORT_MAX_FILE_SIZE
EXPORT コマンドでエクスポートできる最大ファイ
ル サイズを指定します。
デフォルト : なし
OPTION IDLE_TIMEOUT
接続がアイドル状態と判断され、自動終了するまで
のサーバの待ち時間 ( 分 ) を指定します。0 ( デフォ
ルト値 ) に設定した場合、接続のタイムアウトが起
こりません。
OPTION PRECOMPUTED_VIEW_MAINTENANCE 集約テーブルの親の詳細テーブルが更新された場合
に、集約テーブルを自動的に更新するかどうかを指
定します。これを集約管理とも呼びます。OFF に設
定した場合、集約テーブルは自動更新されません。
デフォルト : ON
(７/８)
構成ファイル
B-17
構成情報
ファイルのエントリ
説明
OPTION PRECOMPUTED_VIEW_MAINTENANCE バージョン情報を使用するデータベース内の事前計
_ON_ERROR
算ビューのエラー管理を行うよう指定します。
バージョン情報を使用しないデータベースにはこの
オプションは無効です。この場合、更新中にエラー
が発生すると、集約テーブルを含む事前計算ビュー
が無効に設定されます。
バージョン情報が有効な場合、親テーブルと集約
テーブルの更新を ROLLBACK 設定によってロール
バックするか、INVALIDATE 設定によって、バー
ジョン情報を使用しないデータベースと同じように
処理するかを指定することができます。
デフォルト : ROLLBACK
OPTION BAR_XBSA_LIB
XBSA 格納域マネージャの X/Open Backup Services
API (XBSA) ライブラリ パスを指定します。バック
アップと復元に XBSA 格納域マネージャを使用する
場合は、このパラメータとパラメータ
BAR_SM_USER が必要になります。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : なし
OPTION BAR_SM_USER
XBSA 格納域マネージャのユーザ名を指定します。
バックアップと復元に XBSA 格納域マネージャを使
用する場合は、このパラメータとパラメータ
BAR_XBSA_LIB が必要になります。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : なし
BARTAPE
テープ装置の物理名に論理名をマッピングします。
バックアップと復元にテープ装置を使用する場合
は、このパラメータを指定する必要があります。複
数のテープ装置を使用する場合は複数のエントリを
指定し、テープ装置ごとにパラメータ BARTAPE を
指定します。
デフォルト : 設定なし
(８/８)
B-18
Administrator’s Guide
チューニング パラメータとパフォーマンス パラメータ
チューニング パラメータとパフォーマンス
パラメータ
ファイルのエントリ
説明
TUNE TMU_BUFFERS
TMU のバッファ キャッシュ サイズを 8KB のブロッ
ク単位で指定します。有効範囲は 128 ∼ 8,208 ブ
ロックです。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : 128 ブロック
TUNE ROWS_PER_SCAN_TASK
並列リレーション スキャンを実行する前に、リレー
ション スキャンでスキャンされる最少処理行数を指
定します。
デフォルト : 2,147,483,647 ( カンマは入力しない )
戻り値 : 1 ∼ 231 の整数
TUNE ROWS_PER_FETCH_TASK
並列フェッチ処理を実行する前に、STARjoin の
フェッチ フェーズで返す最少行数を指定します。
デフォルト : 2,147,483,647 ( カンマは入力しない )
戻り値 : 1 ∼ 231 の整数
TUNE ROWS_PER_JOIN_TASK
並列結合プロセスを実行する前に、STARjoin 処理
( インデックス検索 ) で返す最少エントリ数を指定
します。
デフォルト : 2,147,483,647 ( カンマは入力しない )
戻り値 : 1 ∼ 231 の整数
TUNE ROWS_PER_TARGETJOIN_TASK
並列 TARGETjoin プロセスを実行する前に、
TARGETjoin で処理する最少行数を指定します。
デフォルト : 2,147,483,647 ( カンマは入力しない )
戻り値 : 1 ∼ 231 の整数
TUNE QUERYPROCS
1 つのクエリを処理するのに使用するプロセス数の
最大数を指定します。
デフォルト : 0
戻り値 : 0 ∼ 32,767 の整数
(１/８)
構成ファイル
B-19
チューニング パラメータとパフォーマンス パラメータ
ファイルのエントリ
説明
TUNE TOTALQUERYPROCS
1 つのウェアハウス デーモンが制御するすべての
データベース サーバで、並列クエリ処理に同時に利
用できるプロセスの最大数を指定します ( パラメー
タ MAX_SERVERS で指定する上限と併用 )。
デフォルト : 0
戻り値 : 0 ∼ 32,767 の整数
TUNE FORCE_SCAN_TASKS
リレーション スキャンに使用する並列タスク数を指
定します。
デフォルト : OFF
戻り値 : 0 ∼ 32,767 の整数
TUNE FORCE_FETCH_TASKS
1 つのクエリで、行データのフェッチに使用する並
列タスク数を指定します。
デフォルト : OFF
戻り値 : 0 ∼ 32,767 の整数
TUNE FORCE_JOIN_TASKS
1 つのクエリで、結合処理に使用する並列タスク数
を指定します。
デフォルト : OFF
戻り値 : 0 ∼ 32,767 の整数
TUNE FORCE_TARGETJOIN_TASKS
1 つのクエリで、TARGETjoin の処理に使用する並
列タスク数を指定します。
デフォルト : OFF
戻り値 : 0 ∼ 32,767 の整数
TUNE FILE_GROUP
ディスク I/O の競合を軽減するため、ディスク グ
ループを設定します。
デフォルト : なし
戻り値 : 0 ∼ 32,767 の整数
TUNE GROUP
1 つのクエリで、指定されたディスク グループを同
時にアクセスする並列プロセスの最大数を指定しま
す。
デフォルト : クエリ 1 つにつき、ディスク グループ
ごとに 1 プロセス
(２/８)
B-20
Administrator’s Guide
チューニング パラメータとパフォーマンス パラメータ
ファイルのエントリ
説明
TUNE FORCE_HASHJOIN_TASKS
ハイブリッド ハッシュ結合に使用する並列タスク数
を指定します。
デフォルト : OFF
戻り値 : 0 ∼ 32,767 の整数
TUNE PARALLEL_HASHJOIN
ハイブリッド ハッシュ結合の処理に並列プロセスを
使用するかどうかを指定します。
デフォルト : ON
TUNE FORCE_AGGREGATION_TASKS
集約関数の処理に使用する並列タスク数を指定しま
す。
デフォルト : OFF
戻り値 : 0 ∼ 32,767 の整数
TUNE
PARTITIONED_PARALLEL_AGGREGATION
集約関数の処理に並列プロセスを使用するかどうか
を指定します。
デフォルト : OFF
TUNE
PARALLEL_SET_OPERATION
Set 演算子 UNION、INTERSECT、EXCEPT を含む
クエリの処理に並列プロセスを実行するかどうかを
指定します。
デフォルト : OFF
TUNE RESULT_BUFFER
クエリのリザルト バッファのサイズを指定します。
デフォルト : UNLIMITED
TUNE RESULT_BUFFER_FULL_ACTION
リザルト バッファが飽和状態になった時、クエリ処
理を中止するか一時停止するかを指定します。
デフォルト : PAUSE
FILLFACTOR PI, FILLFACTOR STAR,
FILLFACTOR SI
プライマリ インデックス、STAR インデックス、セ
カンダリー ( ユーザ定義 ) インデックスについて、
新規インデックス ノードに使用するフィル ファク
タを指定します。
デフォルト : 100
FILLFACTOR_VARCHAR
VARCHAR データ型列のユーザ見積りサイズを指定
します。
デフォルト : 10
(３/８)
構成ファイル
B-21
チューニング パラメータとパフォーマンス パラメータ
ファイルのエントリ
説明
OPTION OLAP_APPROXIMATE_NUMERIC_FAST_
COMPUTATION
ON に設定すると、OLAP 関数を含むクエリの性能が
向上します。
このパラメータの詳細については、『SQL Reference
Guide』を参照してください。
デフォルト : ON
OPTION
PERFORMANCE_MONITOR_COMMANDS
パフォーマンス モニタがパフォーマンス DST に格
納できるコマンドの最大数を指定します。0 より大
きい値を指定する必要があります。
このパラメータの詳細については、『Query
Performance Guide』を参照してください。
デフォルト : 100
OPTION
PERFORMANCE_MONITOR_MAXOPERATORS
監視するクエリに格納できる演算子の最大数を指定
します。
このパラメータの詳細については、『Query
Performance Guide』を参照してください。
デフォルト : 100
OPTION PERFORMANCE_MONITOR_SESSIONS
パフォーマンス モニタで監視できる同時セッション
の最大数を指定します。0 より大きい値を指定する
必要があります。
このパラメータの詳細については、『Query
Performance Guide』を参照してください。
デフォルト : 20
OPTION TMU_OPTIMIZE
TMU によるオプティマイズ モードのインデックス
作成を切り換えます。
デフォルト : OFF
OPTION XMP_TEMP_SPACE
XML ファイルの並列解析処理中に作成されるスピ
ル ファイル のディレクトリを指定します。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : QUERY_TEMPSPACE_DIRECTORY に
指定されたディレクトリ
(４/８)
B-22
Administrator’s Guide
チューニング パラメータとパフォーマンス パラメータ
ファイルのエントリ
説明
TUNE XMP_MAX_TASKS
XML 入力ファイルの解析用に割り当てられる並列
タスクの最大数を指定します。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : 1
TUNE INDEX_TEMPSPACE_THRESHOLD
インデックスの作成に使用する一時領域の最大サイ
ズ (KB または MB 単位 ) を指定します。
デフォルト サイズ : 10MB
デフォルトの単位 : KB
最大値 : 2GB
TUNE INDEX_TEMPSPACE_MAXSPILLSIZE
インデックス作成に使用できるスピル領域 ( 一時的
な領域 ) の最大サイズを KB (K)、MB (M)、GB (G)
のいずれかの単位で指定します。
デフォルト : 1GB
TUNE INDEX_TEMPSPACE_DIRECTORY
インデックスの作成に使用するスピル ファイル ( 一
時的なファイル ) のディレクトリを指定します。複
数のディレクトリに関する複数のエントリを指定し
ます。1 つの
TUNE INDEX_TEMPSPACE_DIRECTORY のパラ
メータにつき 1 つのディレクトリを指定します。
デフォルト : /tmp (UNIX) または c: ¥tmp (Windows)
TUNE QUERY_MEMORY_LIMIT
クエリ処理に使用するメモリの最大量を KB (K)、
MB (M)、GB (G) のいずれかの単位で指定します。
この上限に達すると、クエリ処理のスピル ファイル
( 一時的なファイル ) が作成されます。
デフォルト サイズ : 50MB
有効範囲 : 2MB ∼ 4GB
デフォルト : 1GB
TUNE QUERY_TEMPSPACE_MAXSPILLSIZE
クエリ処理に使用するスピル領域 ( 一時的な領域 )
の最大サイズを KB (K)、MB (M)、GB (G) のいずれ
かの単位で指定します。
(５/８)
構成ファイル
B-23
チューニング パラメータとパフォーマンス パラメータ
ファイルのエントリ
説明
TUNE QUERY_TEMPSPACE_DIRECTORY
クエリ処理に使用するスピル ファイル ( 一時的な
ファイル ) のディレクトリを指定します。複数の
ディレクトリに関する複数のエントリを指定しま
す。1 つの
TUNE QUERY_TEMPSPACE_DIRECTORY のパラ
メータにつき 1 つのディレクトリを指定します。
デフォルト : /tmp (UNIX) または c:¥tmp (Windows)
TUNE TMU_ROW_MESSAGES
LOAD 処理中に返される行メッセージの警告レベル
を指定します。
デフォルト : FULL
TUNE TMU_SERIAL_MODE
PTMU を、並列処理を使用しないシリアル モードで
実行するかどうかを指定します。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : OFF
TUNE TMU_CONVERSION_TASKS
入力データを、データを表現するために使用するプ
ラットフォーム ベースの内部形式に変換するとき
に、PTMU が使用するタスクの数を指定します。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : コンピュータに搭載されているプロ
セッサ数の半分 ( ハードウェアにより決定 )
(６/８)
B-24
Administrator’s Guide
チューニング パラメータとパフォーマンス パラメータ
ファイルのエントリ
説明
TUNE TMU_INDEX_TASKS
ロードするデータに応じてインデックス エントリを
非一意性インデックスに変換するときに、PTMU が
使用するタスクの数を指定します。非一意性イン
デックスには 1 つしかタスクを関連付けることがで
きません。このパラメータには、すべての非一意性
インデックスの処理に使用できるタスクの最大数を
指定します。実際に使用されるタスクの数は、非一
意性インデックスの数と、このパラメータで指定さ
れた数のどちらか小さい方です。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
このパラメータは、パラメータ TUNE
TMU_MAX_TASKS と同時に使用しないでくださ
い。
デフォルト : 非一意性インデックスごとに 1 タスク
TUNE TMU_INPUT_TASKS
REORG 操作でターゲット表をスキャンするときに
割り当てられるタスクの数を指定します。変換タス
クの数は常に INPUT タスクの数と同じなので、こ
のオプションは変換タスクの数も制御します。
このパラメータは、パラメータ TUNE
TMU_MAX_TASKS と同時に使用しないでくださ
い。
デフォルト : なし
TUNE TMU_MAX_TASKS
入力タスクとインデックス作成タスクに割り当てら
れるタスクの総数の上限を指定します。このパラ
メータで指定するタスクの総数は、2 以上にする必
要があります。
デフォルト : なし
TUNE TMU_MMAP_LIMIT
LOAD 操作または REORG 操作でインデックスの
マッピングに使用できるメモリの最大量を指定しま
す。
デフォルト : なし
(７/８)
構成ファイル
B-25
チューニング パラメータとパフォーマンス パラメータ
ファイルのエントリ
説明
TUNE RAMDOM_SAMPLE_MARGIN
クエリ サンプリングで返される行サンプルの要求サ
イズに対する差異の割合を指定します。返される行
の量が指定されたマージンを上回る、または下回る
場合、メッセージが出力されます。
デフォルト : 10
TUNE BAR_UNIT_SIZE
バックアップ ファイルの最大サイズを KB (K)、MB
(M)、GB (G) のいずれかの単位で指定します。
デフォルト : 256M
TUNE ADVISOR_SAMPLE_SIZE
Vista 候補ビュー分析で使用するサンプル サイズの
割合を指定します。サンプル ビューが指定されてい
ない場合、Vista 候補ビュー分析はファクト テーブ
ルのランダム サンプルを使用します。0 または 100
の値を指定すると、サンプリングは無効になり、
ファクト テーブル全体を使用して分析が行われま
す。
デフォルト : 5
TUNE BAR_UNIT_SIZE
バックアップ ファイルの最大サイズを KB (K)、MB
(M)、GB (G) のいずれかの単位で指定します。
このパラメータの詳細については、『Table
Management Utility Reference Guide』を参照してくだ
さい。
デフォルト : 256M
(８/８)
B-26
Administrator’s Guide
デフォルト パラメータ
デフォルト パラメータ
ファイルのエントリ
説明
DEFAULT ROWCOUNT
1 つのクエリの実行が停止するまでに返される最大行数を指定
します。0 を指定すると、抽出される行数に制限がなくなり
ます。
デフォルト : 0
DEFAULT INFO_MESSAGE_LIMIT
クエリごとに返される情報メッセージ (STATISTICS と
INFORMATION) の最大数を指定します。
デフォルト : 1000
DEFAULT RBW_LOADINFO_LIMIT
RBW_LOADINFO システム テーブルに記録されるすべての
TMU セッションに関する履歴ロード情報の量を指定します。
このパラメータを 256 未満の値に設定すると、
RB_DEFAULT_LOADINFO ファイルは切り捨てられますが、
元のファイルは RB_DEFAULT_LOADINFO.save として保存さ
れます。
デフォルト : 256
セグメント パラメータ
ファイルのエントリ
説明
OPTION
DEFAULT_DATA_SEGMENT
デフォルト データ セグメントを格納するディレクトリのパス
を指定します ( 複数のデータベースでデフォルト セグメントを
使用している場合は、指定しないでください )。
デフォルト : RB_PATH に指定されたディレクトリ
OPTION
DEFAULT_INDEX_SEGMENT
デフォルト インデックス セグメントを格納するディレクトリ
のパスを指定します ( 複数のデータベースでデフォルト セグメ
ントを使用している場合は、指定しないでください )。
デフォルト : RB_PATH に指定されたディレクトリ
OPTION
TEMPORARY_DATA_SEGMENT
テンポラリ テーブル用のデフォルト テンポラリ データ セグメ
ントの物理格納ユニット (PSU) を格納するディレクトリを指定
します。
デフォルト : カレント データベース ディレクトリ
(１/３)
構成ファイル
B-27
セグメント パラメータ
ファイルのエントリ
説明
OPTION
TEMPORARY_INDEX_SEGMENT
テンポラリ テーブルのデフォルトのテンポラリ インデックス
セグメントの PSU を格納するディレクトリを指定します。
デフォルト : カレント データベース ディレクトリ
OPTION SEGMENTS
テーブルまたはインデックスを削除するときに、割り当てられ
ているユーザ定義セグメントを削除するか (DROP) または保持
するか (KEEP) を指定します ( デフォルト セグメントは、必ず
削除されます )。
デフォルト : KEEP
OPTION
IGNORE_PARTIAL_INDEXES
クエリを処理する場合に、部分的に利用可能なインデックスを
無視し、全体が利用可能なインデックスだけを考慮することを
指定します。
デフォルト : OFF
OPTION
PARTIAL_AVAILABILITY
部分的に利用可能なテーブルまたはインデックスに対するクエ
リの動作を指定します。
デフォルト : PRECHECK
OPTION
IGNORE_OPTICAL_INDEXES
光セグメントに格納されているインデックスを使用するかどう
かを指定します。
デフォルト : OFF
(２/３)
B-28
Administrator’s Guide
パラメータ ADMIN
ファイルのエントリ
説明
OPTION
OPTICAL_AVAILABILITY
光セグメントに対するクエリの動作を指定します。
OPTION DEFAULT_SEGMENT_SIZE
テーブルとインデックスのデフォルト セグメントのサイズを
指定します。指定単位は KB、MB、GB のいずれかです。
DEFAULT_SEGMENT_SIZE の値を指定しなかった場合、テー
ブルのサイズの限界は 2GB (1 PSU) です。値の単位を指定しな
かった場合、デフォルトの単位は KB です。
デフォルト : WAIT_NONE
デフォルト セグメントに格納するテーブルとインデックスを
作成した場合、作成される PSU の数は
DEFAULT_SEGMENT_SIZE の値を 2GB で割った数です。
INITSIZE は 16KB です。各 PSU の MAXSIZE は 2GB から 8KB
を引いた値に設定されます。DEFAULT_SEGMENT_SIZE で設
定した値が 2GB で割り切れない場合は、最後の PSU がほかの
PSU より小さくなります。
OPTION DEFAULT_PSU_EXTENDSIZE
デフォルト セグメントに格納するテーブルとインデックスの
PSU のエクステント サイズを指定します。デフォルト値は 16K
です。指定単位は KB、MB、GB のいずれかです。単位を指定
しなかった場合、デフォルトの単位は KB です。
詳細については、「OPTION DEFAULT_SEGMENT_SIZE」を参
照してください。
(３/３)
パラメータ ADMIN
ファイルのエントリ
説明
ADMIN ACCOUNTING
デーモンの起動時に、アカウンティング機能をオンに
するかどうかを指定します。
デフォルト : OFF
ADMIN ACCT_DIRECTORY
アカウンティング レコードを格納するファイルのロ
ケーションを指定します。
デフォルト : <$RB_CONFIG>/logs (UNIX) または
<%RB_CONFIG%>¥logs (Windows)
ADMIN ACCT_MAXSIZE
アカウント ファイルの最大サイズを設定します。最
小値は 10,240KB です。
(１/３)
構成ファイル
B-29
パラメータ ADMIN
ファイルのエントリ
説明
ADMIN ACCT_LEVEL
デフォルト : 利用可能なディスク領域がなくなるまで
( カンマは入力しない )
基本的なジョブ アカウンティング レコードと、詳細
なワークロード アカウンティング レコードのどちら
を収集するかを指定します。
デフォルト : JOB
ADMIN LOGGING
ログ デーモンの起動時に、ロギング機能をオンにす
るかどうかを指定します。
デフォルト : ON
ADMIN LOG_DIRECTORY
ログ レコードを格納するログ ファイルのロケーショ
ンを指定します。
デフォルト : <$RB_CONFIG>/logs (UNIX) または
<%RB_CONFIG%>¥logs (Windows)
ADMIN LOG_MAXSIZE
ログ ファイルの最大サイズを設定します。最小値は
10KB です。
このパラメータを設定しない、あるいは 0 または負数
に設定すると、Advisor ログ ファイルの最大サイズに
制限がなくなります。
デフォルト : 利用可能なディスク領域がなくなるまで
( カンマは入力しない )
ADMIN LOG_AUDIT_LEVEL
監査イベントをログに記録する最小重要度を設定しま
す。
デフォルト : ALERT
ADMIN LOG_ERROR_LEVEL
エラー イベントをログに記録する最小重要度を設定
します。
デフォルト : ROUTINE
ADMIN LOG_OPERATIONAL_LEVEL
オペレーション イベントをログに記録する最小重要
度を設定します。
デフォルト : ALERT
ADMIN LOG_SCHEMA_LEVEL
スキーマ イベントをログに記録する最小重要度を設
定します。
デフォルト : ROUTINE
(２/３)
B-30
Administrator’s Guide
パラメータ ADMIN
ファイルのエントリ
説明
ADMIN LOG_USAGE_LEVEL
一般利用イベントをログに記録する最小重要度を設定
します。
デフォルト : ALERT
ADMIN REPORT_INTERVAL
動的システム テーブルをリフレッシュする最大間隔
を ( 分単位で ) 設定します。
デフォルト : 1 分
ADMIN RENICE_COMMAND
(UNIX)
ユーザ優先順位を変更する UNIX の renice 実行可能
ファイルの絶対パス名を指定します。絶対パス名には
ディレクトリを指定しますが、実行可能ファイルの名
前は指定しません。たとえば、/usr/ucb/renice にコマ
ンドがある場合は、このパラメータに /usr/ucb と
指定します。
デフォルト : なし
ADMIN ADVISOR_LOGGING
Advisor ログの起動状態を指定します。ON に設定する
と、ログ デーモン (rbwadmd) の起動時にログ ファイ
ルが作成され、集約ビューの使用時および候補ビュー
の生成時にログ レコードが取得されます。OFF に設定
すると、ログ ファイルは作成されず、データはログ
記録されません。
デフォルト : OFF
ADMIN ADVISOR_LOG_DIRECTORY
Advisor ログ レコードを格納するファイルのロケー
ションを指定します。
デフォルト : <$RB_CONFIG>/logs (UNIX) または
<%RB_CONFIG%>¥logs (Windows)
ADMIN ADVISOR_LOG_MAXSIZE
Advisor ログ ファイルの最大サイズを設定します。最
小値は 10,240KB です。
デフォルト : 利用可能なディスク領域がなくなるまで
( カンマは入力しない )
(３/３)
構成ファイル
B-31
パラメータ PASSWORD
パラメータ PASSWORD
ファイルのエントリ
説明
PASSWORD EXPIRATION_DAYS
各ユーザ パスワードの有効期限を日数で設定します。
デフォルト : 制限なし
PASSWORD
EXPIRATION_WARNING_DAYS
パスワードが失効する何日前から、ログイン直後の警告メッセー
ジを表示するかを設定します。
デフォルト : なし
PASSWORD
CHANGE_MINIMUM_DAYS
次にパスワードを変更するまでの、必要最低日数を指定します。
PASSWORD RESTRICT_PREVIOUS
同じパスワードを再使用できるまでに、何回以上パスワードを変
更する必要があるかを設定します。
デフォルト : 制限なし
PASSWORD
ALLOW_LOGNAME
パスワードにユーザのログイン名を使用できるかどうかを指定し
ます。
デフォルト : ON
PASSWORD
CHANGE_INITIAL
初めてログインしたときに初期パスワードを変更する必要がある
かどうかを指定します。
デフォルト : OFF
PASSWORD
COMPLEX_NUMERIC
以前のパスワードと変更後のパスワードに 1 つの数値以上の違い
が必要かどうかを指定します。
デフォルト : OFF
PASSWORD
COMPLEX_NUM_ALPHA
パスワードに使用するアルファベット文字の必要最少数を設定し
ます。
デフォルト : 0
PASSWORD
COMPLEX_NUM_NUMERICS
パスワードに使用する数字の必要最少数を設定します。
PASSWORD
COMPLEX_NUM_PUNCTUATION
パスワードに使用する句読文字の必要最少数を設定します。
デフォルト : 0
デフォルト : 0
(１/２)
B-32
Administrator’s Guide
データベース エントリ
ファイルのエントリ
説明
PASSWORD MINIMUM_LENGTH
パスワードに使用する必要最少文字数を設定します。
デフォルト : 0
PASSWORD
LOCK_FAILED_ATTEMPTS
データベースとの接続に失敗により、ユーザ アカウントをロック
するまでに許容される入力ミスの最大回数を設定します。
デフォルト : 0
PASSWORD
LOCK_PERIOD_HOURS
入力ミスの許容回数を超えた場合に、ユーザ アカウントをロック
する時間を指定します。
デフォルト : 0
(２/２)
データベース エントリ
エントリ
説明
DB AROMA
AROMA というデータベース論理名と、物理的なロケーションと
の対応を指定します。Aroma データベースがインストールされて
いる場合は、この行が構成ファイルに記述されます。
UNIX のデフォルト : DB AROMA <redbrick_dir>/aroma_db
Windows のデフォルト : DB AROMA <redbrick_dir>¥aroma_db
DB ADMIN
ADMIN というデータベース論理名と、物理的なロケーションと
の対応を指定します。
UNIX のデフォルト : DB ADMIN <redbrick_dir>/admin_db
Windows のデフォルト : DB ADMIN <redbrick_dir>¥admin_db
構成ファイル
B-33
構成パラメータのまとめ
構成パラメータのまとめ
以下の表は、データベース サーバ環境を制御する各パラメータ、設定方法、制御の
対象となるプロセスの一覧です。rbw.config に格納されている順に記載し、その後
に、SET コマンドのみで制御されるパラメータを記載します。
設定方法
パラメータ
rbw.config
RB_HOST SHMEM
(UNIX)
SQL
SET
制御されるプロセス
TMU
コマンド
サーバ
TMU
デーモン
✓
✓
✓
rbwapid
RB_HOST MAPFILE
(UNIX)
✓
✓
✓
rbwapid
RB_HOST SERVER
✓
rbwapid
✓
servermon
MAX_SERVERS
✓
rbwapid
CLEANUP_SCRIPT
✓
rbwapid
SERVER_NAME (UNIX)
✓
rbwapid
UNIFIED_LOGON
(Windows)
✓
rbwapid
LOGFILE_SIZE
✓
rbwapid
PROCESS_CHECKING_
INTERVAL
✓
rbwapid
MAX_ACTIVE_
DATABASES
✓
rbwapid
REMOTE_TMU_
LISTENER
✓
rbwapid
パラメータ RBMON
RBMON INTERVAL
(UNIX)
パラメータ RBWAPI
(１/９)
B-34
Administrator’s Guide
構成パラメータのまとめ
設定方法
パラメータ
rbw.config
SQL
SET
制御されるプロセス
TMU
コマンド
サーバ
TMU
デーモン
パラメータ NLS_LOCALE
MESSAGE_DIR
✓
✓
✓
すべて
LOCALE
✓
✓
✓
すべて
FIRST_DAYOFWEEK
✓
✓
✓
すべて
パラメータ TUNE
TMU_BUFFERS
✓
✓
✓
ROWS_PER_SCAN_
TASK
✓
✓
✓
ROWS_PER_FETCH_
TASK
✓
✓
✓
ROWS_PER_JOIN_
TASK
✓
✓
✓
QUERYPROCS
✓
✓
✓
TOTALQUERYPROCS
✓
FORCE_SCAN_TASKS
✓
✓
✓
FORCE_FETCH_TASK
✓
✓
✓
FORCE_JOIN_TASK
✓
✓
✓
FILE_GROUP
✓
✓
rbwapid
GROUP
✓
✓
rbwapid
FORCE_HASHJOIN_
TASK
✓
✓
✓
PARALLEL_
HASHJOIN
✓
✓
✓
✓
rbwapid
(２/９)
構成ファイル
B-35
設定方法
制御されるプロセス
パラメータ
rbw.config
SQL
SET
TMU
コマンド
FORCE_
AGGREGATION_
TASKS
✓
✓
✓
PARTITIONED_
PARALLEL_
AGGREGATION
✓
✓
✓
RESULT_BUFFER
✓
✓
✓
RESULT_BUFFER_
FULL_ACTION
✓
✓
✓
FILLFACTOR SI, PI,
STAR
✓
✓
✓
FILLFACTOR VARCHAR
✓
✓
✓
INDEX_TEMPSPACE_
THRESHOLD,
MAXSPILLSIZE,
DIRECTORY
✓
✓
✓
QUERY_MEMORY_
LIMIT,
QUERY_TEMPSPACE_
MAXSPILLSIZE,
DIRECTORY
✓
✓
✓
TMU_ROW_MESSAGES
✓
✓
✓
TMU_SERIAL_MODE
✓
✓
✓
TMU_CONVERSION_
TASKS
✓
✓
✓
TMU_INDEX_TASKS
✓
✓
✓
TMU_INPUT_TASKS
✓
✓
✓
TMU_MAX_TASKS
✓
✓
✓
サーバ
TMU
デーモン
(３/９)
構成パラメータのまとめ
設定方法
SQL
SET
制御されるプロセス
TMU
コマンド
パラメータ
rbw.config
TMU_MMAP_LIMIT
✓
RANDOM_SAMPLE_
MARGIN
✓
✓
✓
ADVISOR_SAMPLE_
SIZE
✓
✓
✓
BAR_UNIT_SIZE
✓
✓
BAR_XBSA_LIB
✓
✓
BAR_SM_USER
✓
✓
サーバ
✓
TMU
デーモン
✓
✓
✓
パラメータ OPTION
AUTOROWGEN
✓
✓
✓
ARITHABORT
✓
✓
✓
ALLOW_POSSIBLE_
DEADLOCK
✓
✓
✓
READER_PRIORITY
✓
CROSS_JOIN
✓
✓
✓
COUNT_RESULT
✓
✓
✓
CHECK_REPORT_
FILE_PERMISSIONS
✓
CHECK_TABLE_INDEX
_DIRECTORY
✓
GRANT_TEMP_
RESOURCE_TO_ALL
✓
ADVISOR_LOGGING
✓
✓
✓
✓
✓
✓
✓
✓
(４/９)
構成ファイル
B-37
構成パラメータのまとめ
設定方法
制御されるプロセス
パラメータ
rbw.config
SQL
SET
UNIFORM_
PROBABILITY_FOR_
ADVISOR
✓
✓
✓
PRECOMPUTED_
VIEW_QUERY_
REWRITE
✓
✓
✓
ADVISOR_MAXIMUM_
CANDIDATE_VIEWS
✓
✓
✓
USE_INVALID_
PRECOMPUTED_
VIEWS
✓
✓
✓
VERSIONING
✓
✓
✓
✓
TRANSACTION_
ISOLATION_LEVEL
✓
✓
✓
✓
TMU_VERSIONING
✓
TMU_COMMIT_
REPORT_INTERVAL
✓
✓
✓
TMU_COMMIT_TIME_
INTERVAL
✓
✓
✓
EXPORT_DEFAULT_
PATH
✓
EXPORT_DELIMITER
✓
EXPORT_MAX_FILE_
SIZE
✓
IDLE_TIMEOUT
✓
PRECOMPUTED_
VIEW_MAINTENANCE
✓
✓
TMU
コマンド
サーバ
TMU
デーモン
✓
✓
✓
✓
✓
✓
✓
✓
(５/９)
B-38
Administrator’s Guide
構成パラメータのまとめ
設定方法
制御されるプロセス
パラメータ
rbw.config
SQL
SET
TMU
コマンド
PRECOMPUTED_
VIEW_MAINTENANCE_
ON_ERROR
✓
✓
TMU_OPTIMIZE
✓
PERFORMANCE_
MONITOR_
COMMANDS
✓
✓
rbwpmond
PERFORMANCE_
MONITOR_
MAXOPERATORS
✓
✓
rbwpmond
PERFORMANCE_
MONITOR_
MAXSESSIONS
✓
✓
rbwpmond
サーバ
TMU
✓
✓
デーモン
✓
パラメータ SEGMENT
DEFAULT_DATA_
SEGMENT
✓
✓
✓
DEFAULT_INDEX_
SEGMENT
✓
✓
✓
TEMPORARY_DATA_
SEGMENT
✓
✓
✓
TEMPORARY_INDEX_
SEGMENT
✓
✓
✓
SEGMENTS (DROP,
KEEP)
✓
✓
✓
IGNORE_PARTIAL_
INDEXES
✓
✓
✓
PARTIAL_
AVAILABILITY
✓
✓
✓
(６/９)
構成ファイル
B-39
構成パラメータのまとめ
設定方法
制御されるプロセス
パラメータ
rbw.config
SQL
SET
TMU
コマンド
IGNORE_OPTICAL_
INDEXES
✓
✓
✓
OPTICAL_
AVAILABILITY
✓
✓
✓
DEFAULT_
SEGMENT_SIZE
✓
✓
✓
DEFAULT_PSU_
EXTENDSIZE
✓
✓
✓
ROWCOUNT
✓
✓
✓
INFO_MESSAGE_
LIMIT
✓
RBW_LOADINFO_
LIMIT
✓
サーバ
TMU
デーモン
パラメータ DEFAULT
✓
✓
パラメータ ADMIN
* UNIX では、SQL ALTER SYSTEM 文でこれらのパラメータを設定することができます。
ACCOUNTING*
✓
rbwlogd
ACCT_DIRECTORY
✓
rbwlogd
ACCT_LEVEL*
✓
rbwlogd
ACCT_MAXSIZE *
✓
rbwlogd
ADVISOR_
LOGGING *
✓
✓
rbwlogd
ADVISOR_LOG_
DIRECTORY
✓
✓
rbwlogd
ADVISOR_LOG_
MAXSIZE
✓
✓
rbwlogd
(７/９)
B-40
Administrator’s Guide
構成パラメータのまとめ
設定方法
SQL
SET
制御されるプロセス
TMU
コマンド
パラメータ
rbw.config
LOGGING*
✓
rbwlogd
LOG_AUDIT_LEVEL *
✓
rbwlogd
LOG_DIRECTORY
✓
rbwlogd
LOG_ERROR_LEVEL *
✓
rbwlogd
LOG_MAXSIZE *
✓
rbwlogd
LOG_OPERATIONAL_
LEVEL *
✓
rbwlogd
LOG_SCHEMA_
LEVEL *
✓
rbwlogd
LOG_USAGE_LEVEL*
✓
rbwlogd
REPORT_INTERVAL
✓
RENICE_COMMAND
(UNIX)
✓
✓
EXPIRATION_DAYS
✓
✓
✓
EXPIRATION_
WARNING_DAYS
✓
✓
✓
CHANGE_MINIMUM_D
AYS
✓
✓
RESTRICT_PREVIOUS
✓
ALLOW_LOGNAME
✓
✓
CHANGE_INITIAL
✓
✓
COMPLEX_NUMERIC
✓
✓
✓
サーバ
✓
TMU
デーモン
✓
パラメータ PASSWORD
(８/９)
構成ファイル
B-41
構成パラメータのまとめ
設定方法
SQL
SET
制御されるプロセス
TMU
コマンド
パラメータ
rbw.config
COMPLEX_NUM_
ALPHA
✓
✓
COMPLEX_NUM_
NUMERICS
✓
✓
✓
COMPLEX_NUM_
PUNCTUATION
✓
✓
✓
MINIMUM_LENGTH
✓
✓
✓
LOCK_FAILED_
ATTEMPTS
✓
✓
✓
LOCK_PERIOD_
HOURS
✓
✓
✓
✓
✓
✓
サーバ
TMU
デーモン
その他のパラメータ
DB データベース論理名
LOCK (WAIT, NO WAIT)
✓
すべて
✓
✓
✓
LOCK (table, database)
✓
✓
ORDER_BY_ASC_
NULL, ORDER_BY_
DESC_NULL
✓
✓
✓
* UNIX では、SQL ALTER SYSTEM 文でこれらのパラメータを設定することができます。
(９/９)
B-42
Administrator’s Guide
付録
システム テーブルと動
的統計テーブル
付録 C では、IBM Red Brick Warehouse のシステム カタログ、システム
テーブル、動的統計テーブル (DST) について説明します。テーブルご
とに、列名、データ型、列の内容も記載します。
付録 C では、以下について説明します。
■
■
■
システム カタログ
動的統計テーブル
データ型とデータのサイズ
システム カタログ
IBM Red Brick Warehouse のデータベースに格納されているデータの管
理情報は、システム テーブルに格納されています。システム テーブ
ルの内容を表示するには SELECT 文を使用します。この制御文にシス
テム テーブル ジョインを含めることができます。ただし、システム
テーブル内のデータは読み取り専用なので、データの挿入、更新、お
よび削除はできません。
以下のコマンドを実行すると、そのユーザがアクセスできるテーブル
が表示されます。システム テーブルと、そのユーザが利用できるユー
ザ作成テーブルの一覧です。
select * from rbw_tables ;
システム カタログ
システム カタログは、システム テーブルの一覧を格納したものです。システム
テーブルには、データベース全体の情報が格納されています。システム テーブルに
格納された情報をユーザが表示する場合、そのユーザが作成したテーブルまたはア
クセス権を持っているテーブルとテーブル情報だけが表示されます。各ユーザが作
成したテーブル、アクセス可能なテーブルは、RBW_TABAUTH システム テーブル
と RBW_USERAUTH システム テーブルに格納されています。
テーブル名
テーブルの内容
RBW_COLUMNS
RBW_TABLES のすべてのオブジェクトの各列の情報を格納
します。
RBW_CONSTRAINTS
CREATE TABLE 文で設定したプライマリ キーとフォーリン
キー制約の情報を格納します。
RBW_CONSTRAINTCOLUMNS
CREATE TABLE 文で設定したプライマリ キー制約とフォー
リン キー制約を構成する列名を格納します。
RBW_HIERARCHIES
指定された階層構造内の関係を示します。
RBW_INDEXCOLUMNS
RBW_INDEXES の各インデックスのキーを構成する列を格
納します。
RBW_INDEXES
RBW_TABLES のすべてのテーブルについて、インデックス
の情報を格納します。
RBW_LOADINFO
ロード操作の統計値を格納します。
RBW_MACROS
データベースに設定されているすべてのマクロの情報を格納
します。
RBW_OPTIONS
チューニングが可能なデータベース パラメータについて、現
在の設定値を格納します。
RBW_PRECOMPVIEW_CANDIDATES
候補ビューの Advisor システム テーブル (『IBM Red Brick
Vista User’s Guide』参照 )
RBW_PRECOMPVIEW_UTILIZATION
データベース内に定義されたビューの Advisor システム テー
ブル (『IBM Red Brick Vista User’s Guide』参照 )
RBW_PRECOMPVIEWCOLUMNS
集約テーブルと事前計算ビューの関係を示します。
RBW_RELATIONSHIPS
プライマリ キーとフォーリン キーの関係を共有するテーブル
と、各関係に適用する制約名を格納します。
RBW_ROLE_MEMBERS
すべてのユーザ定義ロールと、それを付与されたユーザおよ
びロールの関係を格納します。
(１/２)
C-2 Administrator’s Guide
システム カタログ
テーブル名
テーブルの内容
RBW_ROLES
データベースに定義されているすべてのユーザ作成ロールの
情報を格納します。
RBW_SEGMENTS
システム内のすべてのセグメントの情報を格納します。DBA
または RESOURCE システム ロールまたは ACCESS_ANY ア
クセス権を持っているユーザだけがこのテーブルにアクセス
することができます。
RBW_STORAGE
システムに使用されている物理記憶装置 (PSU) の情報を格納
します。DBA または RESOURCE システム ロールまたは
ACCESS_ANY アクセス権を持っているユーザだけがこの
テーブルにアクセスすることができます。
RBW_SYNONYMS
RBW_TABLES にあるテーブルについて、すべてのテーブル
シノニムの情報を格納します。
RBW_TABAUTH
RBW_TABLES のオブジェクトについて、アクセス権の付与
の状況を格納します。
RBW_TABLES
データベースにある、システム テーブルを含むすべてのテー
ブル、ビュー、シノニムの情報を格納します。
RBW_USERAUTH
データベースの使用を許可されたユーザに付与されているア
クセス権の情報を格納します。
RBW_VIEWS
RBW_TABLES にあるビューの情報を格納します。
RBW_VIEW_REFERENCES
ビューの参照するテーブルの情報を格納します。
RBW_VIEWTEXT
RBW_VIEWS のすべてのビューについて、ビューのテキスト
を格納します。
(２/２)
システム テーブルと動的統計テーブル
C-3
RBW_COLUMNS テーブル
RBW_COLUMNS テーブル
RBW_COLUMNS テーブルは、RBW_TABLES テーブルに格納されているすべての
データベース オブジェクトについて、各オブジェクトの列の情報を格納します。
ユーザが RBW_COLUMNS テーブルに格納されている情報を表示する場合、その
ユーザが作成したかアクセス権を持っているオブジェクト内の列だけが表示されま
す。このテーブルは、TABLE、VIEW、SYNONYM に対する ALTER、CREATE、
DROP の各コマンドで更新されます。テーブルを構成する列は以下のとおりです。
列名
列タイプ
列の内容
NAME
CHAR(128)
列の名前。
TNAME
CHAR(128)
テーブルの名前。
SEQ
SMALLINT
テーブル列の構成順序。
TYPE
CHAR(12)
列のデータ型。
LENGTH
SMALLINT
列のバイト数。
PRECISION
SMALLINT
指定または暗黙に示された数値精度。
TIME 列と TIMESTAMP 列の場合、数字
は小数秒を示します。
SCALE
SMALLINT
指定された拡大 / 縮小ファクタ。
START
INTEGER
SERIAL 列定義の開始値。
STEP
INTEGER
SERIAL 列のステップ値の定義。
NULLS
CHAR(1)
NULL を許すかを示すフラグ (Y または
N)。
UNIQ
CHAR(1)
列値が一意かを示すフラグ (Y または N)。
PKSEQ
SMALLINT
プライマリ キーの列順。プライマリ キー
を構成しない列の場合は 0。
TID
SMALLINT
テーブル識別子。
DEFAULTVALUE
VARCHAR(1022)
列のデフォルト値。
SEGSEQ
SMALLINT
セグメント範囲指定におけるセグメント
化の基準列の順序 ( セグメント化の基準
列は 1、それ以外の列は 0、ビューは
NULL)。
(１/２)
C-4 Administrator’s Guide
RBW_CONSTRAINTCOLUMNS テーブル
列名
列タイプ
列の内容
FILLFACTOR
SMALLINT
最大長のパーセンテージで示される
VARCHAR 列の見積もり長。デフォルト
は 10。
USAGE
CHAR(16)
列の用途。
COMMENT
CHAR(256)
ユーザが指定するコメント。ALTER
TABLE、ALTER SYNONYM、または
ALTER VIEW 文で設定しなかった場合は
NULL。
(２/２)
RBW_CONSTRAINTCOLUMNS テーブル
RBW_CONSTRAINTCOLUMNS テーブルは、CREATE TABLE 文でプライマリ キー
とフォーリン キー制約を設定した列を示します。
列名
列タイプ
列の内容
CONSTRAINT_N
AME
CHAR(128)
制約の名前。
TNAME
CHAR(128)
制約を含むテーブルの名前。
CNAME
CHAR(128)
制約が設定されている列の名前。
COLSEQ
INTEGER
制約定義における列の順番。
システム テーブルと動的統計テーブル
C-5
RBW_CONSTRAINTS テーブル
RBW_CONSTRAINTS テーブル
RBW_CONSTRAINTS テーブルは、CREATE TABLE 文で設定したプライマリ キー
とフォーリン キー制約の情報を格納します。
列名
列タイプ
列の内容
NAME
CHAR(128)
制約の名前。
ID
INTEGER
制約の内部識別番号。
TYPE
CHAR(11)
制約の種類 : PRIMARY KEY または FOREIGN KEY。
TNAME
CHAR(128)
制約を含むテーブルの名前。
CREATOR
CHAR(128)
テーブルを作成したユーザ、あるいは最後にテーブ
ルを変更したユーザ。
RBW_HIERARCHIES テーブル
RBW_HIERARCHIES テーブルは、階層構造内のテーブルと列の関係を示します。
列名
列タイプ
列の内容
NAME
CHAR(128)
階層構造の名前。
FROM_TABLE
CHAR(128)
値のマッピング元のテーブル。
FROM_COLUMN
CHAR(128)
値のマッピング元の列。
TO_ TABLE
CHAR(128)
値のマッピング先のテーブル。
TO_COLUMN
CHAR(128)
値のマッピング先の列。
CONSTRAINT_NAME
CHAR(128)
ロールアップ関係の定義に使用したキー制
約を指定します。ロールアップ関係が同じ
テーブル内の場合は NULL。
C-6 Administrator’s Guide
RBW_INDEXCOLUMNS テーブル
RBW_INDEXCOLUMNS テーブル
RBW_INDEXCOLUMNS テーブルは、RBW_INDEXES テーブルに格納されている
すべてのインデックスについて、インデックス キーの情報を格納します。インデッ
クス キーを構成する列ごとに、1 行ずつ格納されています。
RBW_INDEXES テーブルの情報をユーザが検索すると、そのユーザが作成したオ
ブジェクトか、アクセスを許可されたオブジェクトのインデックスだけが返されま
す。このテーブルは、CREATE TABLE、DROP TABLE、CREATE INDEX、DROP
INDEX の各コマンドで更新されます。テーブルを構成する列は、次のとおりです。
列名
列タイプ
列の内容
INAME
CHAR(128)
インデックスの名前。
TNAME
CHAR(128)
テーブルの名前。
CNAME
CHAR(128)
キーを構成する列名。
SEQ
SMALLINT
キーの構成順序。
FKNAME
CHAR(128)
STAR インデックスに対するフォーリン キー制約の
名前。STAR インデックス以外は NULL。
RBW_INDEXES テーブル
RBW_INDEXES テーブルは、RBW_TABLES テーブルに格納されているすべての
オブジェクトについて、各オブジェクトのインデックスの情報を格納します。
RBW_INDEXES テーブルの情報をユーザが検索すると、そのユーザが作成したオ
ブジェクトか、アクセスを許可されたオブジェクトの列に設定されたインデックス
だけが返されます。このテーブルは、CREATE TABLE、DROP TABLE、ALTER
INDEX、CREATE INDEX、DROP INDEX の各コマンドで更新されます。テーブルを
構成する列は、次のとおりです。
列名
列タイプ
列の内容
NAME
CHAR(128)
インデックスの名前。デフォルトのプライマリ
キー インデックスには <table_name>_PK_IDX と
いう名前が付けられます。
TNAME
CHAR(128)
テーブルの名前。
TYPE
CHAR(7)
インデックスの種類 − BTREE、STAR、TARGET、
TARGETS、TARGETM、または TARGETL。
(１/２)
システム テーブルと動的統計テーブル
C-7
RBW_INDEXES テーブル
列名
列タイプ
列の内容
LOCAL
CHAR(1)
インデックスがローカル インデックスであるかど
うかを示すフラグ。ローカル インデックスでは、
各インデックス セグメントが対応するテーブル セ
グメント内の行データを参照します (Y または N)。
CNAME
CHAR(128)
インデックスの付いた列の名前。複数の列イン
デックスの、最初の名前。
CREATOR
CHAR(128)
インデックスの作成者。
DATETIME
TIMESTAMP
インデックスの作成日時。NULL は、インデックス
を作成中であることを示します。
FILLFACTOR
INTEGER
インデックスのフィル ファクタ設定。
INTACT
CHAR(1)
インデックスが正常 (Y) か、未修復の破損が検出
されている (N) かを示すフラグ。
PARTIAL
CHAR(1)
オフライン セグメントがある時、テーブルが部分
的にのみ利用可能であるかを示すフラグ (Y または
N)。
STATE
CHAR(20)
VALID、INVALID、BUILDING。
COMMENT
CHAR(256)
ユーザが設定したコメント。ALTER INDEX 文で
設定しなかった場合は NULL。
(２/２)
C-8 Administrator’s Guide
RBW_LOADINFO テーブル
RBW_LOADINFO テーブル
RBW_LOADINFO テーブルは、テーブルおよびオフライン セグメントへのデータ
ロードの履歴を格納します。このテーブルは、LOAD DATA 文によって更新され、
ロード操作ごとに 1 行ずつ格納されています。最新の 256 行が格納されます。それ
より古い行は自動的に削除されます。テーブルを構成する列は、以下のとおりで
す。
列名
列タイプ
列の内容
TNAME
CHAR(128)
テーブルの名前。
SEGNAME
CHAR(128)
オフライン セグメントにロードした
場合のセグメント名。オフライン
ロードでない場合は NULL。
USERNAME
CHAR(128)
ロードを実行したユーザの名前。
STARTED
TIMESTAMP
ロードの開始日時。
FINISHED
TIMESTAMP
ロードの完了日時。
MODE
CHAR(20)
行を挿入したり修正するためのモー
ド (INSERT、REPLACE、APPEND、
MODIFY、MODIFY AGGREGATE、
UPDATE、UPDATE AGGREGATE)。
STATUS
CHAR(128)
成功 (Success): 正常にロードを完了。
未完了 (Incomplete): ロード中に、致
命的ではないエラーが発生。整合性
保持のためのテーブル ロールバック
と、処理状況の表示が可能。
エラー (Error): テーブル変更前の初期
段階、またはテーブル変更後にテー
ブル ロールバックが失敗したため
テーブルの整合性がとれず、ロード
に失敗。
INSERTED
DECIMAL(18)
挿入された行数。
UPDATED
DECIMAL(18)
更新された行数。
SKIPPED
DECIMAL(18)
START RECORD 句の指定により、読
み飛ばされた入力ファイルの行数。
DISCARDED
DECIMAL(18)
破棄された入力ファイルの行数。
(１/２)
システム テーブルと動的統計テーブル
C-9
RBW_MACROS テーブル
列名
列タイプ
列の内容
AUTOROWGEN
CHAR(1)
自動生成された行の有無 (Y または
N)。
COMMENT
CHAR(256)
ユーザが設定したコメント。LOAD
DATA 文以外で設定した場合は NULL。
TRANSACTION_TYPE
CHAR(32)
コマンドのトランザクション タイ
プ。戻り値 : READ_ONLY、
VERSIONING、BLOCKING。
READ_REVISION
DECIMAL(10,0)
トランザクションがアクセスした
データベースのリビジョン番号
NEW_REVISION
DECIMAL(10,0)
トランザクションが作成したデータ
ベースのリビジョン番号。トランザ
クションが中止されるか、コミット
されなかった場合は NULL。
(２/２)
RBW_MACROS テーブル
RBW_MACROS テーブルは、データベースにあるすべてのマクロの情報を格納し
ます。DBA システム ロールのメンバーか、ACCESS_ANY 権限を持っているユーザ
が RBW_MACROS テーブルの情報を検索すると、すべてのパブリック マクロとプ
ライベート マクロを参照できます。ほかのユーザは、自身が作成したマクロか、
PUBLIC として定義されたマクロだけを参照できます。テンポラリ マクロの情報
は、作成者だけが参照できます。このテーブルは、CREATE MACRO と DROP
MACRO コマンドによって更新されます。テーブルを構成する列は次のとおりです。
列名
列タイプ
列の内容
NAME
CHAR(128)
マクロの名前。
TYPE
CHAR(9)
マクロの種類 : PUBLIC、PRIVATE、TEMPORARY。
NARGS
SMALLINT
予想されるマクロの引数の数。
CREATOR
CHAR(128)
マクロの作成者。
DATETIME
TIMESTAMP
マクロの作成日時。
(１/２)
C-10
Administrator’s Guide
RBW_OPTIONS テーブル
列名
列タイプ
列の内容
CATEGORY
SMALLINT
マクロのシンタックス カテゴリ。IBM Red Brick
Warehouse では 256 未満の値を定義することができ
ます。CREATE MACRO 文で設定しなかった場合は
NULL。
IBM Red Brick Warehouse が定義するカテゴリの詳細
については、『SQL Reference Guide』を参照してく
ださい。
COMMENT
CHAR(256)
ユーザが設定したコメントまたは記述データ。
CREATE MACRO 文または ALTER MACRO 文で設定
していない場合は NULL。
TEXT
CHAR(1024)
マクロ定義のテキスト。
(２/２)
RBW_OPTIONS テーブル
RBW_OPTIONS テーブルは、データベースに格納されているチューニング用のパ
ラメータの値を格納します。このテーブルは、現行セッション中にユーザが SET コ
マンドを実行すると更新されます。テーブルを構成する列は以下のとおりです。
列名
列タイプ
列の内容
USERNAME
CHAR(128)
セッションを実行しているユーザの名前
OPTION_NAME
CHAR(128)
パラメータの名前
VALUE
CHAR(1024)
パラメータの現在の設定値
RBW_PRECOMPVIEW_CANDIDATES テーブル
RBW_PRECOMPVIEW_CANDIDATES Advisor システム テーブルの詳細について
は、『IBM Red Brick Vista User’s Guide』を参照してください。
RBW_PRECOMPVIEW_UTILIZATION テーブル
RBW_PRECOMPVIEW_UTILIZATION Advisor システム テーブルの詳細について
は、『IBM Red Brick Vista User’s Guide』を参照してください。
システム テーブルと動的統計テーブル
C-11
RBW_PRECOMPVIEWCOLUMNS テーブル
RBW_PRECOMPVIEWCOLUMNS テーブル
RBW_PRECOMPVIEWCOLUMNS テーブルは、集約テーブルの列と事前計算
ビューの列の関係を示します。
列名
列タイプ
列の内容
TNAME
CHAR(128)
事前計算ビューに関連付けられた集約テーブルの名
前。
TCOLUMN
CHAR(128)
集約テーブルの列の名前。
VNAME
CHAR
事前計算ビューの名前。
VCOLUMN
CHAR
事前計算ビューの列の名前。
RBW_RELATIONSHIPS テーブル
RBW_RELATIONSHIPS テーブルは、スキーマ内の各テーブル間におけるプライマ
リ キーとフォーリン キーの関係を格納します。テーブルを構成する列は以下のと
おりです。
列名
列タイプ
列の内容
PKTABLE
CHAR(128)
参照先 ( ディメンジョン ) テーブルの名前。
FKTABLE
CHAR(128)
参照元 ( ファクト ) テーブルの名前。
PKCONSTRAINT
CHAR(128)
参照先テーブルのプライマリ キー制約の名前。
CREATE TABLE 文で制約名を指定しなかった場
合は、テーブル名に文字列
_PKEY_CONSTRAINT を付加した名前が生成さ
れる。
(１/２)
C-12
Administrator’s Guide
RBW_ROLE_MEMBERS テーブル
列名
列タイプ
列の内容
FKCONSTRAINT
CHAR(128)
参照元テーブルに指定されたフォーリン キー制
約の名前。CREATE TABLE 文で制約名を指定し
なかった場合は、テーブル名に文字列
_FKEY<N>_CONSTRAINT を付加した名前が生
成される (<N> は、参照元テーブルの指定にお
けるフォーリン キー指定の順序を示す数字 )。
DELACTION
CHAR(9)
DELETE にともなう動作 : CASCADE、
NO_ACTION。
CREATOR
CHAR(128)
テーブルの作成者。
(２/２)
RBW_ROLE_MEMBERS テーブル
RBW_ROLE_MEMBERS テーブルは、ユーザが作成したロールとそのメンバー ( そ
のロールを付与されたすべてのユーザとロール ) の関係を格納します。ユーザが
RBW_ROLE_MEMBERS に格納されている情報を表示する場合、そのユーザがメ
ンバーであるすべてのユーザ定義ロールを参照できます。このテーブルは、
GRANT および REVOKE コマンドによって更新されます。
列名
列タイプ
列の内容
ROLENAME
CHAR(128)
ロールの名前。
USERNAME
CHAR(128)
ROLENAME を付与された、ユーザまたはユーザ作
成ロールの名前。
INDIRECT
CHAR(1)
ユーザまたはユーザ作成ロールが、ROLENAME の
間接メンバー (Y) か、直接メンバーか (N) かを示す
フラグ。
ADDED
TIMESTAMP
ユーザまたはユーザ定義ロールが、ROLENAME の
メンバーになった日時。
システム テーブルと動的統計テーブル
C-13
RBW_ROLES テーブル
RBW_ROLES テーブル
RBW_ROLES テーブルは、データベースにあるユーザ定義ロールの情報を格納し
ます。RBW_ROLES テーブルに格納されている情報をユーザが検索すると、デー
タベースにあるすべてのユーザ定義ロールを参照できます。
列名
列タイプ
列の内容
NAME
CHAR(128)
ロールの名前。
CREATOR
CHAR(128)
ロールの作成者。
CREATED
TIMESTAMP
ロールの作成日時。
COMMENT
CHAR(256)
ユーザが設定したコメント。ALTER ROLE 文で設
定しなかった場合は NULL。
RBW_SEGMENTS テーブル
RBW_SEGMENTS テーブルは、システムのすべてのセグメントの情報を格納しま
す。DBA または RESOURCE システム ロールのメンバーか、ACCESS_ANY 権限を
持っているユーザが RBW_SEGMENTS テーブルの情報を検索すると、すべてのセ
グメントを参照できます。CONNECT システム ロールのメンバーは、どのセグメン
トも参照できません。このテーブルは、ALTER SEGMENT、CREATE SEGMENT、
DROP SEGMENT、CREATE TABLE、DROP TABLE、CREATE INDEX、DROP
INDEX、BACKUP、RESTORE、LOAD DATA の各コマンドによって更新されます。
テーブルを構成する列は以下のとおりです。
列名
列タイプ
列の内容
NAME
CHAR(128)
セグメントの名前。
TNAME
CHAR(128)
行データまたはインデックスのセグメン
トを使用するテーブルの名前。アタッチ
されていないセグメントの場合は NULL。
CREATOR
CHAR(128)
セグメントの作成者。
DATETIME
TIMESTAMP
セグメントの作成日時。
NPSUS
INTEGER
セグメントに使用されている物理格納ユ
ニット (PSU) の数。
(１/４)
C-14
Administrator’s Guide
RBW_SEGMENTS テーブル
列名
列タイプ
列の内容
NCOLS
INTEGER
データまたはインデックスのセグメント
化に使用されている列の数。
MINKEY
VARCHAR(1024)
セグメント内で最小のキー値。STAR イ
ンデックスの場合、このキー値は
segname rownum の形式です。segname は
参照先のテーブルにアタッチされたセグ
メントを識別し、rownum はそのセグメ
ント内の行を識別します。
MAXKEY
VARCHAR(1024)
セグメント内で最大のキー値。STAR イ
ンデックスの場合、このキー値は
segname rownum の形式です。segname は
参照先のテーブルにアタッチされたセグ
メントを識別し、rownum はそのセグメ
ント内の行を識別します。
ID
INTEGER
セグメント ID。
TOTALFREE
INTEGER
セグメントの未使用スペース (KB)。
9-35 ページ「TOTALFREE 列」を参照。
INAME
CHAR(128)
セグメントを使用するインデックスの名
前。アタッチされていないセグメントお
よび行データ セグメントの場合は NULL。
ONLINE
CHAR(1)
オンライン セグメントかを示すフラグ (Y
または N)。システム セグメントの場合は
NULL。
OPTICAL
CHAR(1)
光ディスク上の PSU がセグメントに含ま
れているかを示すフラグ (Y または N)。
( システム セグメントの場合は NULL。）
INTACT
CHAR(1)
セグメントが正常 (Y) か、未修復の破損
が検出されている (N) かを示すフラグ。
システム セグメントの場合は NULL。
(２/４)
システム テーブルと動的統計テーブル
C-15
RBW_SEGMENTS テーブル
列名
列タイプ
列の内容
INSYNCH
CHAR(1)
行の内容がテーブルのインデックスと同
期しているかどうかを示すフラグ。オフ
ライン セグメントの場合は Y または N、
オンライン セグメントの場合は Y、イン
デックス セグメント、アタッチされてい
ないセグメント、システム セグメントの
場合は NULL。
LAST_OFFLINE
TIMESTAMP
セグメントが最後にオフラインにされた
日時。初期値は、セグメントの作成日
時。
LAST_ONLINE
TIMESTAMP
セグメントが最後にオンラインにされた
日時。初期値は、セグメントの作成日
時。
LAST_LOAD
TIMESTAMP
セグメントに対する最新のオフライン
ロードの完了日時。初期値は NULL。
COMMENT
CHAR(256)
ユーザが設定したコメント。ALTER
SEGMENT 文で設定していない場合は
NULL。
LOCAL_ID
SMALLINT
RBW_SEGID シュード列に返されるセグ
メント ID。戻り値 :
■ テーブル セグメントの RBW_SEGID
■ ローカル インデックスの一部であるセ
グメントの場合は、対応するデータ セ
グメントの LOCAL_ID
■ STAR インデックス セグメント、非
ローカル インデックス セグメント、ま
たはアタッチされていないセグメント
の場合は NULL
(３/４)
C-16
Administrator’s Guide
RBW_STORAGE テーブル
列名
列タイプ
列の内容
USAGE
CHAR(32)
セグメントが実行中の操作。戻り値 : :
UNUSED、TABLE、INDEX、LOAD_WORK、
LOAD_INDEX、BACKUP_DATA、
VERSION_LOG。
ROWCOUNT
DECIMAL(10)
セグメントの行数。
DEFAULT_SEG
CHAR(1)
セグメントがデフォルト セグメント (Y)
か、名前付きセグメント (N) かを示すフ
ラグ。
(４/４)
RBW_STORAGE テーブル
RBW_STORAGE テーブルは、システムの PSU を格納します。DBA または
RESOURCE システム ロールのメンバーか、ACCESS_ANY 権限を持っているユーザ
が RBW_STORAGE テーブルの情報を検索すると、すべての PSU を参照できます。
CONNECT システム ロールのメンバーは、どの PSU も参照できません。このテーブ
ルは、CREATE SEGMENT、DROP SEGMENT、CREATE TABLE、DROP TABLE、
CREATE INDEX、DROP INDEX、BACKUP の各コマンドによって更新されます。
テーブルを構成する列は次のとおりです。
列名
列タイプ
列の内容
SEGNAME
CHAR(128)
PSU の所属するセグメント名。
SEGID
SMALLINT
PSU の所属するセグメントの ID。
PSEQ
INTEGER
セグメントを構成する PSU の順序。
LOCATION
CHAR(1024)
PSU のロケーション。
MAXSIZE
INTEGER
PSU の最大サイズ (KB)。9-33 ページ
「MAXSIZE 列」、9-39 ページ「セグメ
ントへの領域の割り当て方法」、および
9-54 ページ「PSU サイズの変更」を参
照。
INITSIZE
INTEGER
PSU の初期サイズ (KB)。9-54 ページ
「PSU サイズの変更」参照。
(１/２)
システム テーブルと動的統計テーブル
C-17
RBW_SYNONYMS テーブル
列名
列タイプ
列の内容
EXTENDSIZE
INTEGER
PSU を拡張する際の増分の単位 (KB)。
9-54 ページ「PSU サイズの変更」参照。
USED
INTEGER
INTACT
CHAR(1)
PSU が正常 (Y) か、未修復の破損が検出
されている (N) かを示すフラグ。システ
ム セグメントの場合は NULL。
PHYSICAL_LOCATION
CHAR(1024)
PSU の実際の場所。
PSU の使用済み領域 (KB)。9-34 ページ
「USED 列」参照。
(２/２)
RBW_SYNONYMS テーブル
RBW_SYNONYMS テーブルは、データベースにあるすべてのテーブルについて、
テーブル シノニムの情報を格納します。RBW_SYNONYMS テーブルの情報をユー
ザが検索すると、そのユーザが作成したシノニムか、アクセスを許可されたシノニ
ムだけが返されます。このテーブルは、ALTER SYNONYM、CREATE SYNONYM、
DROP SYNONYM の各コマンドで更新されます。テーブルを構成する列は、次のと
おりです。
C-18
列名
列タイプ
列の内容
NAME
CHAR(128)
シノニムの名前。
TNAME
CHAR(128)
シノニムの参照先テーブルの名前。
CREATOR
CHAR(128)
シノニムの作成者。
COMMENT
CHAR(256)
ユーザが設定したコメント。ALTER SYNONYM 文で
設定しなかった場合は NULL。
Administrator’s Guide
RBW_TABAUTH テーブル
RBW_TABAUTH テーブル
RBW_TABAUTH テーブルは、テーブルのオブジェクト特権の付与状況を格納しま
す。RBW_TABAUTH テーブルの情報をユーザが検索すると、そのユーザが作成し
たテーブルか、アクセスを許可されたテーブルに対するオブジェクト特権だけが返
されます。このテーブルは、GRANT および REVOKE コマンドによって更新されま
す。テーブルを構成する列は次のとおりです。
列名
列タイプ
列の内容
GRANTEE
CHAR(128)
テーブルまたはビューに対するオブジェクト特権が
付与されているユーザまたはロール ( ユーザが作成
したロールにオブジェクト権限を付与できる )。
GRANTOR
CHAR(128)
GRANTEE ( 被付与者 ) に特権を付与したユーザ。
TNAME
CHAR(128)
テーブル、ビュー、またはシノニムの名前。
SELAUTH
CHAR(1)
被付与者が SELECT 特権を持っているかどうか (Y、
N、R、I のいずれか )。
INSAUTH
CHAR(1)
被付与者が INSERT 特権を持っているかどうか (Y、
N、R、I のいずれか )。
DELAUTH
CHAR(1)
被付与者が DELETE 特権を持っているかどうか (Y、
N、R、I のいずれか )。
UPDAUTH
CHAR(1)
被付与者が UPDATE 特権を持っているかどうか (Y、
N、R、I のいずれか )。
DATETIME
TIMESTAMP
オブジェクト特権が付与された日時。
次の表はアクセス権を示したものです。
値
説明
Y
ユーザがタスク権限を持っている。
N
ユーザがタスク権限を持っていない。
R
ユーザがロールにより直接的にオブジェクト権限を持っている。
I
ユーザがロールにより間接的にタスク権限を持っている。
システム テーブルと動的統計テーブル
C-19
RBW_TABLES テーブル
RBW_TABLES テーブル
RBW_TABLES テーブルは、データベースにあるすべてのテーブル、ビュー、シノ
ニムの情報を格納します。RBW_TABLES テーブルの情報をユーザが検索すると、
そのユーザが作成したオブジェクトか、アクセスを許可されたオブジェクトだけが
返されます。このテーブルは、TABLE、VIEW、SYNONYM に対する CREATE、
DROP の各コマンドで更新されます。テーブルを構成する列は、次のとおりです。
列名
列タイプ
列の内容
NAME
CHAR(128)
テーブル、ビュー、またはシノニムの名
前。
TYPE
CHAR(8)
オブジェクトのタイプ : TABLE、VIEW、
SYNONYM、SYSTEM。
CREATOR
CHAR(128)
テーブルの作成者 ( システム テーブルの
場合は空白 )。
ID
SMALLINT
テーブル識別子。負の数字はシステム
テーブルを識別します。
DATETIME
TIMESTAMP
テーブルの作成日時。
MAXSEGMENTS
INTEGER
テーブルの最大セグメント数
(CREATE TABLE または ALTER TABLE
で指定 )。指定されていない場合は
NULL。
MAXROWS_PER_SEG
DECIMAL(10)
セグメント当たりの最大行数
(CREATE TABLE または ALTER TABLE
で指定 )。指定されていない場合は
NULL。
MAXSIZE_ROWS
DECIMAL(10)
最大行数 ( アタッチされた各セグメント
のすべての PSU について、CREATE
SEGMENT のパラメータ MAXSIZE から
算出 )。
SEGMENT_BY
CHAR(11)
テーブルのセグメント化の方法 (range、
hash、NULL のいずれか )。
(１/２)
C-20
Administrator’s Guide
RBW_USERAUTH テーブル
列名
列タイプ
列の内容
INTACT
CHAR(1)
テーブルが正常 (Y) か、未修復の破損が
検出されている (N) かを示すフラグ。
PARTIAL
CHAR(1)
オフライン セグメントがあるために、
テーブルが部分的にのみ利用可能かどう
かを示すフラグ (Y または N)。
COMMENT
CHAR(256)
ユーザが設定したコメント。設定されて
いない場合は NULL。
(２/２)
RBW_USERAUTH テーブル
RBW_USERAUTH テーブルは、ユーザに付与されているアクセス権の情報を格納
します。DBA システム ロールのメンバーか、ACCESS_ANY 権限を持っているユー
ザが RBW_USERAUTH テーブルの情報を検索すると、すべてのユーザの権限を参
照できます。RESOURCE または CONNECT システム ロールのメンバーは、自分の
権限だけが参照できます。このテーブルは、GRANT および REVOKE コマンドに
よって更新されます。テーブルを構成する列は次のとおりです。権限については、
C-19 ページ「RBW_TABAUTH テーブル」を参照してください。
列名
列タイプ
列の内容
GRANTEE
CHAR(128)
ユーザまたはロールによって付与
される権限。ユーザが定義したロー
ルに、タスク権限を付与できる。
GRANTOR
CHAR(128)
GRANTEE ( 被付与者 ) に特権を付
与したユーザ。
DBAAUTH
CHAR(1)
GRANTEE が DBA システム ロール
のメンバーかどうか (Y、N、R、I の
いずれか )。
RESAUTH
CHAR(1)
被付与者が RESOURCE システム
ロールのメンバーかどうか (Y、N、
R、I のいずれか )。
DATETIME
TIMESTAMP
権限が付与された日時。
(１/５)
システム テーブルと動的統計テーブル
C-21
RBW_USERAUTH テーブル
列名
列タイプ
列の内容
LOCKED
CHAR(1)
接続試行が失敗したために
GRANTEE のアカウントがロックさ
れているかどうか (Y、N のどちら
か )。ロールの場合は NULL。
EXPIRED
CHAR(1)
設定された有効期限内にパスワー
ドを変更しなかったため、
GRANTEE のアカウントが期限切れ
になっているかどうかを示すフラ
グ (Y または N)。ロールの場合は
NULL。
PASSWORD_TS
TIMESTAMP
GRANTEE のデータベース パス
ワードが追加または最後に変更さ
れた日時。
USER_MANAGEMENT
CHAR(1)
GRANTEE が、データベース ユー
ザの変更、作成、削除およびパス
ワードの変更ができるかどうか (Y、
N、R、I のいずれか )。
GRANT_TABLE
CHAR(1)
GRANTEE が、データベース ユー
ザおよびロールにオブジェクト特
権を付与できるかどうか (Y、N、R、
I のいずれか )。
ROLE_MANAGEMENT
CHAR(1)
GRANTEE が、ロールの変更、作
成、削除、付与、取り消しができ
るかどうか (Y、N、R、I のいずれ
か )。
ALTER_ANY
CHAR(1)
GRANTEE が、インデックス、セグ
メント、テーブル、マクロ、
ビュー、シノニムの変更ができる
かどうか (Y、N、R、I のいずれか )。
PUBLIC_MACROS
CHAR(1)
GRANTEE が、PUBLIC マクロの作
成および削除ができるかどうか (Y、
N、R、I のいずれか )。
(２/５)
C-22
Administrator’s Guide
RBW_USERAUTH テーブル
列名
列タイプ
列の内容
ACCESS_ANY
CHAR(1)
GRANTEE が、システム テーブル
のユーザの個人情報を含め、すべ
てのデータベース オブジェクトか
らデータを検索できるかどうか (Y、
N、R、I のいずれか )。
MODIFY_ANY
CHAR(1)
GRANTEE が、任意のデータの挿
入、更新、削除、ロードができる
かどうか (Y、N、R、I のいずれか )。
DROP_ANY
CHAR(1)
GRANTEE が、任意のユーザが作成
したオブジェクトを削除できるか
どうか (Y、N、R、I のいずれか )。
CREATE_ANY
CHAR(1)
GRANTEE が、ほかのユーザの資源
を使用するオブジェクトを含め、
任意のオブジェクトを作成できる
かどうか (Y、N、R、I のいずれか )。
LOCK_DATABASE
CHAR(1)
GRANTEE が、データベースをロッ
クできるかどうか (Y、N、R、I のい
ずれか )。
BACKUP_DATABASE
CHAR(1)
GRANTEE が、データベースをバッ
クアップできるかどうか (Y、N、R、
I のいずれか )。
RESTORE_DATABASE
CHAR(1)
GRANTEE が、データベースを復元
できるかどうか (Y、N、R、I のいず
れか )。
UPGRADE_DATABASE
CHAR(1)
GRANTEE が、データベースをアッ
プグレードできるかどうか (Y、N、
R、I のいずれか )。
REORG_ANY
CHAR(1)
GRANTEE が、任意のテーブルまた
はインデックスを再編成できるか
どうか (Y、N、R、I のいずれか )。
OFFLINE_LOAD
CHAR(1)
GRANTEE が、作業用セグメントを
使用してオフライン ロードおよび
セグメントの同期ができるかどう
か (Y、N、R、I のいずれか )。
(３/５)
システム テーブルと動的統計テーブル
C-23
RBW_USERAUTH テーブル
列名
列タイプ
列の内容
ALTER_SYSTEM
CHAR(1)
GRANTEE が、ALTER SYSTEM 文
によるデータベース管理タスクを
実行できるかどうか (Y、N、R、I の
いずれか )。
ACCESS_SYSINFO
CHAR(1)
GRANTEE が、動的統計テーブルを
検索し、データベース動作に関す
る統計値を参照できるかどうか (Y、
N、R、I のいずれか )。
ALTER_TABLE_INTO_ANY
CHAR(1)
GRANTEE が、自分のテーブルをほ
かのユーザのセグメントに変更で
きるかどうか (Y、N、R、I のいずれ
か )。
CREATE_OWN
CHAR(1)
GRANTEE が 自分のオブジェクト
( インデックス、プライベート マク
ロ、セグメント、シノニム、テー
ブル、ビュー ) を作成できるかどう
か (Y、N、R、I のいずれか )。
DROP_OWN
CHAR(1)
GRANTEE が、自分のオブジェクト
を削除できるかどうか (Y、N、R、I
のいずれか )。
ALTER_OWN
CHAR(1)
GRANTEE が、自分のインデック
ス、マクロ、セグメント、シノニ
ム、テーブル、ビューを変更でき
るかどうか (Y、N、R、I のいずれ
か )。
GRANT_OWN
CHAR(1)
GRANTEE が、自分のオブジェクト
に対するオブジェクト特権を、ほ
かのユーザに付与できるかどうか
(Y、N、R、I のいずれか )。
IGNORE_QUIESCE
CHAR(1)
ユーザが、制止データベースをア
クセスできるか (Y)、ロックアウト
されているか (N) を示すフラグ。
ACCESS_ADVISOR_INFO
CHAR(1)
ユーザが Advisor システム テーブル
をクエリできるか (Y)、できないか
(N) を示すフラグ。
(４/５)
C-24
Administrator’s Guide
RBW_VIEW_REFERENCES テーブル
列名
列タイプ
列の内容
TEMP_RESOURCE
CHAR(1)
ユーザに一時テーブルを作成する
権限があるか (Y)、ないか (N) を示
すフラグ。
ISROLE
CHAR(1)
GRANTEE がロールであるかを示す
フラグ ( ロールの場合は Y、ユーザ
の場合は N)。
PRIORITY
SMALLINT
データベース サーバ リソースでの
ユーザの優先順位を示す 0 から 100
までの値。 0 が最高優先順位、100
が最低優先順位。
EXPORT
CHAR(1)
GRANTEE が、EXPORT 文による
データベース管理タスクを実行で
きるかどうか (Y、N、R、I のいずれ
か )。
COMMENT
CHAR(256)
ユーザが設定したコメント。設定
されていない場合は NULL。
(５/５)
RBW_VIEW_REFERENCES テーブル
RBW_VIEW_REFERENCES テーブルは、各ビューのビュー クエリ内にあるすべて
のテーブルの名前を格納します。RBW_VIEW_REFERENCES テーブルの情報を
ユーザが検索すると、そのユーザが作成したビューか、アクセスを許可された
ビューだけが返されます。このテーブルは、ALTER VIEW、CREATE VIEW、DROP
VIEW の各コマンドで更新されます。テーブルを構成する列は次のとおりです。
列名
列タイプ
列の内容
VIEW_NAME
CHAR(128)
ビュー テーブル名。
REF_NAME
CHAR(128)
ビューの参照するテーブルの名前。
ビューが事前計算ビューである場合、
ビューに関連づけられた集約テーブルの
名前はここに含まれません。
REF_TYPE
CHAR(8)
参照先テーブルの種類 : TABLE、VIEW、
SYNONYM、SYSTEM。
システム テーブルと動的統計テーブル
C-25
RBW_VIEWS テーブル
RBW_VIEWS テーブル
RBW_VIEWS テーブルは、データベースにあるすべてのビューの名前を格納しま
す。RBW_VIEWS テーブルの情報をユーザが検索すると、そのユーザが作成した
ビューか、アクセスを許可されたビューだけが返されます。このテーブルは、
ALTER VIEW、CREATE VIEW、DROP VIEW の各コマンドで更新されます。テーブ
ルを構成する列は次のとおりです。
C-26
列名
列タイプ
列の内容
NAME
CHAR(128)
ビューの名前。
CREATOR
CHAR(128)
ビューの作成者。
PRECOMPVIEW
CHAR(1)
ビューが事前計算されたかどうかを示す
フラグ (Y または N)。
PRECOMPVIEW_TABLE
CHAR(128)
事前計算ビューに関連付けられた集約
テーブルの名前。ビューが事前計算
ビューでない場合は NULL。
DETAIL_TABLE
CHAR(128)
集約テーブルの対象となる詳細テーブル
を示す。ビューが事前計算ビューでない
場合は NULL。
VALID
CHAR(1)
集約テーブルのデータが、詳細テーブル
のデータと一致するかどうかを示す。
ビューが事前計算ビューでない場合は
NULL。
MAINTENANCE
CHAR(7)
集約保守が実行されるかどうかを示しま
す。戻り値は、NULL ( 事前計算ビューで
ない場合 )、ON、OFF、または
REBUILD。
COMMENT
CHAR(256)
ユーザが設定したコメント。ALTER
VIEW 文で設定しなかった場合は NULL。
Administrator’s Guide
RBW_VIEWTEXT テーブル
RBW_VIEWTEXT テーブル
RBW_VIEWTEXT テーブルは RBW_VIEWS テーブルに格納されているすべての
ビューのテキストを格納します。RBW_VIEWSTEXT テーブルの情報をユーザが検
索すると、そのユーザが作成したビューか、アクセスを許可されたビューのテキス
トだけが返されます。256 文字を超えるビュー テキストは、複数の行に分割されま
す。このテーブルは、CREATE VIEW および DROP VIEW コマンドで更新されます。
テーブルを構成する列は次のとおりです。
列名
列タイプ
列の内容
NAME
CHAR(128)
ビューの名前。
SEQ
INTEGER
ビュー テキストの識別番号。
TEXT
CHAR(1024)
ビュー定義のテキスト ( キーワード CREATE VIEW
を含む )。
動的統計テーブル
動的統計テーブル (DST) を使用すると、データベースの動作を容易に監視すること
ができます。DST には、以下のものが含まれます。
■
DST_COMMANDS
■
DST_DATABASES
■
DST_LOCKS
■
DST_SESSIONS
■
DST_USERS
DST の詳細については、8-6 ページ「動的統計テーブルによるデータベース動作の
監視」を参照してください。
Query Performance Monitor では、クエリやその他の SQL コマンドに関する統計情報
は、以下のパフォーマンス DST に格納されます。
■
DST_PERFORMANCE_COMMANDS
■
DST_PERFORMANCE_OPSTATS
■
DST_PERFORMANCE_IOSTATS
パフォーマンス DST の詳細については、
『Query Performance Guide』を参照してくだ
さい。
システム テーブルと動的統計テーブル
C-27
DST_COMMANDS テーブル
DST_COMMANDS テーブル
DST_COMMANDS テーブルは、現在接続中のセッションが実行したコマンドに関
する情報を格納します。この情報は、各コマンドの累積統計値から構成されます。
統計値には、コマンドから派生するサブプロセスも算入されます。
次の表は、DST_COMMANDS テーブルの列の名前と内容をまとめたものです。
列名
列タイプ
説明
DBNAME
CHAR(128)
データベース論理名。
UNAME
CHAR(128)
コマンドを実行したユーザの名前。
NODE_NAME
CHAR(128)
コマンドを実行しているノードの名
前 (MPP サーバの場合 )。
PID
INTEGER
コマンドを実行しているセッション
のプロセス ID。
STARTED
TIMESTAMP
コマンドの開始日時。
STATE
CHAR(64)
■ Connecting
■ Idle
■ Executing
■ 返された行数 <x>、演算に使用され
た行数 <y> ( クエリの場合 )
■ 挿入された行数 <x> (Insert の場合 )
■ 削除された行数 <x> (Delete の場合 )
■ 更新された行数 <x> (Update の場合 )
COMMAND
CHAR(1024)
実行中のコマンドの、マクロ展開前
のテキスト。
CACHE_READS
INTEGER
ローカル バッファ キャッシュでのブ
ロック検出回数 ( 論理 Read 要求を除
く )。
CACHE_WRITES
INTEGER
ローカル バッファ キャッシュでのブ
ロック検出回数 ( 論理 Write 要求を除
く )。
LOGICAL_READS
INTEGER
コマンドが実行した論理 Read 回数。
(１/２)
C-28
Administrator’s Guide
DST_COMMANDS テーブル
列名
列タイプ
説明
LOGICAL_WRITES
INTEGER
コマンドが実行した論理 Write 回数。
PHYSICAL_READS
INTEGER
コマンドが実行した物理 Read 回数
( この統計値をサポートしないプラッ
トフォームの場合は NULL)。
PHYSICAL_WRITES
INTEGER
コマンドが実行した物理 Write 回数
( この統計値をサポートしないプラッ
トフォームの場合は NULL)。
SYSTEM_CPUTIME
DEC(9,2)
コマンドが使用したシステム CPU の
時間 ( 秒単位 )。
USER_CPUTIME
DEC(9,2)
コマンドが使用したユーザ CPU の時
間 ( 秒単位 )。
SPILL_COUNT
INTEGER
1 回の動作に使用したスピル ファイ
ル ( 一時的なファイル ) の数。
MEMORY_USED
INTEGER
コマンドが使用しているメモリの量
(KB 単位 )。
TEMPSPACE_USED
INTEGER
コマンドが使用しているスピル領域
( 一時的な領域 ) の量 (KB 単位 )。
PARALLELISM
INTEGER
コマンドが実行している並列タスク
の数。
TRANSACTION_TYPE
CHAR(32)
コマンドのトランザクション タイ
プ。戻り値 : READ_ONLY、
VERSIONING、BLOCKING。
READ_REVISION
DECIMAL(10,0)
トランザクションがアクセスした
データベースのリビジョン番号。
NEW_REVISION
DECIMAL(10,0)
トランザクションが作成したデータ
ベースのリビジョン番号。トランザ
クションが中止されるか、コミット
されなかった場合は NULL。
TRANSACTION_
ISOLATION_LEVEL
CHAR(32)
トランザクションのアイソレーショ
ン レベル。戻り値 :
REPEATABLE_READ、SERIALIZABLE。
LAST_UPDATED
TIMESTAMP
この行が最後に更新された日時。
(２/２)
システム テーブルと動的統計テーブル
C-29
DST_DATABASES テーブル
DST_DATABASES テーブル
DST_DATABASES テーブルは、データベース全体の利用状況を示す統計値を格納し
ます。データベースのロケーションおよび状態 ( 制止または稼働 ) も格納します。
次の表は、DST_DATABASES テーブルの列の名前と内容をまとめたものです。
列名
列タイプ
説明
DBNAME
CHAR(128)
データベース論理名。
DBLOCATION
CHAR(1024)
データベース ディレクトリ パス。
CURRENT_CONNECTS
INTEGER
接続中のセッション数。
PEAK_CONNECTS
INTEGER
同時接続セッションの最大数。
TOTAL_CONNECTS
INTEGER
接続セッションの累積数。
TOTAL_FATAL_EXITS
INTEGER
セッションが異常停止した回数。
無効なログイン回数と、制止デー
タベースに対する接続の失敗回数
を含む。
TOTAL_COMMANDS
INTEGER
データベースに対して実行された
コマンド数。
QUIESCED
CHAR(1)
データベースが制止状態 (Y) か、稼
働状態 (N) かを示すフラグ。
ADMINDB
CHAR(1)
データベースが管理データベース
(Y) か、ユーザが作成したデータ
ベース (N) かを示すフラグ。
VERSION_LOG_
SEGMENT
CHAR(128)
バージョン ログを含むセグメント
の名前。バージョン ログが存在し
ない場合は NULL。
VERSIONING_
STARTED
CHAR(1)
データベースのバージョニングが
有効かどうか (Y、N、バージョン ロ
グが存在しない場合は NULL)。
ACTIVE_VACUUM_
CLEANERS
INTEGER
データベース上で稼動中のバ
キューム クリーナ デーモン数 (0 ま
たは 1)。バージョン ログが存在し
ない場合は NULL。
(１/２)
C-30
Administrator’s Guide
DST_DATABASES テーブル
列名
列タイプ
説明
CURRENT_REVISION
DECIMAL(10, 0)
コミットされた最新のデータベー
ス リビジョン番号。バージョン ロ
グが存在しない場合は NULL。
OLDEST_ACTIVE_
REVISION
DECIMAL(10, 0)
最低 1 つの Read プロセスを持つ、
最も早くコミットされたデータ
ベース リビジョン番号。バージョ
ン ログが存在しない場合は NULL。
QUERY_REVISION
DECIMAL(10,0)
特定のユーザ クエリが使用中の
データベース リビジョン番号。ク
エリ リビジョンが設定されていな
い場合、この列は NULL。
LATEST_MERGED_
REVISION
DECIMAL(10, 0)
データベースの主 PSU からマージ
された、データベースの最新バー
ジョンのリビジョン番号。バー
ジョン ログが存在しない場合は
NULL。
VERSION_LOG_USED
INTEGER
新バージョンのデータベース ブ
ロックで使用されるディスク容量
(KB)。バージョン ログが存在しな
い場合は NULL。
VERSION_LOG_
AVAILABLE
INTEGER
バージョン ログで使用可能なディ
スク空き容量 (KB)。バージョン ロ
グが存在しない場合は NULL。
VERSION_LOG_
MAXIMUM_USED
INTEGER
バージョン ログに使用可能な最大
ディスク容量 (KB)。最高水準とも
呼ばれる。ALTER SYSTEM RESET
STATISTICS 文でリセット可能。
バージョン ログが存在しない場合
は NULL。
MAXREVISIONS
INTEGER
データベースに存在可能な最大ア
クティブ リビジョン数。バージョ
ン ログが存在しない場合は NULL。
ALTER DATABASE CREATE
VERSION LOG IN 文で代用可。
LAST_UPDATED
TIMESTAMP
この行が最後に更新された日時。
(２/２)
システム テーブルと動的統計テーブル
C-31
DST_LOCKS テーブル
DST_LOCKS テーブル
DST_LOCKS テーブルは、各セッションが保持または待機しているロックに関する
情報を格納します。ロックを待機しているセッションについては、DST_LOCKS
テーブルは、そのロックを保持 ( ブロッキング ) しているプロセスの情報も含みま
す。
次の表は、DST_LOCKS テーブルの列の名前と内容をまとめたものです。
C-32
列名
列タイプ
説明
DBNAME
CHAR(128)
データベース論理名。
UNAME
CHAR(128)
ユーザ名。
NODE_NAME
CHAR(128)
プロセスを実行しているノードの名前
(MPP システムの場合 )。
PID
INTEGER
プロセスの PID。
TNAME
CHAR(128)
ロックされているテーブル ( セグメントに
対するロックの場合は NULL)。
SEGNAME
CHAR(128)
セグメントに対するロックのセグメント名
( テーブルのみのロックの場合は NULL)。
DATETIME
TIMESTAMP
ロック要求の日時。
TYPE
CHAR(2)
現在のトランザクションに適用されている
ロックの種類。戻り値 : read-only (RO)、
read-key (RK)、read-data (RD)、write-blocking
(WB)、write-key (WK)、write-data (WD)。
BLOCKER_UNAME
CHAR(128)
ロックを保持しているユーザの名前。その
プロセスがロックを保持している場合は
NULL。
BLOCKER_PID
INTEGER
現在接続をブロッキングしているロックを
保持しているプロセスの PID。そのプロセ
スがロックを保持している場合は NULL。
BLOCKER_NODE
CHAR(128)
ブロッキング プロセスを実行しているノー
ドの名前 (MPP システムの場合 )。そのプロ
セスがロックを保持している場合は NULL。
LAST_UPDATED
TIMESTAMP
この行が最後に更新された日時。
Administrator’s Guide
DST_SESSIONS テーブル
DST_SESSIONS テーブル
DST_SESSIONS テーブルは、データベースに接続している各セッションの情報を
格納します。セッションが実行したすべてのコマンドに関する累積統計値と、ピー
ク統計値 (1 つのコマンドの最大値 ) も含まれます。
列名
列タイプ
説明
DBNAME
CHAR(128)
データベース論理名。
UNAME
CHAR(128)
セッションを実行しているユーザ
のデータベース ユーザ名。
PID
INTEGER
セッションの rbwsvr プロセス
ID。
COMPONENT
CHAR(32)
SERVER、WORKGROUP SERVER、
TMU、PTMU。
STARTED
TIMESTAMP
セッションの開始日時。
NET_ADDRESS
CHAR(32)
クライアント プロセス ( ある場
合 ) のネットワーク アドレス。
CLIENT_TOOL
CHAR(32)
クライアント フロントエンド
ツールの名前。クライアント
ツールを使用していない場合は
NULL。
GATEWAY
CHAR(128)
ゲートウェイ識別子。ゲートウェ
イを使用していない場合は NULL。
INDEX_TEMPSPACE_
DUPLICATESPILLPERCENT
INTEGER
コピーに作成された一時領域のイ
ンデックス作成割合。REORG 処
理でのみ使用可能。
PRIORITY
SMALLINT
セッションの現在の優先順位。
QUERY_MEMORY_LIMIT
INTEGER
クエリに使用できるメモリの最大
サイズ (8KB のブロック単位 )。
QUERY_TEMPSPACE_
CHAR(1024)
クエリに使用する一時領域のディ
レクトリ。
DIRECTORIES
(１/４)
システム テーブルと動的統計テーブル
C-33
DST_SESSIONS テーブル
列名
列タイプ
説明
QUERY_TEMPSPACE_
INTEGER
クエリに使用する一時領域のクエ
リ当たりの最大サイズ (8KB のブ
ロック単位 )。
INDEX_TEMPSPACE_
DIRECTORIES
CHAR(1024)
インデックス作成に使用する一時
領域のディレクトリ。
INDEX_TEMPSPACE_
MAXSPILLSIZE
INTEGER
インデックス作成に使用する一時
領域の操作当たりの最大サイズ
(8KB のブロック単位 )。
REPORT_INTERVAL
INTEGER
この情報の更新間隔 ( 分単位 )。
TOTAL_COMMANDS
INTEGER
セッション中に実行されたステー
トメント数。
TOTAL_CANCELS
INTEGER
セッション中にキャンセルされた
ステートメント数。
TOTAL_CACHE_READS
INTEGER
ローカル バッファ キャッシュで
のブロック検出回数 ( 論理 Read
要求を除く )。
TOTAL_CACHE_WRITES
INTEGER
ローカル バッファ キャッシュで
のブロック検出回数 ( 論理 Write
要求を除く )。
TOTAL_LOGICAL_READS
INTEGER
セッションが実行した論理 Read
回数。
TOTAL_LOGICAL_WRITES
INTEGER
セッションが実行した論理 Write
回数。
TOTAL_PHYSICAL_READS
INTEGER
セッションが実行した物理 Read
回数 ( この統計値をサポートしな
いプラットフォームの場合は
NULL) 。
TOTAL_PHYSICAL_
INTEGER
セッションが実行した物理 Write
回数 ( この統計値をサポートしな
いプラットフォームの場合は
NULL)。
DEC(9,2)
セッションが使用したシステム
CPU の時間 ( 秒単位 )。
MAXSPILLSIZE
WRITES
TOTAL_SYSTEM_CPUTIME
(２/４)
C-34
Administrator’s Guide
DST_SESSIONS テーブル
列名
列タイプ
説明
TOTAL_USER_CPUTIME
DEC(9,2)
セッションが使用したユーザ
CPU の時間 ( 秒単位 )。
TOTAL_SPILL_COUNT
INTEGER
セッションがスピル領域 ( 一時的
な領域 ) を使用した回数。
PEAK_CACHE_READS
INTEGER
セッションの 1 コマンド中に、
ローカル バッファ キャッシュに
ブロックが検出された最大回数
( 論理 Write 要求を除く )。
PEAK_CACHE_WRITES
INTEGER
セッション中に、ローカル バッ
ファ キャッシュにブロックが検
出された最大回数 ( 論理 Write 要
求を除く )。
PEAK_LOGICIAL_READS
INTEGER
現在のセッション中のコマンドが
実行した論理 Read の最大回数。
PEAK_LOGICAL_WRITES
INTEGER
現在のセッション中のコマンドが
実行した論理 Write の最大回数。
PEAK_PHYSICAL_READS
INTEGER
現在のセッション中のコマンドが
実行した物理 Read の最大回数
( この統計値をサポートしないプ
ラットフォームの場合は NULL) 。
PEAK_PHYSICAL_WRITES
INTEGER
現在のセッション中のコマンドが
実行した物理 Write の最大回数
( この統計値をサポートしないプ
ラットフォームの場合は NULL)。
PEAK_SYSTEM_CPUTIME
DEC(9,2)
セッション中のコマンドが使用し
たシステム CPU の最長時間 ( 秒単
位 )。
PEAK_USER_CPUTIME
DEC(9,2)
セッション中のコマンドが使用し
たユーザ CPU の最長時間 ( 秒単
位 )。
PEAK_SPILL_COUNT
INTEGER
セッション中のコマンドがスピル
領域 ( 一時的な領域 ) を使用した
最大回数。
(３/４)
システム テーブルと動的統計テーブル
C-35
DST_USERS テーブル
列名
列タイプ
説明
PEAK_PARALLELISM
INTEGER
セッション中のコマンドが実行し
た並列タスクの最大数。
PEAK_MEMORY_USED
INTEGER
セッションの 1 コマンドが、デー
タベースのアクセスに使用したメ
モリの最大量 (KB 単位 )。
PEAK_TEMPSPACE_USED
INTEGER
セッションの 1 コマンドが、デー
タベースのアクセスに使用したス
ピル領域 ( 一時的な領域 ) の最大
量 (KB 単位 )。
LAST_UPDATED
TIMESTAMP
この行が最後に更新された日時。
(４/４)
DST_USERS テーブル
DST_USERS テーブルは、データベース サーバが最後に起動したあとにデータベー
スにアクセスしたユーザに関する情報を格納します。各ユーザの統計値は、ALTER
SYSTEM RESET STATISTICS 文でリセットできます。すべてのユーザ セッションに
関する累積統計値と、ピーク統計値 (1 つのセッションの最大値 ) も含まれます。
次の表は、DST_USERS テーブルの列の名前と内容をまとめたものです。
列名
列タイプ
説明
DBNAME
CHAR(128)
データベース論理名。
UNAME
CHAR(128)
ユーザ名。
FIRST_LOGIN
TIMESTAMP
ユーザが最初にデータベースにア
クセスした日時。
LAST_LOGIN
TIMESTAMP
ユーザが最後にデータベースにア
クセスした日時。
CURRENT_CONNECTS
INTEGER
現在接続中のセッション数。
PEAK_CONNECTS
INTEGER
ユーザによる同時接続セッション
の最大数。
TOTAL_CONNECTS
INTEGER
ユーザによる接続回数。
(１/４)
C-36
Administrator’s Guide
DST_USERS テーブル
列名
列タイプ
説明
TOTAL_FATAL_EXITS
INTEGER
ユーザに対して、セッションが異
常終了した回数 。
TOTAL_COMMANDS
INTEGER
ユーザが実行したコマンドの総
数。
TOTAL_CANCELS
INTEGER
ユーザが取り消したコマンド数。
TOTAL_CACHE_READS
INTEGER
ローカル バッファ キャッシュでの
ブロック検出回数 ( 論理 Read 要求
を除く )。
TOTAL_CACHE_WRITES
INTEGER
ローカル バッファ キャッシュでの
ブロック検出回数 ( 論理 Write 要求
を除く )。
TOTAL_LOGICAL_READS
INTEGER
データベースに対して、ユーザが
実行した論理 Read 回数。
TOTAL_LOGICAL_WRITES
INTEGER
データベースに対して、ユーザが
実行した論理 Write 回数。
TOTAL_PHYSICAL_READS
INTEGER
データベースに対して、ユーザが
実行した物理 Read の回数 ( この統
計値をサポートしないプラット
フォームの場合は NULL)。
TOTAL_PHYSICAL_WRITES
INTEGER
データベースに対して、ユーザが
実行した物理 Write の回数 ( この統
計値をサポートしないプラット
フォームの場合は NULL)。
TOTAL_SYSTEM_CPUTIME
DEC(9,2)
ユーザが、データベースのアクセ
スに使用したシステム CPU の累積
時間 ( 秒単位 )。
TOTAL_USER_CPUTIME
DEC(9,2)
ユーザが、データベースのアクセ
スに使用したユーザ CPU の累積時
間 ( 秒単位 )。
TOTAL_SPILL_COUNT
INTEGER
スピル領域 ( 一時的な領域 ) が使
用された累積回数。
(２/４)
システム テーブルと動的統計テーブル
C-37
DST_USERS テーブル
列名
列タイプ
説明
PEAK_CACHE_READS
INTEGER
セッション中に、ローカル バッ
ファ キャッシュにブロックが検出
された最大回数 ( 論理 Read 要求を
除く )。
PEAK_CACHE_WRITES
INTEGER
セッション中に、ローカル バッ
ファ キャッシュにブロックが検出
された最大回数 ( 論理 Write 要求を
除く )。
PEAK_LOGICIAL_READS
INTEGER
データベースに対して、ユーザが
1 セッション中に実行した論理
Read の最大回数。
PEAK_LOGICAL_WRITES
INTEGER
データベースに対して、ユーザが
1 セッション中に実行した論理
Write の最大回数。
PEAK_PHYSICAL_READS
INTEGER
データベースに対して、ユーザが
1 セッション中に実行した物理
Read の最大回数 ( この統計値をサ
ポートしないプラットフォームの
場合は NULL) 。
PEAK_PHYSICAL_WRITES
INTEGER
データベースに対して、ユーザが
1 セッション中に実行した物理
Write の最大回数 ( この統計値をサ
ポートしないプラットフォームの
場合は NULL)。
PEAK_SYSTEM_CPUTIME
DEC(9,2)
セッション中に、ユーザがデータ
ベースのアクセスに使用したシス
テム CPU の最長時間 ( 秒単位 )。
PEAK_USER_CPUTIME
DEC(9,2)
セッション中に、ユーザがデータ
ベースのアクセスに使用したユー
ザ CPU の最長時間 ( 秒単位 )。
PEAK_SPILL_COUNT
INTEGER
セッション中に、スピル領域 ( 一
時的な領域 ) が使用された最大回
数。
(３/４)
C-38
Administrator’s Guide
データ型とデータのサイズ
列名
列タイプ
説明
PEAK_PARALLELISM
INTEGER
セッション中に、ユーザがデータ
ベースに対して実行した並列タス
クの最大数。
PEAK_MEMORY_USED
INTEGER
セッション中に、ユーザがデータ
ベースのアクセスに使用したメモ
リの最大量 (KB 単位 )。
PEAK_TEMPSPACE_USED
INTEGER
セッション中に、ユーザが使用し
たスピル領域 ( 一時的な領域 ) の
最大量 (KB 単位 )。
LAST_UPDATED
TIMESTAMP
この行が最後に更新された日時。
(４/４)
データ型とデータのサイズ
次の表に各データ型のサイズ ( バイト単位 ) を示します。
データ型
バイト単位のサイズ
CHARACTER
長さ ( バイト数）。最大値は 1024。
VARCHAR
値またはフィル ファクタのどちらか大きいほうを作成したリ
テラルまたは式の長さ ( バイト数 )。最大値は 1024。デフォル
トは 1。
DATE
3。
TIME
秒未満の小数がない場合は 3、ある場合は 5。
TIMESTAMP
秒未満の小数がない場合は 6、ある場合は 8。
INTEGER
4 ( 範囲 : -231 ∼ 231 - 1; 231 = 2,147,483,648)。
SERIAL
4 ( 範囲 : 1 ∼ 231 - 1; 231 = 2,147,483,648)。
SMALLINT
2 ( 範囲 : -215 ∼ 215 - 1; 215 = 32,768)。
TINYINT
1 ( 範囲 : -27 ∼ 27 - 1;
27 = 128)。
(１/２)
システム テーブルと動的統計テーブル
C-39
データ型とデータのサイズ
データ型
バイト単位のサイズ
FLOAT, DOUBLE
8 ( 範囲 : 約 1.E-308 ∼ 1.E308)。
REAL
4 ( 範囲 : 約 1.E-38 ∼ 1.E37)。
DECIMAL または NUMERIC 精度
1-2
1
3-4
2
5-9
4
10-11
5
12-14
6
15-16
7
17-18
8
19-21
9
22-23
10
24-26
11
27-28
12
29-31
13
32-33
14
34-35
15
36-38
16
(２/２)
データ型の定義と使用方法については、『SQL Reference Guide』を参照してくださ
い。
C-40
Administrator’s Guide
特記事項
特記事項
本書に記載されている製品、サービス、または機能は、国によっては
提供されない場合があります。各地域で現在利用可能な IBM 製品およ
びサービスについては、該当地域の担当者にお問い合わせください。
IBM 製品、プログラム、またはサービスのすべての記述箇所は、対象
の IBM 製品、プログラム、またはサービスのみが使用されることを明
示的または暗示的に示すものではありません。IBM の知的所有権を侵
害しない、同等の機能を有する製品、プログラム、またはサービスを
使用できる場合があります。ただし、IBM 以外の製品、プログラム、
またはサービスの操作に関する評価および確認は、お客様の責任の元
に行ってください。
本書に記載の各事項は、特許または特許出願により保護されている場
合があります。本書の提供は、これらの特許の使用許諾をお客様に付
与するものではありません。使用許諾に関する質問は、下記に書面に
てお問い合わせください。
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
ダブル バイト (DBCS) に関する使用許諾については、各国 IBM の知的
財産部門にお問い合わせいただくか、下記まで書面にてお問い合わせ
をご送付ください。
IBM World Trade Asia Corporation
Licensing
〒 106 - 0032 東京都港区六本木 3 丁目 2 - 31
以下の段落の記述は、英国、または記述の内容が地域法に合致しない国には適用さ
れません。International Business Machines Corporation は、本書を「現状のまま」提供
し、明示的または黙示的を問わずいかなる保証の責任も負わないものとし、第三者
の権利侵害のないことへの保証、商品性の保証、または特定目的への適合性の保証
などを含み、かつこれらに限定されない、いかなる黙示的な保証の責任も負わない
ものとします。特定の取引における明示的または黙示的な保証の制限が国または地
域によって禁じられる場合、この記述は適用されないものとします。
この情報には、技術上不正確な点や誤植が含まれている可能性があります。本書の
情報は定期的に見直され、必要な変更は本書の改訂版に反映されます。IBM は本書
に記載されている製品またはプログラムに対して、随時、予告なしに変更または改
良を加えることがあります。
本書において参照されている IBM 以外の Web サイトは、単に便宜上の理由で記載
されているだけであり、それらのサイトに対する IBM の保証または支持を示すもの
ではありません。それらの Web サイトで提供される内容は、本 IBM 製品には関係
ありません。これらの利用は、お客様の責任の元で行ってください。
お客様により提供された情報は、IBM が適切と判断するすべての方法で、使用また
は頒布される場合があります。これにより、お客様に責任が発生することはありま
せん。
本プログラムのライセンス保持者で、次の事項を可能にするための情報を希望する
方は、下記にお問い合わせください。(i) 独自に作成されたプログラムと、他のプロ
グラム ( 本製品を含む ) との間の情報交換、(ii) 交換された情報の共用
IBM Corporation
J46A/G4
555 Bailey Avenue
San Jose, CA 95141-1003
U.S.A.
上記の情報は、適切な使用条件の元で利用可能ですが、有償の場合もあります。
本書で説明されるライセンス プログラムおよびこれに関して利用できるライセンス
資料は、IBM Customer Agreement、IBM International Program License Agreement、また
はそれと同等の合意の各条項に基づいて、IBM より提供されます。
2 Administrator’s Guide
この文書に含まれるすべての実行データは、管理環境下で決定されたものです。こ
のため、操作環境によって実行結果が大きく変化する場合があります。開発レベル
のシステムで測定が行われた可能性がありますが、その測定値が一般に利用可能な
システムのものと同じである保証はありません。さらに、一部の測定値には推定値
が含まれている場合があります。このため、実際の結果とは異なる可能性がありま
す。本書を利用されるお客様は、それぞれの特定の環境に適したデータを検証する
必要があります。
IBM 以外の製品に関する情報は、各製品の供給者、出版物、または公的に入手可能
な情報源から取得されたものです。IBM ではこれらの製品をテストしておらず、
IBM 以外の製品のパフォーマンス、互換性、またはその他の要件については確認し
ていません。IBM 以外の製品の機能に関する質問については、各製品の供給者にお
問い合わせください。
特記事項 3
商標
AIX、DB2、DB2 Universal Database、Distributed Relational Database
Architecture、NUMA-Q、OS/2、OS/390、および OS/400、IBM Informix、
C-ISAM、Foundation.2000TM、IBM Informix 4GL、IBM Informix
DataBlade Module、Client SDKTM、CloudscapeTM、CloudsyncTM、
IBM Informix Connect、IBM Informix Driver for JDBC、Dynamic
ConnectTM、IBM Informix Dynamic Scalable ArchitectureTM (DSA)、
IBM Informix Dynamic ServerTM、IBM Informix Enterprise Gateway
Manager (Enterprise Gateway Manager)、IBM Informix Extended Parallel
ServerTM、i.Financial ServicesTM、J/FoundationTM、MaxConnectTM、Object
TranslatorTM、Red BrickTM、IBM Informix SE、IBM Informix SQL、InformiXMLTM、RedBack、SystemBuilderTM、U2TM、UniData、UniVerse、
wintegrate は、International Business Machines Corporation の商標または登録商標で
す。
Java および Java ベースの商標およびロゴは、米国およびその他の国における Sun
Microsystems, Inc の商標または登録商標です。
Windows、Windows NT、および Excel は、米国およびその他の国における Microsoft
Corporation の商標または登録商標です。
UNIX は、米国およびその他の国における、X/Open Company Limited が独占的にラ
イセンスしている登録商標です。
本書におけるその他の会社、製品およびサービスの名称は、それぞれ各社の商標ま
たはサービス マークです。
4 Administrator’s Guide
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
索引
索引
記号
.rbretrc ファイル 1-17, 2-23
.rbwerr ファイル 2-23
.rbwrc ファイル 1-17, 2-22
数字
1 ブロックあたりの行数
CHECK TABLE の出力 5-31, 5-32
MAXROWS PER SEGMENT 5-29
VARCHAR フィル ファクタの影
響 5-26, 5-27, 5-28, 5-29
行番号の数 5-24
計算 5-24
通常の行サイズ 5-24, 5-27
A
ACCESS_ADVISOR_INFO タスク権
限 7-12
ACCESS_ANY タスク権限 7-12
ACCESS_SYSINFO タスク権
限 7-12, 8-4
ADD STORAGE 句、ALTER
SEGMENT 文 9-42
Administrator ツール 1-8, 2-25
ADMIN データベース
rbw.config ファイル エント
リ B-33
説明 8-4
Advisor
説明 2-14
ロギング 8-29
ログ ファイル
サイズ指定 8-33
ディレクトリの指定 8-32
ログ ファイル、削除 8-30
ALTER DATABASE 文
CLEAN VERSION LOG 句 6-19
FREEZE QUERY REVISION
句 6-14
START CLEANING 句 6-26
STOP CLEANING 句 6-25
UNFREEZE QUERY REVISION
句 6-22
ALTER SEGMENT 文
ADD STORAGE 句 9-42
ATTACH 句 9-42
CHANGE EXTENDSIZE 句 9-43
CHANGE MAXSIZE 句 9-43
CHANGE PATH 句 9-43, 9-55
CLEAR 句 9-42
DETACH 句 9-42
DROP LAST STORAGE 句 9-43
FORCE INTACT 句 9-43, 9-70
MIGRATE TO 句 9-43, 9-55
OFFLINE 句 9-42
ONLINE 句 9-70, 9-71
OVERRIDE FULLINDEXCHECK
句 9-58
RANGE MOVE 句 9-42
RANGE 句 9-42
RELEASE STORAGE 句 9-43
SEGMENT BY 句 9-43
VERIFY 句
説明 9-43
破損したセグメント 9-69
破損セグメントの発見 9-55
破損の原因 9-70
失敗 9-43
使用方法 9-42
ALTER SYSTEM 文
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
な行
Advisor ロギング 8-32
句
ADVISOR_LOGGING 8-32
CANCEL USER
COMMAND 8-11
CHANGE ACCOUNTING
LEVEL 8-41
CHANGE LOGGING
LEVEL 8-28
CHANGE USER PRIORITY 8-12
CLOSE USER SESSION 8-11
QUIESCE DATABASE 8-10
RESET STATISTICS 8-11
RESUME DATABASE 8-10
START ACCOUNTING 8-40
START LOGGING 8-28
STOP ACCOUNTING 8-40
STOP LOGGING 8-28
SWITCH ACCOUNTING
FILE 8-41
SWITCH LOGGING FILE 8-28
SWITCH_ADVISOR_LOG_FILE
8-32
TERMINATE LOGGING
DAEMON 8-28
セッションの終了 8-11
データベースを稼働状態にす
る 8-10
必要な権限 8-9
モードの変更 8-41
ALTER TABLE 文
DROP CONSTRAINT 句 9-79
ON DELETE 句 9-77
SERIAL 列の start 値と step
値 9-79
カスケード デリート 9-77
使用方法 9-75
中断した操作 9-80
デフォルト値の変更 9-76
フィル ファクタ 9-79
フォーリン キーの追加 9-78
領域不足エラー 9-81
列の削除 9-76
列の追加 9-76
列名の変更 9-76
ALTER USER 文 8-12
ALTER_ANY タスク権限 7-12
ALTER_OWN タスク権限 7-13
2 Administrator’s Guide
F
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
CATEGORY 値、マクロ 5-59
CHANGE ACCOUNTING LEVEL
句、ALTER SYSTEM 文 8-41
CHANGE EXTENDSIZE 句、
ALTER SEGMENT 文 9-43
CHANGE MAXSIZE 句、ALTER
SEGMENT 文 9-43
CHANGE PATH 句、ALTER
SEGMENT 文 9-43, 9-55
CHECK INDEX
DESCRIBE オプション 9-20, 9-21,
9-23
VERBOSE オプション 9-18, 9-20,
9-22, 9-26
サイズ情報の取得 9-13
ファイル アクセス権 B-14
CHECK TABLE
VARCHAR フィル ファクタ 5-30,
5-31
VERBOSE オプション 5-31, 9-14
∼ 9-17
テーブル構造のチェック 9-13 ∼
9-17
ファイル アクセス権 B-14
CLEAN VERSION LOG 句、ALTER
DATABASE 文 6-19
CLEAR 句、ALTER SEGMENT
文 9-42
COMMENT 値、マクロ 5-59
R
S
T
U
V W
X
Y
わ行
ALTER_SYSTEM タスク権限 7-12,
8-4
ALTER_TABLE_INTO_ANY タスク
権限 7-13
Aroma データベース
rbw.config ファイル エント
リ B-33
インストール 1-20
作成、チュートリアル A-1 ∼
A-29
ASCII コード セット 2-28
ATTACH 句、ALTER SEGMENT
文 9-42
Automatic Row Generation、TMU
参照整合性 2-39
C
Q
CONNECT システム ロール、説
明 2-37, 7-7
COUNT 関数 B-14
CREATE INDEX 文、使用方法 5-33
CREATE MACRO 文、使用方
法 5-59
CREATE ROLE 文、使用方法 7-15
CREATE SEGMENT 文、使用方
法 5-12
CREATE TABLE 文
使用方法 5-21
制約名 5-22
例 A-8
CREATE VIEW 文、使用方法 5-57
CREATE_ANY タスク権限 7-12
CREATE_OWN タスク権限 7-13
CTRL-C 処理スレッド 1-14
CURRENT_USER、SQL 変数 5-58
D
DBA システム ロール
説明 2-37, 7-7
取り消し 7-8, 7-21
付与 7-8, 7-18
dbcreate ユーティリティ 5-4
データベースの削除 9-105
例 A-7
dbsize ユーティリティ
B-TREE インデックスの見積
り 4-31
STAR インデックスの見積
り 4-31
TARGET インデックスの見積
り 4-31
セグメント化された TARGET イ
ンデックスの見積り 4-32
ディレクトリ ロケーション 4-26
テーブルの見積り 4-26
DDL 操作 9-7
DELETE 操作
テーブルのロック 9-10
バージョン管理された 6-13
モード、アクション 5-23
DETACH 句、ALTER SEGMENT
文 9-42
DROP HIERARCHY 文、使用方
法 9-102
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
DROP LAST STORAGE 句、ALTER
SEGMENT 文 9-43
DROP ROLE 文、使用方法 9-102
DROP_ANY タスク権限 7-12
DROP_OWN タスク権限 7-13
DROP 文 9-101
DST_COMMANDS テーブル C-28
DST_DATABASES テーブル
バージョン ログ領域 6-23
列名 C-30
DST_LOCKS テーブル 9-7, C-32
DST_SESSIONS テーブル C-33
DST_USERS テーブル C-36
E
EXPAND 文 5-61
EXPORT タスク権限 7-12
EXTENDSIZE の値
RBW_TABLES テーブル 9-54
F
Findserver ユーティリティ
INTERVAL B-13
使用方法 9-97
FOR DELETE オプション 9-10
FORCE INTACT 句、ALTER
SEGMENT 文 9-43, 9-56, 9-70
FOREIGN KEY REFERENCES 句、
テーブルの関連付け 4-59
FREEZE QUERY REVISION 句、
ALTER DATABASE 文 6-14
G
GRANT CONNECT 文 7-5, 7-6
GRANT ( 特権 ) 文
使用方法 7-9
例 7-16
GRANT_OWN タスク権限 7-13
GRANT_TABLE タスク権限 7-12
GRANT 権限とロール コマンド
使用方法 7-8, 7-18
例 7-19
GUI ツール、Administrator 2-25
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
I
IGNORE_QUIESCE タスク権
限 7-12
INITSIZE 値、RBW_TABLES テー
ブル 9-54
INTACT 列
値 9-70
J
Java データベース コネクティビ
ティ 1-8
JDBC API 1-8
JDBC Driver 1-8
MAXSIZE_ROWS 値、
RBW_TABLES テーブル C-20
MAXSIZE の値
RBW_STORAGE テーブル 9-33
RBW_TABLES テーブル 9-54
MAXSPILLSIZE 値
INDEX_TEMPSPACE 4-49
クエリ処理の一時領域 4-56
見積り、クエリ 4-56
Microsoft Access、データベース ア
クセス 7-5
MIGRATE TO 句、ALTER
SEGMENT 文 9-43, 9-55
MODIFY_ANY タスク権限 7-12
N
L
LOAD DATA 文の例、Aroma デー
タベース A-17 ∼ A-25
LOCK_DATABASE タスク権
限 7-12
logdview 実行ファイル 8-17
M
MAXROWS PER SEGMENT オプ
ション
1 ブロックあたりの行数 5-29
RBW_TABLES 値 C-20
REORG 操作の強制実行 5-22
STAR インデックスへの影
響 4-30
VARCHAR フィル ファクタ 5-22
値の変更 9-77
エラー メッセージ 5-22
使用方法 5-22
フィル ファクタ 5-25
未使用行番号 5-29
MAXSEGMENTS オプション
RBW_TABLES 値 C-20
REORG 操作の強制実行 5-22
STAR インデックスへの影
響 4-30
値の変更 9-77
使用方法 5-22
NULL 値、ORDER BY 句 2-23
O
ODBC
クライアント アプリケーション
要件 7-5
初期化ファイル 2-24
データソースの設定 2-24
ドライバ 1-8
odbc.ini ファイル 2-24
OFFLINE_LOAD タスク権限 7-13
OFFLINE 句、ALTER SEGMENT
文 9-42
ONLINE 句、ALTER SEGMENT
文 9-70, 9-71
OVERRIDE FULLINDEXCHECK
句、ALTER SEGMENT 文 9-58
OVERRIDE REFCHECK 句
使用方法 5-23
注意 2-40
P
PSU
MAXSIZE の値 9-33
移動 9-55
インデックス 5-14
拡張サイズ 4-21
サイズと拡張 4-21
索引 3
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
な行
サイズの変更 9-54
シーケンス ID C-17
ディスク領域の割り当て 5-14
バージョン ログ 6-11
場所の変更 9-55
破損 9-69
開けない 9-55
PUBLIC_MACROS タスク権
限 7-13
PUBLIC アクセス 7-9
R
RAID デバイス、バージョン ロ
グ 6-18
RANGE LIKE SEGMENT 句
ALTER SEGMENT ATTACH
文 5-15, 5-16
RANGE MOVE 句、ALTER
SEGMENT 文 9-42
RANGE 句、ALTER SEGMENT
文 9-42
rb_cm ユーティリティ 8-3, 9-82
rb_creator ユーティリティ 5-4, A-7
RB_DEFAULT_LOADINFO ファイ
ル 5-8
rb_deleter ユーティリティ、データ
ベースの削除 9-105
rb_sample クリーンアップ スクリプ
ト、使用方法 4-53
rbclean.bat テンプレート、使用方
法 4-53
rbodbc32.ini ファイル 2-24
rbw.findserver ユーティリティ 9-97
rbw.servermon デーモン
Findserver 9-97
間隔の設定 B-13
停止 9-97
rbw.start スクリプト
rbwadmd デーモン 9-96
使用方法 9-96
rbw.start スクリプト、使用方
法 9-96
rbw.stop スクリプト、使用方
法 9-96
RBW_COLUMNS テーブル C-4
RBW_CONSTRAINT_COLUMNS
テーブル C-5
4 Administrator’s Guide
F
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
わ行
RBW_CONSTRAINTS テーブ
ル 5-22, C-6
RBW_HIERARCHIES テーブル C-6
RBW_INDEXCOLUMNS テーブ
ル C-7
RBW_INDEXES テーブル C-7
RBW_LOADINFO テーブル C-9
RBW_MACROS テーブル C-10
RBW_OPTIONS テーブル 2-30,
C-11
RBW_PRECOMPVIEW_CANDIDA
TES テーブル C-2
RBW_PRECOMPVIEW_COLUMNS
テーブル C-12
RBW_PRECOMPVIEW_UTILIZATI
ON テーブル C-2
RBW_RELATIONSHIPS テーブ
ル 5-22, C-12
RBW_ROLE_MEMBERS テーブ
ル 7-23, C-13
RBW_ROLES テーブル 7-23, C-14
RBW_ROWNUM シュード列 5-17,
9-36, 9-44
RBW_SEGID シュード列 9-36
RBW_SEGMENTS テーブル 2-21,
C-14
RBW_SEGNAME シュード列 5-17,
9-36
RBW_STORAGE テーブル C-17
RBW_SYNONYMS テーブル C-18
RBW_TABAUTH テーブル 7-23,
C-19
RBW_TABLES テーブル C-20
RBW_USERAUTH テーブル 7-23,
C-21
RBW_VIEW_REFERENCES テーブ
ル C-25
RBW_VIEWS テーブル C-26
RBW_VIEWTEXT テーブル C-27
rbwadmd スレッド
開始 9-96
停止 9-99
rbwadmd デーモン
開始 9-96
出力 2-36
詳細 8-12
停止 9-97
統計収集の間隔 8-14
rbwapid デーモン
rbw.config ファイル エント
リ B-11
説明 1-10
rbwconc スレッド 1-14
rbwlogd デーモン
アカウンティングのロール 8-35
開始 8-16
出力 2-36
定義 1-12
停止 8-28
rbwlogview 実行ファイル 8-17
rbwlsnr スレッド 1-14
rbwpchk デーモン 1-13
rbwsvr プロセス 1-10
rbwvcd デーモン。「バキューム ク
リーナ デーモン」を参照。
Read 回数 8-7
Read ロック 9-7
READ ロック オプション 9-6
RECOVER オプション 6-16, 6-17
Red Brick Decision Server
説明 1-3
Red Brick Warehouse
構成要素の概要 1-5 ∼ 1-8
redbrick
管理ユーザ 1-15
ディレクトリのアクセス権 5-6
ユーザ アカウント 2-36, A-4
ユーザの umask 設定 5-6
RELEASE STORAGE 句、ALTER
SEGMENT 文 9-43
REMOVE DAMAGED SEGMENTS
オプション、ALTER
DATABASE CLEAN VERSION
LOG 文 6-19
RENAME 句、ALTER SEGMENT
文 9-43
REORG_ANY タスク権限 7-13
REORG 操作
ALTER SEGMENT の後 4-59
MAXROWS PER SEGMENT オプ
ションの影響 5-22
MAXSEGMENTS オプションの影
響 5-22
RESOURCE システム ロール
説明 2-37, 7-7
取り消し 7-8, 7-21
付与 7-8, 7-18
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
REVOKE 権限とロール コマン
ド 7-21
RISQL エントリ ツール
起動 A-8
ユーザ アカウント 7-3
RISQL エントリ ツールと RISQL レ
ポータ
説明 1-8
ユーザ アカウント 7-4
ロケール 2-32
ROLE_MANAGEMENT タスク権
限 7-13
S
SEGMENT BY 句
ALTER SEGMENT 文 9-43
CREATE INDEX 文 4-19, 4-20,
5-15, 5-16
CREATE TABLE 文 4-19, 5-15
SEGMENT LIKE 句
CREATE INDEX 文 4-19, 4-20,
5-15
SEGMENT LOCAL 句
CREATE INDEX 文 4-20
SERIAL 列、start 値と step 値の変
更 9-79
SERIAL 列の start 値と step 値 9-79
SET TRANSACTION ISOLATION
LEVEL 9-12
SET コマンド、SQL
DEFAULT SEGMENT STORAGE
PATH 5-19
IGNORE OPTICAL INDEXES 9-74
OPTICAL AVAILABILITY 9-73
PARTIAL AVAILABILITY 9-49
REPORT_INTERVAL 8-15
RESULT BUFFER 4-56
RESULT BUFFER FULL
ACTION 4-57
SEGMENT 5-20
TMU COMMIT RECORD
INTERVAL 6-5
TMU COMMIT TIME
INTERVAL 6-5
TMU VERSIONING 6-17
TRANSACTION ISOLATION
LEVEL 9-12
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
USE LATEST REVISION 6-21
VERSIONING 6-17
概要 2-24
指定 9-86
SKU 番号 3-15
SQL 構文、取り消し 8-11
STARjoin
定義 2-6
START ACCOUNTING 句、ALTER
SYSTEM 文 8-40
START CLEANING 句、ALTER
DATABASE 文 6-26
STOP CLEANING 句、ALTER
DATABASE 文 6-25
STOP ACCOUNTING 句、ALTER
SYSTEM 文 8-40
SuperScan 技術 2-5
SWITCH ACCOUNTING FILE 句、
ALTER SYSTEM 文 8-41
T
Table Management Utility (TMU) 1-7
Aroma の例 A-24 ∼ A-28
定期的なコミットでのロード 6-5
バージョニングの有効化 6-17
パラメータ TUNE B-19
TARGETjoin
定義 2-6
ローカル インデックス 2-10, 5-13
TEMP_RESOURCE タスク権
限 7-13
TMU。
「Table Management Utility
(TMU)」を参照。
TOTALFREE 列、
RBW_SEGMENTS テーブ
ル 9-35
USED 列、RBW_STORAGE テーブ
ル 9-34
USER、SQL 変数 5-58
USER_MANAGEMENT タスク権
限 7-13
V
VARCHAR 列
CHAR から変更 9-78
フィル ファクタの影響 5-24
フィル ファクタの監視 5-30
フィル ファクタの設定 5-24
フィル ファクタの変更 5-33
VERIFY 句
ALTER SEGMENT 文 9-70
VERIFY 句、ALTER SEGMENT
文 9-43, 9-55
破損したセグメント 9-69
Vista
Advisor ロギング コマンド 8-29
クエリ サンプリング 2-15
集約保守 2-14
説明 2-14
バージョニング 6-6
Visual Basic、データベース アクセ
ス 7-5
W
Windows のウェアハウス サービス
開始 9-99
監視 9-99
定義 1-10
停止 9-99
Write 回数 8-9
Write ロック 9-7
WRITE ロック オプション 9-6
U
UNFREEZE QUERY REVISION 句、
ALTER DATABASE 文 6-22
UPC レベル 3-22
UPGRADE_DATABASE タスク権
限 7-13
USAGE ROUTINE イベント 8-23,
8-29
あ
アイソレーション レベル 9-12
アウトボード テーブル 3-12
アウトリガー テーブル 3-12
アカウンティング
rbwlogd デーモン 8-35
開始 8-40
索引 5
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
な行
概要 8-34
環境設定 8-38
起動状態 8-38
サンプル コード 8-37
ジョブ モード 8-34
停止 8-40
パラメータ LA 8-35
ファイル 8-37
ファイルの切り替え 8-41
プロセス 8-35
モードの設定 8-39
モードの変更 8-41
レコード フォーマット 8-35
ワークロード モード 8-34
アカウンティング パラメータ
LA 8-35
アカウンティング ファイル
切り替え 8-41
サイズ 8-37, 8-39
削除 8-37
ロケーション 8-37, 8-38
アクセス権限 2-37, 7-3 ∼ 7-37
い
意思決定支援型データベース 3-5
一時テーブル 4-26
一時領域 4-56
TARGET インデックスの作
成 4-51
インデックス作成 4-41
クエリ 4-42
クエリ結果 4-42
ファイルの削除 4-53
一時領域のディレクトリ 4-41, 4-56
一過性テーブル 4-58
一般利用イベント 8-23
イベントのロギング
USAGE ROUTINE 8-23
開始 8-28
概要 8-15
カテゴリ 8-21, 8-22
環境設定 8-25
起動状態 8-25
重要度 8-21
重要度の変更 8-28
メッセージ 8-21
メッセージ テンプレート 8-17
6 Administrator’s Guide
F
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
ロギングのサブシステム 8-16
ログ デーモン 8-16
ログ ファイル 8-24
イミディエート ファミリ、定
義 2-40
インクリメンタル ロード 6-5
インストール、ロケールの定
義 2-30
インデックス
B-TREE
サイズの見積り 4-31
セグメントのアタッチ 9-44
定義 2-6
例 4-9
ローカル 2-10, 5-13
STAR
MAXROWS PER SEGMENT オ
プションの使用 5-22
MAXROWS PER SEGMENT の
指定がない場合のサイ
ズ 4-59
MAXSEGMENTS オプションの
使用 5-22
行の追加による影響 4-59
サイズの見積り 4-31
作成 4-6
シンプル スター スキーマ 3-7
セグメント化 5-16 ∼ 5-18
セグメントのアタッチ 9-44
定義 2-6
フィル ファクタ、変更 5-40
複数 2-6
無効、原因 4-59
例 4-7
TARGET
一時領域の所要量 4-51
概要 4-10
サイズの見積り 4-31
性能 4-10
セグメントのアタッチ 9-44
選択性 4-11
定義 2-6
ドメイン、格納領域 4-12
ドメイン、定義 4-11
ドメイン サイズの選択 4-11
ハイブリッド 4-11
例 4-10
ローカル 2-10, 5-13
概要 2-6
P
Q
R
S
T
U
V W
X
Y
わ行
サイズの見積り 4-27
削除 9-102
作成確認 5-35
作成のガイドライン 5-33
セグメント化された TARGET
サイズの見積り 4-32
セグメント化の基準となる
列 9-46
増加、監視 9-32
追加 4-4
光ディスク上のセグメントでの選
択 9-74
部分的な利用 2-13
並列 5-35
ローカル
サイズ見積り 4-32
作成 5-53
説明 4-13
定義 2-10, 5-13
う
ウェアハウス プロセス
CTRL-C 処理スレッド 1-14
概要 1-9 ∼ 1-14
サーバ プロセス 1-10
デーモン プロセス 1-10
バキューム クリーナ デーモ
ン 1-13
プロセス チェッカ デーモン 1-13
リスナ スレッド 1-14
ログ デーモン プロセス 1-12
え
エラー イベント 8-22
お
オブジェクト特権
概要 2-37
定義 7-9
付与 7-9
ロールへの付与 7-16
オプティマイズ モードのインデッ
クス作成のソート フェー
ズ 4-43
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
オプティマイズ モードのインデッ
クス作成のマージ フェー
ズ 4-43
オフライン操作
スペース計画 4-50
オペレーション イベント 8-23
オンライン マニュアル 13
オンライントランザクション処理
型データベース (OLTP) 3-3
か
開始、データベース サーバ 9-96
階層、削除 9-102
拡張スター スキーマ 3-21
格納領域のセグメント化
使用に向けての設計 4-16 ∼ 4-59
説明 2-7
デフォルト ロケーション 5-19
物理構成 2-9
カスケード デリート操作 2-40,
5-23
環境変数
ODBCINI 2-24
RB_CONFIG 2-25
RB_DSN 2-25
RB_EXE 2-25
RB_HOME 2-25
RB_HOST 2-25
RB_NLS_LOCALE 2-32
RB_PATH 2-25
RISQL エントリ ツール 7-4
ユーザ アカウント 7-4
環境変数 ODBCINI 2-24
環境変数 RB_CONFIG
説明 2-25
ユーザ アカウント 7-4
環境変数 RB_DSN 2-25
環境変数 RB_EXE 2-25
環境変数 RB_HOME 2-25
環境変数 RB_HOST
説明 2-25
ユーザ アカウント 7-4
環境変数 RB_NLS_LOCALE 2-32
環境変数 RB_PATH
説明 2-25
ユーザ アカウント 7-4
関係テーブル 3-11
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
監査イベント 8-22
監視
VARCHAR フィル ファクタ 5-30
データベース サーバ プロセ
ス 9-96
データベース動作 8-6
テーブルやインデックスのデータ
の増加 9-32
凍結バージョン 6-21
バージョン ログ領域 6-23
管理データベース 8-4
管理デーモン
出力 2-36
き
キーワード
構文ダイアグラム 9
キーワード CASCADE、使用方
法 5-23
キーワード CONSTRAINT 5-22
キーワード NO ACTION
使用方法 5-23
説明 2-40
記憶装置、光ディスク 9-71
期限切れのユーザ アカウント 7-28
キャッシュの入出力統計値 8-7
行、削除
参照整合性 2-40
テーブルのロック 9-10
行 ID
CREATE STAR INDEX 文 4-19,
5-15
説明 5-16
行単位で再利用 9-35
行番号
1 ブロックあたり 5-26
1 ブロックあたりの行数 5-24,
5-31
CREATE STAR INDEX 文 4-19,
5-15
RBW_ROWNUM シュード列 9-44
RBW_SEGNAME シュード
列 9-36
VARCHAR フィル ファクタの影
響 5-25
行 ID 5-16
説明 9-36
データベース サーバによる使
用 5-24
範囲の移動 9-48
範囲の指定 9-44, 9-48
未使用 5-25, 5-28, 5-29
共有メモリ 1-14
く
クエリ
ロギング 8-23, 8-29
クエリ サンプリング 2-15
クエリのロギング 8-29
クライアント / サーバ環境
互換性 2-34
異なるロケール 2-31
クライアント ツール
RISQL エントリ ツールと RISQL
レポータ 2-32
サード パーティ 2-32
ロケール 2-32
クリーンアップ、一時領域 4-53
け
言語
定義 2-27
変換されないテキスト 2-31
変更の影響 2-31, 2-35
こ
構成パラメータ
ACCOUNTING 8-38, B-29
ACCT_DIRECTORY 8-37, 8-38,
B-29
ACCT_LEVEL 8-39, B-30
ACCT_MAXSIZE 8-37, 8-39, B-29
ADMIN
ADVISOR_LOGGING 8-31
ADVISOR_LOG_DIRECTORY 830, 8-32, B-31
ADVISOR_LOG_MAXSIZE 8-29,
8-33, B-31
ADVISOR_SAMPLE_SIZE B-26
ALLOW_LOGNAME B-32
索引 7
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
な行
ALLOW_POSSIBLE_DEADLOCK
B-13
ARITHABORT B-13
AUTOROWGEN B-13
BAR_UNIT_SIZE B-26
BARTAPE B-18
CHANGE_INITIAL B-32
CHANGE_MINIMUM_DAYS B-3
2
CHECK_REPORT_FILE_PERMISS
IONS B-14
CHECK_TABLE_INDEX_DIRECT
ORY B-14
CLEANUP_SCRIPT B-11
COMPLEX_NUM_ALPHA B-32
COMPLEX_NUM_NUMERICS B32
COMPLEX_NUM_PUNCTUATIO
N B-32
COMPLEX_NUMERIC B-32
COUNT_RESULT B-14
CROSS_JOIN B-13
DEFAULT_DATA_SEGMENT B27
DEFAULT_INDEX_SEGMENT B27
DEFAULT_PSU_EXTENDSIZE B29
DEFAULT_SEGMENT_SIZE B-29
EXPIRATION_DAYS B-32
EXPIRATION_WARNING_DAYS
B-32
EXPORT_DEFAULT_PATH B-17
EXPORT_DELIMITER B-17
EXPORT_MAX_FILE_SIZE B-17
FILE_GROUP B-20
FILLFACTOR B-21
FILLFACTOR_VARCHAR B-21
FIRST_DAYOFWEEK B-13
FORCE_AGGREGATION_TASKS
B-21
FORCE_FETCH_TASKS B-20
FORCE_HASHJOIN_TASKS B-21
FORCE_JOIN_TASKS B-20
FORCE_SCAN_TASKS B-20
FORCE_TARGETJOIN_TASKS B20
GRANT_TEMP_RESOURCE_TO_
ALL B-14
8 Administrator’s Guide
F
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
わ行
GROUP B-20
IDLE_TIMEOUT B-17
IGNORE_OPTICAL_INDEXES 974, B-28
IGNORE_PARTIAL_INDEXES B28
INDEX_TEMPSPACE_DIRECTOR
Y 4-43, B-23
INDEX_TEMPSPACE_MAXSPILL
SIZE 4-43, B-23
INDEX_TEMPSPACE_THRESHO
LD 4-43, 4-47, 4-48, B-23
INFO_MESSAGE_LIMIT B-27
INTERVAL B-13
LOCALE B-12
LOCK_FAILED_ATTEMPTS B-33
LOCK_PERIOD_HOURS B-33
LOG_AUDIT_LEVEL 8-27, B-30
LOG_DIRECTORY 8-24, 8-25,
B-30
LOG_ERROR_LEVEL 8-27, B-30
LOG_MAXSIZE 8-24, 8-26, B-30
LOG_OPERATIONAL_LEVEL 827, B-30
LOG_SCHEMA_LEVEL 8-27,
B-30
LOG_USAGE_LEVEL 8-27, B-31
LOGFILE_SIZE B-12
LOGGING 8-25, B-30
MAPFILE B-11
MAX_ACTIVE_DATABASES B-1
2
MAX_SERVERS B-11
MESSAGE_DIR B-12
MINIMUM_LENGTH B-33
NLS_LOCALE LOCALE 2-30
NLS_LOCALE
MESSAGE_DIR 2-35
OLAP_APPROXIMATE_NUMERI
C_FAST_COMPUTATION B-2
2
OPTICAL_AVAILABILITY 9-73,
B-29
OPTION
ADVISOR_LOGGING B-15
OPTION
ADVISOR_MAXIMUM_CAND
IDATE_VIEWS B-16
OPTION BAR_XBSA_LIB B-18
PARALLEL_HASHJOIN B-21
PARALLEL_SET_OPERATION B
-21
PARTIAL_AVAILABILITY B-28
PARTITIONED_PARALLEL_AGG
REGATION B-21
PERFORMANCE_MONITOR_CO
MMANDS B-22
PERFORMANCE_MONITOR_MA
XOPERATORS B-22
PERFORMANCE_MONITOR_SES
SIONS B-22
PRECOMPUTED_VIEW_MAINTE
NANCE B-17
PRECOMPUTED_VIEW_MAINTE
NANCE_ON_ERROR B-18
PRECOMPUTED_VIEW_QUERY_
REWRITE B-15
PROCESS_CHECKING_INTERVA
L B-12
QUERY_MEMORY_LIMIT B-23
QUERY_TEMPSPACE_DIRECTO
RY B-24
QUERY_TEMPSPACE_MAXSPIL
LSIZE B-23
QUERYPROCS B-19
RANDOM_SAMPLE_MARGIN B26
rbw.config の設定
RBW_LOADINFO_LIMIT B-27
READER_PRIORITY 9-7, B-13
REMOTE_TMU_LISTENER B-12
RENICE_COMMAND 8-12, B-31
REPORT_INTERVAL 8-14, B-31
RESTRICT_PREVIOUS B-32
RESULT_BUFFER B-21
RESULT_BUFFER_FULL_ACTIO
N B-21
ROWCOUNT B-27
ROWS_PER_FETCH_TASK B-19
ROWS_PER_SCAN_TASK B-19
SERVER B-11
SERVER_NAME B-12
SHMEM B-11
TEMPORARY_DATA_SEGMENT
B-27
TEMPORARY_INDEX_SEGMENT
B-28
TMU_BUFFERS B-19
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
TMU_COMMIT_RECORD_INTER
VAL B-16
TMU_COMMIT_TIME_INTERVA
L B-17
TMU_CONVERSION_TASKS B-2
4
TMU_INDEX_TASKS B-25
TMU_INPUT_TASKS B-25
TMU_MAX_TASKS B-25
TMU_MMAP_LIMIT B-25
TMU_OPTIMIZE B-22
TMU_ROW_MESSAGES B-24
TMU_SERIAL_MODE B-24
TMU_VERSIONING B-16
TOTALQUERYPROCS B-20
TRANSACTION_ISOLATION_LE
VEL B-16
UNIFIED_LOGON B-12
UNIFORM_PROBABILITY_FOR_
ADVISOR B-15
USE_INVALIDATE_PRECOMPUT
ED_VIEWS B-15
VERSIONING B-16
XML_MAX_TASKS B-23
XML_TEMP_SPACE B-22
構成パラメータ LOG
_MAXSIZE 8-24
構成パラメータ LOG_DIRECTORY
使用方法 8-24, 8-25
構成パラメータ LOG_MAXSIZE
使用方法 8-26
構成パラメータ LOGGING
使用方法 8-25
構成パラメータ
LOG_AUDIT_LEVEL
rbw.config ファイル エント
リ B-30
使用方法 8-27
構成パラメータ LOG_DIRECTORY
rbw.config ファイル エント
リ B-30
構成パラメータ
LOG_ERROR_LEVEL
rbw.config ファイル エント
リ B-30
使用方法 8-27
構成パラメータ LOG_MAXSIZE
rbw.config ファイル エント
リ B-30
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
サーバ プロセス 1-10
サービス、ウェアハウス、概
要 1-9
R
S
T
U
V W
X
Y
Z
わ行
構成パラメータ
LOG_OPERATIONAL_LEVEL
使用方法 8-27
構成パラメータ
LOG_OPERATIONAL_LEVEL
rbw.config ファイル エント
リ B-30
構成パラメータ
LOG_SCHEMA_LEVEL
rbw.config ファイル エント
リ B-30
使用方法 8-27
構成パラメータ
LOG_USAGE_LEVEL
rbw.config ファイル エント
リ B-31
使用方法 8-27
構成パラメータ LOGGING
rbw.config ファイル エント
リ B-30
構成ファイル
エントリ B-10
説明 B-1
パラメータのまとめ B-34
変更 9-87
例 B-2
高復旧性バージョニング
説明 6-16
凍結バージョンの使用 6-22
構文ダイアグラム
キーワード 9
表記規則 7
変数 9
コード セット
ASCII 2-28
定義 2-28
変換 2-32, 2-34
変更の影響 2-31
コスト、バージョン ログ 6-7
コピー管理ユーティリティ 8-3,
9-82
コンプリート ファミリ、定義 2-40
さ
Q
最初のログイン、パスワード 7-32
サイズの見積り
B-TREE インデックス 4-31
STAR インデックス 4-31
TARGET インデックス 4-31
システム テーブル 4-39
セグメント化された TARGET イ
ンデックス 4-32
テーブルとインデック 4-25
例、データベース サイズの見積
り 4-33
算術エラー、オプション B-13
参照先テーブル
アウトボード、アウトリ
ガー 3-12
定義 3-7
参照整合性
ON DELETE 句 5-23
削除操作 2-40
削除動作、定義 5-23
定義 2-39
データのロードと挿入 2-39
参照元テーブル 3-7
サンプリング、クエリの結果 2-15
サンプル データベース、インス
トール スクリプト 4
し
システム、データベース ユーザ ア
カウント 5-9
システム アカウント、新規ユーザ
用 7-4
システムカタログ、内容 C-2
システム テーブル
サイズの見積り 4-39
説明 C-1 ∼ C-27
ロケールの参照 2-30
システム ロール
概要 2-37
説明 7-7
取り消し 7-8, 7-21
付与 7-8, 7-18
事前計算ビュー 2-14
シノニム
削除 9-103
シュード列 5-17, 9-36
集約テーブル
索引 9
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
な行
説明 2-14
例 3-28
集約保守 2-14
ジョイン
テーブルの関連付け 4-59
ファクト テーブル間、インデッ
クス 4-5
フォーリン キー参照 2-6
照合シーケンス 2-29
初期化ファイル 1-17, 2-22
ジョブ アカウンティング 8-34
す
スキーマ イベント 8-23
スキーマのロック 9-7
スクラッチ領域、所要量の見積
り 4-43
スター スキーマ 3-32
サポートされるタイプ 3-32
性能 3-7
設計上の考慮事項 3-17
説明 3-6
属性の使用 3-24
例 3-19, 3-32
スレッド、定義 1-9
せ
制限、データベース サーバ 1-20
制限付き削除操作 5-23
静止、データベース 8-10
性能
STAR インデックス 4-6
TARGET インデックス 4-10
スキーマ設計 3-7
制約、低い選択性 4-11
セカンダリ ディメンジョン テーブ
ル 3-12
セキュリティ
パスワード 7-26
ロールに基づく 7-11
セグメント
アタッチ 9-44
移動 9-55
オンライン / オフライン 2-12,
9-49
同期化 9-49
10 Administrator’s Guide
F
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
切り離し 9-44
クリア 9-49
検証 9-55
再利用 9-57
削除 9-103
作成のガイドライン 4-58, 5-12,
5-15
自動ロック 9-9
使用可能な領域 9-32 ∼ 9-33
新規セグメントの追加 9-63
正常 9-56
定義 2-7
定期的に更新するデータ、
例 5-41 ∼ 5-56
デフォルト
定義 2-8
名前付きセグメントへの変
更 4-17
名前付き 2-8, 4-16
名前の変更 9-49
破損 9-55
破損、復旧 9-69 ∼ 9-71
パラメータ
DEFAULT_SEGMENT_SIZE 4
-21
範囲、移動 9-48
範囲、変更 9-48
光ディスク、定義 9-72
部分的な利用 2-13
分散、データ 2-10
変更 9-42 ∼ 9-56
領域の追加 9-39
ロールオフ 9-57
セグメント化された STAR イン
デックスの図 5-54
セグメントのアタッチ 9-44
セグメントの切り離し 9-44
セグメントのクリア 9-49
セグメントの再利用 9-57
セグメント パラメータ
rbw.config のエントリ B-27
セグメント名の変更 9-49
セッション
終了 8-11
ユーザ優先順位の変更 8-12
接続の上限
rbw.config ファイル エント
リ B-11
変更 9-87
P
Q
R
S
T
U
V W
X
Y
わ行
接続を禁止する時間、指定 7-37
ゼロ除算エラー、オプション B-13
選択性、定義 4-11
そ
相互参照テーブル 3-11
挿入およびロード操作時のデータ
の参照整合性 2-39
ソートの要素
定義 2-29
変更の影響 2-31
属性、スキーマ設計による影
響 3-24
ソフトウェア要件 4
た
タスク権限
ACCESS_SYSINFO 8-4
ALTER_SYSTEM 8-4
定義 7-12
データベース動作の管理 8-4
付与 7-16
多対 1 の関係、フォーリン
キー 3-8
多対多の関係
定義、ファクト テーブル 3-11
定義、複数列フォーリン
キー 3-11
断続更新アプリケーション 6-5
ち
注意
OVERRIDE REFCHECK 5-23
セグメント用の FORCE
INTACT 9-56
調整
データベース 1-19
て
定期的なコミット 6-5
定期的に更新するデータ
STAR インデックス 4-22, 5-41
設計 4-22
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
ローカル インデックス 4-13
定期的に更新するデータ、例 5-41
∼ 5-56
停止、データベース サーバ 9-96
ディスク スピル ファイル、削
除 4-53
ディスク領域
一時領域の所要量、見積り 4-43
∼ 4-56
オンラインロードの所要量 4-50
格納領域のセグメント化による構
成 4-16
再利用 9-35
テーブルとインデックスのサイ
ズ、予測 4-25
テーブルの拡大、設計 4-58
割り当て 4-58, 5-14
ディメンジョン テーブル
大規模 4-14
定義 3-7
バージョニングを使用したクリー
ニング 6-7
ディメンジョン テーブルの検
索 3-23
データ
構成 4-3
削除時の参照整合性 5-23
削除操作時の参照整合性 2-40
集約 3-28
ロード 2-3
データ型
サイズ C-39
列の変更 9-78
データソース名の定義 2-24
データのアンロード
概要 1-18
凍結バージョン 6-22
データのロード
インクリメンタル 6-5
概要 1-18, 2-3
高復旧性 6-16
定期的なコミット 6-5
定期的に更新するデータ、
例 5-41 ∼ 5-56
データベースがオンラインである
間 9-7
バージョン管理されたデータベー
ス 6-8
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
例、Aroma データベース A-17 ∼
A-28
データ ブロック、バージョン ロ
グ 6-11
データベース
アクセス 7-3 ∼ 7-37
移動 9-55, 9-82
拡大パターン 4-58
稼動 8-10
コピー 9-55, 9-82
サイズの見積り例 4-33
削除 1-16, 9-105
作成 1-16
手順 5-3 ∼ 5-62
例、Aroma A-1 ∼ A-29
システムのアカウントとパスワー
ド 5-9
実装 1-16, 2-6
新規追加 5-8
制限と最大サイズ 1-20
静止 8-10
セグメントのデフォルト ロケー
ション 5-13
設計 1-15
調整 1-19
データ テーブルの構成 4-3
データのロード A-24
データベース オブジェクトの削
除 9-101, 9-104
テーブルとインデックスのサイ
ズ、予測 4-25
凍結 6-21
凍結解除 6-22
動作の監視 8-6
動作の制御 8-9
バージョニングでのバックアップ
と復元 6-24
パスワード セキュリティ 7-26 ∼
7-37
パスワードの変更 7-6, A-8
メンテナンス 1-19
ユーザの追加 7-5
ロック 9-6 ∼ 9-13
ロックする時期 9-10
論理名 2-16
rbw.config ファイル エント
リ B-33
定義 5-8
データベース管理者
DBA アカウント 2-37
ロール 1-19
データベース サーバ
UNIX での監視 9-96
Windows 1-7
Windows での監視 9-99
Windows での停止 9-99
インストール 2-21
最大数 B-11
制限 1-20
説明 1-7
ソフトウェア構成要素 1-5
データベース サーバ ソフトウェア
のバージョン 9-100
データベース サーバのインストー
ル 1-15, 2-21
データベース ディレクトリ、定
義 2-15
データベース動作の制御 8-9
データベースの管理、概要 1-14
データベースの作成、Aroma
チュートリアル A-1 ∼ A-29
データベースの設計 1-15
データベースのメンテナンス 1-19
データベース論理名
rbw.config ファイル エント
リ B-33
説明 2-16
定義 5-8
テーブル
Aroma テーブルの作成 A-8
アクセス、ビューを使った制
限 5-58
一過性 4-58
拡大 4-58
行の追加、STAR インデックスへ
の影響 4-59
検索 3-23
サイズの見積り 4-26
削除 9-103
作成のガイドライン
MAXROWS PER SEGMENT の
設定 5-22
MAXSEGMENTS の設定 5-22
削除における参照整合性 5-22
順序 5-21
フォーリン キーの順序 5-22
システム テーブル、サイズの見
積り 4-39
索引
11
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
な行
セグメント化の基準となる
列 9-46
セグメントのアタッチ 9-44
セグメント内 5-13
増加、監視 9-32
光記憶装置 9-73
ファミリ、イミディエートとコン
プリート 2-40
複数のファクト テーブル 3-9
部分的な利用 2-13
変更 9-75
ロック 9-6, 9-13
ロックする時期 9-10
テーブルやインデックスの可用
性 9-49
デッドロック 9-11
テリトリ
定義 2-28
変更の影響 2-31, 2-35
テンポラリ マクロ
削除 9-102
範囲 5-60
と
同期
セグメント 9-49
統計値
Read と Write 8-7
収集間隔 8-14
プラットフォームが利用効率に与
える影響 8-9
リセット 8-11
統計値のリセット 8-11
凍結バージョン
実行できない操作 6-15
実行できる操作 6-15
制御 6-21
定義 6-13
無効化 6-21
動的統計テーブル
DST_COMMANDS C-28
DST_DATABASES C-30
DST_LOCKS C-32
DST_SESSIONS C-33
DST_USERS C-36
RBW_TABLES テーブル 8-6
概要 8-6
12 Administrator’s Guide
F
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
更新間隔 8-14
統計収集の間隔 8-14
読者
対象読者 3
ドメイン、TARGET インデックス
格納領域の表現形式 4-12
サイズ指定 4-11
定義 4-11
トランザクション
単一の文 2-38
定義 2-38
トランザクション処理型データ
ベース 3-3
は
バージョニング
Vista 6-6
オプション 6-16
高復旧性オプション 6-16
高復旧性と凍結バージョン 6-22
コスト 6-7
定期的なコミット オプショ
ン 6-5
ディメンジョン テーブルのク
リーニング 6-7
データのロード 6-8
データベースの利用効率 6-4
凍結バージョン、制御 6-21
凍結バージョン、理解 6-13
バキューム クリーナの制御 6-25
必要性の特定 6-4
ブロックの削除 6-13
有効化 6-16
バージョン管理されたデータベー
ス
Aroma データベースの例 6-26
説明 2-38
バージョン管理されたトランザク
ション、定義 2-38
バージョン ログ
PSU 6-11
空であることの確認 6-19
監視 6-23
クリーニング 6-19
構造 6-11
高復旧性 6-16
コスト 6-7
P
Q
R
S
T
U
V W
X
Y
わ行
サイズ見積り 6-18
削除 6-20
削除されたブロック 6-13
作成 6-18
性能の調整 6-18
先行書き込みログとしての使
用 6-16
データ ブロック 6-11
データベースの監視 6-23
有効化 6-16
理解 6-10
領域の追加 6-20
領域の割り当て 6-18
バイナリ方式の文字比較 2-29
バキューム クリーナ デーモン
手動での開始 6-26
手動での停止 6-25
制御 6-25
説明 1-13
パス名、相対と絶対 9-82
パスワード
一般的な制限 5-10
期限切れ警告 7-29
再使用の制限 7-30
最初のログイン時の強制変
更 7-32
最初のログインでの変更 7-32
システム アカウント、変更 5-9
システム デフォルトの変更 A-8
使用、ユーザ ログイン名 7-32
新規ユーザ 7-5
制約、標準 7-6
セキュリティ 7-26
セキュリティ パラメータ 7-26
接続を禁止する時間 7-37
必要最少文字数 7-34
変更 7-6
変更、強制 7-27
変更頻度 7-31
文字の組み合わせと長さ 7-34
有効期限 7-27
ログイン名 7-32
ロックされたアカウント 7-36
破損したセグメントの復旧 9-69
バックアップ操作
インデックス作成時 5-33
概要 1-19
バージョン管理されたデータベー
ス 6-24
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
バージョン ログのクリーニン
グ 6-19
ハッシュ
ジョイン 4-13
パブリック マクロ 5-60
パラメータ DEFAULT
まとめ B-40
パラメータ。「構成パラメータ」を
参照。
パラメータ ACCOUNTING
rbw.config ファイル エント
リ B-29
使用方法 8-38
パラメータ ACCT_DIRECTORY
rbw.config ファイル エント
リ B-29
使用方法 8-37, 8-38
パラメータ ACCT_LEVEL
rbw.config ファイル エント
リ B-30
使用方法 8-39
パラメータ ACCT_MAXSIZE
rbw.config ファイル エント
リ B-29
使用方法 8-37, 8-39
パラメータ ADMIN
rbw.config のエントリ B-29
変更 9-91, 9-95
まとめ B-40
パラメータ ADMIN
ADVISOR_LOGGING
rbw.config ファイル エント
リ B-31
使用方法 8-31
変更 9-87, 9-92
パラメータ
ADVISOR_LOG_DIRECTORY
rbw.config ファイル エント
リ B-31
使用方法 8-32
ログ ファイルでの使用 8-30
パラメータ
ADVISOR_LOG_MAXSIZE
rbw.config ファイル エント
リ B-31
使用方法 8-33
ログ ファイルでの使用 8-29
パラメータ ADVISOR_LOGGING
変更 9-90
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
パラメータ ADVISOR_LOGGING、
ADMIN
rbw.config ファイル エント
リ B-31
パラメータ ADVISOR_LOGGING、
OPTION
rbw.config ファイル エント
リ B-15
パラメータ
ADVISOR_MAXIMUM_CANDI
DATE_VIEWS
変更 9-90, 9-94
パラメータ
ADVISOR_MAXIMUM_CANDI
DATE_VIEWS、OPTION
rbw.config ファイル エント
リ B-16
パラメータ
ADVISOR_SAMPLE_SIZE
rbw.config ファイル エント
リ B-26
変更 9-90, 9-94
パラメータ ALLOW_LOGNAME
rbw.config ファイル エント
リ B-32
使用方法 7-32
パラメータ
ALLOW_POSSIBLE_DEADLOC
K
rbw.config ファイル エント
リ B-13
構文と使用方法 9-11
変更 9-89, 9-93
パラメータ ARITHABORT
rbw.config ファイル エント
リ B-13
変更 9-89, 9-93
パラメータ AUTOROWGEN
rbw.config ファイル エント
リ B-13
変更 9-91, 9-94
パラメータ BAR_SM_USER
変更 9-88, 9-92, 9-95
パラメータ BAR_UNIT_SIZE
rbw.config ファイル エント
リ B-26
変更 9-91
パラメータ BAR_XBSA_LIB
変更 9-88, 9-92, 9-94
パラメータ BARTAPE
rbw.config ファイル エント
リ B-18
変更 9-91
パラメータ CHANGE_INITIAL
rbw.config ファイル エント
リ B-32
使用方法 7-32
パラメータ
CHANGE_MINIMUM_DAYS B32
パラメータ
CHECK_REPORT_FILE_PERMI
SSIONS
rbw.config ファイル エント
リ B-14
ファイルの変更 9-89, 9-93
パラメータ
CHECK_TABLE_INDEX_DIREC
TORY
rbw.config ファイル エント
リ B-14
変更 9-89, 9-93
パラメータ CLEANUP_SCRIPT
rbw.config ファイル エント
リ B-11
構文と使用方法 4-53
ファイルの変更 9-87
変更 9-92
パラメータ
COMPLEX_NUM_ALPHA
rbw.config ファイル エント
リ B-32
使用方法 7-34
パラメータ
COMPLEX_NUM_NUMERICS
rbw.config ファイル エント
リ B-32
使用方法 7-35
パラメータ
COMPLEX_NUM_PUNCTUATI
ON
rbw.config ファイル エント
リ B-32
使用方法 7-35
パラメータ COMPLEX_NUMERIC
rbw.config ファイル エント
リ B-32
使用方法 7-32
索引
13
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
な行
パラメータ COUNT_RESULT
rbw.config ファイル エント
リ B-14
変更 9-89, 9-93
パラメータ CROSS_JOIN
rbw.config ファイル エント
リ B-13
変更 9-89, 9-93
パラメータ DEFAULT
rbw.config のエントリ B-27
パラメータ
DEFAULT_DATA_SEGMENT
rbw.config ファイル エント
リ B-27
構文と使用方法 5-19
複数データベース 5-13
変更 9-89, 9-93
パラメータ
DEFAULT_INDEX_SEGMENT
rbw.config ファイル エント
リ B-27
構文と使用方法 5-19
複数データベース 5-13
変更 9-89, 9-93
パラメータ
DEFAULT_PSU_EXTENDSIZE
rbw.config ファイル エント
リ B-29
説明 4-21
変更 9-89, 9-93
パラメータ
DEFAULT_SEGMENT_SIZE
rbw.config ファイル エント
リ B-29
説明 4-21
変更 9-89, 9-93
パラメータ EXPIRATION_DAYS
rbw.config ファイル エント
リ B-32
使用方法 7-27, 7-31
パラメータ
EXPIRATION_WARNING_DAY
S
rbw.config ファイル エント
リ B-32
使用方法 7-29
パラメータ
EXPORT_DEFAULT_PATH
14 Administrator’s Guide
F
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
わ行
rbw.config ファイル エント
リ B-17
変更 9-89, 9-93
パラメータ EXPORT_DELIMITER
rbw.config ファイル エント
リ B-17
変更 9-89, 9-93
パラメータ
EXPORT_MAX_FILE_SIZE
rbw.config ファイル エント
リ B-17
変更 9-89, 9-93
パラメータ FILE_GROUP
rbw.config ファイル エント
リ B-20
変更 9-89, 9-93
パラメータ FILLFACTOR
rbw.config ファイル エント
リ B-21
使用方法 5-37
変更 5-33, 5-40, 9-91, 9-95
パラメータ
FILLFACTOR_VARCHAR、
rbw.config ファイル エント
リ B-21
パラメータ FIRST_DAYOFWEEK
rbw.config ファイル エント
リ B-13
変更 9-89, 9-93
パラメータ FORCE
TARGETJOIN_TASK
変更 9-89
パラメータ
FORCE_AGGREGATION_TASK
S
rbw.config ファイル エント
リ B-21
変更 9-89, 9-93
パラメータ FORCE_FETCH_TASKS
rbw.config ファイル エント
リ B-20
変更 9-89, 9-93
パラメータ
FORCE_HASHJOIN_TASKS
rbw.config ファイル エント
リ B-21
変更 9-89, 9-93
パラメータ FORCE_JOIN_TASKS
rbw.config ファイル エント
リ B-20
変更 9-89, 9-93
パラメータ FORCE_SCAN_TASKS
rbw.config ファイル エント
リ B-20
変更 9-89, 9-93
パラメータ
FORCE_TARGETJOIN_TASKS
rbw.config ファイル エント
リ B-20
パラメータ
GRANT_TEMP_RESOURCE_TO
_ALL
rbw.config ファイル エント
リ B-14
変更 9-89
パラメータ
GRANT_TEMP_RESOURCES_T
O_ALL
変更 9-93
パラメータ GROUP
rbw.config ファイル エント
リ B-20
変更 9-89, 9-93
パラメータ IDLE_TIMEOUT
rbw.config ファイル エント
リ B-17
変更 9-90, 9-92
パラメータ
IGNORE_OPTICAL_INDEXES
rbw.config ファイル エント
リ B-28
構文と使用方法 9-74
変更 9-89, 9-93
パラメータ
IGNORE_PARTIAL_INDEXES
rbw.config ファイル エント
リ B-28
変更 9-90, 9-94
パラメータ INDEX_TEMPSPACE
DIRECTORY 4-43
rbw.config ファイル エント
リ B-23
使用 4-44
ロケーション 5-34
MAXSPILLSIZE 4-43
rbw.config ファイル エント
リ B-23
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
オフライン ロード 4-51
サイズの決定 4-49
THRESHOLD 4-43
rbw.config ファイル エント
リ 4-47, 4-48, B-23
値の決定 4-48
値の決定 4-43
オフライン ロード操作での使
用 4-50
現在値 4-52
設定 4-41
説明 4-43
変更 9-91, 9-95
リセット 4-46
パラメータ
INFO_MESSAGE_LIMIT
rbw.config ファイル エント
リ B-27
変更 9-89, 9-93
パラメータ INTERVAL
rbw.config ファイル エント
リ B-13
使用方法 9-97
変更 9-88
パラメータ LOCALE
rbw.config ファイル エント
リ B-12
変更 9-88, 9-92
パラメータ
LOCK_FAILED_ATTEMPTS B33
使用方法 7-36
パラメータ
LOCK_PERIOD_HOURS
rbw.config ファイル エント
リ B-33
使用方法 7-37
パラメータ LOGFILE_SIZE
rbw.config ファイル エント
リ B-12
変更 9-87, 9-92
パラメータ MAPFILE
rbw.config ファイル エント
リ B-11
パラメータ
MAX_ACTIVE_DATABASES
rbw.config ファイル エント
リ B-12
変更 9-87, 9-92
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
パラメータ MAX_SERVERS
rbw.config ファイル エント
リ B-11
変更 9-87, 9-92
パラメータ MESSAGE_DIR
rbw.config ファイル エント
リ B-12
変更 9-88, 9-92
パラメータ MINIMUM_LENGTH
rbw.config ファイル エント
リ B-33
使用方法 7-34
パラメータ NLS_LOCALE 2-30
rbw.config のエントリ B-12
まとめ B-35
パラメータ NLS_LOCALE
MESSAGE_DIR 2-35
パラメータ
OLAP_APPROXIMATE_NUME
RIC_FAST_COMPUTATION
変更 9-89, 9-93
パラメータ
OPTICAL_AVAILABILITY
rbw.config ファイル エント
リ B-29
構文と使用方法 9-73
変更 9-89, 9-93
パラメータ OPTION
rbw.config のエントリ B-13
まとめ B-37
パラメータ OPTION
ADVISOR_LOGGING
rbw.config ファイル エント
リ B-15
変更 9-90, 9-94
パラメータ OPTION
ADVISOR_MAXIMUM_CANDI
DATE_VIEWS
rbw.config ファイル エント
リ B-16
変更 9-90, 9-94
パラメータ OPTION
BAR_XBSA_LIB
rbw.config ファイル エント
リ B-18
パラメータ OPTION
OLAP_APPROXIMATE_NUME
RIC_FAST_COMPUTATION
rbw.config ファイル エント
リ B-22
パラメータ OPTION
PRECOMPUTED_VIEW_QUER
Y_ REWRITE
変更 9-90
パラメータ OPTION
PRECOMPUTED_VIEW_QUER
Y_REWRITE
変更 9-94
パラメータ OPTION
USE_INVALID_PRECOMPUTE
D_VIEWS
変更 9-94
パラメータ PARALLEL_HASHJOIN
rbw.config ファイル エント
リ B-21
パラメータ
PARALLEL_SET_OPERATION
rbw.config ファイル エント
リ B-21
変更 9-89, 9-93
パラメータ
PARTIAL_AVAILABILITY
rbw.config ファイル エント
リ 9-49, B-28
変更 9-90, 9-94
パラメータ
PARTITIONED_PARALLEL_AG
GREGATION
rbw.config ファイル エント
リ B-21
変更 9-89, 9-93
パラメータ PASSWORD
ALLOW_LOGNAME 7-32
CHANGE_INITIAL 7-32
CHANGE_MINIMUM_DAYS 7-31
COMPLEX_NUM_ALPHA 7-34
COMPLEX_NUM_NUMERICS 735
COMPLEX_NUM_PUNCTUATIO
N 7-35
COMPLEX_NUMERIC 7-32
EXPIRATION_DAYS 7-27
EXPIRATION_WARNING_DAYS
7-29
LOCK_FAILED_ATTEMPTS 7-36
LOCK_PERIOD_HOURS 7-37
MINIMUM_LENGTH 7-34
索引
15
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
な行
rbw.config のエントリ B-32
RESTRICT_PREVIOUS 7-30
説明 7-26
変更 9-91, 9-95
まとめ B-41
パラメータ
PERFORMANCE_MONITOR_C
OMMANDS
rbw.config ファイル エント
リ B-22
変更 9-90, 9-94
パラメータ
PERFORMANCE_MONITOR_M
AXOPERATORS
rbw.config ファイル エント
リ B-22
変更 9-88, 9-92
パラメータ
PERFORMANCE_MONITOR_SE
SSIONS
rbw.config ファイル エント
リ B-22
変更 9-88, 9-92
パラメータ
PRECOMPUTED_VIEW_MAINT
ENANCE
rbw.config ファイル エント
リ B-17
変更 9-90, 9-94
パラメータ
PRECOMPUTED_VIEW_MAINT
ENANCE_ON_ERROR
rbw.config ファイル エント
リ B-18
変更 9-90, 9-94
パラメータ
PRECOMPUTED_VIEW_QUER
Y_REWRITE
rbw.config ファイル エント
リ B-15
変更 9-90, 9-94
パラメータ
PROCESS_CHECKING_INTERV
AL
rbw.config ファイル エント
リ B-12
変更 9-87, 9-92
パラメータ
QUERY_MEMORY_LIMIT
16 Administrator’s Guide
F
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
値の見積り 4-55
変更 9-90, 9-94
パラメータ
QUERY_TEMPSPACE 4-41
DIRECTORY
rbw.config ファイル エント
リ B-24
使用 4-44
MAXSPILLSIZE
rbw.config ファイル エント
リ B-23
値 4-56
QUERY_MEMORY_LIMIT
rbw.config ファイル エント
リ B-23
クエリへの影響 4-53
現在値 4-52
説明 4-53 ∼ 4-56
変更 9-90, 9-94
パラメータ
QUERY_TEMPSPACE_DIRECT
ORY
rbw.config ファイル エント
リ B-24
パラメータ
QUERY_TEMPSPACE_MAXSPI
LLSIZE
rbw.config ファイル エント
リ B-23
パラメータ QUERYPROCS
rbw.config ファイル エント
リ B-19
変更 9-87, 9-92
パラメータ
RANDOM_SAMPLE_MARGIN
rbw.config ファイル エント
リ B-26
変更 9-90, 9-94
パラメータ RBMON B-34
パラメータ
RBW_LOADINFO_LIMIT
rbw.config ファイル エント
リ B-27
変更 9-89, 9-93
パラメータ RBWAPI
rbw.config のエントリ B-11
まとめ B-34
パラメータ RBWMON B-13
パラメータ READER_PRIORITY
P
Q
R
S
T
U
V W
X
Y
わ行
rbw.config ファイル エント
リ B-13
競合の軽減 9-7
変更 9-87, 9-92
パラメータ
REMOTE_TMU_LISTENER
rbw.config ファイル エント
リ B-12
変更 9-87, 9-92
パラメータ RENICE_COMMAND
rbw.config ファイル エント
リ B-31
ユーザ優先順位 8-12
パラメータ REPORT_INTERVAL
rbw.config ファイル エント
リ B-31
使用方法 8-14
変更 9-91, 9-95
パラメータ RESTRICT_PREVIOUS
rbw.config ファイル エント
リ B-32
使用方法 7-30
パラメータ RESULT_BUFFER
rbw.config ファイル エント
リ B-21
説明 4-56
変更 9-90, 9-94
パラメータ
RESULT_BUFFER_FULL_ACTI
ON
rbw.config ファイル エント
リ B-21
説明 4-57
変更 9-90, 9-94
パラメータ ROWCOUNT
rbw.config ファイル エント
リ B-27
変更 9-89, 9-93
パラメータ
ROWS_PER_FETCH_TASK
rbw.config ファイル エント
リ B-19
変更 9-89, 9-93
パラメータ
ROWS_PER_JOIN_TASK
rbw.config ファイル エント
リ B-19
変更 9-89, 9-93
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
パラメータ
ROWS_PER_SCAN_TASK
rbw.config ファイル エント
リ B-19
変更 9-89, 9-93
パラメータ
ROWS_PER_TARGETJOIN_TAS
K
rbw.config ファイル エント
リ B-19
変更 9-89, 9-93
パラメータ SEGMENT
まとめ B-39
パラメータ SEGMENTS
rbw.config ファイル エント
リ B-28
使用方法 5-20
変更 9-90, 9-94
パラメータ SERVER
rbw.config ファイル エント
リ B-11
変更 9-87, 9-92
パラメータ SERVER_NAME
rbw.config ファイル エント
リ B-12
変更 9-88, 9-92
パラメータ SHMEM
rbw.config ファイル エント
リ B-11
変更 9-87
パラメータ
TARGETJOIN_LOCAL_PREDIC
ATES
変更 9-89, 9-93
パラメータ
TEMPORARY_DATA_SEGMEN
T
rbw.config ファイル エント
リ B-27
変更 9-89, 9-93
パラメータ
TEMPORARY_INDEX_SEGME
NT
rbw.config ファイル エント
リ B-28
変更 9-89, 9-93
パラメータ TMU_BUFFERS
rbw.config ファイル エント
リ B-19
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
変更 9-91, 9-94
パラメータ
TMU_COMMIT_RECORD_INTE
RVAL
rbw.config エントリ B-16
定期的なコミットの使用 6-5
変更 9-91, 9-94
パラメータ
TMU_COMMIT_TIME_INTERV
AL
rbw.config エントリ B-17
定期的なコミットの使用 6-5
変更 9-91, 9-94
パラメータ
TMU_CONVERSION_TASKS
rbw.config ファイル エント
リ B-24
変更 9-91, 9-94
パラメータ TMU_INDEX_TASKS
rbw.config エントリ B-25
変更 9-91, 9-94
パラメータ TMU_INPUT_TASKS
rbw.config エントリ B-25
変更 9-91, 9-94
パラメータ TMU_MAX_TASKS
rbw.config エントリ B-25
変更 9-91, 9-94
パラメータ TMU_MMAP_LIMIT
rbw.config エントリ B-25
変更 9-91, 9-94
パラメータ TMU_OPTIMIZE
rbw.config ファイル エント
リ B-22
変更 9-91, 9-94
パラメータ
TMU_ROW_MESSAGES
rbw.config エントリ B-24
変更 9-91, 9-94
パラメータ TMU_SERIAL_MODE
rbw.config エントリ B-24
変更 9-91, 9-94
パラメータ TMU_VERSIONING
rbw.config ファイル エント
リ B-16
RECOVER オプション 6-17
バージョニングの有効化 6-17
変更 9-91, 9-94
パラメータ TOTALQUERYPROCS
rbw.config ファイル エント
リ B-20
変更 9-87, 9-92
パラメータ
TRANSACTION_ISOLATION_L
EVEL
rbw.config ファイル エント
リ B-16
変更 9-90, 9-94
パラメータ TUNE
OPTICAL_AVAILABILITY 9-73
rbw.config のエントリ B-19
まとめ B-35
パラメータ UNIFIED_LOGON
rbw.config ファイル エント
リ B-12
変更 9-92
パラメータ
UNIFORM_PROBABILITY_FOR
_ADVISOR
rbw.config ファイル エント
リ B-15
変更 9-90, 9-93, 9-94
パラメータ
USE_INVALID_PRECOMPUTE
D_VIEWS
rbw.config ファイル エント
リ B-15
変更 9-90, 9-94
パラメータ VERSIONING
rbw.config ファイル エント
リ B-16
バージョニングの有効化 6-17
変更 9-90, 9-94
パラメータ XML_MAX_TASKS
rbw.config ファイル エント
リ B-23
変更 9-91, 9-94
パラメータ XML_TEMP_SPACE
rbw.config ファイル エント
リ B-22
変更 9-91, 9-94
ひ
光記憶装置のサポート 9-71 ∼ 9-73
光ディスク上のセグメント
インデックスの選択 9-74
索引
17
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
定義 9-72
低い選択性
クエリ性能の向上 4-10
定義 4-11
ビュー
削除 9-104
作成のガイドライン 5-57
事前計算 2-14
説明 3-16
表記規則
構文ダイアグラム 7
構文の規則 6
マニュアル 5
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
「ファイル システムがいっぱいで
す」メッセージ 9-32
ファクト テーブル 3-7, 3-23
ファクトどうしのジョイン
STARjoin の規則 4-5
フィル ファクタ、VARCHAR
設定 5-24
変更 9-79
フィル ファクタ、インデックス
キー サイズへの影響 5-39
設定 5-36
説明 4-28
変更 5-39
フォーリン キー
追加と削除 9-78
定義 3-7
複数列 3-11, 4-15
復元操作
インデックス作成時 5-33
バージョン管理されたデータベー
ス 6-24
複数のデータベース、セグメント
のデフォルト ロケーショ
ン 5-13
復旧の手順 1-19
物理入出力統計値 8-7
プライベート マクロ 5-60
プライマリ キー、定義 3-7
プロセス
監視 9-96
定義 1-9
プロセス チェッカ デーモン 1-13
18 Administrator’s Guide
R
S
T
U
V W
X
Y
わ行
ブロック、8 キロバイト 9-33
へ
並列インデックス 5-35
並列クエリ処理
PSU 数 4-18, 4-56
並列処理
概要 2-5
変換されるテキスト 2-31
変数、構文ダイアグラム 9
ま
ふ
Q
マクロ
EXPAND 文 5-61
削除 9-102
作成と使用 5-59
参照の解決 5-60
説明 1-17
範囲 5-60
例 5-61
マニュアル
IBM Red Brick Warehouse のリス
ト 11
オンライン 13
マルチスター スキーマ 3-13
マルチバイトの文字セット 2-28
む
も
文字セット 2-29
ゆ
有効期限、パスワード 7-27
ユーザ
データベースへの追加 7-5
パスワードの変更 7-6
ユーザ、redbrick 1-15, 2-15, 2-36
ユーザ アカウント
RISQL エントリ ツール 7-3
期限切れ 7-28
新規ユーザの追加 7-4 ∼ 7-6
ロック 7-36
ユーザ アクセス、設定 1-17
ユーザ作成のロール
管理 7-11 ∼ 7-25
削除 9-102
作成 7-15
直接のメンバーと間接的なメン
バー 7-11
取り消し 7-21
付与 7-18 ∼ 7-21
ユーザ優先順位、変更 8-12
ユーティリティ プログラム
dbsize 4-26
findserver 9-97
rb_cm 8-3
コピー管理 8-3
無効な STAR インデックス 4-59
り
め
メッセージ
内部、変換されない 2-35
ファイル 2-35
変換された 2-35
メッセージ テンプレート 8-17
メモリの使用
ロードおよびインデックスの所要
量 4-43 ∼ 4-56
メモリ不足エラー 4-48, 5-34
メンバー、ロール 7-11
リストリクト デリート 2-40
リスナ スレッド 1-14
リソース アクセス権、ODBC 7-5
領域不足エラー 4-49
リングィスティック方式の文字比
較 2-29
れ
レキシカル方式の文字比較 2-29
列
削除 9-76
追加 9-76
Z
記号
数字
A
B C
あ行
か行
さ行
D
た行
E
F
な行
データ型の変更 9-78
デフォルト値、変更 9-76
名前の変更 9-76
幅の見積り 4-26
ろ
ロード ウィンドウ 6-4
ロール
削除 9-102
システム 7-7
システム テーブル情報 7-23
直接のメンバーと間接的なメン
バー 7-11
取り消し 7-8, 7-21
付与 7-8, 7-18 ∼ 7-21
メンバー 7-18 ∼ 7-21
ユーザ作成 7-11 ∼ 7-25
ロールに基づくセキュリティ 7-11
ロールの間接的なメンバー
使用方法 7-18
定義 7-11
例 7-20, 7-24
ログイン名、パスワード 7-32
ログ ビューア
使用方法 8-19
シンタックス 8-18
ログ ファイル
Advisor 8-30
UNIX でのタイプ 9-98
Windows でのタイプ 9-100
切り替え 8-28
サイズ指定 8-26
削除 8-24
命名規則 8-24, 8-30
ロケーションの指定 8-25
ロケール
インストール時の定義 2-30
オーバーライド、サーバ 2-31
クライアント / サーバ環境 2-31
クライアント ツール 2-32
言語の要素 2-27
コード セットの要素 2-28
システム テーブル参照 2-30
ソートの要素 2-29
データベースに対して別のロケー
ルを指定 5-5
デフォルト 2-30, 2-33
G
H
は行
I
J
ま行
K
L
や行
M
N O
ら行
P
Q
R
S
T
U
V W
X
Y
Z
わ行
テリトリの要素 2-28
要素 2-27
ロック
READ オプション 9-6
WRITE オプション 9-6
待機動作、変更 9-10
テーブルとデータベースをロック
する時期 9-6, 9-13
テーブル ロックの種類 9-7
ロックされたユーザ アカウン
ト 7-36
ロック時の NO WAIT 9-10
ロック時の WAIT/NO WAIT 9-10
論理入出力統計値 8-7
わ
ワークロード アカウンティン
グ 8-34
索引
19