Exadata取り組みを複雑にしている問題の1つにアプリケーションが単一なハードウェアから統合型のハードウェア・プラットフォームへ移行しているということです。ユーザは1ホストで使用していたアプリケーションは統合型のハードウェア・プラットフォームでは遅くなるという間違った印象を持っています。Monitor)はこのパフォーマンスに関する懸念を解決する手法です。このリソース・マネージャを使用しなければすべてのセッションは均等になり、単一の高活性のベータベースがリソースを独占し、Exadataインプリメンテーションに非常に重要になります。DBRMはユーザが現在も使用している同じリソース・マネジャーです。11GR2での新機能はデータベース・レベルでCPU使用率をプロビジョンするインスタンス・ケージです。これはデータベースの個別インスタンスでCPU使用をケージ、コントロールできるものです。quantum」ウェイト・イベントを確認できます。このイベントが高ければDBRMがアクティブにCPUの消費量を絞っています。リソース·プランがユーザの望むように使用されていることを確認するためには、モニターするためのV$RSRCビューがあります。IORMはExadata専用でデータベース・ロードを分離手助けする方法が2つあります。インターデータベースIORMは優先順位との組み合わせで、データベース名で複数のデータベース間での優先順位を管理します。2つ目はIORMカテゴリで、これは新規アトリビュートですが、データベース名で分離することで利用されます。ユーザは「oltp_category_batch」と呼ぶカテゴリーを作成することができ、これは2CPU用です。次にこれに1対複数のデータベースをアサインすることができます。3つ目のオプション、設定はイントラデータベースです。ExadataではDBRMプランが有効になった時にデータベースはストレージ・グリッド内のすべてのセルにこのプランの記述を転送します。DBRMが最初に作成される限り、これはデフォルトです。どのオプションをユーザが使用しようともIORMはストレージセル・レベルで管理されます。各セルディスクで「cellsrv」はセルにアサインされた各データベース用の各コンシューマ・グループと各バックグラウンド・プロセス用のIORMキューを保持します。Cacheとは別のものです。Cacheは追加の5TBデータベースを提供し、2つの方法で使用されます。1つ目はキャッシュをより推奨された構成で構成します。CacheはASMが使用できるソリッド・ステート・ディスクとして分割します。これはこのストレージ用としての推奨使用方法ではありませんが、設定方法インストラクションはあります。Cacheと対比してパフォーマンスを最小限に抑えられます。これを使用するにはイニシャル・パラメータ「cell_flash_cache=keep」を設定する必要があります。「Cellcli」はv$sysstat同様にフラッシュ・キャッシュ使用をモニターに使用できます。WordPress.。