Падает сервер 3.0.4.32920 64 bit при восстановлении бд из архива.

Единственная запись в логе:

SERVER6 Thu Feb 22 17:10:57 2018
INET/inet_error: read errno = 10054, server host = localhost, address = 127.0.0.1/3050

Дважды пытался, и с помощью утилиты gbak (с ключем -se) и из нашей программы (подключение
к серверу через API).

Архив базы сделан на ФБ 2.5.

Как бы выяснить в чем дело?

PS: бэкап большой -- 48 ГБ.

на ночь оставил третью попытку. теперь gbak но без ключа -se и без указания имени сервера в имени файла базы данных. Утром посмотрим.

пока дождусь утра. пройдет ли восстановление без серверного протокола или нет. Тут просто 512 ГБ ОЗУ и полный дамп может быть проблематичен в силу этого.

может попробовать сборку с отладочной информацией?

3.03 тоже падал.

дамп процесса тоже нелегко будет сделать. я выделяю 200 гб под кэш страниц и 64 гб под темп кэш.

на момент падения восстанавливается 100 гб базы.

Значит, сначала отвечу не по делу, потом по делу:

1) базу слегка почистили. насколько возможно. до этого ее размер доходил до 180+ Гб. Так что кэш в 200 Гб вполне оправдан, учитывая что сервер будет дальше работать лет пять и база будет расти.

2) в разгар рабочего дня 300 подключений из которых пару десятков с аналитическими выборками (большие запросы с группировками и сортировками). Простое отключение кэша дает в темп каталоге несколько десятков фалов сортировок с размерами от 1 Гб и выше. Так что 64 Гб под темп кэш это суровая реальность, а не фантазии.

3) если вы следите за тенденциями, то SAP перешел на базу SAP HANNA, которая "in-memory, column-oriented, relational database management system". Ключевое здесь "in-memory". По отзывам, на практических примерах у них пошло ускорение в 100-1000 раз. Так что большие объемы памяти это уже реальность, а завтра будет повседневность.

Теперь по делу:

1) оставленный на ночь gbak тоже завершился ошибкой. Скрин в прикреплении.

2) но, запущенный на другом сервере gbak завершился успешно. Итоговый размер бд 126 Гб.

В чем разница:

а) сервер 3.0.4.32917
б) ключи -v -o при восстановлении. Восстанавливалось ооочень долго, полтора суток.
в) на этом сервере 32 Гб ОЗУ
г) количество буферов устеновлено 2000, остальные параметры firebird.conf по-умолчанию.


Теперь я думаю попробовать вернуть все параметры конфигурации Firebird по-умолчанию и прогнать восстановление на большом сервере с буфером 2000 страниц.

Если пройдет, тогда дело в больших значениях параметров. Если нет, тогда в чем-то другом.

небольшой вопрос по дампу. насколько я понимаю, падает процесс сервера и перезапускается операционной системой. Т.е. в тот момент когда gbak кинет ошибку "error reading from connection" нужного мне процесса для дампа уже не будет. Или я не прав?

размер страницы на всякий случай. он не меняется.

количество страниц указано потому что база с 2.5 классик и там, естественно, кэш минимальный.

служба перезапускается автоматом, так как установлена командой:

instsvc i -a

hvlad,

выслал почтой ссылку на архив с дампом.

Gorynich,

хватает. чистые все диски. новый же сервер ))

Огромное спасибо Владу за исправление!

https://github.com/FirebirdSQL/firebird/commit/42630c1c836a7d21b765303d20a7a2a3624db99c

если здесь:

https://github.com/FirebirdSQL/firebird/commits/master

отсутствует запись "increment build number", значит snapshot builds здесь:

http://web.firebirdsql.org/download/snapshot_builds/win/3.0/

не перекомпилировались?