| Oracle Enterprise Manager Application Configuration Consoleパフォーマンスおよびチューニング・ガイド リリース5.3.2 B56958-01 |
|
 戻る |
| Oracle Enterprise Manager Application Configuration Consoleパフォーマンスおよびチューニング・ガイド リリース5.3.2 B56958-01 |
|
戻る |
Application Configuration Consoleパフォーマンスおよびチューニング・ガイド
リリース5.3.2
部品番号: B56958-01(原本部品番号:E14655-02)
2009年11月
このドキュメントでは、Application Configuration Consoleおよびサード・パーティ製ソフトウェアをチューニングしてパフォーマンスと効率性を改善する方法について、様々な観点からアドバイスを提供します。アドバイスは、構成設定の調整から追加ハードウェアの導入まで全範囲を網羅しています。
このドキュメントは、次の項で構成されています。
Application Configuration Consoleは、複数層アーキテクチャで動作します。つまり、パフォーマンスに影響を与える可能性のある多数の潜在的フラッシュ・ポイントが存在します。このアーキテクチャを理解しておくと、問題のトラブルシューティングやボトルネックの解決の際に、どこを確認すればよいかを判断しやすくなります。
エンドユーザーは、Application Configuration Consoleに、Eclipseベースのリッチ・クライアントやWebベースのレポーティング・クライアントまたはダッシュボード・クライアントを通してアクセスします。これらのクライアントは、HTTPS（XML-RPC）を使用するリモート・プロシージャ・コール（RPC）を通して、Application Configuration Consoleサーバーと通信します。Application Configuration Consoleクライアントは、各ユーザーのマシンにインストールします。
レポーティング・クライアントおよびダッシュボード・クライアントを使用して、Webブラウザから、Application Configuration Consoleで管理されている構成情報やアクティビティに関するリアルタイムの情報にアクセスできます。
Application Configuration ConsoleサーバーはTomcatサーバー上で稼働してクライアントのリクエストを処理し、データを管理するために次の2つのリポジトリを使用します。1つはApplication Configuration Consoleメタデータを管理するリレーショナル・データベース、もう1つはApplication Configuration Consoleで管理される構成のバージョン履歴を管理するバージョン・コントロール・リポジトリです。
トラッキングと比較の操作では、その性格上、システムに対する要求が高くなります。設定、構成およびタスクの実行について綿密な計画を立てておくと、この要求を大幅に低減してサーバーのオーバーロードを防ぐのに役立ちます。この項では、トラッキングと比較の操作を行ううえで考慮する計画をいくつか紹介します。
トラッキングおよび比較のアクティビティをアセット・レベル（デフォルトのリソース・ビュー）で実行する傾向にある場合、構成が多数含まれるアセットをトラッキングまたは比較すると、システムに負荷がかかります。この解決策として、アセットをタイプ別に構成ファイルの論理サブセットに分け（たとえば、オペレーティング・システム、アプリケーション、Web層など）、その結果作成された多数のより小さいアセットを使用してアクティビティを実行します。
構成単位をベースにすると、操作のタイプ以外の他の要素によって負荷が跳ね上がる可能性があります。操作に関与するファイルのタイプと同様に、ファイルのサイズも重要です。たとえば、100Kの2つのファイルの比較は、1Kの2つのファイルの比較よりも多くのメモリーおよびCPU時間を消費します。または、他の条件がすべて同じである場合、XMLマッピングされたファイルの比較は、Javaプロパティにマッピングされたファイルの比較よりも多くのリソースを消費します。そのため、特にサイズの大きい複雑な構成では、どの構成をトラッキングまたは比較するかを十分に検討することが目標となります。
トラッキングと比較の操作を最適化するには、どの構成を対象とする必要があるかを正確に判断し、その一連のファイルに対するリソース仕様を構築します。すべての構成を重要であると判断した場合以外は、ディレクトリにワイルドカードを使用するのは避けてください。
特殊な環境のためにこの手段が適切でない場合は、アセット・ビューを使用してアセット内の構成のサブセットを抜粋し、トラッキングまたは比較の対象とする論理グループを作成します。アセット・ビューは、アセット内にある構成のサブセットを見る方法で、これを使用して特定のユーザー・グループになんらかの関係があるか特別に関連する構成を表示します。
例として、2つのアセット、AとBを比較するケースを検討してみます。各アセットには500個の構成が含まれており、その中の30個の構成が比較を行う必要のある重要なものであるとします。各アセットに対してアセット・ビューA1とB1をそれぞれ作成し、対象とする30個の構成を選定します。それから、アセット・ビューのレベルでA1とB1の比較を実行するように、比較を設定します。
アセット・ビューの詳細は、Application Configuration Consoleクライアントのオンライン・ヘルプを参照してください。
これは表題に示すとおりです。トラッキング・ジョブを夜間に実行すれば、通常の業務時間中はリソースを解放して、検索や置換などの日常業務やアセットのロードをより効率的に行えます。
比較のうち、少なくとも長時間かかるとわかっている比較をオフピークにスケジュールすれば、業務時間中にその同じ時間分のパフォーマンス改善効果が得られます。そのうえ、翌日には結果レポートが手元にあり、すぐに確認できます。
複数のイベントをオフピークにスケジュールする場合は、時間をずらしてリソースに与える影響を分散させることもできます。
Application Configuration Consoleは、最初に名前で、次にコンテナ内の要素の位置に基づいて比較を実行します。構成内で同じ名前が使用されており、なおかつ配置が一致している場合は、比較は期待どおり、プロパティ値の相違点を検出します。ただし、何事にも完璧ということはなく、名前と位置が構成間で異なることもよくあり、その結果相違点が誤検出される可能性もあります。特に、WebLogicやWebSphereの構成はノイズの影響を受けやすく、重要な比較の妨げとなることがあります。
この問題を回避するために、メタデータを比較キーの形式に設定し、名前と位置の相違を埋めて値を比較できるようにすることができます。比較キーとこの内容での使用方法の詳細は、Application Configuration Consoleクライアントのオンライン・ヘルプ、特に代替の比較計画のトピックを参照してください。
構成にメタデータを設定するのは、比較キーとしては役立ちますが、面倒な作業でもあります。しかも、メタデータは更新操作で上書きされるため、短い期間しか使用できません。メタデータの設定プロセスを自動化するには、比較キーを適用するときに保存仕様（saveSpecEntry）を使用します。saveSpecEntryは、アセットをロードまたは更新するときに適用される一連のルールを定義したものです。この場合は、saveSpecEntryで構成のメタデータを比較キーのタイプに設定し、mvPath式を評価してその値を取得します。保存仕様とこの内容での使用方法の詳細は、Application Configuration Consoleクライアントのオンライン・ヘルプ、特に比較キーと保存仕様の登録のユースケースのトピックを参照してください。
ただし、非常に一般的な構成では、mvPath式の評価は時間がかかる場合もあります。次の2つの式について検討してみます。ただし、非常に一般的な構成では、mvPath式の評価は時間がかかる場合もあります。次の2つの式について検討してみます。
タイプServerの要素の下に配置されている特定のプロパティ名（ID）に対して、1つの既知の構成（config.xml）を解決します。
特定のプロパティ名（ID）に対して、Application Configuration Console内にある既知の構成すべて、およびそれに対応する要素すべてを解決します。
最初の式の方が、より高速に非常に明確に解決されます。そのため、おおまかにいえば、比較でmvPath式を使用する場合は、できるだけ具体的にすることです。
Application Configuration Consoleクライアントには、対話形式の比較操作、つまり後で実行するようにスケジュールされていない比較操作の開始から完了までの時間について、20分の制限値がハードコードされています。操作がタイムアウトになると、結果は失われます。この章に記載する計画に従えば、実行時間は大幅に削減されるはずです。比較の実行時間が数分でも超過する場合は、効率性を見直す必要があります。
|
注意: スケジュールされた比較（およびトラッキング・イベント）は、タイムアウトしません。処理に異常がないかぎり、完了するまで実行されます。 |
Application Configuration Consoleのインストールでは、そのサーバー、Webレポート・サーバーおよびトラッキング・サーバーの個別のデプロイが作成されます。これにより、サーバーをTomcat JVMの別のインスタンスに簡単に再デプロイすることができます。
オフピーク時のトラッキング操作のスケジュールがオプションにない場合は、代替の救済策として、トラッキング・サーバーを別のJVMインスタンスに再デプロイする方法があります。サイトでWebレポートが頻繁に使用される場合は、Webレポート・サーバーを再デプロイすると全体のパフォーマンスも改善されます。
トラッキング・サーバーおよびWebレポート・サーバーの再デプロイの詳細は、『Application Configuration Consoleインストレーション・ガイド』を参照してください。
Application Configuration Consoleを広範囲に渡って使用する組織では、作業負荷を複数のホスト・マシンに分散する必要があります。これを念頭に置いて、特定のコンポーネントを個別のホスト・マシン上の個々のJVMインスタンスに移動（再デプロイ）して、機能的なスケーリングを効率的に達成できるようにソフトウェアがパッケージ化されています。
Application Configuration Consoleのインストールでは、次のような個別のサーバー・デプロイが作成されます。
コア・サーバー: アセットのロード、比較生成、クライアント・リクエストへのレスポンスなどのアクティビティを実行します。これはプライマリ・サーバーで、Application Configuration Consoleのコアとなるものです。
トラッキング・サーバー: ジョブ・スケジュールに基づいて外部リソースに対してトラッキング操作を実行します。これはセカンダリ・サーバーです。
Webレポート・サーバー: Application Configuration Consoleデータに対してWebベースのレポート生成を行います。これはセカンダリ・サーバーです。
デプロイは、次の場所にある1つのTomcat上の個別のディレクトリとして設定されます。
$OACC_INSTALL/appserver/tomcat/webapps/mvserver|mvtrack|mvwebreports
サーバーのデプロイには特別な必要事項はありませんが、次の条件の一部またはすべてが使用サイトに当てはまる場合は、デプロイをお薦めします。
トラッキングが大容量のアクティビティになっている。
ユーザーが積極的にレポートを生成および表示している。
Application Configuration Consoleのコア・サーバーでのアクティビティが全体的に高レベルである。
サーバーの再デプロイの詳細は、『Application Configuration Consoleインストレーション・ガイド』を参照してください。
Oracle RDBMSは本質的に複雑であり、そしてApplication Configuration Consoleはデータベース集中型のアプリケーションです。この組合せでは、DBAがデータベース・パフォーマンスのあらゆる側面を積極的に監視して分析することが要求されます。Oracleデータベースにはパフォーマンス問題の原因となり得るものは、事実上多数あります。必要に応じて調査や対処する必要がある分野もいくつか認識されています。この章に記載するタスクを、列挙する順に実行してください。ただし、まず最初に、Application Configuration Consoleのコア・サーバーとOracleデータベースを別々のホストに置くことをお薦めします。
統計を定期的に、少なくとも週1回は生成してください。これは、使用情報を分析用に提供するだけでなく、データベースのアクセス・プランを最適化して操作速度を大幅に向上させることができます。
分析を生成するには、次のようにします。
データベースにoaccuserとして接続し、次のコマンドを実行します。
exec dbms_stats.gather_schema_stats(ownname => 'OACCUSER', options => 'GATHER AUTO');
コア・サーバーを停止して再起動します。
Application Configuration ConsoleはJavaベースのアプリケーションで、Apache Tomcatインスタンスにデプロイされて仮想マシン（JVM）内で実行されます。この章では、TomcatとJVMの双方に適用される一般的なチューニングの考慮点について説明します。これらの技術については、Web上でGoogle検索によって豊富な情報が得られます。あるいは、単にSun Microsystems Java Webサイト（http://java.sun.com）にアクセスすれば、次のドキュメントを入手できます。
http://java.sun.com/performance/reference/whitepapers/tuning.html
Tomcat上で設定を調整してパフォーマンスを改善できる領域は次の2つです。
同時アクティビティをサポートするJVMスレッド
データベース・アクセスをサポートする接続プール
JVM内で作業するものとしてのスレッドについて考えてみます。使用できるスレッドが多いほど、同時に行える作業は多くなります。受信リクエストを処理できるだけの十分なスレッドがあることを確認してください。確認結果を基に、必要に応じて次のディレクトリにあるserver.xmlのスレッド設定を増やします。
$OACC_INSTALL/appserver/tomcat/conf/
特に、ポート9980とポート9943のコネクタ・オブジェクトを見つけて、maxThreads、minSpareThreadsおよびmaxSpareThreadsのプロパティ値を変更します。また、同じファイルにあるHTTPまたはHTTPSコネクタでも、類似名のプロパティ値を変更することを検討します。
|
注意: ここではチューニングを行っていることを忘れないでください。値を無差別に増やさないでください。スレッドはメモリーとCPUを消費します。JVM内にアイドルのスレッドがあまりにも多いと、実際にパフォーマンスが低下する可能性があります。 |
Tomcatは、各サーバー・デプロイ、つまり、コア・サーバー、トラッキング・サーバーおよびWebレポート・サーバーに対して、データベースへの接続プールを作成して維持します。各デプロイに対する接続プールのサイズを変更するには、次のディレクトリにある対応する構成ファイル（mvserver、mvtrack、mvwebreports）のmaxActiveプロパティ値を変更します。
$OACC_INSTALL/appserver/tomcat/conf/Catalina/localhost
このプロパティ値は、使用可能な接続プールの不足が分析によって実証された場合にのみ変更してください。
ヒープとは、JVMで利用できるメモリー領域のことです。一般的には、ヒープはいくら多くても多すぎることはありません。この項では、Application Configuration Consoleのコア・サーバー用とクライアント用のヒープ設定を増やす方法について説明します。
Application Configuration Consoleのコア・サーバーは、初期状態では1024MBのヒープを使用するように構成されています。これは、比較的少ないデータ量を扱うには十分なサイズです。ただし、オペレーティング・システムに追加で使用可能なメモリーがあれば、これを2倍の2048MBにすることをお薦めします。ヒープ・サイズを増やすには、次のようにします。
次のディレクトリに進みます。
$OACC_INSTALL/appserver/tomcat/bin
setenv.batまたはsetenv.shファイルを開き、プラットフォームに合せて編集します。
次のようにJavaオプションを設定します。
JAVA_OPTS=-Xms2048m –Xmx2048m
編集内容を保存します。
増やしたヒープ・サイズは、次にコア・サーバーを再起動したときに有効になります。
Application Configuration Consoleクライアントのインストール時には、512MBのヒープ・サイズで実行するように構成されます。これは比較的少ないデータ量を扱うには十分です。ただし、オペレーティング・システムに追加で使用可能なメモリーがあれば、これを2倍の1024MBにすることをお薦めします。ロードするデータ量が10,000構成を超える場合は、必ずこれを増やしてください。ヒープ・サイズを増やすには、次のようにします。
次のディレクトリに進みます。
$OACC_INSTALL/eclipse
start.batまたはstart.shファイルを開き、プラットフォームに合せて編集します。
次のようにJavaオプションを設定します。
-vmargs –Xms1024m –Xmx1024m
編集内容を保存します。
増やしたヒープ・サイズは、次にクライアントを再起動したときに有効になります。
Application Configuration Consoleは、V3準拠のLDAPに対する検索フィルタおよびバインド操作を認証ユーザーに発行します。認証にかかる時間が異常に長いと思われる場合は、次の点を確認してください。
グループおよびユーザーDNの値が正確であるかチェックします。これが不正確であると、LDAPツリーの下位に至るまで不必要な検索が行われる可能性があります。
LDAPサーバーに十分なリソースがあることを確認してください。LDAP管理者に、サーバー・ロードのチェックやログの調査などを依頼してください。
この項では、Application Configuration Consoleを維持管理するための様々なプロセスについて説明します。
Application Configuration Consoleは、バージョン・コントロール・システムとしてSubversion（SVN）を使用しています。これはApplication Configuration Consoleが操作のバックアップに適用する精度に応じて、時間の経過とともに大きくなる可能性があります。Oracleをインストールした直後に必要なディスク容量は約400MBですが、アクティブで大規模な環境では50GB以上に増大することもめずらしくありません。このような大きな影響から、ストレージだけでなくパフォーマンス面においても、SVNリポジトリを管理可能なサイズになるまで削除する推奨方法が必要であることが認識されています。ただし、単純に古いバージョンを削除してディスク容量を確保する方法は推奨できません。保持する履歴のバージョン番号をリセットして、データベースの整合性をシームレスに維持することも必要です。
この項で詳説するプロセスの目的は次のとおりです。
リポジトリから削除しても問題ないと思われるバージョンを削除する便利な方法を提供します。
残されたバージョン履歴に基づいて、リポジトリを再構築します。
データベースを更新し、再構成されたバージョン番号を反映します。
Application Configuration ConsoleインストールとOracleデータベースの同期バックアップをとります。
Application Configuration Consoleを停止します。OracleとSVNサービスは継続して実行できます。
Application Configuration Consoleファイルシステムのバックアップ・コピーを作成します。たとえば、次のようにします。
/opt/oracle/oacc/server/*
削除スクリプトにより、リポジトリ（/opt/oracle/oacc/svn）のコピーが保存されますが、これは全プロセスの完了後に削除できます（「データベース内のバージョン番号の更新」を参照）。
サイトの監視プロトコルに従って、DBAがデータベースのバックアップをとります。
リポジトリに含まれる履歴レコードを調べ、カットオフ・ポイントを設定します。このマーカーより古いバージョンがすべてパージされます。たとえば、バージョン履歴を6か月間維持することがサイトのポリシーであれば、バージョンが約6か月のものを探し、そこから新たにバージョン履歴を開始します。
リポジトリのバージョン履歴ディレクトリ（デフォルト: $OACC_INSTALL/svn/db/db/revs）のリストを表示します。これには、0からnまでの範囲のバージョンが表示されます。ここで、nは最新のバージョン番号です。新たにバージョン履歴を開始するよう選択した日付に一致する日付を持つバージョン番号を探します。このバージョン番号と最新のバージョン番号をメモしておきます。これらのバージョン番号は、削除スクリプトの引数として使用されます。
|
注意: 削除処理では、既存リポジトリのサイズと同程度のスクラッチ・ディスク領域が必要です。リポジトリが20GBであれば、SVNの削除処理用として20GBのディスク容量を一時的に確保する必要があります。 |
次に進む前に、この項で説明するプロセスに関する次の点に注意してください。
この項の説明は、次の規則に従っています。$OACC_INSTALLは、コア・サーバーがインストールされている場所、たとえばWindowsではC:\Program Files\Oracle\oacc\server、LinuxまたはUNIXではopt/oracle/oacc/serverを指します。
SVNバイナリ・ディレクトリがデフォルト（$OACC_INSTALL/svn/bin）以外の場所にある場合は、それに応じてMVRemoveVersionsスクリプトのSVNLOCATION変数を更新する必要があります。
SVNリポジトリがデフォルト（$OACC_INSTALL/svn/db）以外の場所にある場合は、それに応じてMVRemoveVersionsスクリプトのDB_LOCATION変数を更新する必要があります。
SVNリポジトリを削除するには、次のようにします。
コア・サーバーとセカンダリ・サーバー（トラッキングおよびWebレポート）が動作中であれば、停止します。
シェルを開き、次のディレクトリに移動します。
$OACC_INSTALL/appserver/tomcat/shared/scripts
使用プラットフォームに適したバージョン削除スクリプトを実行します。スクリプトには2つの引数を使用します（保持するバージョン範囲の開始と終了、この終了バージョンはリポジトリ内の最新バージョンにする必要があります）。たとえば、次のようにします。
./MVRemoveVersions.sh 100 200
./MVRemoveVersions.bat 100 200
UNIXシステムでは、スクリプトの実行権限が必要になる場合があります。たとえば、次のようにします。
> chmod +x MVRemoveVersions.sh
|
注意: スクリプトの実行には、保持するバージョン2000個につき約1時間かかります。スクリプトの実行中は、進捗インジケータは表示されません。 |
次のメッセージが表示された場合:
Complete. If there were no errors encountered in the execution, you should now execute remove_versions.sql as the mValent Oracle user (default=OACCUSER).
データベースを更新する前に、ログ・ファイル（格納場所: $OACC_INSTALL/appserver/shared/scripts/MVRemoveVersions.log）をチェックしてエラーがなかったか確認してください。
リポジトリを削除したら、データベースを更新して新しいバージョン番号を反映します。
remove_versions.sqlスクリプトを、Oracleサーバーの一時ディレクトリにコピーします。（このスクリプトはデータベースが格納されているホストで実行する必要があります。）
suコマンドを使用して、ログインをOracleユーザーに変更します。たとえば、次のようにします。
su oracle
Application Configuration ConsoleユーザーのOracleユーザー名とパスワード（デフォルト: OACCUSER）を使用し、SQL*Plusセッションを開いてデータベースにログインします。この手順では、ユーザー名とパスワードを検証します。たとえば、次のようにします。
> sqlplus OACCUSER/OACCUSER@OACCSERV
> exit
シェルを開き、手順1でスクリプトをコピーした一時ディレクトリに移動します。
remove_versions.sqlスクリプトを実行します。バージョン範囲にはバージョン削除スクリプトで指定したのと同じものを使用します。たとえば、次のようにします。
> sqlplus OACCUSER/OACCUSER@OACCSERV @remove_versions.sql 100 200
スクリプトにより、Oracle SIDおよびApplication Configuration ConsoleユーザーのOracleユーザー名とパスワード（デフォルト: OACCUSER）を求められます。適切な値を入力します。
スクリプトが完了すると、リポジトリ（$OACC_INSTALL/svn/db）のサイズが、削除されたバージョン履歴分のみ減少したのがわかります。
Application Configuration Consoleを起動して、クライアントのバージョン履歴にアクセスできることを確認します。すべてが予期したとおりに動作しているようであれば、スクリプトによって$OACC_INSTALL/svn/db_$DATEに保存された日付の付いた元のリポジトリのコピーを削除できます。ここで、$DATEはスクリプトの実行日時に相当する数値の日付文字列です。
この項では、Application Configuration Consoleのパフォーマンス改善に役立つと思われるその他各種の推奨事項を記載します。
Application Configuration Consoleを必ず最新リリースにアップグレードし、最新のパフォーマンス拡張を使用してください。たとえば、5.3.2リリースはJDK 1.6に対応しており、このJDK 1.6では、特にガベージ・コレクションとメモリー管理の点で、JDK1.5から目に見えてパフォーマンスが改善されています。さらに、Application Configuration Consoleの5.3.2リリースには、特定のコードベースのパフォーマンス拡張がいくつか含まれています。
パフォーマンスと全体スループットを最適化するために、可能であれば64ビットのハードウェア、オペレーティング・システムおよびJVMで実行することをお薦めします。おそらく、より重要なのはデータベースを64ビットのマシンでホストすることです。というのは、ここがボトルネックとなる可能性が高いからです。
3項では、サーバーの再デプロイについて説明しました。これは、大量のデータを含み、トラッキング、比較およびレポート操作が頻繁に使用される多忙なマルチユーザー環境に対処する手段です。リソースが無限にある場合は、代替方法として、究極のロード・バランシング、つまり個別のApplication Configuration Consoleインスタンスで一意のデータベース・インスタンスにアクセスする方法を検討することもできます。たとえば、次のように1つのアプローチを1つの構成区分にします。
Application Configuration ConsoleインスタンスA: UNIX/Linuxオペレーティング・システム構成
Application Configuration ConsoleインスタンスB: アプリケーション構成
Application Configuration ConsoleインスタンスC: Windowsオペレーティング・システム構成
この方法を採用する場合は、トレードオフを理解していることが重要です。この種のロード・バランシングでは、間違いなく明確な利点が得られます。ただし、これらは完全に分離した個別のインスタンスであることを理解しておいてください。これは、インスタンス間の比較や複数のインスタンスを対象としたレポート生成は行えないことを意味します。つまり、Application Configuration Consoleの2つ以上のインスタンスからデータをマージすることはできません。これらの条件を了承できるのであれば、個別インスタンスを考慮の対象にすることができます。
Application Configuration Consoleで作成されたものをすべて維持するにはある程度のオーバーヘッドがあります。そのため、定期的に大掃除を行い、すでに有効でないか使用されていないものは削除することをお薦めします。
このカテゴリにあてはまるアセット、ホスト、認証パックおよびリソース仕様を削除します。
使用されていないアセット・ビューをすべて削除します。特に、WebSphereやWebLogicの自動化モジュールで作成されたデフォルトのアセット・ビューを確認してください。これらによって余分な構成データが定義されていることがあります。このカテゴリにあてはまるアセット・ビューはすべて削除します。
2項では、トラッキングと比較の操作でパフォーマンスを最適化する計画を提案しました。たとえば、大きなアセットはタイプ別に構成の論理サブセットに分割します。アセット・ビューを使用して、トラッキングまたは比較の対象とする構成の論理グループをアセット内に作成します。このガイドラインの他に、ベスト・プラクティスとして、アセットはできるだけ小さくし、どんな場合でも上限は500構成を超えないようにすることをお薦めします。これは、Application Configuration Consoleの操作（比較、更新、同期）時だけでなく、アセットのロード時においても、パフォーマンス低下を防ぐ効果があります。
オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。
ドキュメント内のサンプル・コードのアクセシビリティについて
スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧だけを行に記述する必要があります。しかしJAWSは括弧だけの行を読まない場合があります。
外部Webサイトのドキュメントのアクセシビリティについて
このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。
聴覚に障害があるお客様のOracleサポート・サービスへのアクセス
Oracleサポート・サービスに連絡するには、テレコミュニケーション・リレー・サービス（TRS）を使用してOracleサポート（+1-800-223-1711）までお電話ください。Oracleサポート・サービスの技術者が、Oracleサービス・リクエストのプロセスに従って、技術的な問題を処理し、お客様へのサポートを提供します。TRSの詳細は、http://www.fcc.gov/cgb/consumerfacts/trs.htmlを参照してください。電話番号の一覧は、http://www.fcc.gov/cgb/dro/trsphonebk.htmlを参照してください。
次の各項に、各サービスに接続するためのURLを記載します。
Oracleサポート・サービス
オラクル製品サポートの購入方法、およびOracleサポート・サービスへの連絡方法の詳細は、次のURLを参照してください。
http://www.oracle.com/lang/jp/support/index.html
製品マニュアル
製品のマニュアルは、次のURLにあります。
http://www.oracle.com/technology/global/jp/documentation/index.html
研修およびトレーニング
研修に関する情報とスケジュールは、次のURLで入手できます。
http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page_id=3
その他の情報
オラクル製品やサービスに関するその他の情報については、次のURLから参照してください。
http://www.oracle.com/lang/jp/index.htmlhttp://www.oracle.com/technology/global/jp/index.html
|
注意: ドキュメント内に記載されているURLや参照ドキュメントには、Oracle Corporationが提供する英語の情報も含まれています。日本語版の情報については、前述のURLを参照してください。 |
Oracle Enterprise Manager Application Configuration Consoleパフォーマンスおよびチューニング・ガイド, リリース5.3.2
部品番号: B56958-01
Oracle Enterprise Manager Application Configuration Console Performance and Tuning Guide, Release 5.3.2
原本部品番号: E14655-02
Copyright © 2009, Oracle and/or its affiliates. All rights reserved.
制限付権利の説明
このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。
ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。
このソフトウェアまたは関連ドキュメントが、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供される場合は、次のNoticeが適用されます。
U.S. GOVERNMENT RIGHTS
Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
このソフトウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアを危険が伴うアプリケーションで使用する際、このソフトウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。
OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。
このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。
