iBase.ru Forum

Что может означать эта ошибка? Может у кого то что то подобное проявлялось?

azrael писал(а):Что может означать эта ошибка

Не могу сортировать по полю, которое не существует.

Прошу прощения за поднятие старой темы, но судя по всему решение никто не нашёл...
У меня такая же проблема почти каждый раз, когда принудительно выкидываю юзеров (или не из-за этого) с помощью ibconsvc.
По логу видно, что прерывается на одном и том же месте... при создании индекса...
Backup происходит gbak'ом.
При работающей базе backup делается без проблем.
В общем после отрубания всех юзеров первый коннект - эта ошибка.
И видимо при этом происходит лечение базы, т.к. со второго раза backup проходит всегда.

IB: Yaffil build 885 (но и на более ранних была та же проблема).

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

Alex Prodigy писал(а):... Но без этого тоже никак - почему-то висят коннекты, хотя компы клиентов уже могут быть выключены...

Про keepalive читал?

С каких пор конекты стали мешать делать резервную копию гбак-ом?

но судя по всему решение никто не нашёл...

решение чего, собственно?

По логу видно, что прерывается на одном и том же месте... при создании индекса...

по логу чего? индексы, вообще-то, создаются или при restore, или при их явном или неявном (constraint) создании.
при бэкапе никакие индексы никогда не создаются.

И видимо при этом происходит лечение базы, т.к. со второго раза backup проходит всегда.

"лечение базы" самостоятельно не происходит никогда.

проверь соответствие *.msg и gds32.dll. может у тебя файл сообщений не от клиента Yaffil.

Ivan_Pisarevsky

С каких пор конекты стали мешать делать резервную копию гбак-ом?

Я вообще-то написал, что

При работающей базе backup делается без проблем.

Но мне нужно получать полный доступ к файлу БД. Поэтому все коннекты должны быть отрублены.

Так вот. Даже если не делать backup, а просто сделать запрос по любой таблице, то пару минут зависон, после чего отвисает и запрос выполняется.

kdv

проверь соответствие *.msg и gds32.dll. может у тебя файл сообщений не от клиента Yaffil.

От Yaffil'а, это точно. А yaffil.msg вообще убран, начиная с билда 856.

по логу чего? индексы, вообще-то, создаются или при restore, или при их явном или неявном (constraint) создании.
при бэкапе никакие индексы никогда не создаются.

Ну видно по логу при backup'е.
Естесственно индексы не создаются. Я неправильно выразился - не при создании индекса, а при записи его в файл backup'а.

Вот место ошибки:
gbak: writing index RDB$FOREIGN86
gbak: ERROR:cannot sort on a field that does not exist
gbak: ERROR:isc_compile_request failed
gbak:Exiting before completion due to errors

решение чего, собственно?

Хотелось бы без таких вот заморочек.

А про лечение не совсем согласен. Ведь при первом коннекте что-то там делается... И не так уж и важно - backup это или простой запрос. Подвисон на пару минут с последующей работой (но backup при этом не завершается корректно).

А про лечение не совсем согласен.

похоже, у тебя системные таблицы попорчены.

kdv писал(а):

А про лечение не совсем согласен.

похоже, у тебя системные таблицы попорчены.

А чего им портиться-то?
И если так, то они портятся именно в момент выкидывания клиента?
Ну а это вообще насколько возможно?
Метаданные вроде не меняются в рантайме.
Подскажите, где копать?

Подскажите, где копать?

слушай, так много вопросов... Законы Мэрфи знаешь? Все что может портиться - портится.

www.ibase.ru/devinfo/db_repair.htm

И если так, то они портятся именно в момент выкидывания клиента?

нет. что значит "выкидывание клиента"?

kdv писал(а):нет. что значит "выкидывание клиента"?

Бывает, что остаются коннекты уже выключенных компов...
Т.е. клиент давно уже домой ушёл, а сервер думает, что клиент жив...
Почему такое происходит, неизвестно (может, с сетью что-то не так?).
И приходится выкидывать принудительно этот коннект с помощью ibconsvc.
Ну и собственно всё. Ничего криминального не делается...

Alex Prodigy писал(а):

kdv писал(а):нет. что значит "выкидывание клиента"?

Бывает, что остаются коннекты уже выключенных компов...
Т.е. клиент давно уже домой ушёл, а сервер думает, что клиент жив...
Почему такое происходит, неизвестно (может, с сетью что-то не так?).
И приходится выкидывать принудительно этот коннект с помощью ibconsvc.
Ну и собственно всё. Ничего криминального не делается...

Про кипалив почитай таки.

Если БД выгрузить в скрипт и потом из этого скрипта создать? Что происходит?

Ivan_Pisarevsky писал(а):Про кипалив почитай таки.

Если БД выгрузить в скрипт и потом из этого скрипта создать? Что происходит?

Про keepalive читал давно-давно. И такие ошибки (10054) возникают. И возникали во всех конторах, где я видел IB.
Т.е. в итоге Вы считаете, что та ошибка при backup'е происходит именно из-за подвисших коннектов или непредвиденных разрывов?
Буду тогда копать в этом направлении.
Спасибо.

А по поводу скрипта отпишусь завтра, сегодня уже раб. день заканчивается...

Alex Prodigy писал(а):И такие ошибки (10054) возникают. И возникали во всех конторах, где я видел IB.

Не говорите за весь IB.
FB 1.0.3. Куча повисших/оставленных/дохлых коннектов, да ещё половина через BDE который вообще транзакцию не завершает никогда, 1 - 2 раза в день бэкап-рестор (работа круглосуточная) помножим на три десятка таких баз - не вижу я никаких проблем с gbak, по крайней мере, регулярно возникающих.
А описанную тобой вообще не припоминаю.
Пользователи рубятся через gfix shutdown базы.

Т.е. в итоге Вы считаете, что та ошибка при backup'е происходит именно из-за подвисших коннектов или непредвиденных разрывов?

нет, не считаем.

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

kdv писал(а):

Т.е. в итоге Вы считаете, что та ошибка при backup'е происходит именно из-за подвисших коннектов или непредвиденных разрывов?

нет, не считаем.

Хм. Ну тогда я вообще не понимаю, в чём может быть причина.
Ведь если нет подвисших коннектов, то база бэкапится с первого раза безо всяких ошибок.

Ivan_Pisarevsky
База из скрипта создалась. Сейчас заливаются данные из второго скрипта.

Alex Prodigy писал(а):Хм. Ну тогда я вообще не понимаю, в чём может быть причина.

Причина такого поведения может быть в повреждении файла БД, о чем КДВ говорил выше. А уж повредиться она могла по многим причинам, как то отрубание питания, сбойный жесткий диск, сбойная память и т.п.

Ivan_Pisarevsky писал(а):Причина такого поведения может быть в повреждении файла БД, о чем КДВ говорил выше. А уж повредиться она могла по многим причинам, как то отрубание питания, сбойный жесткий диск, сбойная память и т.п.

Но база-то неповреждённая!
Я же говорю, что она "повреждается" только после дисконнекта повисших клиентов. И если не делать backup, а подключиться к базе и попытаться выполнить любой запрос, она подвисает (ну лечится всё-таки видимо ), через пару минут отвисает и выдаёт ответ на запрос. После этого можно смело делать backup, он пройдёт без проблем. Кроме того, после backup'а сразу делается restore (собственно для этого мне и нужен монопольный доступ к БД, т.к. она переименовывается). И он проходит без ошибок.
В общем, если keepalive не поможет избавиться от повисших клиентов, то больше вариантов у меня просто не останется... Придётся закрыть глаза на 2-х разовый backup и всё... База-то всё равно целая получается.

P.S. Только что закончился залив данных... Уууффф... А создание базы из скрипта с последующим заливанием всех данных говорит о неиспорченности БД или нет?

Alex Prodigy писал(а):Но база-то неповреждённая!
Я же говорю, что она "повреждается" только после дисконнекта повисших клиентов. И если не делать backup, а подключиться к базе и попытаться выполнить любой запрос, она подвисает (ну лечится всё-таки видимо ), через пару минут отвисает и выдаёт ответ на запрос.

Классик ? свип_интевал != 0 ?

hvlad писал(а):Классик ? свип_интевал != 0 ?

Классик! свип_интервал по дефолту.
Надо вырубить?