簡単！DB2の設計: 2．データベース、表スペース、表の作成

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 初級

平 孝, ISE、インフォーメーション・マネージメント, IBM

2009年 03月 05日

この記事では、データベース、表スペース、表を作成する際に、どのような選択肢がありそれぞれどのような特徴があるのかを説明していきます。

はじめに

DBサーバーを構築する際には、インスタンス作成後にデータベース作成、表スペース作成、表の作成という流れがありますが、それぞれの作業においていくつかの選択肢があります。
ここではどのような選択肢があり、どのような考慮点があるのかを説明し、「最低限このポイントだけは押さえておきましょう！」という点を中心にご紹介します。

各作業において以下のような項目を検討していく必要があります。

• データベース作成：自動ストレージを使用するか？コードページは？ソート時の文字の順序は？デフォルトのパラメータは？
• 表スペース作成：表スペースの数は？表スペースタイプは？ページサイズは？
• 表作成：効率的にアクセス、管理するための表とは？

各選択肢を選ぶ際には、それぞれの特徴や制約をある程度理解する必要がありますので、ここからは各選択肢について説明していきます。

上に戻る

データベースの分割

前回、ご紹介したようにインスタンス内には複数のデータベースが作成できます。
データベースを複数に分けるメリットには、

• バックアップ／リストアの単位を分ける
• 各種ヒープなどを別々に管理する
• データベース作成時に指定するコードページやソート順を分ける

などが挙げられます。

デメリットとしては、

• 複数のDB間で1つのUOW内で処理したい場合には、2フェーズコミットが必要
• オブジェクト、管理対象が多くなることで運用、設計が煩雑

などが挙げられます。
管理対象を分けるという目的でデータベースを分割する場合には、インスタンスから分割した方がDBの再起動、Fixpackレベルも複数レベル保持することができるため、1つのインスタンスに1つのデータベースという構成が一般的です。

上に戻る

データベース作成時の自動ストレージ

この自動ストレージは、V8.2.2から提供されている機能で、データベース作成時にストレージパスを指定するだけで、その後の表スペースのタイプ（SMS、DMS）やコンテナーはDB2が自動的に決定してくれます。
V9.1からはデフォルトで自動ストレージ・データベースとなります。

　CREATE DATABASE DB名 ON PATH　

ただし、V9.1からは指定しなくても自動ストレージ・データベースとなります。
このPATHは複数の指定が可能です。

データベース作成時にのみ指定可能なオプションです。DB用の大きなJFSを用意して、そこを指定してデータベースを作成してみましょう。
ストレージの効率性や可用性などを詳細に決める必要がある場合、表スペースコンテナーとしてRawデバイスを指定したい場合、後々表スペースのサイズを調整していきたい場合は、自動ストレージを使用しないでください。

上に戻る

データベース作成時の構成アドバイザー

V9.1より、データベース作成時に、システムリソース（メモリー、CPUなど）を考慮し、データベース構成パラメータ、バッファプールをデフォルトで自動設定してくれます。
V9.5では、この機能がデフォルトで起動するようになりました。
より適切なパラメータの設定のためには、ベンチマークを実施して調整する必要がありますが、最初の値としてこの機能を利用することができます。

　CREATE DATABASE DB名 AUTOCONFIGURE USING MEM_PERCENT 60　

ただし、V9.5では指定しなくても自動的に起動されます。

USING以下に指定可能なキーワードには、上記のメモリーのパーセンテージ以外にも、ワークロードタイプ、トランザクション規模、接続数などがあります。
AUTOCONFIGUREコマンドを使用すれば、データベース作成後に推奨パラメータを設定することができます。

上に戻る

データベースのコードページ

データベースを作成する前に決めておかなければいけない項目に、コードページがあります。
これらはデータベース作成時のみに指定可能であり、後で変更する場合には、データベースを再作成する必要があるため、変更がないようにしましょう。

データベース・コードページとは、データベースに格納される文字列の文字コードのことです。これはデータの格納形式を決めるもので、データベースを作成した後で変更することはできません。
DB2では1インスタンスにつき、インスタンスユーザを決める必要があります。
デフォルトではインスタンスユーザのロケールと同じ設定がされます。
AIX、Windows、HPでは、一般的にはSJISで、Linux、Sunでは、一般的にはEUCになると思われます。

選択可能なコードページには以下があります。

• S-JIS
• EUC
• Unicode

　CREATE DATABASE DB名 ・・・・ USING CODESET UTF-8 TERRITORY JP　

V9.5より、デフォルトのコードページはUnicode（UTF-8）となりました。

上に戻る

データベースのソート順

日本語の50音順でソートしたい、という照合要件があるならば、こちらもデータベースを作成するタイミングで指定する必要があります。間違った照合順序でデータベースを作成してしまうと、50音順でデータを参照できなくなりますので注意が必要です。
CHAR、VARCHAR といった文字列の照合順序はデータベース作成時の設定によって決まります。SQL 比較、ORDER BY 文節、索引や統計の設定すべてにおいて、この照合順序が使用されます。データベース・コードページには依存しません。

設定は主に3種類となります。

• SYSTEM

デフォルトの設定です。この照合順序ではアルファベットのみが正しく重み付けされるため、日本語のひらがなやカタカナは50音順にはソートされません。シングルバイトのみを使用する環境で有効な設定です。

• COMPATIBILITY

DB2 バージョン2の設定です。ほとんどの場合、こちらを使用する要件はありません。

• IDENTITY

バイト単位で照合を行う設定のため、ひらがなやカタカナが正しくソートされます。また、シングルバイトも正しくソート可能です。

よって、日本語を扱うデータベースを構築する場合は、identityを明示的に指定することをお奨めします。

表示例）

SYSTEM

[半角英字]
aAbBcC ～ xXyYzZ
[ひらかな1] 
 ぃいぅうぇえぉおかがきぎ ～ さざしじ ～ ただちぢっつづ ～ なにぬねのはばぱひびぴ ～ まみむめ
    ぁあもゃやゅゆょよらりるれろわをん

IDENTITY

[半角英字]
    ABCD ～ WXYZabcd ～ wxyz 
[ひらかな]
    ぁあぃいぅうぇえぉおかがきぎ ～ ただちぢっつづてでとどなにぬねのはばぱひびぴ ～ まみむめもゃやゅゆょよらりるれろわをん 

COMPATIBIITY

[半角英字]
    AaBbCc ～ XxYyZz
[ひらかな1] 
    あぃいぅうぇぉおかがきぎ ～ さざしじ ～ ただちぢっつづ ～    なにぬねのはばぱひびぴ ～ まえみむめ
  ぁもゃやゅゆょよらりるれろわをん

上に戻る

表スペースの種類

表スペースは、表データや索引の置き場所となる論理的なスペースです。
実際にデータを保存する場所はコンテナーという場所で、表スペースは1つ、もしくは複数のコンテナーから構成されています。

表スペースには大きく2種類あります。システムに管理させるもの、データベースに管理させるものです。
システムに管理させるSMSについては、定義するときにコンテナーとなる記録先のディレクトリーを指定します。そのファイル・システムの容量が表スペースの容量となり、ファイル・システム拡張が表スペースの拡張となります。

データベースに管理させるDMSについては、コンテナーにファイル、もしくはRAWデバイスの選択肢があります。
SMSの管理はシステムに任せているので、管理は楽ですが、DMSに比べるとパフォーマンスはあまりよくありません。
DMSのファイルとRAWデバイスについては、表スペース作成時に「NO FILESYSTEM CACHING」が指摘できるようになり、パフォーマンスの差はなくなったといって良いかと思います。

一時表スペースは、表の再作成が頻繁に発生する可能性があります。
また、サイズも小さなものが多い傾向があります。
一時表スペースはSMSを選択するようにしましょう。
それ以外のカタログ表スペース、ユーザー表スペース、索引表スペースはDMSを選択するようにしましょう。

特性	SMS	DMS
表スペース内のコンテナーの数を動的に増やしたり減らしたりできる
テーブルのデータとインデックスのデータを別個の表スペースに保管できる
テーブルのLOBデータを別個の表スペースに保管できる
スペースは必要なときにだけに割り当てられる
表スペースを複数の異なるディスクに配置できる

上に戻る

表スペースのページサイズ

表スペースを作成する際には、ページサイズを指定する必要があります。
指定したページサイズが、表、索引の記憶域のブロックとなり、基本的に、DB2はここで指定した単位がバッファプールのI/O単位となります。

ページサイズ毎に、各種制約が異なってきますので、レコード長、表のサイズなどを調査してページサイズを決定しましょう。
DB2 V9.1より、LARGE表スペースを選択できるようになりました。このLARGE表スペースに関しては、ページサイズの各種制約が大きく緩和されています。

これら制約を考慮してページサイズを選択していくのですが、何種類ものページサイズを用意すると、対応したバッファプールや一時表スペースも用意することとなり、設計、運用が煩雑になるため、ページサイズはどれか1種類に決めるようにしましょう。
行長の問題さえクリアできれば、8KBのページサイズを推奨します。
DB2 V8までは、8KBのページサイズだと、作成できる表スペースの最大は128GBであり、大規模な環境ではこの制約に違反するケースもありましたが、V9以降ではこの制約が緩和され、8KBのページサイズだと、4TBの表スペースまで作成することができるようになりました。

上に戻る

表の種類

表を作成する際には、以下の選択肢を検討することでより効率的にデータの管理が可能となることがあります。

• マテリアライズ照会表（MQT)
• 多次元クラスタリング（MDC)
• パーティション表

よりパフォーマンス、可用性を高めることを検討する場合には、これらの選択肢を検討しましょう。
ただし、MQTやMDCが本当に効果的なのかどうかを判断するのは難しい場面もあります。そんなときは設計アドバイザーを使用してみてください。SQLステートメントの情報をもとに設計アドバイザーが適切なMQT、MDC、索引などに関して推奨してくれます。
また、作成済みのMQT、MDC、索引についても評価してくれます。

上に戻る

マテリアライズ照会表（MQT）

同じような集計処理などを行う場合は、あらかじめその結果のテーブルを作っておく、というものです。
MQTを作っておけば、オプティマイザーがそのMQTの情報を利用した方が効果的と判断した場合、自動で使用してくれるため、アプリケーションからはこの表の存在を意識する必要はありません。オプティマイザーがMQTを選択した場合には、高速に結果を返すことができます。

基テーブルからMQTへのデータの反映方法には2種類あり、即時反映（IMMEDIATE）か遅延反映（DEFERRED）か選ぶ必要があります。

即時反映はその名のとおり、基テーブルが反映されたと同時にMQTへも反映されますが、遅延反映は明示的に反映するコマンド（refreshコマンド）を実行しないと反映されません。遅延反映の場合、オプティマイザーがMQTを使用した方が効果的と判断した場合は、古いデータをアクセスしてしまいますので、即時にするか遅延にするかはデータの鮮度と、データ反映時の負荷が他へ影響するかどうかを考慮にいれて検討する必要があります。

上に戻る

多次元クラスタリング（MDC）

MDCとはMultidimensional Clusteringの略です。
複数の属性の値でデータを分類し、自動的に格納する機能です。同じ属性のデータは同じ領域に格納されるため、検索性能の向上か見込まれます。また、同じ属性のデータを高速に削除することもできます。
大規模テーブルで、列の値のユニーク性が低く、かつその列の値によってデータが均等に分散される場合に、有効になります。
通常のインデックスはレコード単位で検索をしにいく一方、MDCはブロック単位で検索にいくため、検索の階層が少なくなり、パフォーマンスが向上するというメリットもあります。

上に戻る

パーティション表

パーティション表はひとつの表を複数の区分に分割し、区分単位でのアクセス性能向上が見込めます。
また、古い区画を高速にロールアウト（区分のデタッチ）し、別の履歴表などにロールイン（区分のアタッチ）したりすることもできます。
UNION ALL Viewで、月単位の明細表を管理されていた方ならば、パーティション表のイメージも沸きやすいのではないでしょうか？

上に戻る

おわりに

この文書では、DBサーバーを構築する際に必要な、データベース、表スペース、表に関して、どのような選択肢があり、どのような考慮点があるかを中心に見てきました。
パーティション表、MDC表などの詳細な内容に関しては、別途参考資料などを参照してください。パフォーマンス、可用性などをより向上させるためには、提供されている様々な機能を利用することで回避できるはずです。

参考文献

• DB2 V9 デザイン・ガイド：データベース物理設計
  
  
• DB2 9.5対応！プレ匠塾・DB2管理者ここが重要！実践ノウハウ講座
  
  
• Best practices for DB2 for Linux, UNIX, and Windows (US)
  
  
• (オンライン・マニュアル)DB2 Information Center
  

著者について

		平 孝はDB2バージョン2の時代からに14年間DB2を専門として担当してきました。主に並列データベースであるDPFを担当し、性能関連の問題判別を中心にトラブルサポートを実施してきました。現在は日本アイ・ビー・エム　システムズ・エンジニアリングに所属し、先進のプロジェクトサポート、障害時の緊急サポート、最新バージョンのワークショップ開催などの仕事に従事しています。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る