database file appears corrupt bad checksum

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

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 у.е.

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

среда, 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

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

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