Ошибка при резервном копировании базы данных
Модераторы: Анастасия, Дмитрий
-
yudin
- Новичок
- Сообщения: 1
- Зарегистрирован: Сб янв 07, 2012 12:07 am
Ошибка при резервном копировании базы данных
Здравствуйте.
У меня в настройках стоит резервное копирование при каждом выходе из программы, сегодня начала появляться следующая ошибка:
gbak: ERROR:internal gds software consistency check (wrong record length (183), file: vio.cpp line: 1121)
gbak: ERROR: gds_$receive failed
gbak:Exiting before completion due to errors
gbak: ERROR:internal gds software consistency check (can’t continue after bugcheck)
Резервная копия не делается!
Подскажите пожалуйста, что это такое и как с этим бороться.
-
Дмитрий
- Разработчик
- Сообщения: 1696
- Зарегистрирован: Ср ноя 21, 2007 6:18 am
- Контактная информация:
Re: Ошибка при резервном копировании базы данных
Сообщение
Дмитрий » Ср апр 18, 2012 12:34 pm
Пожалуйста, приведите полностью текст ошибки, которую выдает программа. Чтобы скопировать текст ошибки из сообщения об ошибке, нужно нажать Ctrl-C, когда активно окно с ошибкой. Далее этот текст можно вставить в текст сообщения при помощи Ctrl-V.
-
Senya_is2
- Новичок
- Сообщения: 6
- Зарегистрирован: Ср апр 18, 2012 12:05 pm
Re: Ошибка при резервном копировании базы данных
Сообщение
Senya_is2 » Ср апр 18, 2012 4:53 pm
обновил программу до последней версии 1.3.10.733
на рабочий стол добавились два ярлыка, кроме прежнего, MoneyTracker — Домашняя бухгалтерия и MoneyTracker — Тестовая база
тестовая запускается с демоданными. а первая с моей историей, но при закрытии выдает туже ошибку что и раньше
-
Дмитрий
- Разработчик
- Сообщения: 1696
- Зарегистрирован: Ср ноя 21, 2007 6:18 am
- Контактная информация:
Re: Ошибка при резервном копировании базы данных
Сообщение
Дмитрий » Чт апр 19, 2012 1:47 pm
Добрый день. Попробуйте перед установкой удалить файл Backup.exe из папки с программой, чтобы точно быть уверенным, что он перезаписывается. Проблема идет именно с запуском этого файла, причем на уровне Windows, т.е. операционная система не может запустить этот файл, потому что он поврежден.
description: Regular backups with «gbak -b» failed at these error
gbak: ERROR:BLOB not found
gbak: ERROR:gds_$receive failed
gbak:Exiting before completion due to errors
content of /var/log/firebird.log (all times are in UTC):
our_database (Server) Tue May 17 03:34:51 2011
Database: /srv/firebird/our_database.fdb
deadlock
internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4043)
our_database (Server) Tue May 17 03:36:39 2011
Database: /srv/firebird/our_database.fdb
deadlock
our_database (Server) Tue May 17 03:36:44 2011
Database: /srv/firebird/our_database.fdb
deadlock
our_database (Server) Wed May 18 06:15:25 2011
Fatal lock manager error: invalid lock id (21688), errno: 22
Last successful backup started at 2011-05-17T22:00Z and ended at 2011-05-18T04:53Z
after that error we have been unable to backup database, gfix binary copy of it trough —mend or —validate —full
we were able to backup database with gbak -b —ignore but unable to restore (gbak restored the file but ended on bad page type error and quit)
but the gfix was able to find a lot of following types of errors:
Database: /mnt/tmp/our_database.fdb
Index 1 is corrupt on page 8136665 level 1. File: ../src/jrd/validation.cpp, line: 1649
in table DEVICE_PIM_DATA (133)
our_database (Server) Fri May 20 16:24:02 2011
Database: /mnt/tmp/our_database.fdb
Page 22655159 is an orphan
We were able to finally backup the database after manually scanning all blobs and removing records with missing blobs (cca 8 records).
Our database have 89GB file size (cca 70% of content are blobs). After gbak failed we upgraded to 2.1.4 and solved the problem with this version. We provide free service for users all around the world so we do not want any downtime. (but the database itegrity is still a priority). Should we do anything about reported errors?
=>
Regular backups with «gbak -b» failed at these error
gbak: ERROR:BLOB not found
gbak: ERROR:gds_$receive failed
gbak:Exiting before completion due to errors
content of /var/log/firebird.log (all times are in UTC):
our_database (Server) Tue May 17 03:34:51 2011
Database: /srv/firebird/our_database.fdb
deadlock
internal gds software consistency check (error during savepoint backout (290), file: exe.cpp line: 4043)
our_database (Server) Tue May 17 03:36:39 2011
Database: /srv/firebird/our_database.fdb
deadlock
our_database (Server) Tue May 17 03:36:44 2011
Database: /srv/firebird/our_database.fdb
deadlock
our_database (Server) Wed May 18 06:15:25 2011
Fatal lock manager error: invalid lock id (21688), errno: 22
Last successful backup started at 2011-05-17T22:00Z and ended at 2011-05-18T04:53Z
after that error we have been unable to backup database, gfix binary copy of it trough —mend or —validate —full
we were able to backup database with gbak -b —ignore but unable to restore (gbak restored the file but ended on bad page type error and quit)
but the gfix was able to find a lot of following types of errors:
Database: /mnt/tmp/our_database.fdb
Index 1 is corrupt on page 8136665 level 1. File: ../src/jrd/validation.cpp, line: 1649
in table DEVICE_PIM_DATA (133)
our_database (Server) Fri May 20 16:24:02 2011
Database: /mnt/tmp/our_database.fdb
Page 22655159 is an orphan
We were able to finally backup the database after manually scanning all blobs and removing records with missing blobs (cca 8 records).
Our database have 89GB file size (cca 70% of content are blobs). After gbak failed we upgraded to 2.1.4 and solved the problem with this version. We provide free service for users all around the world so we do not want any downtime. (but the database itegrity is still a priority).
Should we do anything about reported errors?
environment: PC, Debian Squeeze => amd64, Debian Squeeze
При обращении по поводу ремонта баз данных Firebird (InterBase) Вам нужно предоставить следующую информацию на support@ibase.ru (просьба не присылать базы данных или другие большие файлы без предварительного запроса):
- Операционная система на сервере (версия, установленные сервиспаки, для Unix также необходимо указать версию kernel)
- Версия используемого сервера (например, Firebird 1.5 for Windows, SuperServer, build 4290). Точную версию сервера (на Windows можно посмотреть на закладке Version, если открыть Properties exe-файла)
- Размер файла базы данных и тип файловой системы
- Примерную причину повреждения базы данных – отключение питания, падение сервера, и т. п.
- Последние 10-20 сообщений в interbase.log (firebird.log)
- Log от утилиты IBFirstAid Diagnostician (от Direct, полученный путем анализа поврежденной базы данных, запакованный zip или rar). Оценить объем повреждений и «ремонтопригодность» БД можно по статье.
- В письме обязательно укажите Ваш номер телефона для связи (с кодом города)
Ремонт БД
(срок ремонта – 1 день)
минимальная стоимость – 15000 рублей
Ремонт БД от 30 гигабайт и выше
(срок ремонта – 1 день)
минимальная стоимость – 50000 рублей
Срочный ремонт, в выходные, праздничные дни и ночное время
стоимость определяется отдельно
Далее перечислены типичные повреждения и сообщения об ошибках баз данных InterBase, Firebird, с которыми успешно борется группа наших специалистов. Остальные типы повреждений также ремонтируемы, однако в каждом конкретном случае первоначально определяется объем восстановимых данных.
| N | Ошибка | Вероятная причина | Действия по восстановлению | Примерные трудозатраты |
|---|---|---|---|---|
| 1 | internal gds software consistency check (cannot find tip page (165)) | В результате физического повреждения файла базы данных потеряна страница учета тразакций (TIP) | Анализ потерянных страниц, генерация новой страницы учета транзакций вместо потерянной, проверка базы данных и тестовое backup/restore. | 1-3 часа |
| 2 | database file appears corrupt() wrong page type Page NNN is of wrong type (expected X, found Y) | В результате физического повреждения нарушена последовательность страниц в файле базы данных или неправильные значения на страницах указателей (Pointer Pages), страницах вершин индексов (Index Root Pages) и т. д. | Анализ последовательности страниц в базе данных, исправление неправильных ссылок в последовательности, возможно – перегенерация запорченных страниц и генерация новых вместо потерянных. Затем проверка базы данных с помощью gfix и контрольное backup/restore. | 2-4 часа |
| 3 | Unknown database I/O error for file «…base.gdb»
Error while trying to read from file |
В результате аварийного отключения питания или аварийного завершения работы сервера последние несколько страниц файла базы данных не успевают записаться на диск и при следующем обращении к базе данных сервер не может построить целостный образ базы данных (internal database image) и открыть ее. | По оставшимся в базе данных страницам выясняются потерянные ссылки на страницы, их типы и количество. Генерируются новые страницы вместо потерянных. Производится проверка базы данных с помощью gfix и контрольное backup/restore. | 2-4 часа |
| 4 | ERROR: internal gds software consistency check (decompression overran buffer(179)) | Серьезное повреждение базы данных, возможно запорчены системные таблицы. Иногда эта ошибка возникает при переносе базы данных с одной операционной системы на другую через файловую копию. В каждом конкретном случае разбираться нужно конкретно. | Анализ цепочек отношений в базе данных, генерация новых страниц, итерационный процесс восстановления. | от 2 часов |
| 5 | database file appears corrupt ()
-bad checksum -checksum error on database page XX |
Результат физических повреждений. В зависимости от номера страницы ситуация может меняться – это может быть простой случай наподобие 2, а может быть и очень сложный. | Анализ проблемной страницы, в зависимости от ее типа, далее восстановление потерянных цепочек. | от 2 часов |
| 6 | База данных выглядит работоспособной. Но 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) |
Серьезное повреждение базы данных, которое нельзя точно идентифицировать – оно может быть связано как с физическими повреждениями базы данных, так и ошибками в коде сервера, а также некоторыми редкими сочетаниями структур метаданных. | Ситуация требует тщательного изучения, обычно решение состоит в поиске и удалении проблемных объектов базы данных, после чего они пересоздаются вновь. Иногда требуется перекачка данных в новую базу данных. | от 2 часов |
| 7 | internal gds software consistency check (next transaction older than oldest active transaction (266)) | Такая ошибка встречается только на серверах InterBase 4.x-5.x, связана с порчей заголовочной страницы. | Обычно лечится настройкой подходящих параметров транзакции на заголовочной странице. Номера транзакций рассчитываются исходя из анализа записей на страницах данных (data pages). | 1-3 часа |
| 8 | База данных (размером менее 4 Гб) не открывается вообще – Interbase или Firebird отказывается ее рассматривать в качестве базы данных. | Как минимум, запорчена заголовочная страница. Случай требует тщательного изучения. | Регенерация базы данных на основе оставшейся части БД. Процесс сложный, и никто не даст 100% гарантии успеха. | от 3 часов |
| 9 | База данных размером 4 Гб, на версиях InterBase 4.x-5.x-6.0.x,а также на ранних бета-версиях Firebird 0.9.x не открывается, сервер отказывается ее рассматривать как корректную базу данных и не делает попыток ее открыть. | Очень сложный и трудоемкий случай, однако воссстановление вполне возможно с высокими шансами на успех. Причина состоит в том, что в ранних версиях InterBase существовало ограничение на размер файла в 4 Гб (под Windows), потому что для перемещения по файлу используется 32-битная адресация. При превышении размера базы данных в 4 Гб указатель перемещается из конца в начало файла и начинает писать поверх системных страниц. Процесс затирания обычно аварийно прерывается на первых нескольких десятках страниц, и затем базу данных невозможно использовать или вообще открыть с помощью ядра InterBase. | Процесс восстановления заключается в генерации новых системных страниц на основе анализа структуры всей оставшейся базы, а также ручной правке связей между страницами. Это длительный итерационный процесс, однако он обычно имеет значительные шансы на успех, так как чаще всего повреждения базы данных локализованы в небольшой области. | от 10 часов |
| 10 | Во время restore базы данных появляется ошибка вроде Conversion error from string «XXX». | Ошибка может быть связана как с ошибочными NULL, которые появились в полях с атрибутом NOT NULL, так и с повреждениями самого файла резервной копии, или еще с чем-то. Каждый раз необходимо исследовать базы данных для постановки диагноза – предварительный диагноз невозможен. | Анализ базы данных на потерянные страницы, попытка перекачки базы данных в новую БД с целью выявления проблемных мест. Процесс итерационный и трудоемкий. | от 4 часов |
Все указанные причины повреждения для описанных ошибок являются приблизительными и выведены на основе статистики, собранной командой iBase в процессе лечения нескольких сотен баз данных. С вероятностью до 70% можно утверждать, что данные ошибки соответствуют описанной причине и потребуют для своего исправления указанное количество часов.
Для всех случаев ремонта соблюдается полная конфиденциальность.
Также, вместо ремонта базы данных нашими специалистами, вы можете приобрести утилиту IBSurgeon FirstAid, которая позволяет ремонтировать в автоматическом режиме до 95% различных видов повреждений баз данных.
Цены на ПО IBSurgeon
Модераторы: kdv, Alexey Kovyazin
-
Vitaliy
- Сообщения: 2
- Зарегистрирован: 30 апр 2005, 11:58
Не делается GFIX
при попытке сделать Backup выдается ошибка:
gbak: ERROR: I/O error for file «D:1.GDB»
gbak: ERROR: Error while trying to read from file
gbak: ERROR: Достигнут конец файла.
gbak: ERROR: gds_$receive failed
gbak: Exiting before completion due to errors
при попытке сделать Gfix -mend -full -ignore *.gdb пишет:
internal gds software consistency check (page in use during flush (210))
В логе пишет тоже самое…
при проверке в логе ругается на таблицы:
Index 2 is corrupt on page 49479 in table MOVES3 (163)
Pointer page (sequence 26) inconsistent in table OUTPTRS (165)
Data page 49409 (sequence 305) is confused in table REMNS (166)
и конечно же 
:
Page 49476 wrong type (expected 7 encountered 5)
Page 49408 wrong type (expected 4 encountered 5)
и в конце опять:
internal gds software consistency check (page in use during flush (210))
К базе можно подключиться 
…
если IBExpert открываешь эту таблицу и пытаешься ее пролистать, то на определенном этапе выходит ошибка:
«Error while truing to read from file.
Достигнут конец файла»
вот такая у меня проблема…. с другой стороны кому сейчас легко ))))
если кто решит помочь — буду очень признателен…. при случие отвечу темже ))))))))
-
Гость
Сообщение
Гость » 30 апр 2005, 12:37
забыл уточнить:
все это дело происходит на InterBase 5.6
-
kdv
- Forum Admin
- Сообщения: 6595
- Зарегистрирован: 25 окт 2004, 18:07
Сообщение
kdv » 03 май 2005, 10:06
1. размер базы?
2. размер страницы?
3. файловая система?
ну и, что произошло с базой, собственно. погас свет, или еще чего…
-
Vitaliy
- Сообщения: 2
- Зарегистрирован: 30 апр 2005, 11:58
Сообщение
Vitaliy » 11 май 2005, 07:07
Vitaliy
Ну еслиб честно то энта база не моя даже…. попросили помочь )))
Поэтому предистория этой проблемы смутная …. — вроде при каком-то пересчете и удалении документов ушел в перезагрузку комп.
(Для информации: все это происходит на ресторанной программе StoreHouse (менеджерская часть R-Keeper))
Размер файла GDB = 202 Мб
Размер страницы = 4096
Файловою систету той машины на которой произошол сбой — не знаю…
Сейчас пытался востановить на Fat32 / Win2000 /
← →
stud
(2003-09-23 15:03)
[0]
arithmetic overflow or division by zero has occurred.
arirhmetic exception, numeric overflow, or string truncation.
что сие может означать?
создаю новую базу этими же скриптами, переношу данные датапампом — и в новой базе все работате??? что может быть?
← →
kaif
(2003-09-23 15:23)
[1]
Когда эта ошибка происходит:
1. При backup?
2. При Restore?
← →
stud
(2003-09-23 15:24)
[2]
при backup
← →
kaif
(2003-09-23 15:30)
[3]
Есть ли в базе:
1. Вычисляемые поля, в которых могло бы происходить деление на 0?
2. Есть ли поля, объявленные NOT NULL, добавленные в таблицу, в которой уже есть строки, но для которых ты забыл создать все значения и какие-то осталиcь NULL?
← →
kaif
(2003-09-23 15:32)
[4]
Сначала сделай на всякий копию файла БД.
Затем попробуй из самых подозрительных таблиц удалить все данные и сделать backup. Так ты узнаешь, которая таблица создает проблему (если их не несколько…).
← →
stud
(2003-09-23 15:33)
[5]
нет.
← →
kaif
(2003-09-23 15:53)
[6]
В общем, стратегия такая, какую я предложил. Удаляешь последовательно данные из каждой таблицы и пытаешься после этого сделать backup. Как только backup заработает, начинаешь разбираться в причинах (напрягать мозг). Может, ты чего-то не видишь.
← →
stud
(2003-09-23 16:10)
[7]
может))
← →
stud
(2003-09-23 16:42)
[8]
после перезагрузки появилось следующее сообщение:
unsuccesful execution caused by system error that does not preclude succesful execution of subsequent statments.
message length error (encountered 38, expected 30).
gds_$receive failed.
что в переводе на русский (промпт) значит
неудачное выполнение вызвано системной ошибкой, которая не препятствует успешному выполнению следующего выражения
ошибка длины сообщения ….
только файл бекапа не создается, хотя сервис нормально завершает работу(IBexpert)
IBconsole выдает такое сообщение:
Arithmetic exception, numeric overflow, or string truncation
и что делать?
удалять данные из таблиц слишком муторно, потомучто добавлять их обратно нужно, а там триггеры, генераторы …..
(((((((((((
← →
Johnmen
(2003-09-23 16:59)
[9]
Удалять кривые данные все равно придется..:)
← →
stud
(2003-09-23 17:03)
[10]
дык а найти их как.
тут косоль выдает сообщения по очереди:
о переполнении
или о длине сообщения
каждый раз по разному
как найти на каком объекте это происходит?
← →
Johnmen
(2003-09-23 17:08)
[11]
Так ведь kaif © предложил методику.
← →
kaif
(2003-09-23 19:14)
[12]
Ну так чем эпопея-то закончилась?
Не исключена ведь и кривизна сервера…
Народу интересно.
Если что-то удалось раскопать, сообщи на форум. И версию сервера не забудь.
← →
Zacho
(2003-09-23 19:18)
[13]
2 stud :
Почитай
http://www.ibase.ru/devinfo/db_repair.htm
← →
stud
(2003-09-24 09:22)
[14]
вот именно это вчера нашед и изучал, сейчас начну ломать)))
← →
stud
(2003-09-24 09:40)
[15]
при проверке базы gfix -validate
выдается следующее сообщение
Summary of validation errors
Number of index page errors : 1
Number of database page errors : 6
← →
Sergey13
(2003-09-24 09:42)
[16]
А может и ломать ничего не надо. У меня были похожие проблемы. Получились из за того что менял типы данных через домены (длины, точность). Все меняется, но старые данные (которые были до замены), видимо хранятся в старом виде. Помогло помнится нечто вроде апдейта с поле=поле+»», или поле=поле*1. Можно попробовать через создание поля «двойника».
← →
stud
(2003-09-24 09:47)
[17]
да все бы ничего, только знать бы какое поле))) или хотя бы таблица….
← →
Sergey13
(2003-09-24 10:02)
[18]
Дык скажи гбаку делать подробный вывод. В ИБЭксперте можно вроде (нет под рукой). Там будет писаться имя таблицы, на которой происходит ошибка.
← →
stud
(2003-09-24 10:10)
[19]
gbak: writing parameter SPEC for stored procedure
вот тут он и останавливается. с процедурой все в порядке, т.к. бэкап с ней проходил раньше и она не менялась
← →
Sergey13
(2003-09-24 10:34)
[20]
Вот тут не подскажу. Черт его знает че там. Попробуй ее убить/ пересоздать. Или смотри все таблицы, которые там упоминаются.
ЗЫ:Кстати а таблицы уже бекапились по логу или еще нет. Какой там порядок не помню.
← →
stud
(2003-09-24 10:39)
[21]
вот последние данные))
gbak: writing data for table PERERYV
gbak: 2 records written
gbak: writing index RDB$PRIMARY28
gbak: writing data for table MKB_10
gbak: 0 records written
gbak: writing index RDB$PRIMARY6
gbak: writing data for table BASE_RASP
gbak: ERROR: message length error (encountered 38, expected 30)
gbak: ERROR: gds_$receive failed
gbak: Exiting before completion due to errors
← →
Sergey13
(2003-09-24 10:49)
[22]
>gbak: writing data for table
BASE_RASP
>gbak: ERROR: message length error (encountered 38, expected 30)
ИМХО, тут надо копать. В таблице BASE_RASP.
← →
stud
(2003-09-24 11:01)
[23]
копал,но текстовых полей в этой таблице нету. только time, smallint,integer и первичный ключ
← →
Sergey13
(2003-09-24 11:07)
[24]
Так не обязательно текстовые. Например integer на smallint не менял? И как эти типы описывается — «напрямую» для каждого поля или через домены?
← →
stud
(2003-09-24 11:08)
[25]
нет. похоже дело в ПК, вот как-бы его удалить
в ибэксперте не получается, не отключает индекс и не дает удалить ПК
← →
Sergey13
(2003-09-24 11:18)
[26]
Ну и не отключай. Создай поле дубликат ПК1. Потом ПК1=ПК, потом ПК=ПК1. Потом удали ПК1.
← →
stud
(2003-09-24 11:23)
[27]
нашел в чем дело, точнее объекты. две таблицы удалил их — все нормально
← →
Alex_Raider
(2003-09-24 12:57)
[28]
Это может быть (и есть)
и название этому только одно:
Убогенькие разработчики убогонького серверка сэкономили,
и объединили несколько сообщений об ошибках в одно сообщение,
специально чтобы пользователям (то бишь нам) их продукта было удобнее работать:
arithmetic overflow or division by zero has occurred.
arirhmetic exception, numeric overflow, or string truncation.
У тебя же имеет место быть последнее (изменил формат поля).
← →
stud
(2003-09-24 13:04)
[29]
но при удалении данных из таблицы то же самое было
← →
KaRaT
(2003-09-24 13:50)
[30]
Ключевое поле содержит дубликат (номер одинаковый). Такое происходить не должно, но глюки случаются… удали ключ, найди повторяющееся поле и сделай ему туда что-нибудь другое. Восстанови ключ.
← →
stud
(2003-09-24 13:57)
[31]
да нет все нормально со значениями, я же писал выше при удалении данных из таблицы и уничтожении первичного ключа тоже самое происходит. к тому же создание копии БД из этих же данных проходит нормально и все бекапится без проблем.
← →
stud
(2003-09-25 17:30)
[32]
однако сегодня проблема повторилась))
очевидно из-за смены типа полей. поменял timestamp на date.
таблицы известны, какие действия можно предпринять, кроме их удаления?