Потеряна информация при сбое питания Firebird

← →
atruhin © (2006-02-15 15:50) [0]

Сегодня произошел сбой питания сервера. На сервере 3 БД. К одной из них в этот момент подключений не было, к двум были. И на всех трех базах потерялись данные за последнии 9 дней, т.е. последнии данные остались за 06.02.06, последний перезапуск сервера был 03.02.06. Почему такое может быть? Неужели сервер держит данные в кэше за 9 дней? Объем даныых не большой: в две БД менее 1000 записей в день, в третью 2000-3000 тысячи.
ПО работает несколько лет во многих местах, подобный случай первый. В чем может быть проблема? После перезапуска было сделано несколько запросов к данным таблицам, думаю с полным fetch, могли ли остаться потерянные данные как проверить?

← →
Johnmen © (2006-02-15 16:10) [1]

9 дней срок большой, и ForceWrite False здесь, видимо, непричём...
В плане бреда - м.б. длиннющие пишущие транзакции были на момент сбоя?
Если данные потеряны, то м.сказать, что навсегда...

← →
Виталий Панасенко (2006-02-15 16:28) [2]

"Есть мнение" на WWW.IBASE.RU, что к такому рез-ту может привести порча индекса. Правда, мнение, если идет выборка по условию.Если же full scan(select * from table), то должно показать в любом случае

← →
unknown © (2006-02-15 16:29) [3]

Можно попробовать gfix-ом пофиксить бд, возможно сбились ссылки страниц бд
(да еще много чего м.б.)

← →
DSKalugin © (2006-02-15 16:44) [4]

http://ibase.ru/devinfo/db_repair.htm

← →
Desdechado © (2006-02-15 17:14) [5]

если данных не много изменяется, то сервер вполне мог их в кэше держать до вытеснения

← →
atruhin © (2006-02-15 17:56) [6]

>>http://ibase.ru/devinfo/db_repair.htm
Читал неоднократно.
>>Если же full scan(select * from table), то должно показать в любом случае
Пробовал. Нет их.
>>
В плане бреда - м.б. длиннющие пишущие транзакции были на момент сбоя?
Нет с разными базами работают разные клиенты комплекса, на ночь все отключаются.
на WWW.IBASE.RU я тоже задал этот вопрос, пока ни чего вразумительного. :( Кто сказал бы про такое, сам не поверил бы. Не знаю что и предположить.
Сейчас речь уже не о данных, пытаюсь доискаться причины, чтобы предотвратить в дальнейшем.
>>если данных не много изменяется
В двех бызах изменений данных нет, только добавление. За 9 дней по трем базам не менее 27 тыс. записей. Неужели может хранить все это в кэше 9 дней и не скинуть на диск?
На ibase подсказали параметры (не знал о них, упустил)
#MaxUnflushedWrites = 100
#MaxUnflushedWriteTime = 5
у меня они были закоментированны, по умолчанию. Но ведь должны же быть разумные сроки.

← →
atruhin © (2006-02-15 19:05) [7]

Кому интересно нашел пример на ibase:
Не знаю как Firebird и Win2003, но у меня (Win2000 + IB7) однажды произошел полный откат на два дня, т.е., до момента последней перезагрузки. Хотя до этого сервак молотил неделями без проблем. И честно тебе скажу, ничего веселого в этом нет. Если в работе есть перерывы, то лучше перегружаться, и желательно на холодную.
Значит не я первый, хотя все равно обидно. :(

← →
AlexWlad © (2006-02-15 19:20) [8]

> atruhin © (15.02.06 19:05) [7]

Не перегружаться надо, а бэкапы регулярно делать. Регулярность зависит от критичности данных.

← →
Anatoly Podgoretsky © (2006-02-15 19:34) [9]

А чего плакаться то и тратить силы на восстановления, данные это стоят меньше стоимости UPS, не стоит и рыпаться

← →
atruhin © (2006-02-15 19:49) [10]

>>[8] AlexWlad © (15.02.06 19:20)
>>Не перегружаться надо, а бэкапы регулярно делать.
Если бы внимательно прочитал, увидел что это цитата с ibase. И суть не в предложенном способе, а в том что такое имеет место быть.
>>данные это стоят меньше стоимости UPS
Ну я клиенту это же сказал. Они где то неделю как аккумулятор на УПСе меняют. А вообще система находится п процессе ввода в эксплуатацию/ тестирования, до автобэкапа руки не дошли. И вопрос не о потере данных, а о том что такое возможно, а это очень расстраивает. Не должен SQL сервер при сбое терять данные за несколько дней.

← →
Johnmen © (2006-02-15 20:11) [11]

Есть сильные подозрения, что виноват не сервер, а винды. Докешировались...

← →
Anatoly Podgoretsky © (2006-02-15 20:23) [12]

atruhin © (15.02.06 19:49) [10]
Такое возможно, а что бы не было возможным - переходи на MS SQL или другую промышленную СУБД

← →
unknown © (2006-02-15 20:49) [13]

Все зависит от разработчика.
Можно подумать, в > MS SQL или другую промышленную СУБД исключается возможность потери данных

← →
Anatoly Podgoretsky © (2006-02-15 21:04) [14]

Не исключена - выход из строя винчестеров

← →
atruhin © (2006-02-15 21:16) [15]

Всем спасибо. На другой сервер перейти нет возможности к сожалению. В принципе это первый раз за 5 лет работы. Будем жить! :)

Начать с управляемого UPS

Не ты первый. У меня тоже была подобная х.... пару лет назад. И точно также никто ничего путнего не подсказал.

Методом науного втыка выяснилось (потому, как глюк в лабораторных условиях удолсь вызвать заново !!!), что Interbase/Firebird тута не причем. Это винды. У меня было 2ГБ ОЗУ и 4 проца, а я забыл выключиь своп (так назваемый файл подкачки, в настройках:"Мой компьютер -> Свойства -> Дополнительно -> Быстродействие" ).

Дык вот, вывод: Если у тебя стоит WinNT (WinXP, Win2k, Win2k3), а также RAID или SCSI контроллер ЖД, то своп нужно рубить на фиг, иначе такие глюки будут не только к IB/FB, а й с файлами в расшаренных папках, открытыми с сервака по сети.

Тоже выяснил. Путем следственно оперативных действий нашел умного человака, который вчера оказавается сделал "Восстановление системы" на точку сохранения девятидневной давности. :) Помогла отмена восстановления.
Одного не пойму. Ну восстонавливает винда системные файлы, но нафиг чужие базы то трогать?

>>А у тебя файлы БД GDB или FDB? Вроде GDB в ХР зарегистрированный тип.
У меня GDB. А под что оно зарезервированно? Первый раз слышу о таком. Век живи, век учись!

Ну вот, я же намекал в [13], что "каждый сам себе злобный буратина" (с)

Потеряна информация при сбое питания Firebird Найти похожие ветки