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

Добрый день.

При обновлении с версии 8 до версии 9.1 Smeta.ru на Windows 7 произошел сбой обновления базы. Попытка восстановления из старых бэкапов не дала результатов - все бэкапы оказались неполными (при размере базы около 12 ГБ файл gbk около 890 Mb).

К сожалению физической копии базы перед обновлением не делалось.

При валидации базы получается 3 record level errors, 2 index page errors, 755 database page errors (общее количество старниц 3 224 919)
Firebird.log прикрепить не могу, вот что касается ошибок:

RED-ПК Tue Nov 15 00:34:01 2016
Database: Q:\DATASD123.SSD
Chain for record 31259288 is broken in table A_SMETA (152)
RED-ПК Tue Nov 15 00:34:01 2016
Database: Q:\DATASD123.SSD
Chain for record 31259313 is broken in table A_SMETA (152)
RED-ПК Tue Nov 15 00:35:01 2016
Database: Q:\DATASD123.SSD
Relation has -2 orphan backversions (694763 in use) in table A_SMETA (152)
RED-ПК Tue Nov 15 00:54:20 2016
Database: Q:\DATASD123.SSD
Index 1 is corrupt on page 104093 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1667
in table A_SMETA_VIEW_NUM (400)
RED-ПК Tue Nov 15 00:54:20 2016
Database: Q:\DATASD123.SSD
Index 1 is corrupt on page 104093 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1657
in table A_SMETA_VIEW_NUM (400)

Что делал:
gfix -v -full
gfix -mend -full -ignore
gbak -b -v -ig -g
gbak -c -i
При таком восстановлении вылезли ошибки пори востановлении индексов:
cannot comit index FK_A_SMETA_CENLVL_ID
ERROR: violation of FOREIGN KEY constraint "FK_A_SMETA_CENLVL_ID" on table "A_SMETA_CENLVL"
ERROR: Foreign key reference target does not exist

cannot comit index FK_A_SMETA_INDLVL_ID
ERROR: violation of FOREIGN KEY constraint "FK_A_SMETA_INDLVL_ID" on table "A_SMETA_INDLVL"
ERROR: Foreign key reference target does not exist

Открыл таблицу в IBExpert и провел запросы:
select * from a_smeta_cenlvl where not ID in (select id from A_Smeta)
delete from a_smeta_cenlvl where not ID in (select id from A_Smeta)

select * from a_smeta_indlvl where not ID in (select id from A_Smeta)
delete from a_smeta_indlvl where not ID in (select id from A_Smeta)

Ошибка при восстановлении исчезла. Однако бэкап не окрывается с ошибкой:

GSCODE = 335544788
Исключительная ситуация EIBInterBaseError в модуле SmetaRu.exe. Unable to perform operation. You must be either SYSDBA or owner of the database.

Проблема в том, что IBBackup_Configurator при создании бэкапа все равно создает битый файл gbk (примерно 890 Мб). Восстановление из созданного gbak архива тоже не проходит.

Возможно ли перенести данные по сметам в новую рабочую базу данных?

Добрый день!
Воспользуйтесь услугой экспертизы и ремонта базы данных у отдела программистов ГК СтройСофт.
Подробнее об оказании этой услуги можно узнать у консультантов по телефонам: 8-495-974-15-89 и 8-495-221-78-59.

druiddqd@yandex.ru писал(а):Попытка восстановления из старых бэкапов не дала результатов - все бэкапы оказались неполными (при размере базы около 12 ГБ файл gbk около 890 Mb).

бэкапы, сделанные Программой мониторинга БД представляют собой zip-архив стандартного бэкапа, при наличии навыков работы с многофайловыми бэкапами баз interbase/firebird их можно восстановить стандартными средствами. Малый размер объясняется хорошей "сжимаемостью".

druiddqd@yandex.ru писал(а):При таком восстановлении вылезли ошибки пори востановлении индексов:...
Открыл таблицу в IBExpert и провел запросы:...
Ошибка при восстановлении исчезла. Однако бэкап не окрывается с ошибкой:...

Все правильно делаете, только проводите все манипуляции с БД под FSTSUSER, а не SYSDBA... (в том числе при использовании gbak)

druiddqd@yandex.ru писал(а):При обновлении с версии 8 до версии 9.1 Smeta.ru на Windows 7 произошел сбой обновления базы.

При обновлении создается копия БД. Если не запускать процедуру обновления повторно, исходную базу можно найти во временной папке.

База банных, обновление которой было прервано, не может быть приведена в рабочее состояние только стандартными средствами, по причине отсутствия в ней значительной части метаданных (хранимых процедур и триггеров). Также процессе ее восстановления необходимо вычислить прерванный скрипт и довести процедуру обновления до конца...

druiddqd@yandex.ru писал(а):Возможно ли перенести данные по сметам в новую рабочую базу данных?

В этом и состоит суть услуги экспертизы и восстановления БД. Однозначный ответ на данный вопрос можно получить лишь предоставив саму базу. В вашем случае, судя по тому что gfix и gbak отрабатывают до конца, восстановление возможно без потери данных.

Semenov писал(а):]бэкапы, сделанные Программой мониторинга БД представляют собой zip-архив стандартного бэкапа, при наличии навыков работы с многофайловыми бэкапами баз interbase/firebird их можно восстановить стандартными средствами. Малый размер объясняется хорошей "сжимаемостью".

При восстановлении такого архива процесс прерывается на восстановлении таблицы A_Smeta. Нормальный размер архива после gback 5 Гб.

Метаданные восстанавливал в в IBExpert: сделал Database Comparer с предварительно очищенной работающей базой от версии 9.1 (Стер все сметы кроме 2ух и удалил все нормативы). После этого исправил все несоответствия.

Получил на выходе INET/inet_error: read errno = 10054.

Утром закажу счет на экспертизу.

druiddqd@yandex.ru писал(а):Утром закажу счет на экспертизу.

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

после обновление релиза до 9.1.4.0 программа не запускается, пишет "путь к базе указан неверно или база находится на профилактике. Что делать?

"...Не удается найти указанный файл"
Вероятно, обновление было прервано пользователем или по другой причине (аппаратный сбой или подобное).
Во избежание потери данных обратитесь за консультацией по телефонам горячей линии 8-495-974-15-89 и 8-495-221-78-59.

Копию базы данных делали?
Перейдите по указанному в сообщении пути и проверьте наличие файла базы данных и правильность его расширения .ssd. Возможно указан .ssd0.

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

Kventin Dorvard писал(а):Не запускайте повторно процесс обновления. Есть вероятность, что копия базы данных сохранилась в папке BaseTemp в папке Data в каталоге с релизом. Скопируйте ее оттуда на всякий случай. В противном случае информация будет потеряна.
После этого, а также после того как проверите соответствие файла базы данных правильному расширению (при необходимости его переименовать) возможно запустить процесс обновления повторно.

так и есть. Спасибо, заработало

Пожалуйста. Удачной работы!

Ошибка при ремонте БД:

wrong page type
page 1771362 is of wrong type (expected 4, found
gds_$compile_request failed

Куда копать?

arbeiten писал(а):Куда копать?

в общем случае - в направлении платного ремонта