gbak - почти сразу падает при запуске
gbak - почти сразу падает при запуске
сегодня вдруг 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)
в чем может быть проблема, как лечить?
по поиску не нашел ничего
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 - почти сразу падает при запуске
а в процедурах соответствующие параметры поменял?Батор писал(а):
единственно что менял вчера - это чистил наследие прошлых: в нескольких таблицах поля типа Timestamp изменял на Date (в IBExpert ставил один и тот же домен, у которого тип Date)
в чем может быть проблема, как лечить?
по поиску не нашел ничего
дык gfix и вперед.Батор писал(а):во многих процедурах поменял 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
А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
то бишь остается только перезаливка ч/з скрипт?dimitr писал(а):не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
ЗЫ Убейте лишние топы мои, не виноватая я
тфу, посты топы не надо
Для трудолюбивых - да. Ленивые обычно обходятся Update ChangedTable Set ChangedColumn=ChangedColumn. Но если на домене висят все таблицы, то глобальная перезаливка будет ленивее - меньше репу напрягать.stix-s писал(а):то бишь остается только перезаливка ч/з скрипт?dimitr писал(а):не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
Полумеры это всё, и посты и топы... Рыбу чистят с головы.stix-s писал(а): ЗЫ Убейте лишние топы мои, не виноватая я
тфу, посты топы не надо
Если я правильно понял, некие злые тулзы напрямую редактируют RDB$....., не спрашивая дозволу и не проверяя соответстие типов?dimitr писал(а):не привелись, конечно. А учитывая, что некоторые тулзы до сих пор меняют тип данных через модификацию системных таблиц, то можно вдвойне огрести на бекапе. Недавно уже был такой случай, как раз с timestamp/date.stix-s писал(а):А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
ибо нам все пофиг, ты сам так решил?
данные вроде должны привестись - там все данные были с временем 00:00:00stix-s писал(а): дык gfix и вперед.
А вообще, канешна интересно, тип поля ты поменял, а старые данные корректно к этому типу привелись иль как?
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 происходит что и в первом посте - пифл падает
Я все же скорее с dimitr-ом соглашусь, что не привелись, но ты ведь это проверить можешьБатор писал(а): данные вроде должны привестись - там все данные были с временем 00:00:00
запросом
Код: Выделить всё
select cast(FIELD as date) from Table
Хто такой злобный пифл?Батор писал(а): а при использовании ключа -ig происходит что и в первом посте - пифл падает
в нескольких таблицах проверил - вроде нормально открываетсяstix-s писал(а): Я все же скорее с dimitr-ом соглашусь, что не привелись, но ты ведь это проверить можешь
запросомСам же говоришь, что потерянные страницы естьКод: Выделить всё
select cast(FIELD as date) from Table
Хто такой злобный пифл?
пифл = GBAK
Тебе не кажется, что сие утверждение находится в логическом противоречии с тем, что ты сюда вообще пришёл? Ибо если бы всё работало, то зачем тогда что-то спрашивать?Батор писал(а): IBExpert вот так делает:и все работаютКод: Выделить всё
update RDB$RELATION_FIELDS set RDB$FIELD_SOURCE = 'RDB$448' where (RDB$FIELD_NAME = 'DATE_BD') and (RDB$RELATION_NAME = 'SPR_CONTR')
Скорее всего это вот эта бага
Проверить можно
а) запустить бекап через сервисы
б) взять из снапшота свежий fbclient и подложить его gbak'у под именем gds32
В обоих случаях должна быть ругань вместо падения (хотя я бы подстелил соломки под IB )
Если это оно, то метод лечения очевиден
Проверить можно
а) запустить бекап через сервисы
б) взять из снапшота свежий fbclient и подложить его gbak'у под именем gds32
В обоих случаях должна быть ругань вместо падения (хотя я бы подстелил соломки под IB )
Если это оно, то метод лечения очевиден
"работают" - в том плане, что вроде бы все штатно работает,Merlin писал(а):Тебе не кажется, что сие утверждение находится в логическом противоречии с тем, что ты сюда вообще пришёл? Ибо если бы всё работало, то зачем тогда что-то спрашивать?Батор писал(а): и все работают
но бэкап то делаться не хочет
Ну. Было поле длиною 8 байт, с соответствующим идентификатором типа. Идентификатор хакерски поменяли на тип, длина которого должна быть 4 байта. Данные и описание их длины остались старые. Вот что хоть что-то работает или делает вид что работает - это да, может удивлять. А что бакап не получается - в этом ничего удивительного я лично не наблюдаю.Батор писал(а): "работают" - в том плане, что вроде бы все штатно работает,
но бэкап то делаться не хочет