構成の処理方法を変更できるかどうかはわかりませんが、ローカルオーバーライドのアイデアを使用して、これに似たものを実装しました。具体的には、同一の構成テーブルが 2 つあります (CentralConfig と LocalConfig と呼びます)。CentralConfig は中央の場所で維持され、読み取り専用のサテライトの場所に複製されます。LocalConfig は、ローカル サイトで設定できます。構成データを照会するプロシージャーは、最初に LocalConfig テーブル内のデータを検索し、見つからない場合は、CentralConfig テーブルからデータを取得します。
たとえば、v$parameter テーブルの値を使用してこれを実行しようとしている場合、SQL 分析で FIRST_VALUE 関数を使用して構成をクエリできます。
SELECT DISTINCT
NAME
, FIRST_VALUE(VALUE) OVER(PARTITION BY NAME
ORDER BY localsort
) VALUE
FROM (SELECT t.*
, 0 localsort
FROM local_parameter t
UNION
SELECT t.*
, 1 localsort
FROM v$parameter t
)
ORDER BY NAME;
ユニオンの localsort 列は、local_parameter の値が v$parameter の値よりも優先されるようにするためのものです。
私たちのシステムでは、実際にはこれよりもはるかに洗練されています。検索しているパラメーターの「名前」に加えて、探しているコンテキストを説明する「コンテキスト」列もあります。たとえば、一元的に設定されたパラメーター「タイムアウト」があるかもしれませんが、ローカルであっても、この値を使用する複数のコンポーネントがあります。それらはすべて同じかもしれませんが、それらを別の方法で構成したい場合もあります。そのため、ツールが「タイムアウト」値を検索すると、スコープによっても制約されます。構成自体では、次のように、スコープに必要なものを定義するときにワイルドカードを使用できます。
CONTEXT NAME VALUE
------------- ------- -----
Comp Engine A timeout 15
Comp Engine B timeout 10
Comp Engine % timeout 5
% timeout 30
上記の構成では、すべてのコンポーネントに対してタイムアウト 30 を使用しますが、任意のタイプのコンプ エンジンではタイムアウト 5 を使用しますが、コンプ エンジン A と B ではそれぞれ 15 と 10 を使用します。最後の 2 つの構成は CentralConfig で維持される可能性がありますが、他の 2 つは LocalConfig で維持される可能性があり、次の方法で設定を解決します。
SELECT DISTINCT
NAME
, FIRST_VALUE(VALUE) OVER(PARTITION BY NAME
ORDER BY (TRANSLATE(Context
, '%_'
, CHR(1) || CHR(2)
) DESC
, localsort
) VALUE
FROM (SELECT t.*
, 0 localsort
FROM LocalConfig t
WHERE 'Comp Engine A' LIKE Context
UNION
SELECT t.*
, 1 localsort
FROM CentralConfig t
WHERE 'Comp Engine A' LIKE Context
)
ORDER BY NAME;
これは基本的に同じクエリですが、localsort の前に TRANSLATE 式を挿入し、Context に制約を課している点が異なります。% と _ 文字を chr(1) & chr(2) に変換して、降順で英数字の後に並べ替えます。このように、明示的に定義された「Comp Engine A」は「Comp Engine %」の前に来て、「%」の前に来ます。コンテキストが同じように定義されている場合、ローカル構成が中央のものよりも優先されます。local が常に central より優先されるようにしたい場合は、central がより厳密にスコープされている場合でも、2 つのソート条件の位置を逆にするだけです。