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)

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

stix-s · Сообщение **stix-s** » 17 июл 2007, 07:22

Батор писал(а):
единственно что менял вчера - это чистил наследие прошлых: в нескольких таблицах поля типа 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

stix-s · Сообщение **stix-s** » 17 июл 2007, 08:00

Батор писал(а):во многих процедурах поменял 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 и вперед.
А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?

dimitr · Сообщение **dimitr** » 17 июл 2007, 08:23

stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?

не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.

stix-s · Сообщение **stix-s** » 17 июл 2007, 08:27

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

то бишь остается только перезаливка ч/з скрипт?
ЗЫ Убейте лишние топы мои, не виноватая я

тфу, посты

топы не надо

Merlin · Сообщение **Merlin** » 17 июл 2007, 12:04

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

Для трудолюбивых - да. Ленивые обычно обходятся Update ChangedTable Set ChangedColumn=ChangedColumn. Но если на домене висят все таблицы, то глобальная перезаливка будет ленивее - меньше репу напрягать.

stix-s писал(а): ЗЫ Убейте лишние топы мои, не виноватая я
тфу, посты топы не надо

Полумеры это всё, и посты и топы... Рыбу чистят с головы.

WildSery · Сообщение **WildSery** » 17 июл 2007, 12:35

Merlin писал(а):Рыбу чистят с головы.

это гниёт с головы. а чистят с хвоста.

stix-s · Сообщение **stix-s** » 17 июл 2007, 13:59

WildSery писал(а):
Merlin писал(а):Рыбу чистят с головы.
это гниёт с головы. а чистят с хвоста.

Злые вы, я филе покупаю

stix-s · Сообщение **stix-s** » 17 июл 2007, 17:11

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 происходит что и в первом посте - пифл падает

stix-s · Сообщение **stix-s** » 18 июл 2007, 07:14

Батор писал(а): данные вроде должны привестись - там все данные были с временем 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

Merlin · Сообщение **Merlin** » 18 июл 2007, 13:02

Батор писал(а): IBExpert вот так делает:
Код: Выделить всё
update RDB$RELATION_FIELDS set
RDB$FIELD_SOURCE = 'RDB$448'
where (RDB$FIELD_NAME = 'DATE_BD') and
(RDB$RELATION_NAME = 'SPR_CONTR')
и все работают

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

hvlad · Сообщение **hvlad** » 18 июл 2007, 14:25

Скорее всего это вот эта бага
Проверить можно
а) запустить бекап через сервисы
б) взять из снапшота свежий fbclient и подложить его gbak'у под именем gds32
В обоих случаях должна быть ругань вместо падения (хотя я бы подстелил соломки под IB

)
Если это оно, то метод лечения очевиден

Батор · Сообщение **Батор** » 18 июл 2007, 23:06

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

"работают" - в том плане, что вроде бы все штатно работает,
но бэкап то делаться не хочет

Merlin · Сообщение **Merlin** » 18 июл 2007, 23:41

Батор писал(а): "работают" - в том плане, что вроде бы все штатно работает,
но бэкап то делаться не хочет

Ну. Было поле длиною 8 байт, с соответствующим идентификатором типа. Идентификатор хакерски поменяли на тип, длина которого должна быть 4 байта. Данные и описание их длины остались старые. Вот что хоть что-то работает или делает вид что работает - это да, может удивлять. А что бакап не получается - в этом ничего удивительного я лично не наблюдаю.

Сообщение **kdv** » 19 июл 2007, 00:17

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

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

Сообщение **kdv** » 19 июл 2007, 10:05

была включена в дистрибутив Delphi 2005

ну так сколько ей лет. и потом, надо же читать ibase.ru. я и в новостях про это писал, своевременно.

iBase.ru Forum

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

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

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