Гость
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Зависание FB при удалении таблицы/поля / 25 сообщений из 47, страница 1 из 2
03.09.2018, 07:33
    #39696971
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
Владу Хорсуну.
FB 3.0.4 SS Windows x64.
При работе с метаданными баз при работающих пользователях натолкнулся на следующую проблему. Иногда, при удалении таблицы или поля (в wait-транзакции), при коммите (из IBExpert) происходит зависание. Завершение транзакций в базе не отрабатывает - в MON$TRANSACTIONS висят ожидающие коммита транзакции. При этом иногда при попытке считать данные из MON$ATTACHMENTS так же происходит зависание. Если выборка из MON$ATTACHMENTS не зависла, то при удалении части/всех подключений оттуда - коммит завершается и можно продолжать работать с базой.
При попытке остановить процесс сервера - firebird никак на это не реагирует, помогает только перезагрузка виндовса.
Воспроизвести на тестовой базе такой случай не удалось.

В следующий раз, когда такое произойдет, достаточно ли будет сделать файл дампа процесса (через диспетчер задач виндовса) или надо что-то другое сделать для диагностики?
P.S. Воспроизводимый пример буду стараться сделать в любом случае.
...
Рейтинг: 0 / 0
03.09.2018, 09:06
    #39696994
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMaxИногда, при удалении таблицы или поля (в wait-транзакции), при коммите (из IBExpert) происходит зависаниеДля wait тр-ций это вполне ожидаемо.

CyberMaxЗавершение транзакций в базе не отрабатываетА вот это уже странно. Хотя формулировка утверждения оставляет много вопросов...

CyberMaxПри попытке остановить процесс сервера - firebird никак на это не реагирует, помогает только перезагрузка виндовса.А если убить клиента, который делал DDL (IBE) ?

CyberMaxВ следующий раз, когда такое произойдет, достаточно ли будет сделать файл дампа процесса (через диспетчер задач виндовса) или надо что-то другое сделать для диагностики?Дамп памяти (полный, full) - это обязательно. Ещё можно сделать дамп лок-таблицы (fb_lock_print -d <database> -a)
...
Рейтинг: 0 / 0
03.09.2018, 09:38
    #39697010
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
hvladА вот это уже странно. Хотя формулировка утверждения оставляет много вопросов...
Я через MON$TRANSACTIONS вижу много запущенных concurrency/RO транзакций, которые при нормальной работе живут очень недолгое время. Тут же видно, что со временем под теми же пользователями появляются новые такие же транзакции, а старые не пропадают.

hvladА если убить клиента, который делал DDL (IBE) ?
Не помогает. Более того, само подключение не удаляется. Запрос DELETE FROM MON$ATTACHMENTS WHERE ... выполняется, но после обновления подключение остаётся.

hvladДамп памяти (полный, full) - это обязательно. Ещё можно сделать дамп лок-таблицы (fb_lock_print -d <database> -a)
Принято.
...
Рейтинг: 0 / 0
03.09.2018, 09:42
    #39697013
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMax,

а Force disconnect в IBE пробовал?
...
Рейтинг: 0 / 0
03.09.2018, 09:50
    #39697015
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
Симонов Денис,

Я через диспетчер задачи снимал.
Пробовал остановить базу через gfix и shutdown - зависание gfix во время шатдауна.
...
Рейтинг: 0 / 0
03.09.2018, 09:53
    #39697016
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMaxhvladДамп памяти (полный, full) - это обязательно. Ещё можно сделать дамп лок-таблицы (fb_lock_print -d <database> -a)
Принято.Да, ещё - если пользуешься снапшотом (речь ведь о 3.0.4), то нужно сохранять .pdb файлы от него.
Без них дамп памяти бесполезен.
...
Рейтинг: 0 / 0
03.09.2018, 10:20
    #39697036
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
2 hvlad. fb_lock_print -d при зависании:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
LOCK_HEADER BLOCK
        Version: 146, Creation timestamp: 2018-09-03 10:43:55
        Active owner:      0, Length: 12582912, Used: 11873256
        Enqs: 28435363, Converts:   1497, Rejects:   4176, Blocks:    847
        Deadlock scans:      4, Deadlocks:      0, Scan interval:  10
        Acquires: 56834109, Acquire blocks: 120864, Spin count:   0
        Mutex wait: 0.2%
        Hash slots: 30011, Hash lengths (min/avg/max):    0/   0/   7
        Remove node:      0, Insert queue:      0, Insert prior:      0
        Owners (27):    forward: 252888, backward: 10746168
        Free owners (32):       forward: 1050960, backward: 11091200
        Free locks (968):       forward: 253456, backward: 11865960
        Free requests (92017):  forward: 10122528, backward: 6883072
...
Рейтинг: 0 / 0
03.09.2018, 10:26
    #39697041
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
Это через 5 минут.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
LOCK_HEADER BLOCK
        Version: 146, Creation timestamp: 2018-09-03 10:43:55
        Active owner:      0, Length: 12582912, Used: 11873256
        Enqs: 28461213, Converts:   1761, Rejects:   7072, Blocks:    901
        Deadlock scans:     30, Deadlocks:      0, Scan interval:  10
        Acquires: 56879043, Acquire blocks: 120867, Spin count:   0
        Mutex wait: 0.2%
        Hash slots: 30011, Hash lengths (min/avg/max):    0/   0/   7
        Remove node:      0, Insert queue:      0, Insert prior:      0
        Owners (38):    forward: 252888, backward: 9613576
        Free owners (21):       forward: 9843984, backward: 4105112
        Free locks (1005):      forward: 11868720, backward: 11866344
        Free requests (87311):  forward: 2092944, backward: 10230136
...
Рейтинг: 0 / 0
03.09.2018, 10:54
    #39697059
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
hvladДа, ещё - если пользуешься снапшотом (речь ведь о 3.0.4), то нужно сохранять .pdb файлы от него.
Речь идет только о firebird.pdb, который в корневой папке снапшота? Или нужны еще какие-то pdb?
...
Рейтинг: 0 / 0
03.09.2018, 10:54
    #39697060
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMax,

заголовок лок таблицы тут ничем не поможет.
Нужен полный дамп памяти, в первую очередь.
И уже потом может понадобиться полное содержимое лок-таблицы.
...
Рейтинг: 0 / 0
03.09.2018, 10:55
    #39697061
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMaxhvladДа, ещё - если пользуешься снапшотом (речь ведь о 3.0.4), то нужно сохранять .pdb файлы от него.
Речь идет только о firebird.pdb, который в корневой папке снапшота? Или нужны еще какие-то pdb?Нужны все pdb, которые есть в архиве. Самый "главный" - engine12.pdb
...
Рейтинг: 0 / 0
03.09.2018, 11:36
    #39697083
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
hvlad,

Написал на почту, которая на sf.net.
...
Рейтинг: 0 / 0
03.09.2018, 12:18
    #39697102
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
Вижу, что wait тр-ция удаляет таблицу и ждёт EX блокировку на её метаданные.
Блокировку эту ей не дают, видимо в других коннектах есть активные (или просто препарированные) запросы к этой таблице.
Несколько больше можно было бы сказать с помощью полного дампа лок таблицы.
Это всё вполне ожидаемо для wait тр-ции. Советую использовать конечное время ожидания в таких случаях.

Вот этогоCyberMaxЗавершение транзакций в базе не отрабатываетне вижу
...
Рейтинг: 0 / 0
03.09.2018, 12:36
    #39697116
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
hvladВижу, что wait тр-ция удаляет таблицу и ждёт EX блокировку на её метаданные.
Блокировку эту ей не дают, видимо в других коннектах есть активные (или просто препарированные) запросы к этой таблице.
Что самое интересное, удаляемая таблица (заканчивается на B2), нигде не используется. Я перед этим делал безусловный DELETE FROM B2 в этом же коннекте и более ничего.

hvladВот этогоCyberMaxЗавершение транзакций в базе не отрабатываетне вижу
А видно некоторое количества запущенных concurrency\nowait транзакций после старта удаления?

И по поводу удаления подключения в таком состоянии - можно ли сделать, чтобы это отрабатывало?

hvladСоветую использовать конечное время ожидания в таких случаях.
Я напишу Хвастунову. У него при удалении таблицы используются настройки транзакции для работы с метаданными, а там сейчас wait стоит.
...
Рейтинг: 0 / 0
03.09.2018, 13:23
    #39697151
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMaxЧто самое интересное, удаляемая таблица (заканчивается на B2), нигде не используется.Используется - как минимум в аттаче 15094, дальше не искал

CyberMaxА видно некоторое количества запущенных concurrency\nowait транзакций после старта удаления?Мне нужно ещё час ковыряться в дампе, чтобы это найти. Не вижу смысла.

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

Проще (да и лучше) тебе не использовать wait тр-ции с бесконечным ожиданием :)
...
Рейтинг: 0 / 0
03.09.2018, 13:42
    #39697175
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMaxпри удалении таблицы или поля (в wait-транзакции), при коммите (из IBExpert) происходит
зависание

Ну, удаление таблицы - ещё туда-сюда, но действительно ли нужна эксклюзивная блокировка
при удалении поля?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.09.2018, 01:53
    #39697467
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
Dimitry SibiryakovНу, удаление таблицы - ещё туда-сюда, но действительно ли нужна эксклюзивная блокировка
при удалении поля?
Дмитрий, вы, наверно, не совсем поняли. У IBExpert есть настройка параметров транзакций - для работы с данными, для работы с метаданными и для выполнения скриптов. Настройка для метаданных сделана с wait - чтобы можно было перекомпиливать триггеры/ХП/пакеты на "горячую". И эти же настройки IBExpert'ом применяются при модификации таблицы (в том числе удаления полей и таблицы). Какая там блокировка внутри сервера, эксклюзивная или нет, или еще что, мне как-то неинтересно. Если дроп отрабатывается - ОК, если нет - разбираемся, что пошло нет так, как сейчас.
...
Рейтинг: 0 / 0
04.09.2018, 02:39
    #39697471
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
Влад, пробую удалить другую таблицу через nowait-транзакцию. Получаю отлуп:
DROP TABLE IMP_TABLE;

Код: plaintext
1.
2.
3.
4.
5.
Невозможно подтвердить транзакцию:
Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
lock conflict on no wait transaction.
unsuccessful metadata update.
object TABLE "IMP_TABLE" is in use.

Эта таблица 100% не должна никем из пользователей использоваться. Как посмотреть, кто её держит?

P.S. Повторный запуск дропа таблицы выдает:
Код: plaintext
1.
2.
3.
4.
5.
6.
This operation is not defined for system tables.
unsuccessful metadata update.
DROP TABLE IMP_TABLE failed.
SQL error code = -607.
Invalid command.
Table IMP_TABLE does not exist.

Это так и должно быть?
...
Рейтинг: 0 / 0
04.09.2018, 07:22
    #39697503
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
Еще инцидент. Создал сегодня в рабочей базе таблицу LOG по скрипту - с двумя ВК. Через пять минут пытаюсь ее удалить и на те:
Код: plaintext
1.
2.
3.
4.
5.
Невозможно подтвердить транзакцию:
Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
lock conflict on no wait transaction.
unsuccessful metadata update.
object TABLE "LOG" is in use.
Пробую удалить ВК. Один удалился (на свежесозданную таблицу), второй не хочет:
Код: sql
1.
ALTER TABLE LOG DROP CONSTRAINT FK_LOG_USER


Код: plaintext
1.
2.
3.
4.
5.
Невозможно подтвердить транзакцию:
Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
lock conflict on no wait transaction.
unsuccessful metadata update.
object INDEX "FK_LOG_USER" is in use.
Само поле не удаляется с таким же сообщением.

Тем временем снова запустил удаление таблицы LOG и забыл закоммитить. Через какое-то время позвонили два пользователя-кассира, у которых при попытке запуска хранимки выдавалось:
Код: plaintext
1.
2.
3.
4.
FormMain:
Table  is not defined.
SQL error state =42S02
Table LOG is not defined.

Я подозреваю, что пользователи как-то через зависимости в метаданных добрались до этой таблицы. Но обычно FB позволяет удалить поле, а при попытке обратиться к нему получаешь "column unexpectly deleted".
...
Рейтинг: 0 / 0
04.09.2018, 07:46
    #39697510
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
Локализовал последний случай.
Пользователь входит в программу. Я в 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.
Невозможно подтвердить транзакцию:
This operation is not defined for system tables.
unsuccessful metadata update.
object INDEX "FK_TEST_1" is in use.

Текст не про lock conflict, а про metadata update. То есть вышеописанный случай - про другое.
...
Рейтинг: 0 / 0
04.09.2018, 08:45
    #39697539
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMaxпробую удалить другую таблицу через nowait-транзакциюЗачем nowait ? Не надо nowait, ибо будет
CyberMax
Код: plaintext
lock conflict on no wait transaction.

CyberMaxЭта таблица 100% не должна никем из пользователей использоваться. Как посмотреть, кто её держит?Напрямую - никак. Можно попробовать заглянуть в MON$STATEMENTS, но косвенное использование (через процедуры, например) так не обнаружить.
CyberMaxПовторный запуск дропа таблицы выдает:
Код: plaintext
1.
2.
3.
4.
5.
This operation is not defined for system tables.
unsuccessful metadata update.
DROP TABLE IMP_TABLE failed.
SQL error code = -607.
Invalid command.
Table IMP_TABLE does not exist.
Что такое повторный запуск ? В какой тр-ции ?
...
Рейтинг: 0 / 0
04.09.2018, 08:53
    #39697541
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMaxТо есть загвоздка в использовании этим пользователем индекса FK, из-за чего ни поле, ни таблица уже не удаляются.А как можно использовать индекс, но при этом не трогать таблицу ? :)
...
Рейтинг: 0 / 0
04.09.2018, 09:09
    #39697546
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
hvladЗачем nowait ? Не надо nowait
Так если в wait, то сервер зависает.
Я тогда что-то не понял. При работе в FB 2.5 я модификацию метаданных всегда делал в nowait-транзакции. FB при коммите сразу же выдавал сообщение об ошибке, если что-то пошло не так. Здесь же из-за особенностей FB3 пришлось это делать в wait-транзакции и получилось, что в случае lock conflict - зависание.
Как тогда правильно?

hvladЧто такое повторный запуск ? В какой тр-ции ?
В IBExpert делаю выполнение этого же запроса (DROP TABLE IMP_TABLE) в этой же транзакции после неудачного предыдущего выполнения.
...
Рейтинг: 0 / 0
04.09.2018, 09:17
    #39697552
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
hvladА как можно использовать индекс, но при этом не трогать таблицу ? :)
Конечно, тут одно из другого вытекает. Вопрос в том - кем и зачем индекс этот используется? Ведь если это поле используется в каком-то запросе, то сообщение об ошибке другое - без lock conflict. Меня этот LC очень смущает. Ведь это означает, что есть какая-то конкурирующая транзакция. И я хочу выяснить, какая.
...
Рейтинг: 0 / 0
04.09.2018, 09:17
    #39697553
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зависание FB при удалении таблицы/поля
CyberMax,

попробуй провести эти эксперименты в isql, ибо IBExpert иногда наступает сам себе на...
...
Рейтинг: 0 / 0
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Зависание FB при удалении таблицы/поля / 25 сообщений из 47, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]