Comments
Description
Transcript
Oracle9i データベース・リソース・ マネージャ
Oracle9i データベース・リソース・ マネージャ Oracleテクニカル・ホワイトペーパー 2001年6月 Oracle9iデータベース・リソース・マネージャ はじめに ..............................................................................................................3 システムおよびリソースの管理 ......................................................................3 リソース・プランおよびポリシーの策定 ......................................................3 リソース・プランとリソース・コンシューマ・グループ......................3 リソース割当てポリシー..............................................................................4 長時間実行の操作により消費されるリソースの事前管理......................4 ネストしたリソース・プラン......................................................................4 データベース・リソース・マネージャの使用例 ..........................................5 OLTPアプリケーション................................................................................5 パッケージ・アプリケーション..................................................................7 データ・ウェアハウス..................................................................................8 柔軟で適応性の高いリソース管理 ..................................................................8 データベース統合..........................................................................................9 まとめ ................................................................................................................10 Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 2 Oracle9i データベース・リソース・マネージャ はじめに アプリケーションおよびデータベースのパフォーマンス、拡張性および 可用性の維持にとって重要なことは、容易にかつ正確にシステム管理と リソース管理ができることです。Oracle8iではデータベース・リソー ス・マネージャが導入され、データベース管理者が定義したビジネス上 の優先順位に従ってシステム・リソースを適用することにより、データ ベース操作に優先順位を付けられるようになっています。Oracle9iでは サービス・レベルの目標を達成するためにデータベース・リソースを自 動的にかつ事前に管理できるようにする新機能が搭載され、データベー ス・リソース・マネージャが大きく拡張されています。 システムおよびリソースの管理 データベースの可用性には、データベースの機能とパフォーマンスの両 方が含まれます。データベースが使用可能であっても、ユーザーが必要 とするパフォーマンス・レベルが得られない場合、可用性およびサービ ス・レベルの目標は達成されていません。データベースにアクセスする 様々なアプリケーション間でリソースがどのように配分されているかに より、アプリケーション・パフォーマンスは大きく左右されます。 Oracle8iデータベース・リソース・マネージャでは、管理者がデータ ベースのユーザーおよびアプリケーション間にCPUを割り当てられるだ けでなく、操作の並列度を制限することができます。データベース・リ ソース・マネージャを使用すると、全体的な企業目標を達成するため に、1人のユーザーのリソース消費を別のユーザーと均衡化し、それぞ れのタスクの優先度に基づいてシステム・リソースをパーティション化 することができます。Oracle9iでは、リソースを大量に消費する操作を データベース・リソース・マネージャが自動的に検出してそのリソース 消費を制限し、システム全体のパフォーマンス低下を防ぐことができま す。極端な場合、操作が許容できないほど長時間実行されてシステム・ リソースが大幅に消費されることが予想されるときなどは、その操作を 開始しないようにすることもできます。 リソース・プランおよびポリシーの策定 リソース・プランとリソース・コンシューマ・グループ データベース・リソース・マネージャは、データベース管理者が指定す るリソース・プランに基づいてユーザーまたはアプリケーション間にリ ソースを割り当てます。リソース・プランは、様々なアクティブ・ユー ザーまたはアクティブ・アプリケーション間でリソースをどのように配 分するかを指定するディレクティブで構成されます。ユーザーまたはア Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 3 プリケーションは、それぞれのリソース要件およびビジネス優先順位に 基づいて、異なるリソース・コンシューマ・グループに分類されます。 Real Application Clusters（RAC）環境では、グループ・メンバーのイン スタンスに異なるリソース・プランを割り当てて、異なるワークロード をサポートするように調整できます。たとえば、ノードが2つのクラス タでは、リソースのほとんどをオンライン・ユーザーに割り当てるリ ソース・プランを片方のインスタンスで使用し、リソースのほとんどを バッチ操作に割り当てる別のプランをもう一方のインスタンスで使用で きます。これにより、複数の異なるアプリケーションまたはユーザーが 相互に影響せずに同一データベースを使用できます。 リソース割当てポリシー 管理者は、リソース・プラン・ディレクティブを使用して、様々なリ ソース・コンシューマグループにリソースをどのように配分するかを指 定できます。たとえば、優先順位が高、中、低のリソース・コンシュー マ・グループに対して、それぞれ80、15、5の割合でシステムCPUリ ソースを配分するようなリソース・プランを作成できます。ユーザーま たはアプリケーションが使用できるリソースは、それぞれが属するリ ソース・コンシューマ・グループに割り当てられているリソースに依存 します。様々なデータベース・ユーザーまたはアプリケーションを異な るリソース・コンシューマ・グループ間に分類するのは、リソース・プ ランの作成時に行います。ただし、これは管理者が定義した基準に基づ いて、データベース・リソース・マネージャにより動的に変更すること もできます。たとえば、実行中セッションの操作が5分以内に終了しな い場合、そのセッションを高優先順位から中優先順位のリソース・コン シューマ・グループに自動的に移動できます。 長時間実行の操作により消費されるリソースの事前管理 長時間実行される操作に関して、同時にアクティブにできるセッション 数を制限することもできます。したがって、中優先順位または低優先順 位の操作をたとえば4つ以上同時に実行しないように、データベース・ リソース・マネージャに指示することができます。このようなグループ に属するアクティブ・セッション数が3を超えると、新規セッションは キューに入れられ、実行中の3つの操作のいずれかが完了した場合にの み実行が許可されます。さらに、データベース・リソース・マネージャ は操作の実行を開始する前にその実行時間を予測することができるの で、データベース管理者はこの機能を使用して、極端に長時間のリソー ス集中型の操作を開始しないようにすることができます。このために は、リソース・コンシューマ・グループを参照するプラン・ディレク ティブに予想実行時間の上限を指定します。 このような機能により、管理者は長時間のバッチ操作で消費されるリ ソースを事前に制限し、オンライン・ユーザーに影響を与えないように することができます。 ネストしたリソース・プラン プラン内に含まれるプラン、つまりサブプランを定義できます。サブプ ランを使用すると、アプリケーション内でリソースをさらに分割できま Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 4 す。また、使用可能なCPUリソースをリソース・プラン内で複数のレベ ルに割り当てることもできます。レベルを使用して、リソース・コン シューマ・グループの割当て制限と、未使用CPUリソースをどのように 配分するかを指定します。 データベース・リソース・マネージャのこのような機能により、データ ベース管理者はデータベース・リソースの配分に関して今までにないレ ベルの制御を行うことができ、非常に単純かつ強力なリソース割当てポ リシーを実装できます。 データベース・リソース・マネージャの使用例 OLTPアプリケーション アプリケーション データベース・リソース・マネージャが実際にどのように使用されるか を示すために、銀行のATMアプリケーションでの使用を検討してみま しょう。このようなアプリケーションの第1の目標は、ATMユーザーに 対して迅速かつ予測可能な応答時間を保証することです。同時に、この アプリケーションをサポートするデータベースは、月次または年次（あ るいはその両方の）アクティビティの要約といった他のバッチ処理の実 行にも使用できます。このような操作がATMユーザーへの応答時間に悪 影響を与えないようにするために、次のようなリソース・プランを作成 できます。 リソース・コンシューマ・ CPUリソース割当て リソース割当て グループ ATMユーザー 90% バッチ処理 10% 表1: 銀行アプリケーションのリソース・プラン このプランは、バッチ処理操作のリソース使用の上限を10%に抑えて、 システムCPUリソースの少なくとも90%がATMユーザー向けサービスで 使用できるようにしています。ただし、システム上で他のアクティビ ティが発生していない（つまり、バッチ操作がCPUリソースをまったく 消費していない）場合は、CPUリソースの100%すべてがATMユーザー 向けサービスで使用されます。 異なるクラスのATMユーザー間にどのようにリソースを割り当てるかを 指定して、このプランをさらに細かく調整することができます。この銀 行では、顧客の預金額に応じて顧客を2つのグループ（得意顧客と通常 顧客）に分類しているものとします。得意顧客により良いサービスを提 供するために、「ATMユーザー」サブプランを作成します。このサブプ ランは、ATMユーザーに割り当てられるリソースをさらにどのように再 分割するかを制御します。この例では、得意顧客にはATMユーザー・リ ソースの80%が割り当てられ、通常顧客には残りの20%が割り当てられ ます。 Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 5 図1: 「ATMユーザー」サブプランを指定した銀行アプリケーション・プラン ユーザー」サブプランを指定した銀行アプリケーション・プラン サブプランの使用は、主プランで2種類のATMコンシューマ・グループ を作成するのとは異なります。後者の場合、得意顧客に割り当てられた リソースで未使用の分は、バッチ・ユーザーを含む他のリソース・コン シューマ・グループのすべてに配分されます。「ATMユーザー」サブプ ランにより、得意顧客リソース・コンシューマ・グループで使用されて いないリソースは、他のリソース・コンシューマ・グループに渡される 前に、まずATM通常顧客に提供されます。 これまで説明してきたリソース・プランでは、CPUリソースを単一レベ ルに割り当てます。つまり、サブプランまたはリソース・コンシュー マ・グループにより使用されていない割当ては、他のサブプランまたは リソース・コンシューマ・グループ間で比例配分されます。この銀行で 第3のリソース・コンシューマ・グループをこのプランに追加し、CPU リソースの少なくとも5%を顧客用通知書の出力に使用できるようにす るものとします。ATMユーザーが使用していないリソースは、バッチ処 理用に使用可能にされる前に、まず通知書出力用に提供する必要があり ます。これを行うには、次に示されているような複数レベルのプランを 作成します。 リソース・コンシューマ・ グループ 「ATMユーザー」 サブプラン 顧客通知書の出力 バッチ・ユーザー レ ベ ル 1 の CPU レ ベ ル 2 の CPU リソース割当て リソース割当て 90% 0% 0% 5% 100% 0% 表2:複数 複数レベルの銀行アプリケーション・プラン 複数レベルの銀行アプリケーション・プラン 改訂されたこのプランは、レベル1へのリソース割当ての上限を95%に 抑えて、CPUリソースの少なくとも5%が顧客通知書の出力で使用できる ようにしています。レベル1に割り当てられていないリソースまたはレ Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 6 ベル1で消費されないリソースは、レベル2のリソース・コンシューマ・ グループまたはサブプランで使用可能にされます。したがって、ATM ユーザー割当て分で未使用のリソースは、バッチ処理で使用可能にされ る前に、まず通知書出力用に使用可能にされます。CPUリソースを90、 5、5％の割合で分割する単一レベルのプランを作成していたとすると、 ATMユーザーに割り当てられたリソースで未使用の分は、通知書出力と バッチ・ユーザーとの間で均等に配分されていたはずです。 パッケージ・アプリケーション パッケージ化されたERPまたはCRMアプリケーションをサポートする データベースの場合、その要件は銀行データベースでの要件とはかなり 異なります。トランザクションが短く応答時間が予測可能であるという 特性を持つATMアプリケーションをサポートするデータベースとは異な り、ERPデータベースのワークロードは極めて多様です。短いトランザ クションと長時間実行されるバッチ・ジョブ（大規模なパラレル問合せ など）とが混在する可能性があります。また、ATMデータベースとは異 なり、前もってトランザクションを分類しておけない可能性もありま す。このようなシステムの目標は、バッチ・ジョブで消費されるリソー スを制限して、OLTPユーザーには迅速に応答することです。この目標 を達成するために、次のようなプランを作成できます。 初期 リソース コンシューマ グループ OLTP CPU % BATCH 30% 同時アクティ 同時アクティ ブ・セッショ ンの最大数 切替えリソース コンシューマ グループ 最長実行予 測時間 切替えグループ = BATCH 切替え時間 = 3分 70% 5 12時間 表3: パッケージ・アプリケーション・プラン このプランでは、ワークロードをOLTPとBATCHという2つのグループ に分類します。優先順位の高いOLTPグループにはCPUリソースの70%が 割り当てられ、BATCHグループには残りの30%とOLTP割当ての未使用 分が割り当てられます。OLTPグループでは、操作の実行時間は最長3分 です。操作がこの時間内に完了しないと、操作はBATCHグループに自 動的に切り替えられ、その分のCPUリソースの割当てが減ります。リ ソース・コンシューマ・グループを自動的に切り替えるこの機能によ り、Oracle9iデータベース・リソース・マネージャでは長時間実行され ている操作を検出して、システム全体のパフォーマンスに対する影響を 低く抑えることができます。 バッチ・ジョブにはCPUリソースの一部しか割り当てられないので、 バッチ・ジョブが多数同時に実行される場合は、ジョブが完了しない可 能性があります。これを防ぐために、このプランでは、同時にアクティ ブにできるBATCHグループの最大セッション数を5に制限しています。 この最大値に達すると、他のBATCHグループのセッションはすべて キューに入れられ、実行中の5つのジョブのいずれかが完了した場合に のみ実行が許可されます。最後に、12時間を超えて実行される可能性の Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 7 あるバッチ・ジョブは、実行を開始できません。これにより、潜在的な 不正操作をデータベースが事前に阻止できます。 この例は、データベース・リソース・マネージャを使用するとデータ ベース管理者はシステム・リソースをどのように配置するかを制御でき るため、ハードウェア投資に対する収益率の最大化にはデータベース・ リソース・マネージャが威力を発揮することを示しています。さらに、 データベース・リソース・マネージャはリソース使用を自動的かつ事前 に制御し、人的介入を最小限に抑えてサービス・レベルの目標を達成し ます。 データ・ウェアハウス データ・ウェアハウスの主な目標はスループットの最大化であり、応答 性はOLTPやERPアプリケーション環境ほど厳密には要求されない場合 があります。データ・ウェアハウスでは、短くて重要な操作をサポート することもありますが、ワークロードのほとんどは長時間実行される問 合せです。 初期 リソース コンシューマ グループ 高優先度 中優先度 CPU % 同時アクティ 同時アクティ ブ・セッショ ンの最大数 60% 30% 20 低優先度 10% 4 切替えリソース コンシューマ グループ 最長実行予 測時間 切替えグループ = 低優先度 切替え時間 = 60分 見積もり時間の使 用 = TRUE SWITCH_ESTIMA 15時間 TE = TRUE 表4: データ・ウェアハウス・プラン このプランを使用すると、重要な操作は「高優先度」リソース・コン シューマ・グループの一部として実行され、CPUリソースの60%が割り 当てられます。ジョブを中優先度または低優先度で実行すべきかどうか を管理者が常に事前に認識できるとは限らないので、重要でない操作は すべて「中優先度」グループで開始されます。1時間内に完了しない場 合、または1時間を超えて実行されると予想される場合、ジョブは「低 優先度」グループに切り替えられます。重要でないジョブで15時間を超 えて実行されると予想されるものは、まったく開始できません。 柔軟で適応性の高いリソース管理 システムは一定の状態では動作しないものです。朝には期待した結果を 上げていたリソース・プランやポリシーが、夕方にはそうでなくなるこ とがあります。このため、データベース・リソース・マネージャの構成 はすべて、データベースの実行中に変更可能です。データベース・イン スタンスを再起動しなくても、プラン、サブプラン、レベル、リソー Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 8 ス・コンシューマ・グループのメンバー、リソース割当てディレクティ ブをすべて動的に変更できます。 したがって、データベース管理者は、様々なリソース・プランおよびリ ソース・コンシューマ・グループを多数データベース内に作成しておく ことができます。このようなプランのいずれかをデフォルトに指定して おくと、データベース起動時にそのプランが自動的にアクティブになり ます。その他のプランは、1日のうち、1か月のうち、または四半期のい つか、あるいは別のリソース割当てスキームが必要になったときに、代 替プランとして使用できます。この機能を使用すると、前述の例で最長 実行予測時間の指定が原因で実行できなかったジョブを、後で実行する こともできます。 データベース・リソース・マネージャが提供するリソース割当てメカニ ズムは、従来の優先順位ベースのスキームよりも格段に優れています。 CPUリソースの割当てに割合を使用することで、リソース・コンシュー マ・グループのすべてがある程度の最小リソースを必ず受け取るため、 他のグループの需要がどれだけ高くても、欠乏状態になることはありま せん。さらに、リソース割当てポリシーは、ハードウェアに変更があっ てもそのまま使用できます。したがって、データベースが稼働するハー ドウェアやオペレーティング・システムが何であっても、ユーザーまた はアプリケーション間でのリソースの配分はそのまま変わりません。 データベース統合 データベース・リソース・マネージャは、データベース・セキュリ ティ・システムに完全に統合されています。管理者は、PL/SQLイン ターフェースまたはOracle9i Enterprise Managerコンソールのいずれか で、リソース・プランおよびリソース・コンシューマ・グループの作 成、更新または削除を行えます。管理者はデフォルトのコンシューマ・ グループと必要権限をユーザーに割り当てます。ユーザーに必要な権限 が付与されている場合、ユーザーはセッションのリソース・コンシュー マ・グループを切り替えて、セッションで使用可能なリソースを変更で きます。さらに、管理者はユーザーのデフォルト・コンシューマ・グ ループを変更したり、アクティブなセッションをグループ間で動的に移 動することができます。 Oracle9iでは、ハードウェア・リソースの制限の実装でユーザー・プロ ファイルの使用を今後もサポートします。データベース・リソース・マ ネージャは、より洗練された高度なデータベース・リソース管理方法を 提供します。定義されたリソース割当てプランの中で複数の異なるサー ビス要求を均衡化し、長時間実行されるリソース集中型処理のリソース 消費を事前に制御できます。 最後に、動的パラレル度（ADOP）機能では、パラレル操作の最適パラ レル度を選ぶ際に、データベース・リソース・マネージャのリソース割 当てを考慮します。ADOPでは、パラレル問合せやパラレルDML操作の パラレル度を自動的に調整して、システムの使用率を最適化します。 Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 9 図2: データベース・リソース・マネージャを管理するOracle Enterprise データベース・リソース・マネージャを管理する Managerインタフェース インタフェース まとめ 従来、データベース・リソースへのアクセスに関しては、すべてのユー ザーとアプリケーションに同じアクセスが提供されてきました。ほとん どの場合はこの方法で問題はありませんが、これでは基本的なビジネ ス・ニーズがまったく考慮されていません。つまり、エンタープライズ ではアクティビティによって重要度が違うということです。Oracle8iで データベース・リソース・マネージャが導入され、エンタープライズの アプリケーションおよびユーザーに対して釣り合いの取れたデータベー ス・サービスを保証するリソース割り当てポリシーをデータベース管理 者が初めて実装できるようになりました。Oracle9iでの拡張により、 データベース・リソース・マネージャはより自動化され、より強力にな り、予防性が高くなっています。Oracle9iデータベース・リソース・マ ネージャを使用すると、人的介入を最低限に抑えつつ、予想されたサー ビス・レベルを極めて容易に提供し、パフォーマンスに影響を与えずに システムの拡張性をほとんど無制限に拡大できます。 Oracle9iデータベース・リソース データベース・リソース・マネージャ データベース・リソース・マネージャ 10 Oracle9iデータベース・リソース・マネージャ データベース・リソース・マネージャ 2001年 年6月 月 著者: 著者 Sushil Kumar 協力者: 協力者 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 世界共通窓口: 世界共通窓口 Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com オラクル社は、インターネットを推進するソフトウェアを提供します。 Oracleは米国オラクル社の登録商標です。 は米国オラクル社の登録商標です。 本書で引用される多くの製品名とサービス名は、米国オラクル社の 商標である場合があります。 その他記載された企業名および製品名は、識別のためにのみ 掲載されており、それぞれの所有者の商標または登録商標です。 版権 © 2001 Oracle Corporation 無断転載を禁ず