ヘッダーをスキップ
Oracle Content Database Oracle WebCenter Suite用管理者ガイド
10g（10.1.3.2.0）
E05041-01
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

2 Oracle Content DBの配置計画

この章では、Oracle Content DBの配置を計画する方法を説明します。

この章では、次の項目について説明します。

Oracle Content DBの配置構成

この項では、Oracle Content DBの2種類の配置について説明し、高可用性に関する注意事項を示します。

ここでは、次の内容について説明します。

OC4Jアプリケーションのデプロイ・オプションの詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。

単一コンピュータへの配置

Oracle Content DBは、コンピュータがハードウェアおよびソフトウェアの推奨要件を満たしていれば、単一コンピュータにインストールできます。コンピュータが推奨要件を満たしていないと、この構成のパフォーマンスは満足のいくレベルに達しない可能性があります。ハードウェアおよびソフトウェアの要件の詳細は、Oracle Application Serverのプラットフォーム別インストレーション・ガイドを参照してください。

単一コンピュータへの配置では、Oracle Content DBとすべての必須コンポーネントが単一のコンピュータにインストールされます。コンポーネントには、Oracle Application ServerとOracle Databaseが含まれます。単一コンピュータへの配置では、ロード・バランシングやフェイルオーバーは使用できません。

図2-1は、単一コンピュータ上で稼働するOracle Content DBドメインを示しています。

図2-1 単一コンピュータへのOracle Content DBの配置

図2-1の説明が続きます
「図2-1 単一コンピュータへのOracle Content DBの配置」の説明

図2-1で示すOracle Content DBノード・プロセスの詳細は、「Oracle Content DBノード」を参照してください。

複数コンピュータへの配置

Oracle Content DBは複数のコンピュータに配置できます。この構成では、コンポーネントを分離し、フェイルオーバー、ロード・バランサおよび高可用性オプションを構成することが可能です。複数コンピュータへの配置では、単一コンピュータへの配置の場合よりもハードウェア要件が低いコンピュータを使用できます。ハードウェア要件の詳細は、Oracle Application Serverのプラットフォーム別インストレーション・ガイドを参照してください。

適切なネットワーク・ロード・バランサとコンピュータ構成を使用した場合、Oracle Content DBインスタンスが1台のホストで実行されているのか、複数のホストで実行されているのかがユーザーにはわからないこともあります。ユーザーは、特定のOracle Content DBプロトコル・サーバーに適したクライアント・アプリケーションを使用して、フォルダやドキュメントなどのコンテンツにアクセスします。

図2-2は、Oracle Content DBコンポーネントが3台のコンピュータに分散された、複数コンピュータへの配置の例です。

図2-2 複数コンピュータへのOracle Content DBの配置

図2-2の説明が続きます
「図2-2 複数コンピュータへのOracle Content DBの配置」の説明

図2-2で示すOracle Content DBノード・プロセスの詳細は、「Oracle Content DBノード」を参照してください。

Oracle Content DBエージェントは、一度に1つの中間層でしか実行できません。ただし、エージェントを非アクティブな状態で複数の中間層に配置しておき、エージェントが実行されていた中間層で障害が発生した場合にアクティブ化することは可能です。詳細は、次の項を参照してください。

高可用性に関する注意事項

Oracle Content DBを初めて構成する場合、最初に構成する中間層には、後続の中間層に格納されない重要な構成設定が含まれています。そのため、最初のOracle Content DB中間層を削除した場合、または最初の中間層が停止した場合には、これらの構成設定を別の中間層にリストアする必要があります。

これらの構成設定を次に示します。

  • 削除された、または使用不能になった中間層で一部またはすべてのOracle Content DBエージェントを実行していた場合は、これらのエージェントを別の場所で実行するよう構成する必要があります。これを行うには、別のOracle ContentDB中間層で実行しているノードのノード構成を変更します。詳細は、「ノード構成の変更」を参照してください。また、次の項の「複数の中間層の環境におけるエージェントの高可用性のベスト・プラクティス」も参照してください。

  • IFS.DOMAIN.APPLICATION.ApplicationHostドメイン・プロパティは、特定の中間層（通常は最初に構成された中間層）を指しています。その中間層が削除された、または使用不能になった場合は、別のOracle ContentDB中間層を指すように、このドメイン・プロパティを更新する必要があります。詳細は、「ドメインのプロパティの変更」を参照してください。

  • Oracle MailをSMTPサーバーとして使用し、削除された、または使用不能になった中間層でOracle Mailを実行していた場合は、別のSMTPサーバーを指すようにIFS.DOMAIN.EMAIL.SmtpHostドメイン・プロパティおよびIFS.DOMAIN.EMAIL.SmtpPortドメイン・プロパティを更新する必要があります。詳細は、「ドメインのプロパティの変更」を参照してください。

複数の中間層の環境におけるエージェントの高可用性のベスト・プラクティス

デフォルトでは、すべてのOracle Content DBエージェントは最初に構成された中間層で実行する必要があります。中間層が複数ある場合、Oracle Content DB Webアプリケーションとは別に実行するようにエージェントを構成する必要があります。そうしないと、エージェントが停止し、エージェントが実行されているOC4J_Contentインスタンスを再起動する必要がある場合、Oracle Content DB Webクライアント、WebDAVアクセスおよびWebサービスも停止します。

次の手順に従って、Webアプリケーションとは異なるノードでエージェントを実行します。

  1. 最初の中間層でOracle Content DBをインストールおよび構成します。デフォルトでは、すべてのエージェントおよびWebアプリケーション（EcmHttpServer）がこの中間層で実行されます。

  2. この中間層では、エージェントは実行されたままにしますが、Webアプリケーション（EcmHttpServer）は無効にします。これには、次の手順を実行します。

    1. Application Server Controlに接続し、Content DBのホームページに移動します。これを行う方法の詳細は、「Oracle Content DBのホームページへのアクセス」を参照してください。

    2. Content DBのホームページで、「管理」タブをクリックします。

    3. 表の「ノード構成」行で、「タスクに移動」アイコンをクリックします。

    4. 「ノード構成」ページで、EcmHttpServerが実行されているノード構成の名前をクリックします。

    5. 「ノード構成の編集」ページの「サーバー」セクションで、「アクティブ化/非アクティブ化」をクリックします。

    6. EcmHttpServerを「アクティブなサーバー」リストから「非アクティブなサーバー」リストに移動し、「OK」をクリックします。

    7. 「ノード構成の編集」ページで「OK」をクリックします。

    8. 「クラスタ・トポロジ」ページに戻り、OC4J_Contentインスタンスを選択して「再起動」をクリックします。

  3. 2番目の中間層でOracle Content DBをインストールおよび構成します。デフォルトでは、すべてのエージェントは無効ですが、Webアプリケーション（EcmHttpServer）は実行されます。

  4. 必要に応じて、追加のOracle Content DB中間層をインストールおよび構成します。デフォルトでは、これらの中間層では、すべてのエージェントは無効ですが、Webアプリケーション（EcmHttpServer）は実行されます。

  5. 必要に応じて、Webアプリケーションを実行する中間層に対してロード・バランサを構成します。

Oracle Content DBのサイジング・ガイドライン

この項では、Oracle Content DBのサンプル配置に対するハードウェア要件、および組織にOracle Content DBを配置するために必要なハードウェア構成を決定する計算式について説明します。

ここでは、次の内容について説明します。

ハードウェア要件

Oracle Content DBのハードウェア要件は、主に表2-1に示す要素によって決定します。

表2-1 Oracle Content DBハードウェア要件を決定する主な要素

ハードウェア・リソース 中間層コンピュータの要件の決定要素 データベース・コンピュータの要件の決定要素

CPU

  • 1秒当たりに実行される操作のピーク時の数

  • 1秒当たりに実行される操作のピーク時の数

  • Oracle Text索引付けを使用するかどうか

メモリー

  • 1秒当たりに実行される操作のピーク時の数

  • 同時接続ユーザーのピーク時の数

  • 同時接続ユーザーごとに使用されるセッションの平均数

  • 各フォルダのファイル数

  • 1秒当たりに実行される操作のピーク時の数

  • ファイル数

ディスク・サイズ

適用なし

  • ファイル数

  • ファイルの平均コンテンツ・サイズ（索引付けの使用の有無にかかわらない）

ディスク・スループット

適用なし

  • 1秒当たりに読取りおよび書込みされるファイルのピーク時の数

  • ファイルの平均コンテンツ・サイズ

ハードウェア要件を決定するためには、ユーザーが実行する作業の種類を想定する必要があります。次に示す値は、オラクル社（ユーザー40,000人以上）における配置に基づいて推測される平均値で、一般的なOracle Content DB使用計画に適用できます。

表2-2 ユーザー・プロファイル

ユーザー・タスク 接続ユーザーが毎時に実行する操作の数

フォルダを開く

8

ファイルの読取りまたは書込み

10

問合せ

0.1

このサイジング・ガイドラインは、Sun社のハードウェア上での10,000人の同時接続ユーザーのベンチマークに基づいています。このガイドラインは、従業員数55,000人、ファイル数3,000万、コンテンツ量13TBのオラクル社内における本番環境での使用から得た数値に対しても、検証されています。このシステムでは、Intel Linuxハードウェアを中間層コンピュータに、およびSun社のハードウェアをデータベースに使用しています。


注意:

サイジング・ガイドラインは次のセクションで説明しますが、ユーザー・プロファイルが表2-2で説明した平均数値よりもはるかに大きい場合は、ガイドラインがあてはまらない可能性があります。

各中間層コンピュータのサイジング計算式

この項では、各中間層コンピュータのハードウェア・サイジングの決定に使用する計算式を説明します。表2-3に、サイジング計算式の概要を示します。

表2-3 各中間層コンピュータのOracle Content DBサイジング推奨事項

コンポーネント サイジング推奨事項

CPUの数

切上げ（ピーク時の同時接続ユーザー数/250 + 33%の余裕）

必要な使用可能ディスク領域

Oracle Content DBに500MB以上

コンピュータの合計メモリー（HTTPがプライマリ・プロトコル）

HTTPがプライマリ・プロトコルではない場合: 480MB +（3.6MB * ピーク時の同時接続ユーザー）

コンピュータの合計メモリー（HTTP以外のプライマリ・プロトコル）

HTTPがプライマリ・プロトコルではない場合、または目的のユーザー・プロファイルが表2-2に示す平均値と異なる場合: 480MB +（1MB * ピーク時の同時接続ユーザー * 各同時接続ユーザーが使用する平均セッション数）+（3KB * Javaオブジェクト・キャッシュに想定するオブジェクト数）+（8MB * データベースへの接続数）

CPUの数

次の計算式を使用して、必要なCPUの数を決定します。

roundup(peak concurrent connected users / 250 + 33% headroom)

peak concurrent connected usersパラメータは、Oracle Content DBにログインし、1日のうちのピーク時間帯に操作を実行したユーザーの数を意味します。ユーザー数が不明な場合は、Oracle Content DBのユーザー全体の10%と仮定してください。

headroomパラメータは、使用可能なままにしておく必要があるCPUリソースを意味します。効率を最適化するために、割当てはCPUの75%未満のみとする必要があります。

この計算式は、次の想定に基づきます。

  • 計算式は、Sun SPARC Solaris 400MHz UltraSPARC-IIプロセッサ（2次キャッシュ8MB）と想定します。

  • その他のRISCプロセッサは、周波数に相応の実行性能とします。

  • WindowsまたはLinuxコンピュータのIntel Pentium III以降のプロセッサは、周波数の半分に相応の実行性能とします。たとえば、800MHz Pentiumプロセッサは400MHz RISCプロセッサとほぼ同等です。

必要な使用可能ディスク領域

Oracle Content DBに少なくとも500MBを割り当てます。

コンピュータの合計メモリー（HTTPがプライマリ・プロトコル）

HTTPがプライマリ・プロトコルの場合、次の計算式を使用して、必要なコンピュータのメモリーを決定します。

480MB + (3.6MB * peak concurrent connected users)

480MBは、最初のOracle Content DB中間層コンピュータ用です。3.6MBという値は、次の仮定に基づいて計算されています。

  • 同時接続ユーザー当たり1.6セッション: Oracle Content DBのプライマリ・インタフェースがHTTPノードによるとします。追加の0.6セッションは、Oracle Content DB Webクライアント・ユーザーが別のOracle Content DB Webクライアントを開始する、またはユーザーがWebフォルダまたはOracleドライブにアクセスすると開始するHTTPセッションです。

  • 同時接続ユーザー当たり0.1接続プールの接続: 前述のユーザー・プロファイルに基づきます。

  • 同時接続ユーザー当たりJavaデータ・キャッシュに400オブジェクト: 前述のユーザー・プロファイルに基づき、フォルダ当たり50ファイル、1時間当たり8フォルダを開くとします。

コンピュータの合計メモリー（HTTP以外のプライマリ・プロトコル）

HTTPがプライマリ・プロトコルではない場合、または目的のユーザー・プロファイルが表2-2に示す平均値と異なる場合、次の計算式を使用して、必要なコンピュータのメモリーを決定します。

480MB + (1MB * peak concurrent connected users * average number of sessions in use by each concurrent connected user) + (3KB * number of objects desired in the Java object cache) + (8MB * number of connections to the database)

480MBは、最初のOracle Content DB中間層コンピュータ用です。他の値は次の仮定に基づいて計算されています。

  • 1MBという値は、高く設定されています。Oracle Content DBは、中間層メモリーを使用して項目をキャッシュすることにより、データベースCPUロードを削減するように最適化されています。その結果、データベース・コンピュータがさほどスケーラビリティのボトルネックにならず、また1プロセッサまたは2プロセッサの中間層コンピュータのメモリーは、ハイエンド・データベース・コンピュータ（大容量の接続記憶装置や多数のプロセッサを搭載するコンピュータ）のメモリーまたはCPUよりも安価なため、システムをよりスケーラブルで安価にできます。

  • サービス構成のIFS.SERVICE.MaximumConcurrentSessionsパラメータで、ピーク時の同時ユーザーのセッション数を制限することをお薦めします。オラクル社では、最大2GBのJavaヒープでテスト済です。次の点に合致する場合、この制約により、1ノード当たり最大約700の同時接続ユーザー、および1986MBの合計サイズになると考えられます。

    • 各ユーザーが使用するセッションが1.6

    • 各セッションが1MB（700 * 1.6 * 1MB = 1,120MB）

    • 各ユーザーが必要とするJavaデータ・キャッシュ・オブジェクトが400

    • 各オブジェクトのサイズが3KB（700 * 400 * 3KB = 866MB）

    HTTP/WebDAVメモリーのオーバーヘッドは、10の同時ゲスト・ユーザー・リクエストに対するメモリーを含みます。そのため、ゲスト・ユーザーはHTTP/WebDAVアクセスの接続ユーザーとして計算しないでください。

  • 各同時接続ユーザーが使用する平均セッション数に対して、HTTPノードには値1.6を使用します。

  • 次の計算式を使用して、Javaオブジェクト・キャッシュに想定するオブジェクト数を計算します。

    (number of folder opens in the peak hour) * (number of objects per folder) * (number peak concurrent connected users)

    この結果を使用して、IFS.SERVICE.DATACACHE.Sizeパラメータの値を設定してください。

  • データベースへの接続数は、実行中の同時読取りまたは書込みの操作数に基づきます。標準ユーザー・プロファイルを使用する場合、ユーザー当たりのデータベース接続数を0.1に想定します。これは、各サービスに対するパラメータIFS.SERVICE.CONNECTIONPOOL.WRITEABLE.MaximumSizeとIFS.SERVICE.CONNECTIONPOOL.READONLY.MaximumSizeとの合計です。

中間層メモリーの詳細は、「サービス構成およびJavaメモリーのサイズ設定」を参照してください。

データベース・コンピュータのサイジング計算式

この項では、Oracle Content DBユーザーが使用する各データベース・コンピュータのハードウェア・サイジングの決定に使用する計算式を説明します。表2-4に、サイジング計算式の概要を示します。

表2-4 各データベース・コンピュータのOracle Content DBサイジング推奨事項

コンポーネント サイジング推奨事項

CPUの数

切上げ（ピーク時の同時接続ユーザー数/250 + 33%の余裕）

必要な使用可能ディスク領域

4.5GB +生ファイルの合計サイズ+（生ファイルの合計サイズ* 20%）

コンピュータの合計メモリー

64MB + 128MB +データベース・バッファ・キャッシュ+（1MB *データベースへの接続数）+（500バイト*ファイルの数）+（100KB *ピーク時の同時接続ユーザー数）

CPUの数

次の計算式を使用して、必要なCPUの数を決定します。

roundup(peak concurrent connected users / 250 + 33% headroom)

peak concurrent connected usersパラメータは、Oracle Content DBにログインし、1日のうちのピーク時間帯に操作を実行したユーザーの数を意味します。ユーザー数が不明な場合は、Oracle Content DBのユーザー全体の10%と仮定してください。

headroomパラメータは、使用可能なままにしておく必要があるCPUリソースを意味します。効率を最適化するために、割当てはCPUの75%未満のみとする必要があります。Oracle Text索引付けを使用する場合、バックグラウンドでのOracle Textによる新規ファイル・コンテンツの索引付け用に、追加CPUを1つ使用します。

この計算式は、次の想定に基づきます。

  • 計算式は、Sun SPARC Solaris 400MHz UltraSPARC-IIプロセッサ（2次キャッシュ8MB）と想定します。

  • その他のRISCプロセッサは、周波数に相応の実行性能とします。

  • WindowsまたはLinuxコンピュータのIntel Pentium III以降のプロセッサは、周波数の半分に相応の実行性能とします。たとえば、800MHz Pentiumプロセッサは400MHz RISCプロセッサとほぼ同等です。

必要な使用可能ディスク領域

次の計算式を使用して、必要な使用可能ディスク領域を決定します。

4.5GB + total raw file size + (total raw file size * 20%)

4.5GBは、Oracleソフトウェアおよび初期データベース構成に必要な領域です。Oracle Textを使用してコンテンツを索引付けしない場合、生ファイルの合計サイズに20%のかわりに15%を掛けます。

次の点に考慮すると、データベース・コンピュータに必要な使用可能ディスク領域の量を増加できます。

  • バックアップおよび信頼性のためのミラー化

  • REDOログ・サイズ（挿入するファイル数とそのサイズにより決定）

  • 各データベースの最後のエクステントの未使用部分（事前作成したデータベース・ファイルで発生する未使用部分、または次のエクステント設定が大きい場合に大きくなることがある未使用部分）

コンピュータの合計メモリー

次の計算式を使用して、必要なコンピュータのメモリーを決定します。

64MB + 128MB + database buffer cache + (1MB * number of connections to the database) + (500 bytes * number of files) + (100KB * peak concurrent connected users)

この計算式は、次の想定に基づきます。

  • 128MBは、小規模なOracle Serverの実行に必要な最小のメモリーです。

  • ファイルの数: 約50,000ファイルに対するデータベース・バッファ・キャッシュは、デフォルトのOracleデータベース構成で十分です。50,000ファイルを超える配置の場合、ワイルドカード・ファイル名検索を含めて、パフォーマンスの最適化のためにファイル当たり500バイトを割り当てます。ユーザーがワイルドカード・ファイル名検索を実行しない場合は、この数値を減らしてください。

  • 前述のユーザー・プロファイルに基づいた同時接続ユーザー当たりに0.1データベース接続が必要であると推定して、100KBを計算しています。各データベース接続に必要なデータベース・メモリーは、約1MBです。

メモリーの要件: サンプル配置

表2-5に、各中間層コンピュータ上のおおよその最小メモリー・オーバーヘッドを示します。

表2-5 メモリー・オーバーヘッド

説明 中間層コンピュータのおおよその最小メモリー（MB）

オペレーティング・システムがコンピュータのブート時に使用するメモリー。

60

最初のJava仮想コンピュータ（JVM）のオーバーヘッド。

30

Application Server Control。各中間層で実行する必要がある。

150

Oracle HTTP Server（デフォルトのHTTPデーモンを含む）。Oracle Content DB Webクライアント、HTTP、WebフォルダおよびOracle Driveへのアクセスに必要。

30

Oracle Content DB OC4Jプロセス。Oracle Content DB Webクライアント、HTTP、WebフォルダおよびOracle Driveへのアクセスに必要。Oracle HTTP Serverと対にする必要がある。

180

合計

450

Oracle Content DBの表領域

ここでは、Oracle Content DB表領域の次の項目について説明します。

データベース・タイプおよびストレージ要件

表2-6に、Oracle Content DBに格納する様々なデータのタイプおよび各表領域の使用目的を示します。各表領域の詳細は、以降の項で説明します。

表2-6 表領域の定義

表領域のタイプ 表領域名 説明

ファイル・ストレージ

CONTENT_IFS_LOB_I

テキストやワード・プロセッシング・ファイルなどのOracle Textで索引付け可能なファイルのラージ・オブジェクト（LOB）・データを格納します。

ファイル・ストレージ

CONTENT_IFS_LOB_N

zipファイルなどのOracle Textで索引付けしないファイルのLOBデータを格納します。

ファイル・ストレージ

CONTENT_IFS_LOB_M

画像、オーディオ、ビデオ・ファイルなどのOracle interMediaで索引付け可能なファイルのLOBデータを格納します。

Oracle Text

CONTENT_IFS_CTX_I

Oracle TextがOracle Content DBファイルから抽出した単語（トークン）を格納します（Oracle表DR$IFS_TEXT$I）。

Oracle Text

CONTENT_IFS_CTX_X

Oracle TextトークンのOracle B*ツリー索引を格納します（Oracle索引DR$IFS_TEXT$X）。

Oracle Text

CONTENT_IFS_CTX_K

各種のOracle Text表を格納します（Oracle表DR$IFS_TEXT$K、DR$IFS_TEXT$N、DR$IFS_TEXT$R）。

メタデータ

CONTENT_IFS_MAIN

ファイル、ユーザーとグループ情報およびその他のOracle Content DBオブジェクト・データのメタデータを格納します。

Oracle Workflow

WORKFLOW_IFS_MAIN

Oracle Workflowのデータを格納します。

一般Oracleストレージ

その他

Oracleデータ辞書、トランザクション中の一時データなどを格納するSYSTEM、ROLLBACK、TEMPおよびその他の表領域。

標準的な表領域の記憶域およびディスクI/Oの詳細を、表2-7に示します。

表2-7 表領域の記憶域の要件およびディスクI/O

表領域 I/Oスループット要件の合計に対する割合 ディスク領域の要件に対する割合

CONTENT_IFS_MAIN

50%

2%

CONTENT_IFS_CTX_X

20%

1%

CONTENT_IFS_CTX_I

10%

1%

CONTENT_IFS_LOB_I

7%

34%

CONTENT_IFS_LOB_N

5%

55%

その他

5%

1%

CONTENT_IFS_LOB_M

1%

4%

CONTENT_FS_CTX_K

1%

1%

WORKFLOW_IFS_MAIN

1%

1%

合計

100%

100

表2-7の内容について、次の点に注意してください。

  • I/Oの割合は、db_cache_sizeのサイズに大きく依存します。この数値は、8GBのdb_cache_size、1,700万のファイルおよび40,000人の名前付きユーザーを有するオラクル社内部の実装に基づきます。

  • CONTENT_IFS_MAIN表領域は、最大限のI/O容量でディスク全体に展開するための最も重要な表領域です。

  • CONTENT_IFS_CTX_I、CONTENT_IFS_CTX_XおよびCONTENT_IFS_CTX_K表領域のディスクI/Oの大部分は、Oracle Textバッチ・プロセス（ctx_ddl.sync_indexおよびctx_ddl.optimize_index）から生成されるため、エンド・ユーザーのパフォーマンスには重要ではありません。必要な場合は、これらの表領域は低いI/O容量でディスク上に存在できます。

ファイルのOracleデータベースへの格納

ディスク領域は、Oracle Content DB内のファイルを実際に格納するディスクで最も多く消費されます（CONTENT_IFS_LOB_I表領域、CONTENT_IFS_LOB_N表領域およびCONTENT_IFS_LOB_M表領域）。この項では、ファイルを格納する方法およびこれらのファイルに必要な領域を計算する方法を説明します。

前述したとおり、Oracle Content DBに格納されたファイルは、実際にはデータベース表領域に格納されます。Oracle Content DBは、Oracle Databaseのラージ・オブジェクト（LOB）機能を使用します。すべてのファイルは、バイナリ・ラージ・オブジェクト（BLOB）として格納されます。BLOBは、データベースで提供されるLOBのタイプの1つです。LOBでは、データベースに格納された通常のデータと同様のトランザクション・セマンティクスが提供されます。これらのセマンティクスを完了するために、LOBは個々に変更およびリカバリ可能なピースに小さく分割されます。これらの小さいピースは、チャンクと呼ばれます。チャンクは、LOB列が含まれる表領域の1つ以上の連続したデータベース・ブロックのグループです。

データベース・ブロックおよびそれらのブロックに含まれるチャンクの情報（BlockOverhead）の両方によって、格納されるデータにオーバーヘッドが課せられます。現在、BlockOverheadは1ブロック当たり60バイトで、ブロック・ヘッダー、LOBヘッダーおよびブロック・チェックサムで構成されます。Oracle Content DBは、チャンク・サイズが32KBのLOBを構成します。

たとえば、データベースのDB_BLOCK_SIZEパラメータが8192（8KB）に設定されていると想定します。1つのチャンクには4つの連続したブロックが必要であり、240バイトのオーバーヘッドが課せられます。1つのチャンク内で使用可能な領域は、32768-240=32528バイトになります。

Oracle Content DBに格納される各ドキュメントは、整数のチャンクで構成されます。前述の例を使用すると、たとえば、500KBのドキュメントでは、実際には512000/32528=15.74=16のチャンクが使用されます。16のチャンクによって、16*32K=524288バイトが使用されます。このファイルを格納するためのチャンクのオーバーヘッドは524288-512000=12288となり、これは元のファイル・サイズの2.4%に当たります。

Oracle Content DBによって使用されるチャンク・サイズは、ファイルへのアクセス時間を最適化するように設定されます。ファイルに1つ以上のチャンクを使用する必要があるため、1つのチャンクのサイズより小さいファイルの場合、ディスク領域に対するオーバーヘッドの割合が大きくなります。

LOB上でトランザクション・セマンティクスに必要なもう1つの構造は、LOB索引です。1つのLOB索引エントリで、特定のLOBオブジェクトの8つのチャンクを示すことができます（NumLobPerIndexEntry=8）。前述の例では、500KBのファイルによって16のチャンクが使用されるため、このオブジェクトには2つの索引エントリが必要です。各エントリによって46バイト（LobIndexEntryOverhead）が使用されます。これらの各エントリはOracle B*ツリー索引に格納され、索引の断片化の度合いに応じて、固有のオーバーヘッドが課せられます。

LOB領域の使用率に影響する最後の要因は、LOB列の作成時に使用されるPCTVERSIONパラメータです。PCTVERSIONの動作の詳細は、『Oracle Database SQLリファレンス』を参照してください。

Oracle Content DBは、作成するLOB列に対して、デフォルトで20%のPCTVERSION値を使用します。これによって、読取り一貫性ビューで「ORA-22924 スナップショットが古すぎます。」というエラーが発生する可能性が減ります。デフォルトでは、PCTVERSIONチャンクを永続的に使用するには、予測されるディスク使用量に20%以上のチャンク領域を追加する必要があります。

ディスク領域が問題となる大規模なシステムの場合、PCTVERSIONパラメータを1に設定し、ディスク・ストレージの要件を小さくしてください。この操作は、次のSQLコマンドを使用して、実行中のシステムに対していつでも実行できます。

alter table odmm_contentstore modify lob (globalindexedblob) (pctversion 1);
alter table odmm_contentstore modify lob (emailindexedblob) (pctversion 1);
alter table odmm_contentstore modify lob (emailindexedblob_t) (pctversion 1);
alter table odmm_contentstore modify lob (intermediablob) (pctversion 1);
alter table odmm_contentstore modify lob (intermediablob_t) (pctversion 1);
alter table odmm_nonindexedstore modify lob (nonindexedblob2) (pctversion 1);




LOB表領域の使用量を計算するには、次の手順を実行します。




    

  1. 


    1チャンク当たりのブロック数を計算し、次にチャンク・サイズからBlockOverhead（60バイト）の合計を引いて、ファイルが使用するチャンク数を求め、チャンク当たりの使用可能な領域を計算します。
    

    2. 

  2. 


    次の計算式を使用して、ファイル・サイズをチャンク当たりの使用可能な領域で割り、チャンクの数を計算します。
    

    chunks = roundup(FileSize / ChunkSize=((ChunkSize/BlockSize) * BlockOverhead)))


    


    たとえば、FileSize = 100,000、ChunkSize = 32768、Blocksize = 8192およびBlockOverhead = 60の場合、次のようになります。
    

    roundup(100000 / (32768 - ((32768 / 8192) * 60))) = 4 chunks


    3. 

  3. 


    チャンク数にチャンク・サイズを掛けて、その結果にPCTVERSION因数を掛け、次にNumLobPerIndexEntry（8）およびLobIndexEntryOverhead（46バイト）を足して、ファイルのディスク領域を計算します。
    

    FileDiskSpaceInBytes = roundup(chunks * ChunkSize * PCTVERSIONFactor) + roundup(chunks / NumLobPerIndexEntry * LobIndexEntryOverhead)


    


    chunks = 4、ChunkSize = 32768、PCTVERSIONFactor = 1.1、NumLobPerIndexEntry = 8およびLobIndexEntryOverhead = 46の場合、次のようになります。
    

    roundup(4 * 32768 * 1.1) + (roundup(4 / 8) * 46)= 144226 FileDiskSpaceInBytes


    4. 

  4. 


    次の計算式を使用して、前述の式をLOBに格納される各ファイルに対して適用した結果を合計し、ファイル・ストレージに使用されるディスク領域の総量を計算します。
    

    TableSpaceUsage = sum(FileDiskSpaceInBytes)


    


    格納するすべてのファイルに対して行います。
    

    5. 




Oracle Content DBは、複数のLOB列を作成します。表領域に格納されるコンテンツの量に基づいて、各表領域の領域計算を実行する必要があります。
 

  



Oracle Content DBのメタデータおよびインフラストラクチャ



Oracle Content DBサーバーは、ファイル・システムに関する永続的な情報、およびそのファイル・システムのコンテンツをデータベース表に保持します。これらの表および関連付けられた構造は、CONTENT_IFS_MAIN表領域に格納されます。この表領域は、約300の表および500の索引を含みます。これらの構造は、ファイル・システム、およびそのファイル・システムを使用する様々なプロトコルおよびユーザー・インタフェースの両方をサポートするために必要です。



この領域を管理および計画する作業は、通常のOracle Databaseのインストール操作とほとんど同様です。システム管理者は、この表領域から使用されるファイルごとに約6Kのオーバーヘッドを計画するか、またはコンテンツ全体の約2%に相当するオーバーヘッドを計画する必要があります。カテゴリなどの多数のカスタム・メタデータが存在する場合、オーバーヘッドはさらに大きくなります。



この表領域に割り当てられた初期ディスク領域は、デフォルトのインストール時で、約50MBです。50MBのうち、16MBがインストールの完了時に実際に使用されています。これには、すべての必要な表、索引、およびインストールの一部としてOracle Content DBにロードされる約700ファイルに必要なメタデータのインスタンス化が含まれます。この表領域内のそれぞれの表および索引の増加率は、個々のインストールで使用されるOracle Content DBの機能に応じて異なります。
 

  



Oracle Text



Oracle Content DBとOracle Textを併用すると、ユーザーはOracle Content DB内に格納されたファイルに対する強力な検索機能を使用できます。この機能のディスク領域は、パフォーマンスを最適化するために3つの個別の表領域に分割されています。



CONTENT_IFS_CTX_I表領域には、索引付けされた様々なファイル内に存在するテキスト・トークン（個別のワード）を保持する表が含まれます。これらのテキスト・トークン用のストレージは、ファイルのASCIIコンテンツの大きさにほぼ比例します。



ASCIIコンテンツの割合は、元のファイルの形式によって異なります。テキスト・ファイルでは、ASCII以外のコンテンツが空白のみであるため、1つのファイルに対するオーバーヘッドの割合が大きくなります。Microsoft WordやPowerPointなどのファイル・タイプには、テキスト・トークンとして扱われない、書式設定に必要な大量のデータが含まれます。そのため、これらのタイプのファイルでは、1つのドキュメントに対するオーバーヘッドの割合が小さくなります。様々なコンテンツ・タイプが含まれるシステムでは、予測されるオーバーヘッドは、索引付けされたファイルの元のサイズの約8%です。



表2-8で、一般的な形式のファイルにおけるASCIIテキストの容量のガイドラインを示します。
 



表2-8 ファイル・タイプ別の平均ASCIIコンテンツ






形式
プレーンASCIIコンテンツ（ファイル・サイズの割合）
すべてのファイル・コンテンツの標準的な割合脚注1









Microsoft Excel脚注2





250%





4%









ASCII





100%





2%









HTML





90%





10%









リッチ・テキスト形式





80%





2









Microsoft Word





70%





13%









Acrobat PDF





10%





18%









Microsoft PowerPoint





1%





3%









イメージ（JPEG、BMP）、圧縮ファイル（Zip、TAR）、バイナリ・ファイルなど





0%





50%









合計





 
 




100%






 




脚注1オラクル社におけるOracle Content DBの内部利用の統計より。



脚注2デフォルトで、Oracle TextはExcelファイル内の各数値を別個の単語として索引付けします。ExcelはASCIIに比べてより効率的に数値を格納するため、ASCIIコンテンツのファイル・サイズの割合は、100%を超えます。



CONTENT_IFS_CTX_K表領域には、ファイルのOracle Content DBロケータ（Oracle Content DB DocID）から同じファイルのOracle Textロケータ（Oracle Text DocID）に変換する必要がある表および索引が含まれます。この表領域で予測される領域の使用量は、索引付けされたファイル当たり約70バイトです。



CONTENT_IFS_CTX_X表領域には、CONTENT_IFS_CTX_I表領域に格納されるテキスト・トークン情報に対して使用されるB*ツリー・データベース索引が含まれます。このデータベース索引は、CONTENT_IFS_CTX_I表領域と同様に、ASCIIコンテンツに比例して大きくなります。様々なコンテンツ・タイプが含まれるシステムでは、予測されるオーバーヘッドは、ファイルのASCIIコンテンツの約4%、または索引付けされたファイルのサイズの約1%です。
 

  



ディスク領域の要件: サンプル配置



この項では、ディスク領域の様々な要件を示し、サーバーにファイルを追加した場合に必要なディスク領域がどのように増加するかを説明します。



オラクル社の社内利用においてOracle Content DBを実行した実績に基づき、大規模システム（数百GBのファイル・コンテンツ）のOracle Content DBのディスク・オーバーヘッドを、表2-9に示します。
 



表2-9 ディスク領域の要件の概要






表領域のオーバーヘッドのタイプ
生ファイル・コンテンツの合計に対するオーバーヘッド脚注1
主な決定要因









ファイル・ストレージ





12%





チャンク・サイズ（デフォルト32KB）を基準にしたファイル・サイズ









Oracle Text





5%





すべてのファイルのASCIIコンテンツの量









メタデータ





2%





フォルダ、ファイルなどの数









一般Oracleストレージ





1%





TEMP、UNDOおよびその他の表領域の固定化した構成不可のデータベース設定









合計





20%





適用なし






 




脚注1バックアップおよび信頼性のためのミラー化、挿入するファイル数およびそのサイズにより決定されるREDOログ・サイズ、各データベース・ファイルの最後のエクステントの未使用部分（事前作成したデータベース・ファイルを使用すると発生、または次のエクステント設定が大きい場合に大きくなることがある）は、これに含まれません。



ラージ・オブジェクト、表領域、チャンク・サイズおよびエクステントの用語の説明は、『Oracleデータベース概要』を参照してください。



オーバーヘッドの多くの割合をLOBオーバーヘッドが占める場合、Oracle Content DBインスタンスのオーバーヘッドは、ファイルの平均値および中間値によって異なることに注意してください。
 





 













 
戻る
 戻る 		
次へ
 次へ		











 
目次
 目次		
索引
 索引