Restore не проходит до конца

Chemist · Сообщение **Chemist** » 21 авг 2006, 21:26

Не восстанавливается БД из backup.

Версия сервера 1.5.3.4870 CS на ASP Linux 11, RAID 0
Размер БД > 106 Гб
Размер FBK ~ 60 Гб

localhost Mon Aug 21 18:54:03 2006
Database: /db/base.res
internal gds software consistency check (pointer page vanished from DPM_next (249))

localhost Mon Aug 21 18:54:03 2006
Database:
I/O error for file "/db/base.res"
Error while trying to read from file
No such file or directory

localhost Mon Aug 21 18:54:03 2006
Database: /db/base.res
I/O error for file "/db/base.res"
Error while trying to read from file
No such file or directory
...

Бэкап сделан в момент, когда одна из таблиц достигла таки размера 36 Гб, а казалось что это так много

. Восстановление проводилось два раза, состав ошибки не изменился. Единственное отличие заключается в конечном размере БД перед остановкой восстановления, в первом случае это 81 Гб, во-втором - 85Гб.

Вопросы.

1. Что обозначает ошибка ... DPM_next (249).
2. С чем может быть связано не восстановление БД: ошибка БД, железо, иное...
3. Перед backup log содержал записи - это может вызвать критическое повреждение БД.

localhost Mon Jul 31 16:19:24 2006
Database: /db/base.fdb
Index 1 is corrupt on page 297614 in table A1 (128)

localhost Mon Jul 31 16:19:24 2006
Database: /db/base.fdb
Index 1 is corrupt on page 297614 in table A1 (128)

localhost Mon Jul 31 16:19:24 2006
Database: /db/base.fdb
Index 7 is corrupt on page 194880 in table A1 (128)

localhost Mon Jul 31 16:19:24 2006
Database: /db/base.fdb
Index 7 is corrupt on page 194880 in table A1 (128)

localhost Mon Jul 31 16:19:25 2006
Database: /db/base.fdb
Relation has 689 orphan backversions (0 in use) in table A1(128)

localhost Mon Jul 31 16:43:37 2006
Database: /db/base.fdb
Index 4 has orphan child page at page 207162 in table A2 (136)

localhost Mon Jul 31 17:00:39 2006
Database: /db/base.fdb
Index 3 is corrupt on page 293373 in table A3 (139)

Сообщение **kdv** » 21 авг 2006, 22:40

восстановить можно только на firebird 2, где снят лимит на 36 гиг. dpm_next - это то самое, о чем своевременно предупреждает IBAnalyst, и о чем мы предупреждали больше года назад. Т.е. ни под какой версией IB/FB кроме FB2 такая таблица работать не будет, и кроме того, не забэкапится (нормально).

можно считать, что те записи, которые перелезли лимит в 36 гиг на таблицу, Вы потеряли. Можно будет попробовать зафиксировать таблицу на уровне 36 гиг, и сделать бэкап. только вот вопрос - как эту базу Вы сможете доставить к нам в офис. Если диск scsi, то мне его подключить просто некуда, к сожалению. ide/sata - без проблем.

попробуйте для начала заресторить БД под FB 2.

Alexey Kovyazin

Еще вариант - попробуйте ресторить под 1.5, но поставьте маскимально возможный размер страницы. Там на долю процента сокращаются накладные расходы на хидеры страниц - может, поможет.

Кстати, что за база, какое назначение, где используется?

Сообщение **kdv** » 21 авг 2006, 22:45

позвоните завтра в 10 утра
www.ibase.ru/dbrepair.htm
телефон в самом конце.

Chemist · Сообщение **Chemist** » 22 авг 2006, 11:09

kdv писал(а):восстановить можно только на firebird 2, где снят лимит на 36 гиг. dpm_next - это то самое, о чем своевременно предупреждает IBAnalyst, и о чем мы предупреждали больше года назад. Т.е. ни под какой версией IB/FB кроме FB2 такая таблица работать не будет, и кроме того, не забэкапится (нормально).

Проверка IBAnalyst к сожалению в разумный интервал времени был возможен только до ~ 40 Гб. Далее....

Это, кстати, относиться ко всем средствам администрирования БД линейки Interbase/Firebird. Нормальным развитием в этом направлении является NBackup, будем учиться. Еще бы подтянуть к этому gfix -sweep (например, gfix -sweep 83Гб - 11:00 - 21:45

) и т.п., вообще бы лафа настала.

kdv писал(а):можно считать, что те записи, которые перелезли лимит в 36 гиг на таблицу, Вы потеряли. Можно будет попробовать зафиксировать таблицу на уровне 36 гиг, и сделать бэкап. только вот вопрос - как эту базу Вы сможете доставить к нам в офис. Если диск scsi, то мне его подключить просто некуда, к сожалению. ide/sata - без проблем.

попробуйте для начала заресторить БД под FB 2.

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

На счет FB2. Можно ли восстановить БД без метаданных, только таблицы. Скрипт метаданных для перехода на FB2.RC4 подготовлен, но из backup метаданные не ресторяться, т.к. есть некоторые пересчения по новым функциям и зарезервированным словам

. Единственный вариант перелезть на FB2 без перелива данных - это скопировать на сервер с FB2, накатить скрипт, сделать backup/restore

PS. Доставить можно на внешнем носителе, но есть ньюансы...

Chemist · Сообщение **Chemist** » 22 авг 2006, 11:14

Alexey Kovyazin писал(а):Еще вариант - попробуйте ресторить под 1.5, но поставьте маскимально возможный размер страницы. Там на долю процента сокращаются накладные расходы на хидеры страниц - может, поможет.

Сейчас это и делаю на другой машине, чтобы исключить фактор железа. Есть некоторые сомнения в машине, на которой стоит ASP Linux.

Alexey Kovyazin писал(а):Кстати, что за база, какое назначение, где используется?

Сгенерированная по определенным сценариям БД уровня ERP за много лет работы.

hvlad · Сообщение **hvlad** » 22 авг 2006, 12:56

Chemist писал(а):Проверка IBAnalyst к сожалению в разумный интервал времени был возможен только до ~ 40 Гб. Далее.... Это, кстати, относиться ко всем средствам администрирования БД линейки Interbase/Firebird. Нормальным развитием в этом направлении является NBackup, будем учиться. Еще бы подтянуть к этому gfix -sweep (например, gfix -sweep 83Гб - 11:00 - 21:45 ) и т.п., вообще бы лафа настала

В FB2 sweep должен быть быстрее (на ОДС11).
Плюс планируется уделить этому вопросу дополнительное внимание в FB3

Chemist · Сообщение **Chemist** » 22 авг 2006, 13:06

hvlad писал(а):В FB2 sweep должен быть быстрее (на ОДС11). Плюс планируется уделить этому вопросу дополнительное внимание в FB3

Проверим

, сначала надо переползти.

Chemist · Сообщение **Chemist** » 23 авг 2006, 12:13

Chemist писал(а):
Alexey Kovyazin писал(а):Еще вариант - попробуйте ресторить под 1.5, но поставьте маскимально возможный размер страницы. Там на долю процента сокращаются накладные расходы на хидеры страниц - может, поможет.
Сейчас это и делаю на другой машине, чтобы исключить фактор железа. Есть некоторые сомнения в машине, на которой стоит ASP Linux.

Для интересующихся. Восстановление БД на другой машине прошло успешно, без ошибок. Параметры для GBAK, которые были :
- page size 16384
- use all space

ЗЫ. После предварительной проверки разница в кол-ве записей до и после составляет 2681. Но, целостность данных и их непротиворечивость на момент достижения физического ограничения и после администрирования вроде подтверждается.

Сообщение **kdv** » 23 авг 2006, 13:44

при перелезании за 36 гиг (до FB 2), как я уже говорил, данные-то пишутся, но вот читаются они "не оттуда". поэтому количество записей в качестве проверки целостности ориентиром вряд ли может служить

use_all_space - да, помогает, но все равно место новой записи считается по фиксированной формуле, которая ни от числа записей ни от размера страницы не зависит.

решением этой проблемы в FB2 было измененение разрядности физического номера записи, который был 32-разрядным, а теперь 40-разрядный (64, но часть бит не используется).

Chemist · Сообщение **Chemist** » 23 авг 2006, 15:25

kdv писал(а):при перелезании за 36 гиг (до FB 2), как я уже говорил, данные-то пишутся, но вот читаются они "не оттуда". поэтому количество записей в качестве проверки целостности ориентиром вряд ли может служить
use_all_space - да, помогает, но все равно место новой записи считается по фиксированной формуле, которая ни от числа записей ни от размера страницы не зависит.

Понятно, что не помогает при работе с этой версией сервера. Но на данный момент таблица восстановлена правильно, если судить по тестовым запросам. Но все равно хотелось бы в этом убедиться и иными способами. Надеюсь сегодня нам это удастся. IbAnalyst показывает для этой таблицы еще ~10000 страниц.

kdv писал(а):решением этой проблемы в FB2 было измененение разрядности физического номера записи, который был 32-разрядным, а теперь 40-разрядный (64, но часть бит не используется).

Деваться некуда. Перевод на FB2 идет полным ходом. Отличная тестовая платформа получается

PS. Меня все больше начинет смущать CS на ASP Linux для такой большой БД. То ли Linux-сервер настроен криво, то ли Win2003 SS ложит его на лапатки.

Ivan_Pisarevsky

Версия сервера 1.5.3.4870 CS на ASP Linux 11, RAID 0

Месье камикадзе? сотню гиг коммерческих данных сложить на рэйд 0...

Chemist · Сообщение **Chemist** » 23 авг 2006, 17:08

Ivan_Pisarevsky писал(а):
Версия сервера 1.5.3.4870 CS на ASP Linux 11, RAID 0
Месье камикадзе? сотню гиг коммерческих данных сложить на рэйд 0...

Читайте внимательно ВСЕ сообщения - это сгенерированная БД. Предназначена для тестирования. RAID 0 нужен был только для увеличения объема дискового пространства на имеющихся мощностях

.

Chemist · Сообщение **Chemist** » 06 сен 2006, 17:38

hvlad писал(а):В FB2 sweep должен быть быстрее (на ОДС11).
Плюс планируется уделить этому вопросу дополнительное внимание в FB3

Наконец-то удосужился сделать sweep под ODS11

. Я не верю своим глазам ~30 минут

.