iBase.ru Forum

InterBase 7.1 SP2

Что это за ошибка:
internal gds software consistency check (Bad base for bitmap SET operation) ???

Не могу найти ее описание!
Сегодня эта ошибка появляется постоянно! Работу с базой можно продолжать только после полного рестарта сервера.
BackUp/Restore - сделать пока не могу(честно говоря, я не уверен что поможет).

Что делать?

ошибки такой не слышал, но internal gds software consistency check это дело известное.

www.ibase.ru/devinfo/db_repair.htm

Судя по Interbase.log после gfix - рушатся индексы!

Index 11 is corrupt on page 530666 in table OUTBOOK (173)
Index 2 is corrupt on page 514626 in table MOTION (181)
Index 2 is corrupt on page 514626 in table MOTION (181)
и т.д.

Как с этим бороться?

перейти на 7.5.

И это решит проблему? (С IB7.0 таких косяков не было...)
А не нет ли у 7.5 каких-нибудь других отрицательных особенностей?

переходить на 7.5 не обязательно. базу надо сначала починить.

переходить на 7.5 не обязательно. базу надо сначала починить.

Сделал вчера базе backup/restore.
Жду сообщений об ошибках(хорошо если напрасно жду).

смотри в interbase.log

там и смотрю...
Пока кроме 10054 ничего не было.

Ну вот и дождался!

mySERV (Server) Wed Apr 20 15:30:21 2005
Database: D:\WORK\DBREESTR\REESTR.GDB
database file appears corrupt ()
wrong page type
page 137651 is of wrong type (expected 7, found 82)
internal gds software consistency check (error during savepoint backout (290), file: exe.c line: 1792)

После проверки gfix-ом:
Relation has 1 orphan backversions (0 in use) in table TMP$POOLS (68)
Index 5 is corrupt on page 428502 in table OUTBOOK (173)
Index 6 is corrupt on page 428919 in table OUTBOOK (173)
Index 10 is corrupt on page 430468 in table OUTBOOK (173)
Index 11 is corrupt on page 137651 in table OUTBOOK (173)
Page 562174 is an orphan
и далее куча orphan-ов...
Грохнул я эти 4 индекса, создал по новой, все работает...

Почему могут портиться индексы? (В IB5.6 и 7.0 таких проблем не было).
Это баг 7.1?
Как бороться, куда копать?

Больше всего похоже на последствия краша сервера или оси. FW - on?

FW - ON
Операционка - Win 2000 Adv.serv SP4.
Система, вроде, работает нормально. В сист. логе - все чисто.

CommitRetaining пореже использовать.

CommitRetaining - вообще не используем.

А CommitRetaining только в этой версии этой СУБД криво работает, или у вас к нему вообще предубеждение?

А CommitRetaining только в этой версии этой СУБД криво работает, или у вас к нему вообще предубеждение?

почему это "у меня предубеждение"??? CommitRetaining именно так и работает. то есть, с точки зрения сервера (удержание версий, застревание OIT, OST...) представляет собой длиннууууууую транзакцию, начинающуюся StartTransaction и завершающуюся Commit, с кучей CommitRetaining посередине. То есть, CommitRetaining никоим образом не "укорачивает" транзакцию.

Често говоря я именно и полагал, что тразакция каждый раз стартует заново. Ибо номер транзакции не может не измениться - как иначе отличить данные до и после вызова CommitRetaining.

Гы, да об том и речь. Номер-то растёт, а контекст сохраняется. То бишь, ресурсы, связанные с транзакцией, удерживаются с момента старта самой первой из этой скрытой цепочки. И остальным транзакцям приходится иметь это в виду.

Где почитать можно?

где-где.... http://www.ibase.ru/devinfo/ibtrans.htm

и еще www.ibase.ru/devinfo/utl.htm
только Крэйг пишет, что якобы CommitRetaining можно делать бесконечно. Что неправда, и я специально отметил в переводе.