はじめに
Db2の構築案件では、論理設計だけでなく物理設計の品質が性能や運用性に大きく影響します。
IBMからは「Db2データベース物理設計ガイド」という資料が公開されており、設計初期に検討すべき内容が体系的に整理されています。
本記事では、このガイドをベースに構築案件で特に重要となるポイントを抜粋して解説します。
詳細については、IBM公式資料もあわせて参照してください。
【SIL】【IM】Db2 for LUW データベース物理設計ガイド
当資料は、Db2 for Linux, UNIX, and Windowsを用いたデータベースの物理設計において実施すべきことを、設計の流れに沿って解説したものです。
物理設計の全体像
物理設計は、単にストレージ配置を決める作業ではなく、以下のような流れで進みます。
| ステップ | 内容 |
|---|---|
| ① 表・索引定義 | テーブル構造、インデックス設計 |
| ② インスタンス構成 | インスタンス分割、DB分割 |
| ③ 表スペース構成 | 表スペース設計 |
| ④ 容量見積もり | 必要ディスク容量の算出 |
| ⑤ 配置設計 | ストレージへの配置 |
| ⑥ ユーザー設計 | 権限・ユーザー管理 |
| ⑦ パラメータ設定 | DB/DBM構成 |
| ⑧ OS設計 | OSレベルの最適化 |
この中でも、初期検討で特に重要なのが②と④です。
インスタンス構成とデータベース分割の考え方
インスタンス構成は、Db2の設計において最初に決めるべき重要な要素です。
インスタンス分割のポイント
インスタンスを分けることで、以下を分離できます。
- メモリ・プロセス空間
- 障害影響範囲
- 管理単位
一方で、分割しすぎると以下のデメリットがあります。
- 管理コスト増加
- リソースの分散
- 運用の複雑化
そのため、一般的には以下の観点で判断します。
| 観点 | 分割の目安 |
|---|---|
| 環境 | 本番/検証で分離 |
| 用途 | OLTP/DWHで分離 |
| 可用性 | 障害影響を分けたい場合 |
データベース分割のポイント
同一インスタンス内でデータベースを分割するかどうかも重要です。
分割の主な目的は以下です。
- バックアップ単位の分離
- 障害影響範囲の限定
- セキュリティ分離
ただし、分割しすぎると以下の影響があります。
- 接続管理の複雑化
- クロスDB処理(2フェーズコミット)の制約
表スペース容量見積もりの考え方
容量見積もりは、後から修正が難しいため重要です。
物理設計ガイドでは、見積もりの方法や計算式が詳細に記載されていますので、ぜひご確認ください。
見積もりの基本要素
以下を考慮して算出します。
- テーブル件数
- レコードサイズ
- インデックスサイズ
- 将来増加率
シンプルな目安
超概算として算出したい場合、以下のような考え方が使われます。
(昔のIBM技術情報にありました。)
ディスク容量 = 生データ量 × 4倍

あくまで目安ではありますが、初期段階では参考になります。
まとめ
Db2の案件に携わる際、IBMの「物理設計ガイド」は非常に有用です。
特に以下は初期段階で検討する必要があります。
- インスタンス構成とDB分割
- 容量見積もり
今回はポイントを絞って紹介しましたが、構築案件に関わる場合は、一度目を通しておくことをおすすめします。


コメント