8.1 物理設計で行うこと

物理設計では、方式設計担当者とともに、最終的なシステム設計書をもとに物理的な配置とベンダー製品の各種機能の使用を決定します。
物理設計にあたっては、費用的な観点や信頼性と障害対策に対する方針、物理的なサーバの配置条件など、さまざまな観点から検討する必要があります。

そこで、ここではデータベース設計上、汎用的に留意しておくべき点に焦点を絞って、Oracleデータベースの設計例を紹介します。
物理設計の中でも、最も一般的に行われているファイルの配置について、基本的な考え方と実際のワークシートを使用した設計例を紹介します。

耐障害性を考慮した配置

制御ファイルは、多重化（最低でも二重化）し、それぞれのファイルを別の物理ボリュームに配置します。

REDOログファイルは、同一グループに最低2つのメンバーを作成し、多重化します。
メンバーは別ボリュームに配置します。

アーカイブログファイルの出力先をローカルで多重化します。
出力先は別ボリュームに配置します。

SYSTEM表領域にはユーザオブジェクトを格納しないようにします。

競合を考慮した配置

更新処理の多いシステムでは、REDOログファイルは、できるだけ独立したボリュームに配置し、他のファイルヘの書き込みと競合をおこさないように配置します。
索引を多用するシステムでは、索引と表を格納する表領域を分け、物理ボリュームも分けます。

管理の容易性を考慮した配置

異なる業務で使用するオブジェクトは、なるべく別の表領域に格納します。
理由は、障害時の回復処理を考えると、表領域が分かれていれば、ディスク障害が発生したボリュームを使用していた業務のみがディスクを使えないという障害の局所化を実現できるためです。
また、オンラインバックアップを取得する際には、表領域が業務ごとに分かれていれば、業務のアクセス頻度に応じて、表領域単位にバックアップを取得する時間帯を考えることができるという利点もあります。

参考

カットオーバー後の物理配置に関するチューニング

• OLTP系のアプリケーション：

  UNDO表領域への書き込みがボトルネックになっていないかを確認します 必要に応じて、パラレル書き込みができるような環境に移行します 業務用の表領域で、書き込み処理がボトルネックになっている表領域があった場合、そこに格納されているオブジェクトの表領域を分け、さらにボリュームも分けて格納します

• DSS系のアプリケーション：

  一時表領域のエクステントサイズを、大容量のソートをするための初期化パラメータSORT_AREA_SIZEの整数倍に設定し、大容量のソート用の一時表領域を作成します もし、一時表領域への書き込み、読み込みがボトルネックになっている場合、パラレル処理ができるような環境に移行します

管理の容易性を考慮して分割

障害を局所化できるように業務ごとに分けます。

オンラインバックアップを考えた場合、更新頻度が0のもの、頻度が低いもの、高いものを個別の表領域に分けることによって、バックアップ計画が立てやすくなります。
更新頻度が高いものは、バックアップを頻繁に取得して、回復に必要な時間を短くするようにします。
更新頻度が低いものは、バックアップの間隔が長くなっても、更新頻度が高いものほど影響は大きくありません。
更新頻度が0の読み取り専用表領域を作成し、日常のバックアップ計画からは外しておくようにします。

表領域の特性と表の特性に応じて分割

エクステントサイズ、ブロックサイズの違いによって分けます。

競合を考慮して分割

同時にアクセスする可能性の高いオブジェクトは、異なる表領域、異なるボリュームに分けて格納します。
表と検索は分けて異なる表領域に格納します。

データファイルは管理のしやすさを考慮し、最大でも2GBぐらいの大きさにとどめます。
バックアップを取得したり、リカバリ時にリストアする時間を短くすることができます。

解説トレーナー