Есть некая чужая процедура Оракл
Приходится ее вызывать иногда
со стороны фоксовой процедуры
Процедура эта иногда работает
бог знает сколько
Сегодня так вышло, что два разных модуля
вызвали ее одновременно
Вернее , второй вызвал тогда,
когда первый еще не отработал
Итог, висяк екзешника на сервере ,
где я его даже и сорвать не могу
С авторами уже говорили по этому поводу
несколько раз, без толку
Чтобы такое придумать,
чтобы такого не было
Асинхронный вызов процедуры, тоже не вариант,
фокс это отпустит, но на стороне Оракл
так все и будет висеть

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

Есть у меня блокировки семафора на стороне
фокса. Это не помогает
Зашел в фокс, заблокировал семафор.
Дошло в коде до процедуры,
вызвали ее. Ждем пождем.
Запустили другую сессию
Семафор занят. Сидим на колесике, ждем.

Володь, надо смотреть блокировки и ожидания на сервере, там может быть банальное ожидание ресурса или даже deadlock.

Ну и тюнинг провести не мешает, если ХП так долго работает, может ей статистики или индексов не хватает.





Исправлено 1 раз(а). Последнее : PaulWist, 09.12.20 19:03

да и так понятно.
Оракловая процедура сама себе устраивает клинч
Исправлять не хотят.

Ну если имеешь доступ к Ораклу придется самому тюнинг наводить, ведь твоя прога не работает, проходили, знаем

boba
Исправлять не хотят.

Встречался с таким.
Разрабы чужой БД, упорно не желали признавать своей неправоты.
Пришлось написать 2 теста.
1. Фиктивную процедуру, которая возвращала фиктивные данные, но мгновенно.
Этим убедил в работоспособности моего ПО.
2. На общепризнанном языке (в моем случае на шарпе)
организовал вызов ХП по кнопке, доказал что тормоз невозможный.

В итоге все поправили, и поблагодарили.
Может так попробовать?

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

boba
Был грех еще до удаленки хотел аж по роже одному дать.

Не надо "душить прекрасные порывы".

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

А что в Оракле нет аналога sp_getapplock ?

Там ещё гибче. Select ... for update ... nowait.

pasha_usue
Там ещё гибче. Select ... for update ... nowait.

И что делает эта конструкция - устанавливает U блокировку на записи/ключи/схему ?

А если включен TIL SNAPSHOT или RCSI (думаю в Оракле есть аналоги), тогда как?





Исправлено 2 раз(а). Последнее : PaulWist, 10.12.20 23:17

По хорошему процедура не должна сама себя блокировать при параллельных запусках, и уж тем более доводить дело до дедлока. Она лишь может проделать ненужный объём работы (два раза что-то просчитать, например).

Не стоит и "принудительно" её блокировать - это явный костыль. Хотя если уж "очень хочется", то такие средства есть - пакет DBMS_LOCK.

select for update - ну у него есть своя (ограниченная) сфера применения. Прям вот везде пихать это не стоит, как и более жёсткие LOCK TABLE. Равно как и переключение режима транзакций в serializable - где-то оно нужно, но для применения этого режима надо иметь веские основания.

Какого рода рекомендация ожидается в ситуации "это я не могу править" - ну мне как-то не понятно... Раскритиковать других товарищей и пожаловаться на свою долю - так это непродуктивно И как обычно - организационные вопросы НЕ решаются програмными путями.

Да, можно клиентскими блокировками избежать двойного запуска ХП - при этом методы синхронизации вовсе не обязаны быть "до победы" - попробовал захватить мьютекс/семафор в течении 1 секунды - не вышло - написал юзеру что "извини, кто-то считает", и ничего не блокируя вышел из соответствующей формы/процедуры запуска, пусть чем-то другим в проге юзер занимается. Для работы с разных машин, конечно, никакие мьютексы/семафоры не годятся...

Игорь, причем тут жалобы
Я работаю не для своей кухни.
Некоторые запуски упомянутой процедуры
идут в модуле на фоксе по расписанию на сервере
Я там программу не могу выкинуть, приходится просить
админа. В фоксе у меня есть светофоры, которые препятствуют
повторной работе самого этого блока.
Но это не помогает.
Вот сегодня, сели сама работа на фоксе заняла
полторы минуты, два вызова процедуры Оракл
800 секунд.
Два дня назад процедуру запустили вне фоксового модуля,
попало как раз в тот момент, когда фоксовый модуль работал
по расписанию на сервере. Там процедура сама себя заблокировала и повесила
работу по расписанию на 5 часов. Пришлось просить админа
ее срывать. Я совершенно договоро способен. Всегда быстро
принимаю чужие решения и быстро их реализую
У меня тут нет никаких собственных интересов.
Вы говорите, процедура не должна сама себя блокировать,
а она блокирует.
В той схеме, где она сидит, у меня прав на редакцию нет,
только на вызов. И что тут по вашей теории делать.
Я не жаловался, а описывал ситуацию,
когда ты сам ничего поделать не можешь, а летит у тебя.
Это рабочий модуль, который должен работать как часы.
Но уже три раза валился на несколько часов.
Народ ждет данные со стороны Оракл, а их там нет.
Я оказываюсь виноватым.
Да, есть способы лучше, чем select for update
Теперь вопрос, сколько времени нужно автору процедуры,
чтобы вставить в нее эти пару строчек, ну пять
Думаю, с питьем чая минут 10 максимум.
А проблеме почти год.
У меня то прав на редакцию нет.
Есть другой Оракл с другой задачей, авторы ушли без возврата
Там была похожая ситуация.
Я поступил просто, взял запрос текста сессии,
если там видел нечто работающее,
что запускать нельзя, то не давал запустит.
Понятно, что способ через задницу, но работает.
Но в той задаче, о которой речь, у меня и на запрос сессии прав нет.



Исправлено 1 раз(а). Последнее : boba, 11.12.20 10:03

boba
Вы говорите, процедура не должна сама себя блокировать,
а она блокирует.
В той схеме, где она сидит, у меня прав на редакцию нет,
только на вызов. И что тут по вашей теории делать.

Выписать задачу по исправлению такого поведения авторам или тем у кого есть права. Мне кажется это логично и правильно.
Хорошо бы приложить пример воспроизводящий проблему. Даже текстового описания вида "запустить процедуру в одной сессии sql developer, запустить её же во второй сессии - в результате процедура блокируется и не завершается в течении как минимум 5 часов" будет достаточно.

авторы все прекрасно знают.