ポリシー管理データベースの管理

ポリシー管理データベースの管理では、作成、サイズ設定、パッチ適用およびロード・バランシングに関して、管理者管理データベースより構成および再構成の手順が少なくて済みます。また、クラスタ内のサーバー・プールのサーバーはどのデータベースでも実行できるため、データベース・インスタンスとノード名のマッピングを作成して維持する必要はありません。サーバーを空きプールに再配置することによって、またはサーバー・プールの最小サイズと最大サイズを調整することによって、パッチ適用などのメンテナンス・タスクを実行できるため、必要な可用性が維持されます。

関連項目:

詳細は、「srvctl modify srvpool」および「srvctl relocate server」を参照してください

ポリシー管理データベースでは、サービスの管理も容易になります。ポリシー管理データベースは、単一サーバー・プールに割り当てられ、プール内のすべてのサーバーにわたってシングルトンまたは均一として実行されるためです。サービスごとに明示的に優先かつ使用可能なデータベース・インスタンス・リストを作成または維持する必要はなくなりました。手動による再配置または高可用性イベントのためサーバーをサーバー・プールに移動すると、統一されたすべてのサービスおよびその依存データベース・インスタンスは自動的に起動します。1つ以上のシングルトン・サービスをホストしているサーバーがダウンした場合、これらのサービスは、サーバー・プール内の残りの1つ以上のサーバーで自動的に起動します。Oracle RAC One Nodeの場合、対応するデータベース・インスタンスも自動的に起動します。

相互に関連するサービスの管理は、各サーバー・プールの重要度属性を利用することによって向上します。サーバー・プールで実行される各サービスは、クラスタ内で他のサーバー・プールにホストされているサービスに関連するサーバー・プールの重要度を継承します。最も重要なサーバー・プールの最小サイズが0(ゼロ)より大きい場合、このサーバー・プール内のサービスおよび関連のデータベース・インスタンスは、クラスタの起動時に最初に起動し、クラスタ内に1つのサーバーが実行されているかぎり、実行されている最後のサービスおよびデータベース・インスタンスになります。重要でないサービスは最も重要でないサーバー・プールのビジネスに提供でき、要求または障害のために十分なリソースが使用できない場合、これらのサービスは最終的に停止され、よりビジネスクリティカルなサービスが使用可能なまま存続するようにできます。

数多くの管理タスクは、統合環境内の複数のデータベース、サービスまたはサーバー・プールに影響を与える可能性のある変更を伴うことがあるため、特定のSRVCTLコマンドの評価モードを使用して、コマンドのリソース影響のレポートを取得できます。

サーバー・プールを変更するシステムに対する影響を評価する次の例を考えてください。

$ srvctl modify srvpool -l 3 -g online -eval
Service erp1 will be stopped on node test3
Service reports will be stopped on node test3
Service inventory will be stopped on node test3
Service shipping will be stopped on node test3
Database dbsales will be started on node test3
Service orderentry will be started on node test3
Service billing will be started on node test3
Service browse will be started on node test3
Service search will be started on node test3
Service salescart will be started on node test3
Server test3 will be moved from pool backoffice to pool online

前述の例に示すとおり、サーバー・プールを変更すると、数多くのリソース状態の変更を招くことがあります。Oracle ClusterwareまたはOracle Database Quality of Service Managementを介してポリシー・セットを使用できます。