Oracle Database インストレーション・ガイド 10gリリース2(10.2) for HP Tru64 UNIX B31755-01 |
|
この付録では、Optimal Flexible Architecture標準について説明します。この標準は、ほとんどメンテナンスを必要としない信頼性の高いOracleインストールを保証するために作成された一連の構成ガイドラインです。 この付録の内容は、次のとおりです。
Optimal Flexible Architecture標準は、次の目的で設計されています。
Optimal Flexible Architectureは、コンピュータ上でOracleディレクトリおよびファイルを編成する際に従う必要のある一連のガイドラインです。インストール・メディアに収録されているOracleコンポーネントは、すべてOptimal Flexible Architectureに準拠しています。つまり、Oracle Universal Installerでは、Oracle DatabaseコンポーネントがOptimal Flexible Architectureガイドラインに準拠したディレクトリ位置にインストールされます。
Optimal Flexible Architectureの使用は要件ではありませんが、データベースのサイズが大きくなると思われる場合や、複数のデータベースを使用する予定がある場合は、使用することをお薦めします。
Optimal Flexible Architecture標準に準拠したOracle製品インストールには、次の特性があります。
このファイル・システムは、次のような操作を容易に管理できるように編成されています。
I/O負荷は十分な数のディスク・ドライブ間で分散され、パフォーマンス・ボトルネックが防止されます。
ほとんどの場合、Optimal Flexible Architecture標準を実装するために新規ハードウェアを用意する必要はありません。
アプリケーションを複数のドライブ間で分散することで、ドライブ障害の影響を受けるアプリケーションを最小限に抑えます。
次の項目を複数のディスク・ドライブ間で分散できます。
ログイン用ホーム・ディレクトリを追加、移動または削除でき、それを参照するプログラムを改訂する必要はありません。
ファイルのカテゴリが、独立したUNIXディレクトリ・サブツリーに分けられているため、あるカテゴリのファイルに対する操作が他のカテゴリのファイルに及ぼす影響は最小限に抑えられます。
複数バージョンのOracleソフトウェアを同時に実行できます。これにより、旧リリースを使用中止にする前に、新リリースをテストしてから使用できます。アップグレード後に新リリースに転送する操作は管理者が容易に実行でき、ユーザーに対して透過的です。
管理情報をデータベースごとに分離することにより、管理データが適切な構造で編成および格納されます。
データベース・ファイルは、次のように名前が付けられます。
表領域の内容は次の目的で分離されます。
I/O負荷は、自動ストレージ管理ディスク・グループ内またはRAWデバイス内でOracleデータを格納するドライブを含め、すべてのドライブ間でチューニングされます。
以前のリリースのOracle Databaseでは、Optimal Flexible Architecture標準推奨のOracleホーム・パスは次のようになっていました。
/u01/app/oracle/product/9.2.0
Oracle Database 10gでは、Optimal Flexible Architecture推奨のOracleホームのパスが変更されています。Optimal Flexible Architecture推奨のパスは次のようになりました。
/u01/app/oracle/product/10.2.0/
type[_n]
この例で、type
は、Oracle Database(db
)やOracle Client(client
)などのOracleホームのタイプです。また、n
はオプションのカウンタです。この構文には、次の利点があります。
/u01/app/oracle/product/10.2.0/db_1
/u01/app/oracle/product/10.2.0/client_1
/u01/app/oracle/product/10.2.0/db_1
/u01/app/oracle/product/10.2.0/db_2
この項では、Optimal Flexible Architecture標準で推奨されるネーミング方法について説明します。この項の内容は、次のとおりです。
この項では、マウント・ポイントの規則について説明します。
ストライプ化もミラー化もされていないファイル・システムに格納されたデータベースについてOptimal Flexible Architecture推奨事項に完全に準拠するには、個別の物理デバイスに3つ以上のファイル・システムが必要です。
すべてのファイル・システムのマウント・ポイント名には、構文/
pm
を使用します。p
はリテラル、m
は各マウント・ポイントを区別するための一意の固定長キー(通常は2桁の番号)です。たとえば、/u01
と/u02
、または/disk01
と/disk02
となります。
各ディスク・ドライブに1つのアプリケーションからのデータベース・ファイルが格納され、各データベースにI/Oボトルネックを防止できる十分な数のドライブがある場合は、マウント・ポイントのネーミングに構文/
pm
/
q
/
dm
を使用します。表C-1に、この構文で使用している変数を示します。
変数 | 説明 |
---|---|
|
マウント・ポイント名 |
|
|
|
初期化パラメータ |
たとえば、test
データベース専用に2つのドライブを割り当てるには、マウント・ポイント名として/u01/oradata/test
および/u02/oradata/test
を指定します。
この項では、Optimal Flexible Architecture標準に準拠したディレクトリのネーミング規則について説明します。
Oracleベース・ディレクトリは、同じユーザーによりインストールされたOracle製品のトップレベル・ディレクトリです。Oracleベース・ディレクトリ名には、構文/
pm
/
h
/
u
を使用します。表C-2に、この構文で使用している変数を示します。
変数 | 説明 |
---|---|
|
マウント・ポイント名 |
|
標準ディレクトリ名 |
|
ディレクトリの所有者名(Oracle Universal Installerを実行中のユーザー) |
たとえば、/u01/app/oracle
はoracle
ユーザーにより作成されたOracleベース・ディレクトリで、/u01/app/applmgr
はapplmgr
ユーザーにより作成されたOracleベース・ディレクトリです。
Oracleベース・ディレクトリをUNIXファイル・システムと同じレベルに置くと、様々なマウント・ポイントにあるOracleベース・ディレクトリの集合を、1つのパターン一致文字列/*/app/*
を使用して参照できるという利点があります。
明示的なパス名は、パスワード・ファイル、/etc/passwd
およびOracle oratab
ファイルなど、格納用に特別に設計されたファイル内でのみ参照します。グループ・メンバーシップは、/etc/group
ファイル内でのみ参照します。
複数バージョンのOracleソフトウェアを同時に実行するというOptimal Flexible Architectureの要件を満たすように、ソフトウェアをパターン/
pm
/
h
/
u
/product/
v
/
type
_[
n
]
と一致するディレクトリにインストールします。
表C-3に、この構文で使用している変数を示します。
変数 | 説明 |
---|---|
|
マウント・ポイント名 |
|
標準ディレクトリ名 |
|
ディレクトリ所有者名 |
|
ソフトウェアのバージョン |
|
データベース( |
|
オプションのカウンタ。このカウンタによって、同じOracleベース・ディレクトリに同じ製品を複数回インストールできます。 |
次に例を示します。
/u01/app/oracle/product/10.2.0/db_1
は、このシステムに初めてインストールされるOracle DatabaseのOracleホーム・ディレクトリを示します。
/u01/app/oracle/product/10.2.0/crs
は、Oracle ClusterwareのOracleホーム・ディレクトリを示します(ClusterwareはRACのインストールに必要です)。 システムではOracle Clusterwareを1回のみインストールできます。したがって、オプションのカウンタは不要です。
インストール後にORACLE_HOME
環境変数を設定して、Oracleホーム・ディレクトリを指定します。
管理データの編成を容易にするために、データベース固有の管理ファイルはパターン/
h
/admin/
d
/
a
/
と一致するサブディレクトリに格納することをお薦めします。h
はOracleベース・ディレクトリ、d
はデータベース名(DB_NAME)、a
は特定のタイプのデータベース管理ファイル用のサブディレクトリです。表C-4に、データベース管理ファイル用のサブディレクトリを示します。
たとえば、/u01/app/oracle/admin/sab/adhoc/
はデータベースsab
に関連付けられているadhoc
サブディレクトリです。
次の表に、データベース・ファイル用の推奨ファイル・ネーミング規則を示します。
ファイル・タイプ | ファイル・ネーミング規則 |
---|---|
制御ファイル |
|
REDOログ・ファイル |
|
データファイル |
|
次の表に、この構文の変数を示します。
変数 | 説明 |
---|---|
|
この付録で前述したマウント・ポイント名 |
|
Oracleデータを他のすべてのファイルと区別する文字列(通常は |
|
|
|
Oracle表領域名 |
|
2桁の文字列 |
この規則に従うと、/u03/oradata/sab/system01.dbf
ファイルが属しているデータベースを容易に判別できます。
持続期間、I/O要求需要およびバックアップ頻度の異なるセグメントのグループを、異なる表領域間で分離します。
表C-5に、データベース・コンフィギュレーション・アシスタントによりOracleデータベースごとに作成される特殊な表領域を示します。データベースを手動で作成する場合は、必要な表領域も作成する必要があります。これらの表領域は、アプリケーション・セグメントに必要な表領域とは別のものです。
表領域 | 必須 | 説明 |
---|---|---|
EXAMPLE |
No |
Sample Schemasの格納に使用するEXAMPLE表領域 |
SYSAUX |
Yes |
SYSTEM表領域の補助表領域 |
SYSTEM |
Yes |
データ・ディクショナリ・セグメント |
TEMP |
Yes |
一時セグメント |
UNDOTBS1 |
Yes |
OracleがUNDO情報の格納に使用 |
USERS |
No |
その他のユーザー・セグメント |
これらの特殊な表領域を作成すると、データ・ディクショナリ・セグメントは削除されることがなく、削除できる他のセグメントはSYSTEM表領域への格納が許可されないため効率的です。これにより、表領域の空き領域が断片化されたことが原因でSYSTEM表領域をリビルドする必要がなくなります。
表領域には、8文字以内で意味のある名前を指定します。Oracle Databaseの表領域名は長さ30文字以内ですが、移植性のあるUNIXファイル名は14文字に制限されています。データファイルのベース名に推奨される標準はtn
.dbf
で、t
は意味のある表領域名、n
は2桁の文字列です。拡張子と2桁の文字列で合計6文字になるため、表領域名に使用できるのは8文字のみとなります。
意味のある名前を使用すると、データファイルとそれを使用する表領域を関連付けることができます。たとえば、Oracle General Ledgerのデータと索引を格納する表領域には、それぞれGLDおよびGLXという名前を使用できます。
表C-6に、ファイル・クラスの識別に使用する構文を示します。
表C-7に、2つのOracleホーム・ディレクトリと2つのデータベースを含むOptimal Flexible Architecture準拠のサンプル・インストールのファイル・マッピング階層を示します。データベース・ファイルは、3つのマウント・ポイント/u02
、/u03
および/u04
間で分散されています。
Optimal Flexible Architectureの目標の1つは、I/O負荷を様々な物理ドライブ間に分散させ、それにより信頼性とパフォーマンスを向上させることです。そのためには、次の方法があります。
Oracle Databaseのログ・ファイルとデータベース・ファイルを、異なるハードウェア信頼性レベルで分離して処理できます。Oracle Databaseのログ・ファイルは、冗長的に格納されるため当初は高度な信頼性を備えています。データベース・ファイルにも同様の信頼性を持たせるには、ディスクのミラー化を使用してデータをすべて複製する作業が必要になる場合があります。
通常、ディスクのミラー化には、複数の同一ドライブと1つのRAIDコントローラが必要です。あるディスクに障害が発生した場合は、他の方法では消失するようなデータを残りのディスクがリカバリできます。ディスクの1つを使用して消失データをリカバリすると、ミラーが消失する場合があります。その場合は、新規のミラーを作成する必要があります。
ディスクのミラー化は、ディスク・コントローラが提供する一部のレベルのRedundant Array of Independent Disks(RAID)構成に含まれます。RAIDレベルにより、冗長量が決まります。一部のRAIDレベルでは、ホット・スワップ機能を使用できます。これは、コンピュータの電源をオフにしたり機能を失わずに、不良ディスクを交換できることを意味します。
データベースで使用するディスクの設定方法は、ディスクの数と使用可能なハード・ディスク・コントローラのタイプに応じて異なります。ハード・ディスク・コントローラでストライプ化とミラー化の両方がサポートされる場合は、ストライプ化をサポートするようにコントローラを構成することをお薦めします。
ストライプ化により、パフォーマンスが大幅に向上します。ストライプ化されたドライブの領域はすべて、1つの論理ドライブとして表示されます。また、領域は、ストライプ内のすべてのディスクにある領域のストライプを走査することで使用されます。これは、大きいファイルには第1ディスクの一部の領域、第2ディスクの一部の領域、最後のディスクの一部の領域というように順番に使用された後、再び第1ディスクから使用されていくことを意味します。各ファイルは、ストライプ化された全ディスクにまたがって分散できます。この種のファイル内のデータには、複数のCPUが競合なしでランダムにアクセスできます。
通常、ストライプ化をサポートするコントローラは、キャッシュ機能も提供します。これは、データをコントローラに書き込み、キャッシュに入れ、ディスクではなく記憶域にしばらく保存できることを意味します。読み取られたデータも、同様にコントローラでキャッシュに入れることができます。Oracle Databaseでは、すべてのデータベース読取りがすでにシステム・グローバル領域(SGA)にキャッシュされているため、読取りキャッシュを使用しないでください。SGAに使用できるバッファ・サイズは、初期化パラメータ・ファイルinit.ora
のDB_CACHE_SIZE
パラメータの値により決定されます。この値により、起動時にOracle Databaseも構成されます。
|
Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|