Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION
02.12.2011 13:50, reshetnyakvkt пишет: До этого стоял *FirebirdSS-2.5.0.25946-ReleaseCandidate3.amd64* Как был установлен? Из RPM или из tar.gz или собран и установлен из сорцов? После установки *FirebirdSS-2.5.1.26351-0.amd64* Как был установлен? Из RPM или из tar.gz или собран и установлен из сорцов? такая конструкция валит сервер наглухо. Приложения выполняющее этот запрос висит не реагируя Так валит сервер или вешает коннект, выполняющий запрос? Это совсем разные вещи. Как при этом себя чувствуют остальные коннекты? Это уже второй раз так случается и прослеживается закономерность. Т.е. это выполнялось всего дважды и оба раза висло или же выполнялось многократно, но висло всего дважды? Какие права даны на каталог /tmp/firebird? Вопрос к разработчикам что происходит. Если конструкция с "MON$ATTACHMENTS.MON$ATTACHMENT_ID" больше не работает, то подскажите как теперь без последствий отключать непослушные коннекты? У всех остальных она работает. Дмитрий
Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION
Во всех случаях сервер установлен из rpm. Старый удалялся ч/з rpm -e, с перезагрузкой оси. Сама ось не висит, выполняет команды и т.д. А к серверу firebird не присоединится, все соединения уходят в никуда, т.е. висят без ответа на ошибку коннекта или другое. Такой скипт после установки новой версии FB выполнялся дважды оба раза с печальным итогом. Права на /tmp/firebird (rwx-rwx-__ [firebird/firebird]), вроде нормально. Висят в нем 8 файлов суммарно 8мб. Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32. Суммарный объем файлов баз к которым применяется скрипт около 28Гб, могу предположить что дело может быть в попытке поднять их в память которой только 8Гб, и сервер уходит в глубокий своппинг. Хотя раньше такого не наблюдалось. Не знаю что ещё добавить. Если скрипт работает у других, то подожду следущего раза и если ситуация повторится, буду отслеживать кто виноват пробуя с разными базами. Может отчленять по кускам. -- View this message in context: http://firebird.1100200.n4.nabble.com/delete-from-MON-ATTACHMENTS-where-MON-ATTACHMENTS-MON-ATTACHMENT-ID-CURRENT-CONNECTION-tp4145993p4146299.html Sent from the firebird-russian mailing list archive at Nabble.com.
Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION
02.12.2011 15:05, reshetnyakvkt пишет: Во всех случаях сервер установлен из rpm. Старый удалялся ч/з rpm -e, с перезагрузкой оси. Сама ось не висит, выполняет команды и т.д. А к серверу firebird не присоединится, все соединения уходят в никуда, т.е. висят без ответа на ошибку коннекта или другое. А уже установленные на этот момент соединения продолжают работать? Или тоже виснут наглухо? Или прибиваются скриптом перед его подвисом? Такой скипт после установки новой версии FB выполнялся дважды оба раза с печальным итогом. А если убрать FOR-цикл с удаленным выполнением запросов, т.е. гасить только коннекты к своей базе? Если будет работать, то проблема не в MON$, а в коннектах к другим базам, см. ниже. Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32. Причем тут клиент? Версия клиентской библиотеки на это никак не влияет. Суммарный объем файлов баз к которым применяется скрипт около 28Гб, могу предположить что дело может быть в попытке поднять их в память которой только 8Гб, и сервер уходит в глубокий своппинг. Такое возможно, ведь EXECUTE STATEMENT не сразу закрывает свой коннект. Какой размер страничного кеша установлен для этих баз? Хотя раньше такого не наблюдалось. Может настройки какие-то менялись? Не знаю что ещё добавить. Если скрипт работает у других Точно такого же (с коннектами к другим базам) наверное ни у кого нет :-) А вот простой DELETE FROM MON$ATTACHMENTS есс-но работает. Дмитрий
Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION
"reshetnyakvkt" ... Сама ось не висит, выполняет команды и т.д. А к серверу firebird не присоединится, все соединения уходят в никуда, т.е. висят без ответа на ошибку коннекта или другое. Бектрейс висячего процесса и копия лок-таблицы могут пролить свет на эту тайну -- Хорсун Влад
