2015-04-14 1 views
2

Я ищу лучшее решение для определения того, изменились ли данные в таблице Oracle. Это будет использоваться для запуска вычисления, которое использует множество данных из тех же таблиц. Это будет дорогостоящий опрос всех данных для отслеживания изменений. Изменения происходят редко.Обнаружить, изменились ли данные в таблице Oracle

Я проанализировал следующие проблемы.

  • ORA_ROWSCN: Чтобы замедлить работу, будет выполняться полное сканирование таблицы.
  • Oracle Audit: невозможно настроить в моей среде.
  • DBMS_ALERT: Писатели не могут сигнализировать.

Тогда я придумал следующую простую идею. Добавьте триггер в таблицы, который увеличивает последовательность при вставке, обновлении или удалении. Я знаю, что это будет реализовано, если откатиться, но я могу позволить себе некоторые ложные срабатывания. Служба моих расчетов затем проверяет текущее значение последовательности для обнаружения возможных изменений (= очень дешевый запрос)

CREATE OR REPLACE TRIGGER trg_change_tracker 
     before insert or update or delete on mytable 
declare 
    dummy number; 
begin 
    select seq_event_seqno.nextval into dummy from dual; 
end; 

Как это звучит? Любые подводные камни?

EDIT: Да, есть мэр мэра: когда автор сдерживает фиксацию, и читатель видит новое значение последовательности и запрос изменений до того, как автор зафиксировал.

+0

Я бы, вероятно, рассмотрел использование триггера только для захвата ключа/события и нажатия его в очередь. Таким образом, у вас минимальная логика внутри триггера, а затем вы можете запустить какой-либо другой процесс из очереди после появления элементов. – Ditto

+0

@ Ditton, я сделал то, что вы описали раньше, но это намного меньше. Новые таблицы для создания, переориентации операций на проверенных таблицах, опорожнения таблиц очередей и будьте осторожны, чтобы не удалять события, которые вы не обрабатывали, и т.д. Мне очень нравится получать решение, чтобы определить, изменилась ли таблица (а не то, что изменилось) так быстро насколько это возможно. – Stig

+0

Управление очередью не так уж сложно, если вы находите это сложным, вы не делаете это правильно;) (вы сами не «удаляете» события, вы «деактивируете» их ...), если вы только хочу знать, ЕСЛИ он изменен, а затем просто выбросить в очередь один флаг /. В любом случае, если вы не хотите играть с очередями (я согласен, есть кривая обучения :), но это того стоит) - тогда вы собираетесь (потенциально) потратить такое же количество энергии на некоторые другие «временное» решение в любом случае. – Ditto

ответ

0

Я могу предложить вам некоторое дополнение к вашему спуску: Когда ваш опрос увидит изменения в последовательности, вы можете проверить открытые транзакции на интересующей таблице, если она существует, а затем пропустить текущий recalc.

UPD: Кроме того, вы можете сохранить мин SCN открытых сделок, а также в случае часто таблиц изменений вы не замерзнете

UPD2: Это некоторые эвристического улучшение, не полное решения проблемы. Если вы пропустите повтор каждый раз, когда увидите открытую транзакцию, вы можете заморозить много времени в случае частого (и может быть длинного) DML на таблице. Я имею в виду, что когда seq изменен, и опрос показывает открытые транзакции на вашем столе, вы можете сохранить min(start_scn) из транзакции v $, и когда опрос увидит открытые транзакции в следующий раз, вы можете сравнить текущий min(start_scn) с sotred min(start_scn), если ток больше то это некоторая шанс, что пора пересчитать.

+0

Мне нравится идея. – Stig

+0

Не могли бы вы немного рассказать об использовании SCN? – Stig