database file appears corrupt bad checksum

На чтение 6 мин. Опубликовано

Упал жесткий диск, после танцев с бубном и без вытащился с винта файлик БД, но при подкючении к ней вылетает эрор:

Error Message:
—————————————-
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements.
database file appears corrupt ().
bad checksum.
checksum error on database page 127120.

[00543D73]
[005400DD]
[00517E8B]
[00540358]
[00EF6D82]
[00E9C8CF]
[00E9D24B]
[00E2AAAF]
[004E5338]

как жить дальше? БД оч нужна. Метод gdb -> gbk -> gdb не прокатил

после танцев с бубном и без вытащился с винта файлик Значит он вытащился неправильно. Вот и все.

Файлы БД обычно силно фрагментируются и при упадении системы восстанавливаются часто криво. Можно попытаться воспользоваться другими программами, кроме той, которой было вытащено файло. Все-таки логика у разработчиков разная. Может быть и повезет.

З.Ы. А для нужных баз бэкап никто не отменял, так же как и рейды уровня 1 или 5.

Можно попытаться воспользоваться другими программами, кроме той, которой было вытащено файло. Все-таки логика у разработчиков разная. Может быть и повезет.

З.Ы. А для нужных баз бэкап никто не отменял, так же как и рейды уровня 1 или 5.

Чем попробовать вытащить? ну и самое главое как?
по поводу бэкапов согласен на все 400%, но это комп, скажем так, с отсорсинга, так что повлиять на применение подобных мер можно только после «грозы»

Здесь приведены сообщения об ошибках при физических повреждениях базы данных InterBase или Firebird.

№ ОШИБКА
internal gds software consistency check (cannot find tip page (165))
database file appears corrupt() wrong page type Page NNN is of wrong type (expected X, found Y)
Unknown database I/O error for file «. base.gdb» Error while trying to read from file
ERROR: internal gds software consistency check (decompression overran buffer(179))
database file appears corrupt () -bad checksum -checksum error on database page XX
База данных выглядит работоспособной. Но gbak не может сделать backup базы, применение gfix не изменяет ситуацию. Ошибка вроде: gbak: ERROR: internal gds software consistency check (cannot find record back version (291)) gbak: ERROR: gds_$receive failed gbak: Exiting before completion due to errors gbak: ERROR: internal gds software consistency check (can’t continue after bugcheck)
internal gds software consistency check (next transaction older than oldest active transaction (266))
База данных размером 4Гб, на версиях InterBase 4.x-5.x-6.0.x, а также на ранних бета-версиях Firebird 0.9.x не открывается, сервер отказывается ее рассматривать как корректную базу данных и не делает попыток ее открыть.
Во время restore базы данных появляется ошибка вроде Conversion error from string «XXX».

По данным группы IBSurgeon ( support@ibase.ru, sales@ibase.ru ) на восстановление базы данных по приведенным повреждениям требуется от 1 часа до более 10 часов.

Ниже приведены данные по стоимости услуг за восстановление баз данных группой IBSurgeon.

Стоимость ремонтных работ (за 1 час):

Ремонт БД, наличный расчет 40 у.е.
Ремонт БД, безналичный расчет 70 у.е.

Восстановление базы данных дорогостоящая процедура, и всего этого можно избежать, регулярно выполняя резервное копирование.

Содержание
  1. среда, 12 августа 2009 г.
  2. «bad checksum» или чиним базу данных Firebird
  3. 1 комментарий:

среда, 12 августа 2009 г.

«bad checksum» или чиним базу данных Firebird

Сломанная база данных Firebird 1.5 — Data.gdb (размер 95 117 312 байт).
Симптомы:

  1. При попытке подключения выводится ошибка: Unsuccessful execution caused by a system error that precludes
    successful execution of subsequent statements.database file appears corrupt ().
    bad checksum.
    checksum error on database page 23069.
  2. Утилиты gfix и IBPump падают с той же ошибкой.
  3. Сделать бэкап/рестор невозможно.

Инструменты:

  1. Любой hex-редактор
  2. Утилита IBFirstAID. Покупать ее не нужно, потребуется только бесплатный диагностический функционал.
  3. IBExpert

Решение проблемы:
Для анализа ошибки открываем БД при помощи IBFirstAID и выполняем «Database Diagnose». Как только завершится диагностика, получаем такой вот лог:

13.08.2009 12:28:28 INFO: Open database files: C:ProjectsClients96Data.gdb
13.08.2009 12:28:28 INFO: Analyzing database low-level structures.
13.08.2009 12:28:28 INFO: Process database file #1 of 1 files.
13.08.2009 12:28:36 INFO: Actual PageCount: 23222 found in database
13.08.2009 12:28:36 ERROR: Found 1 undefined pages.
13.08.2009 12:28:36 INFO: ====== DATABASE IS READY FOR DIAGNOSING AND REPAIRING. ====
13.08.2009 12:28:36 INFO: ====== Now choose «Diagnose» or «Repair». ====
13.08.2009 12:29:22 INFO: ——————- Starting diagnose
13.08.2009 12:29:22 INFO: Running procedure: Header page check
13.08.2009 12:29:22 INFO: ODS Major = 10 (10)
13.08.2009 12:29:22 INFO: ODS Minor = 1
13.08.2009 12:29:22 INFO: Next transaction = 7192198
13.08.2009 12:29:22 INFO: Oldest transaction = 7192158
13.08.2009 12:29:22 INFO: Oldest active = 7192159
13.08.2009 12:29:22 INFO: Oldest snapshot = 7191770
13.08.2009 12:29:22 INFO: PageSize is Ok = 4096
13.08.2009 12:29:22 INFO: Header page check: Ok
13.08.2009 12:29:22 INFO: Running procedure: Checking of RDB$Pages consistency
13.08.2009 12:29:24 ERROR: Possible error in next TIP page
13.08.2009 12:29:24 ERROR: Error in RDB$pages — wrong (missing?) page #23069 pageType = 3 pageSequence = 441 relation >13.08.2009 12:29:24 INFO: RDB$Pages checking: found 1 errors
13.08.2009 12:29:24 INFO: Running procedure: Low-level check of all relations
.

Из данного лога делаем выводы:

  1. Размер страницы БД — 4096: 13.08.2009 12:29:22 INFO: PageSize is Ok = 4096
  2. Найдена одна битая страница под номером 23069, ее тип — 03: 13.08.2009 12:28:36 ERROR: Found 1 undefined pages.
    13.08.2009 12:29:24 ERROR: Possible error in next TIP page
    13.08.2009 12:29:24 ERROR: Error in RDB$pages — wrong (missing?) page #23069 pageType = 3 pageSequence = 441 relation >13.08.2009 12:29:24 INFO: RDB$Pages checking: found 1 errors

Открываем БД в hex-редакторе (я использовал biew). Переходим по смещению битой таблицы. Чтобы вычислить смещение, нужно номер страницы умножить на размер страницы:

23069 * 4096 = 94490624 (0x5A1D000)

Внимательно изучаем заголовок страницы основываясь на информации отсюда:

  1. Тип страницы не соответствует (ожидается 03, а имеем — 01)
  2. Контрольная сумма никак не может равняться 0x303C, т.к. в текущей версии ODS контрольная сумма всегда равна 0x3039 (12345)

Вносим изменения в БД:

Теперь необходимо выполнить ремонт БД основываясь на вот этой статье: http://ibase.ru/devinfo/db_repair.htm

Все, база данных починена и полностью работоспособна.

1 комментарий:

Добрый день, прошу помощи по восстановлению базы gdb, так случилось на работе а там работа за год(((, опыта и понимания процесса восстановления нет.
Вот что смог сделать:
лог с IBSergion
15:01:33 DEBUG: Checking LIST_VYC (137).
15:01:33 Data page check: Undefined page type for pagenum = 12367
15:01:33 ERROR: Data page#12367 has critical errors
15:01:33 ERROR: Error on data page #12367
15:01:33 INFO: Pointer page #5814 checking: found 1 errors.
15:01:33 ERROR: Error in checking relation #137 Found 1 errors.
15:01:33 ERROR: Relation LIST_VYC (137) is CORRUPT

логин пароль стандартные, заранее благодарен.

ССылка на файл базы
https://mega.dp.ua/RywNKmVe

За помощь готов оплатить.Заранее благодарен.

Оцените статью