Страница 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-ом соглашусь, что не привелись, но ты ведь это проверить можешь
запросом
Сам же говоришь, что потерянные страницы есть
Батор писал(а):
а при использовании ключа -ig происходит что и в первом посте - пифл падает
Хто такой злобный
пифл?
Добавлено: 18 июл 2007, 07:21
Батор
stix-s писал(а):
Я все же скорее с
dimitr-ом соглашусь, что не привелись, но ты ведь это проверить можешь
запросом
Сам же говоришь, что потерянные страницы есть
Хто такой злобный
пифл?
в нескольких таблицах проверил - вроде нормально открывается
пифл = 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
Добавлено: 19 июл 2007, 04:21
Батор
была включена в дистрибутив Delphi 2005
уже качаю патч
Добавлено: 19 июл 2007, 10:05
kdv
была включена в дистрибутив Delphi 2005
ну так сколько ей лет. и потом, надо же читать ibase.ru. я и в новостях про это писал, своевременно.