Здравствуйте.

Вдруг запонадобилось срочно FireBird 3 вкатить на ALT Simply Linux x64. Cделал все как обычно, подключаюсь к базе нормально. Но если 1 пользователь подключен, второго уже не пускает, пишет: database DBNAME shutdown. Разбираться время нет к сожалению, поэтому прошу помощи. Дома и на тестовой машине, на таком же линуксе стоит FB3 одна из самых первых версий и нормально работает, но ставил очень давно и к сожалению уже не помню чего делал... Подскажите куда копать?

Ivan_Pisarevskyдело не в сервера, а в базе, ее надо перевести в состояние онлайн.

воспользуйся утилитой gfix

Спасибо!

Ivan_Pisarevsky./gfix -?
usage: gfix [options] <database>
plausible options are:
-ac(tivate_shadow) activate shadow file for database usage
-at(tach) shutdown new database attachments
-b(uffers) set page buffers <n>
-co(mmit) commit transaction <tr / all>
-ca(che) shutdown cache manager
-fu(ll) validate record fragments (-v)
-fo(rce_shutdown) force database shutdown
-fe(tch_password) fetch password from file
-h(ousekeeping) set sweep interval <n>
-i(gnore) ignore checksum errors
-icu fix database to be usable with present ICU version
-k(ill_shadow) kill all unavailable shadow files
-l(ist) show limbo transactions
-me(nd) prepare corrupt database for backup
-mo(de) read_only or read_write database
-nol(inger) close database ignoring linger setting for it
-n(o_update) read-only validation (-v)
-o(nline) database online <single / multi / normal>
-pr(ompt) prompt for commit/rollback (-l)
-pa(ssword) default password
-role set SQL role name
-r(ollback) rollback transaction <tr / all>
-sq(l_dialect) set database dialect n
-sw(eep) force garbage collection
-sh(utdown) shutdown <full / single / multi>
-tw(o_phase) perform automated two-phase recovery
-tra(nsaction) shutdown transaction startup
-u(se) use full or reserve space for versions
-user default user name
-v(alidate) validate database structure
-w(rite) write synchronously or asynchronously
-z print software version number

Я скорее всего ещё много не знаю о FB3, я догадываюсь что после восстановления из бэкапа (восстанавливаю в новый файл)каждый раз проделывать эту операцию нужно будет?

rdb_dev-Rik-Я скорее всего ещё много не знаю о FB3, я догадываюсь что после восстановления из бэкапа (восстанавливаю в новый файл)каждый раз проделывать эту операцию нужно будет?Скорее всего, ты многого не знаешь о FirebirdSQL вообще, а не в частности о FB3. В FirebirdSQL v2.5 было тоже самое.
Наверно, во всяком случае раньше не сталкивался.

Ivan_Pisarevsky-Rik-догадываюсь что после восстановления из бэкапа (восстанавливаю в новый файл)каждый раз проделывать эту операцию нужно будет?Если база в шатдауне после рестора, значит рестор обломался, надо смотреть его лог и устранить причину. Принудительный перевод в онлайн требуется после принудительного шатдауна. Вообще хорошая практика перед копированием базы зашатдаунить оную, потом перевести в онлайн после завершения копирования, я и решил что так и было и базу просто забыли поднять в онлайн.

-Rik-Разбираться время нет к сожалению, поэтому прошу помощи.Можем помочь, если будешь разбираться, если не разбираться, то это в раздел "работа", за денежку.
Да, хотелось бы разобраться. Я сегодня вечером повторю операцию, это займет время база ~80 гиг, сохраню лог. Бэкап делаю на FB 2.5, затем рестор на FB 3.0.4, с этим не может быть связано, с переходом с более ранней версии?

Ivan_Pisarevsky-Rik-Бэкап делаю на FB 2.5, затем рестор на FB 3.0.4Это осмысленная операция? Клиентский софт об этом знает? Или "шоб було"?Клиентский софт об этом знает. Приложения десктопные, кроссплатформенные, работают на компонентах IBX собственной модификации, те в свою очередь используют fbclient.dll (libfbclient.so), то что делал для себя, давно перевел на FB3, сложностей не возникло, процедуры все работает. Теперь вот большая рабочая база, если что-то пойдет не так, есть время за выходные откатиться назад, вернее исходный вариант вместе с носителями никто не трогает.

Док@-Rik-
Юр, привет, кстати :)
Привет Док

Ну вот, проблема ясна.

gbak:cannot commit index ZAYAVPOS_IDX9
gbak: ERROR:sort error
gbak: ERROR: No free space found in temporary directories
gbak: ERROR: operating system directive write failed
gbak: ERROR: No such file or directory

Говорит места не хватает во временной директории. Только не понятно, на разделе, на котором разворачиваю базу, там ещё 130 гб свободно, сама база 80гб. Тогда вопрос, к какой временной директории обращается FireBird?

Всем спасибо. Пока все понятно. Переезд базы на данный момент откладывается, там с сервером какая-то проблема. Если при возобновлении работ что-то ещё вылезет по поводу перехода на FB3, продолжу тему.