レベル: 中級 Editorial staff, developerWorks, IBM
2008年 10月 18日 本資料は、DB2のデータベースを設計の主に物理設計を実施することを目的に、設計に必要となる項目や設計のポイントについてご紹介しています。
データベース設計を始める前に
ここでは、データベース設計を始めるにあたって必要となる前提および、設計に必要な材料について説明します。
前提
表の論理設計が終了していること
データベースの設計は大きく分けて論理設計と物理設計に分けられますが、物理設計作業の前提として、論理設計が完了していることがあげられます。論理設計では、業務で使われているマスターや注文などのデータを行と列からなるリレーショナルモデルで表し、冗長なデータをなくしたりするための正規化を実施し、テーブル間の関係を定義するところまでを実施します。つまり、データベースに格納したい表や、その列のデータ型、長さなどが決まっている状態です。
物理設計作業は、表の論理設計で決められた表を、DB2のデータベースの表として定義してゆきます。物理記憶域のどこにどのように表スペースや表、索引といった各オブジェクトを配置するかのマッピングを行ないます。
データベースのコードセットおよび照合順序が決まっていること
データベースのコードセットおよび照合順所は、データベース作成時にしか指定できず、後から変更することができません。要件に基づいて事前に決定しておくことが必要です。
必要な材料を確認しよう
業務要件
物理設計では、論理設計で決められた論理設計書が要件定義のインプットとなります。表やデータタイプに関する情報は論理設計書を使用してください。
また要件に応じて下記項目を事前に決定する必要があります。
データベースのコードページ
データベースのコードページとは、そのデータベース内で扱う文字セットの各文字をそれぞれユニークなコードポイントに関連づけたものです。コードポイントとは文字を16進で表現したものになります。例えば、日本語を扱えるコードページには、IBM-943とUTF-8などがありますが、同じ“あ”という文字でもそれぞれのコードページで表現する16進数のコードポイントは異なります。
コードページを決定するには、格納したい文字データがそのコードページで表現できるかどうか、既存のデータベースやアプリケーションとの連携上、互換性のあるコードページであるかなどさまざまな条件を基に考慮する必要があります。例えば、IBM-943のコードページは日本語用のコードページですので、データベースに韓国語などの多国籍語の文字を格納したいという要件がある場合、UTF-8を選択しなければならないでしょう。
なお、コードでデータベースのコードページはCREATE DATABASE時にCODESETで指定し、データベース作成後は変更することはできません。
データベースの照合順序
データベースの照合順序とは、文字の比較や並べ替えを行う時のルールとなるものです。データベース・マネージャーはこのルールに基づいて文字を比較します。DB2の照合順序にはさまざまなものがありますが、よく使用されるものとしてはIDENTITYとSYSTEMがあります。2つの照合順序で文字列をソートした例を図1に示します。照合順序の違いによってアルファベットや平仮名、カタカナの並び順が異なるのがわかると思います。
なお、データベースの照合順序はCREATE DATABASE時にCOLLATEで指定し、データベース作成後は変更することはできません。
図1. 照合順序の比較
このようにデータベースのコードセットおよび照合順序はデータベースの動作に影響を与えます。また、コードセットの種類によって文字列の長さが変わるため、データの見積もりに影響を与えますので事前に決定しておく必要があります。データベース作成時のデフォルトコードセットはV9.1とV9.5で異なりますので注意して設定してください。
データの見積もり
物理設計でデータベース内のオブジェクトを見積もる際には、論理設計で決定した表の定義とともに、お客様から業務データ量についての情報を得ることが必要です。ここで言う業務データ量とは、必ずしも各表に対応するデータ量を指すわけではなく、業務の中で扱われる顧客数、コード類、1日のトランザクション数、データの保持期間などがインプットになる場合もあります。これらの情報から物理設計を行う中で各表のレコード数の見積もりを行うこともあります。
非機能要件
データベース物理設計目標は、格納すべきデータを物理的に格納することですが、それ以外の要件も満たすことが求められるケースもあります。それぞれのシステムの性能や運用の要件を満たすために最適な実装を行うことが必要になります。例えば、ロギングはオフラインバックアップと循環方式で要件を満たせるか、それともアーカイブロギング方式が必要かというような運用の要件があると考えられます。他にも、ユーザーがデータベースを定期的に監視したり変更を加えたりすることが難しいようなケースでは、管理が容易な表スペースや構成を採用するなどです。これらの非機能要件はデータベース管理や運用要件、性能要件がインプットになってきます。
データベース設計
データベース設計のステップ
ここから、データベースの物理設計を下記に示すステップに沿って、説明してゆきます。項目ごとに設計方法や目安とともにポイントを記載しています。
- 業務要件の整理
1.1 インスタンスの構成とデータベース分割
1.2 OS関連
- データの見積もり
2.1 データ容量の見積もり
2.2 表の分類と表スペース、バッファープールの構成
2.3 表スペース容量の見積もり
2.4 ディスク上へのオブジェクトの配置方法
- 非機能要件の整理と設計
3.1 ロギング方式の決定
3.2 自動管理機能
- 物理設計書に含まれるもの
1. 業務要件の整理と設計
データベースの設計を始める前に、業務の種類や要件について整理しておきましょう。
まず物理設計の対象となっているシステムの業務はどういった種類のものでしょうか。一般的にデータベースシステムを大別すると、OLTP（OnLine Transaction Processing）と呼ばれるタイプと、DSS（Decision Support System）と呼ばれるタイプに分類できます。OLTPシステムでは、比較的単純な参照・更新のSQLが多数並列的に実行されるようなタイプが多く、商品の注文処理などはこれにあたります。このシステムでは、レスポンスタイムの性能やより多くのトランザクション・レートを実行できることが求められると思います。一方DSSシステムでは、比較的複雑なSQLで大量のデータに対して分析を行うようなケースが多く見られます。このような業務のタイプや使われ方に応じた物理設計を心がけることが大事です。
1.1 インスタンスの構成とデータベース分割
ここではインスタンスとデータベースの分割について解説します。
インスタンスはDB2のデータベースを構成する最も大きな要素であり、データベースを管理するデータベース・マネージャーとよばれる単位になります。このインスタンスの中にデータベースを作成します。
インスタンスは、ひとつのOSに複数作成することができ、データベースは1つのインスタンス中に複数作成することが可能ですが、基本は１インスタンス１データベースを検討してください。その上で、以下のような要件があれば分割を検討します。
【インスタンス分割検討の目安】
- 運用時間が異なる業務でインスタンスの起動停止を行いたいかどうか
業務ごとにデータベースの運用時間帯が異なり、インスタンスの停止を必要とするような場合は分割を検討します。なお、サービス停止時は、一般的にインスタンスそのものを停止するのではなく、アプリケーションやネットワークの運用でサービスを停止します。
- 業務ごとにデータベース・マネージャーの構成を変更したいかどうか
データベース・マネージャーのパラメータ等はインスタンスごとに設定しますので、その要件が大きく異なるような業務が複数ある場合は分割を検討します。
【データベース分割検討の目安】
データベース分割を検討する際には、まず1つのデータベースで業務要件、運用要件、性能要件が満たせるかを検討し、不可能な場合分割を検討します。最初に整合点の必要性とアプリケーションの処理内容をおさえておきましょう。データベースをひとつにまとめるか、分割するかの指針は以下となります。
データベースをひとつにまとめるケース
- 業務要件からで整合点が必要な場合
データの整合点を保障できる単位はデータベースになります。よって複数の表の間で必ずデータ上の整合点を保持したい場合には1つのデータベースにまとめる必要があります。
- アプリケーションから同時にアクセスしたい場合
同じアプリケーションから同時にアクセスする表郡は1つのデータベースにまとめましょう。アプリケーションが特定の業務処理を行うために単一のデータベースに接続して、処理を行うためです。実際には２フェーズ・コミット機能やフェデレーション機能を使用してデータベースをまたがって処理を行うことも可能ですが、一般的には同時に処理すべきデータは1つのデータベースにまとめます。
データベースを分割するケース
- 分割が必要な業務要件がある場合
アプリケーションや用途に応じてデータベースを分けたい場合や、セキュリティー上、DBを分けておきたい場合には分割を検討します。
- 運用、パフォーマンス要件から分割したい場合
アプリケーション毎にバックアップなど運用方法を変えたい場合やデータベース単位でリソースを確実に確保したい場合は分割を検討します。例えば、データベースのサイズが大きすぎて運用のメンテナンスウィンドウに収まらない場合や、アプリケーションを1つのデータベースに集約させると負荷が高すぎる場合などです。
*ポイント
基本は1インスタンス1データベースとし、要件に応じて分割を検討する
1.2 OS関連
データベースを作成する際に、必要なOS側の設定がありますので確認が必要です。
- データベースのインスタンスユーザー
- アプリケーションからデータをアクセスするためのユーザー
- データベース・マネージャーが使用するポート番号
- （オプション）FENCEDのUDF等を実行するための分離ユーザー
- （UNIXではオプション）DB2 Administration Server用のユーザー
各ユーザーの詳細についてはリンクのマニュアルをご参照ください。
「DB2 のユーザーとグループ (Linux および UNIX)」
2．データの見積もりと設計
ここでは、データ容量を見積もり、具体的にデータを格納する表スペースを設計し、ディスクに配置するまでの流れと方法を解説します。
2.1 データ容量の見積もり
表スペースやバッファープールの設計に入る前に、論理設計で定義された各表にどれだけのデータが格納されるのかを見積もっておきましょう。もし論理設計のフェーズで見積もられていない場合は、お客様の現時点での取り扱いデータ量（例えば顧客数や商品数など）、データを表に格納しておく保持期間、データの増加見込みと何年先までのデータを格納できることを要件とするかなどをヒアリングし見積もる必要があります。
表スペースごとに実際に必要となるディスク容量は「2.3表スペースの見積り」でご紹介しますが、事前に表ごとの容量を見積もることで、表スペースへの表の分類の際に役立ちます。
データ容量の見積もりは以下の手順で実施します。
- 各表の1行あたりのサイズを見積もる
- 各表の行数を見積もる
- 行サイズ×行数で表の1表ごとのデータ量を出す
- 索引容量の見積もりを出す
1. 各表の1行あたりのサイズを見積もる
論理設計で決定した表の定義を基に、各表の1行あたりのサイズを見積もります。この時、以下の点に注意してください。
- 可変長データ型（VARCHARなど）は平均のデータ長を算出し、可変長列ごとに4バイトを加算する
- NULL許可の列がある場合は列ごとに1バイトを加算する
2. 各表の行数を見積もる
各表の行を見積もるためには、トランザクション数や保持期間などの情報を予め取得しておきましょう。
以下にデータの保持期限を考慮した見積もり例を示します。
例：
・ 1日に発生するトランザクション数＝10,000件
・ トランザクション表には1週間保持し、履歴表にデータを移動する
・ 履歴表には2年分のデータを保存する
トランザクション表のデータ量 = 10,000×7（日）= 70,000件
履歴表のデータ量 = 10,000×365（日）×2（年）= 25,550,000件
|
ここで見積もりをする際には、必ずお客様から頂いた情報をもとにデータ見積もりを行い、見積もりはワークシートなどにまとめておくと変更があった際の再見積もりがしやすくなります。
3. 行サイズ×行数で表の1表ごとのデータ量を出す
1.および2.で見積もった行数と行のサイズから表のデータ容量を見積もります。以下の式を参考に、フラグメンテーションなどのオーバーヘッドを考慮して安全率を計算に加えてください。
表のデータ容量の計算式
（ ①平均行サイズ ＋ 10 ）× ②行数 × 安全率
※平均行サイズに加えている10バイトは固定値です。
|
4. 索引容量の見積もりを出す
ここでは索引容量の見積もり方法を紹介します。以下の式を参考に、索引に応じた平均索引サイズを計算し、索引容量を見積もってください。可変長列、NULL許可列のオーバーヘッドなどは表と同様に考えてください。
索引容量の計算式
・Regular表に作成する場合
（ 平均索引サイズ ＋ 9 ）× ②行数 × 安全率
・Large表に作成する場合
（ 平均索引サイズ ＋ 11 ）× ②行数 × 安全率
※平均索引サイズに加算しているオーバーヘッドは表のタイプやXML索引があるかどうかによって異なるため詳細はマニュアルを参考にしてください。
|
ただし、通常索引はパフォーマンスチューニングの過程で後から追加されてゆくため、各表の容量に応じて余裕を見ておいてください。一般的に、OLTPシステムでは多すぎる索引はパフォーマンスへの悪影響（更新処理に時間がかかる等）を及ぼす可能性があるので、最低限にとどめることが推奨されています。一方、DSS系では参照処理が多いため、たくさんの索引を作成し、索引容量がデータ容量より大きくなることもあります。
*ポイント
- 見積もり時には、可変長がある場合は平均長を見積もる
- オーバーヘッドや安全率に配慮して、余裕をもった見積もりを実施する
- 索引が後から追加されることも考慮する
2.2 表スペース、バッファープールの構成
ここでは、表スペースの種類やバッファープールについて理解し、表の表スペースへの配置についてご紹介します。
【表スペースとは】
表スペースは、データの物理的位置を指定するのに使用する論理的なオブジェクトです。表を作成する際には、必ず表スペース上に作成します。
表スペースは、データベースと実際の表データを保持するコンテナとの間にある層として使用され、表データが実際に物理的に格納されるのは表スペースに紐づけられたコンテナ（ファイルやディレクトリなど）になります。
図2のように表スペースは複数のコンテナで構成可能であり、コンテナのサイズを等しくすれば、データはコンテナ間で平均的に割り振られます。
図2. 表スペースとコンテナの割り振り
【バッファープールとは】
バッファープールとは、表の行や索引データが一時的に読み込まれたり変更したりする際に使用される記憶領域です。データの参照や変更をディスクから直接行うのではなく、バッファープール上で行うことでパフォーマンスが向上します。
表スペースはそれぞれ特定のひとつのバッファープールに関連付けるようにします。なお、表スペースとバッファープールのページサイズは一致している必要があります。
【表スペースの分割の目安】
表スペースの分割を検討する際の目安としては以下のようなことがあげられます。分割方法はさまざまな要因により何通りも考えられますが、分割の方針を明確にしておくことが重要です。
- パフォーマンス要件
表データと索引データは異なる表スペースに分ける方がパフォーマンスがよいため分割を検討します。また、一般的にはバッファープールは分割せずに大きなひとつのバッファープールを使用する方がお勧めですが、表を異なるバッファープールで処理させたいといった要件がある場合は、表を分類して別々の表スペースに分割します。例えば、マスター表やコード表など常に参照が行われてトランザクションが処理されるような表は、できる限りバッファープールに読み込ませるために専用のバッファープールを割り当てられることも考えます。表の更新頻度が明らかで、同時に処理される表のディスクI/Oを分散させたいような場合も分割を検討します。
- 運用要件
バックアップなどの運用要件から表スペース分割を検討することもあります。例えば、データベースサイズが大きくバックアップを表スペース単位で取得する場合に、業務ごとに表スペースを分けバックアップを表スペース単位で行うケースが考えられます。そうすることで、大量の更新がある表スペースは頻繁にバックアップを取得し、変更が非常に少ない表スペースはバックアップ間隔を大きくするなどの運用を実施することも可能です。
- ページサイズ
表スペースを作成する際には、4K、8K、16K、32Kのページサイズのいずれかを選択します。ページサイズによって、格納できる表の行サイズや行数、合計のデータ容量が異なりますので、表スペースを分割する際には、これらの制限事項を考慮する必要があります。
あまりに多くの表スペースに分割しすぎると、それぞれについての容量見積もり、容量監視が必要になる等、管理が煩雑になることも考慮しなければなりません。小さな表は1つの表スペースにまとめることも検討してください。
【表スペースの種類や属性の決定】
ここでは、表スペース作成のために決定しておく項目を整理し解説します。表スペース作成時に決定しておく必要がある項目としては以下の1.～7.にあげた項目があります。このうち1.～4.は一度表スペースを作成すると変更ができませんが、5.～7.はパフォーマンスやデータサイズ上必要があれば変更することも可能です。
- 保管データタイプによる表スペースの種別
- ページサイズ
- ファイル管理のタイプによる表スペースの種別
- エクステントサイズ
- プリフェッチサイズ（後からの変更可能）
- バッファープール（後からの変更可能）
- コンテナ数、コンテナサイズ（後からの変更可能）
個々の項目について解説していきます。
1. 保管データタイプによる表スペースの種別
表スペースを保管データタイプの観点で種類分けすると以下のタイプに分けられます。
- REGULARユーザー表スペース
- LARGEユーザー表スペース
- システム一時表スペース
- ユーザー一時表スペース
保管するデータがユーザーデータである場合、REGULARユーザー表スペースもしくはLARGEユーザー表スペースを使用します。REGULAR表スペースよりもLARGE表スペースの方が、ページサイズごとに格納できる行数、ページ数、容量が大きくなっていますので、将来データの増加が予測される場合はLARGEで作成するとよいでしょう。格納できる容量については2.のページサイズの項を参照してください。特にREGULAR、LARGEを指定せずに表スペースを作成した場合、V9.1以降ではLARGE表スペースがデフォルトで作成されます。
一時表スペースは一時的にデータが入る表スペースです。システム一時表スペースは、データベース内でソートや索引作成、再編成などを実行する際に一時的にデータが格納される領域になり、ユーザーがそこに表を作成することはありません。データベースを作成するとデフォルトの一時表スペースとしてTEMPSPACE1という4Kのページサイズのシステム一時表スペースが作成されますが、お使いのページサイズの種類に合わせて一時表スペースを作成してください。ユーザー一時表スペースは、宣言済みグローバル一時表という表を使用する場合に作成する表スペースです。アプリケーションの中でこの一時表を使用する要件がある場合には、ユーザー一時表スペースを作成します。
2. ページサイズ
データが表スペースのコンテナに格納されるとき、エクステントという単位で格納されてゆきます。そのエクステントを構成するのがページという単位であり、これがDB2で扱われるデータの最小単位となります（図3参照）。このページあたりのサイズを決めるのがページサイズであり、4KB、8KB、16KB、32KBの4つのサイズがあります。
図3. ページ、エクステント、コンテナの関係
ページサイズを決定する指針としては以下のようなものがあります。
- 表の行サイズがページサイズの行長の制限に収まるか
- その他のページサイズによる制限を超えていないか
- 格納効率の点で無駄なスペースを使っていないか
行のサイズなどの制限については、表1をご参照の上確認するようにしてください。格納効率についても考慮が必要です。REGULAR表スペースを使用した場合、行長の小さな表を大きすぎるページサイズの表スペースに格納すると1ページを使いきれず格納効率が悪くなることがありますので、不必要に大きなページサイズを指定しないよう注意してください。
表1. 表スペースに格納可能な容量
| ページサイズ | 行長（byte） | 列数 | REGULAR表スペース | LARGE表スペース |
|---|
| 表容量 | ページあたりの行数 | 表容量 | ページあたりの行数 |
|---|
| 4KB | 4005 | 500 | 64GB | 255 | 2TB | 287 | | 8KB | 8101 | 1012 | 128GB | 255 | 4TB | 580 | | 16KB | 16293 | 1012 | 256GB | 255 | 8TB | 1165 | | 32KB | 32677 | 1012 | 512GB | 255 | 16TB | 2335 |
|
なお、運用管理上の観点から、使用するページサイズの種類はできるだけ少なく抑えることをお勧めします。バッファープールや一時表スペースはページサイズごとに必要になるため、数が多いと管理が煩雑になります。
3. ファイル管理のタイプによる表スペースの種別
ここでは、ファイル管理タイプによる表スペースの種類と特徴を解説します。表スペースにはファイル管理タイプによって以下の種類があります。
DMS（Database Managed Storage）表スペースは、データベース・マネージャーによって管理されます。作成時に指定するコンテナの種類によってさらにDMSローデバイスとDMSファイルに分けられます。コンテナがデバイスの場合は、DMSローデバイスになります。コンテナがファイルタイプの場合はDMSファイルという種類になります。なお、DB2 for Windowsの場合は、DMSローデバイスはありません。
DMS表スペースの特徴としては、表と索引が別々の表スペースに作成できる、コンテナの追加、削除、拡張、縮小が可能、SMSに比べてパフォーマンスが良い、といったことがあげられます。
以下はそれぞれのDMS表スペースの作成例になります。
DMSローデバイスの表スペース作成例
コンテナ数が3の場合
CREATE TABLESPACE DMSTBS1 MANAGED BY DATABASE
USING (DEVICE '/dev/rhdisk1' 10000,
DEVICE '/dev/rhdisk2' 10000,
DEVICE '/dev/rhdisk3' 10000 )
※デバイス名の後ろに指定するのは各コンテナに割り振るページ数になります。
このコンテナサイズの合計が表スペースのサイズになります。
|
DMSファイルの表スペース作成例
コンテナ数が2の場合
CREATE TABLESPACE DMSTBS2 MANAGED BY DATABASE
USING (FILE 'dbdata/dmstbs2.f1' 50000,
FILE 'dbdata/dmstbs2.f2' 50000 )
※ファイル名を上記のように絶対パスではなく相対パスで記述した場合は、
データベースディレクトリーから見た相対パスになります。
ファイル名の後ろに指定するのは各コンテナに割り振るページ数になります。
|
SMS（System Managed Storage）は、オペレーティングシステムのファイル管理マネージャーによって管理されます。コンテナとして指定するのはOS上のディレクトリになり、DMS表スペースのようなページ数の指定はありません。表や索引は指定したディレクトリにファイルとして作成されます。このファイルは動的に拡張され、表スペースのサイズの上限は、ファイル・システム/ドライブ/ファイルのOSの限界サイズによって決まります。表スペース作成後に、表スペースの拡張や縮小を行うときは、OS上の領域を調整してください。領域に余裕がある場合はコンテナ上のファイルは自動的に拡張されます。なお、DMSでは物理ディスク追加時などにコンテナを追加するような運用が可能ですが、SMSではコンテナを追加、削除することはできません。また表と索引を別々の表スペースに格納することはできません。
以下はSMS表スペースの作成例になります。
SMS表スペース作成例
コンテナ数が3の場合
CREATE TABLESPACE SMSTBS1
MANAGED BY SYSTEM
USING ('d:¥smstbs1', 'e:¥smstbs1', 'f:¥smstbs1')
※指定するディレクトリは空でなければなりません
|
これらの表スペースからどの種類を選択するかは、そのシステムにおいて何を重要とするかで決まります。2つの観点でDMSとSMSを比較すると以下のようにいえます。
- パフォーマンスの観点を重視 → DMS表スペースを選択
- 運用管理のしやすさを重視 → SMS表スペースを選択
まず、パフォーマンスの面で優れている順に表スペースの種類を並べるとこうなります。
DMSローデバイス ＞ DMSファイル ≫ SMS
DMSローデバイスとDMSファイルとではそれほど大きな差はありませんが、DMSとSMSでは、DMSの方がパフォーマンスに優れているといえます。これは、DMSとSMSのデータのアロケート方法の違いや、DMSは表データと索引データを異なる表スペースに配置できるなどの理由からです。なお、HACMPなどのクラスタソフトを使用する場合、システムのテイクオーバーにかかる時間に関して、DMSローデバイスの方が有利です。パフォーマンスを重視するようなシステムではDMSローデバイスやDMSファイルを検討してください。ただし、一時表スペースとカタログ表スペースについてはSMSが推奨です。
次に、運用管理のしやすい順に表スペースの種類を並べるとこうなります。
SMS ＞ DMSファイル ＞ DMSローデバイス
前述の通りSMS表スペースは、動的に拡張されます。表スペースごとにファイルのサイズを監視する必要がなく管理がしやすいことから、パフォーマンスを必要としないテスト環境や開発用のシステムでよく使用されます。また、本番環境でもパフォーマンスよりも管理のしやすさを重要視する場合はSMSが適していることもあります。DMSファイルとDMSローデバイスを比較すると、DMSローデバイスは使用されるコンテナの数が増えるほど管理対象となる論理ボリュームが増えますが、DMSファイルでは大きな論理ボリュームに複数の表スペースを作成することができ管理が比較的容易です。またDMSファイルはサイズを拡張したい場合に、論理ボリュームの大きさに余裕があれば、ALTER TABLESPACE文でコンテナに指定しているファイルサイズを拡張できるため、サイズの変更も比較的容易です。
設計時にはこのような特徴を踏まえ、パフォーマンスを重視する場合はDMSローデバイスもしくはDMSファイルの使用を検討し、管理の容易さを重視する場合はSMSを検討してください。
4. エクステントサイズ
エクステントとはページの集合であり、表スペースにおけるコンテナのデータの割り振り単位です。エクステントサイズは後から変更できないため、表スペース時に決定しておく必要がありますが、ほとんどの場合デフォルトの32ページから変更する必要はありません。
例外として、多数の小さい表からなる表スペースは、表ごとに割り振られるエクステントの領域を減らすため、サイズを減らすことも検討してください。逆にデータを一度に大量に読み書きする特性の表スペースの場合は、サイズを増やすことを検討してください。なお、エクステントサイズはデータをディスクからバッファープールに読み込む際の単位となるプリフェッチサイズに影響します。
5. プリフェッチサイズ
プリフェッチとは複数のデータページがアプリケーションで必要になることを想定してディスクからバッファープールへ読み出すことをいいます。この時に一度にバッファープールへ読み出すサイズがプリフェッチサイズです（図4参照）。
図4. プリフェッチサイズ
プリフェッチサイズは、コンテナに実際に割り当てられているディスク数とエクステントサイズに応じて以下の式から決定しますが、デフォルトではプリフェッチサイズはAUTOMATICという値になっており、設定値は下記式に基づき自動計算されますので、デフォルト値を使用してください。
プリフェッチサイズ＝
(コンテナ数)×(1コンテナ当りの物理ディスク数*)×エクステントサイズ
*RAIDディスクを使用するなど1コンテナ当りに複数の物理ディスクがある場合は、
コンテナ数が1つでも実際には複数の物理ディスクが使われており、
コンテナあたりの物理ディスク数を計算に加える。
その場合は、レジストリ変数(DB2_PARALLEL_IO)を「*」に設定する。
そうでない場合は、1コンテナ当りの物理ディスク数は1と計算する
|
もしも、RAIDなどのディスクを使用しており、1コンテナあたりに複数の物理ディスクがある場合は、DB2_PARALLEL_IOレジストリ変数を調整し、1コンテナから複数のエクステントがプリフェッチできるように設計してください。なお、DB2_PARALLEL_IOが「*」と設定されている場合には、各コンテナあたり6個の物理ディスクをもっているという想定で自動計算されます。DB2_PARALLEL_IOの詳細は書きマニュアルを併せてご参照ください。
「コンテナを追加またはドロップした後の自動プリフェッチサイズ調整」
「データが RAID 装置にある場合の表スペース・パフォーマンスの最適化」
6. バッファープール
表スペースごとに使用するバッファープールを決定する必要があります。バッファープールのページサイズは表スペースのページサイズと一致するように設計してください。一般的にたくさんのバッファープールを作成し表スペースごとに割り当てるよりも、大きなひとつのバッファープールを複数の表スペースで使用する方が、効率的に使用され良いパフォーマンスが得られますので、バッファープールは細かく分割しないようにしてください。
7. コンテナ数、コンテナサイズ
コンテナ数、コンテナのサイズは、ディスクの構成やデータ量に依存しますが、一般的にできるだけ多くのディスク（6～10個）にコンテナを分散した方がディスクI/Oが軽減でき、パフォーマンスが良いと言われます。コンテナの配置については、「2.4 ディスク上へのオブジェクトの配置方法」を参考にしてください。
*ポイント
- 表データ、索引データは異なる表スペースに配置する（DMSの場合）
- 表スペースとバッファープールのページサイズは一致させる
- 使用するページサイズの種類はできる限り少なく抑える（1～2種類）
- パフォーマンスを重視する場合はDMS、運用管理のしやすさを重視する場合はSMSも検討する
- バッファープールは複数に分割するよりもサイズの大きいバッファープールを1つ使用する方が、一般的にパフォーマンスが良い
- コンテナは複数の物理ディスクに分けI/Oを分散させた方がパフォーマンス上有利
2.3 表スペース容量の見積もり
ここでは、データベースに必要な以下の表スペース領域の見積もり方法について解説します。
- ユーザー表スペース
- 一時表スペース
- カタログ表スペース
【ユーザー表スペース】
ユーザー表スペースの見積もりを行う時に必要となる材料は以下になります。これらの項目は前章までで既に決定していると思います。
- 表スペースに含む表や索引のリスト
- それらの表や索引の平均行サイズと行数
- 表スペースのページサイズ
ユーザー表スペースの見積もりには以下の式を使用して、1ページに格納可能な行数を出し、必要な行数を格納するためにはその表スペースに何ページ必要になるかを算出してください。
1ページあたりに格納可能な行数
ROUND DOWN(ページサイズ/(平均行サイズ + 10))
※ページサイズには実際のページサイズからデータベース・マネージャー用のオーバーヘッドの68バイトを引いて計算すること
|
必要となるページ数
(レコード件数 / 1ページあたりの行数) × 安全率
※ 安全率：オーバーヘッド分、PCTFREEを設定した場合はその分や、
同じ表スペース内でREORGする場合なども考慮すること。
※ ただし、上の表で示した格納可能行数が上記の式で算出される値よりも
小さい場合には、こちらの小さい方の値を使ってください。
|
以下は、上記の式を使用した見積もりの例になります。
※表の平均行サイズ= 56バイト、行数=10万行、ページサイズ=4KBの場合
1ページあたりに格納可能な行数
=（4028/（56バイト+10））
= 61（行）
必要となるページ数
=（100,000/61）× 1.1
= 1,639（ページ） ⇒1,639ページ必要
※ここでは安全率は1.1としていますが、システムに応じて変更してください
|
【一時表スペース】
一時表スペースは実際の使われ方によって使用量が異なるため、事前に正確に見積もることは困難です（索引作成時に使われる量に関しては式により見積もり可能）。テストフェーズなどで使用状況をモニターし、必要に応じてサイズ変更を行ってください。
最初に作成する際の目安としては、最も大きな表の2～3倍と言われます。なお、索引作成時やロードのREBUILD時に必要となる領域については下記式から見積もることが可能です。大量のロード処理などがある場合には考慮してください。
索引作成時に必要となる一時表領域
(平均行サイズ＋9) × 行数 × 3.2
|
【カタログ表スペース】
カタログ表スペースはデータベースごとにひとつ作成され、データベース・オブジェクト(例えば、表、ビュー、索引およびパッケージ)の定義についての情報が保管されます。通常200～300MB程度あれば問題はありませんが、SQLプロシージャーを作成する場合、プロシージャーの実行モジュールがカタログ表スペース内に格納されるため、多数のSQLプロシージャーを作成する場合はスペースに注意してください。
【その他】
他に自動的に作成される表スペースについて以下のものがあります。これらの表スペースは自動保守機能を使用する場合に使われる表スペースですが、自動統計収集はデフォルトでONですので、OFFにしない場合これらの表スペースは自動的に作成されます。
- SYSTOOLSPACE 表スペース
データベースの自動保守（自動統計収集および再編成）を使用する場合に自動作成される表スペースです。自動統計収集および再編成の作業データを、SYSTOOLSPACE表スペース中の表に格納します。SYSTOOLSPACE表スペース作成時のサイズは約700KBですが、使用量に応じて増加します。通常、SYSTOOLSPACEに必要な容量は、データベース中の表の数に比例し、1つの表に対して約1KB として計算してください。
- SYSTOOLSTMPSPACE 表スペース
自動統計情報収集および再編成の評価を行う際に、一時データの保管に使用されるUSER TEMPORARY 表スペースです。
2.4 ディスク上へのオブジェクトの配置方法
ここでは、データベースのオブジェクトの配置方法と考え方について解説します。表スペースの配置を考える際には、表や索引以外のオブジェクトも併せて考える必要があります。具体的には、以下のようなオブジェクトがあります。
- アクティブログとアーカイブログ
- 一時表スペース
- カタログ表スペース
- バックアップ領域
- その他の領域
これらの領域を配置する際には、どういった処理を優先的に実施したいかを考えて配置します。この中でも特に重要になるのがアクティブログの配置です。
【アクティブログとアーカイブログ】
データベースのオブジェクトの中でアクティブログは特に重要です。アクティブログはデータベースの更新を記録するだけでなく、破損回復などのリカバリーにも使用されます。またアクティブログが破損してしまうとデータベースに接続することができなくなります。このような意味からアクティブログの構成、配置は非常に重要になります。アーカイブログについては「3.1ロギング方式の決定」で解説していますので参照してください。以下、ログの配置の際に指針とすべき項目になります。
- アクティブログの2重化を検討する
- アクティブログ専用のディスク上に配置する
- アクティブログとアーカイブログは別ディスクに配置する
- アクティブログに使用するファイ・ルシステムは、ログ容量の約2倍用意する（アーカイブ時のコピーやログのリトリーブ時のスペース確保のため）
- ログアーカイブ機能を使用する場合は、アーカイブ先ディレクトリーの数にあわせて領域を確保し、別のディスク配置する
【一時表スペース】
一時表スペースの配置方法としては、一時表スペースのI/Oが多く、データや索引用の表スペースのI/Oと衝突する場合は、別ディスクに配置するようにしてください。
【バックアップ領域】
ここでいうバックアップ領域とはバックアップを取得した際のバックアップファイルの保管場所を指します。運用設計においてバックアップ運用をすることが決定した場合は、バックアップファイルの保管場所を検討してください。バックアップファイルの保管場所は、バックアップ対象のデータが保管されているディスクとは別のディスクにするようにしてください。理由は、バックアップを取得する場合、バックアップ対象のデータベースを読んでバックアップ先に書く、という処理を行いますので、同じディスクに配置すると読み書きの競合が起こります。また、データが保管されているディスクに障害があった場合、バックアップファイルも同じディスクに保管されていては意味がありませんので、別のディスクに保管するようにしてください。
【その他の領域】
その他の領域としては、例えばロード処理を行う際に使用するファイル保管場所などが考えられます。ロード処理は多くのシステムで使用されている機能ですが、表データが大きいほど処理に時間がかかる可能性があります。そこで、ロード元のファイルを格納するファイル・システムのパフォーマンスを考慮する必要がります。具体的には、ロード用のファイルは、一時表スペースとは別ディスクに配置してください。これは、ロード処理の中では索引の作成処理のためにソートが行われ、ロード元ファイルと一時表スペースを同じディスクに配置しておくと、読み書きの競合が発生してしまうためです。
*ポイント
- アクティブログへの書き込み速度は、データベース更新処理のパフォーマンスにとって特に重要、まずアクティブログの配置を考える
- 一時表スペースと表のデータや索引の表スペースのディスクは分ける
- バックアップ領域はデータ領域とは別のディスクに配置する
- ロードファイルを保管する場合は一時表スペース領域とは別のディスクに配置する
【ユーザー表スペースのディスク配置】
ここまでで、データベース上に作成するオブジェクトについて整理しました。では、表や索引を持つユーザー表スペースとそれ以外のオブジェクトの配置について解説します。
まずユーザー表スペースの配置については、下記の指針を参考にしてください。
- 複数の物理ディスクに表スペースを配置する
- 複数のコンテナを使用する場合は同じサイズ、タイプにする
- 索引用表スペースは別ディスクに配置する（DMSが前提）
- LOB用表スペースは別ディスクに配置する（DMSファイルが前提）
表スペースを複数のディスクに配置することは、表スペース配置の鉄則です。複数のディスクに配置することで、並行して読み書きを行うことができ、I/Oの衝突を防ぐことができます。また、複数コンテナのコンテナサイズが異なる場合、格納されるデータの不均等に分散されます。この結果、データの取り出しなどの並列入出力の効率が低下しますので、表スペースのコンテナは同じサイズにそろえてください。
全体の配置を考える際には、これまでに解説したポイントを抑え、できる限りディスクI/Oを分散させるような配置を行うことが重要です。もしも、物理ディスクの数が限られるなどの制約がある場合はディスクI/Oの競合が発生しないような処理に使われるスペースを同じ物理ディスクに配置するような工夫をしてください。次ページに例を示しますので参考にしてください。
*ポイント
- ユーザー表スペースはできるだけ複数のディスクにまたがるように配置する
- 索引やLOBの表スペースはデータとは別のディスクに配置する
- 物理ディスクを完全に分けることが難しい場合、読み取りや書き込みの競合が起こらないオブジェクトを同じディスクに配置する
図5. 表スペース配置例
図5の例では、アクティブログとバックアップ領域を同一の物理ディスクに配置しています。アクティブログは、データ用表スペースと同じディスクに配置すべきではありませんが、アクティブログのためだけにディスクを1つ確保すると、他の領域が納まりきらないようなケースでは、アクティブログのI/Oとは競合しない、バックアップ領域を同じディスク上に配置するなどの工夫が考えられます。ただし、バックアップを、表スペース単位で、またはオンラインで行い、その間に表へのアクセスがある場合には、ログへの書き込みとバックアップ取得のI/Oが競合するため、適当ではありません。
次に、一時表スペースは、データ用表スペースとは別ディスクに配置すべきですが、この例では一時表スペースのためだけにディスクを確保することができないため、一時表スペースへのアクセスとの競合がおきない表スペースを同じディスク上に配置します。バックアップ領域を配置することもできますが、今回は、LOB用表スペースに格納されている表は、追加のみで、ロード、REORGや複雑なSQLの処理が入らないという想定で、一時表スペースと同じディスク上に配置しました。
データ用表スペースAとINDEX用表スペースAは、検索や更新が頻繁なため、他の表スペースとは分けたいというようなケースでも、Aのためだけにディスクを確保することができない場合には、他の表スペースと同じディスク上でも、できるだけ多くのディスクにまたがるように表スペースを配置するような工夫が考えられます。
3. 非機能要件の整理と設計
物理設計では、データを物理的に格納することが目標となりますが、実際に使用する際の運用管理やパフォーマンスといった非機能要件を設計に取り入れる必要があります。例えば、できるだけ管理のしやすさを優先したい、逆に管理が多少煩雑でもパフォーマンスを優先したい、などさまざまな要件があると思います。表スペースの種別や配置に関しては、ここまでで取り上げた特徴を参考に非機能要件に見合った設計を行ってください。
ここではデータベースの設計時に必ず決定しておく必要があるロギング方式についてご紹介します。また運用管理を自動で行い、ユーザーの負荷を軽減するために使用可能な自動構成や自動管理機能について簡単に解説します。
3.1 ロギング方式の決定
データベースのロギングの方式には大きく分けて循環ロギングとアーカイブロギングがあります。循環ロギングは、ログが循環的に書き出されてゆくため、管理の面からは非常に有利ですが、オフライン以外のバックアップが取得できない、ロールフォワード処理ができないためデータベースがバックアップ取得時点までしか回復できない、などのデメリットもあります。要件に応じてどちらのロギング方式を採用するかを検討してください。詳細は運用設計で決定してください。
ログに関して決定しておく必要のある項目としては、ログファイルサイズ、一次ログ数、二次ログ数があります。データベースのログは一次ログ数に定義した数だけ割り振られます。一次ログで足りない場合、例えば非常に長いバッチを未コミットで実効した場合などには、二次ログが使用されます。二次ログを使用し尽くしてもログが書ききれない場合は、ログフルが発生しエラーとなり、トランザクションはロールバックされます。
ログファイルの容量は、最大のトランザクション(通常大量更新を行うバッチジョブなど)で使用されるログ容量をスナップショットより測定し、その数値を元に見積もってください。なお、ログファイルのサイズをあまり大きくすると、ログファイルの切り替えの際にディスクI/Oの負荷が大きくなり、サイズ(LOGFILSIZ)をあまり小さくすると、頻繁にログファイルが切り替えられるためにバッファープールが有効に利用されない場合があります。
3.2 自動管理機能
ここではデータベース管理者の負荷をできるだけ少なくするという観点にたって、データベースの物理設計で利用可能な自動構成や自動管理を行うための機能についてその概要をご紹介します。
- 自動ストレージ
- 構成アドバイザー
- セルフチューニングメモリー
【自動ストレージ】
自動ストレージは、表スペースのコンテナ管理をDB2に行わせる機能です。この機能を使用するためにはデータベース作成時に自動ストレージデータベースとして作成する必要がありますが、DB2 for LUW V9.5以降はデフォルトで、自動ストレージ機能を使用可能なデータベースが作成されるようになりました。ユーザーは、表スペース作成時にコンテナのリストを記述する必要がなく、コンテナはDB2が事前に決められたストレージパスに自動的に割り振られますが、この際、DB2は自動的に複数のストレージパスにまたがるようにコンテナを作成します。このストレージパスは後から追加することも可能です。また、自動ストレージのメリットとして、表スペースコンテナが自動拡張されるという特徴があります。以下にストレージパスの設定例と自動ストレージ機能を使用した表スペースの作成例をご紹介します。
自動ストレージデータベースでのストレージパスの指定方法
CREATE DATABASE TESTDB AUTOMATIC STORAGE YES
ON /data/path1, /data/path2 DBPATH ON /testdb
※(DBPATH として明示的にリストされた) ディレクトリ/testdb にデータベース TESTDB が作成されます。
自動ストレージが明示的に有効になり、ストレージパスは /data/path1 および /data/path2 になります。
表スペースを自動ストレージ機能を使用して作成
CREATE TABLESPACE TBS1 MANAGED BY AUTOMATIC STORAGE
※ストレージパスに指定したディレクトリに自動的にコンテナが作成されます。
|
【構成アドバイザー】
構成アドバイザーは、サーバーの資源、システムの種類、ユーザー数、アプリケーションの特性などを入力することによって、構成パラメータの推奨値を得ることができる機能です。AUTOCONFIGUREコマンド、コントロール・センターで実行可能で、DB2のデフォルト値をそのまま使用するよりは問題が少ないといえます。V9からは、データベース作成時に自動起動され、データベース構成パラメータが設定されますが、構成アドバイザーが決定したパラメータをもとに確認は必ず行ってください。なお、この機能を使用せずにデータベースを作成したい場合、CREATE DATABASEコマンド実行時に、AUTOCONFIGUREオプションで APPLY NONEを指定してください。
【セルフチューニングメモリー】
セルフチューニングメモリー機能とは、メモリー構成パラメータの値の設定とバッファープールのサイズ変更をDB2が自動的に実行する機能で、データベース管理者のメモリー構成、管理の負荷を軽減します。V9.5では以下のパラメータがセルフチューニングメモリーの対象となっています。
- buffer pools
- lock list
- max locks
- package cache
- sort heap
- application heap
- dbheap
- monitor heap
- statement heap
- statistics heap
図6のようにDB2が使用するメモリーは大きく分けるとINSTANCE_MEMORY、DATABASE_MEMORY、APPL_MEMORYに分けられますが、ユーザーはその上限を指定して、細かいメモリー関連のパラメータはセルフチューニングメモリー機能を使用して管理するというような使い方も可能です。
図6. ページ、エクステント、コンテナの関係
4．物理設計書に含まれるもの
実際のプロジェクトでは、物理設計の成果物は物理設計書として纏めることが一般的です。物理設計書に含まれる内容は、下記のようなものがあります。成果物の形式は、データベースシステムの構成が一目でわかるような図等を含めた概要レベルのもの、細かい構成内容まで明記した詳細レベルのものを作成する場合が多いと考えられます。以下の内容を参考に物理設計書を作成してください。
- インスタンス構成
- インスタンス名
- サービス名
- ポート番号
- ホームディレクトリー
- データベース構成
- データベース名
- ローカルデータベース・ディレクトリー
- ストレージパス（自動ストレージを使用する場合）
- レジストリ変数
- データベース・マネージャー構成パラメータ（デフォルト値/初期設定値）
- データベース構成パラメータ（デフォルト値/初期設定値）
- 表スペース構成
- 表スペース名
- 表スペースID
- 種類
- タイプ
- ページサイズ
- エクステントサイズ
- プリフェッチサイズ
- コンテナ
- バッファープール構成
- バッファープール名
- 表スペースID
- ページサイズ
- SIZE(MB)
- 拡張記憶域の有無
- データ容量見積もりシート
著者について  | | | developerWorks Information Management team |
記事の評価
| 
