Не разрешать операции DML во время пакетов exec

Question

Не разрешать операции DML во время пакетов exec

1

Мне нужна небольшая помощь здесь, потому что я немного борюсь, чтобы найти лучшее решение для своей проблемы. я googled и не имею никакого просвечивающего ответа.

Поэтому, в первую очередь, я объясню эту идею.

1 - У меня есть приложение Java, которое вставляет данные в мою базу данных (Oracle DB) с помощью jdbc.

2 - Моя база данных логически разделена на две части. Одна часть, которая содержит таблицу с экспортированной информацией (из другого приложения) и другую часть с таблицей, представляющей некоторые отчеты.

3 - мое приложение java только вставляет информацию в таблицу экспорта.

4 - Я разработал несколько пакетов, которые преобразуют данные из таблицы экспорта в таблицу отчетов (генерируют некоторые отчеты).

5 - Эти пакеты планируется выполнить 2, 3 раза в день

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

я в двух подходах:

1 - во время преобразования отклоняйте операторы DML во временную таблицу

2 - заблокируйте таблицы, но у меня не так много опыта использования этого. Мой главный вопрос: могу ли я заставить операции DML в jdbc ждать завершения блокировки? Еще не пробовал, но читал здесь и там, что после того, как кто-то выбросил исключение lockwaittimeout или что-то в этом роде.

Может ли кто-нибудь более опытный дать мне несколько советов?

Любые сомнения в том, что я пытаюсь сделать, просто спросить.

andrealmeida 27 фев. 2015, в 17:48

Источник

Теги:

java

plsql

oracle

jdbc

1 ответ

Ещё вопросы

kevinsky · Accepted Answer · 2015-02-27T14-09-00.000Z

Не пытайтесь блокировать таблицы в качестве решения. К сожалению, это распространено, но редко необходимо. Всего несколько идей:

в начале преобразования выберите * данные из таблицы экспорта в таблицу global_temp. Затем выполните ваши пакеты преобразования на этой временной таблице
создайте материализованное представление, например, выберите * данные из таблицы экспорта. Изучите параметры обновления для фиксации, но вам кажется, что вам нужно обновить таблицу непосредственно перед преобразованием
проанализируйте экспортированные данные. Если это похоже на многие другие случаи, большинство данных никогда не будут меняться после импорта. Необходимо анализировать только новые данные. Чтобы помочь в обработке, добавьте поле метки времени date_last_modified и триггер в таблице. Когда строка обновляется, обновите date_last_modified. Это позволяет вам выбрать наименьший набор данных, который возможен только для "только измененных записей",
вы также должны исследовать использование массивного сбора для оптимизации вашего курсора. Это позволит вам сразу получить группу записей, например, моментальный снимок данных в определенный момент времени
Я верю, что ты передумал. Если вы получаете группу записей по одному, то Oracle будет получать состояние записи с последней фиксации любым пользователем. Если вы наварите коллекцию группы записей, они войдут в память и снова будут представлять состояние по состоянию момента.

Лучший способ почувствовать себя более комфортно - это создать тестовый пример. Настройте курсор, который спит в течение каждого цикла обработки. Откройте другой сеанс и измените данные, которые обрабатываются. Посмотрите, что произойдет....

Я изучу ваши предложения. Спасибо ;)
Использование массового сбора кажется подходящим способом. Спасибо за помощь