происходит рестарт IB сервера.

← →
AlexA (2003-04-29 16:10) [0]

При попытке выбора данных из таблицы происходит рестарт IB сервера.
При Backup базы происходит следующие
Backup started on Mon Apr 28 08:01:31 2003...

gbak: gbak version WI-V5.5.0.742
gbak: Version(s) for database "C:\Base\PATP_Pl.GDB"
InterBase/x86/Windows NT (access method), version "WI-V5.5.0.742"
on disk structure version 9.1
gbak: ERROR: connection lost to database
gbak: ERROR: gds_$receive failed
gbak: Exiting before completion due to errors
gbak: ERROR: connection lost to database

Backup exited unsuccessfully on Mon Apr 28 08:03:09 2003

Просматриваем св-ва IB Guardian
....
Abnormal Termination 04/28/103 08:03
Server Started 04/28/103 08:03

Что случилось, Что делать что бы не повторилось?

← →
Zacho (2003-04-29 18:39) [1]

IB 5.5 печально знаменит своими многочисленными багами. Сильно рекомендую перейти хотя бы на 5.6 (кстати, припоминаю,что какие-то из багов 5.5, исправленные в 5.6, приводили к разрушению БД), а лучше - на FB или Yaffil.
Случится могло все, что угодно, скорее всего повреждена база. Сделай validation базы, посмотри, что в interbase.log, попробуй вспомнить, после чего это началось и т.п. По поводу "Что делать что бы не повторилось?" советую почитать http://www.ibase.ru/devinfo/dontdoit.htm

← →
AlexA (2003-04-29 23:25) [2]

>Zacho
спасибо, попозже перейду.
Ни чего подобного не делал , предложеного в документе

← →
kaif (2003-04-29 23:31) [3]

обычно у меня причиной connection lost to database всегда бывали бесконечные рекурсивные вызовы из за ошибок при отладке рекурсивных хранимых процедур. Это может произойти и из-за неправильно продуманного триггера, рекурсивно вызывающего самого себя, например триггера before update, который делает в своем теле update той же записи в той же таблицу, но это не тот случай, так как в данном случае это происходит в select-е
У меня такое ощущение, что других причин, кроме рекурсивных зацикливаний у такой ошибки я не наблюдал.

← →
AlexA (2003-04-29 23:36) [4]

> kaif
Вряд ли это имело место быть за время выходных операторы убили базу, ничего нового они там сделать не могли! Завтра еще раз проверю. Спасибо!

← →
AlexA (2003-04-30 21:09) [5]

> kaif
Нет такого триггера

← →
Desdechado (2003-05-01 13:03) [6]

определись для начала, какие запросы, к каким именно таблицам, с какими именно условиями WHERE приводят к такому. Это даст понимание, где затык.
Судя по логу, gbak не может даже метаданные прочитать, а это говорит о возможной порче корневых страниц.
А вообще причин много.
http://www.ibase.ru/devinfo/db_repair.htm
На этой странице и услуги по реанимации предлагают

← →
sunrider (2003-05-01 15:13) [7]

Прежде чем делать backup нужно убрать ошибки из базы.
это утилита gfix или, интерактивно, из менеджера базы
Потом можно делать backup. Кстати обрати внимание на размер
страницы когда делаешь restore. Для FAT предлагается делать 8192 для NTFS - 4096.
Я обычно ставлю размер страницы таким же, как размер кластера.
После этого проблемы с записями обычно пропадают, даже при обесточивании.

← →
AlexA (2003-05-06 14:46) [8]

>Desdechado
>sunrider
база была запорчена. Сделал backup с отключением проверки контрольной суммы стало все ок. Ошибок в базе не нашел...

Всем спасибо!

происходит рестарт IB сервера. Найти похожие ветки