レベル: 中級 香川 浩子 (eb82674@jp.ibm.com), Advisory IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社
2009年 03月 05日 この記事では、DB2のディスク計画と物理配置について、ご紹介します。
はじめに
データベースの構成要素や作成手順についてご紹介してきましたが、ここではそのデータベースをどのようにディスクに配置するのかという点について解説します。まず、データベースを実際に配置する前に、データベースに適したディスク（ストレージ）構成を検討する必要があります。ストレージ構成が決まったら、データベースが持つオブジェクトを物理ディスク上に配置していきます。データベース・オブジェクトとは、表スペース、表、ビュー、索引、パッケージ、ログ、ロックなど、データベースの構成要素を表します。主なディスク割り振り設計対象は表スペースとログになりますので、ここではその二つのオブジェクトの設計方法について解説します。
このガイドでは、詳細な設計を行うのではなく、ごく一般的なデータベースとして稼動できるレベルでの設計方法を紹介します。
物理配置設計フロー
以下のフローに沿って物理配置を設計していきます。
図1. 物理配置設計フロー
(1) データベースに適したストレージ設計
昨今、ストレージやディスクを取り巻く環境は大きく変わってきました。物理的なディスクと直接繋がることはなくなり、ネットワーク上の仮想化されたディスクとして見えるようになりました。このようなストレージ環境では、以前のような細やかなデータベースのストレージ設計を行う必要はありません。仮想化の恩恵を最大限に生かし、それに適応したデータベースのストレージ設計を行いましょう。
データベース専用のLUNを割り当てる
データベースシステムのみが使用する専用のLUNを割り当てます。ストレージとデータベースの紐付けがシンプルになり、問題が発生した際の判別も容易になります。
ディスクのストライピングを適用する
ストレージが提供しているRAIDのストライピング機能を使用してLUNを作成します。例えばRAID-5、RAID-10などです。このLUNを表スペースのコンテナーに割り当てることにより、I/Oが分散されます。さらに、DB2の機能により、複数のLUNに対しコンテナーを割り当てて、DB2のレベルでストライピングすることも可能です。
RAID-5は1箇所の物理ディスク障害であれば、復旧できます。一方、RAID-10は、冗長性が高く、複数の物理ディスク障害があっても復旧可能ですが、その分コストが高くなります。このことから、大きなデータ領域はRAID-5、トランザクションログはRAID-10を採用することをお薦めします。もちろん、コスト面で問題が無ければ、全ての領域をRAID-10で構成しても構いません。
トランザクションログとデータのLUNを分ける
可用性を高めるために、トランザクションログとデータ（表スペースやデータベースディレクトリ）の領域については、それぞれ別の物理ディスクとLUNに割り当てます。
rawデバイスではなく、ファイルシステム（1FSにつき1LUN）を使用する
ダイレクトI/O、コンカレントI/Oの出現により、パフォーマンスの観点でrawデバイスを使用する必要性は無くなりました。rawデバイスに比べてファイルシステムは管理が容易であり、また1つのファイルシステムに複数のコンテナーを配置し、それぞれ別の表スペースに割り当てることもできます。
ファイルシステムを採用する際の考慮点としては、サーバーを高可用性構成（HAなど）にしている場合、テークオーバーに時間を要する可能性があるという点です。迅速にサーバーを復旧する必要がある場合は、rawデバイスの採用についても検討してください。
NO FILE SYSTEM CACHINGを使用する
ダイレクトI/O、もしくはコンカレントI/Oを有効にするために、表スペース作成時にNO FILE SYSTEM CACHINGを指定します（v8.2以降）。このオプションを指定することで、rawデバイスに対して行われるI/O操作に近いパフォーマンスを得ることができます。なお、LOBを格納する表スペースについてはOSのキャッシュを利用した方がパフォーマンスは良いため、NO FILE SYSTEM CACHINGを指定しません。
(2) 表スペースの物理配置
データベースに適したストレージ設計を行ったら、次にデータベースのオブジェクトをストレージにマッピングしていきます。ここでは、データベースの大半の領域を占め、テーブルやインデックスの置き場所となる表スペースの物理配置について説明します。
実際にデータを保存する場所はコンテナーという場所で、表スペースはコンテナーにて構成されています。つまり、表スペースは論理的な単位であり、実際の入出力はコンテナーという物理的な入れ物に対して行われています。表スペースは1つ以上のコンテナーから構成され、データはコンテナー間で平均的に割り振られます。コンテナーの物理配置を検討する上で最も重要なことは、いかに並列にアクセスを行えるようストレージに配置できるかという点にあります。
以下の方針に従ってコンテナーを配置しましょう。
- 物理的なディスク（RAID）が複数存在する場合は、表スペースのコンテナーをそれぞれのディスクに定義し、パラレル（並列）I/O処理を活用する
- 1表スペースに複数のコンテナーを複数のディスクに定義すると、ディスクへのIO処理を並列に行うことができ、パフォーマンスの向上が見込めるため
- 1ディスクには1表スペースあたり1コンテナーのみを作成する
- 1つの表スペース上のコンテナーを複数作成すると、I/Oの競合が起こるため
- 複数コンテナーを指定するときは、同一のディスク・タイプを使用し、各コンテナー・サイズも同一にする
- パラレル・プリフェッチが効率的に行われ、パフォーマンスの最適化が図れるため
図の表スペースとコンテナーを例に説明しましょう。
図2. 表スペースとコンテナーの例
「良い例」の表スペース1、表スペース2は表スペースのコンテナーを複数のディスクに配置しているため、ディスクへの入出力処理を並列に行うことができます。
一方、「悪い例」の表スペース1～3については、確かに1表スペースあたり1DISK、1コンテナーに従っていますが、複数コンテナーで構成していないため、パラレルアクセスの恩恵を受けることができません。また、表スペース4については、確かに複数コンテナーで構成していますが、1表スペースあたり1DISK、複数コンテナーとしているため、I/Oの競合が発生してしまいます。
複数コンテナーを定義する際のコンテナー・サイズですが、例えば、良い例の表スペース1でご説明しますと、コンテナー1-1～1-3までは100Gで構成して、コンテナー1-4は50Gで構成したとします。DB2はエクステント単位でラウンドロビンに書き込みにいくため、それぞれ同じ量が消費されます。いずれは、コンテナー1-4がいっぱいになってしまい、そうなると4並列が3並列に並列度が落ちてしまいます。これはDMSの場合ですが、SMSで複数コンテナー、別サイズで構成していた場合は、どれかがいっぱいになった時点で、それ以上の書き込みはできなくなってしまうので、注意が必要です。
基本的に、上記の点に留意して表スペースとコンテナーを配置すれば問題ありません。表スペースのタイプとして、システム表スペース、一時表スペース、ユーザー表スペースの3つがありますが、それぞれの配置を以下の方針で検討されても良いでしょう。
(2)-1 システム表スペースの物理配置
システム表スペースは、データベースの全ての情報を格納しており、ユーティリティーやSQL実行時に必ず参照・書き込みされる重要な表スペースです。可用性を高めるために、他の表スペースとは別の物理ディスクにコンテナーを配置することが望ましいです。ただし、物理ディスクの数が少ない場合は、ユーザー表スペースと同じディスクに配置しても良いでしょう。
(2)-2 一時表スペースの物理配置
一時表スペースは、ソート、表の再編成、索引の作成、表の結合などで一時的にデータが入る表スペースです。SQLによっては、ユーザー表スペースよりも頻繁に使用される可能性があります。パフォーマンスのリスクを最小限にするためにも、一時表スペースのコンテナーは、他の2つの表スペースとは別の物理ディスクに配置すると良いでしょう。
(2)-3 ユーザー表スペースの物理配置
ユーザー表スペースには、テーブルデータ、索引、LOBを格納することができます。管理性を高めるために、それぞれのオブジェクト毎に、表スペース、コンテナーを分割することが望ましいです。ディスクについては分割しなくても良いですが、IOの衝突が気になるようでしたら分割を検討します。
(3) ログの物理配置
次にログの物理配置を検討します。ログとは、データベースへのすべての更新内容を発生順に記録しておくファイルになります。ログは、ロールバックやロールフォワード、クラッシュリカバリーなど障害などが発生した場合に元の状態に戻すために必要なものです。
ログには「循環ロギング」と「アーカイブロギング」の2種類の運用モードがありますが、循環ロギングの場合はアクティブログ領域、アーカイブロギングの場合は、アクティブ領域に加えて、アーカイブログ領域が必要です。トランザクションの内容はアクティブログに書き込みが行われるため、特にアクティブログの物理配置はトランザクションのパフォーマンスにも影響することが考えられます。これらの点を踏まえて、ログの物理配置を以下のように行うと良いでしょう。
- ログは、専用のファイルシステムに配置する
- アーカイブログとアクティブログは同じディスクに配置する
- ログを2重化する
可用性を高める場合は、上記に加えて以下を検討します。
- アクティブログ専用のディスク上に配置する
- ログを配置するディスクを表スペースとは別にする
- アーカイブログとアクティブログは別のディスクに配置する
- アーカイブロギングを使用する場合は、アーカイブ先ディレクトリーの数にあわせて領域を確保し、別のディスク配置する
安全性という面で、ログは必ず別のファイルシステム（可能であれば別のディスク）配置するようにしてください。デフォルトはデータベースが保存されるディレクトリーと同じになりますので、必ず分けるようにして下さい。別のディスクにわけると、I/Oパスをわけることができますので、性能面からディスクを分けることは効果的と言えます。また、ログは必ず2重化するようにしてください。RAID、OSレベルのミラーリングを活用するのも手ですが、DB2の機能としてログを2箇所に記録するというログのミラーリングという方法もあります。
おわりに
データベースのオブジェクトである表スペースとログの物理配置について紹介してきました。これらのオブジェクトはデータベース領域の大部分を占めており、ストレージへの配置方法により、可用性や性能面に影響することが理解できたと思います。また、ストレージへの物理配置が重要な理由の1つとして、データベース作成後にストレージの変更を行うことが非常に困難であることが挙げられます。つまり、ストレージの初期設定がされた状態で運用されることになりますので、慎重且つ柔軟性のある設計を行うよう心がけましょう。なお、SVC（SAN Volume Controller）を使用すると、LUNやVGといった物理レイヤーの変更が簡単に行えます。
次のガイドでは、データベースを動かす上で最低限設定が必要なパラメータについて紹介します。
参考文献
著者について  | | | 香川浩子は主にプロジェクトサポートをメインにDB2の技術支援を担当してきました。現在はプロジェクトサポートに留まらず、新機能の稼動検証、資料開発、トラブルサポートなどにも従事しています。今年から部署のGroupLeaderとして日々のマネジメント業務をこなしながら、DB2やそれ以外のスキルの幅を広げるため、さまざまなスキル活動に参画しています。 |
記事の評価
| 
