ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Зависание FB при удалении таблицы/поля
47 сообщений из 47, показаны все 2 страниц
  все  
Зависание FB при удалении таблицы/поля
    #39696971
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Владу Хорсуну.
FB 3.0.4 SS Windows x64.
При работе с метаданными баз при работающих пользователях натолкнулся на следующую проблему. Иногда, при удалении таблицы или поля (в wait-транзакции), при коммите (из IBExpert) происходит зависание. Завершение транзакций в базе не отрабатывает - в MON$TRANSACTIONS висят ожидающие коммита транзакции. При этом иногда при попытке считать данные из MON$ATTACHMENTS так же происходит зависание. Если выборка из MON$ATTACHMENTS не зависла, то при удалении части/всех подключений оттуда - коммит завершается и можно продолжать работать с базой.
При попытке остановить процесс сервера - firebird никак на это не реагирует, помогает только перезагрузка виндовса.
Воспроизвести на тестовой базе такой случай не удалось.

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

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

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

CyberMaxВ следующий раз, когда такое произойдет, достаточно ли будет сделать файл дампа процесса (через диспетчер задач виндовса) или надо что-то другое сделать для диагностики?Дамп памяти (полный, full) - это обязательно. Ещё можно сделать дамп лок-таблицы (fb_lock_print -d <database> -a)
...
Рейтинг: 0 / 0
03.09.2018, 09:06
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697010
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
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:38
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697013
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
CyberMax,

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

Я через диспетчер задачи снимал.
Пробовал остановить базу через gfix и shutdown - зависание gfix во время шатдауна.
...
Рейтинг: 0 / 0
03.09.2018, 09:50
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697016
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
CyberMaxhvladДамп памяти (полный, full) - это обязательно. Ещё можно сделать дамп лок-таблицы (fb_lock_print -d <database> -a)
Принято.Да, ещё - если пользуешься снапшотом (речь ведь о 3.0.4), то нужно сохранять .pdb файлы от него.
Без них дамп памяти бесполезен.
...
Рейтинг: 0 / 0
03.09.2018, 09:53
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697036
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
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:20
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697041
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Это через 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:26
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697059
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
hvladДа, ещё - если пользуешься снапшотом (речь ведь о 3.0.4), то нужно сохранять .pdb файлы от него.
Речь идет только о firebird.pdb, который в корневой папке снапшота? Или нужны еще какие-то pdb?
...
Рейтинг: 0 / 0
03.09.2018, 10:54
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697060
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
CyberMax,

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

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

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

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

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

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

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

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

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

Ну, удаление таблицы - ещё туда-сюда, но действительно ли нужна эксклюзивная блокировка
при удалении поля?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.09.2018, 13:42
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697467
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Dimitry SibiryakovНу, удаление таблицы - ещё туда-сюда, но действительно ли нужна эксклюзивная блокировка
при удалении поля?
Дмитрий, вы, наверно, не совсем поняли. У IBExpert есть настройка параметров транзакций - для работы с данными, для работы с метаданными и для выполнения скриптов. Настройка для метаданных сделана с wait - чтобы можно было перекомпиливать триггеры/ХП/пакеты на "горячую". И эти же настройки IBExpert'ом применяются при модификации таблицы (в том числе удаления полей и таблицы). Какая там блокировка внутри сервера, эксклюзивная или нет, или еще что, мне как-то неинтересно. Если дроп отрабатывается - ОК, если нет - разбираемся, что пошло нет так, как сейчас.
...
Рейтинг: 0 / 0
04.09.2018, 01:53
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697471
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Влад, пробую удалить другую таблицу через 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, 02:39
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697503
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Еще инцидент. Создал сегодня в рабочей базе таблицу 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:22
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697510
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Локализовал последний случай.
Пользователь входит в программу. Я в 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, 07:46
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697539
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
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:45
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697541
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
CyberMaxТо есть загвоздка в использовании этим пользователем индекса FK, из-за чего ни поле, ни таблица уже не удаляются.А как можно использовать индекс, но при этом не трогать таблицу ? :)
...
Рейтинг: 0 / 0
04.09.2018, 08:53
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697546
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
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:09
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697552
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
hvladА как можно использовать индекс, но при этом не трогать таблицу ? :)
Конечно, тут одно из другого вытекает. Вопрос в том - кем и зачем индекс этот используется? Ведь если это поле используется в каком-то запросе, то сообщение об ошибке другое - без lock conflict. Меня этот LC очень смущает. Ведь это означает, что есть какая-то конкурирующая транзакция. И я хочу выяснить, какая.
...
Рейтинг: 0 / 0
04.09.2018, 09:17
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697553
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
CyberMax,

попробуй провести эти эксперименты в isql, ибо IBExpert иногда наступает сам себе на...
...
Рейтинг: 0 / 0
04.09.2018, 09:17
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697557
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
CyberMaxhvladЗачем nowait ? Не надо nowait
Так если в wait, то сервер зависает.
Я тогда что-то не понял. При работе в FB 2.5 я модификацию метаданных всегда делал в nowait-транзакции. FB при коммите сразу же выдавал сообщение об ошибке, если что-то пошло не так. Здесь же из-за особенностей FB3 пришлось это делать в wait-транзакции и получилось, что в случае lock conflict - зависание.
Как тогда правильно?Указывать конечное время ожидания
Перечитай 21662490 и 21662579


CyberMaxhvladЧто такое повторный запуск ? В какой тр-ции ?
В IBExpert делаю выполнение этого же запроса (DROP TABLE IMP_TABLE) в этой же транзакции после неудачного предыдущего выполнения.Ну так таблица уже помечена как удаляемая (в кеше метаданных текущего коннекта). После роллбека пометка снимется.
...
Рейтинг: 0 / 0
04.09.2018, 09:21
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697560
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов ДенисCyberMax,

попробуй провести эти эксперименты в isql, ибо IBExpert иногда наступает сам себе на...+1
...
Рейтинг: 0 / 0
04.09.2018, 09:22
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697570
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
CyberMaxМеня этот LC очень смущает. Ведь это означает, что есть какая-то конкурирующая транзакция. И я хочу выяснить, какая.Не обязательно тр-ция. Кеш метаданных удерживает блокировки объектов. Для этого не нужны тр-ции.

Счётчик использования объекта метаданных (таблицы, индекса и т.п.) инкрементируется в двух случаях
- при препарировании запроса
- при выполнении запроса в тр-ции

Соответственно декремент происходит при
- уничтожении препарированного запроса
- завершении тр-ции

Итого, блокировку объекта может удерживать не только тр-ция, но и факт существования препарированного запроса (который так или иначе использует объект)
...
Рейтинг: 0 / 0
04.09.2018, 09:33
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697581
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
hvlad]Не обязательно тр-ция. Кеш метаданных удерживает блокировки объектов. Для этого не нужны тр-ции.

Счётчик использования объекта метаданных (таблицы, индекса и т.п.) инкрементируется в двух случаях
- при препарировании запроса
- при выполнении запроса в тр-ции

Соответственно декремент происходит при
- уничтожении препарированного запроса
- завершении тр-ции

Итого, блокировку объекта может удерживать не только тр-ция, но и факт существования препарированного запроса (который так или иначе использует объект)
Тогда разрешите еще несколько вопросов:
1. Так как используется счетчик, нет возможности узнать, кто конкретно поставил блокировку?
2. В 3.0 кэш метаданных - раздельный. Каким образом увеличивается счетчик блокировок моего коннекта, если объект используется в другом коннекте?
3. Если транзакция завершается без уничтожения препарированного запроса - он уничтожится?
4. Блокировка действует в рамках транзакции. Или может быть такое, что активных транзакций нет, а блокировка - есть?
...
Рейтинг: 0 / 0
04.09.2018, 10:09
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697584
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
CyberMax,

а ты до этого работал в 2.5 SS? Просто те у кого был CS/SC особенно ничего и не заметили при переходе на 3.0 SS. Привыкли уже.
...
Рейтинг: 0 / 0
04.09.2018, 10:14
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697585
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Симонов Дениса ты до этого работал в 2.5 SS?
Я во всех версиях работал только с SS.
...
Рейтинг: 0 / 0
04.09.2018, 10:19
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697616
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
CyberMax1. Так как используется счетчик, нет возможности узнать, кто конкретно поставил блокировку?Явно известно только в каком коннекте она используется.
Чтобы узнать точнее, нужно перебрать все запросы в кеше метаданных данного коннекта.

CyberMax2. В 3.0 кэш метаданных - раздельный. Каким образом увеличивается счетчик блокировок моего коннекта, если объект используется в другом коннекте?Никаким не увеличивается.

CyberMax3. Если транзакция завершается без уничтожения препарированного запроса - он уничтожится?Конечно нет. Запросом владеет тот, кто его создал - пользователь.
Системные запросы пока не обсуждаем.

CyberMax4. Блокировка действует в рамках транзакции. Или может быть такое, что активных транзакций нет, а блокировка - есть?Блокировка метаданных никак не привязана к области действия тр-ции.

Ещё раз. Есть объекты метаданных. Они загружаются в кеш метаданных по мере необходимости.

С каждым таким объектом связан existence lock (блокировка существования).
При загрузке объекта в кеш и до начала его использования берётся existence lock в shared (SH) режиме.
Каждый "пользователь" объекта метаданных инкрементирует счётчик использования объекта.
Пока счётчик не нулевой, existence lock не может быть отпущен.

Есть два вида таких пользователей - препарированный запрос и активная тр-ция.
Для того, чтобы удалить объект, нужно получить existence lock в exclusive (EX) режиме.
Чтобы его получить, все кеши должны отпустить свои SH блокировки.
Это невозможно, пока соотв. счётчики использования не нулевые.

Таким образом, пока есть препарированные запросы, заинтересованные в данном объекте, и пока жива хоть одна тр-ция,
в которой выполнялся подобный запрос, получить EX блокировку не удастся.
...
Рейтинг: 0 / 0
04.09.2018, 10:41
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697632
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
hvlad,

ну с транзакциями всё понятно.
А вот возник такой вопрос, а можно ли сделать так чтобы при перекомпиляции объекта метаданных, связанные с ним препарированные запросы становились инвалидными и перепрепарировались как только эти запросы потребуются? Я не в смысле ближайшего будущего, а вообще теоретически.
...
Рейтинг: 0 / 0
04.09.2018, 10:59
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697638
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Симонов Дениспопробуй провести эти эксперименты в isql, ибо IBExpert иногда наступает сам себе на...
В общем, перезашел в IBExpert и попытался удалить таблицу IMP_TABLE, к которой никто из пользователей не обращался. Не получилось. Начал выгонять пользователей по одному и пытаться удалить таблицу. По итогу всех выгнал, остался один, но таблица все равно не удалялась. Перезашел - и заработало. Тут же удалил соседнюю такую же проблемную таблицу.
Вариантов два:
1. IBExpert что-то не освобождает.
2. Firebird что-то не освобождает.
Попробую покопать вариант 1, т.к. проверить вариант 2 не знаю как.
...
Рейтинг: 0 / 0
04.09.2018, 11:10
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697644
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов ДенисА вот возник такой вопрос, а можно ли сделать так чтобы при перекомпиляции объекта метаданных, связанные с ним препарированные запросы становились инвалидными и перепрепарировались как только эти запросы потребуются? Я не в смысле ближайшего будущего, а вообще теоретически.Теоритически - можно всё, что не противоречит теории :)

На практике есть много вопросов. Например
- Сейчас движок никак не отслеживает связь объект -> запрос в кеше метаданных, только в обратную сторону.
Т.е. чтобы найти такие запросы, нужно проверить их все.

- Что делать с запросом, который сейчас выполняется ?
- Что делать с запросом, который выполнился, но тр-ция ещё не завершена ?
Не думаю, что разные результаты выполнения одного запроса в одной тр-ции будут именно тем, что ожидает прикладной программист

И т.д. - уверен, что это только верхушка айсберга
...
Рейтинг: 0 / 0
04.09.2018, 11:17
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697653
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
hvlad- Что делать с запросом, который сейчас выполняется ?
- Что делать с запросом, который выполнился, но тр-ция ещё не завершена ?

то же самое что и сейчас. Ругаться. Речь была только о препарированных запросах, которые не активны и транзакции которых завершены.
...
Рейтинг: 0 / 0
04.09.2018, 11:29
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697657
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Симонов Денис,

А сейчас бывают случаи, когда успешно препарированный и успешно выполнявшийся ранее запрос вдруг выдает ошибку, причём не уровня "запрос правильный, но записи такой не найдено", а уровня требующего изменения текста запроса и перепрепарирования?

Навскидку мне кажется прикладные клиентские библиотеки и программы едва ли рассчитаны на автоматическое пере-препарирование запроса.
...
Рейтинг: 0 / 0
04.09.2018, 11:35
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697659
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Вообще, препарирование запроса существует только внутри транзакции, или "препарированность" может быть передана в следующую транзакцию, если сам запрос (текст, BLR) не меняется?

В первом случае препарированные запросы имеет смысл сразу чистить, чтобы кэши освободить. Тут недавно как раз темы пробегали, что в FB3 гораздо больше памяти кэши отъедают. Во втором - наоборот, чтобы по возможности избежать более затратной проверки прав доступа.
...
Рейтинг: 0 / 0
04.09.2018, 11:38
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697667
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Arioch,

ты абсолютно не в теме. Писательский зуд ?
...
Рейтинг: 0 / 0
04.09.2018, 11:43
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697685
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Arioch,

гм. к примеру, открыто 200 коннектов, активно 150 транзакций, при этом существует 500 запросов, из них привязаны к транзакциям штук 20. Остальные 480 - просто prepared, и держатся приложениями.
Это реальные данные по одной из систем. В других - по другому. Сервер сам никакие препарированные запросы не держит.
И т.д. Так что, надо быть поближе к реалиям. В mon$statements посмотреть, и всё такое.
...
Рейтинг: 0 / 0
04.09.2018, 12:14
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697717
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladНа практике есть много вопросов. Например
- Сейчас движок никак не отслеживает связь объект -> запрос в кеше метаданных, только в
обратную сторону.
Т.е. чтобы найти такие запросы, нужно проверить их все.

Можно пойти другим путём:
1) drop чего-то не удаляет объект физически, а всего лишь запись о нём из системных таблиц.
2) Когда эта удалённая запись становится мусором, сборщик мусора пробует получить лок и,
если обломался, оставляет этот мусор в покое до следующего обнаружения. Получил - удаляет
объект, ибо на него уже гарантированно никто не ссылается сейчас и не может сослаться в
будущем.
3) Способ получения идентификаторов придётся немного переделать чтобы новая таблица не
получила ид удалённой, но ещё не вычищенной.

hvlad- Что делать с запросом, который сейчас выполняется ?
- Что делать с запросом, который выполнился, но тр-ция ещё не завершена ?
Не думаю, что разные результаты выполнения одного запроса в одной тр-ции будут именно тем,
что ожидает прикладной программист
При вышеописанной схеме запросы в незавершившихся транзакциях будут выдавать правильные
результаты в соответствии с их уровнем изоляции. Возможен парадокс, когда заранее
препарированный (в давно завершившейся транзакции) запрос возвращает данные из таблицы, а
новое препарирование обламывается, но нормальный "прикладной программист" в такую ситуацию
вряд ли попадёт.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.09.2018, 13:14
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39697998
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Dimitry Sibiryakov1) drop чего-то не удаляет объект физически, а всего лишь запись о нём из системных таблиц.
2) Когда эта удалённая запись становится мусором, сборщик мусора пробует получить лок и,
если обломался, оставляет этот мусор в покое до следующего обнаружения. Получил - удаляет
объект, ибо на него уже гарантированно никто не ссылается сейчас и не может сослаться в будущем.
при таком раскладе, когда RECREATE выдаст ошибку (на фазе CREATE, между прочим) - это еще можно будет понять. Но когда отдельный DROP/COMMIT пройдет, а потом на CREATE "то же имя" получим "object N already exists", при этом в системных таблицах его не видно - вот это будет весело...
...
Рейтинг: 0 / 0
04.09.2018, 17:59
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39698025
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
dimitrпри таком раскладе, когда RECREATE выдаст ошибку (на фазе CREATE, между прочим) - это еще
можно будет понять. Но когда отдельный DROP/COMMIT пройдет, а потом на CREATE "то же имя"
получим "object N already exists", при этом в системных таблицах его не видно - вот это
будет весело...

Это мы получим если получение идентификатора будет идти в системной транзакции, которая
работает в dirty read. А так, вроде бы, уникальное ограничение позволяет две записи с
одинаковым значением если одна из них уже удалена. Или нет?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.09.2018, 18:29
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39698056
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry Sibiryakov2) Когда эта удалённая запись становится мусором, сборщик мусора пробует получить локНе нужно сборщик мусора превращать в сферического мета-коня. Это не будет работать.

PS казалось бы - при чём тут инвалидация препарированных запросов...
PPS ты хочешь приделать версионность к метаданным, это нормально, но зачем скрещивать ужа с ежом - я не понимаю
...
Рейтинг: 0 / 0
04.09.2018, 19:16
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39698081
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladPS казалось бы - при чём тут инвалидация препарированных запросов...
Ну, до меня донеслись слухи, что WAIT - панацея и позволяет свободно альтерить любые
объекты невзирая на подключенных пользователей. А тут вдруг сюрприз в виде данного топика...

hvladPPS ты хочешь приделать версионность к метаданным, это нормально, но зачем
скрещивать ужа с ежом - я не понимаю

Если у тебя есть лучший план для их реализации, не томи, поделись светлой мыслью.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
04.09.2018, 20:07
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39698103
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry Sibiryakov,

сюрпризов пока что не обнаружено. wait тр-ция ведёт себя так, как ей положено.

Ну а мои светлые мысли пока что останутся со мною.
Их и так есть чем занять.
...
Рейтинг: 0 / 0
04.09.2018, 22:12
| Ответить | Цитировать | Написать  
Зависание FB при удалении таблицы/поля
    #39698461
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Dimitry SibiryakovНу, до меня донеслись слухи, что WAIT - панацея и позволяет свободно альтерить любые
объекты невзирая на подключенных пользователей. А тут вдруг сюрприз в виде данного топика...
в данном топике дропают, а не альтерят...
...
Рейтинг: 0 / 0
05.09.2018, 13:46
| Ответить | Цитировать | Написать  
47 сообщений из 47, показаны все 2 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Зависание FB при удалении таблицы/поля
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1560994]:
 0ms
get settings:
 10ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 52ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 72ms
get tp. blocked users:
 1ms
others: 11ms
total:  176ms
созд. / загр.: 176ms
x
x
Закрыть


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