Добрый день!

Разбираюсь со странным поведением процедуры: в целевой таблице появляются загруженные в разное время одинаковые строки, хотя в процедуру включен правильно работающий механизм обработки такой ситуации.
Пробовал повторно вставлять строку, повторяющую дублирующиеся - отсеилась.
В связи с этим имею два вопроса-версии, буду благодарен за советы и комментарии:

1) Первый запуск процедуры, вставивший данные, упал из-за нехватки места в табличном пространстве, к которому относится целевая таблица.
Подскажите могла ли возникнуть ситуация, при котором insert выполнился после того, как место освободилось?

2) В v$sql есть подозрительный delete из целевой таблицы, с давнишним first_load_time и периодически обновляемым last_active_time


Результат:
2018-10-19/17:37:35 || 2018-11-20/12:29:38 || 2018-11-20 15:39:30 || DELETE /*+ no_index(a) */ FROM ACCOUNT a WHERE ROWID IN (SELECT DEL_ROWID FROM ORAWORK.SRV_DEL)

при этом джоин с v$session ничего не возвращает



Возможна ли здесь блокировка или наличие запроса в v$sql, при отсутствии связанной сессии в v$session, не говорит о том, что над таблицей выполняется действие?

SY,
этот вариант связан с вопросом №1. Возможно ли, что упавшая из-за нехватки табличного пространства процедура (а это явно в момент insert) после устранения завершила свою работу и выполнила коммит (он выполняется в конце)? Между упавшим запуском и второй ошибочной вставкой запусков не было

SY
Ситуация на которую я намекал: Сессия 1 проверяет есть ли такая запись в таблице, получает "такой записи нет" и делает вставку. До того как сессия 1 выполняет commit, сессия 2 также проверяет есть ли такая запись в таблице, получает "такой записи нет" и делает вставку. В результате 2 "таких записи".

Ну и откуда мы можем знать что делает твоя процедура при возникновении исключения? Да и дошло ли исключение "нехваткa места в табличном пространстве" до процедуры? Может у тебя задействован resumable и место добавили до истечения resumable_timeout? Тогдa да, этот вариант можем быть связан с вопросом №1 и c cитуацией на которую я намекал.

SY.

Первый запуск упал через 30 секунд после старта, второй запуск произошел спустя 6 часов. show parametrer resumable_timeout возвращает 0.

По поводу отношения "нехватки места в табличном пространстве" именно к процедуре - скорее всего касается оно именно ее, так как параллельно успешно отработали процессы, вставляющие данные в этот же tablespase

-2-baza906наличие запроса в v$sql, при отсутствии связанной сессии в v$sessionЭто статистически более чем частая ситуация.

может быть, тогда вы сталкивались с проблемой, как такой запрос (есть в v$sql, но нет в v$session) можно "убить"?

-2-,
что бы остановить сессию, есть комманда kill, но в моей ситуации идентификатор сессии я получить не могу. Если предположить, что запрос из v$sql все-таки работает, то какой аналог kill для него подойдет?

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

EvgeniaMakarovabaza906,
получается вроде бы не вставил так как места нет, а потом выходит что вставил.
Как будто бы перезапускается процедура заново при ошибке.

вот и мне похоже на какие-то действия после падения.

по вопросам:
1) Текст выполняемого запроса сохраняется в логи и выполняется commit
2) Б.д. проектировал не я, возможно действительно есть смысл создать ключ
3) Нет, только сообщение, на каком этапе возникла ошибка. В нашем случае - при выполнении процедуры.

EvgeniaMakarova,
коммит без открытия новой транзакции.

EvgeniaMakarova,
спасибо большое вам. оберну логирование в отдельную транзакцию и посмотрю на поведение процедуры