gfix -shut full не отключает БД
Модераторы: kdv, Alexey Kovyazin
gfix -shut full не отключает БД
Здравствуйте.
При автоматическом еженедельном backup-restore примерно в трети случаев возникают проблемы. После вызова
gfix -shut full -force 0 localhost:db_alias
файл базы, видимо, иногда продолжает использоваться каким-то процессом, поскольку его не удается переименовать или удалить. Подскажите, пожалуйста, в чем тут дело и как это исправить? Может, надо просто подождать несколько минут, пока завершатся процессы сервера?
Однажды мне в одном подобном случае помог перезапуск сервера (net stop FirebirdServerDefaultInstance & net start FirebirdServerDefaultInstance), но последующие разы было хуже. После такого перезапуска существующие коннекты остаются, а новые пользователи подключиться не могут даже к другим базам на этом сервере (IBExpert при попытке подключиться выдает ошибку unavailable database), и этот способ, как оказалось, тоже не всегда позволяет разблокировать файл.
Конфигурация: Windows Server 2003, firebird classic 2.1.3.18185
При автоматическом еженедельном backup-restore примерно в трети случаев возникают проблемы. После вызова
gfix -shut full -force 0 localhost:db_alias
файл базы, видимо, иногда продолжает использоваться каким-то процессом, поскольку его не удается переименовать или удалить. Подскажите, пожалуйста, в чем тут дело и как это исправить? Может, надо просто подождать несколько минут, пока завершатся процессы сервера?
Однажды мне в одном подобном случае помог перезапуск сервера (net stop FirebirdServerDefaultInstance & net start FirebirdServerDefaultInstance), но последующие разы было хуже. После такого перезапуска существующие коннекты остаются, а новые пользователи подключиться не могут даже к другим базам на этом сервере (IBExpert при попытке подключиться выдает ошибку unavailable database), и этот способ, как оказалось, тоже не всегда позволяет разблокировать файл.
Конфигурация: Windows Server 2003, firebird classic 2.1.3.18185
Re: gfix -shut full не отключает БД
не отключает.
первый совет, не относящийся к проблеме - апгрейд сервера до 2.1.4.
Ответ на вопрос - gfix -shut force всего лишь прекращает операции в коннектах, но не отключает коннекты, поэтому процессы ФБ (классик или суперсервер) продолжают держать файл БД открытым.
p.s. про unavailable database - скорее всего загибаете, там другая ошибка должна быть. все варианты unavailable
перечислены тут
www.ibase.ru/ibfaq.htm#unavail
первый совет, не относящийся к проблеме - апгрейд сервера до 2.1.4.
Ответ на вопрос - gfix -shut force всего лишь прекращает операции в коннектах, но не отключает коннекты, поэтому процессы ФБ (классик или суперсервер) продолжают держать файл БД открытым.
p.s. про unavailable database - скорее всего загибаете, там другая ошибка должна быть. все варианты unavailable
перечислены тут
www.ibase.ru/ibfaq.htm#unavail
Re: gfix -shut full не отключает БД
Спасибо, так и подумал. В принципе, все, что мне нужно, - разблокировать файл БД, чтобы его можно было удалить, а на его место положить восстановленный. Для этого, видимо, надо завершить все процессы сервера, читающие базу. Есть, по-вашему, какой-нибудь способ сделать это?Ответ на вопрос - gfix -shut force всего лишь прекращает операции в коннектах, но не отключает коннекты, поэтому процессы ФБ (классик или суперсервер) продолжают держать файл БД открытым.
Можно попробовать gfix -shut и задержку на 5 минут, но никаких гарантий. Можно еще через таблицы мониторинга узнать PID сервера для всех активных подключений и прибить их, но это требует написания скрипта. Полегче нет способа? Как-то не верится, что разработчики не предусмотрели утилиты для этого. Ничего подобного на http://www.firebirdsql.org/en/reference-manuals/ я не нашел
Похоже, это один из багов fb 2.1.3 - почитал сейчас. Действительно надо обновиться и все проверить еще разp.s. про unavailable database - скорее всего загибаете, там другая ошибка должна быть. все варианты unavailable
перечислены тут
http://www.ibase.ru/ibfaq.htm#unavail
Re: gfix -shut full не отключает БД
добавлю лишь, что шатдаун таки отключает коннекты начиная с версии 2.5. Если это так критично, можно подумать о переходе.
но IMHO проблема где-то в консерватории. Зачем вообще шатдаунить базу при бекап/ресторе? Контрольный рестор обычно делают в сторонке в другой файл, заменять оригинал базы отресторенной копией большого смысла нет.
но IMHO проблема где-то в консерватории. Зачем вообще шатдаунить базу при бекап/ресторе? Контрольный рестор обычно делают в сторонке в другой файл, заменять оригинал базы отресторенной копией большого смысла нет.
Re: gfix -shut full не отключает БД
Бэкап-ресторе выполняется ночью батником (сейчас на Perl переписываю с максимумом проверок на ошибки), т.к. днем руками я это не могу делать - много юзеров работает. Ресторится в посторонний файл, а затем происходит замещение старого файла новым.но IMHO проблема где-то в консерватории. Зачем вообще шатдаунить базу при бекап/ресторе? Контрольный рестор обычно делают в сторонке в другой файл
Если есть способ без замены файла БД, буду очень рад его услышать. Пока пришло в голову править aliases.conf, переставлять элиас на восстановленный файл., заменять оригинал базы отресторенной копией большого смысла нет.
Погуглил на предмет "firebird backup/restore" - как-то глухо, предлагают скачать какой-то левый софт
Не, это нереально, т.к. я работаю в одном из множества филиалов, нарушится совместимость. Разве что до 2.1.4добавлю лишь, что шатдаун таки отключает коннекты начиная с версии 2.5. Если это так критично, можно подумать о переходе.
Re: gfix -shut full не отключает БД
способ чего? Бекап делается для наличия резервной копии. Рестор сразу после бекапа если и делается, то обычно в профилактических целях, чтобы убедиться в том, что из него можно создать базу без каких-либо неожиданностей. Для этого рестор делается с ключом "-c" и с другим именем базы. После чего полученная копия чаще всего удаляется. Зачем вам понадобилось заменять рабочий файл БД отресторенной копией, я не понимаю.seevi писал(а):Если есть способ без замены файла БД, буду очень рад его услышать
Re: gfix -shut full не отключает БД
Сорри, что сразу не объяснил, как-то не подумал, что могут не понять . Процедура, которую я описываю, - бэкап базы, восстановление из резервной копии и замещение старой базы в целях привести базу в порядок: уменьшить размер, перестроить индексы и прибрать мусор (хотя мусор можно и другими средствами).
Делать это раз в неделю - слишком часто, но делать надо, т.к. и бэкапы занимают меньше места (бэкапы делаются через nbackup, базы в несколько гигов), и ощутимо повышается производительность, а софт, с которым мы работаем (выбора, увы, нет), в плане работы с БД не идеален. Например, у нас документы сохраняются в базу по большей части в формате RTF, из-за чего занимают кучу места, и приходится периодически конвертировать их в doc
Делать это раз в неделю - слишком часто, но делать надо, т.к. и бэкапы занимают меньше места (бэкапы делаются через nbackup, базы в несколько гигов), и ощутимо повышается производительность, а софт, с которым мы работаем (выбора, увы, нет), в плане работы с БД не идеален. Например, у нас документы сохраняются в базу по большей части в формате RTF, из-за чего занимают кучу места, и приходится периодически конвертировать их в doc
Re: gfix -shut full не отключает БД
при нормально настроенной сборке мусора уменьшать размер базы смысла никакого нет. Индексы перестраивать нет необходимости, достаточно пересчитывать им статистику. Рестор для этого не нужен. Аналогично про сборку мусора. Если у вас после бекапа-рестора увеличивается производительность, значит этого же результата можно добиться и без него. И забыть про ненужные проблемы с шатдауном. А то наблюдается сценарий из серии "сами себе создаем трудности, а потом мужественно их преодолеваем".seevi писал(а):уменьшить размер, перестроить индексы и прибрать мусор
Re: gfix -shut full не отключает БД
Ок, подумаю насчет сборки мусора. Я почему-то считал, что ее недостаточно.
Небольшой вопрос: у нас база используется для обмена информацией с оборудованием в реальном времени, и некоторые транзакции read commited могут быть активными без конца, хоть целый месяц (пока не сделается backup/restore). Разница между oldest active & next transaction за неделю достигает десятков миллионов. Я правильно понимаю, что пока они висят, неиспользуемые версии, накопленные в этом промежутке, убраны не будут?
Небольшой вопрос: у нас база используется для обмена информацией с оборудованием в реальном времени, и некоторые транзакции read commited могут быть активными без конца, хоть целый месяц (пока не сделается backup/restore). Разница между oldest active & next transaction за неделю достигает десятков миллионов. Я правильно понимаю, что пока они висят, неиспользуемые версии, накопленные в этом промежутке, убраны не будут?
Re: gfix -shut full не отключает БД
ПО ваше? Тогда никто не мешает прочитать статью про транзакции на ibase.ru, и установить для читающих транзакций параметры read read committed rec_version. В этом случае транзакция может быть активной хоть месяц, без влияния на накопление версий, несборку мусора, и производительность.
это, простите, караул, это нужно лечить, немедленно. Если можете, пришлите статистику (вывод gstat -a -r) в zip/rar на support@ibase.ru. И сами ее посмотрите в IBAnalyst.Разница между oldest active & next transaction за неделю достигает десятков миллионов.
статистика покажет, где чего висит и накапливается.Я правильно понимаю, что пока они висят, неиспользуемые версии, накопленные в этом промежутке, убраны не будут?
Re: gfix -shut full не отключает БД
ПО нам пишут на заказ, я им уже сообщил о проблеме, сказал, чтобы использовали read only read committed - как раз вчера читал про это на http://www.ibase.ru/devinfo/utl.htm.
Скачал IBAnalyst Trial - честно говоря, не впечатлило, в IBExpert есть Database Statistics, который показывает ненамного меньше инфы, и информацию о версиях в том числе. Сегодня ставил эксперименты у себя на машине, еще немного продвинулся в понимании, как работает сборка мусора.
Думаю, тему можно закрывать. Благодарю отписавшихся за помощь, развеяли мои заблуждения
Вот, а мы в таком режиме живем уже пару лет. На этой неделе статистика более-менее в порядке - софт часто запускают-останавливают, длинных транзакций не висит, через пару недель посмотрю, сколько накрутит. Думаю сделать пару скриптов для сохранения статистики во времени.это, простите, караул, это нужно лечить, немедленно. Если можете, пришлите статистику (вывод gstat -a -r) в zip/rar на support@ibase.ru. И сами ее посмотрите в IBAnalyst.
Скачал IBAnalyst Trial - честно говоря, не впечатлило, в IBExpert есть Database Statistics, который показывает ненамного меньше инфы, и информацию о версиях в том числе. Сегодня ставил эксперименты у себя на машине, еще немного продвинулся в понимании, как работает сборка мусора.
Все так и оказалосьЯ правильно понимаю, что пока они висят, неиспользуемые версии, накопленные в этом промежутке, убраны не будут?
Думаю, тему можно закрывать. Благодарю отписавшихся за помощь, развеяли мои заблуждения
Re: gfix -shut full не отключает БД
смешно даже сравнивать. IBExpert просто показывает статистику, а IBAnalyst еще и все объясняет, как хинтами, так и в отчете, и т.д.Скачал IBAnalyst Trial - честно говоря, не впечатлило, в IBExpert есть Database Statistics, который показывает ненамного меньше инфы, и информацию о версиях в том числе.
Кстати, почему Trial? Тут на форуме ссылка на полную русскую версию 1.95, триалов у нас уже давно нет.
А кто делает софт, если не секрет? Мне интересно, как так получается, что эксплуататор ПО интересуется работой сервера больше, чем разработчики ПО.
Re: gfix -shut full не отключает БД
Триал я добыл в гугле по первой ссылке, было вполне похоже на официальный сайт. Или триал, или платная версия за $200 - может поэтому меня и не впечатлило, т.к. большая часть подсказок там была в стиле "купите полную версию". Раздел с софтом на форуме я вообще не заметил , посмотрю сегодня
Софт делает какая-то мелкая фирма, я подробностей не знаю, работаю всего пару месяцев. Интересоваться работой сервера приходится: место под бэкапы не резиновое, да и пользователи меня же достанут, если начнутся проблемы. А разработчикам пофигу, они баги по три месяца исправить не могут - меня вообще перестало что-либо удивлять после того, как я увидел структуру БД. Когда изначально кривая и переусложненная архитектура, баги можно править без конца
Софт делает какая-то мелкая фирма, я подробностей не знаю, работаю всего пару месяцев. Интересоваться работой сервера приходится: место под бэкапы не резиновое, да и пользователи меня же достанут, если начнутся проблемы. А разработчикам пофигу, они баги по три месяца исправить не могут - меня вообще перестало что-либо удивлять после того, как я увидел структуру БД. Когда изначально кривая и переусложненная архитектура, баги можно править без конца