Срочный вопрос!!!
Срочный вопрос!!!
InterBase 7.1 SP2
Что это за ошибка:
internal gds software consistency check (Bad base for bitmap SET operation) ???
Не могу найти ее описание!
Сегодня эта ошибка появляется постоянно! Работу с базой можно продолжать только после полного рестарта сервера.
BackUp/Restore - сделать пока не могу(честно говоря, я не уверен что поможет).
Что делать?
Что это за ошибка:
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
www.ibase.ru/devinfo/db_repair.htm
Ну вот и дождался!
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?
Как бороться, куда копать?
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?
Как бороться, куда копать?
-
- Сообщения: 9
- Зарегистрирован: 10 ноя 2004, 22:33
почему это "у меня предубеждение"??? CommitRetaining именно так и работает. то есть, с точки зрения сервера (удержание версий, застревание OIT, OST...) представляет собой длиннууууууую транзакцию, начинающуюся StartTransaction и завершающуюся Commit, с кучей CommitRetaining посередине. То есть, CommitRetaining никоим образом не "укорачивает" транзакцию.А CommitRetaining только в этой версии этой СУБД криво работает, или у вас к нему вообще предубеждение?
-
- Сообщения: 9
- Зарегистрирован: 10 ноя 2004, 22:33
где-где.... http://www.ibase.ru/devinfo/ibtrans.htm
и еще www.ibase.ru/devinfo/utl.htm
только Крэйг пишет, что якобы CommitRetaining можно делать бесконечно. Что неправда, и я специально отметил в переводе.
и еще www.ibase.ru/devinfo/utl.htm
только Крэйг пишет, что якобы CommitRetaining можно делать бесконечно. Что неправда, и я специально отметил в переводе.