ガバナーの規則節

パーティション・データベース環境では、グローバル・スナップショットの代わりにローカル・アプリケーション・スナップショットを使用して、setlimit の評価のための情報を収集します。 forcecoord アクションが実行されるのは、アプリケーションのコーディネーター・パーティションで setlimit 値を超過した場合に限られます。 例えば、ルールに「idle 30」という setlimit があって、コーディネーター・エージェントのアイドル時間が 40 秒になっていると、forcecoord アクションが実行され、すべてのパーティションでアプリケーションが終了します。 ただし、リモートのサブエージェントのみが 40 秒間アイドルになっても、アクションは実行されません。

• Linux および UNIX では、 agentpri データベース・マネージャー構成パラメーターをデフォルト値に設定する必要があります。そうしないと、 nice 値がオーバーライドされます。
• Windows プラットフォームでは、 agentpri データベース・マネージャー構成パラメーターと nice 値を一緒に使用できます。

ガバナーを使用して、デフォルトのユーザー・サービス・スーパークラス、SYSDEFAULTUSERCLASS で実行するアプリケーションの優先順位を制御できます。 ガバナーを使用して、このサービス・スーパークラスで実行するアプリケーションの優先順位を低くする場合、エージェントは自分自身をそのアウトバウンド相関関係子から切断し (両者が関連付けられている場合)、ガバナーによって指定されたエージェント優先順位に従ってその相対優先順位を設定します。 ガバナーを使用して、ユーザー定義サービスのスーパークラスおよびサブクラスでエージェント優先順位を変更することはできません。 その代わりに、スーパークラスまたはサブクラスのエージェント優先順位の設定を使用して、それらのサービス・クラスで実行するアプリケーションを制御する必要があります。 一方で、ガバナーを使用してサービス・クラスでの接続を強制することができます。

   chuser capabilities=CAP_NUMA_ATTACH,CAP_PROPAGATE <userid>

各基準で上位の 3 つのアプリケーションには、他のどのアプリケーションよりも高い優先順位が与えられます。 つまり、 各基準のグループで 1 位のアプリケーションには最も高い優先順位が、 その次のアプリケーションには 2 番目に高い優先順位が、 そして 3 位のアプリケーションには 3 番目に高い優先順位が与えられます。 単一のアプリケーションが複数の基準において 3 位以内となった場合、 そのアプリケーションには最も高い順位となった基準において該当する優先順位が与えられ、 他の基準においては、その次の順位にあるアプリケーションに 1 つ高い優先順位が与えられます。 例えば、アプリケーション A が保持するロックの数が最も多い状況で、推定残り実行時間が 3 番目に短い場合は、アプリケーション A に最初の基準で最も高い優先順位が与えられます。 さらに、推定残り実行時間が 4 位のアプリケーションに、その基準で 3 番目に高い優先順位が与えられます。

このガバナー規則によって選択されたアプリケーションは、 3 つのクラスに分けられます。 それぞれのクラスごとに、ガバナーは上記の基準に基づいて、各クラスからの上位 3 つである、9 個のアプリケーションを選択します。 class オプションを指定すると、このルールで選択されたすべてのアプリケーションが 1 つのクラスと見なされ、前述のように 9 個のアプリケーションが選択され、高い優先順位が与えられます。

複数のガバナー規則で同じアプリケーションが選択された場合、 最後に選択された際の規則によって管理されます。

• 異なるグループのアプリケーションが、すべてのアプリケーションに平均に時間を分割することなく確実に時間を入手するようにします。 例えば、14 のアプリケーション (短いアプリケーション 3 つ、中程度 5 つ、長いアプリケーション 6 つ) を同時に実行している場合、これらは CPU を分割しているので、それぞれの応答時間は満足のいくものではないかもしれません。 データベース管理者は、中程度の長さのアプリケーションと、 長いアプリケーションの 2 つのグループを設定できます。 優先順位を使用して、ガバナーはすべての短いアプリケーションの実行を許可し、 大部分を占める 3 つの中程度のアプリケーションと 3 つの長いアプリケーションを、 同時に確実に実行します。 これを行うために、ガバナー構成ファイルには、 中程度のアプリケーションに 1 つの規則、長いアプリケーションに別の規則が入っています。
  以下に、この点を例証するガバナー構成ファイルの一部を示します。

  desc "Group together medium applications in 1 schedule class."
  applname medq1, medq2, medq3, medq4, medq5
  setlimit cpu -1
  action schedule class;
  
  desc "Group together long applications in 1 schedule class."
  applname longq1, longq2, longq3, longq4, longq5, longq6
  setlimit cpu -1
  action schedule class;

• 複数のユーザー・グループのそれぞれ (例えば、 組織上の部門) が確実に等しい優先度を獲得できるようにします。 あるグループが多数のアプリケーションを実行している場合でも、 管理者は他のグループが自分のアプリケーション用に適度な応答時間を獲得できるようにすることができます。 例えば、3 つの部門 (金融、在庫、企画) が関係している場合、すべての金融ユーザーを 1 つ目のグループに、すべての在庫ユーザーを 2 つ目のグループに、すべての企画ユーザーを 3 つ目のグループに入れることができます。 処理能力は 3 つの部門の間でより平均に、またはその逆に分割されます。
  以下に、この点を例証するガバナー構成ファイルの一部を示します。

  desc "Group together Finance department users."
  authid tom, dick, harry, mo, larry, curly
  setlimit cpu -1
  action schedule class;
  
  desc "Group together Inventory department users."
  authid pat, chris, jack, jill
  setlimit cpu -1
  action schedule class;
  
  desc "Group together Planning department users."
  authid tara, dianne, henrietta, maureen, linda, candy
  setlimit cpu -1
  action schedule class;

• ガバナーにすべてのアプリケーションをスケジュールさせます。

  class オプションを指定しないと、ガバナーは、スケジュール・アクションに該当するアクティブ・アプリケーションの数に基づいて独自のクラスをいくつか作成し、アプリケーションで実行している照会の照会コンパイラーのコスト見積もりに基づいて、アプリケーションをそれぞれのクラスに入れます。 管理者は、どのアプリケーションを選択するかを限定しなければ (つまり、applname、authid、setlimit のいずれかの節を指定しなければ)、すべてのアプリケーションのスケジュールを自分で設定できます。