12 Oracle Content DBのメンテナンスおよびチューニング

この章では、現行のシステムのメンテナンス、パフォーマンスのチューニングおよびリカバリに関する情報を示します。本番システムと同様に、Oracle Content DBの実装にも基本的な障害時リカバリ計画を含める必要があります。

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

バックアップおよびリカバリ
サービス構成およびJavaメモリーのサイズ設定
パフォーマンスのチューニング
パフォーマンスの問題の分析

バックアップおよびリカバリ

アップグレード、新しいデータの移行または他の主要な変更を行う前に、システムをバックアップする必要があります。

Oracle Database層: Oracleデータベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。次の点に注意してください。
- Oracle Content DBスキーマに加えて、他のシステムへの接続を安全に行うための特殊なスキーマCONTENT$CMがあります。システムをバックアップする場合は、必ずこのスキーマも含めてください。
- Oracle WorkflowスキーマOWF_MGRを必ずバックアップしてください。
- BFILEを使用する場合は、それらも必ずバックアップしてください。
Oracle Content DB中間層: この中間層にはバックアップおよびリカバリ・ツールはありません。中間層をバックアップする場合は、Oracleホームを完全にコピーしてください。また、oraInventoryディレクトリを中間層コンピュータにコピーしてください。

サービス構成およびJavaメモリーのサイズ設定

Oracle Content DBでは、サービスに接続できるライブラリ・セッションの最大数はデフォルトのサービス構成で指定されています。ライブラリ・セッションの数を制限すると、OC4J_Content.default_island.1またはapplication.logファイルでメモリー・エラーが発生する可能性が減少します。

ライブラリ・セッションの最大数を制限すると、次のエラーが発生する可能性があります。

Oracle Content DB Webクライアント: 「現在のセッション数が、最大値に達しました。リクエストを後で再試行してください。」
OC4J_Content.default_island.1またはapplication.log: 「IFS-20127: サービスがビジー状態です(最大同時セッション)。」

いずれかのエラーが発生した場合は、サービス構成を小から中に、または中から大に変更します。また、カスタム・サービス構成を作成することもできます。大のサービス構成を使用する場合、またはカスタム・サービス構成を作成する場合は、-Xmx設定を調整する必要があります。

OC4J_Content.default_island.1ファイルまたはapplication.logファイルにjava.lang.OutOfMemoryエラーが記録された場合も、-Xmx設定を調整する必要があります。

表12-1に、-Xmx設定の変更が必要になる要因を示します。

表12-1 Xmx設定

サービス構成	IFS.SERVICE. Maximum ConcurrentSessionsの設定	予測されるPCCU	Xmx（Java最大メモリー）の推奨サイズ	デフォルトのXmx設定（256MB）を変更する必要があるか
小	40	25	64MB	いいえ
中	70	45	162MB	いいえ
大	200	125	430MB	はい

注意:

PCCUはPeak Concurrent Connected Usersの略です。PCCUは、Oracle Content DBにログインし、1日のうちのピーク時間帯に操作を実行したユーザーの数を意味します。ピーク時間のユーザー数が不明な場合は、Oracle Content DBのユーザー全体の10%と仮定してください。

カスタム・サービス構成の作成方法の詳細は、「サービス構成の作成」を参照してください。ノードのサービス構成を変更する方法の詳細は、「ノード構成の変更」を参照してください。

Xmx設定の計算

Xmx設定を計算する際の一般的なガイドラインは次のとおりです。

Xmx = PCCU * 2.8MB

次の式を使用して、より正確な値を決定することもできます。

Xmx = (PCCU * 1.6 sessions per PCCU * 1MB per session) + (DATACACHE.Size * 3KB per data cache object) + (20% JVM overhead for garbage collection)

Xmx設定の最大値は、オペレーティング・システムによって異なります。Linuxオペレーティング・システムの場合、2GBを超える値は設定できません。Solarisオペレーティング・システムの場合、4GBを超える値は設定できません。Oracle Content DBのXmx設定は2GB以下とすることをお薦めします。

Xmx設定の変更方法の詳細は、「ノードのJavaパラメータの調整」を参照してください。

サービス構成設定の調整

ピーク時の同時接続ユーザー数（PCCU）が125を超えると予測される場合は、次の推奨式を使用して、カスタム・サービス構成を作成してください。

MaximumConcurrentSessions = 1.6 * PCCU DATACACHE.Size = 400 * PCCU DATACACHE.EmergencyTrigger =
 0.80 * DATACACHE.Size DATACACHE.UrgentTrigger = 0.75 * DATACACHE.Size DATACACHE.NormalTrigger =
 0.65 * DATACACHE.Size DATACACHE.PurgeTarget = 0.55 * DATACACHE.Size CONNECTIONPOOL.WRITEABLE.MaximumSize =
 0.05 * PCCU CONNECTIONPOOL.WRITEABLE.TargetSize = 0.04 * PCCU CONNECTIONPOOL.WRITEABLE.MinimumSize = 5 
CONNECTIONPOOL.READONLY.MaximumSize = 0.05 * PCCU CONNECTIONPOOL.READONLY.TargetSize = 0.04 * PCCU 
CONNECTIONPOOL.READONLY.MinimumSize = 5

一般的に、サービス構成のその他の設定を調整する必要はありません。

パフォーマンスのチューニング

通常、パフォーマンスは、ネットワークのI/O、ハードディスク・ドライブのI/O、メモリー（ランダム・アクセス・メモリー）のI/O、またはこれらの3つまたは他の要因の組合せの影響を受けます。要因の1つを調整することで、別の場所でパフォーマンスの問題が発生する場合があるため、チューニング作業は論理的な方法で行う必要があります。

ドキュメント格納のための適切な領域の計算方法の詳細は、次の項で説明する内容に加え、「ファイルのOracleデータベースへの格納」および「Oracle Content DBのメタデータおよびインフラストラクチャ」を参照してください。

パフォーマンス・チューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

Oracle Content DBのanalyze.sqlスクリプトの実行

Oracle Content DBは、Oracle Databaseのコストベース・オプティマイザ（CBO）を使用して、SQL文を実行する最も効率的な方法を判別します。CBOを適切に動作させるには、Oracle Content DBの標準操作の一環としてOracle Content DBのanalyze.sqlスクリプトを実行する必要があります。特にデータに大量の変更が加えられた後（多数のファイルがデータベース・インスタンスにロードされた後など）に必要です。このスクリプトは、CBOがSQL文を実行する最も効率的な方法を選択できるように、Oracle Content DBでのデータの内訳に関する統計を生成します。コストベース・オプティマイザの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

システムのパフォーマンスが低下しないように、スクリプトはビジー状態でない期間に実行します。

analyze.sqlスクリプトを実行すると、DBMS_STATSパッケージがコールされ、スキーマ統計がバックアップ表にエクスポートされます。そのため、必要に応じて、後で統計をリストアできます（次の項の「以前の統計のリストア」を参照）。スクリプトを実行するには、まず、SQL*Plusクライアントがインストールされていることを確認します。次に、コマンドラインに次のコマンドを入力します。

cd ORACLE_HOME/content/admin/sql
sqlplus content_db_schema/password@connect_string @analyze.sql content_db_schema

Oracle Content DBに多数のドキュメントが含まれる場合、このスクリプトの実行には時間がかかる場合があります。

以前の統計のリストア

新しい統計を収集する前に、analyze.sqlスクリプトによってバックアップ統計がIFS_BACKUP_STATS表にエクスポートされ、一連の統計にタイムスタンプが指定されます。次のSQL文を実行すると、保存された既存の統計について表を問い合せることができます。

SQL> select distinct statid from IFS_BACKUP_STATS;

次の問合せでは、統計ID（日時スタンプ）ごとにすべての統計のリストが戻されます。次に例を示します。

STATID
------------------------------
01-MAY-02 02:15.36
04-MAY-02 20:00.15
08-MAY-02 02:15.48
11-MAY-02 06:21.40
11-MAY-02 20:15.37

パフォーマンスが低下する前の日時の統計をリストアできます。たとえば、午後8時にanalyzeスクリプトを実行して統計を使用した後にパフォーマンスの低下が認められた場合、次のようにして、その時点より前の時点から統計をリストアできます。

SQL> call dbms_stats.import_schema_stats (content_db_schema,
'IFS_BACKUP_STATS', '08-MAY-02 06:21.40',content_db_schema);

統計をリストアすることで、以前にSQL文を実行した方法に戻すように、CBOに指示することになります。

パフォーマンスの問題の分析

統計を適切に実行し、ハードディスクに表領域をサポートするために十分な空き領域があることを確認した後も、パフォーマンスの問題が発生する場合があります。パフォーマンスの問題が発生した場合、パフォーマンスのボトルネックの原因が、Oracle Databaseにあるか、Oracle Content DBにあるか、または別の原因があるのかを判別する必要があります。

問題を特定するには、まず、実行中のプロセスおよびこれらのプロセスによって使用されているリソースの数を調べます。

問題を再現し、top（UNIXの場合）を実行するか、タスクマネージャ（Windowsプラットフォームの場合）を開始します。
この状態で、Javaプロセス、Oracleシャドウ・プロセス、I/Oまたはこれらの組合せのどれがボトルネックであるかを判別します。

データベースが問題の原因である場合

Oracleシャドウ・プロセスが問題である場合、Statspackユーティリティを使用して、バッファ取得数が最大になるSQL文を特定し、このSQL文に対してEXPLAIN PLANを実行します。

全表スキャンが表示される場合、オプティマイザが適切な計画を選択していないことが問題の原因である可能性があります。この問題をオラクル社カスタマ・サポート・センターに報告してください。問題を特定するには、追加の作業を行う必要があります。

StatspackユーティリティおよびEXPLAIN PLANの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

Javaプロセスが問題の原因である場合

メモリーが不足している可能性があります。たとえば、ログにjava.lang.OutOfMemoryErrorエラーが示されている場合は、そのJVMの最大メモリー（Xmx）設定を大きくします。Xmx設定の変更の詳細は、「ノード構成の変更」を参照してください。

レスポンス時間が長いという問題がユーザーに対して発生している場合、およびtop（UNIXの場合）または同等の機能（たとえば、Windowsプラットフォームのタスクマネージャ）でCPUの100%を使用して1分以上実行しているJavaプロセスが示される場合、JavaのXmx設定が小さすぎる可能性があります。

冗長ガベージ・コレクション（verbosegc）をオンにします。これを行うには、ノード構成のJavaパラメータを編集します。詳細は、「ノードのJavaパラメータの調整」を参照してください。

ノード・ログ・ファイルで、ガベージ・コレクションに関連する出力は、次のように表示されます。
```
[Full GC 1476K->1476K(2112K), 0.0549430 secs]
```
フルGCは、ガベージ・コレクタがnursery内の使用可能なすべてのメモリーを使用し、メモリーを再生するために残りのヒープを使用する必要がある場合に発生します。
フルGCが（起動直後以外に）10分以内に2回以上発生する場合、JVMのXmx設定を大きくします。

キャッシュ 統計の表示とキャッシュ設定の変更

問題がOracle Content DBのJavaプロセスである場合は、次のようにApplication Server Controlを使用して、まずOracle Content DBサービスのキャッシュ・ヒット率を確認します。

Application Server Controlに接続し、Content DBのホームページに移動します。これを行う方法の詳細は、「Oracle Content DBのホームページへのアクセス」を参照してください。
サービスの名前（IfsDefaultServiceなど）をクリックします。「サービス」ページが表示されます。
「パフォーマンス」タブをクリックします。
「コミット済データ・キャッシュ統計」セクションに、キャッシュ・サイズ、キャッシュ・プット、キャッシュ削除、キャッシュ・パージ、キャッシュ・パージ・サイクル、キャッシュ参照およびキャッシュ・ヒット率のリアルタイム・データが表示されます。

目的は、高い確率の（できるかぎり100%に近い）キャッシュ・ヒットを得ることです。サービスのキャッシュ・ヒットの割合が98%未満の場合、コミット済データ・キャッシュのサイズが小さすぎる可能性があります。

統計エージェントはリアルタイム・データを取得するため、ノード・ログまたはアプリケーション・ログを表示すれば、以前の統計も確認できます。このエージェントを構成して、Oracle Content DBリポジトリに格納されたドキュメントに統計を書き込むこともできます。統計エージェントについては、「統計エージェント」を参照してください。
実行時のキャッシュ設定を変更するには、「管理」タブをクリックします。
表の「データ・キャッシュ」行で、「タスクに移動」アイコンをクリックします。
すべてのキャッシュ設定（キャッシュ容量、通常パージ・トリガー、至急パージ・トリガー、緊急パージ・トリガー、パージ・ターゲット）を同じ割合で増やし、「適用」をクリックします。

これによって、中間層コンピュータ上でのメモリー使用量が1オブジェクト当たり約3KB増加します。たとえば、キャッシュ容量を5000増やした場合、メモリー使用量が15MB増加します。

永続的に変更するには、サービス構成を更新します。詳細は、「サービス構成の変更」を参照してください。

接続プール統計の表示と接続プール設定の変更

Application Server Controlを使用して、読取り専用接続プールおよび書込み可能接続プールのターゲットと最大接続数を次のように確認します。

Application Server Controlに接続し、Content DBのホームページに移動します。これを行う方法の詳細は、「Oracle Content DBのホームページへのアクセス」を参照してください。
サービスの名前（IfsDefaultServiceなど）をクリックします。「サービス」ページが表示されます。
「パフォーマンス」タブをクリックします。
「読取り専用接続プール」セクションと「書込み可能接続プール統計」セクションに統計が表示されます。

次のいずれかに該当する場合、「ターゲットの最大接続数」および「絶対最大接続数」の値を大きくします。
- 失敗割当てが0（ゼロ）より大きい。
- 合計接続数が「ターゲットの最大接続数」より3以上大きい。
- 「遅延割当」が5%より大きく、「平均割当時間(ミリ秒)」が10ミリ秒より大きい。
統計エージェントはリアルタイム・データを取得するため、ノード・ログまたはアプリケーション・ログを表示すれば、以前の統計も確認できます。このエージェントを構成して、Oracle Content DBリポジトリに格納されたドキュメントに統計を書き込むこともできます。統計エージェントについては、「統計エージェント」を参照してください。
実行時の接続プール設定を変更するには、「管理」タブをクリックします。
表の「読取り専用接続プール」行または「書込み可能接続プール」行で、「タスクに移動」アイコンをクリックします。
「ターゲットの最大接続数」および「絶対最大接続数」の値を大きくして、「適用」をクリックします。

各ターゲット接続または絶対接続では、中間層の1接続当たり約8MBが使用され、データベース上の1接続当たり1MBが使用されます。

永続的に変更するには、サービス構成を更新します。詳細は、「サービス構成の変更」を参照してください。