|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
Владу Хорсуну. FB 3.0.4 SS Windows x64. При работе с метаданными баз при работающих пользователях натолкнулся на следующую проблему. Иногда, при удалении таблицы или поля (в wait-транзакции), при коммите (из IBExpert) происходит зависание. Завершение транзакций в базе не отрабатывает - в MON$TRANSACTIONS висят ожидающие коммита транзакции. При этом иногда при попытке считать данные из MON$ATTACHMENTS так же происходит зависание. Если выборка из MON$ATTACHMENTS не зависла, то при удалении части/всех подключений оттуда - коммит завершается и можно продолжать работать с базой. При попытке остановить процесс сервера - firebird никак на это не реагирует, помогает только перезагрузка виндовса. Воспроизвести на тестовой базе такой случай не удалось. В следующий раз, когда такое произойдет, достаточно ли будет сделать файл дампа процесса (через диспетчер задач виндовса) или надо что-то другое сделать для диагностики? P.S. Воспроизводимый пример буду стараться сделать в любом случае. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 07:33 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMaxИногда, при удалении таблицы или поля (в wait-транзакции), при коммите (из IBExpert) происходит зависаниеДля wait тр-ций это вполне ожидаемо. CyberMaxЗавершение транзакций в базе не отрабатываетА вот это уже странно. Хотя формулировка утверждения оставляет много вопросов... CyberMaxПри попытке остановить процесс сервера - firebird никак на это не реагирует, помогает только перезагрузка виндовса.А если убить клиента, который делал DDL (IBE) ? CyberMaxВ следующий раз, когда такое произойдет, достаточно ли будет сделать файл дампа процесса (через диспетчер задач виндовса) или надо что-то другое сделать для диагностики?Дамп памяти (полный, full) - это обязательно. Ещё можно сделать дамп лок-таблицы (fb_lock_print -d <database> -a) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 09:06 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
hvladА вот это уже странно. Хотя формулировка утверждения оставляет много вопросов... Я через MON$TRANSACTIONS вижу много запущенных concurrency/RO транзакций, которые при нормальной работе живут очень недолгое время. Тут же видно, что со временем под теми же пользователями появляются новые такие же транзакции, а старые не пропадают. hvladА если убить клиента, который делал DDL (IBE) ? Не помогает. Более того, само подключение не удаляется. Запрос DELETE FROM MON$ATTACHMENTS WHERE ... выполняется, но после обновления подключение остаётся. hvladДамп памяти (полный, full) - это обязательно. Ещё можно сделать дамп лок-таблицы (fb_lock_print -d <database> -a) Принято. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 09:38 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMax, а Force disconnect в IBE пробовал? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 09:42 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
Симонов Денис, Я через диспетчер задачи снимал. Пробовал остановить базу через gfix и shutdown - зависание gfix во время шатдауна. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 09:50 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMaxhvladДамп памяти (полный, full) - это обязательно. Ещё можно сделать дамп лок-таблицы (fb_lock_print -d <database> -a) Принято.Да, ещё - если пользуешься снапшотом (речь ведь о 3.0.4), то нужно сохранять .pdb файлы от него. Без них дамп памяти бесполезен. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 09:53 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
2 hvlad. fb_lock_print -d при зависании: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 10:20 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
Это через 5 минут. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 10:26 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
hvladДа, ещё - если пользуешься снапшотом (речь ведь о 3.0.4), то нужно сохранять .pdb файлы от него. Речь идет только о firebird.pdb, который в корневой папке снапшота? Или нужны еще какие-то pdb? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 10:54 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMax, заголовок лок таблицы тут ничем не поможет. Нужен полный дамп памяти, в первую очередь. И уже потом может понадобиться полное содержимое лок-таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 10:54 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMaxhvladДа, ещё - если пользуешься снапшотом (речь ведь о 3.0.4), то нужно сохранять .pdb файлы от него. Речь идет только о firebird.pdb, который в корневой папке снапшота? Или нужны еще какие-то pdb?Нужны все pdb, которые есть в архиве. Самый "главный" - engine12.pdb ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 10:55 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
hvlad, Написал на почту, которая на sf.net. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 11:36 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
Вижу, что wait тр-ция удаляет таблицу и ждёт EX блокировку на её метаданные. Блокировку эту ей не дают, видимо в других коннектах есть активные (или просто препарированные) запросы к этой таблице. Несколько больше можно было бы сказать с помощью полного дампа лок таблицы. Это всё вполне ожидаемо для wait тр-ции. Советую использовать конечное время ожидания в таких случаях. Вот этогоCyberMaxЗавершение транзакций в базе не отрабатываетне вижу ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 12:18 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
hvladВижу, что wait тр-ция удаляет таблицу и ждёт EX блокировку на её метаданные. Блокировку эту ей не дают, видимо в других коннектах есть активные (или просто препарированные) запросы к этой таблице. Что самое интересное, удаляемая таблица (заканчивается на B2), нигде не используется. Я перед этим делал безусловный DELETE FROM B2 в этом же коннекте и более ничего. hvladВот этогоCyberMaxЗавершение транзакций в базе не отрабатываетне вижу А видно некоторое количества запущенных concurrency\nowait транзакций после старта удаления? И по поводу удаления подключения в таком состоянии - можно ли сделать, чтобы это отрабатывало? hvladСоветую использовать конечное время ожидания в таких случаях. Я напишу Хвастунову. У него при удалении таблицы используются настройки транзакции для работы с метаданными, а там сейчас wait стоит. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 12:36 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMaxЧто самое интересное, удаляемая таблица (заканчивается на B2), нигде не используется.Используется - как минимум в аттаче 15094, дальше не искал CyberMaxА видно некоторое количества запущенных concurrency\nowait транзакций после старта удаления?Мне нужно ещё час ковыряться в дампе, чтобы это найти. Не вижу смысла. CyberMaxИ по поводу удаления подключения в таком состоянии - можно ли сделать, чтобы это отрабатывало?В принципе - можно, на практике - придётся перелопатить кучу кода, который не ожидает неуспешного возврата из ф-ции взятия блокировки и придумать как обрабатывать каждое такое место. Проще (да и лучше) тебе не использовать wait тр-ции с бесконечным ожиданием :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 13:23 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMaxпри удалении таблицы или поля (в wait-транзакции), при коммите (из IBExpert) происходит зависание Ну, удаление таблицы - ещё туда-сюда, но действительно ли нужна эксклюзивная блокировка при удалении поля? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
03.09.2018, 13:42 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovНу, удаление таблицы - ещё туда-сюда, но действительно ли нужна эксклюзивная блокировка при удалении поля? Дмитрий, вы, наверно, не совсем поняли. У IBExpert есть настройка параметров транзакций - для работы с данными, для работы с метаданными и для выполнения скриптов. Настройка для метаданных сделана с wait - чтобы можно было перекомпиливать триггеры/ХП/пакеты на "горячую". И эти же настройки IBExpert'ом применяются при модификации таблицы (в том числе удаления полей и таблицы). Какая там блокировка внутри сервера, эксклюзивная или нет, или еще что, мне как-то неинтересно. Если дроп отрабатывается - ОК, если нет - разбираемся, что пошло нет так, как сейчас. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2018, 01:53 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
Влад, пробую удалить другую таблицу через nowait-транзакцию. Получаю отлуп: DROP TABLE IMP_TABLE; Код: plaintext 1. 2. 3. 4. 5.
Эта таблица 100% не должна никем из пользователей использоваться. Как посмотреть, кто её держит? P.S. Повторный запуск дропа таблицы выдает: Код: plaintext 1. 2. 3. 4. 5. 6.
Это так и должно быть? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2018, 02:39 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
Еще инцидент. Создал сегодня в рабочей базе таблицу LOG по скрипту - с двумя ВК. Через пять минут пытаюсь ее удалить и на те: Код: plaintext 1. 2. 3. 4. 5.
Код: sql 1.
Код: plaintext 1. 2. 3. 4. 5.
Тем временем снова запустил удаление таблицы LOG и забыл закоммитить. Через какое-то время позвонили два пользователя-кассира, у которых при попытке запуска хранимки выдавалось: Код: plaintext 1. 2. 3. 4.
Я подозреваю, что пользователи как-то через зависимости в метаданных добрались до этой таблицы. Но обычно FB позволяет удалить поле, а при попытке обратиться к нему получаешь "column unexpectly deleted". ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2018, 07:22 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
Локализовал последний случай. Пользователь входит в программу. Я в IBExpert создаю таблицу LOG с FK на другую таблицу, используемую в программе. Пользователь делает пару действий в программе через несколько вызовов ХП, после чего я делаю попытку дропнуть FK "ALTER TABLE LOG DROP CONSTRAINT FK_LOG_USER" и получаю "object INDEX "FK_LOG_USER" is in use.". Пользователь выходит из программы, я снова выполняю "ALTER TABLE LOG DROP CONSTRAINT FK_LOG_USER" и на этот раз ВК удаляется. То есть загвоздка в использовании этим пользователем индекса FK, из-за чего ни поле, ни таблица уже не удаляются. Ради теста сделал таблицу с FK, запустил транзакцию с SELECT'ом и попробовал удалить FK в другой транзакции: Код: plaintext 1. 2. 3. 4.
Текст не про lock conflict, а про metadata update. То есть вышеописанный случай - про другое. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2018, 07:46 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMaxпробую удалить другую таблицу через nowait-транзакциюЗачем nowait ? Не надо nowait, ибо будет CyberMax Код: plaintext
CyberMaxЭта таблица 100% не должна никем из пользователей использоваться. Как посмотреть, кто её держит?Напрямую - никак. Можно попробовать заглянуть в MON$STATEMENTS, но косвенное использование (через процедуры, например) так не обнаружить. CyberMaxПовторный запуск дропа таблицы выдает: Код: plaintext 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2018, 08:45 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
CyberMaxТо есть загвоздка в использовании этим пользователем индекса FK, из-за чего ни поле, ни таблица уже не удаляются.А как можно использовать индекс, но при этом не трогать таблицу ? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2018, 08:53 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
hvladЗачем nowait ? Не надо nowait Так если в wait, то сервер зависает. Я тогда что-то не понял. При работе в FB 2.5 я модификацию метаданных всегда делал в nowait-транзакции. FB при коммите сразу же выдавал сообщение об ошибке, если что-то пошло не так. Здесь же из-за особенностей FB3 пришлось это делать в wait-транзакции и получилось, что в случае lock conflict - зависание. Как тогда правильно? hvladЧто такое повторный запуск ? В какой тр-ции ? В IBExpert делаю выполнение этого же запроса (DROP TABLE IMP_TABLE) в этой же транзакции после неудачного предыдущего выполнения. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2018, 09:09 |
|
Зависание FB при удалении таблицы/поля
|
|||
---|---|---|---|
#18+
hvladА как можно использовать индекс, но при этом не трогать таблицу ? :) Конечно, тут одно из другого вытекает. Вопрос в том - кем и зачем индекс этот используется? Ведь если это поле используется в каком-то запросе, то сообщение об ошибке другое - без lock conflict. Меня этот LC очень смущает. Ведь это означает, что есть какая-то конкурирующая транзакция. И я хочу выяснить, какая. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.09.2018, 09:17 |
|
|
start [/forum/topic.php?fid=40&msg=39696971&tid=1560994]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
63ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
others: | 310ms |
total: | 486ms |
0 / 0 |