Пропала информация при сбое питания
Модераторы: kdv, Alexey Kovyazin
Пропала информация при сбое питания
Сегодня произошел сбой питания сервера. На сервере 3 БД. К одной из них в этот момент подключений не было, к двум были. И на всех трех базах потерялись данные за последнии 9 дней, т.е. последнии данные остались за 06.02.06, последний перезапуск сервера был 03.02.06. Почему такое может быть? Неужели сервер держит данные в кэше за 9 дней? Объем даныых не большой: в две БД менее 1000 записей в день, в третью 2000-3000 тысячи.
ПО работает несколько лет во многих местах, подобный лсучай первый. В чем может быть проблема? После перезапуска было сделано несколько запросов к данным таблицам, думаю с полным fetch, могли ли остаться потерянные данные как проверить?
ПО работает несколько лет во многих местах, подобный лсучай первый. В чем может быть проблема? После перезапуска было сделано несколько запросов к данным таблицам, думаю с полным fetch, могли ли остаться потерянные данные как проверить?
сервер-то какой версии?
вариантов несколько.
1. в базах Forced Write=Off, в результате изменения "застряли" в кэше операционной системы. При сбое питания - да, данные пропадут.
В Firebird 1.5 такой проблемы нет.
2. повредились индексы, поэтому последние записи "не видны".
нужно сделать запрос, который не будет использовать индексы, и посмотреть, есть ли данные.
можно еще попробовать IBUndelete -
http://www.ibundelete.com/features.html
если записи эти на диске есть, то он их покажет. хотя, он покажет в том числе и удаленные обычным способом записи.
вариантов несколько.
1. в базах Forced Write=Off, в результате изменения "застряли" в кэше операционной системы. При сбое питания - да, данные пропадут.
В Firebird 1.5 такой проблемы нет.
2. повредились индексы, поэтому последние записи "не видны".
нужно сделать запрос, который не будет использовать индексы, и посмотреть, есть ли данные.
можно еще попробовать IBUndelete -
http://www.ibundelete.com/features.html
если записи эти на диске есть, то он их покажет. хотя, он покажет в том числе и удаленные обычным способом записи.
Сервер Firebird 1.5.2
Сделал запрос с планом PLAN SORT ((CHECKS NATURAL))
записий столь ко же.
IBUndelete - пробовал говорит нет помеченных записей.
Но после этого было несколько запросов именно к данным таблицам.Самое интересное, что в трех базах записи удалились именно до 6 числа .
Последнии записи лога сервера:
SERVER (Client) Fri Feb 03 12:13:18 2006
Guardian starting: c:\firebird\bin\fbserver.exe
SERVER (Client) Wed Feb 15 16:38:14 2006 - вот здесь был сбой питания
Guardian starting: c:\firebird\bin\fbserver.exe
Сейчас уже не до данных, выяснить бы причину и как этого избежать. При каких либо сбоях, зависаниях сервера.
Сделал запрос с планом PLAN SORT ((CHECKS NATURAL))
записий столь ко же.
IBUndelete - пробовал говорит нет помеченных записей.
Но после этого было несколько запросов именно к данным таблицам.Самое интересное, что в трех базах записи удалились именно до 6 числа .
Последнии записи лога сервера:
SERVER (Client) Fri Feb 03 12:13:18 2006
Guardian starting: c:\firebird\bin\fbserver.exe
SERVER (Client) Wed Feb 15 16:38:14 2006 - вот здесь был сбой питания
Guardian starting: c:\firebird\bin\fbserver.exe
Сейчас уже не до данных, выяснить бы причину и как этого избежать. При каких либо сбоях, зависаниях сервера.
forced write в базах = off?
По поводу сбоев и т.п. - читать
www.ibase.ru/devinfo/db_repair.htm
а также
www.ibase.ru/devinfo/sys_failure.htm
вообще для FB 1.5.2 такая ситуация весьма странна - в конфиге есть параметры (и по умолчанию), на тему сброса кэша при fw=off. Эти параметры как раз и были введены в 1.5:
MaxUnflushedWrites
This parameter was introduced in Version 1.5 to handle a bug in the Windows server operating
systems, whereby asynchronous writes were never flushed to disk except when the Firebird server
underwent a controlled shutdown. Hence, on 24/7 systems, asynchronous writes were never flushed at all.
гм, я может грубо скажу, но не надо бросать базу. то есть, не надо оставлять ее без надзора, если никакие (!) меры по автоматизации резервного копирования и т.п. не применялись.Сейчас уже не до данных, выяснить бы причину и как этого избежать. При каких либо сбоях, зависаниях сервера.
По поводу сбоев и т.п. - читать
www.ibase.ru/devinfo/db_repair.htm
а также
www.ibase.ru/devinfo/sys_failure.htm
вообще для FB 1.5.2 такая ситуация весьма странна - в конфиге есть параметры (и по умолчанию), на тему сброса кэша при fw=off. Эти параметры как раз и были введены в 1.5:
MaxUnflushedWrites
This parameter was introduced in Version 1.5 to handle a bug in the Windows server operating
systems, whereby asynchronous writes were never flushed to disk except when the Firebird server
underwent a controlled shutdown. Hence, on 24/7 systems, asynchronous writes were never flushed at all.
-
- Сообщения: 15
- Зарегистрирован: 25 окт 2004, 19:13
Автоматизации копирования не было по тому, что систему только установили 30,01,2006 и посути работа идет в режиме настройки, тестирования. До резервного копирования руки не дошли. Как всегда.гм, я может грубо скажу, но не надо бросать базу. то есть, не надо оставлять ее без надзора, если никакие (!) меры по автоматизации резервного копирования и т.п. не применялись.
Вот их я как то выпустил из виду, не знал. Хм. Они не были установлены, т.е. по умолчанию.вообще для FB 1.5.2 такая ситуация весьма странна - в конфиге есть параметры (и по умолчанию), на тему сброса кэша при fw=off. Эти параметры как раз и были введены в 1.5:
MaxUnflushedWrites
Да ни кто их ни куда не копировал. Звонит клиент, говорит моргнул свет, и данные потерялись, а ИБП увезли в сервис меньть аккамуляторы, неделю назад .Alexey Kovyazin писал(а):Если был бы Линукс, тогда понятно - копирование БД при неотключенных пользователях.
А так не очень понятно. Базы точно не поврежденные?
Неправильные значения нескольких генераторов, меньше чем нужно. В остальном вроде нет.Базы точно не поврежденные?
Только что нашел в ветке:
Продолжительность непрерывной работы FB сервера от 06,04,05
Значит не я первый, хотя все равно обидно.Кому интересно нашел пример на ibase:
Не знаю как Firebird и Win2003, но у меня (Win2000 + IB7) однажды произошел полный откат на два дня, т.е., до момента последней перезагрузки. Хотя до этого сервак молотил неделями без проблем. И честно тебе скажу, ничего веселого в этом нет. Если в работе есть перерывы, то лучше перегружаться, и желательно на холодную.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Да сегодня выяснили, именно он это и был! Помогла отмена восстановления. Один "умный" человек после перезагрузки согласился на вопрос восстановить.Dimitry Sibiryakov писал(а):А не вмешался ли здесь печально известный System Restore, подсунувший файлы, сохраненные при последней перезагрузке?..
Но я не понимаю, восстонавливает система свои файлы, хорошо, но зачем чужие базы трогать.
это сила! надо будет запомнить. с другой стороны, для system restore операционка же должна скопировать исходный файл при начале его изменения. И вы это что, терпите? www.ibase.ru/ibfaq.htm#xp
Вообще я настраивая сисему всегда отключаю, систем рестори, упаковку файлов, лишние службы и т.д., но в данном случае как я и писал система только недавно была установлена, оптимизировать руки не дошли, базу почти пустые около 30 мбkdv писал(а): Хотя, если база микроскопическая, на уровне 5-10 мегабайт, то тогда вполне реально. Задержку с первым коннектом на 2-10 секунд не воспринимают как нечто необычное, ну и ...