レベル: 初級 平 孝 (tairat@jp.ibm.com), ISE、インフォーメーション・マネージメント, IBM
2009年 3月 05日 この記事では、データベースサーバーを構築する際、DB2としてはどのようなオブジェクトを作成し、どの程度の容量を見積もればいいのかという観点から説明していきます。
はじめに
DBサーバーを構築する際には、どのような作業が必要でしょうか？
表の論理設計、物理設計、運用設計、セキュリティー、監視、性能・・・と多くの決めなければならない項目がありますが、ここでは物理設計の部分において、「最低限このポイントだけは押さえておきましょう！」という点を中心にご紹介します。
物理設計においては以下のような項目を検討していく必要があります。
- ディスク容量見積もり ： どの程度のディスク容量が必要か？
- オブジェクト作成 ： DB、表スペース、表はどのように作成すべきか？
- ディスク計画 ： 各オブジェクトをどのように配置すべきか？
- パラメータ設計 ： どのパラメータをチューニングすべきか？
ここからは、データベースにはどのようなDB2オブジェクトが存在するのかという観点でもご紹介した後に、「ディスク容量の見積もり」に関して、大体の目安となる値を紹介します。これらの値はあくまでも参考値であり、データ属性、業務の処理内容、運用方法、規模によって変動していきます。
データベースを構成するオブジェクト
データベースオブジェクトとは、表スペース、表、視点、索引、パッケージ、ログ、ロックなど、DB2の構成要素を表します。
ここでは、物理設計の際に意識すべきオブジェクトを中心に、データベースと各オブジェクトの関係を説明していきます。
図1. データベースを構成するオブジェクト
インスタンス
データを管理するデータベース・マネージャー（DB2のエンジン）であり、起動／停止の単位でもあります。同一サーバー上に複数構成することができます。インスタンスの中に、パーティション、データベース、表スペース、表などのすべてのオブジェクトが含まれます。
パーティション
DB2では、複数のパーティションからなる並列データベースをサポートしています。（Database Partitioning Feature）表に格納されるデータを各パーティションに分散させ、検索時に各パーティションで並列にアクセスするといった大規模データベースに適している構成です。パーティション間のデータの送受信などはDB2が内部的に管理しているため、アプリケーションからはデータの分散などは意識する必要がありません。図1では単一のパーティションの構成を例としています。
データベース
接続（CONNECT）の対象であり、バックアップ／リストアの単位ともなります。インスタンス内に複数のデータベースを作成することが可能です。
表スペース
一つ、もしくは複数の表を格納するためのスペースです。表スペースに紐付けられたコンテナーにより、表や索引を物理ディスク上にどのように配置するかを決めることができます。バックアップ／リストアの単位ともなります。管理タイプにより、2種類（SMS、DMS）、格納するデータ内容により3種類（REGULAR、LARGE、TEMPORARY）に分けられます。
図2. 表スペース、コンテナーの概略図
表、索引
表は列と行からなるデータであり、CREATE TABLEステートメントにより作成できます。その際に、どの表スペースにデータを格納するか指定することができます。
索引はキーの値によって並べられたポインターの集合であり、表データのアクセスを速くし、データのユニーク性を保証することもできます。（ユニーク索引）CREATE TABLEステートメントにより、索引が格納される表スペースをデータと別の表スペースとして指定することができます。
データと索引のバッファープールを分けるためには、別の表スペースを指定する必要があるため、データと索引は別表スペースとしておくことを推奨します。
バッファープール
表および索引のデータがディスクから読み取られるときにそれらをキャッシュに入れるためにデータベース・マネージャーによって割り振られるメイン・メモリーの領域です。
データベースごとに、IBMDEFAULTBP というデフォルトの定義済みのバッファープールが作成されます。追加のバッファープールを CREATE BUFFERPOOL、DROP BUFFERPOOL、および ALTER BUFFERPOOL ステートメントを使用して、作成、ドロップ、および変更することができます。
表スペースを作成する際には、同じページサイズのバッファープールが存在していなければなりません。また、複数の表スペースで共用することが可能です。そのため索引専用のバッファープールと、それ以外用のバッファープールなど用意することができます。
メモリーを効率的に利用するためには、さまざまなページサイズの表スペースを作成せず、バッファープールを乱立させない設計が推奨されます。
小さなデータを読み出すときは、エージェントプロセスが直接表スペースからバッファープールにデータを読み出しますが、連続した領域が必要となる場合には、プリフェッチャーが先読みをします。更新されたページは、ページクリーナーが非同期で表スペースへ書き出します。ただし、LOBに関してはバッファープールを経由せずに、Direct Read／Writeの処理となります。
図3. 表スペースとバッファープール間のデータの流れ
アクティブログ、アーカイブログ
データベースに対する挿入、更新、削除などの更新処理や、各種オブジェクトの作成、削除、変更などの処理は、アクティブログに保管されます。
電源障害などによりDB2が強制停止しても、このログファイルにより整合性が保たれます。また、バックアップからの回復処理の際に、このアーカイブログファイルを使用することで直前のトランザクションまで回復することが可能となっています。
DB2では、循環ロギングとアーカイブ・ロギングという2種類のロギングを使用できます。
アーカイブ・ロギングを選択した場合には、オンラインでのバックアップと、バックアップからの回復処理の際に、アーカイブログを使用して直前のトランザクションまで回復することが可能となります。
ディスク容量見積もり
DBサーバーに必要なディスク容量を詳細に見積もるためには、多くの情報が必要であり、そこからディスク容量を見積もる作業も小さくはありません。そこでよく使われている大体の目安に以下の指標があります。
ここで、生データとはデータロードの際に使用するようなフラットファイルの大きさを利用します。このサイズを基礎数値として約4倍のディスク容量をDBが使用する領域として確保しましょう。
この内訳は図4のようになります。
図4. ディスク内容の内訳
簡単に各項目の説明をします。
データ
データロードに使用するようなフラットファイルです。「生データ」と呼ぶこともあります。表の列に文字属性（Charなど）が多い場合には、この生データがそのまま表のデータサイズに近づきますが、数値属性（Integerなど）が多い場合にはフラット・ファイルとDB格納後の容量の差が大きくなる可能性があります。
オーバーヘッド
表を作成し、データを格納する際のオーバーヘッドです。各行に対してオーバーヘッドが発生しますし、ページに格納する際の余剰や、DB2の管理情報などのオーバーヘッドがあります。
索引
表を効率的にアクセスするためには索引が必要であり、一般的には表に対して2～5本の索引が推奨されています。この索引本数や、表の列の数などによってデータに対する索引サイズの比率は変動します。
表や索引の詳細が決まっていない段階では、まずは生データと同等サイズのスペースを確保することを検討しましょう。
テンポラリー
ここに含まれるのは主に2つあります。
1つはDBオブジェクトである一時表スペースです。大きなソートや大きな表の絞り込みの少ないJoinを実行する場合には、一時表スペースも多く使用されます。また、表のオフライン再編成時には、元表の3倍程度の一時領域を使用することもあり、最も大きな表の3倍以上の一時表スペースは確保したいところです。
もう1つはDBオブジェクトではなく、JFS領域です。他のシステムよりデータベースに格納するデータをファイルで受信し、Loadユーティリティーなどを使用してデータを格納することもあるでしょう。Load前にそれらのファイルをソートすることもあるかもしれません。この作業領域としてのJFSもテンポラリーに含めています。
ログ
DB2に対する更新内容を保存するアクティブログと、アーカイブログを保存する領域です。アクティブログのサイズは、一度に更新する量と、同時トランザクション量によってサイズが変動します。アーカイブログはバックアップの間隔や保存世代数によってサイズが変動します。
システム
DB2のカタログ表や、各表スペースの余裕率などを含んでいます。
当初はユーザー表や索引もないために、最小限のサイズとなっています。
表、索引を作成し、Runstatsを実施することで増加していく領域です。
各表スペースの余裕率
各表スペースの使用率は60％程度に納まるようにしましょう。
その他には、ミラーリングの領域、バックアップイメージをディスクに保存する場合にはその領域、FlashCopyする場合の領域などを別途考慮する必要があります。
おわりに
この文書では、DB2の各種オブジェクトの概要と、DBサーバーとして、どの程度のディスク容量が必要なのかという観点から大体の目安となる指標をご紹介しました。さらに詳細にディスク容量を見積もる際には、表、索引などのより詳細な見積もり式が提供されていますので、表や索引のレイアウトが決まって、見積もり件数の情報も固まってきた段階であれば、より正確にディスク容量を見積もることができます。
必要な場合には参考資料などを参照してください。
参考文献
著者について  | | | 平 孝はDB2バージョン2の時代からに14年間DB2を専門として担当してきました。主に並列データベースであるDPFを担当し、性能関連の問題判別を中心にトラブルサポートを実施してきました。現在は日本アイ・ビー・エム システムズ・エンジニアリングに所属し、先進のプロジェクトサポート、障害時の緊急サポート、最新バージョンのワークショップ開催などの仕事に従事しています。 |
記事の評価
| 
