我不确定你有多大可能改变你处理配置的方式,但我们通过使用本地覆盖的想法实现了类似的东西。具体来说,您有两个相同的配置表(称为 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 值。
在我们的系统中,它实际上比这要复杂得多。除了您要查找的参数的“名称”之外,我们还有一个“上下文”列来描述我们正在查找的上下文。例如,我们可能有一个集中设置的参数“timeout”,但即使在本地,我们也有多个使用该值的组件。它们可能都相同,但我们也可能希望对它们进行不同的配置。因此,当工具查找“超时”值时,它也会受到范围的限制。在配置本身中,当我们定义我们想要的范围时,我们可能会使用通配符,例如:
CONTEXT NAME VALUE
------------- ------- -----
Comp Engine A timeout 15
Comp Engine B timeout 10
Comp Engine % timeout 5
% timeout 30
上面的配置说,对于所有组件,使用 30 的超时,但对于任何类型的 Comp Engine,使用 5 的超时,但是对于 Comp Engines A 和 B,分别使用 15 和 10。最后两个配置可以在 CentralConfig 中维护,但其他两个可以在 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 范围更窄的情况下,您也只需颠倒两个排序术语的位置即可。