Hello, All!
обновил статью
www.ibase.ru/devinfo/garbage.htm#backup
а то прямо опять блуждание в трех соснах начинается. :-)
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
ИМХО вообще убрать из GBAK возможность работы со сборкой мусора.
--
Сергей Смирнов.
WildSery wrote:
ИМХО вообще убрать из GBAK возможность работы со сборкой мусора.
Какие вы все категоричные. Бекап - это чтение всего файла базы, свип -
тоже. Нафига мне делать это дважды, если OIT у меня блокируется лишь раз
в пятилетку?
--
Дмитрий Еманов
On Tue, 19 Dec 2006 11:38:44 +0300, Dmitry Yemanov <[EMAIL PROTECTED]> wrote:
> Какие вы все категоричные. Бекап - это чтение всего файла базы, свип -
> тоже. Нафига мне делать это дважды, если OIT у меня блокируется лишь раз
> в пятилетку?
Почему категоричные? Я ж сказал, что имха.
--
Сергей С
Наводил у себя на сервер порядок и сдуру удалил временную папку в
которую gbak при резервном копировании складывал свои логи (через -y
путь_к_файлу_лога). Ну то, что резервное копирование сломалось это
одно, а вот gbak при таком действии вместо того, чтобы выйти с
ошибкой, зависает и ждет пока
Horsun Vlad wrote:
>
> gbak ждёт, пока место появится.
>
ОУ! так его не килять надо, а место освобождать?
А я его все в расход пускаю :-)))
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
"Konstantin R. Beliaev" ...
> Horsun Vlad wrote:
> >
> > gbak ждёт, пока место появится.
> >
>
> ОУ! так его не килять надо, а место освобождать?
> А я его все в расход пускаю :-)))
Я не помню - он или действительно продолжит работу,
или он висит
"Horsun Vlad" <[EMAIL PROTECTED]> wrote:
>
> Я не помню - он или действительно продолжит работу,
> или он висит ожидая ответа на свой вопрос о следующей
> ленте. Проверить нужно
Второе, насколько я помню. Он ожидает команды в stdin.
--
Дмитрий Еманов
--~--~-~--~~~
Dmitry Yemanov wrote:
> Второе, насколько я помню. Он ожидает команды в stdin.
Блин... :-(
А можно переделать? если вывод идет на диск, а не ленту
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
"Konstantin R. Beliaev" <[EMAIL PROTECTED]> wrote:
>
> А можно переделать?
Не в 2.0.
--
Дмитрий Еманов
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
"Konstantin R. Beliaev" <[EMAIL PROTECTED]>
сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED]
> Dmitry Yemanov wrote:
> > Второе, насколько я помню. Он ожидает команды в stdin.
> Блин... :-(
> А можно переделать? если вывод идет на диск, а не ленту
Возьми и сам переделай. Исходники же
Dmitry Voroshin wrote:
> Возьми и сам переделай. Исходники же есть!
Я не силен в С
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Добрый день!
Если из приложения бэкапить/разбэкапливать базу через сервисы, то на
клиента в случае ошибки/предупреждения передается только текст или еще
и код какой-нибудь?
Очень надо отличить фатальную ошибку от предупреждения, например, о
том, что уменьшен размер страницы.
Андрей
Скажите а в свежем сервере в gbak убрана буферизация вывода? Чтобы можно
было через pipe смотреть вывод без задержек из за ожидания заполнения
буфера вывода.
Юрий
Hi, многоуважаемый All!
Firebird-2.1.0.15978-0_win32
через IBE - делаю B/R - всё ок
пробую использовать gbak
gbak.exe -r o -v l:\Clear.fbk l:\Client.fdb
gbak:opened file l:\Clear.fbk
gbak:transportable backup -- data in XDR format
gbak: backup file is compressed
gbak
Hello, Alexey!
Alexey Voytsehovich wrote:
"d:\Program Files\Firebird\Firebird_2_5\bin\gbak.exe" -B -USER SYSDBA
тут 2.5.
aliases.conf
opc = d:\program files\firebird\firebird_2_1\opc.fb
тут 2.1
также вопрос в сторону - база лежит в каталоге установки.
так и надо, или это недосмотр?
и во
Dmitri Kuzmenko wrote:
Hello, Alexey!
Alexey Voytsehovich wrote:
"d:\Program Files\Firebird\Firebird_2_5\bin\gbak.exe" -B -USER SYSDBA
тут 2.5.
да
aliases.conf
opc = d:\program files\firebird\firebird_2_1\opc.fb
тут 2.1
осталось со старых времен, не перекладывали :)
также вопрос в
Hello, Alex!
Alexey Voytsehovich wrote:
осталось со старых времен, не перекладывали :)
ok.
также вопрос в сторону - база лежит в каталоге установки.
так и надо, или это недосмотр?
есть ли разница?
есть-ли разница между бардаком и порядком?
>> и вообще, все установлено в Program Files
Уже второй раз натыкаюсь на одно и то же:
есть робот, который по расписанию стартует GBAK. Если по какой-то
причине места на диске под бэкап не хватило - GBAK не завершается, а
остается висеть, при этом робот кушает 100% проца.
Кто тут виноват: робот или GBAK, честно говоря не знаю, но поведение
> Лучше всего - полный лог. Даже если все вдруг прошло успешно. :)
полный не полный... парсить лог? к чему привязываться? к конкретному
тексту сообщений?
а если в будущем он изменится?
> Если из приложения бэкапить/разбэкапливать базу через сервисы, то на
> клиента в случае ошибки/предупреждения передается только текст или еще
> и код какой-нибудь?
>
Лучше всего - полный лог. Даже если все вдруг прошло успешно. :)
Andrei пишет:
Если из приложения бэкапить/разбэкапливать базу через сервисы, то на
клиента в случае ошибки/предупреждения передается только текст или еще
и код какой-нибудь?
Текст передается через текстовый буфер, ошибки - через статус-вектор.
Дмитрий
Вдогонку:
К> PS: отесторить пробую с использованием embed dll
при старте "нормального" Classic - всё ok :(
но мне надо именно через embed ...
С уважением,
Константин Григорьевич.
===
Hello, Константин!
Константин wrote:
через IBE - делаю B/R - всё ок
пробую использовать gbak
gbak.exe -r o -v l:\Clear.fbk l:\Client.fdb
^ а без вот этого мазохизма никак нельзя?
gbak: ERROR:arithmetic exception, numeric overflow, or string truncation
gbak: ERROR
Hello, Konstantin!
Константин wrote:
DK> не видит каталог intl ?
Каюсь, грешен был ... ;)
Спасибо ...
а что насчет -r o ?
p.s. точняк надо было запретить такое вообще.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Dmitri Kuzmenko wrote:
а что насчет -r o ?
p.s. точняк надо было запретить такое вообще.
Для "о" есть таки правильное применение: контрольный рестор бэкапа в
файл с другим именем. Без "о" пришлось бы отресторенный в прошлый раз
файл удялять каким-нибудь скриптом.
r -PASSWORD vermut -C -V -G "e:
\database\data\Backup_Databases\t1\zip
\new_db_t1_123_20070402_142632_restored.gdb" -Y "e:\database\data
\Backup_Databases\t1\zip\new_db_t1_123_20070402_142632_restored.log"
gbak: ERROR:Internal error when using clumplet API: attempt to store
2
DL> такое впечатление, что после надписи завершено, сервер еще чем-то
DL> занят. Чем?
в диспетчере задач посмотреть?
--
С уважением
Кочмин Александр
Привет, Dmitry!
Вы пишешь 10 мая 2006:
>> в диспетчере задач посмотреть?
DL> Что посмотреть? Процессор загружен почти на 100%
Кем.
--
With best regards, Alex Cherednichenko.
DL>> Кем.
DL> Посмотрел. FB и быстродействие системы. Съели все. Проходит минут 10.
DL> Отпускают ресурсы.
какое еще быстродействие системы?
Прикалываешься?
--
С уважением
Кочмин Александр
DL>> Шурик, когда оно ничего не делает, то это "бездействие системы",
DL>> а ежели оно молотит мама не горюй, то какое ж це бездействие,
DL>> це именно быстродействие! :-)
DL>>
DL>> Дим, а восстановление системы на дисках отключено?
DL> Да. Расширение файла базы данных fdb.
DL> Вечером по
Привет, Dmitry!
Вы пишешь 13 мая 2006:
>> кстати, а мож это отложенная запись на диск писать начинает?
DL> Да. Это. Плюс особенность компонентов. Я еще Буза на эту тему поклюю.
DL> С gbak такого нет.
Пни gbak с ключиком -SE и удивись.
--
With best regards, Alex Cherednichenko.
"Konstantin R. Beliaev" ...
> Уже второй раз натыкаюсь на одно и то же:
> есть робот, который по расписанию стартует GBAK. Если по какой-то
> причине места на диске под бэкап не хватило - GBAK не завершается, а
> остается висеть, при этом робот кушает 100% проца.
ен я более внимательно посмотрел на лог
последнего рестора БД и нашел упоминание этого индекса:
activating and creating deferred index ACCM_LOADING_STATISTIC_IDX1
gbak:cannot commit index ACCM_LOADING_STATISTIC_IDX1
gbak: ERROR:I/O error for file "/database/elba/restore_.fdb"
gbak: E
DK> не видит каталог intl ?
Каюсь, грешен был ... ;)
Спасибо ...
С уважением,
Константин Григорьевич.
===
Попробовал перенести один старый проект под FB 2, и сразу наступил на
граблю, на самом первом шаге.
Забэкапил базу под FB 1.0.3, ресторю на FB 2.0. После рестора индексов (это
я уже гадаю) идет рестор процедур, так? И вот на этом этапе выскакивает
сообщение: "gbak: ERROR:table ABONEN
142632.gbk" -SERVICE
> "localhost:service_mgr" -USER gamer -PASSWORD vermut -C -V -G "e:
> \database\data\Backup_Databases\t1\zip
> \new_db_t1_123_20070402_142632_restored.gdb" -Y "e:\database\data
> \Backup_Databases\t1\zip\new_db_t1_123_20070402_142632_resto
> Ну, ты и сам понял - пути у тебя длинные. Сходу не скажу что это -
> наша бага, или очередная родовая травма от так называемых архитекторов
> этого так называемого сервисного АПИ...
От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют
киллометровые названия. То бишь бакап и рест
"Kovalenko Dmitry" ...
>
> > Ну, ты и сам понял - пути у тебя длинные. Сходу не скажу что это -
> > наша бага, или очередная родовая травма от так называемых архитекторов
> > этого так называемого сервисного АПИ...
>
> От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют
> килломет
> > > Ну, ты и сам понял - пути у тебя длинные. Сходу не скажу что это -
> > > наша бага, или очередная родовая травма от так называемых архитекторов
> > > этого так называемого сервисного АПИ...
>
> > От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют
> > киллометровые названия.
Hello, Kovalenko Dmitry!
You wrote on Mon, 02 Apr 2007 05:00:58 -0700:
KD> От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют
KD> киллометровые названия. То бишь бакап и ресторе через сервисы им
KD> заказан.
а если в формате 8.3 указать?
Фёдоров Евгений.
ЗАО "Трест-М". Екатери
> KD> От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют
> KD> киллометровые названия. То бишь бакап и ресторе через сервисы им
> KD> заказан.
>
> а если в формате 8.3 указать?
Накуй. Они в любом случае даже через TCP/IP считанные секунды
бакапятся и ресторятся.
Это я так - из з
Hello, Dmitry!
Kovalenko Dmitry wrote:
\Backup_Databases\t1\gbk\new_db_t1_123_20070402_142632.gbk" -SERVICE
"localhost:service_mgr" -USER gamer -PASSWORD vermut -C -V -G "e:
-c -g -совсем_опух?
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Hello, Dmitry!
Kovalenko Dmitry wrote:
Накуй. Они в любом случае даже через TCP/IP считанные секунды
бакапятся и ресторятся.
Это я так - из зловредности ругаюсь.
ты будь последователен:
1. пишешь -SERVICE, тогда пиши -CREATE
2. пишешь -c, тогда пиши -se, -u -pas и так далее
и я не понял,
Dmitri Kuzmenko wrote:
-c -g -совсем_опух?
А есть ли в Липецке подходящая стенка? ;-)
--
Regards. Ded.
> > -c -g -совсем_опух?
Ну почему совсем... В мои то годы?
> А есть ли в Липецке подходящая стенка? ;-)
Есть тут одна, китайская стена. Но это не наш метод :))
Коваленко Дмитрий.
> > Это я так - из зловредности ругаюсь.
>
> ты будь последователен:
>
> и я не понял, зачем localhost:service_mgr двойными кавычками
> обрамлен. Потому что с двоеточием?
Не. Чиста для понтов :)
Коваленко Дмитрий.
Помогите чайнику. Firebird 1.5.2, база около 10
Гб,
каждую ночь база сливалась gbak-ом и
восстанавливалась
на другой сервер.
Из таблицы 24 млн. записей удалил 9 млн.
Других
существенных изменений в базе не было.
После этого
при запуске gbak создал файл примерно в
половину
ожидаемого размера
quot;localhost:"
DBNAME=`cat /opt/fb20cs/aliases.conf |grep "/var/db"|grep -v "#"|grep -v
"cntldb"|awk '{print $1;}'`
BACKUPNAMEDATE=`date +_%Y_%m_%d_%H_%M_%S`
FBK=".fbk20"
TMP="/tmp/"
BACKUPDIR="/var/www/db/"
BZ2=".bz2&q
уксоиду грех жаловаться на отсутствие средств
>>проверки в таких случаях.
Мерси за комплиман (с) :)
Но я, к сожалению, не являюсь специалистом в Linux.
За скрипт отдельное спасибо :)
С уважением,
Всеволод
--
View this message in context:
http://firebird.1100200.n4.nabbl
Hello, Vsevolod!
Vsevolod wrote:
Хотелось бы послушать начальника транспортного цеха (с)
надо было ставить FBDataGuard. Он бы предупредил про отсутствие
места.
Собственно, по идее, когда происходят ошибки при restore,
то база должна оставаться в состоянии shutdown.
если у тебя все пользовате
ограничение, естественно
сняли.
>>Собственно, по идее, когда происходят ошибки при restore,
>>то база должна оставаться в состоянии shutdown.
Я тоже так думаю, но gbak думает иначе :)
>>если у тебя все пользователи SYSDBA, то понятно, почему
>>"никто ничего не заметил&qu
Респект, Усем!
Подскажите плиз как для сабжа указать где искать firebird.msg, сейчас он его
ищет в папке
выше уровнем.
С наилучшими пожеланиями, Oleg Prosvetov.
Valery Gruzdev wrote:
Т.е. я понимаю, что работа с планами в двойке изменилась, и там придется
наверняка что-то править. Но нельзя хотя бы узнать, на какой процедуре
все сломилось? Потому что их больше трехсот, ABONENTS используется
примерно в полусотне.
И во всех 50-ти процедурах планы пр
Valery Gruzdev пишет:
Т.е. я понимаю, что работа с планами в двойке изменилась, и там придется
наверняка что-то править. Но нельзя хотя бы узнать, на какой процедуре
все сломилось? Потому что их больше трехсот, ABONENTS используется
примерно в полусотне. Просматривать их все глазками - утомите
On Mon, 19 Feb 2007 11:10:33 +0300, Valery Gruzdev <[EMAIL PROTECTED]> wrote:
> Но нельзя хотя бы узнать, на какой процедуре все сломилось?
1. Экспертом выгружаешь все метаданные в скрипт.
2. На 2-ке создаёшь базу из этого скрипта.
Все ошибки тебе будут непосредственно носом потыканы.
ЗЫ: Это и
серьезные объемы лопатить тоскливо получается.
Но я не про то сейчас. Процедуры от планов почистить - не проблема, просто
рутинная работа.
Я про диагностику в GBAK :-)
Grue
Все ошибки тебе будут непосредственно носом потыканы.
ЗЫ: Это именно ошибки, а не "работа с планами поменялась". Сервер стал
более строг к синтаксису.
раньше можно было указать типа этого
select ... from TABLE1, TABLE2, TABLE3
plan (TABLE2 nalural)
на ошибку не похоже
--
Булычев Алексей
h
"Boulitchev Aleksey" сообщил/сообщила в новостях следующее:
раньше можно было указать типа этого
select ... from TABLE1, TABLE2, TABLE3
plan (TABLE2 nalural)
Именно эта ситуация.
Grue
On Mon, 19 Feb 2007 12:08:54 +0300, Boulitchev Aleksey <[EMAIL PROTECTED]>
wrote:
> select ... from TABLE1, TABLE2, TABLE3
> plan (TABLE2 nalural)
>
> на ошибку не похоже
Действительно не похоже.
Не знал, что и на такое ругается, у меня все соединения с алиасами, не
попадался такой случай.
--
WildSery пишет:
select ... from TABLE1, TABLE2, TABLE3
plan (TABLE2 nalural)
на ошибку не похоже
Действительно не похоже.
Не знал, что и на такое ругается, у меня все соединения с алиасами, не
попадался такой случай.
Просто FB2 не переваривает _часть_ плана. Ему подавай или все, или ничего
On Mon, 19 Feb 2007 18:27:45 +0300, Andrei Yeryomin <[EMAIL PROTECTED]> wrote:
> Просто FB2 не переваривает _часть_ плана. Ему подавай или все, или ничего.
Тьфу, действительно. Не обратил внимание, что только часть, обратил, что без
алиаса...
Мда, передохнуть надо, кофе попить...
--
Сергей Сми
gbak -b -g
И почитать про сборку мусора и MGA.
С уважением,
Алексей
Victor Grigoryev пишет:
Помогите чайнику. Firebird 1.5.2, база около 10
Гб,
каждую ночь база сливалась gbak-ом и
восстанавливалась
на другой сервер.
Из таблицы 24 млн. записей удалил 9 млн.
Других
Victor Grigoryev пишет:
мусора,
бэкап создался нормально, но
аналогичное "подвисание"
возникло при восстановлении. Сейчас
остается только
надеяться, что к окончанию выходных
ресторинг все-таки
отработает.
Ресторе работает примерно в 3 раза дольше бэкапа, но никак не 10 часов.
Ключ -v раскрое
Здравствуйте, уважаемые.
Накануне пятницы задам глупый вопрос. Просьба сильно не пинать
Вводная:
имеется сервер на базе Intel D805, Centos 5.3,
FirebirdSS-2.1.3.18156-0.i686 брал с http://www.dqteam.com/fb2/ сборка
от Sergey Mereutsa.
Обратил внимание, что при работе GBAK
Здравствуйте.
Обновил у заказчика firebird 1.0 на firebird 2.1
(нужно было использовать временные таблицы и "склеивать запросы в
процедурах")
На сервере стоит ASP Linux 9.0 Ядро 2.4.20-9asp (libs-2.3.2)
Получил такие проблемы:
1. Периодически стал умирать gbak -r на восстановлении
Oleg Prosvetov пишет:
Подскажите плиз как для сабжа указать где искать firebird.msg, сейчас он его
ищет в папке
выше уровнем.
instreg i
--
С уважением,
Андрей Еремин.
Hi "Andrei Yeryomin"
> Oleg Prosvetov пишет:
> > Подскажите плиз как для сабжа указать где искать firebird.msg, сейчас он
> > его ищет в папке
> > выше уровнем.
> instreg i
так более мягко если стывтаь в bat файле
set FIREBIRD=C:\Program Files\Firebird\FB2.1
WBR Evgeny Putilin.
Evgeny Putilin wrote:
так более мягко если стывтаь
Евгений! Попрошу не выражаться в приличном обществе, даже так более
мягко! Сюда ведь и дамы заглядывают.
--
Regards. Ded.
е-то с ней
подозрительно не так стало на уровне субъективных ощущений и решил я ей
заделать b/r. Ощущения меня не подвели и gbak -v -b при формировании
бэкапа на очередной таблице выдал
...
gbak: writing data for table PB_SALE
gbak: ERROR: message length error (encountered 288, expected 284)
g
Привет!
>Обратил внимание, что при работе GBAK утилита top показывает 200%
> использования CPU. До сего дня просто не интересовался.
>Вопрос:
> Как такое возможно? Напомню: FB SuperServer
Пусть меня Птицеводы поправят, но сие возможно только если:
1) top глю
On Thu, 16 Jul 2009 12:40:45 +0500, Sergey Mereutsa
wrote:
Пусть меня Птицеводы поправят, но сие возможно только если:
1) top глючит и плющит "нипадеццки" и он врёт
2) gbak использует 2 нити, обе хавают по ядру на 100%
Ну слава Богу, с головой значит у меня все в порядке. Я
Гоголь Дмитрий wrote:
2) gbak использует 2 нити, обе хавают по ядру на 100%
оно так бывает?
Нет.
--
Дмитрий Еманов
On Thu, 16 Jul 2009 16:08:05 +0500, Dmitry Yemanov
wrote:
Гоголь Дмитрий wrote:
2) gbak использует 2 нити, обе хавают по ядру на 100%
оно так бывает?
Нет.
А через ServicesAPI?
Сейчас проверял: если запускать gbak с ключом -se, то 200% на процесс,
если без такового - 100
Гоголь Дмитрий wrote:
А через ServicesAPI?
Там на сервере не может быть никакого процесса gbak. Разве что тот,
который ты вызвал с -se (если ты это делаешь локально). Но он процессор
грузить почти не будет.
Сейчас проверял: если запускать gbak с ключом -se, то 200% на процесс,
Два
> óÅÊÞÁÓ ÐÒÏ×ÅÒÑÌ: ÅÓÌÉ ÚÁÐÕÓËÁÔØ gbak Ó ËÌÀÞÏÍ -se, ÔÏ 200% ÎÁ ÐÒÏÃÅÓÓ,
> ÅÓÌÉ ÂÅÚ ÔÁËÏ×ÏÇÏ - 100%.
ÓÔÅÓÎÑÀÓØ ÓÐÒÏÓÉÔØ: ÐÏÌÎÕÀ ÓÔÒÏËÕ ÚÁÐÕÓËÁ "Ó ËÌÀÞÅÍ -se" ÍÏÖÎÏ Õ×ÉÄÅÔØ?
ÒÁÚ×Å ÞÔÏ ÐÁÒÏÌØ ÍÏÖÎÏ ÐÒÏÐÕÓÔÉÔØ :-)
On Thu, 16 Jul 2009 17:22:28 +0500, Dmitry Yemanov
wrote:
Гоголь Дмитрий wrote:
А через ServicesAPI?
Там на сервере не может быть никакого процесса gbak. Разве что тот,
который ты вызвал с -se (если ты это делаешь локально). Но он процессор
грузить почти не будет.
А gbak и
On Thu, 16 Jul 2009 17:35:34 +0500, Oleg Matveyev
wrote:
стесняюсь спросить: полную строку запуска "с ключем -se"
да там все то же самое только добавляется -se :service_mgr
--
Гоголь Дмитрий
А gbak и не вижу, есть процесс fbserver и он грузит до 200%.
Чтобы не быть голословным: http://alf2.nm.ru/fb_top.gif
--
Гоголь Дмитрий
> ÄÁ ÔÁÍ ×ÓÅ ÔÏ ÖÅ ÓÁÍÏÅ ÔÏÌØËÏ ÄÏÂÁ×ÌÑÅÔÓÑ -se :service_mgr
ÏË, ÐÅÒÅÆÒÁÚÉÒÕÀ (ÞÔÏ ÈÏÔÅÌ Õ×ÉÄÅÔØ):
ÐÕÔØ Ë âä - ÔÏÞÎÏ ÕËÁÚÁÎ ÌÏËÁÌØÎÙÊ, ÂÅÚ ":"?
ðÒÏ×ÅÌ ÜËÓÐÅÒÉÍÅÎÔ ÐÏÄ ×ÉÎÄÏÊ É Classic.
1) c:\ib\bin\gbak.exe y:\base.fdb s:\base.gbk -user SYSDBA -password
masterkey -g -SERVICE 192.168.36.61/3053:service_mgr
úÁÐÕÓÉÌÓÑ ÂÁËÁÐ, É ÐÏÑ×ÉÌÓÑ ÏÄÉÎ fb_inet_server
2) c:\ib\bin\gbak.exe 192.168.36.61/3053:y:\base.fdb s:\base.gbk -user
SYSDBA -pa
On Fri, 17 Jul 2009 11:22:48 +0500, Oleg Matveyev
wrote:
Провел эксперимент под виндой и Classic.
У меня и на Винде и на Линуксе второй вариант не прокатывает.
gbak: ERROR:connection rejected by remote interface
gbak:Exiting before completion due to errors
т.е. база указывается только
Привет!
> Обновил у заказчика firebird 1.0 на firebird 2.1
Разрядность ОС и билд Птица выдашь только под пытками?
memtest прогоняли на сервере?
--
Best regards,
Sergeymailto:gebele...@gmail.com
и в каких логах ничего не отражается
Просто работал gbak и прервался прям на полуслове в логе. Segmentation fault
увидел всего раз - когда в консоли без ключа -y запустил.
С уважением, Мещеряков Вадим
директор ООО "Комплексные Системы"
454021 г. Челябинск ул. 40 лет Победы 31, 77
"Vadim Mescheryakov" ...
Здравствуйте.
Обновил у заказчика firebird 1.0 на firebird 2.1
(нужно было использовать временные таблицы и "склеивать запросы в
процедурах")
На сервере стоит ASP Linux 9.0 Ядро 2.4.20-9asp (libs-2.3.2)
Получил такие проблемы:
1. Периодически
в, но всегда в разном месте.
> Падает именно gbak или процесс сервера ?
Я копию восстанавливаю без localhost, и если я правильно понимаю gbak сам и
создает новую базу
Gbak исчезает из памяти
> Что в firebird.log ?
Есть несколько ошибок:
mainserver.book.ru Mon Sep 28 14:31:19
При попытке перекомпилировать процедуру в IbExpert получил вот это:
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements.
Unable to complete network request to host "192.168.0.1".
Error writing data to the connection.
Программа на вашем хост-
ии индекса. Оказалась одна планка памяти из 4-х.
Всё остальное работало без проблем.
Перегрев процессора тоже не исключён. Радиаторы у CPU давно пылесосили ? :)
Падает именно gbak или процесс сервера ?
Я копию восстанавливаю без localhost, и если я правильно понимаю gbak сам и
создает новую
"Vadim Mescheryakov" ...
>Если использую в select функцию из своей UDF, так же коннект рвется, без
записи в протокол
Откатился на официальную версию, выложенную на сайте firebirdsql
UDF заработали
А до этого какая версия была ?
Но что с gbak ещё не понятно
Если ре
Установил и UDF не смог использовать - разрыв соединений.
Откатился на официальную сборку 2.1.3.18185
Сегодня ночью Gbak не прошел, так же умер внезапно.
До этого стоял FB 1.0 64 I/O, все началось после обновления сервера и
установки моей udf
С уважением, Мещеряков Вадим
директор ООО "
"Ovchinnikov Vasily" ...
> gbak: writing data for table PB_SALE
> gbak: ERROR: message length error (encountered 288, expected 284)
> gbak: ERROR: gds_$receive failed
> gbak: Exiting before completion due to errors
Меняли формат записи. Скорее всего дропнули
Horsun Vlad пишет:
"Ovchinnikov Vasily" ...
gbak: writing data for table PB_SALE
gbak: ERROR: message length error (encountered 288, expected 284)
gbak: ERROR: gds_$receive failed
gbak: Exiting before completion due to errors
Меняли формат записи. Скорее всего дропнул
"Ovchinnikov Vasily" ...
> Horsun Vlad пишет:
> > "Ovchinnikov Vasily" ...
> >
> >> gbak: writing data for table PB_SALE
> >> gbak: ERROR: message length error (encountered 288, expected 284)
> >> gbak: ERROR: gds_$rec
Привет!
>>memtest прогоняли на сервере?
> Нет, там память ECC, сервер сурьезный, ни каких дампов памяти не создается,
Я бы не молился на магическое буквосочетание "ECC" - всякое бывает и
не все ошибки ейный контроллер ловит. Судя по описанию проблем выше -
железо, 99.99%. Может BB на винте?
--
ðÃÃÃÃ
Ã.
úÃÃÃ
ÃÃÃ ÃÃÃÃÃ ÃÃÃÃÃ
ÃÃÃÃÃÃ. ðÃÃÃÃ
ÃÃÃÃÃÃÃÃÃÃÃ
ÃÃÃ ÃÃÃÃ ÃÃ
ÃÃ
à service api ïó
ÃÃ
ÃÃÃ
ÃÃ ÃÃÃÃÃÃÃÃÃÃÃ ÃÃ ÃÃ
ÃÃÃÃÃÃÃà "ÃÃÃÃÃÃÃÃÃÃÃ". ðÃÃÃÃÃÃ
à ÃÃ
ÃÃ
ÃÃÃÃÃÃ ÃÃ
ÃÃÃ
ÃÃ
FB ÃÃÃ ÃÃ
> Ã ÃÃÃÃÃ
ÃÃÃ
ÃÃ
ÃÃÃÃÃ ÃÃÃÃÃÃÃÃ
ÃÃ?
þÃà ÃÃÃÃÃÃÃÃ
ÃÃ? ðÃÃÃÃ
ÃÃÃÃ ÃÃÃÃÃÃÃ
à ÃÃÃÃà Ãà 100% äÃÃà ÃÃÃÃà ÃÃ
ÃÃÃÃÃÃÃ
Ã.
äÃÃÃÃÃÃ
> ëÃ
Ã.
ðÃÃÃÃÃÃÃ
Ã. FB Ã ÃÃÃÃÃÃÃÃ
ÃÃÃÃÃÃ
ÃÃÃÃÃ
ÃÃ. óÃÃ
ÃÃ ÃÃÃ
. ðÃÃÃÃÃÃà ÃÃÃÃà 10.
ïÃÃÃÃÃÃÃà ÃÃ
ÃÃÃÃÃ.
äÃÃÃÃÃÃ
Hello, Dmitry!
Dmitry Lendel wrote:
ÐоÑмоÑÑел. FB и бÑÑÑÑодейÑÑвие ÑиÑÑемÑ. СÑели вÑе. ÐÑоÑ
Ð¾Ð´Ð¸Ñ Ð¼Ð¸Ð½ÑÑ 10.
ÐÑпÑÑкаÑÑ ÑеÑÑÑÑÑ.
ÑÑÑ... Ðим, возÑми Process Explorer Ñ sysinternals.com, запÑÑÑи
его и ÑмÐ
ðÃÃÃÃ
Ã.
> ÃÃÃ... äÃÃ, ÃÃÃÃÃà Process Explorer à sysinternals.com, ÃÃÃÃÃÃÃ
> Ã
ÃÃ Ã ÃÃÃÃÃÃ ÃÃ ÃÃ
ÃÃÃÃÃ ÃÃÃÃÃ
ÃÃà fbserver.exe. ëÃÃÃÃ
ÃÃÃÃÃ
> ÃÃÃÃÃ
restore ÃÃÃÃÃÃÃ, à Ã.Ã. ïÃÃÃÃÃÃ
ÃÃ
ÃÃÃ ÃÃÃÃÃÃÃÃÃÃÃ ÃÃ
Hello, Alexandr Kochmin!
You wrote to Dmitry Lendel on Thu, 11 May 2006 11:26:10 +0700:
AK> ÃÃÃÃÃ
Ã
ÃÃ
ÃÃÃÃÃÃÃÃ
ÃÃÃÃÃÃ
ÃÃÃÃÃ
ÃÃ?
AK> ðÃÃÃÃÃÃÃÃÃ
ÃÃÃÃ?
ûÃÃÃÃ, ÃÃÃÃà ÃÃà ÃÃÃÃ
ÃÃ ÃÃ
ÃÃ
ÃÃÃ
Ã, ÃÃ ÃÃÃ "ÃÃ
ÃÃÃ
ÃÃÃÃÃÃ
ÃÃÃÃ
1 - 100 of 129 matches
Mail list logo
