iBase.ru Forum

При исправлении базы gfix-ом (gfix.exe -mend -full -ignore) остается ошибка "Number of index page errors". Backup/Restore после гфикса тоже ничего не дает. Как это исправить? И если не трудно киньте ссылочку где почитать что это за ошибка, или объясните коротенько.

veart писал(а):При исправлении базы gfix-ом (gfix.exe -mend -full -ignore)

хорошее "исправление".

veart писал(а):Backup/Restore после гфикса тоже ничего не дает.

Чего именно не даёт? Хочешь сказать, что индексы битыми остаются? Не верю (ц).

veart писал(а):где почитать

Про любой ремонт читать тут.

ошибки с индексами могут возникать, но чинить их никакого смысла нет.
Потому что при backup индексы НЕ СОХРАНЯЮТСЯ. Т.е. в бэкапе есть только их описания, и индексы строятся заново при restore.

Если после restore опять есть ошибки в индексах, значит это дерможелезо - диск, память и т.д. И здесь надо не чинить базу, а срочно менять железо, а то от базы вообще ничего не останется при очередной "починке".

Последоватальность действий:

gfix.exe -mend -full -ignore ...
Выдает - Number of index page errors : 36

gbak.exe -b -v -ig -g ...
gbak.exe -r -c -v ...

Потом опять проверка:
gfix.exe -v -full ....
ошибки остаются - Number of index page errors : 36

В логе b/r никаких ошибок не нашел
Эту статью http://www.ibase.ru/devinfo/db_repair.htm читал, по ней и делал.
Насчет железа - пробовал на разных компах, ошибки одинаковые.
Может в таблицах кривые данные, дубли и из-за них создаются не правильные индексы? (Неправильные пчелы... неправильный мед...) Или они бы просто не создались?

gbak.exe -r -c

ахинея. документацию читать будем, или как?

ошибки остаются - Number of index page errors : 36

при ресторе база СОЗДАЕТСЯ с нуля, полностью. Поэтому если она битая, значит все это происходит на ДЕФЕКТНОМ ЖЕЛЕЗЕ.

Может в таблицах кривые данные, дубли и из-за них создаются не правильные индексы?

бред. page errors это ошибки на страницах. дубли и "индексы" тут ни при чем.
что написано в firebird.log?

Или они бы просто не создались?

если не создались, то их в базе НЕТ. соответственно никаких page errors нет.

база сколько в zip занимает? можешь выложить?

veart писал(а):gbak.exe -r -c -v ...
...
Эту статью http://www.ibase.ru/devinfo/db_repair.htm читал, по ней и делал.

Уже видно, как ты статью внимательно читал.
Трудно что-то советовать, т.к. достоверность остальных твоих заявлений дискредитируется.

kdv писал(а):база сколько в zip занимает? можешь выложить?

У меня тут мысля бредовая мелькнула.
Если -R ресторить в базу, в которой кто-нибудь есть подключенный, то что будет? (никогда не пробовал )

Если -R ресторить в базу, в которой кто-нибудь есть подключенный, то что будет?

по крайней мере page errors не будет.

еще раз повторяю - Restore СОЗДАЕТ БАЗУ с нуля. Нет никакого "восстановления базы" из бэкапа.

1. gbak просит сервер создать НОВУЮ ПУСТУЮ базу с указанным именем и параметрами.
2. gbak переносит пользовательские метаданные из бэкапа в базу.
3. gbak переносит пользовательские данные из бэкапа в базу
4. gbak активирует (создает) все индексы в базе

никаких физических страничных операций с базой gbak не делает. gbak это обычная программа, которая как и ЛЮБАЯ ДРУГАЯ может СОЗДАТЬ БД, создать там метаданные и создать данные. Откуда эти данные и метаданные берутся - не имеет никакого значения. Это может быть файл бэкапа, а может быть ввод данных в программу человеком.

ключ -r пишу сознательно, все равно работаю с копией базы. Понимаю, что затирает полностью и создает с нуля. Если в чем-то другом ошибся - напишите. Что может этот ключ поменять? Если восстановить в другое место, не поверх старой что-то изменится? Коннектов к базе при b/r и gfix-e нет.

ключ -r пишу сознательно, все равно работаю с копией базы.

объясни пожалуйста, почему ты пишешь -c и -r ОДНОВРЕМЕННО.
Где ты такое вычитал или углядел.

все равно работаю с копией базы.

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

Ты лучше не мути воду, а каким-нибудь способом предъяви, как у тебя получается битая база после restore на разных компах.

kdv писал(а):

ключ -r пишу сознательно, все равно работаю с копией базы.

объясни пожалуйста, почему ты пишешь -c и -r ОДНОВРЕМЕННО.
Где ты такое вычитал или углядел.

Зануда. А -full и -ignore в сочетании с -mend в корневом тебя, значить, уже не удивляют?

значить, уже не удивляют?

это я в статье накосячил. исправлю.
при -mend никаких больше ключей не надо.
кроме того,
-mend -ignore сработает, а вот -mend -v -full вообще не будет работать. то бишь, incompatible switch combination.

Насчет -r -c , согласен, ошибся, хотя гбак на это не ругался, не думаю что это как-то повлияло на результат, он просто делал -r.
Насчет параметров gfix, по описанию не совсем понятно какие ключи использовать, писал как в статье. И вообще, как понял индексы восстанавливаются при restore и gfix с ключами тут не причем, или не так?
Сейчас все повторил так:
gfix.exe -mend ...
gbak.exe -b -v -ig -g ...
gbak.exe -c -v ... new.gdb

При b/r никаких ошибок в логах не нашел (ни в interbase.log ни в логах b/r).
При проверке new.gdb, опять - Number of index page errors : 36
В логе interbase.log (IB 7.5, если что):
36 раз одно и то же:
VEART-ASU (Server) Fri Oct 12 11:24:47 2007
Database: C:\PROGRAM FILES\BORLAND\INTERBASE\BIN\NEW.GDB
Index RDB$INDEX_28 is corrupt on page 166181 in table RDB$DEPENDENCIES (13)

В логе interbase.log (IB 7.5, если что):

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

Я не знаю, купленный он у них или нет. Я сам на Firebird'e. Просто подрабатываю еще, просили помочь. И какие нужны доказательства, что он купленный? На InterBase 2007 Developer Edition тоже будет такой глюк? Он же бесплатный.

Просто подрабатываю еще, просили помочь.

если купленный, с этим вопросом можно обратиться на support@ibase.ru.

И какие нужны доказательства, что он купленный?

просто сообщить, какие лицензии, когда и через кого были куплены.
также сообщить точную версию 7.5 (ibserver.exe, правая кнопка, Версия).

тоже будет такой глюк?

нет. на IB 2007 этого нет.

p.s. на исходный вопрос есть совершенно конкретный ответ в отношении 7.5. Вот прямо сейчас у меня перед глазами информация об этой проблеме, которая была обнаружена нами еще в мае 2006 года.
Но, дать этот ответ я могу при условии что 7.5 куплен. Это платный продукт, так что...

Спрашивал, админы там сами не знают, или говорят что не знают, наверное пиратский. Ладно, пусть сами разбираются.

админы там сами не знают, или говорят что не знают, наверное пиратский.

веселые админы, в контексте нынешних проверок.

Ладно, пусть сами разбираются.

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

есть и третий вариант - им была обещана помощь за мзду

Админы там не по БД, просто. Следят только за софтом, сеткой, железом и т.п. По базам я иногда помогаю, если чего не отваливается. Естественно за мзду . В этот раз видимо мзды не получу Лень разбираться, хотя, думаю, если это баг, надо просто скачать сервис пак или апдейт. Будет время, попробую.

Следят только за софтом, сеткой, железом и т.п.

как же они следят, если не могут понять, пиратский IB7.5 там или нет?
а что за приложение, собственно?