Index page errors. Как лечить и что означает.
Модераторы: kdv, Alexey Kovyazin
Index page errors. Как лечить и что означает.
При исправлении базы gfix-ом (gfix.exe -mend -full -ignore) остается ошибка "Number of index page errors". Backup/Restore после гфикса тоже ничего не дает. Как это исправить? И если не трудно киньте ссылочку где почитать что это за ошибка, или объясните коротенько.
Re: Index page errors. Как лечить и что означает.
хорошее "исправление".veart писал(а):При исправлении базы gfix-ом (gfix.exe -mend -full -ignore)
Чего именно не даёт? Хочешь сказать, что индексы битыми остаются? Не верю (ц).veart писал(а):Backup/Restore после гфикса тоже ничего не дает.
Про любой ремонт читать тут.veart писал(а):где почитать
ошибки с индексами могут возникать, но чинить их никакого смысла нет.
Потому что при backup индексы НЕ СОХРАНЯЮТСЯ. Т.е. в бэкапе есть только их описания, и индексы строятся заново при restore.
Если после restore опять есть ошибки в индексах, значит это дерможелезо - диск, память и т.д. И здесь надо не чинить базу, а срочно менять железо, а то от базы вообще ничего не останется при очередной "починке".
Потому что при 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 читал, по ней и делал.
Насчет железа - пробовал на разных компах, ошибки одинаковые.
Может в таблицах кривые данные, дубли и из-за них создаются не правильные индексы? (Неправильные пчелы... неправильный мед...) Или они бы просто не создались?
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 читал, по ней и делал.
Трудно что-то советовать, т.к. достоверность остальных твоих заявлений дискредитируется.
по крайней мере page errors не будет.Если -R ресторить в базу, в которой кто-нибудь есть подключенный, то что будет?
еще раз повторяю - Restore СОЗДАЕТ БАЗУ с нуля. Нет никакого "восстановления базы" из бэкапа.
1. gbak просит сервер создать НОВУЮ ПУСТУЮ базу с указанным именем и параметрами.
2. gbak переносит пользовательские метаданные из бэкапа в базу.
3. gbak переносит пользовательские данные из бэкапа в базу
4. gbak активирует (создает) все индексы в базе
никаких физических страничных операций с базой gbak не делает. gbak это обычная программа, которая как и ЛЮБАЯ ДРУГАЯ может СОЗДАТЬ БД, создать там метаданные и создать данные. Откуда эти данные и метаданные берутся - не имеет никакого значения. Это может быть файл бэкапа, а может быть ввод данных в программу человеком.
объясни пожалуйста, почему ты пишешь -c и -r ОДНОВРЕМЕННО.ключ -r пишу сознательно, все равно работаю с копией базы.
Где ты такое вычитал или углядел.
не надо привыкать убивать базу при restore. задумаешься о чем-то другом, маханешь -r вместо -c - угробишь рабочую базу.все равно работаю с копией базы.
кроме того, в FB 2.x специально изменили -r так, чтобы у любителей этого ключа хоть на время отпало желание его использовать (и в скриптах тоже -r больше не пройдет в старом виде).
Ты лучше не мути воду, а каким-нибудь способом предъяви, как у тебя получается битая база после restore на разных компах.
Насчет -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)
Насчет параметров 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)
если купленный, с этим вопросом можно обратиться на support@ibase.ru.Просто подрабатываю еще, просили помочь.
просто сообщить, какие лицензии, когда и через кого были куплены.И какие нужны доказательства, что он купленный?
также сообщить точную версию 7.5 (ibserver.exe, правая кнопка, Версия).
нет. на IB 2007 этого нет.тоже будет такой глюк?
p.s. на исходный вопрос есть совершенно конкретный ответ в отношении 7.5. Вот прямо сейчас у меня перед глазами информация об этой проблеме, которая была обнаружена нами еще в мае 2006 года.
Но, дать этот ответ я могу при условии что 7.5 куплен. Это платный продукт, так что...
веселые админы, в контексте нынешних проверок.админы там сами не знают, или говорят что не знают, наверное пиратский.
им решать. непонятно другое. у них рук нет, и они не могут сами спросить, или так страшно боятся? или не знают где спросить?Ладно, пусть сами разбираются.
есть и третий вариант - им была обещана помощь за мзду