Страница 1 из 2

gbak - почти сразу падает при запуске

Добавлено: 17 июл 2007, 06:58
Батор
сегодня вдруг gbak начал падать:
InterBase Server - обнаружена ошибка. Приложение будет закрыто. ...
и предлагается отправить отчет в микрософт.

в журнале приложений Ошибка:
Ошибка приложения gbak.exe, версия 7.5.0.129, модуль gbak.exe, версия 7.5.0.129, адрес 0x0001394a.

в interbase log такая запись:
MYSEREVER (Server) Tue Jul 17 15:42:58 2007
INET/inet_error: read errno = 10054 client host = BATOR connection name = myserver user name = BATOR

последние строки лога бэкапа:
gbak: writing stored procedure NDFL_REESTR_OTR_SUM
gbak: writing parameter ID_PERIOD_B for stored procedure
gbak: writing parameter ID_PERIOD_E for stored procedure
gbak: writing parameter ID_CONTR for stored procedure
gbak: writing parameter RESULT_T for stored procedure
gbak: writing parameter KOD_FOR_NDFL for stored procedure
gbak: writing parameter ID_PERIOD for stored procedure
gbak: writing stored procedure TEST_SEV_NADB_PER
gbak: writing parameter ID_PERIOD_B for stored procedure
gbak: writing parameter ID_PERIOD_E for stored procedure
g

до этого бэкап/ресторе ночью делался нормально
а сегодня вот выдал...

хотя база работает нормально.

единственно что менял вчера - это чистил наследие прошлых: в нескольких таблицах поля типа Timestamp изменял на Date (в IBExpert ставил один и тот же домен, у которого тип Date)

в чем может быть проблема, как лечить?
по поиску не нашел ничего :(

Re: gbak - почти сразу падает при запуске

Добавлено: 17 июл 2007, 07:22
stix-s
Батор писал(а):
единственно что менял вчера - это чистил наследие прошлых: в нескольких таблицах поля типа Timestamp изменял на Date (в IBExpert ставил один и тот же домен, у которого тип Date)

в чем может быть проблема, как лечить?
по поиску не нашел ничего :(
а в процедурах соответствующие параметры поменял?

Добавлено: 17 июл 2007, 07:25
Батор
во многих процедурах поменял Timestamp на Date
и перекомпилировал все

теперь gbak не падает, а в логе последние строчки такие:

gbak: writing index RDB$PRIMARY94
gbak: writing data for table DOC_SPRAVKA_PF
gbak: ERROR: System memory exhausted
gbak: Exiting before completion due to errors

Добавлено: 17 июл 2007, 08:00
stix-s
Батор писал(а):во многих процедурах поменял Timestamp на Date
и перекомпилировал все

теперь gbak не падает, а в логе последние строчки такие:

gbak: writing index RDB$PRIMARY94
gbak: writing data for table DOC_SPRAVKA_PF
gbak: ERROR: System memory exhausted
gbak: Exiting before completion due to errors
дык gfix и вперед.
А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?

Добавлено: 17 июл 2007, 08:23
dimitr
stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.

Добавлено: 17 июл 2007, 08:27
stix-s
dimitr писал(а):
stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.
то бишь остается только перезаливка ч/з скрипт?
ЗЫ Убейте лишние топы мои, не виноватая я :(
тфу, посты :) топы не надо :)

Добавлено: 17 июл 2007, 12:04
Merlin
stix-s писал(а):
dimitr писал(а):
stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.
то бишь остается только перезаливка ч/з скрипт?
Для трудолюбивых - да. Ленивые обычно обходятся Update ChangedTable Set ChangedColumn=ChangedColumn. Но если на домене висят все таблицы, то глобальная перезаливка будет ленивее - меньше репу напрягать.
stix-s писал(а): ЗЫ Убейте лишние топы мои, не виноватая я :(
тфу, посты :) топы не надо :)
Полумеры это всё, и посты и топы... Рыбу чистят с головы.

Добавлено: 17 июл 2007, 12:35
WildSery
Merlin писал(а):Рыбу чистят с головы.
:) это гниёт с головы. а чистят с хвоста.

Добавлено: 17 июл 2007, 13:59
stix-s
WildSery писал(а):
Merlin писал(а):Рыбу чистят с головы.
:) это гниёт с головы. а чистят с хвоста.
Злые вы, я филе покупаю :)

Добавлено: 17 июл 2007, 17:11
stix-s
dimitr писал(а):
stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.
Если я правильно понял, некие злые тулзы напрямую редактируют RDB$....., не спрашивая дозволу и не проверяя соответстие типов?
ибо нам все пофиг, ты сам так решил?

Добавлено: 17 июл 2007, 23:16
Батор
stix-s писал(а): дык gfix и вперед.
А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
данные вроде должны привестись - там все данные были с временем 00:00:00

IBExpert вот так делает:

Код: Выделить всё

update RDB$RELATION_FIELDS set
RDB$FIELD_SOURCE = 'RDB$448'
where (RDB$FIELD_NAME = 'DATE_BD') and
(RDB$RELATION_NAME = 'SPR_CONTR')
и все работают, данные на месте

сейчас скопировал файл БД
gfix -v -full - 2 ошибки Page ххххх is an orphan
gfix -mend -full - ошибок нет, но бэкап выдает тоже самое

и как стало "gbak: ERROR: System memory exhausted"
файл бэкапа не создается
а при использовании ключа -ig происходит что и в первом посте - пифл падает

Добавлено: 18 июл 2007, 07:14
stix-s
Батор писал(а): данные вроде должны привестись - там все данные были с временем 00:00:00
Я все же скорее с dimitr-ом соглашусь, что не привелись, но ты ведь это проверить можешь
запросом

Код: Выделить всё

 select cast(FIELD as date) from Table
Сам же говоришь, что потерянные страницы есть
Батор писал(а): а при использовании ключа -ig происходит что и в первом посте - пифл падает
Хто такой злобный пифл?

Добавлено: 18 июл 2007, 07:21
Батор
stix-s писал(а): Я все же скорее с dimitr-ом соглашусь, что не привелись, но ты ведь это проверить можешь
запросом

Код: Выделить всё

 select cast(FIELD as date) from Table
Сам же говоришь, что потерянные страницы есть
Хто такой злобный пифл?
в нескольких таблицах проверил - вроде нормально открывается

пифл = GBAK :)

Добавлено: 18 июл 2007, 13:02
Merlin
Батор писал(а): IBExpert вот так делает:

Код: Выделить всё

update RDB$RELATION_FIELDS set
RDB$FIELD_SOURCE = 'RDB$448'
where (RDB$FIELD_NAME = 'DATE_BD') and
(RDB$RELATION_NAME = 'SPR_CONTR')
и все работают
Тебе не кажется, что сие утверждение находится в логическом противоречии с тем, что ты сюда вообще пришёл? Ибо если бы всё работало, то зачем тогда что-то спрашивать?

Добавлено: 18 июл 2007, 14:25
hvlad
Скорее всего это вот эта бага
Проверить можно
а) запустить бекап через сервисы
б) взять из снапшота свежий fbclient и подложить его gbak'у под именем gds32
В обоих случаях должна быть ругань вместо падения (хотя я бы подстелил соломки под IB :))
Если это оно, то метод лечения очевиден

Добавлено: 18 июл 2007, 23:06
Батор
Merlin писал(а):
Батор писал(а): и все работают
Тебе не кажется, что сие утверждение находится в логическом противоречии с тем, что ты сюда вообще пришёл? Ибо если бы всё работало, то зачем тогда что-то спрашивать?
"работают" - в том плане, что вроде бы все штатно работает,
но бэкап то делаться не хочет

Добавлено: 18 июл 2007, 23:41
Merlin
Батор писал(а): "работают" - в том плане, что вроде бы все штатно работает,
но бэкап то делаться не хочет
Ну. Было поле длиною 8 байт, с соответствующим идентификатором типа. Идентификатор хакерски поменяли на тип, длина которого должна быть 4 байта. Данные и описание их длины остались старые. Вот что хоть что-то работает или делает вид что работает - это да, может удивлять. А что бакап не получается - в этом ничего удивительного я лично не наблюдаю.

Добавлено: 19 июл 2007, 00:17
kdv
www.ibase.ru/devinfo/allversions.htm

откуда гадость взял? IB 7.5.0.129

Добавлено: 19 июл 2007, 04:21
Батор
kdv писал(а):www.ibase.ru/devinfo/allversions.htm

откуда гадость взял? IB 7.5.0.129
была включена в дистрибутив Delphi 2005 :(

уже качаю патч

Добавлено: 19 июл 2007, 10:05
kdv
была включена в дистрибутив Delphi 2005
ну так сколько ей лет. и потом, надо же читать ibase.ru. я и в новостях про это писал, своевременно.