Постоянно выходят ошибки при перезагрузки компьютера

Linux + Firebird 2.5



суть экспермента берем базу данных делаем
1. gfix - v -full /db/dm.fdb
выдает пустую строчку
=> т.е. условно считаем что ошибок нет

2. далее запускаем долгий запрос минут на 30

3. через 10 минут выполняем в линукс команду reboot / ну или выключение питания

4. после перезапуска делаю gfix
выдает кучу ошибок порядка 1000

пробовал включать синхронный / асинхронный режим работы
тот же эфект

как защитить базу данных от подобных проблемм?

wadman,


gfix -write sync database.gdb

От кривых рук?

1. от того что "комп зависает"
2. от вынужденоой перезагрузки когда свет отключают более чем на 2 минуты и в этов ремя выполнялся долгий запрос

> С теневой может есть смысл поэкспериментировать?

что такое "теневой"

Forced writes=On

про тень нашел тут
http://www.firebirdsql.su/doku.php?id=shadow


Линукс десктопный (тоесть с графической оболочкой и за ним работает пользователь) или консольный удаленный?
да графический за ним работают и база лежит тамже + 1-3 кассы
около 200 объектов

юпсы стоят,
1 но пользователи "любят" перезагружать компы.
2 покупка второго винта достаточно накладное мероприятие
3 при теневом копировании могут ли попасть ошибки из основной базы в теневую?

hvlad,

а как вообще происходит теневое копирование базы данных? какие маханизмы в этом участвуют и почему теневое копирование не подверженно таким же сбоям?

>конечно, есть вариант что "долгий запрос" это запрос модификации данных, в результате выходят orphan pages, но тут можно особо не волноваться, если вас вообще как-то слабо волнует сам факт вырубания компьютеров по питанию.


в тестовом примере был именно update запрос


>если вас вообще как-то слабо волнует сам факт вырубания компьютеров по питанию.

нас волнует этот вопрос

и допустим есть 200 удаленных от офиса машин c бд Firebird в которых могут возникнуть проблеммы с питанием
допустим каждом 20-ом и раз в месяц
это 10 проблемных магазинов в месяц.

по факту конечно меньше примерно 1-2 мага в неделю но как то не по себе становиться....
а с учетом того что база летит от "дуновения" (некоректного выключения компьютера) или вынужденной перезагрузки
встает вопрос о надежности решения на базах firebird.... хотелось бы увидеть решение которое учитывает реалии.

вопрос как происходит update в firebird? с точки зрения оборудования и файловой системы. что куда пишется? и почему возникают такие проблеммы?

идите ли, если записывать практически в любой файл хоть сколь-нибудь связанную информацию, и не успеть записать ее всю из-за "ресета", то эта связанная информация перестает быть связанной, она становится поломанной.
А база - это именно хранилище связанной информации. Причем "связанной" в своем смысле - страницы данных, индексов, страницы указателей, страницы занятости страниц, и так далее.
А записать всю связанную информацию одним махом не получится, носители информации пока еще этого не позволяют.

про orphan pages я уже сказал, что это по факту не является повреждением, его можно игнорировать. Ни про какие shadow вам читать нельзя, пока не прочитаете
http://www.ibase.ru/devinfo/db_repair.htm


все бы было бы замечательно, если бы не одно но

>и не успеть записать ее всю из-за "ресета",

а зачем он вообще вносит изменения если я еще commit не выполнил

miwaonline,
Иди поставь в аналогичные условия mysql/postresql/oracle/mssql/whatever, потом приходи, поделишься впечатлениями
txt / csv файл работает нормально
dbf / access тоже

насчет oracle не скажу так как не видел и времени эксперементировать нет. знаю что у него есть логирование и таблица отката изменений un-log


>У тебя есть реально поломанная БД, или это твоим "тестом" навеяло ?
сейчас только тесты, но и бывают поломанные мы их гфикс с мендом + бекап / рестор и все проходит (от 1 часа)
страшно надоело гфикс и бекап рестор...


при Forced writes=Off
выходило сообщение

Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
internal Firebird consistency check (can't continue after bugcheck).

kdv,
запрос был вида
update nab set
nnum3=(select sum(rnum1) from rma where rid1=nidlib) where nconcept in (100801,294000100)
чтоб подольше выполнялся
в nab 8 млн записей в rma 200 000 примерно...

> grep -i bugcheckabort /opt/firebiord/firebird.conf

ls -R -la /opt/firebird | grep .debug

команды я в ibexpert-e вбивал


> Вот только с Firebird что то не так, да?

могу все показать в демонстрации экрана через skype

denis.new.skype

только сегодня у нас уже вечер (я из Уфы)
можно завтра в 10-00 мск-а!?

>Которые по мановению волшебной палочки пишутся строго синхронно и строго мгновенно на любой накопитель с любой скоростью доступа.
который пишет не в основную структуру, а в доп таблицу, а в случаи комита меняет где надо байты...

задача не писать что firebird ... а чего хотелось бы чтоб было улучшено для стабильности работы системы.
firebird - the russian Oracle...

автор в Script Executive, да ? и что же он в ответ "сказал" ?

Unsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
internal Firebird consistency check (can't continue after bugcheck).

авторТак вот: для работы в базой в качестве админа вам понадобится хотя бы минимальный навык работы в командной строке.


как бы умеем...

kdv,

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

а если электричестов ночью вырубается чтоб юпс комп правильно гасил?

а если комп просто зависнет - просто из разетки выдернут и все.... еще хуже будет....

авторПовторяю вопрос: ты понимаешь что делает опция Forced Writes?

да понимаю, перед записью данных на винт пишет их в кеш (ОЗУ/RAM), и в случаи отключения питания теряет эти данные....

авторТы валидацию повторную сделал после своего теста ? Или где ? :)

что такое валидация?
gfix -v -full /db/db.fbd
gfix -mend /db/db.fbd
сделал

авторЯ тебе страшную тайну открою (правда она в документации расписанаи у КДВ на сайте), но для тебя это будет откровнением. Пока нет коммита данные пишутся в файл базы, но на них не "переводятся стрелки", по коммиту "где надо" меняются байты, и вуаля все в порядке. Если данные писаться начали, но коммит по каким-то причинам не произошел, то все те странички в БД, на которые не "перевели стрелки" становятся так называемыми "орфанами" и потом, когда ты запускаешь гфикс он эти самые орфаны метит как свободные страницы.

Постарался написать в терминологии автора топика. :)

вот! и эти данные не должны влиять если я сделаю

авторselect * from table_name

а после перезагрузки до комита (при Forced writes=Off)

выходит сообщение



авторUnsuccessful execution caused by a system error that precludes successful execution of subsequent statements.
internal Firebird consistency check (can't continue after bugcheck).