Dimitry Sibiryakov,

Сейчас посмотрел код. Для ODBC, через который происходит работа с FB, стоит:


Но у меня сейчас начинают закрадываться сомнения, что Odbc-драйвер в действительности ставит уровень Serializable...
Ну и на самом деле мне бы хватило за глаза Repeatable read )) Сейчас уже не вспомню зачем он мне понадобился

Если верить исходнику ODBC-драйвера, то для SQL_TXN_SERIALIZABLE он выставляет isc_tpb_consistency перед запуском транзакции

Это могло вызывать вышеуказанные у меня (не у nimarufa) эффекты?

Всё, вспомнил почему там стоит SQL_TXN_SERIALIZABLE. Он был оставлен так около 10-ти лет назад т.к. когда всё это писалось, выяснилось, что ODBC-драйвер для любой константы устанавливал уровень Read Commited. Я тогда не стал заводить Issue, т.к. нашёл уже заведённый, а потом вся эта фигня была успешно забыта )))
Сейчас проверил, MON$ISOLATION_MODE показывает 2 (2 - read committed record version из https://firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref-appx05-transacs.html), т.е. баг так и остался.
Так что реальный уровень транзакций - read committed record version.

Наверное нафик надо выбросить использование ODBC для FB. Тем более что для других СУБД, с которыми работает система, написаны коннекторы через родное API. Но это так уже к слову пришлось. И в данной теме это оффтопик ))

1) нет (а надо?)
2) супер
3) deadlock при select конкретно в этом ПО вижу за всё время в первый раз. Правда, один раз было в другом ПО (которое писал для другого работодателя) что при пересчёте статистики индекса выскочил deadlock, который затем вылазил при любом запросе на всех клиентах. Вылечилось перезапуском FB. Писал об этом тут: https://www.sql.ru/forum/1251138/
Но сегодня deadlock выскакивал не на всех запросах. Часть просто дико тормозило. Встроенный в ПО профайлер выдавал в лог, что длительность выполнения запросов и последующего коммита, могло достигать часа.

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

hvlad,
В этот раз я просто проверил скорость диска (т.к. жалобы были именно на дикие тормоза). Так вот, скорость последовательного чтения - менее 3 Мб/сек (до проверки скорости случайного доступа дело даже не дошло). При этом диск не загружен ничем другим. Сисадмин пока не может разобраться в чём именно дело. Так что ему сейчас особо не до запуска трейса. Он что-то там копает в настройках виртуализации.
Кстати, возможно вчера и на прошлой недели тоже были резкие проседания в скорости диска. Это как-то могло вызвать проблему?

kdv,
gfix -list в скрипте сборки мусора вызываться до и после sweep, чтобы видать насколько хорошо этот sweep отработал.

PS: в прошлый раз я поехал туда не подготовленным, т.к. мне вообще не сказали в чём проблема. Наша система большая. База данных - это только небольшая часть системы. Не думал вообще, что ей придётся заниматься. Так что пришлось довольствоваться теми готовыми bat-скриптами для сисадмина, которые были в наличии.

насчёт DDL не понял.

И всё-таки повторю вопрос. В каких случаях возможен ответ сервера "deadlock" при простейших select-запросах? Можно что у нас надо подкрутить?

hvlad,

Ступил. Конкретно gfix -list подсмотрел в какой-то рекомендации, уведенной в инете ))))
Я так понимаю, оно особо там не нужно?

DmSer,

К сожалению, нормально поладить с сиадмином не получается. Всё что удалось выяснить, я выкладываю тут.

Мимопроходящий,

Он мне сегодня сказал это прямо дословно, только добавил слово "полное" перед "говно" ))) Но это уже оффтоп пошёл. В общем, в данной организации нам не повезло с сисадмином. Но проблему решить надо в любом случае.

Я готов согласиться даже на то, что наше ПО - трижды говно, лишь бы выяснить в чём проблема и справить ситуацию )