Давно ли вы заглядывали в firebird.log?

49 views
Skip to first unread message

Ovchinnikov Vasily

unread,
Mar 4, 2011, 2:23:42 AM3/4/11
to ru-b...@googlegroups.com
Здравствуйте,уважаемые!

Сегодня вновь, весело и с песнями, будем говорить о тревожном (привет Воронежу, ибо героически преодоленный
легкий испуг, как оказалось по результатам, совмещенный с полуторачасовым простоем автовокзала - такого никому
не пожелаешь).

После того, что я вам сегодня поведаю, только безумный скажет о том, что Firebird SQL - "ненадежная база
данных, применяемая в системах начального уровня". Коих мнений на просторах интернета - пруд пруди.
Откуда ноги растут у этого мифа - не тема нашей сегодняшней беседы. Но знайте, что вы ежедневно своим бытием в
роли системных администраторов опровергаете этот миф, успешно использую Firebird SQL в промышленной эксплуатации.

Примечание: а это - миф! Вы еще не знакомы с опытом создания и тестирования терабайтной базы данных
Firebird SQL причем на обычном настольном компьютере?
Интересующимся читать тут - http://ibase.ru/devinfo/fb1tb.htm

Итак, сегодня еще раз о важном, но игнорируемом аспекте проверок состояния системы - о лог-файле SQL-сервера
Firebird. От чего-то мы в системе до сих пор не предусмотрели средства просмотра сообщений этого файла. А ведь
своевременно заметить неисправность - это не менее важно, чем умение эту неисправность устранить.

Располагается файл по умолчанию тут: %Program Files%\Firebird\Firebird_1_5\firebird.log
Это обычный текстовый файл. Разве что ни слова по-русски там не найдете. Да и не требуется этого от него.
Он хранит в себе сообщения SQL-сервера, возникающие в ходе его работы. Там события запуска-остановки и
всяческие ошибки функционирования баз данных, обнаруженные в ходе обслуживания запросов к ним.

Ошибки там рано или поздно всегда появляются, но не всех их надо опасаться.
Некоторые из сообщений появляются по вполне прозаичным причинам: обрыв соединения, например, при отключении
питания на автовокзале, когда сервер работает от UPS, а клиентские компьютеры внезапно отключились во время
работы программы. Ну или при сбое маршрутизатора, например.
Эти ошибки содержат в себе упоминание о INET/inet_error.
Типовая ошибка такая выглядит так:

MY_SERVER_NAME Thu Dec 31 09:35:32 2010
INET/inet_error: read errno = 10054

Видите такие ошибки? Раз в месяц или реже? Ничего страшного.
Косяками идут по нескольку раз в день и при этом еще и пользователи жалуются на проблемы с программами? Ищите
проблемы в сети! Кабельное хозяйство перетряхните, коммутаторы и сетевые карты также под подозрение попадают.

А вот ежели увидали вы в логе нечто типа

MY_SERVER_NAME Thu Dec 30 10:55:18 2010
Database: F:\AWTSYS\BUSTER.FDB
page 276448, page type 5 lock conversion denied (215)

или
MY_SERVER_NAME Thu Dec 30 14:31:14 2010
Database: F:\AWTSYS\BUSTER.FDB
deadlock
page 276624, page type 5 lock conversion denied
internal gds software consistency check (error during savepoint backout (290))

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

Еще раз повторюсь, что коды ошибок могут быть разные. Их много. Подробнее смотрите на тематических сайтах и
форумах, посвященных Firebird SQL. Для вас самое важное, что требуется оценить - это присутствие в тексте
ошибки слов
internal gds software consistency check
и
page

При малейших сомнениях обращайтесь к нам в техподдержку - проконсультируем. Можете прислать фрагмент лог-файла
или лог-файл целиком (он не велик, как правило).

Что же произойдет, если вовремя не заметить такого рода ошибок в структуре базы данных, на которые указывает
сервер, и продолжать работу? Да ничего может и не произойти по первому времени.

Достаточно сказать, что по опыту разбора ситуаций при первичном ремонте баз данных (т.е. когда база сломалась
впервые после установки системы, и мы это совершенно точно помним, и анализируем firebird.log, памятуя про это)
(ВНИМАНИЕ!!!!)

СООБЩЕНИЯ ОБ ОШИБКАХ НАЧИНАЛИ ПОЯВЛЯТЬСЯ ЗА ПОЛГОДА И ДАЖЕ ЗА ГОД

(БУРНЫЕ АППЛОДИСМЕНТЫ!!!)

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

Согласитесь, что провести ремонт в плановом порядке гораздо предпочтительнее выполнения его же в авральном,
когда по закону подлости SQL-сервер будет неспособен обслуживать запросы после обеда в пятницу при
максимальном пассажиропотоке. Прошу простить мою несколько параноидальную пессимистичность, но закон Мерфи
(пусть они и шутливы) и его следствия никто не отменял.

Резюме: не забывайте время от времени заглядывать в файл %Program Files%\Firebird\Firebird_1_5\firebird.log
При малейших подозрениях в серьезности приведенных там ошибок не стесняйтесь и спрашивайте совета.

--
Regards,
Ovchinnikov Vasily
ova at tkvc ru


Reply all
Reply to author
Forward
0 new messages