Я не уверен, насколько возможно для вас изменить способ обработки вашей конфигурации, но мы реализовали нечто подобное, используя идею локальных переопределений. В частности, у вас есть две таблицы конфигурации, которые идентичны (назовите их CentralConfig и LocalConfig). CentralConfig поддерживается в центральном местоположении и реплицируется на ваши спутниковые местоположения, где это только для чтения. LocalConfig может быть установлен на локальном сайте. Ваша процедура, которая запрашивает данные конфигурации, сначала ищет данные в таблице LocalConfig и, если не найдена, извлекает их из таблицы CentralConfig.
Например, если вы пытаетесь сделать это со значениями в таблице параметров v $, вы можете запросить вашу конфигурацию, используя функцию FIRST_VALUE в аналитике SQL:
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 $.
В нашей системе все гораздо сложнее. В дополнение к «имени» для параметра, который вы ищете, у нас также есть столбец «context», который описывает контекст, который мы ищем. Например, у нас может быть параметр «тайм-аут», который устанавливается централизованно, но даже локально у нас есть несколько компонентов, которые используют это значение. Они могут быть одинаковыми, но мы также можем настроить их по-разному. Поэтому, когда инструмент ищет значение «тайм-аут», он также ограничивается областью действия. В самой конфигурации мы можем использовать подстановочные знаки, когда определяем, что хотим для области видимости, например:
CONTEXT NAME VALUE
------------- ------- -----
Comp Engine A timeout 15
Comp Engine B timeout 10
Comp Engine % timeout 5
% timeout 30
Приведенная выше конфигурация говорит, что для всех компонентов используйте тайм-аут 30, но для Comp Engine любого типа используйте тайм-аут 5, для Comp Engine 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;
Это в основном тот же запрос, за исключением того, что я вставляю это выражение TRANSLATE перед моей локальной сортировкой, и я ограничиваюсь контекстом. Он конвертирует символы% и _ в chr (1) и chr (2), что позволяет сортировать их по буквенно-цифровым символам в порядке убывания. Таким образом, явно определенный «Comp Engine A» будет стоять перед «Comp Engine%», который, в свою очередь, будет стоять перед «%». В случаях, когда контексты определены одинаково, локальный конфигурационный файл имеет приоритет над центральным; если вы хотите, чтобы local всегда превосходил центральный, даже в тех случаях, когда центральный диапазон был более ограничен, вы просто изменили бы положения двух членов сортировки.