Транзакция RC REC_VERSION WAIT

1. Удаляю констрейнт (ПК) - isc_dsql_execute,
2. Делаю isc_commit_transaction - и на ее вызове происходит зависание.

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

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

База 13 гиг, в таблице - 100 записей, ПК составной из 2 полей SMALLINT+INTEGER.
База новая, после рестора.

Есть какие идеи, народ? Может ошибка была похожая..

Добавлю.

Пока сервер висит - диск не грузится вообще (0% всегда),
Проц процессом firebird.exe грузится иногда на 3-10% (раз в несколько секунд), а так тоже 0%.

В логе нет ничего (появляется только обрыв соединения после того, как я свою прогу снимаю).

hvladYuRock,

скорее всего, ждёт пока все запросы к таблице завершатся.
Новые запросы блокируются.

Я завершаю все.

Я даже реконнект к бд делал навсякий (перед drop) - не помогло.

P.S. Попробовал с no_wait - то же самое.

YuRockЯ завершаю всеВ мониторинге ничего нет (да и взяться неоткуда).

hvladВоспроизводишь стабильно ?

Сделай fb_lock_print -n -o -l -d <файл БД> во время такого зависания и покажи.

Или давай пример.Воспроизводится всегда, да.
Завтра попробую, спасибо, уже домой уехал.

С примером, боюсь, будут проблемы:
1. Воспроизводится не на всех базах, а эта - большая;
2. Через IBE вообще воспроизвести не могу.

Мимопроходящийэто как раз тот случай с WAIT, когда удаление из MON$ATTACHEMENT совершенно безрезультатно.Я уже писал, что с nowait то же самое.

Кстати, удалось повторить зависание на IBExpert. Достаточно запустить мою прогу и выполнить скрипт
DROP;
COMMIT; --тут зависнет.

Таки какие-то запросы не нравятся, которые висят подготовленными. Их штук 10, но среди них нет ни одного, использующего эту таблицу. FK тоже нет.

hvladСделай fb_lock_print
Unable to access lock table.
File for mapping is empty.

YuRockFile for mappingFor memory mapping

Приходится переписывать с экрана, т.к. скруль работает только с телефона почему-то...

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

И повторяется, к сожалению, не на всех базах.

hvladНе прямые зависимости ? Триггеры\процедуры ?есть одна процедура. Она вызываласть, но стейтмент, ее вызывавший, уничтожен.


hvladКак запускаешь fb_lock_print ?Ровно как ты написал, путь к файлу только указал

hvladYuRockесть одна процедура. Она вызываласть, но стейтмент, ее вызывавший, уничтожен.Сама процедура в кеше метаданных осталасьЯ уже попробовсл ее дропнуть перед удплением пк. М коммитом между этими операциями, конечно.

Процедура дропается, коммитится успешно, дальше ничего не меняется - зависон на еоммите после удаления ПК.

hvladYuRockпропущено...
Ровно как ты написал, путь к файлу только указалПуть к файлу БД ?
Там виртуализация ФС не порылась ?
Путь к файлу бд.
D:\folder\db.gdb

Виртуализация на этом диске не роется.

hvladНу тогда снимай полный дамп памяти и выкладывай для изучения.
Хотя пример, конечно, лучше :)Я пытался воспроизвести и сделать пример, не удалось.

Вот ссылка на дамп "висящего" сервера.
https://1drv.ms/u/s!Ag8PxwKHNcBVopluufc-lMWV5L1k2A

32 бит

hvlad,

Да, дело в этой процедуре. Повторяется легко на двух IBE.
В 1-м заходим в базу, вызываем эту процедуру, commit (но от базы не отсоединяемся);
Во 2-м - дропаем пк, commit - и зависон. Что интересно, если пока висит 2-й в 1-м дисконнектиться, то 2-й развиснет, коммит завершится без ошибок.

Странно, почему тогда мне реконнект не помог.

YuRockСтранно, почему тогда мне реконнект не помогА, не странно. Я скрипты, блин, в другом коннекшене выполняю, чем тот, где процедура вызывалась((

hvladВисит именно там, где я и предполагал - при попытке взять лок индекса.
Имя индекса PK_MPOSTOSAP$REGIONS
Имени таблицы нет, есть только её ID - 132

Тр-ция - READ COMMITTED, RECORD_VERSION, WAIT
её номер 2292570Имя таблицы такое же, как и у индекса PK (только без префикса PK_).

Странно, что этот индекс лочится чз эту процедуру, но не разлочивается. Ведь стейтмент я уничтожил, как и транзакцию, в котором его запускал.

hvladКонкрентно этого зависания можно избежать, если не использовать WAIT тр-цию.Влад, я уже пробовал, 3-й раз это пишу. То же самое.

hvladЯ это читал :) Но - в дампе я вижу WAIT.
Сделаешь с NOWAIT - могу глянуть, может там в другом месте проблемаПрикол в том, что если сделать транзакцию, в которой запускаешь процедуру, nowait - то да, это помогает.
А транзакция, которая индекс удаляет - не важно, какая.
Мне это очень сложно объяснить. Какой-то позор. Я не понимаю, какая разница, какой была та транзакция, если она уже завершена.

YuRockhvladКонкрентно этого зависания можно избежать, если не использовать WAIT тр-цию.Влад, я уже пробовал, 3-й раз это пишу. То же самое.Оказалось, что это ложь. Я запутался.

С NOWAIT выдает object PK_MPOSTOSAP$REGIONS is in use.

Но опять непонятно.

Если в IBE, который лочит индекс, сделать NOWAIT-транзакцию - то потом всё работает и не виснет.

У меня же - не важно, какая транзакция, которая лочит - в результате либо зависон либо object is in use (завасит от WAIT/NOWAIT транзакции, которая удаляет индекс).

hvladЭто - правильно.
Ну и что делать-то?

hvladТы - можешь попробовать реконнект, должен помочь.
Мда, это поможет, только для этого придется делать реконнект другого(их) коннекшена(ов)

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

hvladС другой стороны - если ты не дропнешь этот индекс - всё пропало ? (ц)
Делай тр-цию с таймаутом, обрабатывай\игнорируй ошибку удаления индекса..
Да, всё пропало. Я ж его не просто так дропаю, а чтоб пересоздать. Ключ в индекс добавляю.

В общем, спасибо, проблема решена реконнектом. И так уже пол суток ушло.