Форум ГК "СтройСофт"

Выделенный сервер. На нём Firebird 2.5 с БД, а также служба и утилита мониторинга. База была отконвертирована из версии 6 до 8.0.0.4, потом последовательно апалась до субверсий .7, .12 и, наконец, .15.
Необходимо поднять бэкап трёхдневной давности (тоже версии 8.0.0.15). Выбираю восстановление БД, указываю нужный бэкап, вариант восстановления - одиночная БД в новом месте, указываю новое имя и каталог, начинается процесс восстановления. В окне лога кроме сообщений о восстановлении того-сего вижу вот такие строки:

[skipped]

[0141553] gbak: activating and creating deferred index FKL_RULES_STRUCT_ID_RULES
[0141554] gbak: activating and creating deferred index FK_A_SMETA_CENLVL_ID
[0141555] gbak:cannot commit index FK_A_SMETA_CENLVL_ID
[0141556] gbak: ERROR:violation of FOREIGN KEY constraint "FK_A_SMETA_CENLVL_ID" on table "A_SMETA_CENLVL"
[0141557] gbak: ERROR: Foreign key reference target does not exist
[0141558] gbak: activating and creating deferred index FK_A_SMETA_CENLVL_IDCENLVL
[0141559] gbak: activating and creating deferred index FK_A_S_RES_CENLVL_ID

[skipped]

[0141571] gbak: activating and creating deferred index FK_D_GR_RES_CEN_LEVELS_UNDO_1
[0141572] gbak: activating and creating deferred index FK_A_SMETA_INDLVL_ID
[0141573] gbak:cannot commit index FK_A_SMETA_INDLVL_ID
[0141574] gbak: ERROR:violation of FOREIGN KEY constraint "FK_A_SMETA_INDLVL_ID" on table "A_SMETA_INDLVL"
[0141575] gbak: ERROR: Foreign key reference target does not exist
[0141576] gbak: activating and creating deferred index FK_A_SMETA_INDLVL_IDCENLVL
[0141577] gbak: activating and creating deferred index FK_A_SMETA_INDLVL_DESCR_ID
[0141578] gbak: activating and creating deferred index FK_A_SMETA_INDLVL_DR_IDCENLVL
[0141579] gbak: committing metadata
[0141580] gbak:finishing, closing, and going home
[0141581] gbak:Database is not online due to failure to activate one or more indices.
[0141582] gbak:Run gfix -online to bring database online without active indices.

Во-первых, неясно, откуда проблема - перед резервированием программа мониторинга проверяет (во всяком случае говорит, что проверяет) БД, и там не было никаких проблем (да и в текущем состоянии тоже нет проблем, провека ничего не выявляет, клиенты работают нормально).
Во-вторых, после неудачного восстановления созданный файл БД удаляется (ага, "gbak:Run gfix -online to bring database online without active indices." - пилите, Шура...). При этом НЕ удаляются распакованные части бэкапа.

Сейчас восстанавливаю БД из распакованных частей из командной строки, минуя программу мониторинга. Что там с базой - будет видно потом... но:

1) Как в бэкап могла просочиться ошибка структуры?
2) Почему утилита мониторинга так себя безобразно ведёт?

Вы словили весьма редкую ошибку, по крайней мере я с такой до сих пор не встречался.
Вкратце: это ошибка активизации индекса по указанной в сообщении таблице, причем таблица может быть как обычная (пользовательская), так и системная. Причина возникновения такой ошибки - наличие "лишних" записей в таблице A_SMETA_INDLVL, т.е. ссылающихся на несуществующие записи в таблице A_SMETA.
Лечение здесь должно быть следующее: найти и удалить эти самые лишние записи, после чего вручную активировать индекс. Автоматизированные средства здесь бессильны.
Причины же появления таких записей точно уставновить трудно, скорее всего, они стандартны - ошибка оборудования (как винчестера, так и сети), прыжки по питанию и пр.
Можно посмотреть по логу firebird - это файл firebird.log в основном каталоге firebird. Если не трудно, вышлите нам этот файл.
Итак: Если вы готовы самостоятельно исправить ошибку, я вышлю дополнительные подробные инструкции. Если нет - то мы можем поключиться программами типа TeamViewer к вашему серверу.

Что касается неудаления распакованных файлов из архива - как говорится, спасибо за информацию, будем исправлять.
здесь для общего развития еще инфа по данной ошибке:
http://gsbelarus.com/gs/modules.php?nam ... opic&t=514
http://www.ibaseforum.ru/viewtopic.php?p=22673

Всё ещё поганее. Дело в том, что этой проблемы нет ни в предыдущем, ни в последующем бэкапах. В БД тоже проблемы нет - вручную только что проверил через IBExpert, зависших ссылок в таблице нет (да и не могло быть - FK не дал бы).
Поскольку в самолечение БД не сильно верю - либо это шалости сервиса мониторинга (с чего бы? проверка там перед резервированием, конечно, есть - но ведь без исправления, и была бы ошибка в структуре БД, изготовление бэкапа резанулось бы), либо проблемы при изготовлении бэкапа (и при том - без ошибки?), либо повреждение файла бэкапа (тоже вряд ли - файл валиден до конца и после ошибки, а он к потере страниц неустойчив). В общем, не понимаю, откуда. То есть теоретический механизм возникновения такого типа ошибки понимаю (и то с трудом - FK не должен был допустить её возникновения, к тому же операция просто обязана быть завёрнута в транзакцию), а вот механизма её самоизлечения - нет.
В firebird.log есть единственная запись, относящаяся к периоду "около того" (она датирована датой-временем между изготовлением проблемного и предыдущего бэкапов, разгар работы) и как-то могущая относиться к проблеме:

WNET/wnet_error: ReadFile end-of-file errno = 109

Все остальные записи явно не относятся к проблеме никаким боком - там исключительно INET/inet_error: read errno = 10054, сброс соединения.

Сама ошибка мне тоже неудобств не доставила - ибо восстановленная через комстроку БД (ессно, не самоудалившаяся) нормально была воспринята клиентской частью, всё, что было надо, прекрасно оттуда экспортировалось. После чего полученная БД была благополучно удалена за ненадобностью. Каюсь, поленился посмотреть, были ли в ней сылки в никуда, а отсутствие пары индексов процедура экспорта проигнорировала.

Так... я лопух - ошибка в одной БД, а проверяю другую. Ошибка в БД - есть. Запрос

Код: Выделить всё

select c.id
from a_smeta_indlvl as c
left join a_smeta as a
on c.id=a.id
where a.id is null

и аналогичный на a_smeta_cenlvl дают одну и ту же запись с ID=45120131.

Voyager`tm писал(а):Если вы готовы самостоятельно исправить ошибку, я вышлю дополнительные подробные инструкции.

Да, будьте любезны.

В инете попадаются описания этой ошибки, однако они относятся к очень ранним версиям, и не только firebird, а еще даже Interbase. В-общем, похоже, что это именно ошибка штатной работы с БД, а не backup/restore. В какой-то момент из-за этой ошибки возникают лишние записи в таблице, в момент backup индекс не нужен, а во время restore после восстановления данных при попытке построения индекса как раз и возникает такая ошибка.
Ну а то, что программа работает и без них - так это же индексы, они нужны прежде всего для ускорения работы с таблицами (выборка данных), то есть без них тоже работает, но о-о-о-очень медленно, и тем медленней, чем больше в таблице записей.

Мы пришли к выводу, что наиболее рациональный путь решения данной ошибки, следующий:
- Удаляете записи с такой ID в таблицах a_smeta_cenlvl и a_smeta_indlv
- делаете базе backup/restore (она же "Ремонт БД"). Пусть это дольше, однако более надежно.

Voyager`tm писал(а):Удаляете записи с такой ID в таблицах a_smeta_cenlvl и a_smeta_indlv

Анализ структуры показывает, что записи в этих таблицах завязаны не только на таблицу a_smeta, но и на таблицу level_cost_simple... не получится так, что поправим в одном месте, а перекосит в другом?

Впрочем, попробую... вечером, когда все слезут с базы, сделаю копию и поизмываюсь над ней. А там видно будет... просто база пухлая, под 10 гектар, ей на бэкап-рестор надо далеко не один час.

Сделал копию БД (файловую), удалил проблемные записи из таблиц.
Бэкап-рестор смогу сделать только завтра - не умеет программа мониторинга выполнять две задачи параллельно, пусть и на разных БД...
О результатах отпишусь.

Мои опасения оказались напрасными. Пропыхтев почти 5 часов, программа мониторинга получила чистенькую, без ошибок, базу данных.

Voyager`tm, спасибо за помощь в устранении проблемы.

Что же, остается надеяться, что как можно меньше пользователей столкнутся с данной ошибкой. Спасибо на добром слове!

Добрый вечер! при бэкап ресторе появилась запись: Database is not online due to failure to activate one or more indices.. база не восстановилась.. Что делать? как исправить данную ошибку?