Транзакция 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-й развиснет, коммит завершится без ошибок.

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