Oracle® Database

Quality of Service Managementユーザーズ・ガイド

12cリリース1 (12.1)

B71294-06(原本部品番号:E49047-07)

2017年1月

Oracle Database Quality of Service Managementユーザーズ・ガイド, 12cリリース1 (12.1)

B71294-06

Copyright © 2014, 2017, Oracle and/or its affiliates.  All rights reserved.

原本著者: Janet Stern

原本協力者: Mark Scardina

原本協力者: Troy Anthony、Mark Bauer、Janet Blowney、Annie Flint、Barry Gleason、Roland Knapp、Barb Lundhild、John McHugh、Markus Michalewicz、Ganesh Padmanabhan、Daniel Semler、Peter Sharman、Richard Strohm、Mark Townsend、Li Weng、Douglas Williams

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracleおよびその関連企業の登録商標です。その他の名称は、他社の商標の可能性があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このリリースのOracle Database Quality of Service Managementにおける変更

- Oracle Database QoS Management 12cリリース1 (12.1.0.2)での変更点

- 新機能

- Oracle Database QoS Management 12cリリース1 (12.1.0.1)での変更点

- 新機能

- 非推奨となった機能

- サポートされない機能

- その他の変更

1 Oracle Database QoS Managementの概要

- Oracle Database QoS Managementとは

- Oracle Database QoS Managementを使用する利点

- Oracle Database QoS Managementの概要

- Oracle Database QoS Managementの動作

- Oracle Database QoS Managementとサーバー・プール

- Oracle Database QoS Managementとインスタンス・ケージング

- Oracle Database QoS Managementとサービス

- ポリシー・セットの概要

- サーバー・プールの概要

- Oracle Database QoS Managementがサーバー・プールを使用する方法

- パフォーマンス・クラスの概要

- パフォーマンス・クラス・タグ

- 作業リクエストへの分類子の適用

- 作業リクエストを分類するための追加フィルタの使用方法

- 新規パフォーマンス・クラスの作成の決定

- パフォーマンス・ポリシーとパフォーマンス目標の概要

- パフォーマンス目標の概要

- サーバー・プールのディレクティブ・オーバーライドの概要

- パフォーマンス・クラスのランクの概要

- Oracle Database QoS Managementポリシー・ワークロードの重要性によるデータベースの起動順序の決定

- Oracle Database QoS Managementがパフォーマンス・データを収集および分析する方法

- 推奨の概要

- Oracle Database QoS Managementが推奨を生成する方法

- 推奨のタイプ

- コンシューマ・グループの昇格と降格

- CPU数の変更

- サーバー・プール間でのサーバーの移動

- 最適な推奨の選択

- 推奨の内容

- 推奨の実装の概要

- 例: 推奨の生成方法

- Oracle Database QoS Managementの管理対象

- サービス・レベルを満たすためのデータベース・リソースの管理

- データベース・サービス

- Oracle Database Resource Manager

- Oracle Clusterware

- 実行時接続ロード・バランシング

- 高可用性管理とOracle Database QoS Management

- メトリックの概要

- パフォーマンス・メトリック

- リソース・メトリック

- パフォーマンス満足度メトリック

- パフォーマンスの問題を識別するためのメトリックの使用方法

2 サポートされるワークロードと方針

- Oracle Database QoS Managementでサポートされる構成

- サポートされるサーバー・プール構成

- サポートされるデータベース構成

- サポートされるサービス構成

- サポートされるワークロードと目標のタイプ

- パフォーマンス・クラスの分類子の作成方針

- 効果的なリソース管理のための構成方針

- リソース・ボトルネックについて

- CPUリソース・ボトルネック

- グローバル・キャッシュ・リソース・ボトルネックの構成の推奨

- I/Oリソース・ボトルネックの構成の推奨

- その他のタイプのボトルネックの構成の推奨

- Oracle Database QoS Managementの実装例

- デモ・システムの説明

- システム・ワークロードの説明

- 初期のOracle Database QoS Management構成

- デモ・システムのOracle Database QoS Managementパフォーマンス・ポリシーの作成

- Oracle Database QoS Managementでのサービス・レベルの管理

3 Oracle Database QoS Managementのインストールおよび有効化

- Oracleデータベースのワークロードを管理するためのOracle Database QoS Managementの構成

- クラスタ用Oracle Grid Infrastructureのインストールおよび構成

- サーバー・プールの作成および構成

- Oracle RACデータベースの作成および構成

- データベース初期化パラメータの変更

- データベース・サービスの作成

- Oracle Database QoS Management管理者のアカウントの作成

- Oracle Database QoS Managementの有効化

- データベース・レベルでのOracle QoS Managementの有効化

- 初期ポリシー・セットの作成

- クラスタ・レベルでのOracle QoS Managementの有効化

4 Oracle Database QoS Managementシステムの管理

- Oracle Database QoS Managementが有効になっているかどうかの判断

- データベースの有効ステータスの確認

- クラスタの有効ステータスの確認

- Oracle Database QoS Managementでのパフォーマンスの監視

- Oracle Database QoS Managementダッシュボードの使用方法

- Oracle Database QoS Managementダッシュボードへのアクセス

- クラスタに対するOracle Database QoS Managementの有効化

- クラスタに対するOracle Database QoS Managementの無効化

- パフォーマンス概要グラフの解釈

- 推奨の表示

- 推奨の詳細の表示

- 推奨の実装

- ポリシー・セットの管理

- ポリシー・セットの編集

- ポリシー・セットへのサーバー・プールの追加

- サーバー・プール設定の変更

- ポリシー・セットへのデータベース・サービスの追加

- ポリシー・セットを更新して新規データベースを追加

- パフォーマンス・クラスの管理

- パフォーマンス・クラスの作成

- パフォーマンス・クラスの削除

- パフォーマンス・クラス名の変更

- 既存のパフォーマンス・クラスの編集

- 分類子の追加

- 分類子の変更

- 分類子の削除

- 分類子の評価順序の指定

- パフォーマンス・ポリシーの管理

- パフォーマンス・ポリシーの作成とパフォーマンス目標の指定

- 既存のパフォーマンス・ポリシーの編集

- パフォーマンス・ポリシーのコピー

- 現在のパフォーマンス・ポリシーの設定

- ダッシュボードからのアクティブなパフォーマンス・ポリシーの変更

- ポリシー・セット・エディタ・ウィザードからのアクティブなパフォーマンス・ポリシーの変更

- QOSCTLを使用したアクティブなパフォーマンス・ポリシーの変更

- パフォーマンス・ポリシーの削除

- パフォーマンス・ポリシーに対する推奨の自動実装

- サーバー・プールのディレクティブ・オーバーライドの設定

- パフォーマンス・メトリックの確認

- すべてのパフォーマンス・クラスのパフォーマンス・メトリックの表示

- 個々のパフォーマンス・クラスのパフォーマンス・メトリックの表示

- 「サービスのクオリティ管理」イベントのアラートの構成

- リソース待機時間のブレークダウンの表示

- Oracle Database QoS Managementの管理ユーザーの作成

- QOSCTLユーティリティのリファレンス

- Oracle Database QoS Managementのリソース・プランの編集

5 Oracle Database QoS Managementのトラブルシューティング

- 一般的な問題

- Oracle Database Quality of Service Managementを有効にできない

- データベースに対してOracle Database QoS Managementを有効にできない

- Oracle Database Resource Managerが有効にならず、リソース・プランがエラーになる

- サーバー・プールにアクセスできない

- サーバー・プールが管理不能としてマークされる

- パフォーマンス・クラスのメトリックがない

- Oracle Database QoS Managementが推奨を生成しない

- 最近追加したサーバーが不適切なサーバー・プールに配置されている

- RMIポートの競合が検出される

- ログまたはトレース・ファイルの特定

- トレースの有効化

用語集

索引

図一覧

- 1-1 インスタンス・ケージングとCPUスライス

- 1-2 Oracle Database QoS Managementポリシー・セットの要素

- 1-3 サーバー・プール、Oracleデータベースおよびデータベース・サービスのダイアグラム

- 1-4 サーバー・プールとCPUスライス

- 1-5 パフォーマンス・ポリシーによるベースライン・リソース管理

- 1-6 Oracle Database QoS Managementサーバー・アーキテクチャのダイアグラム

- 1-7 推奨されるアクションの分析例

- 2-1 サンプル・ワークロードの図

- 4-1 測定のみパフォーマンス・クラスのパフォーマンス満足度メトリック

- 4-2 Oracle Database Quality of Service Managementのダッシュボード

- 4-3 「パフォーマンス概要」のグラフの例

- 4-4 パフォーマンス目標を満たしていないパフォーマンス・クラスを示す「パフォーマンス概要」ページ

はじめに

Oracle Database Quality of Service Managementユーザーズ・ガイドへようこそ。このドキュメントでは、Oracle Database Quality of Service Management(Oracle Database QoS Management)の概念と、Oracle Database QoS Managementの構成、管理およびトラブルシューティング方法について説明します。Oracle Database QoS Managementでは、リソースの使用率と待機時間を監視し、この情報を使用して、アプリケーション間で共有しているリソースを管理します。Oracle Database QoS Managementでは、指定したパフォーマンス・レベルでアプリケーションの実行を維持するためにシステム構成を調整するように推奨します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Database Quality of Service Managementユーザーズ・ガイド』は、次のタスクを実行するクラスタ管理者、データベース管理者およびシステム管理者を対象としています。

- ハードウェアのプロビジョニングとデプロイ

- Oracle Grid Infrastructureソフトウェアのインストールと共有リソースの割当て

- 共有環境での多様なワークロードのパフォーマンス管理

- 障害発生時のワークロードの管理

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Database 12cリリース1 (12.1)ドキュメント・セットの次のドキュメントを参照してください。

- 『Oracle Grid Infrastructureインストレーション・ガイド for Linux』またはその他のサポートされるプラットフォーム

- 『Oracle Clusterware管理およびデプロイメント・ガイド』

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

- 『Oracle Database管理者ガイド』

- 『Oracle Database概要』

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このリリースのOracle Database Quality of Service Managementにおける変更

この章では、Oracle Database Quality of Service Managementにおける変更を示します。

- Oracle Database QoS Management 12cリリース1 (12.1.0.2)での変更点

- Oracle Database QoS Management 12cリリース1 (12.1.0.1)での変更点

Oracle Database QoS Management 12cリリース1 (12.1.0.2)での変更点

Oracle Database 12cリリース1 (12.1.0.2)の『Oracle Database Quality of Service Managementユーザーズ・ガイド』における変更は次のとおりです。

新機能

- 許可された自動アクション
この機能では、Oracle Quality of Managementサービスがリソース別およびポリシー別に実行できる認可された自動アクションを指定できます。認可された自動アクションを指定することで、推奨アクションに人間が対応する必要がなくなるため、SLAを危険にさらす需要の急増やノードの障害に対処するレスポンス時間が改善されます。

「パフォーマンス・ポリシーに対する推奨の自動実装」を参照してください

- Oracle Database QoS管理をアクティブにする必要がないメモリー・ガード
このリリースでは、Oracle Database QoS Managementを使用しているかどうかにかかわらず、Memory Guardはデフォルトで有効です。メモリー・ガードはノードのメモリー不足を検出し、既存のワークロードが縮小してメモリーが解放されるまで、新しいセッションを他のインスタンスに送ります。ノードの空きメモリーが増えると、自動的にサービスが再び新しい接続を受け入れられるようになります。

Memory Guardの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- Oracle Database QoS Managementを監視モードで実行している場合にパフォーマンス関連アラートを生成
Enterprise Managerポリシー・エディタで、パフォーマンス・クラスにゼロ以外のパフォーマンス目標(PO)を設定し、さらに「測定のみ」ボックスを選択できるようになりました。以前のリリースでは、「測定のみ」が選択されている場合、PO値は無視されたため、管理者はパフォーマンス目標に対してワークロードがどの程度適切に実行されたかを測定できませんでした。

このリリースでは、POとして正の値が指定され、「測定のみ」ボックスが選択されている場合、Oracle Database QoS Managementはパフォーマンス満足度メトリック(PSM)を算出します。POに違反している場合、Oracle Database QoS Managementはリソースを識別してアラートを生成します。

詳細は、「メトリックの概要」を参照してください。

- アクティブなOracle Database QoS Managementパフォーマンス・ポリシーの順序によってOracle RACデータベースの起動順序を決定
ユーザー作成のOracle Database QoS Managementポリシーがアクティブな場合、パフォーマンス・クラスのランク付けされた順序により、最初に起動するOracle RACデータベースまたはリクエスト・リアルタイムLMSプロセス・スロットが決定されます。データベース内のすべてのパフォーマンス・クラスでMax(Ranks)を使用することにより、各データベースのビジネスの重要度を一貫性のある表現で示すことができます。

- 測定のみモードでの管理者管理型データベースのサポート
Oracle Quality of Management Serviceでは、管理者管理型データベースのデータベース・ワークロードの測定と監視をサポートしています。これにより、パフォーマンスのリアルタイム監視およびボトルネックの識別が大幅に強化されます。データベース・スキーマやデータベース内部に精通している必要はありません。

Oracle Database QoS Management 12cリリース1 (12.1.0.1)での変更点

Oracle Database 12cリリース1 (12.1.0.1)の『Oracle Database Quality of Service Managementユーザーズ・ガイド』における変更は次のとおりです。

新機能

- MemoryGuard
MemoryGuardは、メモリー不足によりノードが削除または再起動されるのを防ぎ、ワークロード高負荷またはログイン・ストームを影響を受けたクラスタの高可用性を向上させます。

- サーバー・プール・カテゴリ定義およびCRSポリシー・セットとの統合のサポート
Oracle Quality of Management Serviceは、サーバー・プールのカテゴリ化の使用をサポートします。これにより、特定の属性で識別されているサーバーを特定することで、サーバー・プールを使用してサーバーを動的に管理できるため、異機種間ノードで構成されるクラスタに特に有益です。

サーバー・カテゴリおよびサーバー・プールの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- CDBおよびPDBの監視のサポート
測定のみモードで、Oracle QoS Managementをコンテナ・データベース(CDB)およびプラガブル・データベース(PDB)とともに使用できます。

コンテナ・データベースおよびプラガブル・データベースの詳細は、『Oracle Database概要』および『Oracle Database管理者ガイド』を参照してください。

- 測定のみモードでサポートされるカスタム・リソース・プラン
データベースが測定のみモードに設定される場合、Oracle Quality of Service Managementとともにカスタム・データベース・リソース・マネージャ・プランを使用できます。

- グリッド管理リポジトリは、Oracle Quality of Service Managementの必須要件です。
Oracle Database 12cのOracle Quality of Service Managementでは、Oracle Clusterware 12cをインストールまたはアップグレードする場合にグリッド管理リポジトリを構成する必要があります。

非推奨となった機能

- QOSCTLユーティリティの-checkpasswdオプション

サポートされない機能

このドキュメントで以前に記載されていた機能の一部が、Oracle Database 12cリリース1ではサポートされていません。サポートされない機能のリストは、『Oracle Databaseアップグレード・ガイド』を参照してください。

その他の変更

- Oracle Enterprise Manager Database Controlは、このリリースに含まれていません
以前のリリースのOracle Databaseでは、Oracle Enterprise Manager Database Controlがこのマニュアルで説明されているプライマリ・データベース管理ツールでした。現在、このマニュアルでは、Oracle Enterprise Manager Cloud Control 12cがプライマリ・インタフェースとして説明されています。

1 Oracle Database QoS Managementの概要

この章では、Oracle Database Quality of Service Management(Oracle Database QoS Management)の概要について説明します。この章の内容は次のとおりです。

- Oracle Database QoS Managementとは

- Oracle Database QoS Managementを使用する利点

- Oracle Database QoS Managementの概要

- Oracle Database QoS Managementの管理対象

- メトリックの概要

Oracle Database QoS Managementとは

多くの企業では、データ・センターのコンピュータ・システムを統合し、標準化しています。アプリケーションごとに個別のサーバーを使用するかわりに、クラスタ化したデータベースで複数のアプリケーションを実行します。また、アプリケーションをインターネットに移行することで、オープン・ワークロードの管理の問題が発生しました。オープン・ワークロードは要求のサージに影響されるため、システムがオーバーロードし、完全には予想または計画できない新しいタイプのアプリケーション障害がもたらされる可能性があります。このような環境でターゲット・サービス・レベル内のアプリケーションの可用性とパフォーマンスを維持するには、次のことを実行する必要があります。

- リソースのプール。

- パフォーマンス・ボトルネックをリアルタイムで検出する管理ツールの保持。

- 要求の変化に対応するためのリソースの再割当て。

Oracle Database QoS Managementは、システム全体のワークロード・リクエストを監視する自動化されたポリシーベースの製品です。Oracle Database QoS Managementは、アプリケーション間で共有されるリソースを管理し、システム構成を調整して、アプリケーションの実行をビジネスに必要なパフォーマンス・レベルに維持します。Oracle Database QoS Managementは、システム構成および要求で発生した変更に対応し、アプリケーションのパフォーマンス・レベルがそれ以上変動することを回避します。

Oracle Database QoS管理は、ターゲット・システムの各作業リクエストのパフォーマンスを監視します。Oracle Database QoS Managementは、作業リクエストがデータベース・サービスを使用してデータベースへの接続をリクエストした時点で作業リクエストの追跡を開始します。作業リクエストの完了に必要な時間、つまりレスポンス時間(エンドツーエンドのレスポンス時間またはラウンドトリップ時間とも呼ばれます)は、データのリクエストが開始された時点からデータ・リクエストが完了した時点までの時間です。レスポンス時間の2つの構成要素、つまりリソースの使用に費やした時間とリソースの使用の待機に費やした時間を正確に測定することで、Oracle Database QoS Managementはシステム内のボトルネックを迅速に検出できます。その後、Oracle Database QoS Managementは、ボトルネックを緩和してサービス・レベルを維持または復元するためのリソースの再割当てを提案します。

Oracle Database QoS Managementは、次の目的でシステムのリソースを管理します。

- 要求を満たすのに十分なリソースが使用可能な場合は、ワークロードが変化した場合でも、アプリケーションに対するビジネスレベルのパフォーマンス要件が満たされるようにします。

- 要求を満たすのに十分なリソースが使用可能でない場合、Oracle Database QoS Managementは重要度の低いパフォーマンス要件を犠牲にして、より重要度の高いビジネス・パフォーマンスを満たそうとします。

Oracle Database QoS Managementを使用する利点

一般的な企業では、アプリケーションのレスポンス時間が許容レベル内にない場合、問題の解決に非常に時間がかかることがあります。多くの場合、管理者が行う最初の質問は、「システムは正しく構成されているか。パラメータを変更して問題を解決できるか。ハードウェアの追加が必要か」です。残念ながら、これらの質問に正確に回答するのは非常に困難です。その結果、非生産的でフラストレーションの多い実験を何時間にもわたって行うことになります。

Oracle Database QoS Managementには次の利点があります。

- Oracle Real Application Clusters(Oracle RAC)リソースを管理するシステム管理者の時間と費用の要件が軽減されます。

- パフォーマンス低下の回数の削減に役立ちます。

- アプリケーションのパフォーマンスを制限または低下させる問題の解決に必要な時間を短縮します。

- ワークロードが変化したときでもシステムを安定させます。

- サーバーの追加または削除をアプリケーションに対して透過的にします。

- サーバー障害がシステムに与える影響を低減します。

- サービス・レベル合意(SLA)が満たされるようにします。

- ハードウェア・リソースをより効果的に共有できるようにします。

Oracle Database QoS Managementは、クラスタ内のアプリケーションによって共有されるリソースの管理に役立ちます。Oracle Database QoS Managementは、パフォーマンス・ボトルネックの識別と解決を支援できます。Oracle Database QoS Managementは、アプリケーションまたはデータベースのパフォーマンスの問題を診断またはチューニングしません。アプリケーションのパフォーマンスをチューニングする場合、目標は最適なパフォーマンスの実現です。Oracle Database QoS Managementはアプリケーションのより高速な実行を追求するのではなく、アプリケーションが最適なパフォーマンス・レベルで稼働することを妨げる障害を排除します。

Oracle Database QoS Managementの概要

ここでは、システムでOracle Database QoS Managementがどのように動作し、ワークロードのパフォーマンスをどのように評価するかについて簡単に説明します。

- Oracle Database QoS Managementの動作

- ポリシー・セットの概要

- サーバー・プールの概要

- Oracle Database QoS Managementがサーバー・プールを使用する方法

- パフォーマンス・クラスの概要

- パフォーマンス・ポリシーとパフォーマンス目標の概要

- Oracle Database QoS Managementがパフォーマンス・データを収集および分析する方法

- 推奨の概要

Oracle Database QoS Managementの動作

Oracle Databaseでは、特定のワークロード専用のサーバー・グループでサービスを開始することにより、サービスを使用してシステムのワークロードを管理できます。たとえば、データベース層では、あるサーバー・グループをオンライン・トランザクション処理(OLTP)専用にし、別のサーバー・グループをアプリケーション・テスト専用にし、第3のサーバー・グループを内部アプリケーション専用にすることができます。システム管理者は、データベース・サービスを実行できるサーバーの数を手動で変更することで、リソースを特定のワークロードに割り当てることができます。

このようにサーバー・グループを使用すると、あるワークロードの要求のサージ、障害およびその他の問題が他のワークロードに影響することを防ぐために、ワークロードは相互に分離されます。しかし、このタイプのデプロイメントでは、リソースが共有されないため、各ワークロードのピーク要求に対応するために各グループにサーバーを個別にプロビジョニングする必要があります。

Oracle Database QoS Managementでは、次のアクションが実行されます。

1. QoS管理者が作成したポリシーを使用して次の処理を行います。

- 受信した作業リクエストの属性(アプリケーションの接続先のデータベース・サービスなど)を使用して各作業リクエストをパフォーマンス・クラスに割り当てます。

- 各パフォーマンス・クラスの目標レスポンス時間(パフォーマンス目標)を判断します。

- ビジネスにとって最も重要なパフォーマンス・クラスを判断します。

2. すべてのパフォーマンス・クラスのリソース使用率とリソース待機時間を監視します。

3. パフォーマンス・クラスに対して有効になっているパフォーマンス目標に照らして、そのパフォーマンス・クラスの平均レスポンス時間を分析します。

4. 目標のレスポンス時間を超えているパフォーマンス・クラスのパフォーマンスを向上させるリソース再割当ての推奨を生成し、その推奨が実装された場合に各パフォーマンス・クラスのパフォーマンス・レベルに対して予測される影響を分析します。

5. Oracle Database QoS Management管理者から指示された場合に、推奨にリストされているアクションを実装し、システムを評価して、リソースの再割当て後に各パフォーマンス・クラスがそのパフォーマンス目標を満たしているかどうかを確認します。

Oracle Database QoS Managementとサーバー・プール

サーバー・プールを使用し、クラスタ内にサーバーのグループを作成してワークロードを分離できます。いかなる時点においても、1つのサーバーは1つのサーバー・プールにしか所属できません。Oracle Databaseは、単一のサーバー・プールで、または複数のサーバー・プールにまたがって作成できます。Oracle Database QoS Managementは、測定および予測された要求に基づいてサーバーをあるサーバー・プールから別のサーバー・プールに移動するための推奨を作成できます。また、Oracle Database QoS Managementは、現在有効になっているパフォーマンス目標を満たすためにサーバーを再配置することもできます。

関連項目:

サーバー・プールの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

Oracle Database QoS Managementとインスタンス・ケージング

複数のデータベース・インスタンスが1つのサーバーを共有している場合、データベース・インスタンスはサーバーのCPU、メモリーおよびI/O帯域幅を共有する必要があります。インスタンス・ケージングでは、Oracle Database Resource ManagerとCPU_COUNTデータベース初期化パラメータを使用して、Oracleデータベース・インスタンスのCPU使用率を制限します。Oracle Database QoS Managementを使用する場合、サーバーのすべてのインスタンスのCPU_COUNT値の合計を、物理CPUの合計数以下にする必要があります。また、各CPUパーティション、つまりスライスの厚さ(CPU数)は、サーバー・プール内のデータベースの各インスタンスで均一である必要があります。これらの要件により、各データベースの予測可能で分離されたパフォーマンスを確認できます。

図1-1 インスタンス・ケージングとCPUスライス

インスタンス・ケージングを実装すると、Oracle Database QoS Managementで、あるスライスから同一サーバー・プール内の別のスライスへのCPUリソースの再割当てを提案できます。インスタンス・ケージング設定を変更する推奨を実装する場合、Oracle Database QoS Managementは、サーバー・プールのサーバー上で実行されているすべてのデータベース・インスタンスのCPU_COUNTパラメータを均一に変更します。

CPU_COUNTパラメータを変更して、リソース・プランをアクティブ化するようにOracle Database QoS Managementを構成すると、インスタンス・ケージング機能が有効になります。インスタンス・ケージングを使用してインスタンスのCPU使用率に制約を加えると、そのインスタンスはCPUバウンドになる可能性があります。このとき、リソース・マネージャによって、アクティブなリソース・プランに基づき、様々なデータベース・セッション間でのCPU占有率の割当てが開始されます。

Oracle Database QoS Managementとサービス

Oracle RACクラスタでは、Oracle Database QoS Managementはデータベース・サービスが提供されているサーバー・プールとノードを監視します。1つのサービスは1つのサーバー・プールでのみ実行できます。データベースが複数のサーバー・プールにわたる場合、すべてのサーバー・プールのインスタンスにアクセスするために、複数のサービスを作成する必要があります。

ワークロードは、Oracle Clusterwareによって管理されているデータベース・サービスを使用してデータベースに接続するクライアントとアプリケーションについて監視されます。接続では、Java Database Connectivity(JDBC)(シックまたはシン)またはOracle Call Interface(OCI)を使用する必要があります。接続では、ロード・バランシング・アドバイザのランタイム目標がSERVICE_TIMEに設定され、接続ロード・バランシング目標がLONGに設定されているサービスを使用する必要があります。次に例を示します。

srvctl modify service -db db_name -service service_name -rlbgoal SERVICE_TIME
-clbgoal LONG -cardinality UNIFORM

次のように、データベース・サービスのカーディナリティを定義する必要があります。

- サービスが実行されるサーバー・プールの最大サイズが1より大きい(または無制限)場合、サービスのカーディナリティをUNIFORMに設定します。

- サービスが実行されるサーバー・プールの最大サイズが1の場合、サービスのカーディナリティをSINGLETONに設定します。

関連項目:

サービスおよびデータベース・ワークロードの管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

ポリシー・セットの概要

Oracle Database QoS Managementの中心となる概念はポリシー・セットです。ポリシー・セットでは、リソース、パフォーマンス・クラス(ワークロード)、および各パフォーマンス・クラスのパフォーマンス目標を指定する1つ以上のパフォーマンス・ポリシーを指定できます。ポリシー・セットでは、リソースの可用性に対する制約も指定できます。Oracle Database QoS Managementのパフォーマンス・ポリシーは、システム全体で各パフォーマンス・クラスのリソースの可用性を管理し、パフォーマンス・ポリシーに設定されたパフォーマンス目標が満たされるようにします。

Oracle Enterprise Managerを使用してシステムの新しいデフォルト・ポリシーを作成するとき、Oracle Database QoS Managementによってデフォルトの分類ルールおよび関連するパフォーマンス・クラス名が提供されます。たとえば、最初のポリシー・セットを作成するとき、Oracle Database QoS Managementによってクラスタ内のすべてのデータベース・サービスが検出され、各サービスのパフォーマンス・クラスが作成されます。パフォーマンス・クラスには、サービス名の最後に_pcを追加して名前が付けられます。たとえば、サービスの名前がsalesである場合、そのサービスのパフォーマンス・クラスに割り当てられる名前はsales_pcです。

ポリシー・セット内では一度に1つのパフォーマンス・ポリシーをアクティブにできます。パフォーマンス・ポリシーは、カレンダ・スケジュール、メンテナンス・ウィンドウ、イベントなどを使用して特定の要件に対応するようにアクティブにできます。パフォーマンス・ポリシーの詳細は、「パフォーマンス・ポリシーとパフォーマンス目標の概要」を参照してください。

ポリシー・セットを作成する場合は、Oracle Database QoS Managementで管理する必要のあるクラスタ内のサーバー・プールを指定します。(類似するパフォーマンス要件を持つワークロードの分類に使用される)パフォーマンス・クラスも定義します。次に、パフォーマンス・ポリシーを作成して、優先順位が最高のパフォーマンス・クラスと各パフォーマンス・クラスのパフォーマンス目標を指定します。パフォーマンス目標を満たすために、Oracle Database QoS Managementは必要に応じてリソースの再割当てを推奨し、推奨アクションが各パフォーマンス・クラスのパフォーマンス目標を満たす能力に与える影響を予測します。

たとえば、営業時間中のアプリケーション・ワークロードを管理するポリシーを作成できます。顧客が製品またはサービスを購入するために使用するアプリケーションは、この期間中にビジネスに対する優先順位が最も高いアプリケーションです。注文調達および請求アプリケーションにも高い優先順位を指定します。人事およびエンタープライズ・リソース・プランニング(ERP)アプリケーションは、この期間中に優先順位が低いアプリケーションです。オンライン販売アプリケーションで要求のサージが発生する場合は、販売アプリケーションに割り当てるリソースを増やし、重要度の低いアプリケーションに割り当てるリソースを減らすことがOracle Database QoS Managementによって推奨されます。推奨には、各パフォーマンス・クラスに対するパフォーマンスの変化(プラスまたはマイナス)の予測も含まれます。推奨の詳細は、「推奨の概要」を参照してください。

図1-2に示すポリシー・セットは次の要素から構成されます。

- Oracle Database QoS Managementで管理されているサーバー・プール

- 類似するパフォーマンス目標を持つ作業リクエストのグループであるパフォーマンス・クラス

- 次のものを使用してリソースをパフォーマンス・クラスに割り当てる方法を記述するパフォーマンス・ポリシー。

- パフォーマンス目標

- パフォーマンス・クラス・ランク

- サーバー・プールのディレクティブ・オーバーライド

図1-2 Oracle Database QoS Managementポリシー・セットの要素

関連項目:

- 「作業リクエストへの分類子の適用」

- 「初期ポリシー・セットの作成」

- 「ポリシー・セットの管理」

サーバー・プールの概要

ビジネスに対して作成するクラスタ数を決定する場合は、サーバーの統合によって可能になるコストの節約と、統合されたワークロードがある程度有意に相互干渉する危険性とを比較する必要があります。サーバー・プールを導入してクラスタを論理的に分割すると、ワークロードを分離したまま物理的な統合とリソースの機敏性の利点を実現できます。

管理者は、図1-3に示すように、様々なサーバー・プールで実行できるワークロードを定義できます。Oracle RACデータベースに接続するアプリケーションは、そのサーバー・プールに現在割り当てられているサーバー上でのみ稼働するサービスを使用します。たとえば、図1-3では、OSサービスを使用する接続とアプリケーションはHRサーバー・プール内のサーバーにのみアクセスするため、これらの接続によって実行される作業はSalesサービスを使用しているアプリケーションに干渉しません。Oracle Database QoS Managementは、サービス・レベルを満たすためのこれらの各グループ内のリソース割当ての管理、およびビジネス要件の変化に対応するためのリソースの自動的な再配布を支援できます。

図1-3 サーバー・プール、Oracleデータベースおよびデータベース・サービスのダイアグラム

サーバー・プールを使用して、単一エンティティとして管理できるサーバーのグループを作成できます。これらのサーバー・プールで実行するようにデータベースを作成できます。各サーバーがデータベースの単一インスタンスのみを実行する場合、そのデータベースにより多くのリソースが必要な場合は、サーバー・プールに追加のサーバーを割り当てることができます。複数のデータベース・インスタンスが単一のサーバー上で実行されている場合、データベース・インスタンスはそのサーバーの共有リソース(メモリーやCPUなど)を競う必要があります。あるデータベース・インスタンスが他のインスタンスよりもワークロードが大幅に高い場合、そのデータベース・インスタンスによって、同じサーバー上で実行されている他のインスタンスのパフォーマンスが大幅に低下することがあります。

インスタンス・ケージングを使用して、Oracle DatabaseインスタンスのCPU使用率を制限できます。CPU_COUNTパラメータを設定して1つのインスタンスが使用できる最大CPU数を制限することで、サーバー上のデータベース・インスタンス間でCPUをパーティション化して、インスタンスがCPUリソースを過剰に使用するのを防ぐことができます。CPU_COUNT設定は、サーバー・プール内のデータベースの各インスタンスで同じである必要があります。Oracle Database QoS Managementは、サーバー・プール内のすべてのデータベース・インスタンスのCPU使用率を監視し、必要に応じて、現在の設定の変更を推奨できます。

図1-4 サーバー・プールとCPUスライス

単一のサーバー・プールを使用するかわりに、複数のサーバー・プールを作成してサービスを管理し、プール間にサービスを再配置することをお薦めします。この構成の使用には、次の利点があります。

- 異なるタイプのワークロードには異なる構成が必要であり、チューニング目標も異なります。たとえば、OLTPアプリケーションを使用して商品またはサービスを購入する顧客は、出荷および支払い情報の画面のレスポンス時間が短いことを期待します。アプリケーションでの注文の処理に要する時間が長すぎると、顧客は興味を失い、会社は販売機会を逸する可能性があります。対照的に、社内HRアプリケーションを使用している従業員は、HR画面のスポンス時間が短くなくても、画面を使用し続けようとします。HRアプリケーションでのオンライン・タスクの処理に予想より長い時間がかかった場合でも、従業員が使用を中止する可能性はほとんどありません。

- アプリケーションには、1日、1週間または1か月中にビジネス目標を満たすための様々なリソース要件があります。サーバー・プールを使用してアプリケーションのワークロード間でリソースを分割できます。特定の期間のパフォーマンス目標を満たすために、パフォーマンス・ポリシーでサーバー・プールのディレクティブ・オーバーライドを使用してサーバー・プールのデフォルト属性(MaxやMinなど)を変更できます。
たとえば、会社にオンライン納税申告アプリケーションがある場合、そのアプリケーションでは、政府が指定する期日までに顧客の納税証明書を準備し、提出する必要があります。提出期限の直前の期間中、納税証明書の準備と提出に関連するアプリケーションはその年の他の期間よりも多くのリソースを必要とします。このサービス要件を確実に満たすために、QuarterlyFilingsという名前のパフォーマンス・ポリシーを作成して標準のサーバー・プール・ディレクティブをオーバーライドし、QuarterlyFilingsがアクティブなときは、追加のワークロードを処理するために確定申告書類作成アプリケーションで使用するサーバー・プールに2台ではなく最低4台のサーバーが必要であることを指定できます。QuarterlyFilingsパフォーマンス・ポリシーが有効でないときは、デフォルトのパフォーマンス・ポリシーが有効であるため、そのサーバー・プール内の最小サーバー数は2です。

- ワークロードをサポートするサーバー数がOracle Database QoS Managementによって調整されるため、要求レベルが変化した場合でもアプリケーション・ユーザーのパフォーマンス・レベルが一貫します。これにより、ワークロード・レベルが低から高に変化した場合に顧客のパフォーマンスの期待値がリセットされるのを防ぎます。
たとえば、需要の高い新しい消費者製品を販売しており、その製品を割引価格で大量に販売することを会社が広告したとします。その結果、多くの新規顧客がこの製品を注文するため、OLTPアプリケーションでは急増するトランザクション数を処理する必要があります(要求のサージが発生します)。新規顧客は、OLTPアプリケーションのパフォーマンスに対して何を期待すべきかかわかりません。しかし、既存の顧客は、新規顧客の大量流入によって自身のオンライン・ショッピングの操作性が影響を受けた場合、否定的な反応を示す可能性があります。また、OLTPアプリケーションがすべての受信注文を処理できない場合、新規顧客の一部はアプリケーションを中止し、かわりに別の会社に注文したり小売店に行ったりする可能性があります。

Oracle Database QoS Managementでは、使用可能なリソースの再割当てを管理して、他のアプリケーションのサービスのクオリティを低下させずに要求のサージに対応できます。

- 一部のワークロードは適切にスケーリングできませんが、クラスタ環境の高可用性の利点は享受できます。これらのワークロードを固定サイズのサーバー・プールにデプロイすると、パフォーマンスの管理性と高可用性の両方が実現されます。
たとえば、サイズが1サーバーに固定されたサーバー・プールでERPアプリケーションを実行すると、サーバー・プールの最大サイズとサーバー・プールの最小サイズが両方とも1に設定されます。そのサーバー・プールのサーバーに障害が発生した場合、Oracle Clusterwareはそのサーバー・プールに新しいサーバーを自動的に割り当てて、最小サイズの1サーバーが維持されるようにします。障害が発生したサーバー上にあるインスタンスおよびサービスは、新しいサーバーで再開されるため、これらのインスタンスおよびサービスを使用しているアプリケーションは使用可能な状態のままです。

注意:

- サーバー・プールの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- ポリシー管理型Oracle RACデータベースの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- OLTPシステムの説明は、『Oracle Database概要』を参照してください。

Oracle Database QoS Managementがサーバー・プールを使用する方法

クラスタにOracle Grid Infrastructureを初めてインストールするときに、デフォルトのサーバー・プール(空きプール)が作成されます。最初は、すべてのサーバーがこのサーバー・プールに配置されます。管理する必要のあるワークロードに応じて、1つ以上のサーバー・プールを作成する必要があります。新規サーバー・プールを作成する場合、そのサーバー・プールに割り当てるサーバーは空きプールから自動的に移動され、新規に作成されたサーバー・プールに配置されます。この時点で、そのサーバー・プールで実行するデータベースをインストールし、そのデータベースに接続するアプリケーションに対してOracle Clusterwareで管理されるデータベース・サービスを作成できます。

Oracle RACデータベースでサーバー・プールの柔軟性を利用するには、ポリシー管理型デプロイメント・オプションを使用してデータベースを作成する必要があります。これにより、データベースが複数のサーバー・プールに配置されます。アップグレードされたOracleデータベースは管理者管理型データベースに直接変換されるため、ポリシー管理型データベースに別途移行する必要があります。管理者管理型データベースのポリシー管理型データベースへの変更の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle Database 12cリリース1 (12.1.0.2)以降、測定のみモードまたは監視モードで管理者管理型データベースを監視できます。

注意:

サーバー・プールの作成時に、候補サーバー・リスト(server_names attribute)またはカテゴリを使用する場合、Oracle Database Quality of Service (QoS) Managementでサーバー・プールを拡張できる能力がこのような制限により限定されるため、適切ではないサーバーは使用されません。

関連項目:

- 「ポリシー・セットへのサーバー・プールの追加」

- ポリシー管理型データベースの作成の詳細は、『Oracle Real Application Clustersインストレーション・ガイド for Linux and UNIX Systems』(またはその他のプラットフォーム)を参照してください

- 「Oracle Database QoS Managementでのパフォーマンスの監視」

パフォーマンス・クラスの概要

ポリシー・セットには、クラスタで実行する様々なパフォーマンス・クラス、つまりワークロードのパフォーマンス目標が含まれています。Oracle Database QoS Managementでは、ポリシー・セットに定義された一連の分類ルールを使用して、作業リクエストをパフォーマンス・クラスに分類します。作業リクエストをパフォーマンス・クラスに割り当てるために使用する基本的な分類子は、データベースへの接続に使用するサービスの名前です。

- パフォーマンス・クラス・タグ

- 作業リクエストへの分類子の適用

- 作業リクエストを分類するための追加フィルタの使用方法

- 新規パフォーマンス・クラスの作成の決定

パフォーマンス・クラス・タグ

作業リクエストの分類では、作業リクエストが属するパフォーマンス・クラスを識別するユーザー定義の名前(タグ)が適用されます。特定のパフォーマンス・クラスにグループ化されているすべての作業リクエストは、同じパフォーマンス目標を持ちます。事実上、タグは作業リクエストを関連するパフォーマンス・クラスのパフォーマンス目標に結び付けます。Oracle Database QoS Managementによってタグが各作業リクエストに割り当てられるため、システムのすべてのコンポーネントが測定を行い、該当するパフォーマンス目標に照らして評価するためのデータをOracle Database QoS Managementに提供できます。

作業リクエストへの分類子の適用

分類は、新しい作業がシステムに入るたびに行われます。作業リクエストがサーバーに到着すると、作業リクエストのタグがチェックされます。作業リクエストにタグがある場合、サーバーはこの作業リクエストがすでに分類されていると判断し、タグは変更されません。作業リクエストにタグが含まれていない場合は、分類子がチェックされ、対応するパフォーマンス・クラスのタグが作業リクエストに付加されます。

作業リクエストの分類方法を示すために、Oracle RACデータベースに接続するアプリケーションについて考えます。アプリケーションでは、データ・サービスsalesを使用します。Oracle Database QoS Management管理者は、Oracle Database QoS Managementの初期構成中に、sales_pcパフォーマンス・クラスにsalesサービスを使用する作業リクエストが含まれる必要があることを指定しました。接続リクエストがデータベースによって受信されると、Oracle Database QoS Managementはタグをチェックします。タグが見つからない場合、Oracle Database QoS Managementは、パフォーマンス・ポリシーで指定された順序で接続リクエスト内の情報を各パフォーマンス・クラスに対して指定されている分類子と比較します。分類される接続リクエストがsalesサービスを使用している場合は、sales_pcパフォーマンス・クラス内の分類子が接続リクエストの情報と比較されるときに、一致が見つかり、データベース作業リクエストにsales_pcパフォーマンス・クラスのタグが割り当てられます。

作業リクエストを分類するための追加フィルタの使用方法

1つのアプリケーションで、一連のパフォーマンス特性を持つ多くのタイプの作業リクエストをサポートできます。デフォルトの分類ルールを拡張および調整することで、Oracle Database QoS Management管理者は1つのアプリケーションに対して複数のパフォーマンス目標を記述できます。たとえば管理者は、Webベースのアプリケーションに、ログイン、参照、検索および購入に関連する作業リクエストごとに異なるパフォーマンス目標が必要であると判断する場合があります。

Oracle Database QoS Managementでは、パフォーマンス・クラスをデータベースで実行されている実際のワークロードにマップするために、接続パラメータのユーザー定義の組合せがサポートされます。これらの接続パラメータは2つの一般クラスに属しており、結合してきめ細かいブール式を作成できます。

- 構成パラメータ: サポートされる構成パラメータはSERVICE_NAMEおよびUSERNAMEです。パフォーマンス・クラスの各分類子では、データベース・サービスの名前を指定する必要があります。クライアントまたは中間層からデータベース接続を行っているユーザーの名前を識別することで、粒度を高めることができます。これらの分類子を使用する利点は、異なるワークロードを別々のパフォーマンス・クラスに関連付けるためにアプリケーション・コードを変更する必要がないことです。

- アプリケーション・パラメータ: サポートされるアプリケーション・パラメータはMODULE、ACTIONおよびPROGRAMです。これらはオプションのパラメータです。MODULEとACTIONの値はアプリケーション内で設定する必要があります。アプリケーションのタイプに応じて、これらのパラメータは次のように設定できます。

- OCI: OCI_ATTR_MODULEおよびOCI_ATTR_ACTIONを使用します。

- Oracle Data Provider for .NET(ODP.NET): OracleConnectionオブジェクトでModuleNameおよびActionNameプロパティを指定します。

- JDBC: SYS_CONTEXTにMODULEおよびACTIONを設定します。

PROGRAMパラメータは、データベース・ドライバとプラットフォームごとに異なる方法で設定または導出されます。詳細と例については、適切なOracle Database開発者ガイドを参照してください。

アプリケーションのワークロードを管理するには、アプリケーション・コードで特定のサービスを使用してデータベース接続を行います。アプリケーションの様々な部分で生成されたワークロードをより正確に制御するために、追加のパフォーマンス・クラスを作成し、サービスまたはユーザー名に加えてPROGRAM、MODULEまたはACTIONを含む分類子を使用できます。たとえば、salesサービスを使用するクラスタへのすべての接続がsales_pcパフォーマンス・クラスに属するが、salesサービスを使用していてもユーザー名がAPPADMINの接続はsales_adminパフォーマンス・クラスに属することを指定できます。

関連項目:

- Oracle Call Interfaceプログラマーズ・ガイド

- Oracle Data Provider for .NETの開発者ガイド

- 『Oracle Database JDBC開発者ガイド』

新規パフォーマンス・クラスの作成の決定

ワークロードとパフォーマンスの目標は、時間とともに変化します。

特定のデータ・センターで使用するパフォーマンス・クラスは、時間の経過とともに変更されることが予想されます。たとえば、アプリケーションのある部分に対するパフォーマンス目標の変更が必要になることがあります。この場合は、追加の分類子を持つ新しいパフォーマンス・クラスを作成してターゲットの作業リクエストを識別し、パフォーマンス・ポリシーを更新してこのパフォーマンス・クラス用の新しいパフォーマンス目標を追加します。つまり、1つのパフォーマンス目標を1つ以上のよりきめ細かなパフォーマンス目標で置換し、1つのパフォーマンス・クラスの作業リクエストを複数のパフォーマンス・クラスに分割します。

アプリケーション開発者は、使用するパフォーマンス・クラスを推奨できます。具体的には、アプリケーション開発者は異なるアプリケーション・ワークロードを識別する方法を推奨でき、ユーザーはこれらの推奨を使用して、各タイプの作業リクエストが別々に管理されるようにパフォーマンス・クラスの分類子を作成できます。

追加のパフォーマンス・クラスを作成すると、異なるアプリケーション・ワークロードに対して許容されるレスポンス時間を指定できます。たとえば、パフォーマンス目標では、sales_pc_checkoutパフォーマンス・クラスのcheckoutアクションを実行している作業リクエストは1ミリ秒以内に完了する必要があり、sales_pc_browseパフォーマンス・クラスのbrowseアクションを実行している作業リクエストは100ミリ秒以内に完了する必要があることを指定できます。

関連項目:

「パフォーマンス・クラスの管理」

パフォーマンス・ポリシーとパフォーマンス目標の概要

様々なパフォーマンス目標を管理するには、1つ以上のパフォーマンス・ポリシーを定義します。

パフォーマンス・ポリシーは、パフォーマンス目標のコレクションであり、ビジネスに対する重要度の基準です。たとえば、通常の営業時間、平日の非営業時間、週末の運用、および四半期決算の処理中に使用するパフォーマンス・ポリシーをそれぞれ定義できます。どの時間についても、Oracle Database QoS Management管理者によって指定された1つのパフォーマンス・ポリシーが有効になります。各パフォーマンス・ポリシーの中で、パフォーマンス目標の重要度(ランキング)を変えて、特定の期間中に特定のワークロードに高い優先順位を与えることができます。

パフォーマンス・ポリシーには、同時に有効になるパフォーマンス目標のコレクションがあります(クラスタ上で実行されているアプリケーションまたはワークロードごとに1つ以上のパフォーマンス目標)。一部のワークロードとそれらのパフォーマンス目標は、他のワークロードとそれらのパフォーマンス目標よりもビジネスにとって重要です。一部のパフォーマンス目標は、特定の期間に重要度が高く、その他の期間には重要度が低い場合があります。

- パフォーマンス目標の概要

- サーバー・プールのディレクティブ・オーバーライドの概要

- パフォーマンス・クラスのランクの概要

- Oracle Database QoS Managementポリシー・ワークロードの重要性によるデータベースの起動順序の決定

パフォーマンス目標の概要

各パフォーマンス・クラスのパフォーマンス目標を作成して、各パフォーマンス・クラスに割り当てられているすべての作業リクエストのターゲット・パフォーマンス・レベルを指定します。

パフォーマンス目標では、ビジネス要件(ターゲットのパフォーマンス・レベル)とそのパフォーマンス目標が適用される作業(パフォーマンス・クラス)の両方を指定します。たとえば、パフォーマンス目標では、hr_pcパフォーマンス・クラス内の作業リクエストの平均レスポンス時間が0.2秒未満である必要があることを指定できます。

パフォーマンス目標は、パフォーマンス・ポリシーで指定します。パフォーマンス・クラスが「測定のみ」としてマークされていないかぎり、各パフォーマンス・ポリシーには各パフォーマンス・クラスのパフォーマンス目標が含まれます。このリリースのOracle Database QoS Managementでは、平均レスポンス時間という1種類のパフォーマンス目標のみサポートされます。

ワークロードのレスポンス時間はデータベース・クライアント・リクエストに基づきます。レスポンス時間では、ネットワーク上でクラスタがリクエストを受信してからリクエストがクラスタから離れるまでの時間が測定されます。レスポンス時間には、ネットワーク上でのクライアントとの情報の送受信に必要な時間は含まれません。パフォーマンス・クラス内のすべてのデータベース・クライアント・リクエストのレスポンス時間は、1つのデータベース・リクエストにつき秒単位で測定され、平均化されて、平均レスポンス時間として提示されます。

関連項目:

「パフォーマンス・ポリシーの作成とパフォーマンス目標の指定」

サーバー・プールのディレクティブ・オーバーライドの概要

サーバー・プールのディレクティブ・オーバーライドは、パフォーマンス・ポリシーが有効な場合に、サーバー・プールに「最小」、「最大」および「重要度」の可用性プロパティを設定します。

パフォーマンス・ポリシーには、サーバー・プールのディレクティブ・オーバーライドのセットを含めることができます。サーバー・プールのディレクティブ・オーバーライドは、パフォーマンス・ポリシーのアクティブ化期間中に有効になるため、Oracle Database QoS Managementが推奨する割当て変更に対する制約として機能します。たとえば、サーバー・プールからサーバーを移動するとサーバー・プールのサーバー数が指定された最小サーバー数よりも少なくなる場合、Oracle Database QoS Managementはサーバー・プールからのサーバーの移動を推奨しません。

図1-5に示すように、システムのパフォーマンス・ポリシーを作成して、1年または1日の中での時間に基づいてワークロードを管理できます。通常の条件下では、これらのパフォーマンス・ポリシーはデータベース・ワークロードの実行を安定した速度に保ちます。データベースのワークロード・リクエストが突然増加した場合は、特定のサーバー・プールにパフォーマンス・ポリシーで指定されているよりも多くのリソースが必要になることがあります。

図1-5 パフォーマンス・ポリシーによるベースライン・リソース管理

たとえば、電話で注文を受け、販売アプリケーションを使用して注文を作成するとします。電話セールス部門は通常の営業時間中にのみ応対しますが、顧客はインターネットで注文することもできます。日中は多くの注文が行われるため、販売アプリケーションはワークロードを処理するためにより多くのリソースを必要とします。この構成は、営業時間パフォーマンス・ポリシーを作成してバック・オフィス・サーバー・プールに最大2台のサーバーを配置できることを指定し、Oracle Database QoS Managementが必要に応じてオンライン・サーバー・プールにサーバーを移動できるようにすることで管理されます。電話セールス部門が営業を終了した後は、販売アプリケーションのワークロードが減ります。この構成を管理するには、営業時間後パフォーマンス・ポリシーを作成してバック・オフィス・サーバー・プールに最大4台のサーバーを配置できることを指定し、社内アプリケーションが翌営業日より前にワークロードを完了するのに必要な追加リソースを獲得できるようにします。

このシナリオでは、営業時間パフォーマンス・ポリシーと営業時間後パフォーマンス・ポリシーにサーバー・プールのディレクティブ・オーバーライドを含めることができます。パフォーマンス・ポリシーにサーバー・プールのディレクティブ・オーバーライドが含まれる場合、指定したサーバー・プールに対する「最小」、「最大」および「重要度」の現在の設定は、パフォーマンス・ポリシーが有効になっているときにオーバーライドされます。これにより、販売サーバー・プールに追加のサーバーを配置してオンライン販売アプリケーションに必要なリソースを与え、バック・オフィス・サーバー・プールで使用されるリソースを制限して、そのワークロードが販売ワークロードに干渉しないようにすることができます。

関連項目:

「サーバー・プールのディレクティブ・オーバーライドの設定」

パフォーマンス・クラスのランクの概要

パフォーマンス・ポリシー内で、各パフォーマンス・クラスにビジネスの重要度レベル(ランク)を割り当てて、重要度の低いパフォーマンス・クラスよりも重要度の高いパフォーマンス・クラスのパフォーマンス目標を満たすことを優先できます。すべてのパフォーマンス・クラスのすべてのパフォーマンス目標を同時に満たすだけの十分なリソースがない場合は、重要性の低いパフォーマンス目標を犠牲にして、重要性の高いパフォーマンス・クラスのパフォーマンス目標を満たす必要があります。パフォーマンス・ポリシーは、各パフォーマンス・クラスのビジネスの重要度を指定します。これには、最高、高、中、低または最低を指定できます。

注意:

ランクに基づいたリソースへの優先アクセスは、単一インスタンスのOracle RACデータベースやOracle RAC One Nodeには適用されません。

たとえば、図1-5に示したパフォーマンス・ポリシーを使用すると、営業時間パフォーマンス・ポリシーが有効なときは、オンライン・サーバー・プールにアクセスする販売アプリケーションが最高ランクを持ちます。すべてのパフォーマンス・クラスのパフォーマンス目標を満たすのに十分なリソースがない場合は、バック・オフィス・サーバー・プールを使用しているアプリケーションがパフォーマンス目標を満たしていない場合でも、オンライン・サーバー・プールを使用するアプリケーションが使用可能なリソースに優先的にアクセスします。

同じランクに複数のパフォーマンス・クラスがあってもかまいません。Oracle Database QoS Managementで、パフォーマンス目標を満たしていない複数のパフォーマンス・クラスが検出され、そのパフォーマンス・クラスにアクティブなパフォーマンス・ポリシー内で同じランクが割り当てられている場合、Oracle Database QoS Managementはパフォーマンス目標の実現に最も近いパフォーマンス・クラスにより多くのリソースを与えるような変更を推奨します。推奨されたアクションが実装された後、パフォーマンス・クラスがターゲットのパフォーマンス・レベル以上になると、Oracle Database QoS Managementはシステム・パフォーマンスの評価を新規に実行します。

関連項目:

「パフォーマンス・ポリシーの管理」

Oracle Database QoS Managementポリシー・ワークロードの重要性によるデータベースの起動順序の決定

ユーザー作成のOracle Database QoS Managementポリシーがアクティブな場合、パフォーマンス・クラスのランク付けされた順序により、関連するOracle RACデータベースの開始順序またはリクエスト・リアルタイムLMSプロセス・スロットが決定されます。パフォーマンス・クラス・ランキングの使用により、統合環境で実行しているミッションクリティカルなデータベースに、リアルタイムで実行するLMSプロセスが確実に含まれることになるので、ノード間通信でのリソースのボトルネックが解消されます。Oracle Database QoS Managementポリシーでは各ワークロードのランクを指定するので、各データベースにMax(Ranks)の値を使用することにより、各データベースのビジネスの重要度を一貫性のある表現で示すことができます。

Oracle Database QoS Managementがパフォーマンス・データを収集および分析する方法

Oracle Database QoS Managementサーバーは、管理対象サーバー・プールで実行されている各データベース・インスタンスからメトリック・データを取得します。データは、5秒ごとにパフォーマンス・クラスによって関連付けられます。データには、データベース・リクエスト到着率、CPU使用率、CPU待機時間、I/O使用率、I/O待機時間、グローバル・キャッシュ使用率、グローバル・キャッシュ待機時間など、多くのメトリックが含まれます。クラスタの現在のトポロジとサーバーの状態に関する情報がデータに追加されます。Oracle Database QoS Managementのポリシーおよびパフォーマンス管理エンジン(図1-6に示します)は、データを分析して、アクティブなパフォーマンス・ポリシーによって設定された現在のパフォーマンス目標に関してシステムの全体的なパフォーマンス・プロファイルを判断します。

パフォーマンス評価は1分間に1回実行され、いずれかのパフォーマンス・クラスがその目標を満たしていない場合は推奨が行われます。推奨では、どのリソースがボトルネックであるかが示されます。可能な場合は、推奨に具体的な修正処理が含まれます。推奨には、推奨された処理を実装することに決定した場合にすべてのパフォーマンス・クラスに対して予測される影響のリストも含まれます。

図1-6に、様々なデータ・ソースからのデータの収集のダイアグラムと、Oracle Enterprise Managerでその情報を使用する方法を示します。この図では、CHMはOracle Cluster Health Monitorを示し、Server Manager(SRVM)はOracle Clusterwareのコンポーネントです。

図1-6 Oracle Database QoS Managementサーバー・アーキテクチャのダイアグラム

関連項目:

- 「Oracle Database QoS Managementダッシュボードの使用方法」

- 「パフォーマンス概要グラフの解釈」

- 「パフォーマンス・メトリックの確認」

推奨の概要

Oracle Database QoS Managementでは、推奨を通じて特定のパフォーマンス目標を満たすための余剰容量を管理できます。

ビジネスで定期的に要求のサージが発生する場合、またはオープン・ワークロードをサポートする必要がある場合は、アプリケーションのパフォーマンス・レベルを維持するためにピーク・ワークロードを満たすシステムを設計できます。通常、ピーク・ワークロードを処理できるシステムの作成は、必要に応じて使用可能にでき、不要なときにはアイドルにしておける追加ハードウェアの取得を意味します。要求のサージが発生したとき以外にサーバーをアイドルにしておくかわりに、他のアプリケーションのワークロードの実行にそれらのサーバーを使用することもできます。ただし、要求のサージが発生したときに他のアプリケーションの実行でサーバーがビジー状態の場合は、ピーク・ワークロードを満たすことができず、ビジネス・アプリケーションが期待どおりに実行されない可能性があります。

- Oracle Database QoS Managementが推奨を生成する方法

- 推奨のタイプ

- 最適な推奨の選択

- 推奨の内容

- 推奨の実装の概要

- 例: 推奨の生成方法

Oracle Database QoS Managementが推奨を生成する方法

Oracle Database QoS Managementを使用する場合、システムは反復的なプロセスで絶えず監視され、アクティブなパフォーマンス・ポリシーのパフォーマンス目標が満たされているかどうかが確認されます。パフォーマンス・データがOracle Enterprise Managerに送信され、Oracle Database QoS Managementダッシュボード(ダッシュボード)および「パフォーマンス履歴」ページに表示されます。

1つ以上のパフォーマンス目標が満たされていない場合は、システムのパフォーマンスを評価した後で、Oracle Database QoS Managementは1つのパフォーマンス目標(通常は、現在満たされていないパフォーマンス目標のうち、ランクが最高のもの)のパフォーマンスの向上を追求します。現在のワークロードと予測されるワークロードの両方に対して確保されている容量ですべてのパフォーマンス目標が満たされる場合、Oracle Database QoS Managementは「アクションは必要ありません。パフォーマンス目標はすべて達成されています」と通知します。

関連項目:

- 「Oracle Database QoS Managementダッシュボードの使用方法」

- 「推奨の表示」

- 「パフォーマンス・メトリックの確認」

推奨のタイプ

パフォーマンス・クラスのパフォーマンス目標が満たされていない場合、Oracle Database QoS Managementはボトルネックを軽減するためにリソースの使用のリバランスの推奨を発行します。Oracle Database QoS Managementは考えられるいくつかのソリューションを評価して、次のようなソリューションを選択します。

- システム全体を最も向上させる

- システムの中断を最も少なくする

- 違反中の最もランクの高いパフォーマンス・クラスをサポートする

Oracle Database QoS Managementは、次のタイプの推奨を行うことができます。

- コンシューマ・グループの昇格と降格

- サーバー・プール間でのサーバーの移動

- CPU数の変更

コンシューマ・グループの昇格と降格

パフォーマンス・クラスのパフォーマンス目標が満たされておらず、パフォーマンス・クラスが他のパフォーマンス・クラスと同じデータベースにアクセスしている場合、Oracle Database QoS Managementはコンシューマ・グループ・マッピングの変更を推奨できます。コンシューマ・グループ・マッピングを変更すると、パフォーマンス目標を満たしていないパフォーマンス・クラスがより多くのCPUリソースにアクセスできるようになります。Oracle Database QoS Managementは、同じデータベースとサーバー・プール内のリソースに対して競合しているパフォーマンス・クラスについてのみコンシューマ・グループ・マッピングの推奨を発行します。

CPU数の変更

サーバー・プールのサーバーで複数のデータベース・インスタンスが実行されている場合、Oracle Database QoS Managementは、サーバー上のあるスライスでデータベース・インスタンスによって使用されているCPUリソースを、より多くのCPUリソースを必要とするスライスに提供するように推奨できます。パフォーマンス目標を満たしていないパフォーマンス・クラスがあり、システム上に使用可能なヘッドルームのある別のスライスがある場合、またはそのスライスを使用するパフォーマンス・クラスのランクが低い場合、Oracle Database QoS Managementはアイドル・スライスからオーバーロードしているスライスへのCPUの移動を推奨できます。この推奨が実装されると、サーバー・プール内のすべてのサーバーで、アイドル・インスタンスの場合は下方に、オーバーワーク・インスタンスの場合は上方に、CPU_COUNTパラメータが調整されます。

サーバー・プール間でのサーバーの移動

Oracle Database QoS Managementが表示できる別の推奨アクションは、あるサーバー・プールから別のサーバー・プールにサーバーを移動し、パフォーマンス・クラスのパフォーマンス目標を満たすための追加リソースを提供することです。クラスタ内のすべてのサーバー・プールのサイズが指定された最小サイズの場合、またはリソースが必要なサーバー・プールが最大サイズの場合、Oracle Database QoS Managementはサーバー・プールからのサーバーの削除を推奨できません。この場合、ダッシュボードに現在推奨されるアクションはありませんと表示されます。

サーバー・プールの最小サイズは、サーバー・プールに必要なサーバー数です。クラスタ内の各サーバー・プールのサーバー・プール最小値属性に値を追加する場合、この合計とクラスタ内のサーバー総数の差は、要求の変化を満たすためにサーバー・プール間で移動できる共有サーバー(フロート)を表します。たとえば、クラスタに10台のサーバーと2つのサーバー・プールがあり、各サーバー・プールの最小サイズが4の場合、システムには、サーバー・プール間で移動できる2台のサーバーがあることになります。ターゲット・サーバー・プールが最大サイズに達していない場合、これらのサーバーを移動できます。Oracle Database QoS Managementは、サーバーの移動を推奨する場合、常にポリシーで設定されている最小および最大サイズ制約を考慮します。

サーバー・プールの最小サイズをゼロに設定した場合にシステムで要求のサージが発生すると、Oracle Database QoS Managementは、そのサーバー・プールからすべてのサーバーを移動してサーバー・プールを最小サイズにすることを推奨する場合があります。この結果、そのサーバー・プールを使用するパフォーマンス・クラスはリソースが完全に不足し、基本的に停止します。最小サイズがゼロのサーバー・プールには、ビジネスでの重要度が低く、パフォーマンス・ポリシーでパフォーマンス・クラスに低いランクが割り当てられているアプリケーションのみホストする必要があります。

最適な推奨の選択

Oracle Database Quality of Service Managementは、ワークロード・パフォーマンスを向上させるための推奨を複数提供します。

特定のパフォーマンス・クラスのリソース・ボトルネックを緩和しようとする場合、Oracle Database QoS Managementでは、そのパフォーマンス・クラスにより多くのリソース(CPU時間など)を追加するか、パフォーマンス・クラスの作業リクエストに対してリソースをより迅速に使用可能にすることが推奨されます。推奨は、ターゲット・パフォーマンス・クラスのより高いコンシューマ・グループへの昇格、リソース・プラン内の競合パフォーマンス・クラスの降格、サーバー・プール内の様々なスライス間で共有されているCPUリソースの調整、またはサーバー・プール間でのサーバーの移動の形式をとります。

推奨アクションを実装すると、他のパフォーマンス・クラスに使用できるリソースが減ります。推奨を生成する場合、Oracle Database QoS Managementは全体的なシステム・パフォーマンスへの影響を評価します。リソースの割当ての変更に対して可能な推奨によって1つのパフォーマンス・クラスのレスポンス時間が若干向上しても、他のパフォーマンス・クラスのレスポンス時間が大幅に低下する場合、Oracle Database QoS Managementはパフォーマンス利得が小さすぎるため変更は推奨されないことをレポートします。

Oracle Database QoS Managementは、次の場合に、パフォーマンス・クラスのパフォーマンスに悪影響のある推奨を発行することがあります。

- リソースを奪われるパフォーマンス・クラスに対する悪影響がパフォーマンス目標違反の原因になることが予測されず、リソースへのアクセスが向上するパフォーマンス・クラスについてよい影響が予測される場合

- リソースを奪われるパフォーマンス・クラスのランクが低く、ビジネスに対する重要度が、リソースを増やされるパフォーマンス・クラスの重要度よりも低い場合

リソース・ボトルネックを複数の方法で解決できる場合、Oracle Database QoS Managementは、目標に違反している最もランクの高いパフォーマンス・クラスのパフォーマンスを向上させるアクションを推奨します。Oracle Database QoS Managementで生成された別の推奨を表示し、アクションの実装が推奨されているかどうかを確認することもできます。たとえば、CPUリソース上のボトルネックを解決するために考えられる1つのソリューションは、CPUを最も使用しているパフォーマンス・クラスに関連付けられているコンシューマ・グループを降格させることです。このパフォーマンス・クラスの作業リクエストに対してCPUへのアクセスを制限することにより、そのデータベースに対する他のパフォーマンス・クラスの作業リクエストが使用できるCPU時間が多くなります。ただし、Oracle Database QoS Managementは、ターゲットのパフォーマンス・クラスのレスポンス時間の向上が小さすぎるため、このアクションを推奨しない可能性があります。

関連項目:

- 「推奨の表示」

- 「推奨の詳細の表示」

推奨の内容

推奨の分析データには、図1-7に示すように、各パフォーマンス・クラスのレスポンス時間の予測される変化、各パフォーマンス・クラスの「パフォーマンス満足度メトリック」(PSM)の予測される変化、および数あるアクションの中でこのアクションが選択される理由が含まれます。この例では、推奨されるアクションを実装した場合、Oracle Database QoS Managementは、ランキングが最高のsales cartパフォーマンス・クラスのレスポンス時間がデータベース・リクエスト当たり0.00510秒から0.00426秒に向上することを予測します。これは、PSMの11.6%向上に相当します。他のパフォーマンス・クラスは別のサーバー・プールを使用するため、変更の影響を受けません。

図1-7 推奨されるアクションの分析例

関連項目:

- 「パフォーマンス満足度メトリック」

- 「パフォーマンスの問題を識別するためのメトリックの使用方法」

- 「推奨の表示」

推奨の実装の概要

Oracle Database QoS Managementは、推奨を自動的には実装しません。推奨アクションが実行されるのは、QoS管理者が「実装」ボタンをクリックした後のみです。Oracle Database QoS Management管理者が推奨を実装した後、新しい推奨が行われる前に、指定された設定時間にわたってシステム・パフォーマンスが再評価されます。また、パフォーマンス・クラスが目標を達成していない期間に基づいて、アラートを生成するようEnterprise Managerを構成することも可能です。

関連項目:

- 「Oracle Database QoS Managementダッシュボードの使用方法」

- 「推奨の表示」

- 「推奨の実装」

- 「パフォーマンス・メトリックの確認」

例: 推奨の生成方法

オンライン・サーバー・プールに2台のサーバーがあり、バック・オフィス・サーバー・プールに2台のサーバーがあるシステムについて考えます。オンライン・サーバー・プールは、sales_pcパフォーマンス・クラスおよびsales_cartパフォーマンス・クラスという2つのワークロードをホストします。オンライン・サーバー・プールの最小サイズは2です。バック・オフィス・サーバー・プールは、人事(HR)アプリケーションとエンタープライズ・リソース・プランニング(ERP)アプリケーションの2つの社内アプリケーションをホストします。バック・オフィス・サーバー・プールの最小サイズは1です。sales_cartパフォーマンス・クラスのランクは最高で、erp_pcパフォーマンス・クラスのランクは最低です。sales_pcパフォーマンス・クラスのランクはhr_pcパフォーマンス・クラスよりも高くなっています。

このシナリオでは、sales_pcのワークロード・サージが発生した結果、リソースの競合とsales_cartパフォーマンス・クラスのパフォーマンス目標違反が発生した場合に、OLTPアプリケーションのサービス・レベル合意(SLA)違反が引き起こされることがあります。sales_cartパフォーマンス・クラスの方がランクが高く、より高いランクはsales_cartパフォーマンス・クラスのパフォーマンス目標を満たすことがsales_pcパフォーマンス・クラスのパフォーマンス目標を満たすことよりも重要であることを示しているため、Oracle Database QoS Managementは、sales_pcワークロードを犠牲にしてsales_cartパフォーマンス・クラスのCPUアクセスを増やす推奨を発行します。

推奨を実装しても、sales_cartおよびsales_pcパフォーマンス・クラスがまだパフォーマンス目標を満たさない場合、Oracle Database QoS Managementは、バック・オフィス・サーバー・プール(重要度の低いワークロードまたはヘッドルームの多いワークロードをホストするサーバー・プール)からサーバーを移動することによりオンライン・サーバー・プールのサーバー数を増やす推奨を発行します。このシナリオでは、バック・オフィス・サーバー・プールは現在最小サイズである1を超えているため、バック・オフィス・サーバーからサーバーを移動できます。バック・オフィス・サーバー・プールの最小サイズが2の場合、Oracle Database QoS Managementは、使用可能なサーバーを別のサーバー・プールで探す必要があります。Oracle Database QoS Managementは、サーバー・プールからサーバーを移動するとそのサーバー・プールが最小サイズを下回る場合には、サーバーの移動を推奨しません。

推奨されたアクションを実装し、アプリケーションでクラスタ管理サービスおよびクライアント・ランタイム・ロード・バランシングを使用する場合、アプリケーション・ユーザーに対してこの再割当てによるサービスの中断は発生しません。サービスは、移動されるサーバー上でトランザクションによって停止されます。ストレスがかかっているサーバー・プールにサーバーが追加された後、すべてのデータベース・インスタンスとそれらによって提供されているサービスは、再割当てされたサーバー上で開始されます。この時点で、セッションはサーバー・プール内の新しいサーバーを使用するように徐々に切り替えられ、ボトルネックが緩和されます。

同じシナリオで、sales_pcパフォーマンス・クラスとhr_pcパフォーマンス・クラスの両方がパフォーマンス目標を満たすために追加のサーバーを必要とする場合、sales_pcパフォーマンス・クラスはhr_pcパフォーマンス・クラスよりもランクが高いため、Oracle Database QoS Managementは最初にsales_pcパフォーマンス・クラスのパフォーマンスを向上させる推奨を発行します。sales_pcパフォーマンス・クラスのパフォーマンス目標が満たされると、Oracle Database QoS Managementはhr_pcパフォーマンス・クラスのパフォーマンスを向上させる推奨を作成します。

Oracle Database QoS Managementの管理対象

Oracle Database QoS Managementは、Oracle Real Application Clusters(Oracle RAC)およびOracle Clusterwareと連動します。Oracle Database QoS Managementは、Oracle RACクラスタ全体で稼働し、様々なアプリケーションをサポートできます。

- サービス・レベルを満たすためのデータベース・リソースの管理

- 高可用性管理とOracle Database QoS Management

注意:

Oracle Database QoS ManagementではOLTPワークロードのみサポートされます。次のタイプのワークロード(またはデータベース・リクエスト)はサポートされません。

- バッチ・ワークロード

- 完了に1秒より長くかかるワークロード

- パラレルデータ操作言語(DML)を使用するワークロード

- 高い使用率レベルでGV$ビューを問い合せるワークロード

サービス・レベルを満たすためのデータベース・リソースの管理

Oracle Database QoS Managementは、クラスタのCPUリソースを管理します。Oracle Database QoS ManagementはI/Oリソースを管理しないため、I/O集中型のアプリケーションはOracle Database QoS Managementによって効果的に管理されません。

Oracle Database QoS Managementは、次の手法でOracle RACデータベースと統合され、クラスタ内のリソースを管理します。

- データベース・サービス

- Oracle Database Resource Manager

- Oracle Clusterware

- 実行時接続ロード・バランシング

Oracle Database QoS Managementは、使用されているすべてのリソースのリソース待機時間を定期的に評価します。パフォーマンス・クラスの作業リクエストの平均レスポンス時間がパフォーマンス目標で指定されている値より大きい場合、Oracle Database QoS Managementは収集されたメトリックを使用してボトルネック・リソースを探します。可能な場合、Oracle Database QoS Managementは、サーバー・プールのサイズを調整するかOracle Database Resource Managerで使用されているリソース・プランのコンシューマ・グループを変更する推奨を提供します。

データベース・サービス

関連する作業リクエストのグループ化のメカニズムを提供するには、データベース・サービスを作成します。アプリケーションは、データベース・サービスを使用してクラスタ・データベースに接続します。ユーザーがデータベースに対して開始した問合せは、Webベース・アプリケーションとは異なるサービスを使用する場合があります。異なるサービスは、異なるタイプの作業リクエストを表す場合があります。Oracle RACデータベースに対して行われた各コールまたはリクエストが作業リクエストです。

データベース・サービスを使用して、データベース・ワークロードを管理および測定することもできます。サービスで使用されるリソースを管理するために、一部のサービスは複数のOracle RACインスタンスに同時にデプロイできますが、その他のサービスはサービスを使用するワークロードを分離するために単一のインスタンスにのみデプロイできます。

Oracle RACクラスタでは、Oracle Database QoS Managementはデータベース・サービスが提供されているサーバー・プールとそのノードを監視します。サービスは、データベース管理者がデータベースに対して作成します。ポリシー管理型データベースでは、サービスは指定されたサーバー・プールのすべてのサーバーで実行されます。アプリケーションを水平にスケーリングできないためシングルトン・サービスが必要な場合は、最小サイズと最大サイズが1のサーバー・プールで実行するようにサービスを制限できます。

パフォーマンスを管理するためにOracle Database QoS Managementを使用するには、サーバー・プールで実行される1つ以上のポリシー管理型データベースを作成する必要があります。管理者管理型データベースの場合、データベース・インスタンスは汎用サーバー・プールに置かれており、Oracle Database QoS Managementはこれらのデータベースの監視しかできません。

Oracle Database QoS Managementを初めて構成する場合、監視されているサーバー・プールに検出されたサービスごとにデフォルトのパフォーマンス・ポリシーが作成されます。これらのデフォルト・パフォーマンス・クラスの名前はservice_name_pcです。リソースを監視および管理するワークロードでは、データベース・サービスを使用してデータベースに接続する必要があります。

関連項目:

サービスの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle Database Resource Manager

Oracle Database Resource Manager(リソース・マネージャ)は、リソース割当てメカニズムの例です。リソース・マネージャは、管理者が指定したリソース・プランに基づいて、リソース・コンシューマ・グループのコレクション間にCPU占有率を割り当てることができます。リソース・プランは、CPUで実行する機会のパーセンテージを割り当てます。

Oracle Database QoS Managementは、既存のリソース・マネージャ・プランは調整しません。Oracle Database QoS Managementは、複雑なマルチレベルのリソース・プランであるAPPQOS_PLANというリソース・プランをアクティブ化します。Oracle Database QoS Managementは、パフォーマンス・クラスであるコンシューマ・グループおよび各コンシューマ・グループのリソース・プラン・ディレクティブも作成します。

Oracle Database QoS Managementの推奨を実装してパフォーマンス・クラスのコンシューマ・グループをプロモートまたは降格する場合、Oracle Database QoS Managementは、APPQOS_PLANリソース・プランで指定されたCPU占有率へのパフォーマンス・クラスのマッピングに推奨された変更を加えます。コンシューマ・グループを変更することで、現在パフォーマンス目標を満たしていないパフォーマンス・クラスがアクセスできるCPUリソースが増やされます。

デフォルトでは、APPQOS_PLANはOracle Schedulerのメンテナンス・ウィンドウ中に置換されます。APPQOS_PLANリソース・プランにはDEFAULT_MAINTENANCE_PLANプランのコンシューマ・グループが組み込まれているため、これらの毎日のウィンドウ中はこのリソース・プランを使用することをお薦めします。SQL*Plusで次のコマンドを実行することにより、APPQOS_PLANを強制的に使用できます。

BEGIN
DBMS_SCHEDULER.DISABLE(name=>'"SYS"."MONDAY_WINDOW"');
END;
/

BEGIN
DBMS_SCHEDULER.SET_ATTRIBUTE(name=>'"SYS"."MONDAY_WINDOW"',
attribute=>'RESOURCE_PLAN',value=>'APPQOS_PLAN');
END;
/

BEGIN
DBMS_SCHEDULER.ENABLE(name=>'"SYS"."MONDAY_WINDOW"');
END;
/

TUESDAY_WINDOWのように、曜日ごとにこれらのコマンドを繰り返します。

注意:

「Oracle Database QoS Managementのリソース・プランの編集」で指定されているものを除いて、APPQOS_PLANは編集しないでください。

関連項目:

- 「Oracle Database QoS Managementの有効化」

- リソース・マネージャの詳細は、『Oracle Database管理者ガイド』を参照してください。

Oracle Clusterware

Oracle Database QoS Managementは、Oracle Clusterwareによって構成されたサーバーの管理と監視を行います。

Oracle Database QoS Managementを使用する前に、Oracle Clusterwareをインストールして構成する必要があります。クラスタ管理者は、ポリシー管理型Oracle RACデータベースのデプロイに使用するサーバー・プールを作成する必要があります。管理者管理型Oracle RACデータベースは、汎用サーバー・プールのみを使用します。

Oracle Database QoS Managementを初めて構成し、初期ポリシー・セットを作成するときに、Oracle Database QoS Managementで管理する必要のあるサーバー・プールと監視のみ必要なサーバー・プールを指定します。Oracle Database QoS Managementで管理するサーバー・プールを選択した場合、Oracle Database QoS Managementは、そのサーバー・プールで実行するすべてのパフォーマンス・クラスで使用されるリソースを監視します。パフォーマンス・クラスがパフォーマンス目標を満たしていない場合、Oracle Database QoS Managementは、必要に応じて追加リソースを提供するためにサーバー・プール間でのサーバーの移動を推奨できます。

関連項目:

ポリシー管理型データベースとサーバー・プールの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください

実行時接続ロード・バランシング

ランタイム接続ロード・バランシングでは、アプリケーションが作業を完了するために接続をリクエストしたときに、Oracleクライアントが接続プール内の接続をインテリジェントに割り当てることができます。新しい接続のルーティング先インスタンスの決定は、データベース・インスタンスが提供する現在のパフォーマンス・レベルに基づいて行われます。

Oracle Database QoS Managementで管理されているリソースを使用するアプリケーションでは、接続ロード・バランシングと透過アプリケーション・フェイルオーバー(TAF)も利用できます。接続ロード・バランシングにより、サービスをサポートしているすべてのインスタンスにユーザー接続を分散できます。サービスごとに、-clbgoalオプションを指定した適切なSRVCTLコマンドを使用して接続ロード・バランシングの目標を設定することで、リスナーがロード・バランシングに使用する方法を定義できます。SRVCTLを-failovermethodおよび-failovertypeオプションなどと使用して、サービスのすべてのユーザー用の単一のTAFポリシーを指定できます。

関連項目:

- ランタイム接続ロード・バランシングの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- 「サポートされるサービス構成」

- TAFの構成の詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。

高可用性管理とOracle Database QoS Management

パフォーマンス管理と高可用性管理システムは密接に関連しています。通常、ユーザーはパフォーマンスが許容される場合にのみシステムが稼働している(使用可能である)とみなします。Oracle Database QoS Managementとパフォーマンス目標を使用して、許容されるパフォーマンス・レベルを指定および維持できます。

Oracle Database QoS Managementは、システムが動的ワークロード条件下でサービス・レベル合意を満たせるようにリソース割当てを最適化するランタイム・パフォーマンス管理製品です。Oracle Database QoS Managementは、ビジネスにとって最も重要な作業が必要なリソースを取得できるようにするための推奨を提供します。Oracle Database QoS Managementは、現在の要求とリソースの可用性に基づいてリソース割当てのリバランスを支援します。ビジネスにとって重要な作業が正常に完了するように、重要でない作業は抑止されます。

Oracle Database QoS Managementは、パフォーマンスを向上させるための機能ではありません。Oracle Database QoS Managementの目的は、最適なパフォーマンス・レベルを維持することです。Oracle Database QoS Managementは、パフォーマンスと可用性の両方に影響するシステム・パラメータが適切に設定され、それらが一定であることを前提としています。たとえば、FAST_START_MTTR_TARGETデータベース・パラメータは、データベース・書込みチェックポイントがデータ・ファイルをブロックする頻度を制御します。このパラメータに低い値を使用すると、データベースのリカバリに要する時間が短縮されますが、redoログ・データを頻繁に書き込むオーバーヘッドがデータベースのパフォーマンスに悪影響を及ぼす可能性があります。Oracle Database QoS Managementは、このようなパラメータに指定された値については推奨を行いません。

高可用性の管理には、ワークロードに関連せず、ワークロードの管理の影響を受けない問題が数多く含まれます。たとえば、システムの可用性は、ソフトウェア・アップグレード・イベントの頻度と期間に大きく依存します。システムの可用性は、ハードウェア障害の頻度にも直接依存します。ワークロードの管理では、ソフトウェア・アップグレードの頻度やハードウェア障害の頻度を変更できません。

関連項目:

- 高可用性を実現するためのOracle RACの使用の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください

- Oracle Databaseパフォーマンス・チューニング・ガイド

- 『Oracle Database高可用性概要』

メトリックの概要

Oracle Database QoS Managementは、作業リクエストがリソースの待機に費やす時間の長さの観察データに基づいて決定を行います。作業リクエストが待機するリソースの例として、CPUサイクル、ディスクI/Oキュー、グローバル・キャッシュ・ブロックなどのハードウェア・リソースがあります。ラッチ、ロック、ピンなど、データベース内で発生する待機もあります。データベース内でのリソース待機はOracle Database QoS Managementメトリックで考慮されますが、タイプ別には管理または指定されません。

作業リクエストのレスポンス時間は、実行時間と様々な待機時間で構成されます。実行時間を変更または改善するには、一般にアプリケーション・ソース・コードの変更が必要です。このため、Oracle Database QoS Managementでは待機時間のみを監視および管理します。

Oracle Database QoS Managementは、システム内のすべてのサーバーによって収集される標準化されたメトリックのセットを使用します。作業リクエストのレスポンス時間の測定に使用されるメトリックには、パフォーマンス・メトリックとリソース・メトリックの2種類があります。作業リクエストはシステムを構成するサーバー、ネットワークおよびストレージ・デバイスを通過するため、これらのメトリックにより、各パフォーマンス・クラスの作業リクエストで発生する待機時間を、リクエストされたリソースごとに直接観察できます。別のタイプのメトリックであるパフォーマンス満足度メトリックは、パフォーマンス・クラスのパフォーマンス目標がどの程度満たされているかを測定します。

関連項目:

「Oracle Database QoS Managementダッシュボードの使用方法」

パフォーマンス・メトリック

パフォーマンス・メトリックは、システムのどこで時間が費やされているかの概要を示し、システム全体で待機時間を比較できます。

パフォーマンス・メトリックは、システムの各サーバーへのエントリ・ポイントで収集されます。データは定期的に収集され、分析、意思決定および履歴格納のために中央ポイントに転送されます。システム・データの収集方法の図は、図1-6を参照してください。

パフォーマンス・メトリックは、レスポンス時間(リクエストを受信した時刻とレスポンスを送信した時刻の差)を測定します。パフォーマンス・クラス内のすべてのデータベース・クライアント・リクエストのレスポンス時間は、1つのデータベース・リクエストにつき秒単位で測定され、平均化されて、平均レスポンス時間として提示されます。

関連項目:

「パフォーマンス・メトリックの確認」

リソース・メトリック

システムの各対象リソースには2つのリソース・メトリックがあります。

- リソース使用時間: 各作業リクエストでリソースの使用に費やした時間を測定します。

- リソース待機時間: リソース取得の待機に費やした時間を測定します。

リソースは、CPU、ストレージI/O、グローバル・キャッシュおよびその他(データベース待機)に分類されます。データは、Oracle RACデータベース、Oracle Clusterwareおよびオペレーティング・システムから収集されます。

関連項目:

「リソース待機時間のブレークダウンの表示」

パフォーマンス満足度メトリック

ワークロード・パフォーマンスの分析に役立つメトリックは、パフォーマンス・クラスの作業リクエストがそのパフォーマンス・クラスの現在のパフォーマンス目標をどの程度満たしているかに関する共通および一貫した数値メジャーです。

この数値メジャーをパフォーマンス満足度メトリックと呼びます。

次の表に示すように、様々なパフォーマンス目標を使用してワークロードのパフォーマンスを測定します。

ワークロード・タイプ

パフォーマンス目標

OLTP

レスポンス時間、1秒当たりのトランザクション

バッチ

速度、スループット

DSS

読取りまたはキャッシュ・ヒット率、期間、スループット

現在、Oracle Database QoS ManagementではOLTPワークロードのみサポートされます。OLTPワークロードについては、レスポンス時間パフォーマンス目標のみ構成できます。

関連項目:

「パフォーマンス概要グラフの解釈」

パフォーマンスの問題を識別するためのメトリックの使用方法

Oracle Database QoS Managementメトリックは、システムのパフォーマンス・クラス・ボトルネックをシステムで識別するために必要な情報を提供します。パフォーマンス・クラスがそのパフォーマンス目標に違反している場合、そのパフォーマンス・クラスのボトルネックは、そのパフォーマンス・クラスの各作業リクエストの最大平均待機時間に寄与するリソースです。

Oracle Database QoS Managementメトリックを使用して、次の手順でパフォーマンス・クラスのボトルネックを探します。

1. Oracle Database QoS Managementは、パフォーマンス目標を満たしていない、最もランクの高いパフォーマンス・クラスを選択します。

2. そのパフォーマンス・クラスについて、収集されたメトリックから各リソースの待機時間が判断されます。

3. リクエスト当たりの待機時間が最も長いリソースが、ボトルネック・リソースとして判断されます。

各データベース・リクエストの平気待機時間と各パフォーマンス・クラスの合計リクエスト数を分析すると、各パフォーマンス・クラスのレスポンス時間のリソース待機時間コンポーネントが提供されます。このような貢献度が最大のリソース(CPU、ストレージI/O、グローバル・キャッシュまたはその他)がパフォーマンス・クラスの現在のボトルネックです。

関連項目:

「リソース待機時間のブレークダウンの表示」

2 サポートされるワークロードと方針

この章では、Oracle Database Quality of Service Management(Oracle Database QoS Management)を使用してシステムのワークロードを管理する様々な方法と、Oracle Database QoS Managementを効果的に使用するためのシステムの構成に関するベスト・プラクティスについて説明します。

- Oracle Database QoS Managementでサポートされる構成

- パフォーマンス・クラスの分類子の作成方針

- 効果的なリソース管理のための構成方針

- Oracle Database QoS Managementの実装例

- デモ・システムのOracle Database QoS Managementパフォーマンス・ポリシーの作成

- Oracle Database QoS Managementでのサービス・レベルの管理

Oracle Database QoS Managementでサポートされる構成

Oracle Database QoS Managementを使用するには、システムが特定の要件を満たしている必要があります。また、アプリケーションとデータベース接続が特定の標準に従っている必要もあります。

サポートされている構成を使用しない場合、Oracle Database QoS Managementは構成違反をレポートし、無効になります。

- サポートされるサーバー・プール構成

- サポートされるデータベース構成

- サポートされるサービス構成

- サポートされるワークロードと目標のタイプ

サポートされるサーバー・プール構成

Oracle Database QoS Managementでは、クラスタとデータベースがサーバー・プールを使用する必要があります。汎用プール内のデータベースはOracle Database QoS Managementで管理できず、ユーザー・インタフェースに表示されません。空きプール内のサーバーを使用して、管理対象サーバー・プールにリソースを追加できます。

Oracle Database QoS Managementがクラスタのリソースを管理するためには、パフォーマンス・ポリシーでサーバー・プールを管理対象としてマークする必要があります。サーバー・プールがOracle Database QoS Managementで管理されていない場合、そのサーバー・プールはOracle Database QoS Managementサーバーから参照できません。マークされていないサーバー・プール内のワークロードまたはリソースは、Oracle Database QoS Managementによって管理されません。

サーバー・プールにデータベース・インスタンスが含まれていない場合、または現在のサイズがゼロの場合でも、Oracle Database QoS Managementで管理するサーバー・プールを選択できます。これにより、ワークロードが開始する前に、Oracle Database QoS Managementで管理するサーバー・プールを事前に構成できます。また、サーバー・プールの最小サイズをゼロに構成した場合、Oracle Database QoS Managementはそのサーバー・プールからサーバーを削除して、より優先度の高いワークロードにリソースを提供できます。この場合は、サーバー・プールにOracle Database QoS Managementで管理するリソースがなくても、そのサーバー・プールで実行されているワークロードは引き続き監視され、可能な場合にはワークロードをサポートするためにそのサーバー・プールにリソースが割り当てられます。

サポートされるデータベース構成

Oracle Database QoS Managementは、リリース11.2.0.2以降のOracle RACデータベースとのみ連動します。Oracle Database QoS Managementの機能を最大限に活用するには、データベースを、サーバー・プールで実行されるポリシー管理型データベースとして構成する必要があります。データベース・インスタンスによって使用される基礎となるサーバー・プールは、Oracle Database QoS Managementで管理されるものとしてマークする必要があります。汎用サーバー・プールの管理者管理型データベースの場合、Oracle Database QoS Managementはワークロードとレスポンス時間を計測および監視します。

データベース・サービスはUNIFORMサービスとして作成する必要があります。これは、指定されたサーバー・プールで実行されている使用可能なすべてのインスタンスによって、サービスが提供されることを意味します。アプリケーションでSINGLETONサービスが必要な場合、Oracle Database QoS Managementを管理モードで使用するために、最大サイズを持つサーバー・プールでサービスを実行する必要があります。最大サイズが1より大きいサーバー・プールでSINGLETONサービスを使用すると、Oracle Database QoS Managementは構成違反をレポートします。このデータベースの管理モードに測定のみが選択されている場合、任意の構成でSINGLETONサービスを使用できます。

Oracle Database QoS Managementでは、サーバー・プールを共有する複数のデータベースがサポートされます。同じサーバー・プールを使用している複数のデータベースがある場合は、サーバー・プールを使用するすべてのデータベースでOracle Database QoS Managementが有効になっている必要があります。Oracle Database QoS ManagementではOracle RAC One Nodeデータベース(シングルトン・データベースとも呼ばれます)もサポートされますが、これらのデータベースでは最大サイズが1のサーバー・プールを使用する必要があります。

データベースを作成する場合、データベース・インスタンスのCPU_COUNT初期化パラメータのデフォルト値は、インスタンスが実行されている各ノード上の物理的なCPUの数に設定されます。同じノードに複数のデータベース・インスタンスがある場合は、各インスタンスのCPU_COUNTの値を調整して、ノードで実行されている各インスタンスのCPU_COUNTの合計が、そのノード上の物理的なCPUの数以下になるようにする必要があります。また、CPU_COUNTの値はデータベースのすべてのインスタンスに対して同じである必要があります。たとえば、両方のインスタンスが同じサーバー・プールにある場合、salesデータベースで、sales1インスタンスに対してCPU_COUNTを4に設定し、sales2インスタンスに対してCPU_COUNTを2に設定することはできません。

関連項目:

『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

サポートされるサービス構成

Oracle Database QoS Managementには、Oracle Clusterwareで管理されているデータベース・サービスが必要です。Oracle Database QoS Managementで管理されているすべてのワークロードは、Oracle Clusterwareで管理されているデータベース・サービスを使用してデータベースに接続する必要があります。デフォルトのデータベース・サービスは使用できません。デフォルトのデータベース・サービスは、Oracle Clusterwareで管理されていません。

データベースへの接続に使用されるサービスはUNIFORMである必要があります。アプリケーションにSINGLETONサービスが必要な場合、Oracle Database QoS Managementを使用するには、最大サイズが1のサーバー・プールでサービスが実行されている必要があります。

Oracle RAC高可用性フレームワークは、データベースとそのサービスを監視し、高速アプリケーション通知(FAN)を使用してイベント通知を送信します。Oracle ClusterwareとOracle Net Servicesは、サービス構成で指定されたルールに従ってサービスのロード・バランシングを行います。これらのルールは次のとおりです。

- 接続ロード・バランシングの目標: インスタンスの現在のワークロードと接続のタイプ(LONGまたはSHORT)を使用して接続がインスタンスにルーティングされ、最高のパフォーマンスを実現できるインスタンスが判断されます。Oracle Database QoS Managementでは、新規サーバーがサービスのサーバー・プールに割り当てられている場合に新規接続が新規サーバーにより高速に移行するように、接続ロード・バランシングの目標をLONGに設定する必要があります。接続を新規サーバーにより迅速に移行することで、ワークロードは使用可能なすべてのインスタンスにより高速に分散され、ワークロードのレスポンス時間がより高速に向上します。

- ランタイム接続ロード・バランシングの目標: ロード・バランシング・アドバイザ・データを使用して、サービスに対して指定されている目標を最もよく満たしているインスタンスが判断されます。2つの目標は、SERVICE_TIME(ロード・バランシング・アドバイザ・データはインスタンス内で行われた作業の経過時間に基づきます)とTHROUGHPUT(ロード・バランシング・アドバイザ・データはインスタンス内で作業が完了する速度に基づきます)です。Oracle Database QoS Managementでは、オプションで最大サイズが1のサーバー・プールを除き、サーバー・プールを使用するすべてのデータベース・サービスに対してランタイム接続ロード・バランシングの目標をSERVICE_TIMEに設定する必要があります。

ランタイム接続のロード・バランシングは、Oracle RACデータベース内のインスタンス間で接続リクエストのバランスをとる方法について接続プールにアドバイスを送信します。ロード・バランシング・アドバイザは、受信した作業に対して最適なサービス・クオリティを提供するインスタンスにその作業を転送する方法についてのアドバイスも提供します。これにより、後で作業を再配置する必要性が最小化されます。

サービスのロード・バランシング目標を構成するには、次の例で示すServer Control(SRVCTL)ユーティリティまたはEnterprise Managerを使用します。

srvctl modify service -db db_name -service service_name -rlbgoal SERVICE_TIME -clbgoal LONG

サポートされるワークロードと目標のタイプ

Oracle Database QoS Managementの初期リリースでは、オンライン・トランザクション処理(OLTP)ワークロードのみサポートされます。サポートされるパフォーマンス目標は、データベース・リクエストの平均レスポンス時間のみです。Oracle Database QoS Managementは、オープン・ワークロード、つまり要求がレスポンス時間に依存しないワークロードを管理するように設計されています。

アプリケーション・ワークロードのデータベース・リクエストは、平均レスポンス時間が1秒未満である必要があり、平均時間が0.5秒未満であることが理想です。パフォーマンス・クラス内の各データベース・リクエストは、リソース使用率が同質である必要があります。ワークロードのデータベース・リクエストのサブセットが他のリクエストよりも非常に多くのリソースを使用する場合、新しいパフォーマンス・クラスを作成して、より多くのリソースを必要とするデータベース・リクエストを含める必要があります。「新規パフォーマンス・クラスの作成の決定」を参照してください。

Oracle Database QoS Managementでは、パラレル問合せを含むワークロードはサポートされません。デフォルトでは、パラレル問合せは、データベースへの接続に使用されたサービスに関係なく、データベースのすべての使用可能インスタンスで実行されます。そのため、ワークロードが含まれていないか、サービスを提供するインスタンスのみでの実行に制限されます。同様の理由で、Oracle Database QoS Managementでは、GV$ビューへの問合せを伴う大量のデータベース・リクエストを含むワークロードはサポートされません。

Oracle Database QoS Managementで管理されるワークロードでは、データベース接続にOracle Clusterwareで管理されているデータベース・サービスを使用する必要があります。接続を開始するクライアントまたはアプリケーションは、JDBC(シックまたはシン)クライアント、つまりOCIクライアントである必要があります。データベースへのbequeath接続を使用するワークロードは、Oracle Database QoS Managementで管理されません。

パフォーマンス・クラスの分類子の作成方針

現在、Oracle Database QoS Managementで管理されるワークロードはOLTPデータベース・ワークロードのみです。データベースのワークロードを管理するには、受信作業リクエストがパフォーマンス・クラスに割り当てられる必要があります。ワークロードは分類子を使用してパフォーマンス・クラスにマップされます。

複数層環境では、クライアントからのリクエストが中間層またはロード・バランシングによって様々なデータベース・セッションにルーティングされるため、データベース・セッション間でのクライアントの追跡が難しくなります。分類子は、セッション属性を使用して作業リクエストを識別します。使用される属性は、サービス名、ユーザー名、モジュール・アクションおよびプログラムです。「作業リクエストを分類するための追加フィルタの使用方法」を参照してください。

各分類子では1つ以上のサービス名を指定する必要があります。分類子で複数のサービス名が指定されている場合、接続データをパフォーマンス・クラスと照合するときに、サービス名がOR演算子を使用して評価されます。分類子で指定されているサービス名の1つが作業リクエストのサービス名と一致した場合、比較はTRUEと評価されます。

MODULEおよびACTION属性を設定するには、OCIAttrSet()コールを使用します。アプリケーション・コンテキストには、デフォルトのネームスペースであるUSERENVを使用します。

オプションで、分類子にUserNameおよびプログラム名を含めることもできます。ユーザー名は、セッションが接続するデータベース・ユーザーの名前です。プログラム属性は、サーバーへのログインに使用したクライアント・プログラムの名前です。

パフォーマンス・クラスの分類子に複数の属性が指定されている場合、セッション属性はAND演算を使用して結合されます。分類子で指定されているすべての属性値が作業リクエストのセッション属性値と一致した場合、比較はTRUEと評価されます。類似する属性値を使用する分類子が複数ある場合は、最もきめ細かい条件を持つ分類子を先頭に配置します。「作業リクエストへの分類子の適用」を参照してください。

たとえば、次の分類子について考えます。

- sales_cartサービス、ORDERモジュールおよびCALCULATE TAXアクションを指定するcreate_invoice_taxes_pc

- sales_cartサービスおよびORDERモジュールを指定するcreate_invoice_pc

create_invoice_taxes_pc分類子は、create_invoice_pc分類子より前に評価する必要があります。作業リクエストがsales_cartサービスを使用し、ORDERモジュールのCALCULATE TAXアクションを実行している場合、この作業リクエストはcreate_invoice_taxes_pcに割り当てられます。作業リクエストのすべての属性について一致する値がない場合、作業リクエストは次の分類子であるcreate_invoice_pcと比較されます。create_invoice_pc分類子を最初に評価した場合は、作業リクエストが実行するアクションに関係なく、sales_cartサービスとORDERモジュールを使用するすべての作業リクエストがcreate_invoice_pcパフォーマンス・クラスに割り当てられます。

1つのクラスタに対して最大47個のパフォーマンス・クラスを作成できます。クラスタに47を超えるサービスがある場合は、分類子内で複数のサービス名を使用します。分類子に対して一致が見つかると、Oracle Database QoS Managementは一致する作業リクエストにタグを割り当てます。タグは、TRUEに評価される分類子に基づきます。「パフォーマンス・クラス・タグ」を参照してください。

効果的なリソース管理のための構成方針

ここでは、Oracle Database QoS Managementによって管理されるシステムの構成の主要な推奨と要件について説明します。

- リソース・ボトルネックについて

- CPUリソース・ボトルネック

- グローバル・キャッシュ・リソース・ボトルネックの構成の推奨

- I/Oリソース・ボトルネックの構成の推奨

- その他のタイプのボトルネックの構成の推奨

リソース・ボトルネックについて

Oracle Database QoS Managementは、CPU、グローバル・キャッシュ、I/Oおよびその他のリソースの使用時間と待機時間を測定して、ボトルネックの場所を判断します。

ターゲットのパフォーマンス・クラスとそのボトルネック・リソースはOracle Database QoS Managementダッシュボード(ダッシュボード)で識別されますが、このリリースでアクティブに管理されるのはCPUリソースのみです。

CPUリソース・ボトルネック

CPUリソース・ボトルネックは、ワークロードを実行しているCPUキューのコレクションでの待機時間が過剰な場合に検出されます。Oracle Database QoS Managementは、ボトルネックを緩和するために実装できる推奨を提供します。

このタイプのボトルネックを解決する1つの方法は、ワークロードをCPUで実行する機会を増やすことです。Oracle Database QoS Managementは、サーバー・プール間でCPU占有率の高いコンシューマ・グループにワークロードを割り当てることで、この解決策を実装します。

もう1つの解決策は、提供するCPUリソースを増やすことです。サーバー・プールの各サーバーで複数のインスタンスがCPUリソースを共有していて、インスタンス・ケージングが実装されている場合、Oracle Database QoS Managementはサーバー・プール内のインスタンスのCPU数の変更を提案できます。この解決策では、ランクの低いインスタンスまたはヘッドルームのあるインスタンスからCPUリソースを奪ってリソースを増やし、パフォーマンスの期待値に達していないワークロードにより多くのCPUリソースを与えます。

インスタンス間のCPU数を調整することで緩和できないCPUリソース・ボトルネックがある場合、Oracle Database QoS Managementは新しいサーバーをサーバー・プールに移動することを推奨できます。空きプール、よりストレスの少ないサーバー・プール、または重要度の低いワークロードをホストしているサーバー・プールからサーバーを移動できます。

グローバル・キャッシュ・リソース・ボトルネックの構成の推奨

グローバル・キャッシュ・リソース・ボトルネックは、データベース・インスタンス間でのデータ・ブロックの移動が過剰な場合に検出されます。これは通常、正しく構成されていないか水平にスケーリングできないアプリケーションが原因で発生します。アプリケーションを最大サイズが1のサーバー・プールで実行するように構成するかデータをパーティション化すると、通常はボトルネックが緩和されます。

Oracle Database QoS Managementは、このリリースではどちらのアクションも実行できず、このタイプのボトルネックに対して実装できる推奨を提供しません。

I/Oリソース・ボトルネックの構成の推奨

I/Oリソース・ボトルネックは、ストレージ・サブシステムでの待機時間が過剰な場合に検出されます。このタイプのボトルネックは、通常はディスク・スピンドルが少なすぎるか、ストレージ相互接続上のネットワーク帯域幅が十分でないことが原因で発生します。このボトルネックを解決するには、より多くのディスクにデータベース・ファイルを分散するか、別のネットワーク・インタフェース・カード(NIC)をストレージ相互接続専用に構成します。

Oracle Database QoS Managementは、このリリースではこのタイプのボトルネックを解決できず、実装できる推奨を提供しません。

その他のタイプのボトルネックの構成の推奨

ボトルネックの分類に使用される最後のリソース・タイプ「その他」は、他のすべての待機時間に使用されます。これらのデータベース待機時間は、通常、最適化されていないアプリケーションやラッチの待機などによるSQLパフォーマンスの問題が原因です。これらのボトルネックは、自動ワークロード・リポジトリ(AWR)や自動データベース診断モニター(ADDM)などのOracle Databaseチューニング・ツールを使用して調査できます。

これらのタイプのボトルネックの解決は、Oracle Database QoS Managementで提供されるランタイム・システム管理の範囲外であり、Oracle Database QoS Managementは実装できる推奨を提供しません。

Oracle Database QoS Managementの実装例

ここでは、Oracle Database QoS Managementの実装例について説明します。Oracle Database QoS Managementがパフォーマンスを管理するプロセスについて説明します。

- デモ・システムの説明

- システム・ワークロードの説明

- 初期のOracle Database QoS Management構成

デモ・システムの説明

実装例では、Linux上で実行されている4ノード・クラスタを使用します。

ノードの名前はtest_rac1からtest_rac4までです。通常の操作では、各ノードは次の処理を行います。

ノード

目的

サービス

test_rac1

クラスタ用Oracle Grid Infrastructureとbackofficeデータベースの最初のデータベース・インスタンスを実行します。

HRおよびERP

test_rac2

クラスタ用Oracle Grid Infrastructureとbackofficeデータベースの2つ目のデータベース・インスタンスを実行します。

HRおよびERP

test_rac3

クラスタ用Oracle Grid Infrastructureとonlineデータベースの最初のデータベース・インスタンスを実行します。

SalesおよびSales_Cart

test_rac4

クラスタ用Oracle Grid Infrastructureとonlineデータベースの2つ目のデータベース・インスタンスを実行します。

SalesおよびSales_Cart

クラスタは、次の制約のある2つのサーバー・プールに論理的に分割されます。

名前

最小サイズ

最大サイズ

現行サイズ

重要度

backoffice

1

-1

2

1

online

1

-1

2

2

Free

0

-1

0

0

ここで示すサーバー・プール制約は、少なくとも1台のサーバーが各サーバー・プール(およびそれらのサーバー・プールで実行されるデータベース)に割り当てられ、残りのサーバーはサービス・レベルを管理するためにオンデマンドで共有できることを保証します。onlineサーバー・プールは、「重要度」の値が最高であるため、最もクリティカルなワークロードをホストします。サーバー障害が発生した場合、onlineサーバー・プールの最小サイズの維持が、他のサーバー・プールの最小サイズの維持よりも優先されます。

システム・ワークロードの説明

データベースには、様々なタイプのワークロードがあります。

このリリースのOracle Database QoS Managementは、OLTPワークロードの管理に重点を置いています。このタイプは、オープン・ワークロード(システム・パフォーマンスが低下した場合でも要求が一定のワークロード)が発生する可能性が最も高く、ワークロードの急増による停止に対して脆弱です。このデモでは、同じクラスタでホストされている内部ワークロードと外部ワークロードの組合せがあり、リソースを共有できることを想定しています。

このデモ・システムには、図2-1に示すように4種類のワークロードがあります。

- ERPサービスを使用してbackofficeサーバー・プールのデータベース・インスタンスに接続するJ2EEに基づくERPアプリケーション

- HRサービスを使用してbackofficeサーバー・プールのデータベース・インスタンスに接続するOracle C Interface(OCI)に基づく内部HRアプリケーション

- Salesサービスを使用してonlineサーバー・プールのデータベース・インスタンスに接続するJ2EEに基づく外部Salesアプリケーション

- Salesサービスを使用してonlineサーバー・プールの特定のデータベース・ユーザーを介してデータベース・インスタンスに接続するJ2EEに基づく外部販売チェックアウト・アプリケーション(Sales Cart)

図2-1 サンプル・ワークロードの図

2つのサーバー・プールを使用することで、ワークロードとそれらの依存データベースは論理的に分離されますが、それらの間でリソースを簡単に共有できます。

初期のOracle Database QoS Management構成

最初、このシステムにはOracle Database QoS Managementが構成されていません。Oracle Enterprise Manager Cloud Controlを使用して、クラスタに対してOracle Database QoS Managementを有効にするために完了する2つの構成ワークフローがあります。最初のワークフローでは各データベースをOracle Database QoS Management用に構成し、2つ目のワークフローではクラスタに対してOracle Database QoS Managementを構成および有効化します。

関連項目:

Oracle Database QoS Managementの有効化の詳細は、「Oracle Database QoS Managementの有効化」を参照してください

デフォルトのポリシー・セットを作成した後で、自動的に検出されるデータベース・サービスを使用して、Oracle Database QoS Managementを微調整してそれぞれのサービス・レベル合意または目標にワークロードを合せることができます。

デモ・システムのOracle Database QoS Managementパフォーマンス・ポリシーの作成

ここでは、Oracle Database QoS Managementの実装例をさらに進化させて、パフォーマンス・ポリシーの作成とアクティブ化、および追加のパフォーマンス・クラスでの調整を含めます。

測定のみモードでデータベース・サービスを検出することでデフォルトのパフォーマンス・ポリシーが作成されるため、最初にデフォルトのパフォーマンス・ポリシーをアクティブにし、クラスタ内ですべてのワークロードがどのように実行されるかをテストできます。ダッシュボードには、様々な要求期間中の各パフォーマンス・クラスの平均レスポンス時間を構成するリソースの使用時間と待機時間の両方が表示されます。これらの数値は、割り当てられたリソースで達成できる最小レスポンス時間を理解するのに役立ちます。

定期的に異なる時間にワークロードがピークになる場合、またはサービス・レベル合意(SLA)が時間や曜日などに基づいて変化する場合は、サーバー・プールのサイズを変更する測定のみのパフォーマンス・ポリシーを追加で作成して、ワークロードに必要な最小リソースを評価します。このデモでは、Salesアプリケーションについて、onlineサーバー・プールを使用するワークロードが最低2台のサーバーを必要とします。backofficeサーバー・プールは、ワークロード・リクエストを満たすために1台のサーバーのみ必要とします。両方のサーバー・プールに現在2台のサーバーが含まれている場合は、backofficeサーバー・プールの最小サイズを1に設定することにより、onlineサーバー・プールが必要に応じてbackofficeサーバー・プールからサーバーを取得できるようにすることができます。「Business Hours」パフォーマンス・ポリシーでサーバー・プールのディレクティブ・オーバーライドを使用して、backofficeサーバー・プールの最小サイズを1に指定します。

サーバー・プールの最小サイズは、そのサーバー・プールが所有しているサーバー数として解釈できます。クラスタ内のすべてのサーバー・プールの最小サイズの合計がクラスタ内のサーバー数より少ない場合、余分なサーバーはフロータと呼ばれ、すべてのサーバー・プールで共有されます。たとえば、クラスタに15台のサーバーと3つのサーバー・プールがあり、各サーバー・プールの最小サイズが4の場合、システムには3つのフロータがあります。

パフォーマンス・ポリシーが測定のみモードで実行された後、パフォーマンス目標を各パフォーマンス・クラスに追加できます。パフォーマンス目標は、そのパフォーマンス目標の維持がビジネスにとってどれほど重要かに基づいてランク付けされます。パフォーマンス目標は、観察されたレスポンス時間より長くSLAを満たすのに必要なレスポンス時間より短い範囲でヘッドルームが最大になるように設定する必要があります。パフォーマンス・クラスでワークロード・サージが発生する場合は、少なくとも50%のヘッドルームを維持することが、リソースのトレードオフをサポートするための適切な開始点です。たとえば、パフォーマンス・クラスの平均レスポンス時間が2ミリ秒(ms)の場合、パフォーマンス目標は3ms(2msのレスポンス時間と、50%のヘッドルームに対応する1ms)に設定できます。

サービスベースの分類子によって構成が簡単になりますが、サービスのパフォーマンス目標を複数定義することが必要になる場合があります。たとえば、salesサービスには、製品の参照、顧客アカウントの追加、ショッピング・カート、注文の参照などの多くの異なるワークロードが含まれる場合があります。ショッピング・カート・ワークロードは収益を生成するため、このワークロードのレスポンス時間は他のワークロードよりも短くする必要があります。別のパフォーマンス・クラスおよび関連する分類子を作成して、様々なワークロードに対して特定のパフォーマンス目標を指定する必要があります。

ポリシー・セット・ウィザードの分類子の定義ページで、サービス名にsalesと入力することでsales cart(営業カート)パフォーマンス分類子を定義できます。アプリケーションでMODULEまたはACTIONを設定できる場合は適切な値を入力し、それ以外の場合は中間層とは別のUSERNAMEを構成します。新しいパフォーマンス・クラスを定義すると、測定のみモードのすべてのパフォーマンス・ポリシーにパフォーマンス・クラスが自動的に表示されます。新しいパフォーマンス・クラスには、デフォルトで最も低いランクが付けられます。最初はこれらの値を使用して、システムのパフォーマンスをテストします。平均パフォーマンス・レベルが特定できたら、このパフォーマンス・クラスのパフォーマンス目標とランクを各パフォーマンス・ポリシー内に設定できます。

Oracle Database QoS Managementでのサービス・レベルの管理

Oracle Database QoS Managementの実装は、サービス・レベルをアクティブに管理することで完了します。管理とは、アラートへの応答、推奨事項の確認および実装、結果の追跡を意味します。この項では、デモ・システムで実行するアクションについて説明します。

すべてのワークロードが実行され、ダッシュボードにデモ・システムのパフォーマンスが表示された後、ワークロード・サージまたは障害が原因でパフォーマンス目標が満たされなくなっている場合にアラートを生成する必要があります。パフォーマンス満足度メトリック(PSM)は、すべての目標を正規化し、システムの状態を迅速に観察する方法を提供します。PSM傾向インジケータを観察することで、パフォーマンス・クラスが過去5分間にその目標をどの程度満たしていたかを確認し、問題を観察できます。パフォーマンス目標違反によって、ボトルネックを緩和するためにリソースを再割当てする方法を示す推奨が生成されます。ボトルネックおよび考えられる解決策をさらに分析するために詳細と予測を使用できます。推奨がOracle Database QoS Managementで実装できるアクションの場合は、「実装」ボタンが表示されます。

ほとんどのSLAでは、短期間のパフォーマンス目標違反は許容されます。したがって、パフォーマンス・クラスでEnterprise Managerアラートを構成して継続的な違反の期間を指定できます。これらのアラートはデータベース・アラート・ページで構成されますが、クラスタ内のすべてのパフォーマンス・クラスに対して定義できます。

ポリシー変更、違反およびアクションの監査ログは、Oracle Database QoS Managementサーバーをホストするサーバー上のoc4j/j2ee/home/log/dbwlm/auditingディレクトリにあるOracle Grid Infrastructureホームにあります。Oracle Database QoS Managementサーバーをホストしているサーバー(OC4Jコンテナ)を判断するには、オペレーティング・システムのプロンプトに次のコマンドを入力します。

srvctl status oc4j

3 Oracle Database QoS Managementのインストールおよび有効化

この章では、システムにOracle Database QoS Managementをインストールして構成するために完了する必要のあるタスクについて説明します。この項の一部のタスクは、クラスタ管理者が実行する必要があります。

注意:

クラスタ管理者の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

Oracleデータベースのワークロードを管理するためのOracle Database QoS Managementの構成

Oracle Database QoS Managementと連動するためのクラスタ用Oracle Grid InfrastructureおよびOracle RACデータベースの構成には、次の一般的なタスクが含まれます。

1. データベース管理者(DBA)は、データベースで使用するサーバー・プールへのアクセスをリクエストします。クラスタ管理者はDBA用のサーバー・プールを作成し、そのサーバー・プールへのアクセス権限をDBAに付与します。クラスタ管理者ユーザーがDBAユーザーと同じ場合は、DBCAでポリシー管理オプションを選択することにより、DBCAの実行時にサーバー・プールを作成できます。サーバー・プールは、インストール後にServer Control(SRVCTL)を使用して作成することもできます。

このサーバー・プールの最小サイズはデータベース・インスタンス数です。サーバー・プールの最大サイズが最小サイズより大きい場合は、ピーク・ワークロードを処理するため、または拡張に対応するために、データベースに新しいインスタンスを追加できます。

2. DBAは、DBCAでポリシー管理オプションを選択して、割り当てられたサーバー・プール内にOracle RACデータベースを作成します。

3. DBAは、Oracle Clusterwareで管理されるデータベース・サービスを作成して、各サービスをサーバー・プールに割り当てます。アプリケーション・ユーザーは、それらのサービスを使用してデータベースに接続します。

4. DBAは、Enterprise Manager Cloud Controlを使用して、データベースでOracle Database QoS Managementを有効にします。

Oracle Database QoS Management管理者の初期構成タスクについては、次の各項で詳細に説明します。

- クラスタ用Oracle Grid Infrastructureのインストールおよび構成

- サーバー・プールの作成および構成

- Oracle RACデータベースの作成および構成

- Oracle Database QoS Managementの有効化

クラスタ用Oracle Grid Infrastructureのインストールおよび構成

クラスタ用Oracle Grid Infrastructureのインストールおよび構成は、本書の対象外です。クラスタ用Oracle Grid Infrastructureのインストールおよび構成の詳細は、ご使用のプラットフォーム向けの『Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイド』を参照してください。

サーバー・プールの作成および構成

デフォルトでは、Oracle Grid Infrastructureのインストール中に、空きプールと呼ばれるサーバー・プールが作成されます。Oracle RACデータベース用のサーバー・プールを作成するには、SRVCTLまたはOracle Enterprise Managerを使用できます。

DBCAを使用してOracle RACデータベースを作成する場合は、データベースをポリシー管理することを選択し、データベース・インスタンスを実行するサーバー・プールを選択します。

関連項目:

- サーバー・プールの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- SRVCTLを使用したサーバー・プールの作成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

- DBCAを使用したOracle RACデータベースの作成の詳細は、『Oracle Real Application Clustersインストレーション・ガイド for Linux and UNIX』を参照してください。

クラスタ管理者がデータベース管理者と異なる場合は、クラスタ管理者ユーザーのみがサーバー・プールを作成できます。クラスタ管理者は、インストールされたOracle RACを所有するオペレーティング・システム・ユーザーに、サーバー・プールに対する権限を付与します。詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

注意:

Oracle Database QoS Managementで使用するサーバー・プールを作成するときに、サーバー・プールのSERVER_NAMES属性(srvctl add svrpoolコマンドまたはsrvctl modify svrpoolコマンドの-serversオプション)を構成しないでください。Oracle Database QoS Managementでは、候補リストを使用するサーバー・プールはサポートされません。

Oracle RACデータベースの作成および構成

Oracle RACデータベースの作成および構成の手順は、本書の対象外です。サーバー・プールを使用するOracle RACデータベースの作成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。データベースの作成時に、DBAはポリシー管理型データベースの作成を選択する必要があります。

データベースの作成後、次の手順を実行して、Oracle Database QoS Managementで使用するようにデータベースを構成します。

- データベース初期化パラメータの変更

- データベース・サービスの作成

データベース初期化パラメータの変更

データベースがOracle Database QoS Managementで管理される場合、サーバー・プールで実行される各データベース・インスタンスのCPU_COUNTパラメータを同じ値に設定する必要があります。

各サーバーで実行されるすべてのデータベース・インスタンスのCPU_COUNT値の合計を、物理CPU数以下にする必要があります。たとえば、8つのCPUを持つサーバーがあり、このサーバーで2つのデータベース・インスタンスが実行されている場合は、Oracle Database QoS Managementで管理するデータベースに対して、サーバー上のすべてのデータベース・インスタンスのCPU_COUNTパラメータ値の合計が8以下になるように各インスタンスのCPU_COUNTパラメータを設定する必要があります。たとえば、あるインスタンスでCPU_COUNT=3、もう一方のインスタンスでCPU_COUNT=4と設定するか、あるインスタンスでCPU_COUNT=6、もう一方のインスタンスでCPU_COUNT=2と設定します。

注意:

デフォルトでは、サーバーで起動される各データベースのCPU数は、そのサーバーにインストールされている物理CPU数に設定されます。

サーバー・プールで複数のデータベースを実行している場合、CPU_COUNTにデフォルト設定を使用すると、Oracle Database QoS Managementで違反がレポートされます。このエラーを回避するには、Oracle Enterprise ManagerまたはSQL*Plusを使用して、SPFILEのCPU_COUNT値を手動で構成する必要があります。

- Oracle RACデータベースの全インスタンスのCPU_COUNTデータベース初期化パラメータを変更するには、SQL*Plusを使用します。

ALTER SYSTEM SET cpu_count=n SCOPE=BOTH SID='*';

このコマンドで、nは、データベース・インスタンスで使用する必要があるCPUの数です。

CPU_COUNTは、デフォルトでは設定されない動的パラメータです。この値は、データベース・インスタンスが常に利用する最大CPU数に設定する必要があります。サーバー上のすべてのインスタンスのCPU_COUNT値の合計が、そのサーバーの物理CPU数を超えることはできません。CPU_COUNTには、最小値の2を使用することをお薦めします。

データベース・サービスの作成

アプリケーションおよびユーザーは、サービスを使用して、データベースに接続します。

Oracle RACデータベースのサービスの作成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle Database QoS Management管理者のアカウントの作成

Oracle Database QoS Managementダッシュボード(ダッシュボード)にログインする前に、Oracle Database QoS Management管理ユーザーを作成する必要があります。この設定を初めて行うときは、このアカウントに関連付けられているオペレーティング・システム・ユーザーがクラスタ管理者である必要があります。

Oracle Database QoS Managementサーバーの管理ユーザーは、QoS Adminユーザーと呼ばれます。このユーザーは、QoS Adminユーザーのアカウント・パスワードのチェックや変更など、Oracle Database QoS Managementサーバーのすべての機能にアクセスできます。複数のQoS Adminユーザーを作成することもできます。

QoS Adminユーザー・アカウントを作成するには、次の手順を実行します。

1. クラスタ管理者ユーザーとして、Oracle Database QoS Managementサーバーをホスティングしているノード(OC4Jコンテナ)にログインします。このノードは、Oracle Grid Infrastructureのホームで次のコマンドを使用して判断できます。

srvctl status oc4j

2. 次のコマンドを使用してOC4Jリソースを停止します。

srvctl stop oc4j

3. CRS管理者ユーザーとしてログオンし、次のコマンドを入力します。

qosctl qosadmin -setpasswd qosadmin

このコマンドを入力すると、デフォルトのQoS Adminユーザーのパスワードの入力を1回以上求められます。

別のユーザー名を使用する場合、次のコマンドを入力します。

qosctl qosadmin -adduser username

たとえば、次のとおりです。

- qosadminは、デフォルトのQoS Adminユーザーの名前です。

- usernameは、作成するQoS Adminユーザーの名前です。このユーザーのパスワードの入力を求められます。

4. 次のコマンドを使用してOC4Jリソースを再起動します。

srvctl start oc4j

関連項目:

QOSCTLユーティリティおよびそのコマンドの詳細な説明は、「Oracle Database QoS Managementの管理ユーザーの作成」を参照してください

Oracle Database QoS Managementの有効化

2つの異なるレベルのOracle Database QoS Managementを有効にできます。

- クラスタの管理

- クラスタで実行される個々のデータベースの管理

同一クラスタ上で複数のデータベースが実行されている場合、どのデータベースをOracle QoS Managementで管理するかを決定できます。データベースを管理するには、同じサーバー・プールを使用するすべてのデータベースでOracle Database QoS Managementを有効にする必要があります。有効にしない場合、データベースのダッシュボードにアクセスしようとすると、違反が通知されます。

システムでOracle QoS Managementを有効にするには、次の手順を実行します。

1. データベース・レベルでのOracle QoS Managementの有効化

2. 初期ポリシー・セットの作成

3. クラスタ・レベルでのOracle QoS Managementの有効化

データベース・レベルでのOracle QoS Managementの有効化

1. Oracle Enterprise Manager Cloud Controlにデータベース管理者としてログインします。

2. 「データベース・ターゲット」ページから、変更するデータベースを選択します。

3. 「可用性」、「サービスのクオリティ管理の有効化/無効化」の順に選択します。

4. 「クラスタ資格証明」および「データベース資格証明」に入力し、「ログイン」をクリックします。

注意:

この手順を完了するには、SYSDBAとクラスタ管理者アカウント両方のログイン情報を指定する必要があります。

「QoS管理を有功化/無効化」画面が表示されます。

5. APPQOSSYSユーザーのパスワードの入力を求められます。選択したパスワードを「パスワード」フィールドおよび「パスワードの確認」フィールドに入力し、「OK」をクリックします。

パスワードを入力すると、次の処理が行われます。

- Oracle Database QoS Managementサーバーがデータベースに接続できるようにするAPPQOSSYSアカウントがロック解除され、新しいパスワードが設定されます。

- Oracle Database QoS Managementがデータベースにログインできるようにするための資格証明が、Oracle Cluster Registryに格納されているOracle Walletに書き込まれます。

6. アクティブに管理されているすべてのデータベースでAPPQOS_PLANがアクティブなOracle Database Resource Managerプランとして設定されているため、Oracle Database QoS Managementはパフォーマンス・クラスのCPUアクセスを調整できます。APPQOS_PLANは、すべてのパフォーマンス・クラスで「測定のみ」が選択されているデータベースでは不要です。

初期ポリシー・セットの作成

1. Oracle Enterprise Manager Cloud Controlの「すべてのターゲット」ページで、Oracle Database QoS Managementが有効なクラスタ・データベースを実行しているクラスタを選択します。

2. 「管理」、「サービスのクオリティ管理」、「ポリシー・セットの作成」の順に選択します。

3. QoS Management管理者のパスワード(デフォルトのユーザー名はqosadmin)を使用して、Oracle Database QoS Managementサーバーにログインします。

4. ポリシー・セットの作成ウィザードの最初のページで、データベースを表すサーバー・プールの横の「管理」ボックスを選択します。たとえば、onlineやbackofficeなどです。「次」をクリックします。

5. Oracle Database QoS Managementを開始するには、初期構成のデフォルトを受け入れ、ウィザードの各ページで「次へ」をクリックしてデフォルトのポリシー設定を使用します。5番目のステップでは、「ポリシーの設定」をクリックしてDefaultPolicyを「選択されたアクティブ・ポリシー」として設定し、「次へ」をクリックします。

ポリシー・セットの作成ウィザードの最後のステップで、「ポリシー・セットの発行」をクリックします。

クラスタ・レベルでのOracle QoS Managementの有効化

1. Oracle Enterprise Manager Cloud Controlを使用して、「すべてのターゲット」ページでOracle Database QoS Managementが有効なクラスタ・データベースを実行しているクラスタを選択します。

2. 「管理」、「サービスのクオリティ管理」、「ダッシュボード」の順に選択します。

3. Oracle Database QoS Managementユーザー(qosadminなど)としてログインします。

4. ダッシュボード・ページの「一般」セクションに、Oracle Database QoS Managementの現在のステータスが表示されます。新規システムでは、ステータスは「無効」です。ステータスの横にある「無効」リンクをクリックして、このクラスタでOracle Database QoS Managementを有効にします。

4 Oracle Database QoS Managementシステムの管理

この章では、Oracle Database QoS Managementを使用してOracle RACクラスタのパフォーマンスを管理するときに実行する基本的な管理タスクについて説明します。

- Oracle Database QoS Managementが有効になっているかどうかの判断

- Oracle Database QoS Managementでのパフォーマンスの監視

- Oracle Database QoS Managementダッシュボードの使用方法

- ポリシー・セットの管理

- パフォーマンス・クラスの管理

- パフォーマンス・ポリシーの管理

- パフォーマンス・メトリックの確認

- Oracle Database QoS Managementの管理ユーザーの作成

- Oracle Database QoS Managementのリソース・プランの編集

Oracle Database QoS Managementが有効になっているかどうかの判断

Oracle Database QoS Managementは、クラスタ、サーバー・プール、データベースの3つのレベルで有効にできます。同じOracle RACクラスタ内に複数のデータベースがある場合、そのすべてがOracle Database QoS Managementによって管理されているとはかぎりません。

データベースの有効ステータスの確認

データベースがOracle Database QoS Managementで管理されているかどうかを判断するには、次の手順を実行します。

1. Cloud Controlにログインし、確認するデータベース・ターゲットを選択します。

2. ターゲットのメニューから、「クラスタ・データベース」、「ターゲット情報」の順に選択します。

3. 「ターゲット情報」ウィンドウの下部で、このデータベースに対してOracle Database QoS Managementが有効になっている場合、「QoSステータス」の値は「アクティブ」である必要があります。

クラスタの有効ステータスの確認

Oracle Enterprise Manager Cloud Controlを使用して、Oracle Database QoS Managementがクラスタに対して有効になっているかどうかを判断できます。

クラスタがOracle Database QoS Managementで管理されているかどうかを判断するには、次の手順を実行します。

1. Cloud Controlにログインし、確認するクラスタ・ターゲットを選択します。

2. ターゲットのメニューから、「管理」、「サービスのクオリティ管理」、「ダッシュボード」の順に選択します。

3. 要求されたら、QoSAdminユーザーとしてログインします。

4. ダッシュボードの「一般」セクションで、「QoSステータス」の値をチェックします。ステータス値が「有効」の場合は、クラスタがOracle Database QoS Managementによって管理されています。

Oracle Database QoS Managementでのパフォーマンスの監視

「Oracle Database QoS Managementの有効化」の説明に従ってOracle Database QoS Managementを有効にしてデフォルト・ポリシー・セットを作成したら、Oracle Database QoS Managementの使用を開始してシステムのパフォーマンスを監視できます。

測定のみモードまたはモニター・モードでは、ユーザー定義パフォーマンス・ポリシーのすべてのパフォーマンス・クラスで「測定のみ」ボックスが選択されています。パフォーマンス目標を設定すると、Oracle Database QoS Managementによりダッシュボードにパフォーマンス満足度メトリック(PSM)が表示されます。システムのレスポンス時間が指定されたパフォーマンス目標を超える場合、PSMバーが赤に変わり、オプションのアラートが生成されます(図4-1を参照)。「測定のみ」チェック・ボックスが選択されている場合、Oracle Database QoS Managementは推奨を作成しません。

図4-1 測定のみパフォーマンス・クラスのパフォーマンス満足度メトリック

Oracle Database QoS Managementを測定のみモードまたはモニター・モードで実行することで、リソース共有時の各種ワークロードのパフォーマンスを把握できます。測定のみモードまたはモニター・モード(Oracle Database 12cリリース12.1.0.2で使用可能)は、各パフォーマンス・クラスに使用するベースラインのパフォーマンス目標の決定に役立ちます。このモードを使用して、システムのパフォーマンス・ボトルネックを特定することもできます。

Oracle Database 11gリリース2 (11.2.0.3)以降、Oracle Database QoS Managementとシステム上のOracle RACを測定のみモードまたはモニター・モードで使用できます。

Oracle RACをExadataシステム上で使用している場合、Oracle Database QoS Managementをアクティブ管理モードで使用できます。アクティブ管理モードでは、パフォーマンス・クラスごとにパフォーマンス目標を指定し、Oracle Database QoS Managementはパフォーマンス・クラスが目標を満たしていない場合にパフォーマンスを向上させる推奨を作成できます。

関連項目:

- 「パフォーマンス・メトリックの確認」

- 「パフォーマンス・クラスの管理」

- 「パフォーマンス・ポリシーの作成とパフォーマンス目標の指定」

Oracle Database QoS Managementダッシュボードの使用方法

Oracle Database QoS Managementダッシュボード(ダッシュボード)は、Oracle Database QoS Managementシステムを管理するための使いやすいインタフェースを提供します。

- Oracle Database QoS Managementダッシュボードへのアクセス

- クラスタに対するOracle Database QoS Managementの有効化

- クラスタに対するOracle Database QoS Managementの無効化

- パフォーマンス概要グラフの解釈

- 推奨の表示

- 推奨の詳細の表示

- 推奨の実装

Oracle Database QoS Managementダッシュボードへのアクセス

ダッシュボードには4つの主要セクションがあります。

- 一般

- パフォーマンス概要

- 推奨

- リソース待機時間のブレークダウン

ダッシュボードの「一般」セクションには、システムの簡単な概要が表示されます。このセクションには、「QoSステータス」(「有効」または「無効」)、「現在のアクティブ・ポリシー」、パフォーマンス・クラスの詳細をチェックするためのリンク、および使用可能な推奨の通知が表示されます。現在のアクティブ・ポリシーをすばやく変更できるボタンもあります。

「パフォーマンス概要」セクションには、パフォーマンス・クラス、作業が行われているサーバー・プール、それらのランク、測定されているパフォーマンス目標、およびパフォーマンス目標の監視のみ行われているか、または監視と管理が行われているかを示す表があります。パフォーマンス・クラスごとに、パフォーマンス・クラス・メトリックの概要を示すグラフがあります。詳細は、「パフォーマンス概要グラフの解釈」を参照してください。

「推奨」セクションでは、パフォーマンス・クラスがそのパフォーマンス目標を満たしていない場合に使用できる推奨を確認できます。推奨が行われるのを阻止している違反も確認できます。

ダッシュボードの下部には、「リソース待機時間のブレークダウン」セクションがあります。このセクションには、パフォーマンス・クラスごとのリソース待機時間のブレークダウンを示す表があります。各パフォーマンス・クラスについて、ボトルネック・リソースは待機時間が最も長いリソースです。データは、推奨を生成するためにQoS Managementで使用されます。データは、システムを手動で調整するためにも使用できます。表にリストされている各パフォーマンス・クラスを展開すると、そのパフォーマンス・クラスのサーバー・プールと、各サーバー・プールのリソース待機時間を表示できます。

1. Cloud Controlにログインし、確認するクラスタ・ターゲットを選択します。

2. ターゲットのメニューから、「管理」、「サービスのクオリティ管理」、「ダッシュボード」の順に選択します。

3. ログイン画面が表示され、Oracle Database QoS Management管理者(QoSAdmin)資格証明の入力を求められます。ユーザー名とパスワードを入力した後で、「ログイン」をクリックします。

4. 適切な資格証明を入力すると、図4-2に示すように、「サービスのクオリティ管理ダッシュボード」ページが表示されます。

図4-2 Oracle Database Quality of Service Managementのダッシュボード

クラスタに対するOracle Database QoS Managementの有効化

1. ダッシュボードの「一般」セクションで、「QoSステータス」の横の「無効」をクリックします。

2. 「サービスのクオリティ管理の有効化/無効化」ページで、「QoS管理の有効化」をクリックします。

クラスタに対するOracle Database QoS Managementの無効化

1. ダッシュボードの「一般」セクションで、「QoSステータス」の横の「有効」をクリックします。

2. 「サービスのクオリティ管理の有効化/無効化」ページで、「QoS管理の無効化」をクリックします。

パフォーマンス概要グラフの解釈

ダッシュボードの「パフォーマンス概要」セクションには、図4-3に示すように、現在のパフォーマンス・クラスのリスト、各パフォーマンス・クラスに関する基本情報、およびそのクラスのパフォーマンス・メトリックの最近の傾向を示す2つの棒グラフがあります。

図4-3 「パフォーマンス概要」のグラフの例

図4-3はダッシュボードの「パフォーマンス概要」セクションで、棒グラフが埋め込まれた表で構成されています。表の行はパフォーマンス・クラスのリストになっており、そのパフォーマンス・クラスに関連付けられているサーバー・プール、ランクおよびオブジェクト・タイプが表示されています。また、各パフォーマンス・クラスの行には、待機時間と比較したリソースの使用を表す棒グラフと、過去5分におけるパフォーマンス満足度メトリックを表す棒グラフの2つがあります。リソースの使用VS待機時間の棒グラフには、リソース使用時間(青)、待機時間(グレーまたは赤)、およびパフォーマンス目標のヘッドルーム(緑)部分を示し、長さと色が変わる3つのセクションがあります。パフォーマンス満足度メトリックの棒グラフは左から右に伸びる1本の棒で表示され、緑と赤のセグメントは、パフォーマンス・クラスがパフォーマンス目標を超過(緑)または違反(赤)した5分間の時間スライスを表します。リソースの使用VS待機時間の棒グラフのセクションにカーソルを置くと、カーソルの側に測定値の説明が表示されます。

リソースの使用VS待機時間

リソースの使用VS待機時間のグラフは、ページの内容をリフレッシュしたときのみリフレッシュされます。次に、このグラフの内容を示します。

- 青いセクションは、過去5秒間のすべてのデータベース・リクエストについて、そのパフォーマンス・クラスがリソースの使用に費やした平均時間の部分を示します

- グレーのセクションは、過去5秒間のすべてのデータベース・リクエストについて、そのパフォーマンス・クラスがリソースの待機に費やした平均時間の部分を示します

- 緑のセクションは、過去5秒間のそのパフォーマンス・クラスのヘッドルーム(すべてのデータベース・リクエストに対し、指定されたパフォーマンス目標を下回った平均時間の割合)を示します。

- パフォーマンス・クラスがパフォーマンス目標を満たしていない場合は、グレーと緑とセクションが消えてリソース待機時間が赤で表示され、パフォーマンス目標が実際のレスポンス時間に対応する位置を示す線が表示されます。

- マウスのカーソルをこの棒グラフの任意のセクションの上に置くと、使用、待機およびヘッドルームの実際の値が表示されます。

棒グラフのグレーと緑のセクションの間のポイントは、パフォーマンス目標値です。この値をリソース使用時間より小さい値に設定すると、目標が満たされることがありません。パフォーマンス・クラスのパフォーマンス目標を構成する場合は、(緑で表示される)ヘッドルームを十分に生成できるパフォーマンス目標を設定して、要求が変化した場合にサービスを満たすためにパフォーマンス・クラス間でリソースを共有できるようにする必要があります。

パフォーマンス・クラスの棒グラフに赤のセクションが表示されている場合は、パフォーマンス・クラスがパフォーマンス目標を満たしていないことがわかります。Oracle Database QoS Managementは、可能な場合は問題を解決するために実装する推奨とアクションを発行します。Oracle Database QoS Managementで推奨が生成されるのは1分間に1回であるため、推奨が対応しているのは、現在のパフォーマンス目標グラフより前の時点です。

パフォーマンス満足度メトリック

パフォーマンス満足度メトリックは、特定の5分間のサンプルに対して赤と緑のセグメントを表示するように変化します。これを使用して、システムのパフォーマンスの傾向を見きわめることができます。

パフォーマンス満足度メトリックの棒グラフの意味は次のとおりです。

- 赤いセクションは、サンプリング期間中にパフォーマンス・クラスがパフォーマンス目標を満たしていなかった期間を表します。

- 緑のセクションは、サンプリング期間中にパフォーマンス・クラスがパフォーマンス目標を満たしていた期間を表します。

推奨の表示

推奨を表示する場合、予測される結果は次の3つです。

1. パフォーマンス・クラスがパフォーマンス目標を満たしている場合、「アクションは必要ありません: パフォーマンス目標はすべて達成されています。」という推奨事項が表示されます。

2. Oracle Database QoS Managementで、パフォーマンス・クラスがパフォーマンス目標を満たしておらず、パフォーマンスを改善するための推奨アクションがあると判断された場合は、ダッシュボードの「パフォーマンス概要」グラフのパフォーマンス・クラス名の前にアスタリスク('*')が付けられ、推奨アクションが表示されます。

3. 図4-3に示すように、複数のパフォーマンス・クラスがパフォーマンス目標を満たしていない場合、ターゲットのパフォーマンス・クラスにのみアスタリスクと推奨が表示されます。その推奨事項に関連付けられたアクションがある場合、「実装」ボタンが表示され、それをクリックすると、そのアクションを実装できます。
推奨されるアクションがない場合は、「詳細」ボタンをクリックして最新の分析結果を表示できます。Oracle Database QoS Managementには、実行できるアクションと、それらのアクションが選択されなかった理由が表示されます。

例4-1 「パフォーマンス概要」ページの出力例および推奨されるアクション

図4-4 パフォーマンス目標を満たしていないパフォーマンス・クラスを示す「パフォーマンス概要」ページ

推奨の詳細の表示

Oracle Database QoS Managementが推奨を生成した場合は、「推奨事項の詳細」ボタンをクリックして、推奨が行われた理由に関する詳細情報と、推奨を実装した場合に予想されるパフォーマンス向上を表示できます。

「アクション」ドロップダウン・リストを使用して、様々な推奨を選択できます。Oracle Database QoS ManagementはQoS管理者に最善の推奨を提供しようとしますが、別のアクションの方がよりよい結果になるとユーザーが判断する場合があります。別のアクションを選択すると、「推奨アクション」および「状況分析」セクションの情報が更新されて、別の推奨の影響が反映されます。別の推奨がシステム全体に十分な利益をもたらさないためOracle Database QoS Managementシステムによって拒否された場合は、その推奨を実装できません。

「推奨アクション」ページには、「状況分析」というセクションもあります。このセクションに出力を表示すると、次のスクリーンショットに示すように、推奨の実装がパフォーマンス・クラスおよびサーバー・プールに与えると予測される影響の説明を参照できます。

推奨の実装

推奨アクションがあり、アクションの実装を決定した場合は、ダッシュボードまたは「詳細」ページの「実装」ボタンをクリックします。

推奨を実装した後で、ダッシュボードの画面が変更され、進行中のアクションがあることが表示されます。リソースの変更後、システムが確定するまで新しい推奨は表示されません。推奨を実装する前に「詳細」ページを表示することにより、新しい推奨が使用可能になるまで待機する必要のある時間を判断できます。

推奨アクションを実装した後で、ダッシュボードの「パフォーマンス概要」チャートを表示して、パフォーマンス・クラスがパフォーマンス目標を満たすようになったかどうかを判断します。

関連項目:

パフォーマンス・ポリシーに対する推奨の自動実装

ポリシー・セットの管理

Oracle Database QoS Managementシステムを初めて構成するか、新しいポリシー・セットを作成するかにかかわらず、ポリシー・セットの作成にはポリシー・セットの作成ウィザードを使用します。既存のポリシー・セットを変更するにはポリシー・セットの編集ウィザードを使用します。

注意:

新しいポリシー・セットを作成することに決めた場合は、既存のパフォーマンス・ポリシーとユーザーが追加したパフォーマンス・クラスをすべて再作成する必要があります。格納されているポリシー・セットに対して行った変更は、ポリシー・セット・ウィザードの最後のページで「ポリシー・セットの発行」をクリックするまで保存されません。

- ポリシー・セットの編集

- ポリシー・セットへのサーバー・プールの追加

- サーバー・プール設定の変更

- ポリシー・セットへのデータベース・サービスの追加

- ポリシー・セットを更新して新規データベースを追加

ポリシー・セットの編集

既存のポリシー・セットを変更するには、次の手順を実行します。

1. クラスタ・ターゲット・メニューから、「管理」、「サービスのクオリティ管理」、「ポリシー・セットの編集」の順に選択します。

ポリシー・セット・エディタ・ウィザードが開始します。

2. ポリシー・セット・エディタ・ウィザードの最初のページで、現在のサーバー・プール設定を確認できます。

このページで、Oracle Database QoS Managementで管理するサーバー・プールを指定します。サーバー・プールの「管理」ボックスが選択解除されている場合、そのサーバー・プールを使用するサーバー、データベースまたはワークロードはOracle Database QoS Managementによって表示または管理されません。「詳細」列には、構成違反の詳細と、サーバー・プールの管理を有効にするために実行する修正処理が表示されます。

終了したら、「次へ」をクリックします。「ポリシー・セット・エディタ: パフォーマンス・クラス」ページが表示されます。

3. 2番目のページでは、システムのパフォーマンス・クラスを作成、編集、名前変更または削除できます。新しいパフォーマンス・クラスを作成するか、「パフォーマンス・クラスの編集」ボタンを使用して既存のパフォーマンス・クラスの分類子を変更できます。

「すべてを開く」リンクを使用して各パフォーマンス・クラスの分類子を表示するか、個々のパフォーマンス・クラス・エントリを展開してそのパフォーマンス・クラスの分類子のみ表示できます。

編集するパフォーマンス・クラスを選択し、適切なアクション・ボタン(「編集」、「名前変更」または「削除」)をクリックします。このポリシー・セットのパフォーマンス・クラスを作成する場合は、「パフォーマンス・クラスの追加」ボタンをクリックします。パフォーマンス・クラスの作成の詳細は、「パフォーマンス・クラスの作成」を参照してください。

終了したら、「次へ」をクリックします。

4. パフォーマンス・クラスを作成または変更した後、次の手順は分類子の評価順序の設定です。

分類子は作業リクエストが配置されるパフォーマンス・クラスを決定するため、この手順は非常に重要です。パフォーマンス・クラスを選択し、分類子の右にある矢印キーを使用してリスト内のエントリを上下に移動します。

作業リクエストがシステムに入ると、作業リクエストが分類子に照らして評価されます。最初にTRUEに評価された式によって、作業リクエストが属するパフォーマンス・クラスが決まります。よりきめ細かな分類子をリストの上部に配置し、より汎用的な分類子をリストの下部に配置する必要があります。

5. パフォーマンス・クラスの順序を設定した後、次の手順はパフォーマンス・ポリシーの編集とパフォーマンス目標の設定です。

このページでは、次の処理を実行できます。

- 新しいパフォーマンス・ポリシーの作成

- 既存のパフォーマンス・ポリシーの編集、コピーまたは削除

- QoS Managementで自動的に実装できるリソース割当て方法を指定します。

注意:

DefaultPolicyパフォーマンス・ポリシーは変更できませんが、このポリシーをコピーし、新しいパフォーマンス・ポリシーの基礎として使用できます。

このページでのタスクの実行方法の詳細は、「パフォーマンス・ポリシーの管理」を参照してください。

6. パフォーマンス・ポリシーを構成した後で、ポリシー・セットの発行直後に有効にするパフォーマンス・ポリシーを選択する必要があります。

優先するパフォーマンス・ポリシーを選択し、「ポリシーの設定」をクリックします。終了したら、「次へ」をクリックします。

7. ポリシー・セットをOracle Database QoS Managementシステムに発行する前に、ポリシー・セット構成の確認を求められます。変更が意図したとおりの場合は、「ポリシー・セットの発行」をクリックします。表示されている設定のいずれかを変更する必要がある場合は、「戻る」または「取消」ボタンをクリックします。

「ポリシー・セットの発行」をクリックすると、ダッシュボードに戻ります。

ポリシー・セットへのサーバー・プールの追加

サーバー・プールは、クラスタまたはデータベース管理者がOracle Enterprise Manager Cloud ControlまたはServer Control (SRVCTL)を使用して作成します。サーバー・プールの作成方法は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

クラスタ管理者がサーバー・プールを作成した後で、Oracle Database QoS Managementシステムにサーバー・プールを追加できます。「パフォーマンス・ポリシーの作成とパフォーマンス目標の指定」を参照してください。

関連項目:

- サーバー・プールのサイズの変更の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

- 最近割り当てられたサーバーを既存のOracle RACデータベースの一部にするための構成の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

サーバー・プール設定の変更

サーバー・プール設定を変更するには、ポリシー・セットに対してサーバー・プールのディレクティブ・オーバーライドを構成します。

サーバー・プールのディレクティブ・オーバーライドを構成した場合は、サーバー・プールの作成時に指定したパラメータのかわりに、サーバー・プールに対して指定する新しいパラメータが使用されます。

注意:

リストされているサーバー・プールの最小および最大設定は変更できますが、このインタフェースを使用して追加のサーバー・プールを作成することはできません。ここで行った変更は、発行された後、関連付けられたパフォーマンス・ポリシーがアクティブなときに、Oracle Enterprise Manager Cloud Controlの「サーバー・プールの管理」セクションに設定されている現在のサーバー・プール・プロパティを変更します。

- Oracle Enterprise Manager Cloud ControlまたはSRVCTLの「サーバー・プールの管理」ページを使用して、サーバー・プール・パラメータを手動で変更できます。
Oracle Database QoS Managementを有効にした場合は、この方法を使用してサーバー・プール構成を変更しないでください。サーバー・プールのディレクティブ・オーバーライドとサーバー・プール構成の手動変更の両方を使用すると、現在のポリシー・セットに対して指定したサーバー・プールのディレクティブ・オーバーライドによって手動設定がオーバーライドされるため、混乱が生じることがあります。

関連項目:

「サーバー・プールのディレクティブ・オーバーライドの設定」

ポリシー・セットへのデータベース・サービスの追加

追加サービスを作成して、新規サービスの使用を特定のアプリケーションまたはユーザーに制限することで、より詳細なレベルでワークロード・パフォーマンスを監視できます。データベース・サービスをポリシー・セットに追加するには、新規データベース・サービスごとにパフォーマンス・クラスを作成または変更する必要があります。

1. データベース管理者は、SRVCTLまたはOracle Enterprise Manager Cloud Controlを使用して、Oracle Clusterwareで管理するデータベース・サービスを作成します。Enterprise Manager Cloud Controlの「データベース・ターゲット」ページの「可用性」メニューを使用して、Oracle RACデータベースのサービスを作成できます。

関連項目:

Enterprise Manager Cloud Controlを使用したサービスの作成の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください

2. QoS管理者は、ポリシー・セットに1つ以上のパフォーマンス・クラスを追加するか、新しいデータベース・サービスを含むように既存のパフォーマンス・クラスを変更します。

注意:

Oracle Database QoS Managementにはデータベース・サービスがdb_name:service_nameとして表示されるため、サービス名はデータベース内で一意である必要があります。

ポリシー・セットを更新して新規データベースを追加

新しいデータベースをクラスタに追加すると、このデータベースのワークロードを管理または監視するよう、Oracle Database QoS Managementを構成できます。

1. データベース管理者は、最初にクラスタ・データベースをサーバーにホストするようクラスタまたはシステム管理者にリクエストします。

2. クラスタまたはデータベース管理者は、指定された最小ノード数で新しいサーバー・プールを作成します。クラスタまたはデータベース管理者は、新しいサーバー・プールを作成するかわりに、既存のサーバー・プールへのアクセス権を付与することもできます。

3. データベース管理者は、割り当てられたサーバー・プールに新しいデータベースを作成します。データベース管理者は、Oracle Database QoS Managementで管理するように新しいデータベースが適切に構成されていることを確認します。詳細は、「サポートされるデータベース構成」を参照してください。

4. データベース管理者は、SRVCTLまたはOracle Enterprise Manager Cloud Controlを使用して、Oracle Clusterwareが新しいデータベースについて管理するデータベース・サービスを作成します。

5. データベース管理者は、Cloud Controlの「データベース・ターゲット」ページからデータベースでOracle Database QoS Managementを有効にします。

6. Cloud Controlの「ポリシー・セットの編集」リンクを使用して、QoS管理者は、「ポリシー・セット」に新しいサーバー・プールを追加、「ポリシー・セット」に1つ以上のパフォーマンス・クラスを追加、または新しいデータベース・サービスを含むように既存のパフォーマンス・クラスを変更します。ポリシー・セットの編集の詳細は、「ポリシー・セットの編集」を参照してください。

7. 新しいポリシー・セットの発行を完了すると、Oracle Database QoS Managementによって新しいデータベースが監視および管理されます。

パフォーマンス・クラスの管理

各ポリシー・セットには、1つ以上のパフォーマンス・クラスが含まれます。各パフォーマンス・クラスは、使用するサーバー上のワークロードの型を定義します。

- パフォーマンス・クラスの作成

- パフォーマンス・クラスの削除

- パフォーマンス・クラス名の変更

- 既存のパフォーマンス・クラスの編集

- 分類子の評価順序の指定

パフォーマンス・クラスの作成

パフォーマンス・クラスとそれらで使用される分類子を作成または編集するには、次のタスクを実行します。

1. ポリシー・セット・エディタ・ウィザードを開始します。Oracle Enterprise Manager Cloud Controlの「クラスタ・ターゲット」ページから、「管理」、「サービスのクオリティ管理」、「ポリシー・セットの編集」の順に選択します。

2. ウィザードの第2画面に移動します。

「ポリシー・セットの編集: パフォーマンス・クラス」ページに、使用可能なパフォーマンス・クラスが表示されます。今回初めてシステムを構成する場合は、各データベース・サービスのパフォーマンス・クラスがデフォルトのパフォーマンス・クラスとともに表示されます。

作業リクエストの分類子を指定するには、少なくとも1つのサービス名を指定する必要があります。複数のサービスを指定する場合は、カンマ区切りリストを使用します。オプションで、次のいずれかのフィルタを指定することもできます。

- モジュール名のカンマ区切りリストと、作業リクエストがこのリストのモジュールを使用するかどうか

- アクションのカンマ区切りリストと、作業リクエストがこのリストのアクションを実行するかどうか

- ユーザー名のカンマ区切りリストと、作業リクエストがこのリストのユーザー名を使用するかどうか

- プログラムのカンマ区切りリストと、作業リクエストがこのリストのプログラムを実行するかどうか

3. 「パフォーマンス・クラスの追加」をクリックすると、パフォーマンス・クラスの作成ページが表示されます。「パフォーマンス・クラス名」テキスト・フィールドに、パフォーマンス・クラスの名前を入力します。

4. 「分類子」セクションで、作業リクエストの分類ルールを定義する情報を入力します。最初にデータベース・サービスを選択してから、指定されたデータベース・サービスを使用して作業リクエストに関連付けられているモジュール、アクション、UserNameまたはプログラム名に対して一致する値(「セット内にある」)を指定します。これらの属性に対して除外値(「セット内にない」)を指定することもできます。

パフォーマンス・クラスに複数の分類子を追加する場合は、「分類子の追加」ボタンをクリックし、適切な情報を入力します。

注意:

パフォーマンス・クラスの分類子を評価する場合は、指定したすべての値がAND演算を使用して作業リクエスト属性と比較されます。パフォーマンス・クラスに複数の分類子を指定した場合は、そのパフォーマンス・クラスの各分類子評価の結果がOR演算を使用して結合されます。

5. パフォーマンス・クラスのすべての分類子を定義したら、ウィザードの終わりに達するまで「次へ」ボタンをクリックします。指定した情報を確認し、「ポリシー・セットの発行」をクリックします。

パフォーマンス・クラスの削除

不要になったパフォーマンス・クラスを削除できます。

1. ポリシー・セットの編集ウィザードを開始します。

2. ウィザードの第2画面に移動します。
「ポリシー・セットの編集: パフォーマンス・クラス」ページに、使用可能なパフォーマンス・クラスが表示されます。

3. パフォーマンス・クラスを選択し、「パフォーマンス・クラスの削除」をクリックします。

4. ポリシー・セットの編集ウィザードの最後まで進み、「ポリシー・セットの発行」をクリックして変更を永続化します。

パフォーマンス・クラス名の変更

ポリシー・セットの編集ウィザードを使用して、パフォーマンス・クラスの名前を変更することができます。

1. ポリシー・セットの編集ウィザードを開始します。

2. ウィザードの第2画面に移動します。
「ポリシー・セットの編集: パフォーマンス・クラス」ページに、使用可能なパフォーマンス・クラスが表示されます。

3. パフォーマンス・クラスを選択し、「パフォーマンス・クラス名の変更」をクリックします。

4. 「パフォーマンス・クラス名の変更」ページで、パフォーマンス・クラスの新しい名前を入力し、「OK」をクリックします。

5. ポリシー・セットの編集ウィザードの最後まで進み、「ポリシー・セットの発行」をクリックして変更を永続化します。

既存のパフォーマンス・クラスの編集

パフォーマンス・クラスを編集する際に、システムのパフォーマンス・クラスを作成、編集、名前変更または削除できます。「パフォーマンス・クラスの編集」ボタンを使用して、既存のパフォーマンス・クラスの分類子を変更できます。

1. ポリシー・セット・エディタ・ウィザードを開始します。

a. Oracle Enterprise Manager Cloud Control内の「クラスタ・ターゲット」ページから、「管理」を選択します。

b. 「サービスのクオリティ管理」を選択します。

c. 「ポリシー・セットの編集」を選択します。

2. ウィザードの第2画面に移動します。
「ポリシー・セットの編集: パフォーマンス・クラス」ページに、使用可能なパフォーマンス・クラスが表示されます。

3. 変更するパフォーマンス・クラスを選択し、「パフォーマンス・クラスの編集」をクリックします。

4. 変更が終了したら、「OK」をクリックします。

5. 「ポリシー・セット・エディタ」の最後のページまで進み、「ポリシー・セットの発行」をクリックします。

分類子の追加

パフォーマンス・クラスに分類子を追加するには、次の手順を実行します。

1. ポリシー・セット・エディタ・ウィザードを開始します。

2. ウィザードの第2画面である「ポリシー・セットの編集: パフォーマンス・クラス」ページに移動します。

3. 変更するパフォーマンス・クラスを選択し、「パフォーマンス・クラスの編集」をクリックします。

4. 「パフォーマンス・クラスの編集」ページの「分類子」セクションで、「分類子の追加」ボタンをクリックし、適切な情報を入力します。終了したら、「OK」をクリックします。

5. ポリシー・セットの編集ウィザードの最後まで進み、「ポリシー・セットの発行」をクリックして変更を永続化します。

分類子の変更

パフォーマンス・クラスの1つ以上の分類子を変更するには、次の手順を実行します。

1. ポリシー・セット・エディタ・ウィザードを開始します。

2. ウィザードの第2画面である「ポリシー・セットの編集: パフォーマンス・クラス」ページに移動します。

3. 分類子を変更するパフォーマンス・クラスを選択し、「パフォーマンス・クラスの編集」をクリックします。

4. 「パフォーマンス・クラスの編集」ページの「分類子」セクションで、分類子情報を変更し、「OK」をクリックします。

5. ポリシー・セットの編集ウィザードの最後まで進み、「ポリシー・セットの発行」をクリックして変更を永続化します。

分類子の削除

パフォーマンス・クラスの1つ以上の分類子を削除するには、次の手順を実行します。

1. ポリシー・セット・エディタ・ウィザードを開始します。

2. ウィザードの第2画面である「ポリシー・セットの編集: パフォーマンス・クラス」ページに移動します。

3. 分類子を削除するパフォーマンス・クラスを選択し、「パフォーマンス・クラスの編集」をクリックします。

4. 「パフォーマンス・クラスの編集」ページの「分類子」セクションで、削除する分類子を選択し、「分類子の削除」をクリックします。終了したら、「OK」をクリックします。

5. ポリシー・セットの編集ウィザードの最後まで進み、「ポリシー・セットの発行」をクリックして変更を永続化します。

分類子の評価順序の指定

分類子は、作業リクエストがシステムに入るたびに評価されるブール式を生成します。最初にTRUEに評価された分類子によって、作業リクエストのパフォーマンス・クラスが決まります。作業リクエストが適切なパフォーマンス・クラスに入るようにするには、分類子が評価される順序を慎重に指定する必要があります。

分類子の評価順序を設定するには、次の手順を実行します。

1. ポリシー・セット・エディタ・ウィザードを開始します。

2. 「ポリシー・セットの編集: 分類子の順序付け」というタイトルのウィザードの第3画面まで進みます。

3. 分類子の右側にある矢印キーを使用して、リスト内の分類子を上下に移動します。リストの一番上にあるパフォーマンス・クラスの分類子が最初に評価されます。作業リクエストがそのパフォーマンス・クラスの分類子と一致しない場合は、評価対象がなくなるまで、リスト内の次のパフォーマンス・クラスの評価に進みます。作業リクエストがパフォーマンス・クラスの分類子と一致した場合は、作業リクエストがそのパフォーマンス・クラスに関連付けられ、評価が終了します。

作業リクエストを適切に分類するには、最も厳密な分類子を持つパフォーマンス・クラスをリストの一番上に配置し、最も厳密でない分類子を持つパフォーマンス・クラスをリストの下の方に配置する必要があります。最も汎用的な分類子を持つDefault_pcパフォーマンス・クラスは、リストの一番下に配置する必要があります。

4. ポリシー・セットの編集ウィザードの最後まで進み、「ポリシー・セットの発行」をクリックして変更を永続化します。

パフォーマンス・ポリシーの管理

- パフォーマンス・ポリシーの作成とパフォーマンス目標の指定

- 既存のパフォーマンス・ポリシーの編集

- パフォーマンス・ポリシーのコピー

- 現在のパフォーマンス・ポリシーの設定

- パフォーマンス・ポリシーの削除

- パフォーマンス・ポリシーに対する推奨の自動実装

- サーバー・プールのディレクティブ・オーバーライドの設定

パフォーマンス・ポリシーの作成とパフォーマンス目標の指定

パフォーマンス・ポリシーの作成には、Oracle Enterprise Manager Cloud Controlを使用します。

パフォーマンス・ポリシーを作成および構成するには、次の手順を実行します。

1. ポリシー・セット・エディタ・ウィザードを開始します。

2. 「ポリシー・セットの編集: パフォーマンス・ポリシー」というタイトルのウィザードの第4画面まで進みます。

3. 「ポリシーの追加」ボタンをクリックしてパフォーマンス・ポリシーを作成します。「ポリシーの追加」ページが表示されます。

各パフォーマンス・ポリシーについて、一意の名前を指定する必要があります。ポリシーの説明とその意図も入力できます。次に、ポリシーのパフォーマンス・クラスを構成する必要があります。

パフォーマンス・クラスを構成するには、次の手順を実行する必要があります。

- 各パフォーマンス・クラスのランクを最高から最低まで設定します。より高いランクのパフォーマンス・クラスは、リソースの競合が発生した場合の優先順位が高くなります。

- パフォーマンス目標の値を指定します。
パフォーマンス目標値は、作業リクエスト(データベース・リクエスト)がその時間内に完了する必要のある秒数です。たとえば、0.008秒(8ミリ秒)などを指定します。

注意:

サービス・レベル合意(SLA)または目標レスポンス時間をパフォーマンス目標値として使用しないでください。かわりに、合理的で維持可能な、目標レスポンス時間よりも大きい値を選択してください。大きめの値を使用すると、パフォーマンス目標を超える前にリソースの割当てに関するOracle Database QoS Managementからの推奨を実装する時間が確保されます。

パフォーマンス・クラスを管理せずに、測定または監視のみにするかどうかも選択できます。「測定のみ」を選択した場合、Oracle Database QoS Managementはパフォーマンス・クラスを測定または監視しますが、パフォーマンスを向上させるための推奨は提供しません。

4. オプション: QoS Managementで自動的に実行できるアクションを指定します。「パフォーマンス・ポリシーに対する推奨の自動実装」を参照してください。

5. Optional: サーバー・プールのディレクティブ・オーバーライドを構成します。「サーバー・プールのディレクティブ・オーバーライドの設定」を参照してください。

6. ポリシー・セットの編集ウィザードの最後まで進みます。「ポリシー・セットの発行」をクリックして変更を永続化します。

関連項目:

「Oracle Database QoS Managementでのパフォーマンスの監視」

既存のパフォーマンス・ポリシーの編集

「ポリシーの編集」ページで、各パフォーマンス・クラスのランク、またはパフォーマンス・クラスの「測定のみ」設定を変更できます。QoS Managementで自動的に実装できるリソース割当てアクションのタイプを選択し、サーバー・プールのディレクティブ・オーバーライドを設定することもできます。

1. 「ポリシー・セットの編集」の「パフォーマンス・ポリシー」ページで、変更する「パフォーマンス・ポリシー」を選択し、「編集」をクリックします。

2. パフォーマンス・クラスの新しいランクまたは目標値を指定するか、パフォーマンス・クラスの「測定のみ」設定を有効または無効にします。

3. 変更が終了したら、「OK」をクリックしてポリシー・セット・エディタ・ウィザードに戻ります。

4. ウィザードの最後に達するまで「次」をクリックします。変更を確認し、「ポリシー・セットの発行」をクリックします。

関連項目:

- 「Oracle Database QoS Managementでのパフォーマンスの監視」

- サーバー・プールのディレクティブ・オーバーライドの詳細は、「サーバー・プールのディレクティブ・オーバーライドの設定」を参照してください

パフォーマンス・ポリシーのコピー

新しいパフォーマンス・ポリシーを作成するかわりに、既存のパフォーマンス・ポリシーをコピーできます。コピーしたパフォーマンス・ポリシーは、元のパフォーマンス・ポリシーと同一です。新しいパフォーマンス・ポリシーにすべての詳細を再作成するかわりに、単純にコピーの名前を変更し、編集できます。

現在のパフォーマンス・ポリシーの設定

パフォーマンス・ポリシーは、同時に施行されるパフォーマンス目標のコレクションです。パフォーマンス目標はパフォーマンス・クラスごとに1つずつあります。Oracle Database QoS Managementのアクティブなパフォーマンス・ポリシーを変更するには、複数の方法があります。

ダッシュボードからのアクティブなパフォーマンス・ポリシーの変更

1. ダッシュボード・ページの「一般」セクションで、「アクティブ・ポリシーの変更」ボタンをクリックします。

2. 「ポリシーの設定」ページで、使用するパフォーマンス・ポリシーを選択し、「OK」をクリックします。

ポリシー・セット・エディタ・ウィザードからのアクティブなパフォーマンス・ポリシーの変更

ポリシー・セットをOracle Database QoS Managementに発行したときにアクティブになるパフォーマンス・ポリシーを変更できます。

1. ポリシー・セット・エディタ・ウィザードを開始します。

2. 「ポリシー・セットの編集: ポリシーの設定」というタイトルのウィザードの第5画面まで進みます。

3. 施行するパフォーマンス・ポリシーを選択し、「ポリシーの設定」をクリックします。

ポリシー・セット・エディタ・ウィザードの最後で、指定した設定を確認し、「ポリシー・セットの発行」をクリックしてOracle Database QoS Managementを構成できます。

QOSCTLを使用したアクティブなパフォーマンス・ポリシーの変更

Oracle Database QoS Managementの多くのポリシーは、カレンダに基づいています。QOSCTLを使用してアクティブ・ポリシーを設定することで、Enterprise Manager Cloud Control、Task SchedulerまたはCRONなどのジョブ・スケジューラを介してアクティブなパフォーマンス・ポリシーを自動的に切り替えることができます。

1. Clusterware管理者として、オペレーティング・システム・ユーザーにログインします。

2. コマンドラインで、またはスクリプト内で、-activatepolicyオプションを指定してqosctlコマンドを使用します。コマンドは次の構文を使用する必要があります。

qosctl qos_admin_username -activatepolicy policy_name

パフォーマンス・ポリシー名にスペースが含まれる場合、パフォーマンス・ポリシー名を二重引用符で囲む必要があります。例を示します。

qosctl qosadmin -activatepolicy "Business Hours"

関連項目:

QOSCTLの詳細は、「QOSCTLユーティリティのリファレンス」を参照してください。

パフォーマンス・ポリシーの削除

パフォーマンス・ポリシーを削除するには、次の手順を実行します。

1. ポリシー・セット・エディタ・ウィザードを開始します。

2. 「ポリシー・セットの編集: パフォーマンス・ポリシー」というタイトルのウィザードの第4画面まで進みます。

3. 「ポリシーの削除」ボタンをクリックしてパフォーマンス・ポリシーを削除します。

4. ポリシー・セットの編集ウィザードの最後まで進み、「ポリシー・セットの発行」をクリックして変更を永続化します。

パフォーマンス・ポリシーに対する推奨の自動実装

該当するチェック・ボックスを使用して、次のうちOracle Database QoS Managementで自動的に実装可能なアクションを指定できます。

- パフォーマンス・クラスのコンシューマ・グループの昇格または降格

- サーバー・プール内のデータベース間でのCPUの移動

- サーバー・プール間でのサーバーの移動

これらのいずれのアクションも認可されていない場合、ユーザーがパフォーマンス・クラスの最新の推奨をレビューして「実装」ボタンをクリックするまで、Oracle Database QoS Managementはアクティブ・システムに変更内容を実装しません。

サーバー・プールのディレクティブ・オーバーライドの設定

サーバー・プールのディレクティブ・オーバーライドでは、サーバー・プールを別のサイズに設定したり、サーバー・プールの重要度を変更したりできます。たとえば、広告したセール期間中など、要求のサージが予想される場合に、サーバー・プールのディレクティブ・オーバーライドを使用して、会計アプリケーションにより多くのリソースを割り当てることができます。

サーバー・プールのディレクティブ・オーバーライドは、必要なときにのみ使用する必要があります。サーバー・プールのディレクティブ・オーバーライドを使用するかわりに、システムを一定期間監視し、必要に応じてサーバー・プール設定を変更する必要があります。サーバー・プールのディレクティブ・オーバーライドを使用すると、リソース割当てが予期せず変更されることがあります。たとえば、webapps、HRおよびpayrollという名前のサーバー・プールがあるとします。サーバー・プールのディレクティブ・オーバーライドを作成して、payrollサーバー・プールの最小サーバー・プール・サイズを増やします。サーバー・プールのディレクティブ・オーバーライドがアクティブになると、payrollサーバー・プールの高い最小サーバー要件を満たすために、サーバーがHRまたはwebappsサーバー・プールから除去されることがあります。

関連項目:

サーバー・プール設定の構成の詳細は、「サーバー・プール設定の変更」を参照してください

1. ポリシー・セット・エディタ・ウィザードを開始します。

2. 「ポリシー・セットの編集: パフォーマンス・ポリシー」というタイトルのウィザードの第4画面まで進みます。

3. 「ポリシーの編集」ボタンをクリックしてパフォーマンス・ポリシーを編集します。
「ポリシーの編集」ページが表示されます。

4. 必要に応じて、「サーバー・プールのディレクティブ・オーバーライド」セクションを展開します。

5. サーバー・プールのディレクティブ・オーバーライドを設定するには、次の手順を実行します。

- サーバー・プール内の最小サーバー数の現在の値をオーバーライドするには、そのサーバー・プールの「最小: オーバーライド」フィールドに新しい値を入力します。有効値は、0からそのサーバー・プール内の最小サーバー数までです。

- サーバー・プール内の最大サーバー数の現在の値をオーバーライドするには、そのサーバー・プールの「最大: オーバーライド」フィールドに新しい値を入力します。有効値は、そのサーバー・プール内の最小サーバー数からクラスタのサイズまでです。

- サーバー・プールの重要度の現在の値をオーバーライドするには、そのサーバー・プールの「重要度: オーバーライド」フィールドに新しい値を入力します。有効な値は0から1000で、値が大きいほど重要度が高いことを示します。

6. サーバー・プールのディレクティブ・オーバーライドの値の入力が完了したら、「OK」をクリックして変更を実装します。

7. ポリシー・セットの編集ウィザードの最後まで進み、「ポリシー・セットの発行」をクリックして変更を永続化します。

パフォーマンス・メトリックの確認

Oracle Database QoS Managementシステム全体または個々のパフォーマンス・クラスの各種パフォーマンス・メトリックを表示できます。

- すべてのパフォーマンス・クラスのパフォーマンス・メトリックの表示

- 個々のパフォーマンス・クラスのパフォーマンス・メトリックの表示

- 「サービスのクオリティ管理」イベントのアラートの構成

- リソース待機時間のブレークダウンの表示

すべてのパフォーマンス・クラスのパフォーマンス・メトリックの表示

システムのパフォーマンス・メトリックは、「パフォーマンス・クラスのサービスのクオリティ」ページで表示できます。

Oracle Database QoS Managementを構成した後、Oracle Database QoS Managementがパフォーマンス・データを収集し、システムのパフォーマンスを評価するまで少し時間が必要です。この期間の経過後に、システムのパフォーマンス・メトリックを表示できます。現在のパフォーマンス・メトリックを表示するには、次の手順を実行します。

1. Oracle Enterprise Manager Cloud Controlにクラスタ管理者としてログインします。「クラスタ・ターゲット」ページに移動します。

2. クラスタ・ターゲット・メニューから、「管理」、「サービスのクオリティ管理」、「パフォーマンス・クラスのサービスのクオリティの表示」の順に選択します。

3. 「パフォーマンス・クラスのサービスのクオリティ」ページに、監視されている各パフォーマンス・クラスの現在のパフォーマンスを測定する3つのチャートが表示されます。

a. 「パフォーマンス満足度メトリック」チャート

b. 「要求」チャート

c. 「平均レスポンス時間」チャート

個々のパフォーマンス・クラスのパフォーマンス・メトリックの表示

Oracle Database QoS Managementを構成し、短時間が経過した後、特定のパフォーマンス・クラスのパフォーマンス・メトリックを表示できます。パフォーマンス・クラスの現在のパフォーマンス・メトリックを表示するには、次の手順を実行します。

1. Oracle Enterprise Manager Cloud Controlにクラスタ管理者としてログインします。

2. QoS Management用に構成されている「クラスタ・ターゲット」ページを選択します。

3. クラスタ・ターゲット・メニューから、「管理」、「サービスのクオリティ管理」、「パフォーマンス・クラスのサービスのクオリティの表示」の順に選択します。

4. グラフの右側にある凡例ボックスで、パフォーマンス・メトリックを表示するパフォーマンス・クラスに対応するリンクをクリックします。

「サービスのクオリティ管理」イベントのアラートの構成

継続して手動で「サービスのクオリティ管理」ダッシュボードを監視するのは、不便で、効率がよくありません。かわりに、Enterprise Manager Cloud Control通知システムを使用して、ユーザー指定の時間に存在するネガティブなPerformance Satisfaction Metrics (PSMs)を報告することができます。

警告レベルおよびクリティカル・レベルのどちらに対しても、アラートのしきい値および通知を設定することで、それぞれのパフォーマンス・クラスに指定された期間に基づきアラートが発行されます。アラートは、監視されているサービスを提供するデータベースに対して構成されます。

1. Enterprise Manager Cloud Controlを起動します。

2. アラートを構成するデータベースに移動します。

3. 「クラスタ・データベース」メニューから、「モニタリング」を選択し、「メトリックと収集設定」を選択します。

4. 「メトリック」タブで、カテゴリ「QoS管理 - パフォーマンス満足度メトリック」のメトリックを編集します。

たとえば、「サービスのクオリティ管理」がデータベース・サービスsales_svc_pcを使用する場合、そのサービスの「負のPSM継続時間(秒)」で、期間が120秒より長い場合は警告アラート、180秒より長い期間の場合はクリティカル・アラートを構成します。

構成されたアラートは、違反が検知された時、Enterprise Managerの「データベース・ホーム」ページに表示されます。

リソース待機時間のブレークダウンの表示

ダッシュボードの下部には、「リソース待機時間のブレークダウン」表があります。この表は、パフォーマンス・クラスごとのリソース待機時間のブレークダウンを示します。各パフォーマンス・クラスについて、ボトルネック・リソースは待機時間が最も長いリソースです。データは、推奨を生成するためにOracle Database QoS Managementで使用されます。このデータを使用して、システムを手動で調整することもできます。

Oracle Database QoS Managementの管理ユーザーの作成

Oracle Database QoS Managementには、ユーザーの管理に役立つQOSCTLという名前のコマンドライン・ユーティリティが用意されています。このユーティリティはクラスタの各ノードにインストールされますが、Oracle Database QoS Managementサーバー(OC4Jコンテナ)が実行されているのと同じノード上のOracle Clusterware管理者ユーザーとして実行した場合にのみ正常に動作します。ユーティリティを実行する適切なノードは、次のコマンドを発行することで判断できます。

srvctl status oc4j

QOSCTLユーティリティでは、Oracle Database QoS Management管理ユーザーの作成がサポートされます。アカウント情報は、暗号化された資格証明とともにローカルsystem-jazn-data.xmlファイルに格納されます。アカウント情報は、Oracle Database QoS ManagementサーバーのフェイルオーバーをサポートするためにOracle Clusterware Repository(OCR)にも格納されます。

QOSCTLユーティリティのリファレンス

QOSCTLは、Oracle Database QoS Managementの特定の構成タスクを実行するためのコマンドライン・ユーティリティです。

目的

QOSCTLユーティリティでは、Oracle Database QoS Management管理ユーザーの作成がサポートされます。

セキュリティ要件

QOSCTLユーティリティを使用するには、Oracle Clusterware管理者ユーザーとしてログインする必要があります。

OC4J管理者ユーザーのユーザー名を入力する際、パスワードを含めないでください。実行するコマンドを発行すると、指定したqos_admin_userに関連付けられているパスワードの入力を求められます。

QOSCTLユーティリティのヘルプの表示

qosctlユーティリティのヘルプを表示するには、次のコマンドを使用します。

qosctl -help

構文

次のコード例は、QOSCTLコマンドの一般形式を示しています。

qosctl qos_admin_user command

qos_admin_user引数には、OC4J管理者ユーザーのユーザー名を指定します。コマンド・ラインでパスワードを指定しないでください。

Oracle Database QoS Managementシステムの初期アカウントを構成する場合、コマンドは、オペレーティング・システム認証を使用します。

コマンド

表4-1 QOSCTLユーティリティのコマンドのサマリー

コマンド構文

説明

-activatepolicy policy_name

現在のポリシーを設定します。このコマンドを使用すると、CRONまたはスケジュール・ジョブでポリシーを変更できます。

スペースを含むポリシー名は、二重引用符でカプセル化する必要があります。

-adduser username

パスワードの指定したユーザーおよびプロンプトを追加します。このユーザーには、Oracle Database QoS Managementアプリケーションの使用およびこれらのコマンドの実行に必要なロールが自動的に付与されます。

-listusers

Oracle Database QoS Managementアプリケーションの実行を認可されているユーザーをリストします。

-remuser username

指定したユーザー・アカウントとすべての関連権限を削除します。

注意: このコマンドはリカバリできません。自身のアカウントが削除される可能性があるため、注意して使用してください。

-setpasswd username

指定したユーザーのパスワードを更新します。QOSCTLユーティリティによって、ユーザーの現在のパスワードを求められます。ユーザーのパスワードを変更するには、古いパスワードの正しい値を指定する必要があります。

ユーザーのパスワードを忘れたか紛失した場合は、ユーザー・アカウントを削除し、新しいパスワードでそのユーザーの新しいアカウントを作成する必要があります。

-help

QOSCTLコマンドの構文を表示します。

Oracle Database QoS Managementのリソース・プランの編集

Oracle Database Quality of Service Managementで使用されるリソース・マネージャ・プランを制限付きで編集できます。

Oracle Database QoS Managementは、複雑なマルチレベルのリソース・プランであるAPPQOS_PLANというリソース・プランをアクティブ化します。Oracle Database QoS Managementは、パフォーマンス・クラスであるコンシューマ・グループおよび各コンシューマ・グループのリソース・プラン・ディレクティブも作成します。

APPQOS_PLANの一部のセクションを変更できますが、次の表に指定されているとおりにしか変更できません。

プラン・コンポーネント

変更の可/不可

説明

一般

編集不可

このセクションはQoS管理モデリングおよび推奨エンジンへのキーであるため、編集できません。このセクションを変更すると、変更が検出されます。その場合、Oracle Enterprise Manager Cloud Controlにより、QoS Managementのダッシュボードにデータベース・エラーがレポートされます。

並列性

限定された編集が可能

このセクションは編集可能ですが、上述の理由により、ORA$APPQOS*コンシューマ・グループに設定されたすべての値は各列内で同じである必要があります。

しきい値

限定された編集が可能

このセクションは編集可能ですが、上述の理由により、ORA$APPQOS*コンシューマ・グループに設定されたすべての値は各列内で同じである必要があります。また、これらにグループに「*への切替え」アクションを選択することはできません。

アイドル時間

限定された編集が可能

このセクションは編集可能ですが、上述の理由により、ORA$APPQOS*コンシューマ・グループに設定されたすべての値は各列内で同じである必要があります。

関連項目:

- 「Oracle Database Resource Manager」

- Oracle Database管理者ガイド

- Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス

5 Oracle Database QoS Managementのトラブルシューティング

この章では、Oracle Database QoS Managementを使用している場合に発生する可能性のあるいくつかの問題と、それらの解決方法について説明します。Oracle Database QoS Managementのトレースまたはログ・ファイルの特定方法についても説明します。

- 一般的な問題

- ログまたはトレース・ファイルの特定

- トレースの有効化

一般的な問題

初期構成後に、Oracle Database Quality of Service Managementは自動化されたシステムになります。そのため、発生する可能性のある問題の大部分は、Oracle Database QoS Managementの構成に関連しています。次の各項では、最も一般的な問題とそれらの解決方法について説明します。

- Oracle Database Quality of Service Managementを有効にできない

- データベースに対してOracle Database QoS Managementを有効にできない

- Oracle Database Resource Managerが有効にならず、リソース・プランがエラーになる

- サーバー・プールにアクセスできない

- サーバー・プールが管理不能としてマークされる

- パフォーマンス・クラスのメトリックがない

- Oracle Database QoS Managementが推奨を生成しない

- 最近追加したサーバーが不適切なサーバー・プールに配置されている

- RMIポートの競合が検出される

Oracle Database Quality of Service Managementを有効にできない

クラスタ内でOracle Database QoS Managementを有効にする前に、まずポリシー・セットを作成する必要があります。ポリシー・セットを作成するには、「初期ポリシー・セットの作成」を参照してください。

データベースに対してOracle Database QoS Managementを有効にできない

データベースをOracle Database QoS Managementで管理するには、データベースがコンプライアンスで有効化され、Oracle Database QoS ManagementがAPPQOSSYSデータベース・ユーザーにアクセスできる必要があります。

- コンプライアンス・データベースとは、Oracle Databaseリリース11.2.0.2以降が実行されているOracle RACデータベースです。

- データベースを有効にするには、Oracle Database QoS Managementがデータベースに接続できる必要があります。接続は、Oracle Enterprise Manager Cloud Controlで「サービスのクオリティ管理の有効化」リンクを選択した場合に構成されます。このリンクを選択すると、データベース内のAPPQOSSYSアカウントのクラスタ資格証明とパスワードの入力を求められます。デフォルトでは、APPQOSSYSアカウントは期限が切れています。パスワードを発行すると、アカウントのロックが解除されます。

- APPQOSSYSユーザーのパスワードが他の方法で変更されるかアカウントがロックされた場合は、もう一度「サービスのクオリティ管理の有効化」リンクを選択してこの状況を修正するまで、Oracle Database QoS Managementはこのデータベースに対して無効になります。

関連項目:

Oracle Database QoS Managementを有効化する方法の詳細は、「クラスタに対するOracle Database QoS Managementの有効化」を参照してください。

Oracle Database Resource Managerが有効にならず、リソース・プランがエラーになる

Oracle Database QoS Managementは、データベースでOracle Database QoS Managementによる管理が有効になるたびに、特殊なOracle Database Resource Managerプラン(APPQOS_PLAN)をインストールします。Oracle Database QoS Managementは、パフォーマンス・クラスを様々なレベルのCPUスケジューリングに移動するためにこのリソース・プランを必要とします。このデータベースでOracle Database QoS Managementが有効になっている間は、他のプランをアクティブにできません。リソース・プランがOracle RACデータベースに対して有効になっていない場合は、データベースでOracle Database QoS Managementによる管理を有効にしようとしたときにエラーが発生します。リソース・プランが有効になった後、データベースでOracle Database QoS Managementによる管理の有効化が成功します。

ターゲット・データベースで必須のAPPQOS_PLANがアクティブであることを確認するには、SQL*Plusを使用して接続し、次の文を発行します。

SQL> show parameter resource_manager_plan

次のような出力が表示されます。

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
resource_manager_plan                string      APPQOS_PLAN

サーバー・プールにアクセスできない

サーバー・プールは、特殊なオペレーティング・システム・グループを構成することでデータベースとは別に管理できます。デフォルトでは、クラスタ用Oracle Grid Infrastructureをインストールしたユーザーは、サーバー・プールに対して操作を実行できます。インストールされているOracle Databaseに別のオペレーティング・システムを使用する場合は、そのサーバー・プールにデータベースをデプロイする前に、サーバー・プールに対する実行権限をデータベース・ソフトウェアの所有者に付与する必要があります。この権限を付与するには、CRSCTLユーティリティを使用してサーバー・プールACL属性を変更する必要があります。データベース管理者は、Server Control(SRVCTL)またはOracle Enterprise Managerを使用してサーバー・プールを作成することもできます。

関連項目:

crsctlコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

サーバー・プールが管理不能としてマークされる

Oracle Database QoS Managementがサーバー・プールにデプロイされているパフォーマンス・クラスのパフォーマンスを正しく測定または予測できない場合、そのサーバー・プールは管理不能としてマークされます。サーバー・プールは、次の条件で管理不能とみなされることがあります。

1. サーバー・プール内のサーバーの物理的なCPU数が異なる。

2. 各データベース・インスタンスのCPU数を取得できない。

3. サーバー上のすべてのデータベース・インスタンスに対して構成されているCPU数の合計が、その物理的なCPU数より多い。

4. 最大サイズが1より大きいサーバー・プールにシングルトン・サービスがデプロイされている。

5. Oracle Database QoS Managementがすべてのパフォーマンス・クラスのメトリックを収集できないか、収集されたメトリックに有効なデータが含まれていない。

6. サーバー・プールに、Oracle Database QoS Managementが有効になっていないデータベースがある。

サーバーがサーバー・プールに追加されると、サーバー・プール内の新規サーバー上でポリシー管理型データベースのインスタンスとサービスが起動されます。新規サーバーでインスタンスが起動されると、既存のインスタンスのSPFILEでCPU_COUNT設定が確認され、この値が新規インスタンスに使用されます。デフォルトでは、SPFILEにCPU_COUNTの設定がない場合、新規サーバー上のインスタンスはCPU_COUNTがサーバーの物理CPU数に設定されて起動されます。これはサポートされている構成ではないため、サーバー・プールは管理不能としてマークされます。また、CPU_COUNTパラメータを変更したにもかかわらず、SPFILEに変更内容を保存しなかった場合、新たに起動されたインスタンスでCPU_COUNTパラメータは間違った値に設定され、構成違反となります。

Oracle Database QoS Managementで管理するデータベースおよびデータベース・インスタンスが、「サポートされるデータベース構成」に記載されている要件に準拠していることを確認してください。

パフォーマンス・クラスのメトリックがない

メトリックは、クラスタ内の管理対象データベース・インスタンスを問い合せることでOracle Database QoS Managementによって取得されます。次の条件下では、メトリックは表示されません。

1. データベース・リクエスト(実行される作業)が、特定のパフォーマンス・クラスに対して定義されている分類子と一致せず、「リクエストなし」と表示される。

2. パフォーマンス・クラスのより一般的な分類子が最初に評価されている。その結果、より具体的な分類子を持つパフォーマンス・クラスが「リクエストなし」と表示されます。たとえば、sales_pcパフォーマンス・クラスが分類子service=Salesを使用し、sales_searchパフォーマンス・クラスが分類子(service=Sales and action=Search)を使用する場合、sales_pcパフォーマンス・クラスがポリシー・セットのパフォーマンス・クラスの順序の編集画面で最初にリストされていると、Searchアクションを実行している作業リクエストを含め、salesサービスを使用するすべての作業リクエストがsales_pcパフォーマンス・クラスに配置されます。sales_searchパフォーマンス・クラスはメトリックを生成せず、そのパフォーマンス・クラスに対して「リクエストなし」が表示されます。

3. データベース・インスタンスが過剰に利用され、メトリック問合せがタイムアウト制限に達し、「不完全なデータ」が表示される。

4. データベースがパフォーマンス・クラスに対して相互に一貫性のあるデータを生成せず、「未確認のデータ」が表示される。たとえば、1秒超過したデータベース・リクエストを分類しているパフォーマンス・クラスはこのレスポンスの原因になります。

5. 問合せを通じて収集されるメトリックが、Oracle Database QoS Managementによって実行される健全性検証チェックに合格せず、「未確認のデータ」が表示される。

Oracle Database QoS Managementが推奨を生成しない

Oracle Database QoS Managementダッシュボード(ダッシュボード)にログインすると、推奨が1分間に1回生成されます。推奨は、次の場合にはダッシュボードに表示されません。

1. Oracle Database QoS Managementが無効になっている。

2. 推奨を実装するアクションが進行している。

3. Oracle Database QoS Managementの有効化から最初の1分間、またはポリシー・セットの送信またはポリシー・セットのアクティブ化中。

最近追加したサーバーが不適切なサーバー・プールに配置されている

サーバーは、Oracle Clusterwareによってクラスタ内で移動されるか、管理者の指示に従って移動されます。

クラスタに新しいサーバーが加入すると、Oracle Clusterwareは、配置アルゴリズムと、サーバー・プールの「最小」、「最大」および「重要度」属性の状態に従ってサーバーをサーバー・プールに配置します。この配置プロセスの詳細な説明は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。

RMIポートの競合が検出される

クラスタ用Oracle Grid Infrastructureをインストールすると、Oracle Application Server Containers for J2EE(OC4J)リソースのデフォルト・ポートが23792に設定されます。これにより、ポートがJava Remote Method Invocation(RMI)と競合することがあります。環境のOC4J_PORT環境変数を使用可能なポートの番号に設定し、次のコマンドを使用してOC4Jリソースを再起動する必要があります。

srvctl modify oc4j -rmiport port
srvctl stop oc4j
srvctl start oc4j

ログまたはトレース・ファイルの特定

Oracle Database QoS Managementのログ・ファイルは、Oracle Grid Infrastructureのホーム・ディレクトリにあります。

- Oracle Database QoS Managementサーバーの操作ログ・ファイルは、Grid_home/oc4j/j2ee/home/log/dbwlm/auditing/log.xmlにあります。

- Oracle Database QoS Managementサーバーのトレース・ログ・ファイルは、Grid_home/oc4j/j2ee/home/log/dbwlm/logging/log.xmlにあります。

- OC4J標準出力ログ・ファイルとOracle ClusterwareのServer Manager(SRVM)コンポーネントのトレース・ファイルは、Grid_home/oc4j/j2ee/home/log/oc4j_<timestamp>.outにあります。

- OC4J標準エラー・ログ・ファイルは、Grid_home/oc4j/j2ee/home/log/oc4j_<timestamp>.errにあります。

- Oracle Database QoS ManagementのDBWLMコンポーネントの開始および終了ログ・ファイルは、Grid_home/oc4j/j2ee/home/log/dbwlm.logにあります。

トレースの有効化

トレースは、Oracle Database Quality of Service Managementでの問題のトラブルシューティングに役立ちます。

デフォルトのトレース・レベルはインストール時に設定します。Oracleサポート・サービスの指示に従ってきめ細かなトレースを有効にできます。

用語集

アクション

データベース・リクエストに関連付けられているアクションを識別するためにアプリケーションによって設定されるデータベース・セッション・パラメータ。

アフィニティ

「アフィニティ」という単語は、作業リクエストがルーティング先のインスタンス内に必要なデータを見つけられる可能性が高まることが期待される方針を説明するために使用されます。

集計

集計は、測定のコレクションを取得し、それらを結合して集計メジャーを生成するプロセスです。たとえば、特定のパフォーマンス・クラスの特定のサーバーで完了するすべての作業リクエストのカウントは、集計の1つの形式です。一定期間内に特定のサーバーによって処理される特定のパフォーマンス・クラスのすべての作業リクエストが使用するCPU時間の合計も、集計の1つの形式です。

アプリケーション

アプリケーションは、システムで実行されるソフトウェアであり、ユーザーまたはユーザー・グループに1つ以上のサービスを提供します。Oracle Talent Management、Oracle ERP、Oracle Asset Lifecycle Management、PeopleSoft Campus SolutionsおよびOracle Manufacturingは、すべてのアプリケーションの例です。

通常、アプリケーションは複数のコンポーネントから構成されます。データベース・コンポーネント、J2EEコンポーネント、クライアントPCコンポーネント、バッチ・コンポーネント、Webコンポーネント、Webサービス・コンポーネントなどがあります。

自動プロビジョニング

自動プロビジョニングは、ハードウェアの一部の再タスキングに関連するアクティビティをできるだけ自動化しようとします。たとえば、1つのオペレーティング・システムと1セットのアプリケーション・コンポーネントで実行されていたハードウェア部分を取得し、そのハードウェアを別のオペレーティング・システムと別のアプリケーション・コンポーネント・セットで再デプロイします。

平均レスポンス時間

特定の期間内における、パフォーマンス・クラスのすべての作業リクエストのレスポンス時間の平均。秒単位で指定されます。

ボトルネック

アプリケーションまたはシステム全体のパフォーマンスを制限するコンポーネントまたはリソース。

容量計画

容量計画は、予測されるピーク・ユーザー負荷を処理するために必要なハードウェアの量とタイプを判断する活動です。容量計画は、大きな資本設備予算サイクルの一部として行われることが多く、通常は将来の数か月に対する負荷を予測します。

分類子

作業リクエストをパフォーマンス・クラスにマップするために作業リクエストの属性に適用される値照合ルール。

クローズド・ワークロード

固定数のユーザーがアプリケーションと対話し、それらの各ユーザーが連続的にリクエストを発行するシステムで実行される作業の量。ユーザーからの新しいリクエストは、同じユーザーによる前のリクエストの完了後にのみトリガーされます。ユーザーは、リクエストを発行し、そのリクエストのレスポンスを待ち、一定時間考えてから新しいリクエストを送信します。前のリクエストのレスポンスから、同じユーザーによる新しいリクエストの発行までの平均時間を「思考時間」と呼びます。

クローズド・ワークロードは、セッションベースのワークロードとも呼ばれます。

クラスタウェア

接続しているコンピュータのグループ(クラスタ)を1単位として操作または制御できるようにするソフトウェア。

調整データ

調整データは、なんらかの種類の後処理手順でRAWデータから作成されます。平均の取得、外れ値の除去、フィルタ処理およびパフォーマンス見積もり手順は、すべてRAWデータから調整データを作成するために使用できる後処理の種類です。

データベース・サービス

データベース・サービスは、Oracle Clusterwareで管理されるユーザー作成サービスであり、データベース・セッションの接続ポイントとして機能します。データベース・サービスは、1つ以上のOracle RACインスタンスで提供でき、(サービスを開始および停止するために)インスタンスごとに管理されます。

要求

要求は、システムに提示される作業量の測定値であり、通常は1秒当たりの作業リクエストまたはリクエスト数で測定されます。

経過時間

経過時間測定値(実時間測定値とも呼ばれます)は、単一の連続する時間間隔の測定値です。経過時間の間隔は、特定の時刻t1で始まり、別の時刻t2で終わります。どちらの時刻も同じクロックから読み取られます。経過時間測定値は、(t2 - t1)の値です。

エンドツーエンドのレスポンス時間

エンドツーエンドのレスポンス時間という表現には、ユーザー・リクエストが受信されてから(たとえば、ブラウザで「送信」ボタンをクリックしてから)レスポンスがユーザーに完全に返信されるまでにかかった時間と行われたすべての作業が含まれます。エンドツーエンドのレスポンス時間には、アプリケーション・サーバー、Oracle Database、Oracle Automatic Storage Managementおよびデータ・センターの内部ネットワークの通過に費やされた時間が含まれます。

エントリ・ポイント

エントリ・ポイントは、作業リクエストとOracle Database QoS Managementシステム間の最初のアクセス・ポイントです。作業リクエストは、最初にエントリ・ポイントで分類およびタグ付けされます。

公平分配スケジューリング

公平分配スケジューリングは、一連のユーザーにCPUなどのリソースを公平に割り当て、各ユーザーが指定された配分の使用可能リソースを受け取るようにすることです。くじベースのスケジューリングは、公平分配スケジューリングの一種です。

空きプール

他のサーバー・プールに割り当てられていないサーバーを含むサーバー・プール。

ヘッドルーム

パフォーマンス・クラスがそのパフォーマンス目標を満たす場合、ヘッドルームは実際のレスポンス時間と必要なレスポンス時間の差、つまりパフォーマンスの余剰を表します。

レイヤー

レイヤーと層は同義語です。

レイヤー・アクティブ時間

レイヤー・アクティブ時間は、作業リクエストがレイヤーでアクティブに作業を行っていた累積時間から、下位レイヤーの待機に費やした時間を除いたものです。レイヤー・アクティブ時間には、レイヤーでの実行に費やした時間と、CPU、ローカル接続ディスク、メモリーなどのレイヤー・ローカル・リソースの待機に費やした時間が含まれます。

レイヤー・レスポンス時間

レイヤー・レスポンス時間は、作業リクエストが特定のレイヤーによって完全に処理されるまでの経過時間です。レイヤー・レスポンス時間には、作業リクエストの実行に費やした時間と、ローカルおよびリモートのリソースとサーバーの待機に費やした時間が含まれます。

レイヤー・アクセス

多くの場合、エンド・ユーザーからの単一の作業リクエスト(たとえば、ブラウザでのリンクのクリック)により、複数のリクエストがシステムの様々なレイヤーに到着します。リクエストがレイヤーによって処理される各時間をレイヤー・アクセスと呼びます。

負荷制限

負荷制限は、他の作業リクエストが正常に完了できるように一部の作業リクエストを拒否する処理を意味します。リクエストを正常に拒否するには、アプリケーションの変更が必要な場合があります。たとえば、エンド・ユーザーにカスタマイズした拒否ページを表示することが必要な場合があります。または、作業リクエストからの情報を格納して、後でリクエスト元に返信できるようにすることが必要な場合があります。

くじベースのスケジューリング

くじベースのスケジューリングは、事前に設定された配分に従い、ランダムな数値を使用して一連のユーザーにリソース(CPUなど)を配分するスケジューリング・アルゴリズムです。

メンテナンス・ウィンドウ

自動化されたメンテナンス・タスクが実行される連続的な時間間隔。メンテナンス・ウィンドウは、MAINTENANCE_WINDOW_GROUPという名前のウィンドウ・グループに属するOracle Schedulerウィンドウです。

メモリー不足

サーバー上の使用可能なメモリー量が限られていることを示す状態。

メトリック

メトリックは、測定できる項目です。

モジュール

モジュールは、一般にデータベース・リクエストを行うアプリケーションを識別するためにアプリケーションによって設定されるデータベース・セッション・パラメータです。

オープン・ワークロード

アプリケーションに対する新しい作業リクエストが管理対象システム外から送られてくるシステムで実行される作業。作業リクエストは相互に独立しており、作業リクエストの到着率は、前のリクエストのレスポンス時間、またはすでに到着して処理されているリクエスト数の影響を受けません。システムが一度に実行を求められる作業リクエストの数は、ゼロから無限の範囲です。システムのリソースまたはサーバーは様々なアクティビティを実行して作業リクエストを処理し、処理が完了すると作業リクエストがシステムを離れます。

オープン・ワークロードは、リクエストベースのワークロードとも呼ばれます。

クラスタ用Oracle Grid Infrastructure

Oracleの汎用クラスタウェア、Oracle Automatic Storage Management(Oracle ASM)、Oracle RACエージェントおよびOracle RACデータベース管理インフラストラクチャ・レイヤーから構成されるソフトウェア・スタックに割り当てられている用語。

Oracle Database Resource Manager

Oracle Database Resource Managerは、Oracle Databaseで使用可能なソフトウェア・コンポーネントです。Oracle Database Resource Managerにより、管理者は様々なリソース(CPUなど)を作業リクエストのコレクションであるコンシューマ・グループに割り当てる方法を制御するリソース・プランを作成できます。その目的は、Oracle Database QoS Managementのパフォーマンス・クラスとよく似ています。

パフォーマンス・ボトルネック

Oracle Database QoS Managementは、CPU、グローバル・キャッシュ、I/Oなどの必要なリソースをパフォーマンス・クラスが非常に長く待機していることによるパフォーマンス・ボトルネックを識別しようとします。

パフォーマンス・クラス

パフォーマンス・クラスは、関連する作業リクエストのグループです。パフォーマンス目標は、パフォーマンス・クラスに対して記述されます。特定のパフォーマンス・クラスにグループ化されているすべての作業リクエストは、同じパフォーマンス目標を持ちます。

パフォーマンス・クラス・ランク

パフォーマンス・クラス・ランクは、特定の時点で有効になっているパフォーマンス目標のセット内の各パフォーマンス・クラスのビジネスの重要性を表します。該当するすべてのパフォーマンス・クラスを同時に処理するのに十分なリソースがない場合、Oracle Database QoS Managementはランクが低いパフォーマンス・クラスを犠牲にして、ランクが最高のパフォーマンス・クラスのパフォーマンス目標を満たそうとします。たとえば、より高いランク(最高、「高」、「中」または「低」)のパフォーマンス・クラスがパフォーマンス目標を満たすために、ランクが最低のパフォーマンス・クラスが必要に応じて犠牲になります。

パフォーマンス目標

パフォーマンス目標は、システムのビジネス・レベル目標を指します。パフォーマンス目標には、パフォーマンス目標と可用性目標の両方が含まれます。

パフォーマンス目標

パフォーマンス目標は、特定のパフォーマンス・クラスのビジネス目標にとって最適なパフォーマンス・レベルを定義します。特定のパフォーマンス・クラスに対して、パフォーマンス目標はそのワークロードの目標平均レスポンス時間を指定します。

負荷の高い状況では、より重要な作業がパフォーマンス目標を満たせるように、ビジネス重要度の低い作業はOracle Database QoS Managementシステムによって故意にリソースを減らされます。この状況では、レスポンス時間が非常に低速になるかわりに、「サーバー・ビジー」メッセージが生成されることがあります。

パフォーマンス・ポリシー

パフォーマンス・ポリシーは、同時に施行することを意図したパフォーマンス目標とパフォーマンス・クラス・ランクのコレクションです。パフォーマンス・クラスが「測定のみ」としてマークされていないかぎり、パフォーマンス・ポリシーには各パフォーマンス・クラスのパフォーマンス目標とパフォーマンス・クラス・ランクが1つ以上含まれている必要があります。パフォーマンス・ポリシーには、オプションで、ポリシーがアクティブになる期間に対してサーバー・リソースのベースライン構成を設定するためのサーバー・プールのディレクティブ・オーバーライドが含まれます。

パフォーマンス満足度メトリック

特定のパフォーマンス目標がどの程度満たされているかを示し、Oracle Database QoS Managementがシステムのパフォーマンスと様々なパフォーマンス目標を比較できるようにする正規化された数値。

ポリシー・セット

ポリシー・セットはウィザードで生成されるXMLドキュメントであり、Oracle Database QoS Managementの操作を管理します。ポリシー・セットでは、サーバー・プールとホストされているパフォーマンス・クラス、各パフォーマンス・クラスのパフォーマンス目標を指定するパフォーマンス・ポリシーのコレクション、および各パフォーマンス・ポリシーのサーバー・プールのディレクティブ・オーバーライドを指定します。

プログラム名

プログラム名は、アプリケーションによって設定されるデータベース・セッション属性であり、一般にデータベース・リクエストを行うプログラムを識別するために使用されます。

RAWデータ

RAWデータは、どのような方法でも後処理されていないデータです。カウント、合計および個々のサンプル値はRAWデータの例です。

リソース

リソースは、リクエストを処理するために必要な、数量の限られた共有項目です。たとえば、CPU時間、スレッド、メモリー、I/Oデバイス、キュー内のスロット、ネットワーク帯域幅および一時領域はすべてリソースです。通常はサーバーがリソースを提供します。

リソース割当てコントロール

リソース割当てコントロール(非公式にはノブとも呼ばれます)は、リソース割当てメカニズムへのパラメータまたはパラメータのコレクションです。リソース割当てコントロールの例は次のとおりです。

- Oracle Database Resource Managerのコンシューマ・グループ

- サーバー・プール内のサーバー数

リソース割当てメカニズム

リソース割当てメカニズムは、リソースのコレクションの割当て方法を制御する能力を人やOracle Database QoS Managementなどの外部エンティティに与えるものです。Oracle Database Resource Managerはリソース割当てメカニズムの例です。

リソース・メトリック

リソース・メトリックは、リソースについて測定できるメトリックです。たとえば、「リソース使用時間」や「リソース待機時間」などです。

リソース使用時間

リソース使用時間は、作業リクエストがリソースを排他的に使用していた累積時間です。

リソース使用

リソース使用は、指定された一連の経過時間測定値を、1つの数値に累積した測定値です。たとえば、特定のサーバー上で特定の作業リクエストに費やしたCPU時間の測定値はリソース測定値です。指定された作業リクエストは、作業リクエストが処理されるときに、多くの異なる時間間隔にわたってCPUを使用します。

リソース待機時間

リソース待機時間は、リソースを使用する準備ができている作業リクエストがリソースの待機に費やした累積時間です。

レスポンス時間

サーバーがトランザクション・リクエストを受信してから、トランザクションのコミットまたは中止後にレスポンスを送信するまでの時間。

ローグ作業

予想よりも大幅に多くのリソースを使用する作業リクエスト。たとえば、作業リクエストは無限ループに入ることがあります。一部のシステムでは、ローグ作業を停止または再優先順位付けするための機能が用意されています。

ルーティング

ルーティングは、作業リクエストがシステムを通過するパスを選択する処理です。これには、作業リクエストを渡すシステムの別の層のエンティティを選択するときに行われるすべての選択肢が含まれます。

サーバー

サーバーは、通常は1人のユーザーの専用でない共有コンピュータです。サーバーは、単一のCPUブレードのように単純にすることも、メモリーを共有する多数のCPUを持つ大規模サーバーのように複雑にすることもできます。

サーバー・プール

サーバー・プールは、クラスタ管理者がEnterprise Manager Cloud ControlまたはServer Control (SRVCTL)ユーティリティを使用して作成するサーバーのコレクションです。サーバー・プールは層に含まれています。各サービスは特定のサーバー・プールで実行するように割り当てられます。

サーバー・プール重要度

クラスタ内のすべてのサーバー・プール間でサーバー・プールをランク付けする0から1000まで(0が最も低い重要度です)の数値。

サーバー・プール最大値

サーバー・プールに含まれるサーバーの最大数。

サーバー・プール最小値

サーバー・プールに含まれるサーバーの最小数。

サーバー・プールのディレクティブ・オーバーライド

クラスタ管理者サーバーがクラスタの可用性を高く保つための高可用性ガイドライン。

サービス

サービスは、ユーザー(クライアント)またはユーザー・グループによく認識された価値を提供します。サービスはアプリケーションに提供され、システムで実行されます。たとえば、CollabSuiteは、ファイル、カレンダ、Web会議などのサービスのセットを提供します。「データベース・サービス」も参照してください。

運用時間、容量計画、プロビジョニング、配置などの運用管理に関する決定は、サービス単位で行われます。

サービス配置

データベース・サービスの共有、停止または再配置のアクティビティ。

シングルトン・サービス

サイズが1のサーバー・プール内のサービス。

システム

ワークロード管理インスタンスが動作するサーバーの共有コレクションおよび関連するインフラストラクチャ(ネットワーク、ファイアウォール、ストレージ・システムなど)。

システム・メトリック

システム・メトリックは、異なるレイヤーで発生する処理を結び付けるのに役立つメトリックです。分析の残りの部分を実行できるフレームワークを提供します。たとえば、リクエスト数、レイヤー・レスポンス時間、レイヤー・アクティブ時間などです。

システムのすべての層が同じシステム・メトリック・セットを提供する必要があります。

タグ

作業リクエストがシステムによって受信されると、リクエストされた作業のタイプの分類が試行されます。分類の目的は、この作業リクエストに適用されるパフォーマンス・オブジェクトを判断することです。分類の結果は、作業リクエストがシステムで処理されるときに一緒に運ばれるタグ(パフォーマンス・クラス名)です。タグにより、作業リクエストをワークロード(パフォーマンス・クラス)のパフォーマンス目標に関連付けることができます。

層

層は、システム内の論理処理コンポーネントです。層は、システムにエンドツーエンドの処理スタックを提供するために相互に積み重ねられます。WebCache、OHS、OC4J、Oracle DatabaseおよびOracle Automatic Storage Managementは層の例です。

特定の層には、重複または個別機能を提供する複数のエンティティがある場合があります。たとえば、システムには、より高い可用性と2つのデータベース用(一方はCRM用、もう一方はERP用)の2つのOHSインスタンスが含まれることがあります。

ユニフォーム・サービス

サーバー・プールのすべてのノードに提供する必要のあるサービス。

UserName

データベースの認証に使用されるOCI_ATTR_USERNAMEまたはOracle Databaseユーザー。

作業リクエスト

作業リクエストは、ユーザーが開始できる作業の最小単位です。作業リクエストには、HTTPリクエスト、SOAPリクエスト、データベースに送信されるSQL文、またはプロセスの実行があります。作業リクエストは、外部または別のレイヤーからレイヤーに到着します。作業リクエストが処理されて、レスポンスが生成され、レスポンスはリクエスト元に返信されます。

索引

A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  Q  R  S  T  U  V  W

A

- アクセス制御

- Oracle ASMのためのサポート 1

- ACL属性 1

- ACTION 1 , 2

- アクティブ化

- パフォーマンス・ポリシー 1

- アクティブなリソース・プラン 1

- 追加

- パフォーマンス・クラスへの分類子 1

- サーバー・プールへのサーバー 1

- ポリシー・セットへのサービス 1 , 2

- 管理者管理型データベース

- サポート 1 , 2

- 管理者

- クラスタ 1 , 2 , 3

- Oracle Database QoS Managementの作成 1

- QoSAdminユーザーの作成 1

- データベース 1

- 初期構成タスク 1

- OC4J 1

- Oracle Database QoS Management 1

- アラート

- Oracle Enterprise Manager 1 , 2

- 別の推奨 1 , 2

- アプリケーション・コンテキスト 1

- アプリケーション

- 作業リクエストの分類 1

- 定義 1

- 分類子で使用されるパラメータ 1

- リソース要件 1

- サポートされる接続 1

- APPQOS_PLAN

- 編集 1

- APPQOSSYSユーザー 1 , 2

- 監査ログ 1

- 認可されたアクション 1 , 2 , 3

- 自動データベース診断モニター(ADDM) 1

- 自動ワークロード・リポジトリ(AWR) 1

- 平均レスポンス時間

- パフォーマンス・クラス 1

- パフォーマンス目標 1 , 2

- 定義 1 , 2

B

- バッチ・ジョブ 1

- bequeath接続 1

- ボトルネック

- パフォーマンス・クラス 1 , 2

- パフォーマンス目標 1

- 推奨 1

- CPUリソース 1

- パフォーマンス・クラス 1

- グローバル・キャッシュ・リソース 1

- I/Oリソース 1

- メトリックを使用した特定 1

- その他のリソース 1

- 解消 1

- ビジネス目標 1

C

- カレンダ 1

- 候補サーバー・リスト 1

- CHM 1

- 分類ルール

- デフォルト 1

- 分類子

- 追加 1

- 複数のサービス 1 , 2

- パフォーマンス・クラス 1 , 2

- サービス名 1

- セッション属性 1

- タグ 1

- 作成 1

- default_pc 1

- 削除 1

- 評価順序 1

- デフォルトのパフォーマンス・クラス 1

- 変更 1

- 複数の属性 1

- 評価の順序 1

- セッション属性 1

- 評価順序の指定 1 , 2

- クライアント

- Java Database Connectivity(JDBC)クライアント 1

- プログラムの名前 1

- Oracle Call Interface(OCI) 1

- サポートされる接続 1

- データベース・セッション間での追跡 1

- クラスタ管理者 1 , 2 , 3 , 4

- 構成の推奨 1

- 構成違反 1 , 2

- 構成

- ロード・バランシング目標 1

- クラスタ用Oracle Grid Infrastructure 1

- Oracle RACデータベース 1

- パフォーマンス目標 1

- サーバー・プールのディレクティブ・オーバーライド 1 , 2 , 3

- サーバー・プール 1

- データベースへの接続 1

- 接続時ロード・バランシング 1

- 接続プール 1

- 接続

- bequeath 1

- ロード・バランシング 1

- 実行時のロード・バランシング 1

- データベース 1

- コンシューマ・グループ

- 推奨 1 , 2

- パフォーマンス・ポリシーのコピー 1

- CPU_COUNT

- 複数のデータベース 1 , 2

- デフォルト値 1 , 2

- CPUパーティション 1

- CPUリソース・ボトルネック

- 解消 1

- ポリシー・セットの作成ウィザード 1

- 作成

- 初期ポリシー・セット 1

- Oracle Database QoS Management管理者ユーザー 1

- パフォーマンス・クラス 1

- パフォーマンス・ポリシー 1

- QoSAdminユーザー 1

- サーバー・プール 1 , 2

- サービス 1

- CRSCTL 1

D

- ダッシュボード

- アクセス 1

- 推奨の分析結果 1

- 推奨 1

- リソース・ボトルネック 1

- ワークロード・サージ 1

- 「一般」セクションの説明 1

- 推奨の実装 1

- ログイン 1

- 主要セクション 1

- パフォーマンス概要 1 , 2

- パフォーマンス満足度メトリックのチャート 1

- QoSステータス 1

- 推奨が生成されない 1

- 「「推奨」」セクション 1

- リソースの使用VS待機時間のチャート 1

- リソース待機時間のブレークダウン 1 , 2

- 状況分析 1

- 推奨の詳細の表示 1

- 推奨の表示 1

- データベース

- ランクにより決定された起動順序 1

- Database Configuration Assistant(DBCA) 1

- データベース接続 1

- データベース・パラメータ 1

- Database Resource Manager

- 「Oracle Database Resource Manager」を参照

- データベース

- サービスの追加 1 , 2

- CPU_COUNT 1 , 2

- 準拠 1

- サービスとの接続 1

- 接続 1

- デフォルト・サービス 1

- Oracle Database QoS Managementの有効化 1

- Oracle RAC One Node 1

- ポリシー管理型 1 , 2 , 3

- サービス 1

- サーバー・プールの共有 1

- シングルトン 1

- 起動順序 1

- アップグレード 1

- データベース・サービス

- 「サービス」を参照

- データベース・セッション

- クライアント・リクエストの追跡 1

- デフォルト

- 分類子 1

- CPU_COUNT 1 , 2

- データベース・サービス 1

- ネームスペース 1

- OC4J_PORT 1

- QoSAdminユーザーのパスワード 1

- パフォーマンス・ポリシー 1 , 2

- ポリシー・セット 1 , 2

- QoSAdminパスワード 1

- 削除

- パフォーマンス・クラスの分類子 1

- パフォーマンス・クラス 1

- パフォーマンス・ポリシー 1

- 要求

- レベルの変更 1

- サージ 1 , 2 , 3 , 4

- 無効化

- クラスタに対するOracle Database QoS Management 1

E

- ポリシー・セットの編集ウィザード 1 , 2 , 3 , 4 , 5 , 6

- 有効化

- Oracle Database QoS Management 1

- クラスタに対するOracle Database QoS Management 1 , 2 , 3 , 4

- データベースに対するOracle Database QoS Management 1

- トレース 1

- Enterprise Manager

- Oracle Database QoS Managementサーバーとの統合 1

- 分類子の評価 1

- 分類子の評価順序 1

F

- FAST_START_MTTR_TARGET 1

- 高速アプリケーション通知(FAN) 1

- floaters 1

- 空きプール 1 , 2 , 3

G

- 汎用プール 1

- グローバル・キャッシュ・リソース・ボトルネック

- 解消 1

- 目標

- サービス 1

- LONG 1

- SEVICE_TIME 1

- SHORT 1

- THROUGHPUT 1

- グリッド・インフラストラクチャ管理リポジトリ 1

- GV$ビュー問合せ 1

H

- ヘッドルーム

- 最大化 1

- 高可用性 1

I

- I/Oリソース・ボトルネック

- 解消 1

- 実装

- 別の推奨 1

- 自動アクション 1

- 推奨 1

- 初期化パラメータ

- CPU_COUNT 1 , 2

- 初期ポリシー・セット 1

- インスタンス・ケージング 1

- IPアドレス

- IPv6のサポート 1

J

- Java Database Connectivity

- クライアント 1

- JDBC

- 「Java Database Connectivity」を参照

L

- LMSプロセス 1

- ロード・バランシング

- サービスの目標の構成 1

- 接続 1

- ランタイム接続 1

- ロード・バランシング・アドバイザ

- データ 1

- 目標 1 , 2

- ログ・ファイル 1

M

- メンテナンス・ウィンドウ 1

- 管理対象サーバー・プール

- Oracle RACデータベース・インスタンス 1

- 管理

- サーバー・プール 1 , 2

- ユーザー 1

- 測定のみ

- パフォーマンス・クラス 1 , 2 , 3

- パフォーマンス・ポリシー 1

- 測定のみモード 1 , 2

- MemoryGuard 1 , 2

- メモリー不足 1

- メトリック

- 収集 1

- パフォーマンス 1

- パフォーマンス・クラス 1

- リソース 1

- 非表示 1

- パフォーマンス満足度 1

- 最小レスポンス時間 1

- サーバー・プールの最小サイズ 1

- 変更

- パフォーマンス・クラスの分類子 1

- パフォーマンス・クラス 1

- パフォーマンス・ポリシー 1

- サーバー・プール設定 1

- MODULE 1 , 2

- 複数層環境 1

N

- ネームスペース

- デフォルト 1

O

- OC4J

- 管理者 1

- デフォルトのポート 1

- OC4J_PORT環境変数 1

- OC4Jコンテナ

- 検索 1

- OCI

- 「Oracle Call Interface」を参照

- OCIAttrSet関数 1

- ODP.NET 1

- OLTPワークロード 1

- オープン・ワークロード 1

- Oracle ASM

- アクセス制御 1

- パッチ適用 1

- 役割区分 1

- Oracle Call Interface

- クライアント 1

- Oracle Cluster Health Monitor 1

- Oracle Clusterware Repository 1 , 2

- Oracle Database QoS Management

- 管理者 1 , 2

- アクティブなパフォーマンス・ポリシーの変更 1 , 2

- ダッシュボード 1

- 「ダッシュボード」も参照

- ダッシュボードのセクション 1

- クラスタに対する無効化 1

- クラスタに対する有効化 1 , 2 , 3 , 4

- データベースに対する有効化 1

- ログ・ファイル 1

- サーバー・プールの選択 1

- OC4Jコンテナをホストするサーバー 1

- ステータス 1

- トレース・ファイル 1

- トラブルシューティング 1

- ダッシュボードの使用 1

- クラスタ管理ステータスの表示 1

- 現在のステータスの表示 1

- Oracle Database QoS Management管理者

- 作成 1

- デフォルト・パスワード 1

- Oracle Database Resource Manager

- 有効化 1

- Oracle Enterprise Managerアラート 1

- Oracle Enterprise Managerダッシュボード 1

- 「ダッシュボード」も参照

- Oracle RACデータベース

- 作成 1

- サポートされるリリース 1

- Oracle RAC高可用性フレームワーク 1

- Oracle RAC One Nodeデータベース 1

- Oracle Real Application Clusters(Oracle RAC)

- Oracle Database QoS Management 1

- Oracleウォレット 1

- 過負荷のシステム 1

- オーバーライド

- 「サーバー・プールのディレクティブ・オーバーライド」を参照

P

- パラレル問合せ 1

- パッチ適用

- Oracle ASM 1

- パフォーマンス・クラス

- ランク 1

- パフォーマンス・クラス

- 分類子の追加 1

- サービスの追加 1 , 2

- アラート 1

- 分類子 1

- 同種のリクエスト 1

- サービス 1

- ランクの変更 1

- 分類子の順序付け 1

- 分類子 1

- パフォーマンス目標の構成 1

- 作成 1

- 分類子の作成 1

- デフォルト 1

- デフォルト名 1

- 削除 1

- 分類子の削除 1

- 分類子の評価 1

- パフォーマンスの向上 1

- 不完全なデータ 1

- リスト 1

- 作業リクエストの個別管理 1

- 最大 1

- 測定のみ 1 , 2 , 3

- メトリック 1

- メトリックがない 1

- 変更 1

- 分類子の変更 1

- 複数の分類子 1

- リクエストなし 1

- 未確認のデータ 1

- 予測される推奨の影響 1

- ランク 1

- パフォーマンス目標との関連 1

- 名前の変更 1

- パフォーマンス目標を満たす 1

- 分類子の評価順序の設定 1

- 分類子の評価順序の指定 1

- ランクの指定 1

- アプリケーション開発者による推奨 1

- メトリックを収集できない 1

- パフォーマンス・ポリシーでの使用 1

- パフォーマンス・メトリックの表示 1 , 2 , 3

- リソース待機時間の表示 1

- リソースの待機時間 1

- パフォーマンス・メトリック 1

- パフォーマンス目標

- 重要度 1

- サポートされているタイプ 1

- パフォーマンス目標

- サービス 1

- 構成 1

- 定義 1

- 管理 1

- ランク 1 , 2

- パフォーマンス・クラスとの関連 1

- 指定 1

- 値の指定 1

- パフォーマンス・ポリシー

- アクティブ化 1

- サーバー・プール 1

- changing active 1 , 2

- コピー 1

- 作成 1

- 追加作成 1

- デフォルト 1

- デフォルト・ポリシー 1

- 定義 1

- 削除 1

- 測定のみ 1

- 変更 1

- パフォーマンス・クラスのランキング 1

- パフォーマンス・クラスでの調整 1

- アクティブ・ポリシーのスケジューリング 1

- サーバー・プールのディレクティブ・オーバーライド 1

- パフォーマンスの予測 1

- パフォーマンス満足度メトリック(PSM) 1 , 2 , 3 , 5

- パフォーマンス・チューニング 1

- ポリシーおよびパフォーマンス管理エンジン 1

- ポリシーの変更

- ログ 1

- ポリシー管理型データベース 1 , 2

- ポリシー・セット

- アクティブなポリシー 1

- サーバー・プールの追加 1

- 管理 1

- 新しいポリシー・セットの作成 1

- 現在のポリシー 1

- デフォルト 1

- 初期 1

- 変更 1

- ポリシー・セット

- 内容 1

- 作成 1

- デフォルト 1 , 2

- デフォルト設定 1

- PROGRAM 1 , 2

Q

- qosadmin 1

- QoS管理者

- 初期構成タスク 1

- QoSAdminユーザー

- デフォルト・パスワード 1 , 2

- qosctl 1

- QOSCTLユーティリティ

- 構文 1

R

- パフォーマンス目標のランキング 1

- ランク

- データベースの起動順序 1

- パフォーマンス・クラス 1 , 2

- パフォーマンス・クラス 1

- 推奨事項

- 別 1 , 2

- 分析結果 1

- 自動実装 1

- 別のアクションの選択 1

- コンシューマ・グループ・マッピング 1 , 2

- 生成 1

- 実装 1 , 2 , 3

- 別の推奨の実装 1

- 間隔 1

- 反復 1

- 悪影響 1

- 表示されない 1

- 生成されない 1

- サーバーの再割当て 1

- ダッシュボードのセクション 1

- 状況分析 1

- 表示 1 , 2

- 詳細の表示 1

- 「推奨アクション」ページ 1

- サーバー・プールからのサーバーの削除 1

- 名前の変更

- パフォーマンス・クラス 1

- 要件

- システム 1 , 2

- 解決

- CPUリソース・ボトルネック 1

- グローバル・キャッシュ・リソース・ボトルネック 1

- I/Oリソース・ボトルネック 1

- その他のリソース・ボトルネック 1

- リソース・ボトルネック

- 解消 1

- リソース・マネージャ

- 「Oracle Database Resource Manager」を参照

- リソース・プラン

- APPQOS_PLAN 1 , 2

- 編集 1

- Oracle Database QoS Managementで使用 1

- リソース

- 割当て 1

- ボトルネック

- 推奨 1

- CPUアクセスの増加 1

- ボトルネックの解決 1

- starved 1

- タイプ 1

- 使用 1

- 待機 1

- 待機時間 1

- リソース・タイプ

- ボトルネック 1

- CPU 1

- グローバル・キャッシュ 1

- I/O 1

- OC4J 1

- その他 1

- 待機時間の表示 1

- リソースの使用VS待機時間のチャート 1

- レスポンス時間 1

- レスポンス時間

- リクエスト当たりの平均 1

- 定義 1

- 達成できる最小 1

- RMIポートの競合 1

- 役割区分

- Oracle ASM 1

- 実行時接続ロード・バランシング 1

- ランタイム接続ロード・バランシング目標 1

S

- スケジュール

- アクティブなパフォーマンス・ポリシー 1

- SERVER_NAMES属性 1

- サーバー・プールのディレクティブ・オーバーライド

- 構成 1 , 2

- 指定 1

- 有効値 1

- サーバー・プール

- アクセス 1 , 2

- ポリシー・セットへの追加 1

- サイズの調整 1

- 複数のデータベース 1

- 推奨 1

- サービス 1

- 属性 1

- 候補サーバー・リスト 1 , 2

- 構成 1

- 制約 1

- 作成 1 , 2

- directive overrides 1

- 実行権限 1

- 空きプール 1 , 2

- 最小プール・サイズの増加 1

- リスト 1

- 管理型 1 , 2

- 管理対象としてマーク 1

- 最大サイズ1 1 , 2 , 4

- 最小サイズ 1 , 2 , 3 , 4

- 最小サイズ1 1

- 設定の変更 1

- Oracle Enterprise Managerを使用した変更 1

- 権限 1

- サーバーの削除 1

- 管理のための選択 1

- SERVER_NAMES属性 1

- サーバーが追加されない 1

- 管理不能 1

- 管理対象外 1

- 複数のサーバー・プールの使用 1

- 現在の設定の表示 1

- サーバー

- 不適切なサーバー・プールへの追加 1

- Oracle Database QoS Managementサーバーのホスティング 1

- SERVICE_NAME 1

- SERVICE_TIME 1

- サービス・レベル合意(SLA) 1 , 2 , 3 , 5 , 6

- サービス・レベル 1

- サービス

- ポリシー・セットへの追加 1 , 2

- Oracle Clusterware 1

- 作業リクエスト 1

- ロード・バランシング目標の構成 1

- 作成 1

- デフォルトのデータベース・サービス 1

- デフォルト

- パフォーマンス・クラス 1

- 自動検出 1

- データベース接続 1

- ロード・バランシング 1

- 名前 1

- シングルトン 1

- SINGLETON 1 , 2 , 3

- 複数の指定 1

- トランザクションによる停止 1

- UNIFORM 1 , 2

- ワークロードでの使用 1

- セッション属性

- ACTION 1

- 分類子 1

- MODULE 1

- プログラム 1

- ユーザー名 1

- ポリシーの設定 1

- シングルトン・データベース 1

- SINGLETONサービス 1 , 2

- 状況分析 1

- SLA

- 「サービス・レベル合意」を参照

- スライス 1

- SQLパフォーマンスの問題 1

- SRVCTL 1 , 2 , 3 , 4 , 5

- データベースの起動順序 1

- ストレージ相互接続 1

- サポート

- 接続タイプ 1

- Oracle RACデータベース・リリース 1

- レスポンス時間 1

- ワークロード 1 , 2 , 3

- support for Administrator-Managed databases 1 , 2

- システム・パラメータ 1

- システム・パフォーマンス

- 評価 1 , 2

- システム要件 1 , 2

T

- タグ付け 1

- タグ

- 分類子 1

- 作業リクエスト 1

- トレース・ファイル 1

- トレース

- 有効化 1

- トラブルシューティング

- クラスタに対するOracle Database QoS Managementの有効化 1

- データベースに対するOracle Database QoS Managementの有効化 1

U

- UNIFORMサービス 1

- USERENVネームスペース 1

- USERNAME 1

- ユーザー名 1

- ユーザー

- APPQOSSYS 1

- 管理者の作成 1

- QoSAdminのデフォルト 1

V

- 表示

- 現在のサーバー・プール設定 1

- 最新の分析結果 1

- パフォーマンス・メトリック 1 , 2

- 推奨の詳細 1

- 推奨 1

- リソース待機時間 1

- 違反

- CPU_COUNT 1

- 構成 1 , 2 , 3

- パフォーマンス目標 1

- ログ 1

- 有効になっていないリソース・プラン 1

- 表示 1

W

- 待機時間

- リソース 1

- 表示 1

- ウィザード

- ポリシー・セットの作成 1

- ポリシー・セットの編集 1 , 2 , 3 , 4 , 5 , 6

- ワークロードのランク

- データベースの起動順序 1

- ワークロード

- 新規パフォーマンス・クラスの作成 1

- GV$ビュー・リクエスト 1

- パラレル問合せ 1

- サーバー・プール 1

- コールとパフォーマンス・クラス 1

- consolidating 1

- データベース接続 1

- 作業のサブセットに対する様々なリソース要件 1

- 管理 1

- 監視 1

- OLTP 1

- スケーリング 1

- 分離 1

- サポートされるレスポンス時間 1

- サポートされるタイプ 1 , 2 , 3

- サージ 1 , 2 , 3

- チューニング目標 1

- 作業リクエスト

- サービス 1

- タグ 1

- 分類子の作成 1

- 定義 1

- 個別の管理 1

- メトリック 1

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。