Number of index page errors

[v_marenich]

Так-так, і налаштований на автоматичне завершення роботи у разі низького заряду АКБ. Ви не уявляєте, скільки я наробив шуму в суді, коли у нас здохла батарея. Страхувався тимчасово кількома звичайними безперебійниками, поки не вимолили нову батарею.

Нужно объяснять руководителю (-лям) последствия некооректного завершения работы с БД (существует определенная вероятность разрушения БД, при котором простой "бэкап/рестор" не поможет): либо придется откатывать базу на последний "бэкап" и "кучу" дел придется вводить заново, заново распределять судей (а поскольку автораспределение работает по случайному алгоритму, то дела пойдут другим судьям), а что хуже всего, может произойти рассогласование записей "главная/подчиненная" (будут "осиротевшие" записи) и логика работы будет нарушена, а об этом можно узнать спустя недели, месяцы... Это обернется огромной проблемой с огромными временными (и финансовыми тоже) затратами...
P.S. В своей практике наблюдал не один раз, когда "клиентам" приходилось вводить в базу все с нуля... Так что это реально.

[GDM]

Десь приблизно така розмова і була з ТУ ДСА ))

[uav1606]

Вот и я о том же. А нам всё не дадут нормального бесперебойника. А Eaton NV 600H что-то с сервером не дружит, у меня такое впечатление, что лучше было бы без него... В большинстве случаев он отрубается вместе с электричеством. То ли мощности не хватает, то блок питания сервера с этим ИБП "несовместим"...

[andrey]

Ну и итог вышесказаного. Какие действия предпринимаем?

[oaken]

Ну и итог вышесказаного. Какие действия предпринимаем?

мое личное мнение, нужно как минимум в Резерв БД внести изменения таким образом, чтобы:
  1. Ошибку проверки бд Number of record level errors исключить из ранга ошибок и, возможно, перевести ее в ранг сообщений.
  2. Ошибку проверки БД, которая заключается в невозможности валидации по причине отсутствия монопольного доступа к файлу БД - перевести в разряд сообщений.
  3. Опцию "отключение пользователей" сделать необязательной и по умолчанию отключенной.

[kontrol]

...
мое личное мнение, нужно как минимум в Резерв БД внести изменения таким образом, чтобы:

Теж особиста думка по пунктам:

1. Ошибку проверки бд Number of record level errors исключить из ранга ошибок и, возможно, перевести ее в ранг сообщений.

1. - не згоден. Якщо піти таким шляхом, то через рік 90% помилок просто не будуть відображатися, і хоч користувачі і будуть радіти що в них "немає помилок", але ж вони будуть і їх накопичення може призвести до серйозного збою в БД.

2. Ошибку проверки БД, которая заключается в невозможности валидации по причине отсутствия монопольного доступа к файлу БД - перевести в разряд сообщений.

2. - можливо, але особисто мені так не подобається.

3. Опцию "отключение пользователей" сделать необязательной и по умолчанию отключенной.

3. - ні в якому разі!. Якщо людина збирається зробити резервну копію бази, то до зупинки БД, вона повинна обов'язково подивитися хто зараз працює з БД і мати можливість відключати підключення до БД по-штучно а не "відрубати всіх автоматично".

[oaken]

1. "Number of record level errors" - это не ошибка в классическом ее понимании. Не путать с Index Page Error 
2. Валидация БД - сугубо ручная операция и делать ее автоматом - зло, а тем более делать какие-то выводы полсе проведения валидации в автоматическом режиме.
3. Резервирование можно и нужно проводить без отключения пользователей!!! И чем чаще - тем лучше)

[Ярослав]

Дело в том, что кэшируются не только индексы, но и данные... Будут те же проблемы, что и с индексами + проблемы с  битыми страницами данных. Бэкап рестор здесь уже не поможет. А вообще по умолчанию в Firebird установлена опция кэширования... Думайте сами 

Відключив дану опцію, ДЗС - лагає жах гілки відкриваються з інтервалом у 15-20 сек

[Юрій]

Мне кажется что ошибка рандомная так как у нас проверки делаются с отключением каждый день а ошибка проскакивает один раз в неделю бывает в две недели, каких либо определённых факторов влияющих на появление не выявил, периодичность появления разная, вот только на версии ДАС 1.15 она появлялась 1 раз в два, три месяца, а теперь по чаще )) Жду 1.17 поглядим как себя будет вести "резерв" 

[Ярослав]

Вот пару дней нормально и опять и никто не был подключен
Еще заметил что за 4 дня работы размер базы не изменялся  хотя доков по делам сотни

[numega]

Мне кажется что ошибка рандомная так как у нас проверки делаются с отключением каждый день а ошибка проскакивает один раз в неделю бывает в две недели, каких либо определённых факторов влияющих на появление не выявил, периодичность появления разная, вот только на версии ДАС 1.15 она появлялась 1 раз в два, три месяца, а теперь по чаще )) Жду 1.17 поглядим как себя будет вести "резерв" 

Меня, вот, честно, просто интерес взял, база на MySQL вела бы себя так же, или нет?)

[oaken]

Меня, вот, честно, просто интерес взял, база на MySQL вела бы себя так же, или нет?)

База а тем более сервер тут нипричем... Резерв БД сам же и "ломает" базы всякого рода отключениями. Сейчас идет разработка новой версии резерва, где мы постараемся устранить большинство ошибок.
А мускул просто предназначен для других задач и сравнивать Firebird c ним не очень корректно.

[Ярослав]

Мне кажется что ошибка рандомная так как у нас проверки делаются с отключением каждый день а ошибка проскакивает один раз в неделю бывает в две недели, каких либо определённых факторов влияющих на появление не выявил, периодичность появления разная, вот только на версии ДАС 1.15 она появлялась 1 раз в два, три месяца, а теперь по чаще )) Жду 1.17 поглядим как себя будет вести "резерв" 

Меня, вот, честно, просто интерес взял, база на MySQL вела бы себя так же, или нет?)

Там есть фишка "База отмечена как подозрительная" ыыы