Хранение значений хранимых процедур PLSQL в кэшах памяти Oracle в течение продолжительных периодов времени.

Question

Я собираю данные профилирования во время выполнения из хранимых процедур PLSQL. Данные собираются по мере выполнения определенных хранимых процедур, но их необходимо накапливать при многократном выполнении этих процедур.

Чтобы свести к минимуму накладные расходы, я хотел бы сохранить эти данные профилирования в некотором резидентном хранилище памяти Oracle с доступом к PLSQL где-нибудь на время интервала сбора данных, а затем выгрузить накопленные значения. Интервал сбора данных может составлять секунды или часы; Это нормально, чтобы не хранить эти данные через системные загрузки. Что-то вроде состояния сеанса на веб-серверах подойдет.

Каковы мои варианты хранения таких данных?

Единственный известный мне метод - это контексты в dbms_sessions:

procedure set_ctx (value in varchar8) as 
begin
    dbms_session.set_context ( 'Test_Ctx', 'AccumulatedValue', value, NULL, 'ProfilerSessionId' );
end set_ctx;

Это работает, но занимает около 50 микросекунд (!) На обновление до накопленного значения.

То, на что я надеюсь, - это способ доступа / хранения массива значений в некоторой памяти Oracle с использованием ванильных операторов PLSQL со временем доступа, типичным для обращений к массивам, сделанным для локальных пакетов.

РЕДАКТИРОВАТЬ (после изучения времени жизни переменных пакета PLSQL):

Существуют ли доступные для PLSQL переменные с временем жизни более длительным, чем "сессии"? Я предполагаю, что такие переменные, вероятно, нуждаются в синхронизации для включения безопасных обновлений от нескольких сеансов. Как ни странно, такие данные о производительности, которые я собираю, не будут сильно повреждены такими сбоями синхронизации, потому что значения данных производительности просто растут монотонно. Ошибка синхронизации просто означала бы, что мы не уловили немного этого прироста стоимости, и я не думаю, что это повредит тому, что я делаю, чтобы это имело значение.

Answer 1

Единственный способ, которым я могу думать об этом, это иметь процесс "слушателя", который постоянно работает и поддерживает данные в памяти.Затем ваши другие процессы будут записывать информацию, связываясь со слушателем, например, через DBMS_PIPE или DBMS_AQ .В документации DBMS_PIPE есть пример процесса прослушивания Pro * C.

Однако у меня есть сомнения относительно того, будет ли это более эффективным для вызывающих программ, чем более простое решение записи информации в таблицу.через автономную транзакцию.

Answer 2

Я не совсем уверен, что вы делаете, но я написал подробный пакет журналирования для PL / SQL, который позволяет отслеживать выполнение через PL / SQL и т. Д. И т. Д., С точностью до миллисекунды.Но для себя, есть возможность войти в память, то есть нет ввода-вывода с использованием коллекции PL / SQL.Другими словами, вы можете войти в буфер и периодически сбрасывать буфер в таблицу.Он доступен от https://sourceforge.net/p/plj-logger/home/ или от http://www.pljumpstart.com/download

. Он имеет дополнительное преимущество, заключающееся в простоте реализации.Единый пакет и вспомогательные столы и т. Д.

Answer 3

Как насчет использования пакета для каждого сеанса с достаточно фиксированным профилем памяти, который вы периодически (каждые N обновлений) сбрасываете в базу данных (для данных «всех сеансов»), а затем сбрасываете.

Если вы можете выполнить вставку, а не обновление, риск блокировки должен быть довольно низким, и тогда вы можете использовать представление или материализованное представление по строкам для получения совокупных итогов.

В качестве альтернативы, если использовать комбинированиечто с помощью подхода DBMS_AQ, который предлагает Тони, вы можете гарантировать защиту от блокировок - помещение сообщения в очередь выполняется быстро, и вы можете связать очередь с обратным вызовом в пакете PLSQL, который выполняется в фоновом потоке Oracle.