10g（9.0.4.2）
B15638-01
 目次 |
 索引 |
| Oracle Content Management SDK 管理者ガイド 10g（9.0.4.2） B15638-01 |
|
この章では、動作しているシステムのメンテナンス、チューニングおよびリカバリに関する重要な情報を説明します。すべての本番システムがそうであるように、Oracle Content Management SDK（Oracle CM SDK）の実装にも基本的な障害リカバリ・プランが必要です。Oracle CM SDKインスタンス内のコンテンツの増加に対応するため、システムにはLOB（ラージ・オブジェクト）ファイルの除去など独自の機能がいくつか用意されています。
この章の項目は、次のとおりです。
障害に備えた計画は、システム管理者またはDBAの重要な仕事の1つです。実際のビジネスおよび操作環境に適した毎日または毎週のバックアップ・プランを、必ず実装するようにします。Oracleデータベースに組み込まれたバックアップ機能を利用してください。
アップグレード、新しいデータの移行または他の大きな変更を行う前には、必ずシステムのバックアップを行います。詳細は、『Oracle Databaseバックアップおよびリカバリ基礎』を参照してください。
Oracle CM SDKのデータは、コンテンツとメタデータで構成されます。Oracle CM SDKに格納されるデータのほとんどはコンテンツであり、データベース表領域内のLOB（ラージ・オブジェクト）に格納されます。すべてのドキュメントは、データベースで提供されるLOBの1つの型であるバイナリ・ラージ・オブジェクト（BLOB）として格納されます。関連情報は、「パフォーマンスを向上させる適切な記憶域の装備」を参照してください。
Oracle CM SDKは、LOBの管理を通じてデータの格納を実現します。指定された期間アクセスされていないコンテンツは、BLOBからBFILEに自動的に移動できます。このコンテンツはまだアクセス可能であり、ユーザーが参照または検索したときに通常のコンテンツと同じように表示されます。
格納されるコンテンツの量が増えるにつれて、コンテンツをより低コストのメディアに移動することが望ましくなります。BFILEのサポートは、オフラインおよびニアラインの格納を実現します。
オフラインの格納とニアラインの格納の両方の場合で、あまりアクセスされないコンテンツはディスク・アレイなどの高価なオンライン・メディアからテープなどの低コストのオフライン・メディアに移動されます。メタデータと検索索引はオンラインに維持され、容易にアクセスできます。オフライン格納とニアライン格納の違いは、格納メディア間でのデータ移動の自動化と透過性にあります。格納メディア間のデータ移動を自動化するシステムは、階層ストレージ管理（HSM）システムとも呼ばれます。
Oracle CM SDKは、LOB（オンライン格納）またはBFILE（ニアライン格納）として格納されたコンテンツへの透過的なアクセスを実現します。BFILEは、ディレクトリ・オブジェクトとファイル名で構成される読取り専用のOracleデータ型です。コンテンツがBFILEとして格納されているドキュメントを更新すると、そのコンテンツは、変更が加えられた新しいBLOBとして再ロードされます。新しいコンテンツには索引が付けられます。
エンド・ユーザーは、コンテンツの格納場所を意識する必要はありません。ただし、管理者はコンテンツの格納場所を知っている必要があります。たとえば、Oracle Textによる索引付けを管理する場合、管理者はコンテンツがBLOBでのみ索引付け可能であることを知っている必要があります。一度ドキュメントが索引付けされると、BFILEは読取り専用であるため、Oracle CM SDKではその索引を無限に維持できます。
BFILEの除去は、デフォルトでは実装されません。コンテンツ・エージェントをアクティブにし、頻度の値を構成する必要があります。コンテンツ・エージェントは、指定された時間アクセスのなかったコンテンツをBFILEに移動します。詳細は、付録C「サーバー構成プロパティ」のコンテンツ・エージェントの各プロパティを参照してください。
BFILEが指すファイルは、データベースの$ORACLE_HOME/ifsbfiles/cmsdk_schemaに格納されます。このパスはベース・パスと呼ばれます。
コンテンツ・エージェントは、ベース・パスに基づいて相対パスを関連付けます。BFILEのファイルへの完全なパスは、ベース・パスに相対パスをプラスしたものになります。パスは次のようになります。
$ORACLE_HOME/ifsbfiles/cmsdk_schema/yyyy/dd/mm/hh/mm/ss/ifsbfile_id
次に各要素を説明します。
/yyyy/dd/mm/hh/mm/ss/は、コンテンツ・エージェントに対して設定されたサーバー構成プロパティに基づいてコンテンツ・エージェントが作成した相対パスです。
ifsbfile_idは、一意のIDを各コンテンツに関連付けるファイル・ネーミング・パターンです。
Oracle CM SDKマネージャを使用すると、ベース・パスの変更やBFILEポリシーの設定ができます。BFILEポリシーでは、BFILE参照がコンテンツ表から削除されたときにBFILEデータを削除するかどうかを指定します。
データベースの中で、Oracle CM SDKオブジェクトは単一行としてはモデル化されません。ただし、Oracle CM SDK Import/Export Managerを使用すると、コンテンツがBLOBとして格納される1つのドキュメントまたは少量のドキュメントをエクスポートできます。そのドキュメントは、別のOracle CM SDKスキーマにインポートすることができます。そのスキーマは、エクスポートしたドキュメントのスキーマと同じバージョンであることが必要です。詳細は、付録D「Oracle Content Management SDKへのデータの移行」を参照してください。
Oracle CM SDKのifschgipスクリプトを実行すると、中間層ホストのホスト名またはIPアドレスを変更できます。
このスクリプトを実行する必要があるのは、Oracle CM SDKの構成時に指定したコンピュータの識別子を変更する場合だけです。ホスト名またはIPアドレスは、Oracle CM SDK Configuration Assistantの「ドメインのコンポーネント」画面の「ローカル・ホスト名」フィールドで指定されています。
構成時に「ドメインのコンポーネント」画面でホスト名を指定していて、後から中間層のホスト名を変更する場合は、ifschgipスクリプトを実行する必要があります。構成時にホスト名を指定していて、後からIPアドレスを変更する場合は、このスクリプトを実行する必要はありません。どのような構成であっても、ifschgipスクリプトを実行することによってシステムに悪影響が及ぼされることはありません。
中間層のホスト名またはIPアドレスを変更する手順は、次のとおりです。
ローカル・ファイルをバックアップする必要はありません。これらは、ifschgipスクリプトによってバックアップされます。
これらのプロセスには、ドメイン・コントローラ、通常のノード、HTTPノードとそのOC4Jインスタンス、Application Server Controlなどがあります。詳細は、「Oracle CM SDKドメインの起動と停止」を参照してください。
ifschgipスクリプトを実行します。
$ORACLE_HOME/ifs/cmsdk/bin
次の引数を指定する必要があります。
ifs://db_host:port:db_service:schema
次に例を示します。
ifs://testcomputer.us.oracle.com:1521:cmsdkservice:cmsdkschema
必ずOracle CM SDKの構成時に指定したものと同じ識別子を指定します。たとえば、Oracle CM SDK Configuration Assistantの「ドメインのコンポーネント」画面の「ローカル・ホスト名」フィールドにIPアドレスを入力した場合は、ifschgipスクリプトでもIPアドレスを指定します。
パフォーマンスは通常、ネットワークの入出力（I/O）、ハードディスク・ドライブのI/O、メモリー（ランダム・アクセス・メモリー）のI/O、またはこの3つの要因や他の要因の組合せによって影響を受けます。1つの要因を調整してもボトルネックが別の場所に移動するだけということがあるので、チューニング・タスクは論理的に取り組む必要があります。
この項で紹介する基本的なパフォーマンスのヒントは次のとおりです。
詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
analyze.sqlスクリプトの定期実行Oracle CM SDKは、Oracleデータベースのコストベース・オプティマイザ（CBO）を使用して、SQL文を実行する最も効率的な方法を判断します。CBOが正しく機能するためには、Oracle CM SDKのanalyze.sqlスクリプトを通常のOracle CM SDK操作の一環として実行する必要があります（特に、ユーザーがインスタンスに多数のファイルをロードした後など、データに対して大量の変更が行われた後）。コストベース・オプティマイザの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
パフォーマンスの低下を避けるため、このスクリプトはビジー状態ではない期間に実行します。
analyze.sqlスクリプト（DBMS_STATSパッケージをコールする）はスキーマの統計をバックアップ表にエクスポートするので、次の項目「前の統計のリストア」で説明されているように、必要に応じて統計をリストアできます。スクリプトを実行するには、次のように入力します。
cd $ORACLE_HOME/cmsdk/admin/sql sqlplus cmsdk_schema/password @analyze.sql cmsdk_schema
このスクリプトは、特にOracle CM SDKに多数のドキュメントが含まれている場合は実行に時間がかかります。
新しい統計を収集する前に、analyze.sqlスクリプトによってバックアップの統計がIFS_BACKUP_STATS表にエクスポートされ、その統計セットにタイムスタンプが付けられます。次のSQL文を実行すると、その表で保存されている統計を問い合せることができます。
SQL> select distinct statid from ifs_backup_stats;
この問合せでは、statidによってすべての統計のリストが返されます（日付とタイムスタンプ）。次に例を示します。
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> @import_backup_stats.sql user_name '08-MAY-02 06:21.40'
ディスク領域の最大の消費は、Oracle CM SDKに存在するドキュメントを実際に格納するディスクで生じます。具体的には、索引付けされたメディアおよび索引付けされていないメディアの表領域で生じます。この項では、ドキュメントの格納方法およびそれらのドキュメントで必要とされる領域の量の計算方法を説明します。
LOBでは、データベースに格納される通常のデータと同じようにトランザクション・セマンティクスが規定されています。トランザクション・セマンティクスの基準を満たすためには、個別に変更およびリカバリできる小さな単位にLOBを分割する必要があります。そのように分割された部分をチャンクと呼びます。チャンクは、実際には、LOB列が含まれる表領域の1つ以上の順次的なデータベース・ブロックのグループです。
データベース・ブロックとそれらのブロック内のチャンク情報（BlockOverhead）は両方とも、格納されるデータに対してある程度のオーバーヘッドを強要します。現在のBlockOverheadは、ブロック当たり60バイトで、ブロック・ヘッダー、LOBヘッダーおよびブロック・チェックサムで構成されています。Oracle CM SDKは、LOBを32KBのチャンク・サイズに構成しています。例として、データベースのDB_BLOCK_SIZEパラメータが8192（8KB）に設定されていると仮定します。チャンクは4つの連続したブロックを必要とし、240バイトのオーバーヘッドを強要します。この場合、チャンク内の使用可能な領域は32768-240=32528バイトになります。
Oracle CM SDKに格納される各ドキュメントは、整数個のチャンクで構成されます。前述の例で考えた場合、500KBのドキュメントでは512000/32528=15.74=16個のチャンクが使用されます。16個のチャンクは、16*32KB=524288バイトを占有します。したがって、このドキュメントを格納するためのチャンク・オーバーヘッドは524288-512000=12288バイト（元のドキュメントのサイズの2.4 %）になります。Oracle CM SDKで使用されるチャンク・サイズを設定すると、ドキュメントのアクセス時間が最適化されます。1チャンクの大きさに満たない小さなドキュメントでは、ディスク領域の割合のオーバーヘッドが大きくなります（少なくとも1つのチャンクを使用する必要があるため）。
LOBのトランザクション・セマンティクスで必要とされるもう1つの構造は、LOB索引です。各LOB索引エントリは、特定のLOBオブジェクトの8つのチャンクを指すことができます（NumLobPerIndexEntry = 8）。500KBのドキュメントが16個のチャンクを使用する前述の例で考えると、そのオブジェクトでは2つの索引エントリが必要となります。各エントリは46バイト（LobIndexEntryOverhead）を使用し、Oracle Bツリー索引に格納されます。Oracle Bツリー索引には、索引の断片化の方法に応じた独自のオーバーヘッドがあります。
LOBの領域使用率に影響する最後の要因は、LOB列の作成時に使用されるPCTVERSIONパラメータです。PCTVERSIONの仕組みについては、『Oracle Database SQLリファレンス』を参照してください。
Oracle CM SDKは、作成したLOB列でデフォルトの10%のPCTVERSIONを使用します。その結果、読取り一貫性ビューで「ORA-22924スナップショットが古すぎる」というエラーが生じる可能性が小さくなります。デフォルトでは、永続的なPCTVERSIONチャンクを考慮し、ディスク使用量の予想においてチャンク領域の最低限10%の増加を加味する必要があります。
ディスク領域が問題である大規模システムでは、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の表領域使用量を計算する手順は、次のとおりです。
chunks = roundup(FileSize/(ChunkSize-((ChunkSize/BlockSize) * BlockOverhead)))
たとえば、FileSize = 100,000、ChunkSize = 32768、Blocksize = 8192およびBlockOverhead = 60の場合は、Chunks = roundup (100000 /(32768 - ((32768 / 8192) * 60)))= 4 Chunksになります。
FileDiskSpaceInBytes = roundup(chunks*ChunkSize*PctversionFactor) + roundup(chunks/NumLobPerIndexEntry*LobIndexEntryOverhead)
前述の例を再び利用すると、chunks = 4、ChunkSize = 32768、PctversionFactor = 1.1、NumLobPerIndexEntry = 8およびLobIndexEntryOverhead = 46であるため、FileDiskSpaceInBytes = roundup (4 * 32768 * 1.1) + (roundup(4/8) * 46) = 144226 FileDiskSpaceInBytesになります。
TableSpaceUsage = sum(FileDiskSpaceInBytes) for all files stored
Oracle CM SDKは、複数のLOB列を作成します。領域の計算は、各表領域での格納に適したコンテンツの量に基づいて表領域ごとに行う必要があります。
Oracle CM SDKサーバーは、ファイル・システムとそのファイル・システムのコンテンツに関する永続情報をデータベース表に保持します。それらの表および関連付けられた構造は、Oracle CM SDKのプライマリ表領域に格納されます。それらの構造は、ファイル・システムと、そのファイル・システムを利用する様々なプロトコルおよびAPIの両方をサポートするために必要となります。この領域の管理および計画タスクは、Oracleデータベースの通常インストールの作業とほとんど同じになります。
ドキュメントごとに約6KBのオーバーヘッドまたはコンテンツ全体の約2%がこの表領域から使用されると予測してください。属性、サブクラスまたはカテゴリなどのカスタム・メタデータが大量にある場合、このオーバーヘッドはさらに大きくなります。
プライマリ表領域に割り当てられるディスク領域の初期値は、デフォルト・インストールで約50MBです。50MBのうち、インストール完了の時点では16MBが実際に使用されます。その中には、必須とされるすべての表および索引のインスタンス化、およびインストールの過程でOracle CM SDKにロードされる700以上のファイルで必要なメタデータが含まれます。この表領域中の異なる表および索引は、Oracle CM SDKのどの機能が特定のインストールで使用されるかに応じて異なる比率で増加します。
統計を適切に実行し、表領域をサポートできるだけの十分なハードディスク・ドライブ空き領域があっても、パフォーマンスに問題が残る場合があります。そのような場合は、パフォーマンスのボトルネックがOracleデータベース・サーバー、Oracle CM SDKまたはその他の要因のいずれにあるのかを確認する必要があります。
問題を特定するには、まず、どのプロセスが実行中であり、どのくらいのリソースが消費されているのかを確認します。
top（UNIXの場合）または「タスク マネージャ」（Windowsプラットフォームの場合）を実行します。
ボトルネックがOracleのシャドウ・プロセスである場合は、Statspackを使用してバッファ取得数が最大のSQL文を特定し、そのSQL文に対してEXPLAIN PLANを実行します。
全表スキャンが確認された場合は、それが問題の原因となっている可能性があります（オプティマイザが適切な計画を選択していない可能性があります）。その問題をオラクル社カスタマ・サポート・センターに報告してください。問題を特定するには、さらに作業が必要です。
詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
メモリーが少なすぎる可能性があります。たとえば、ログ・ファイルにjava.lang.OutOfMemoryErrorエラーが記録される場合は、そのJVMの最大メモリー（Xmx）設定を増やします。Xmx設定を変更する方法の詳細は、Oracle Content Management SDKのインストレーションおよび構成ガイドの付録Aを参照してください。
ユーザーがレスポンス時間に不満を持ち、top（UNIXの場合）またはそれに相当するもの（Windowsプラットフォームでの「タスク マネージャ」など）で、Javaプロセスが100%のCPU使用率で1分以上動作していることが示されている場合は、JavaのXmx設定が小さすぎる可能性があります。
verbosegc）をオンにします。このためには、ノード構成の「Javaコマンド」プロパティを編集します。詳細は、表4-1「ノード構成プロパティ」を参照してください。ノードのログ・ファイルに、ガベージ・コレクションに関する出力が次のように記録されます。
GC[1] in 305 ms: (6144kb, 6% free) -> (14Mb, 61% free)
GC[1]は、主要ガベージ・コレクション（major GC）を示します。GC[0]は、若い世代領域（nursery）のみのガベージ・コレクションを示します。この例では、コレクションに305ミリ秒かかります。コレクションの開始時点で、ヒープ・サイズは6,144KBで、6%の空きがありました。ヒープはコレクションの間に14MBに増加し、空きが61%になりました。
Xmx設定値を増やしてください。
ボトルネックがOracle CM SDK Javaプロセスである場合は、まず、Oracle CM SDKサービスのキャッシュ・ヒット率を確認します。次のようにして、Application Server Control（http://host_name:1810）から作業を始めます。
IfsDefaultServiceです。「サービス」ページが表示されます。
目標は、「キャッシュ・ヒット率」を高くすることです（100%も可能）。サービスの「キャッシュ・ヒット率」が98%に満たない場合は、「コミット済データ・キャッシュ」のサイズが小さすぎる可能性があります。
これで、中間層コンピュータでのメモリー使用量が1オブジェクト当たり約3KB増加します。
変更を永続的なものにするには、サービス構成を更新します。詳細は、「サービス構成の変更」を参照してください。
読取り専用接続プールまたは書込み可能接続プールについて、次のいずれかが当てはまる場合には「ターゲットの最大接続数」および「絶対最大接続数」を増やします。
追加された各ターゲット接続または絶対接続は、中間層で1接続当たり約8MBを使用し、データベースでは1接続当たり1MBを使用します。
読取り専用接続プールまたは書込み可能接続プールについて、次のいずれかが当てはまる場合にはTargetSizeおよびMaximumSizeを増やします。
追加された各CurrentSize接続は、中間層で1接続当たり約8MBを使用し、データベースでは1接続当たり1MBを使用します。
ログ・ファイルには、次のような接続プール統計が記録されます。
Cache performance for S_LibraryObject cache CACHESIZE=409 OBJECTCOUNT=409 PUTCOUNT=818 REMOVECOUNT=0 FINDCOUNT=14617 HITCOUNT=13949 MISSCOUNT=668 HITRATIO=0.9542997879181775 MISSRATIO=0.04570021208182254 Cache performance for FolderPath cache CACHESIZE=15 CacheSizeEstimate=15 ACCESSSEQUENCE=599 SequenceAtLastPurge=0 PUTCOUNT=15 REMOVECOUNT=0 PURGECOUNT=0 FINDCOUNT=557 HITCOUNT=433 MISSCOUNT=124 HITRATIO=0.77737881508079 MISSRATIO=0.22262118491921004 Cache performance for committed S_LibraryObjectData cache CACHESIZE=473 CacheSizeEstimate=576 ACCESSSEQUENCE=6821 SequenceAtLastPurge=0 PUTCOUNT=576 REMOVECOUNT=0 PURGECOUNT=0 FINDCOUNT=27092 HITCOUNT=26338 MISSCOUNT=754 HITRATIO=0.972168905950096 <=== THIS IS THE NUMBER TO WATCH MISSRATIO=0.02783109404990403 Cache performance for LibraryObject cache CACHESIZE=221 OBJECTCOUNT=221 PUTCOUNT=221 REMOVECOUNT=0 FINDCOUNT=1473 HITCOUNT=1252 MISSCOUNT=221 HITRATIO=0.8499660556687033 MISSRATIO=0.1500339443312967
カスタムJavaアプリケーションを記述した場合は、次のいずれかを使用してセッションまたはサービスの統計を取得できます（セッション変数は認証されたLibrarySession）。
// LO data cache System.out.println(session.invokeServerMethod("DYNGetCommittedLibraryObjectData CachePerformanceString", null)); // Folder path cache System.out.println(session.invokeServerMethod("DYNGetFolderPathCachePerformance String", null)); // LO cache System.out.println(session.getLibraryObjectCachePerformance().toString()); // Writeable connection pool System.out.println(session.invokeServerMethod("DYNGetWriteableConnectionPool PerformanceString", null)); // Readonly connection pool System.out.println(session.invokeServerMethod("DYNGetReadonlyConnectionPool PerformanceString", null));
このページで行った変更は、実行中のサービス・セッションのみに適用されます。設定を永続的に変更し、ドメインまたはこの特定のノードを再起動するたびにその設定が使用されるようにするには、次の手順を実行します。
SmallServiceConfigurationなど）のプロパティを変更します。
カスタム・アプリケーションのスレッド件数が増加し続けて、まったく減少しない場合は、ソフトウェアでスレッド・リークが発生していることが考えられます。ユーザーによる接続の切断またはタイムアウトのたびに必ずLibrarySession.disconnect()がコールされるようにしてください。
|
 Copyright © 2005 Oracle Corporation. All Rights Reserved. |
|