Re: GBAK - Логирование ошибок при restore
Hello, Vsevolod! Vsevolod wrote: надо было ставить FBDataGuard. Он бы предупредил про отсутствие места. Я не в курсе, а эта тулза работает под Linux ? работает. если у тебя все пользователи SYSDBA, то понятно, почему никто ничего не заметил. А откуда такое предположение интересно ? :) Довольно обидные Ваши слова (с) Полиграф Полиграфыч предположение оттуда, что при ошибках gbak обычно оставляет базу в состоянии shutdown, а в этом состоянии подключиться может только SYSDBA. Все пользователи ходят под своими логинами, которые включены в соответствующие роли. ну и чудненько. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re[6]: GBAK - Логирование ошибок при restore
Привет! Влад в приватной беседе посоветовал пожаловаться Трекеру По опыту могу сказать, что вменяемое требование или описание бага в трекере всегда либо внедряется, либо фиксится. А Влад что на нелегальном положении ? Я за него говорить правов не имею, но рискну предположить, что у него во-первых дел хватает, а во-вторых - устал он комментировать очевидные вещи. Ок, пожалуемсо Правда я никогда еще не жаловался трекеру. Надеюсь выйдет. Там всё просто :) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Re[4]: GBAK - Логирование ошибок при restore
Привет! Влад в приватной беседе посоветовал пожаловаться Трекеру ;-) По опыту могу сказать, что вменяемое требование или описание бага в трекере всегда либо внедряется, либо фиксится. А Влад что на нелегальном положении ? :) Ок, пожалуемсо :) Правда я никогда еще не жаловался трекеру. Надеюсь выйдет. С уважением, Всеволод. -- View this message in context: http://firebird.1100200.n4.nabble.com/GBAK-restore-tp3677712p3689874.html Sent from the firebird-russian mailing list archive at Nabble.com.
Re: GBAK - Логирование ошибок при restore
Привет ! надо было ставить FBDataGuard. Он бы предупредил про отсутствие места. Я не в курсе, а эта тулза работает под Linux ? Да и места там было навалом, там скорее сработало ограничение на размер Temp каталога, этот злосчастный индекс видимо его превысил. Сейчас это ограничение, естественно сняли. Собственно, по идее, когда происходят ошибки при restore, то база должна оставаться в состоянии shutdown. Я тоже так думаю, но gbak думает иначе :) если у тебя все пользователи SYSDBA, то понятно, почему никто ничего не заметил. А откуда такое предположение интересно ? :) Довольно обидные Ваши слова (с) Полиграф Полиграфыч Все пользователи ходят под своими логинами, которые включены в соответствующие роли. С уважением, Всеволод. -- View this message in context: http://firebird.1100200.n4.nabble.com/GBAK-restore-tp3677712p3689883.html Sent from the firebird-russian mailing list archive at Nabble.com.
Re[4]: GBAK - Логирование ошибок при restore
Привет! И мне показалось, что на будущее неплохо иметь такую инфу в конце лога. Я же не требую, никого не обвиняю, и так понял, что сам виноват. Нет так нет - приспособимся Но как никогда хотелось бы все же услышать начальника транспортного цеха (с) Влад в приватной беседе посоветовал пожаловаться Трекеру ;-) По опыту могу сказать, что вменяемое требование или описание бага в трекере всегда либо внедряется, либо фиксится. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: GBAK - Логирование ошибок при restore
Hello, Vsevolod! Vsevolod wrote: Хотелось бы послушать начальника транспортного цеха (с) надо было ставить FBDataGuard. Он бы предупредил про отсутствие места. Собственно, по идее, когда происходят ошибки при restore, то база должна оставаться в состоянии shutdown. если у тебя все пользователи SYSDBA, то понятно, почему никто ничего не заметил. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: GBAK - Логирование ошибок при restore
Vsevolod пишет: Самое обидное что в конце лог файла рестора все было хорошо, что меня, в принципе и сбило с толку и я потерял время : gbak:activating and creating deferred index RDB$FOREIGN101 gbak:committing metadata gbak:finishing, closing, and going home Sat Jul 16 05:45:32 EEST 2011 В связи с этим у меня вопрос - это так и должно было быть и всегда было и я сам дурак или все же неплохо было бы выводить какие-то сообщения в конце лога в случае каких-либо ошибок ? Так быть не должно. Так всегда было. Ты не дурак. Надо выводить, да. Вот пока обида не прошла - занимай гражданскую позицию и пиши в трекер :) А то у аксакалов глаз на это безобразие уже замылился.
Re: Re[2]: GBAK - ����������� ������ ��� restore
ðÒÉ×ÅÔ! ÔÁËÏÍ ÓÌÕÞÁÅ ÎÁÄÏ ÐÒÏÓÔÏ ÐÏÓÌÁÔØ Õ×ÅÄÏÍÌÅÎÉÅ ÁÄÍÉÎÕ É ×Ó£. é gbak ÞÅÓÔÎÏ ×ÏÚ×ÒÁÝÁÅÔ ÎÅÎÕÌÅ×ÏÊ ËÏÄ ÏÛÉÂËÉ ÔÏÍÕ ÐÒÏÃÅÓÓÕ, ËÏÔÏÒÙÊ ÅÇÏ ×ÙÚ×ÁÌ. gbak ÞÅÓÔÎÏ ×ÏÚ×ÒÁÝÁÅÔ ÎÅÎÕÌÅ×ÏÊ ËÏÄ ÏÛÉÂËÉ ÅÓÌÉ ÅÍÕ îå ÕËÁÚÁÌÉ ÐÁÒÁÍÅÔÒ -v ÔÏÇÄÁ ÄÅÊÓÔ×ÉÔÅÌØÎÏ %ERRORLEVEL%=1 É × ÌÏÇÅ: ... gbak: ERROR:operating system directive WriteFile failed gbak: ERROR:îÅÄÏÓÔÁÔÏÞÎÏ ÍÅÓÔÁ ÎÁ ÄÉÓËÅ. gbak:Exiting before completion due to errors ÅÓÌÉ ÕËÁÚÁÎ -v ×ÏÚ×ÒÁÝÁÅÔ %ERRORLEVEL%=0 É × ÌÏÇÅ: ... gbak:activating and creating deferred index TBL1_INDEX1 gbak:cannot commit index TBL1_INDEX1 gbak: ERROR:operating system directive WriteFile failed gbak: ERROR:îÅÄÏÓÔÁÔÏÞÎÏ ÍÅÓÔÁ ÎÁ ÄÉÓËÅ. gbak:activating and creating deferred index PK_TBL1 gbak:committing metadata gbak:finishing, closing, and going home ôÅÓÔÉÒÏ×ÁÌÏÓØ ÎÁ Windows gbak version WI-V2.1.4.18420 Firebird 2.1 ×ÐÒÏÞÅÍ ÎÁ Yaffil 885 ÔÁË ÖÅ ÎÁ ÄÒÕÇÉÈ ×ÅÒÓÉÑÈ ÎÅ ÔÅÓÔÉÒÏ×ÁÌÏÓØ. òÅÞØ ÉÄ£Ô ÔÏÌØËÏ Ï ÓÉÔÕÁÃÉÉ, ÏÐÉÓÁÎÎÏÊ ôó: ÉÎÄÅËÓ, ÄÌÑ ×ÏÓÓÔÁÎÏ×ÌÅÎÉÑ ËÏÔÏÒÏÇÏ ÎÅ È×ÁÔÉÌÏ ÍÅÓÔÁ ÎÁ ÄÉÓËÅ ÎÅ Ñ×ÌÑÅÔÓÑ PK ÉÌÉ FK. ÷ ÓÌÕÞÁÅ PK ÉÌÉ FK ËÏÄ ÏÛÉÂËÉ ÎÅÎÕÌÅ×ÏÊ. -- ó Õ×ÁÖÅÎÉÅÍ, ÷ÁÄÉÍ ìÅÂÅÄØ éÎÖÅÎÅÒ-ÐÒÏÇÒÁÍÍÉÓÔ æÉÒÍÁ ôÅÒÍÉÎÁÌ Ç.ðÏÌÔÁ×Á
Re: Re[2]: GBAK - Логирование ошибок при restore
Привет! Аааа, так тебе рюшечку хочется? Да, рюшечки иногда нужны, я согласен, что было бы хорошо иметь подобный визуальный отчёт в конце работы. Мы, рюшечкофилы, твою позицию поняли :) Хотя я не назвал бы это рюшечкой. Да, и слабо верится, что ты на все случаи жизни используешь скрипты для этого дела. Иногда быстрее набрать команду с несколькими параметрами и отресторить к примеру девелоперскую базу причем не выводить лог в файл. Я почему написал первый пост, просто на эти грабли за 10 лет наступил впервые и по законам Мерфи в самое неподходящее время. И мне показалось, что на будущее неплохо иметь такую инфу в конце лога. Я же не требую, никого не обвиняю, и так понял, что сам виноват. Нет так нет - приспособимся :) Но как никогда хотелось бы все же услышать начальника транспортного цеха (с) С уважением, Всеволод. -- View this message in context: http://firebird.1100200.n4.nabble.com/GBAK-restore-tp3677712p3683801.html Sent from the firebird-russian mailing list archive at Nabble.com.
Re: GBAK - Логирование ошибок при restore
Привет! В вопросе содержится ответ ;-) Я так понял моя гипотеза, что я сам дурак, является верной :) Хотя ... Вывести в конце лога какие-то предупреждения, на мой взгляд, все же не помешало бы. Хотелось бы послушать начальника транспортного цеха (с) Вот уж кому-кому, а линуксоиду грех жаловаться на отсутствие средств проверки в таких случаях. Мерси за комплиман (с) :) Но я, к сожалению, не являюсь специалистом в Linux. За скрипт отдельное спасибо :) С уважением, Всеволод -- View this message in context: http://firebird.1100200.n4.nabble.com/GBAK-restore-tp3677712p3680057.html Sent from the firebird-russian mailing list archive at Nabble.com.
Re[2]: GBAK - Логирование ошибок при restore
Привет! А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В таком случае надо просто послать уведомление админу и всё. И gbak честно возвращает ненулевой код ошибки тому процессу, который его вызвал. Удивлен. Есть gbak, консоль и админ за консолью, запускающий _штатный_ gbak. Админу было бы удобно в конце работы gbak видеть строку Error count: 0, сразу. Аааа, так тебе рюшечку хочется? Да, рюшечки иногда нужны, я согласен, что было бы хорошо иметь подобный визуальный отчёт в конце работы. Тем более, что цена вопроса не велика. Ну вот я не уверен, что время кого-нибудь из птицеводов стоит таратить на этот пустяк. Пусть лучше тру-смп допилят. Из того примера, который я приводил легко можно сделать обёртку, которая именно выдаст инфу, были ли ошибки при ресторе или нет :) -- Best regards, Sergeymailto:gebele...@gmail.com
Re: GBAK - Логирование ошибок при restore
Vsevolod пишет: В связи с этим у меня вопрос - это так и должно было быть и всегда было и я сам дурак или все же неплохо было бы выводить какие-то сообщения в конце лога в случае каких-либо ошибок ? Присоединяюсь. Хотя бы счетчик ошибок в конце лога.
Re[2]: GBAK - Логирование ошибок при restore
Привет! Присоединяюсь. Хотя бы счетчик ошибок в конце лога. А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В таком случае надо просто послать уведомление админу и всё. И gbak честно возвращает ненулевой код ошибки тому процессу, который его вызвал. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: GBAK - Логирование ошибок при restore
Sergey Mereutsa пишет: Присоединяюсь. Хотя бы счетчик ошибок в конце лога. А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В таком случае надо просто послать уведомление админу и всё. И gbak честно возвращает ненулевой код ошибки тому процессу, который его вызвал. Удивлен. Есть gbak, консоль и админ за консолью, запускающий _штатный_ gbak. Админу было бы удобно в конце работы gbak видеть строку Error count: 0, сразу. Тем более, что цена вопроса не велика.
GBAK - Логирование ошибок при restore
Доброго времени суток, всем ! Ситуация следующая. Вчера я имел c утра веселые пару часов пока выяснял почему работа с БД стала жутко медленной. Причина - неактивность одного из индексов на многомиллионной таблице, который стал таким как оказалось после бекапа-рестора БД. Лог файл, на первый взгляд, был нормальным. Таблицы мониторинга практически не помогли в этой ситуации, они показывали всякую ерунду типа нулевого количества индексированных, неиндексированных чтений то более или менее нормальную статистику и самого тяжелого запроса не показали. Когда этот индекс был вычислен я более внимательно посмотрел на лог последнего рестора БД и нашел упоминание этого индекса: 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: ERROR:Error while trying to write to file gbak: ERROR:No space left on device gbak:activating and creating deferred index RDB$PRIMARY45 Самое обидное что в конце лог файла рестора все было хорошо, что меня, в принципе и сбило с толку и я потерял время : gbak:activating and creating deferred index RDB$FOREIGN101 gbak:committing metadata gbak:finishing, closing, and going home Sat Jul 16 05:45:32 EEST 2011 В связи с этим у меня вопрос - это так и должно было быть и всегда было и я сам дурак или все же неплохо было бы выводить какие-то сообщения в конце лога в случае каких-либо ошибок ? P.S. LI-V6.3.1.17910 Firebird 2.1 Classic, OS Linux Ubuntu 7.1 Server , Kernel 2.6.22-14-server I686 С уважением, Всеволод. -- View this message in context: http://firebird.1100200.n4.nabble.com/GBAK-restore-tp3677712p3677712.html Sent from the firebird-russian mailing list archive at Nabble.com.
Re: GBAK - Логирование ошибок при restore
Привет!
В связи с этим у меня вопрос - это так и должно было быть и всегда было и я
сам дурак или все же неплохо было бы выводить какие-то сообщения в конце
лога в случае каких-либо ошибок ?
В вопросе содержится ответ ;-)
P.S. LI-V6.3.1.17910 Firebird 2.1 Classic, OS Linux Ubuntu 7.1 Server ,
Kernel 2.6.22-14-server I686
Вот уж кому-кому, а линуксоиду грех жаловаться на отсутствие средств
проверки в таких случаях.
(форматирование может поехать, скрипт древний, как кал мамонта,
подобные трудятся везде у меня не первый год):
Вот пример (AS IS) для создания резервной копии всех БД, перечисленных
в файле aliases.conf:
#/bin/bash
#set -x
#
#
# This script will backup all databases from firebird aliases.conf file
#
# NOTE: In case of error lock file will NOT be erased
#
#
DB_USERNAME=username
DB_USERPASS=password
HOSTNAME=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
BACKUPLOCK=/tmp/dbbackuper20.lock
BACKUPCMD=/opt/fb20cs/bin/gbak -B -g
RESTORECMD=/opt/fb20cs/bin/gbak -C -REPLACE
CONTROLDB=localhost:cntldb
DELIMITER= --
BACKUPNAME=`date +_%d`
#this function will send mail to administrator
sendMail2Admin()
{
(
echo To: ad...@site.com
echo From: FB database backup script
echo Subject: Error during backup
echo
echo Please check logs - there are some errors during to database backup
process.
echo
) 21 | /usr/lib/sendmail -t
}
if [ -s $BACKUPLOCK ] ; then
echo [BACKUP LOCK DETECTED at: `date` , EXITING]
exit
fi
echo baclup lock$BACKUPLOCK
for db in $DBNAME
do
echo $DELIMITER
echo
# generating database backup
echo [DATABASE BACKUP START at: `date` FOR $db]
$BACKUPCMD -user $DB_USERNAME -password $DB_USERPASS $HOSTNAME$db
$TMP$db$BACKUPNAME$FBK
resCode=$?
#checking for error
if [ $resCode -ne 0 ]
then
echo [DATABASE BACKUP PROBLEM at: `date` FOR $db]
sendMail2Admin
#exit
fi
echo [DATABASE BACKUP END at: `date` FOR $db]
echo [DATABASE CONTROL RESTORE START at: `date` FOR $db]
# doing control restore
$RESTORECMD -user $DB_USERNAME -password $DB_USERPASS $TMP$db$BACKUPNAME$FBK
$CONTROLDB
resCode=$?
#checking for error
if [ $resCode -ne 0 ]
then
echo [CONTROL RESTORE PROBLEM at: `date` FOR $db]
sendMail2Admin
#exit
fi
echo [DATABASE CONTROL RESTORE END at: `date` FOR $db]
# if ok, moving to database
# if failed - mail to admin
rm -rf $TMP$CONTROLDB
mv $TMP$db$BACKUPNAME$FBK $BACKUPDIR
rm -rf $BACKUPDIR$db$BACKUPNAME$FBK$BZ2
bzip2 -z -9 $BACKUPDIR$db$BACKUPNAME$FBK
echo Backup name: $BACKUPDIR$db$BACKUPNAME$FBK
echo $DELIMITER
sync
done
rm -rf $BACKUPLOCK
--
Best regards,
Sergeymailto:gebele...@gmail.com
gbak через сервисы
Добрый день! Если из приложения бэкапить/разбэкапливать базу через сервисы, то на клиента в случае ошибки/предупреждения передается только текст или еще и код какой-нибудь? Очень надо отличить фатальную ошибку от предупреждения, например, о том, что уменьшен размер страницы. Андрей
Re: gbak через сервисы
Если из приложения бэкапить/разбэкапливать базу через сервисы, то на клиента в случае ошибки/предупреждения передается только текст или еще и код какой-нибудь? Лучше всего - полный лог. Даже если все вдруг прошло успешно. :)
Re: gbak через сервисы
Andrei пишет: Если из приложения бэкапить/разбэкапливать базу через сервисы, то на клиента в случае ошибки/предупреждения передается только текст или еще и код какой-нибудь? Текст передается через текстовый буфер, ошибки - через статус-вектор. Дмитрий
Re[2]: Segmentation fault во время работы gbak -r
Привет! memtest прогоняли на сервере? Нет, там память ECC, сервер сурьезный, ни каких дампов памяти не создается, Я бы не молился на магическое буквосочетание ECC - всякое бывает и не все ошибки ейный контроллер ловит. Судя по описанию проблем выше - железо, 99.99%. Может BB на винте? -- Best regards, Sergeymailto:gebele...@gmail.com
Segmentation fault во время работы gbak -r
Здравствуйте. Обновил у заказчика firebird 1.0 на firebird 2.1 (нужно было использовать временные таблицы и склеивать запросы в процедурах) На сервере стоит ASP Linux 9.0 Ядро 2.4.20-9asp (libs-2.3.2) Получил такие проблемы: 1. Периодически стал умирать gbak -r на восстановлении базы (база 3.7 Gb) с сообщением Segmentation fault (копию он всегда делает исправно) 2. При вызове процедур, в которых используются временные таблицы и udf часто (может быть и такое , что до 13-00 не работает, после 13-00 работает :) возникает ошибка: ISC ERROR MESSAGE: Unable to complete network request to host 192.168.0.1. Error writing data to the connection. Программа на вашем хост-компьютере разорвала установленное подключение) Потеряна связь с БД (SQL Server Error: ISC ERROR CODE:335544721 ISC ERROR MESSAGE: Unable to complete network request to host 192.168.0.1. Error writing data to the connection. Программа на вашем хост-компьютере разорвала установленное подключение) При этом, после такого сообщения программа не теряет связь с базой данных а продолжает нормально работать. Весь комплект процедур и udf работает у другого заказчика на Open Suse 11 и ни каких подобных ошибок не возникает, Так же нет подобных ошибок в моем офисе, там стоит та же самая OS (ASP Linux 9.0 Ядро 2.4.20-9asp (libs-2.3.2)) Похоже на то что обе проблемы связаны. Как полечить? С уважением, Мещеряков Вадим директор ООО Комплексные Системы 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Моб: +7 922 6395170 Web: www.del-fin.ru ICQ: 343-554-572 SKYPE: vadimmescheryakov
Re: Segmentation fault во время работы gbak -r
Привет! Обновил у заказчика firebird 1.0 на firebird 2.1 Разрядность ОС и билд Птица выдашь только под пытками? memtest прогоняли на сервере? -- Best regards, Sergeymailto:gebele...@gmail.com
RE: Segmentation fault во время работы gbak -r
Обновил у заказчика firebird 1.0 на firebird 2.1 Разрядность ОС и 32 билд Птица выдашь только под пытками? 2.1.2 а вот вчера поменял на 2.1.3.18185 и не помогло. memtest прогоняли на сервере? Нет, там память ECC, сервер сурьезный, ни каких дампов памяти не создается, ни в каких логах ничего не отражается Просто работал gbak и прервался прям на полуслове в логе. Segmentation fault увидел всего раз - когда в консоли без ключа -y запустил. С уважением, Мещеряков Вадим директор ООО Комплексные Системы 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Моб: +7 922 6395170 Web: www.del-fin.ru ICQ: 343-554-572 SKYPE: vadimmescheryakov
Re: Segmentation fault во время работы gbak -r
Vadim Mescheryakov ... Здравствуйте. Обновил у заказчика firebird 1.0 на firebird 2.1 (нужно было использовать временные таблицы и склеивать запросы в процедурах) На сервере стоит ASP Linux 9.0 Ядро 2.4.20-9asp (libs-2.3.2) Получил такие проблемы: 1. Периодически стал умирать gbak -r на восстановлении базы (база 3.7 Gb) с сообщением Segmentation fault (копию он всегда делает исправно) Периодически - это как ? Если взять бекап, на котором был сбой, и отресторить ещё раз - упадёт ? Падает именно gbak или процесс сервера ? 2. При вызове процедур, в которых используются временные таблицы и udf часто (может быть и такое , что до 13-00 не работает, после 13-00 работает :) возникает ошибка: ISC ERROR MESSAGE: Unable to complete network request to host 192.168.0.1. Error writing data to the connection. Программа на вашем хост-компьютере разорвала установленное подключение) Потеряна связь с БД (SQL Server Error: ISC ERROR CODE:335544721 ISC ERROR MESSAGE: Unable to complete network request to host 192.168.0.1. Error writing data to the connection. Программа на вашем хост-компьютере разорвала установленное подключение) Что в firebird.log ? При этом, после такого сообщения программа не теряет связь с базой данных а продолжает нормально работать. Не может этого быть. Просто программа сама заново коннектится. Весь комплект процедур и udf работает у другого заказчика на Open Suse 11 и ни каких подобных ошибок не возникает, Так же нет подобных ошибок в моем офисе, там стоит та же самая OS (ASP Linux 9.0 Ядро 2.4.20-9asp (libs-2.3.2)) Похоже на то что обе проблемы связаны. Как полечить? Для начала нужно причину определить http://www.ibphoenix.com/main.nfs?a=ibphoenixs=1254244067:355713l=;PAGES;NAME=%27ibp_gdb_linux%27 -- Хорсун Влад
RE: Segmentation fault во время работы gbak -r
Периодически - это как ? На 5 попыток одна прошла. Если взять бекап, на котором был сбой, и отресторить ещё раз - упадёт ? От копии не зависит, может отресторить а может и нет. Скопировал для пробы на свой комп - отресторило Прерывается как правило, на построении индексов, но всегда в разном месте. Падает именно gbak или процесс сервера ? Я копию восстанавливаю без localhost, и если я правильно понимаю gbak сам и создает новую базу Gbak исчезает из памяти Что в firebird.log ? Есть несколько ошибок: mainserver.book.ru Mon Sep 28 14:31:19 2009 INET/inet_error: read errno = 104 mainserver.book.ru Mon Sep 28 14:31:19 2009 INET/inet_error: read errno = 104 mainserver.book.ru Mon Sep 28 16:32:53 2009 INET/inet_error: read errno = 110 mainserver.book.ru Mon Sep 28 16:32:53 2009 INET/inet_error: read errno = 110 mainserver.book.ru Mon Sep 28 17:51:43 2009 INET/inet_error: read errno = 110 Но у меня ощущение что их там меньше чем количество сообщений в логах программы сервера при попытке запуска процедуры. При этом, после такого сообщения программа не теряет связь с базой данных а продолжает нормально работать. Не может этого быть. Просто программа сама заново коннектится. Может быть и коннектится, только я что то не помню что бы я написал такой код :) Пойду почитаю свои исходники. Процедуры же я вызываю отдельной функций в отдельной транзакции, а что то мне помнится в DBExpress если TSQLConnection не подключено, то она само соединяется при попытке открыть запрос, щас ещё логи xinet.d посмотрю. А пока скачал исходники и перекомпилировал Firebird с теми библиотеками что стоят на сервере. Установил и запустил восстановление из копии Блин, не помогло, только что прервалось gbak:activating and creating deferred index DATEDOC gbak:activating and creating deferred index IDDOC gbak:activating and creating deferred index NDOC gbak:activating and creating deferred index PRIM gbak:activating and creating deferred index STATUS gbak:activating and creating deferred index RDB$PRIMARY1 gbak:committing metadata Segmentation fault [r...@mainserver firebird]# С уважением, Мещеряков Вадим директор ООО Комплексные Системы 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Моб: +7 922 6395170 Web: www.del-fin.ru ICQ: 343-554-572 SKYPE: vadimmescheryakov
RE: Segmentation fault во время работы gbak -r
При попытке перекомпилировать процедуру в 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. Программа на вашем хост-компьютере разорвала установленное подключение. . В firebird.log Пусто IbExpert по честному отвалился от базы С уважением, Мещеряков Вадим директор ООО Комплексные Системы 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Моб: +7 922 6395170 Web: www.del-fin.ru ICQ: 343-554-572 SKYPE: vadimmescheryakov
Re: Segmentation fault во время работы gbak -r
Vadim Mescheryakov ... Периодически - это как ? На 5 попыток одна прошла. Если взять бекап, на котором был сбой, и отресторить ещё раз - упадёт ? От копии не зависит, может отресторить а может и нет. Проблемы с железом, 99.99%. 0.01% - какой-то хитрый софт вмешивается Скопировал для пробы на свой комп - отресторило Прерывается как правило, на построении индексов, но всегда в разном месте. Тем более. Проверяй память. При построении индексом она очень активно используется. Я так у себя 2 года назад неделю ловил несуществующую проблему именно при построении индекса. Оказалась одна планка памяти из 4-х. Всё остальное работало без проблем. Перегрев процессора тоже не исключён. Радиаторы у CPU давно пылесосили ? :) Падает именно gbak или процесс сервера ? Я копию восстанавливаю без localhost, и если я правильно понимаю gbak сам и создает новую базу Gbak исчезает из памяти Это gbak + embedded. Движок и падает. -- Хорсун Влад
Re: Segmentation fault во время работы gbak -r
Vadim Mescheryakov ... Если использую в select функцию из своей UDF, так же коннект рвется, без записи в протокол Откатился на официальную версию, выложенную на сайте firebirdsql UDF заработали А до этого какая версия была ? Но что с gbak ещё не понятно Если рестор одного и тогоже бекапа то падает, то не падает, то дело явно не в gbak'е. -- Хорсун Влад
RE: Segmentation fault во время работы gbak -r
Откатился на официальную версию, выложенную на сайте firebirdsql UDF заработали А до этого какая версия была ? В августе поставил с сайта 2.1.2 В сентябре обновил на 2.1.3.18185 Вчера скачал исходники - пересобрал эту же версию на том сервере где должено все работать. Установил и UDF не смог использовать - разрыв соединений. Откатился на официальную сборку 2.1.3.18185 Сегодня ночью Gbak не прошел, так же умер внезапно. До этого стоял FB 1.0 64 I/O, все началось после обновления сервера и установки моей udf С уважением, Мещеряков Вадим директор ООО Комплексные Системы 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Моб: +7 922 6395170 Web: www.del-fin.ru ICQ: 343-554-572 SKYPE: vadimmescheryakov
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
On Fri, 17 Jul 2009 11:22:48 +0500, Oleg Matveyev o_matv...@mail.ru wrote: Провел эксперимент под виндой и Classic. У меня и на Винде и на Линуксе второй вариант не прокатывает. gbak: ERROR:connection rejected by remote interface gbak:Exiting before completion due to errors т.е. база указывается только локально. Запусился бакап, и появились _два_ fb_inet_server! оба жрут по одному ядру, так что в твоем эксперименте 200% для одного процесса Superserver объяснимо. Вот как раз и ничего и не объясняет: для классика - да, для супера - нет. -- Гоголь Дмитрий
CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
Здравствуйте, уважаемые. Накануне пятницы задам глупый вопрос. Просьба сильно не пинать Вводная: имеется сервер на базе Intel D805, Centos 5.3, FirebirdSS-2.1.3.18156-0.i686 брал с http://www.dqteam.com/fb2/ сборка от Sergey Mereutsa. Обратил внимание, что при работе GBAK утилита top показывает 200% использования CPU. До сего дня просто не интересовался. Вопрос: Как такое возможно? Напомню: FB SuperServer -- Гоголь Дмитрий
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
Привет! Обратил внимание, что при работе GBAK утилита top показывает 200% использования CPU. До сего дня просто не интересовался. Вопрос: Как такое возможно? Напомню: FB SuperServer Пусть меня Птицеводы поправят, но сие возможно только если: 1) top глючит и плющит нипадеццки и он врёт 2) gbak использует 2 нити, обе хавают по ядру на 100% -- Best regards, Sergeymailto:gebele...@gmail.com
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
On Thu, 16 Jul 2009 12:40:45 +0500, Sergey Mereutsa gebele...@gmail.com wrote: Пусть меня Птицеводы поправят, но сие возможно только если: 1) top глючит и плющит нипадеццки и он врёт 2) gbak использует 2 нити, обе хавают по ядру на 100% Ну слава Богу, с головой значит у меня все в порядке. Я сам такие же выводы сделал. Но как-то уж очень странно, особенно учитывая что top-у не один год от роду. Да и многопроцессорным(многоядерным) машинам тоже. А по второму пункту вопрос к Владу и Диме: оно так бывает? -- Гоголь Дмитрий
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
Гоголь Дмитрий wrote: 2) gbak использует 2 нити, обе хавают по ядру на 100% оно так бывает? Нет. -- Дмитрий Еманов
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
On Thu, 16 Jul 2009 16:08:05 +0500, Dmitry Yemanov dim...@users.sf.net wrote: Гоголь Дмитрий wrote: 2) gbak использует 2 нити, обе хавают по ядру на 100% оно так бывает? Нет. А через ServicesAPI? Сейчас проверял: если запускать gbak с ключом -se, то 200% на процесс, если без такового - 100%. -- Гоголь Дмитрий
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
Гоголь Дмитрий wrote: А через ServicesAPI? Там на сервере не может быть никакого процесса gbak. Разве что тот, который ты вызвал с -se (если ты это делаешь локально). Но он процессор грузить почти не будет. Сейчас проверял: если запускать gbak с ключом -se, то 200% на процесс, Два потока работают независимо: сервис gbak и fbserver. Аффинити на линуксах нет, т.е. процессом сервера может быть загружено два ядра. Правда, вряд ли одновременно оба на 100%, ибо потоки по сути последовательно работают в процессе бекапа. если без такового - 100%. Тоже самое, но каждый процесс (gbak, fbserver) загрузит по одному ядру. -- Дмитрий Еманов
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
óÅÊÞÁÓ ÐÒÏ×ÅÒÑÌ: ÅÓÌÉ ÚÁÐÕÓËÁÔØ gbak Ó ËÌÀÞÏÍ -se, ÔÏ 200% ÎÁ ÐÒÏÃÅÓÓ, ÅÓÌÉ ÂÅÚ ÔÁËÏ×ÏÇÏ - 100%. ÓÔÅÓÎÑÀÓØ ÓÐÒÏÓÉÔØ: ÐÏÌÎÕÀ ÓÔÒÏËÕ ÚÁÐÕÓËÁ Ó ËÌÀÞÅÍ -se ÍÏÖÎÏ Õ×ÉÄÅÔØ? ÒÁÚ×Å ÞÔÏ ÐÁÒÏÌØ ÍÏÖÎÏ ÐÒÏÐÕÓÔÉÔØ :-)
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
On Thu, 16 Jul 2009 17:22:28 +0500, Dmitry Yemanov dim...@users.sf.net wrote: Гоголь Дмитрий wrote: А через ServicesAPI? Там на сервере не может быть никакого процесса gbak. Разве что тот, который ты вызвал с -se (если ты это делаешь локально). Но он процессор грузить почти не будет. А gbak и не вижу, есть процесс fbserver и он грузит до 200%. Два потока работают независимо: сервис gbak и fbserver. Аффинити на линуксах нет, т.е. процессом сервера может быть загружено два ядра. Правда, вряд ли одновременно оба на 100%, ибо потоки по сути последовательно работают в процессе бекапа. Спасибо, Дима, за подробные объяснения. PS. И еще спасибо за реализацию: Dmitry Yemanov resolved CORE-1971. -- Resolution: Fixed The new predicate evaluation order is always from left to right. -- Гоголь Дмитрий
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
А gbak и не вижу, есть процесс fbserver и он грузит до 200%. Чтобы не быть голословным: http://alf2.nm.ru/fb_top.gif -- Гоголь Дмитрий
Re: CentOS + FB2.1.3 SS + gbak + TOP CPU=200%
ÄÁ ÔÁÍ ×ÓÅ ÔÏ ÖÅ ÓÁÍÏÅ ÔÏÌØËÏ ÄÏÂÁ×ÌÑÅÔÓÑ -se hostname:service_mgr ÏË, ÐÅÒÅÆÒÁÚÉÒÕÀ (ÞÔÏ ÈÏÔÅÌ Õ×ÉÄÅÔØ): ÐÕÔØ Ë âä - ÔÏÞÎÏ ÕËÁÚÁÎ ÌÏËÁÌØÎÙÊ, ÂÅÚ hostname:?
Backup, gbak vs api vs Firebird-Net-Provider (бэкап с удаленного сервера с доставкой результата на локальную машину)
У gbak есть полезная возможность - бэкап с удаленного сервера с доставкой результата на локальную машину. Очень нужна данная функциональность. Отсутствует в Firebird-Net- Provider - сохранение бэкапа только в файловой системе сервера. В родном API клиента - не нашел, похоже тоже отсутствует. Выходит gbak использует недокументированные возможности API? Просто вариант с запуском из управляемого кода gbak (а значит придется утилиты отставлять на локальную машину из дистрибутива сервера для конкретной OS) в консоле слегка кривоват, может кто что подскажет? Заранее спасибо за ответ.
Re: Backup, gbak vs api vs Firebird-Net-Provider (бэкап с удаленного сервера с доставкой результата на локальную машину)
Hello, Eugeny! Vinogradniy Eugeny wrote: У gbak есть полезная возможность - бэкап с удаленного сервера с доставкой результата на локальную машину. мда. Эта полезная возможность является изначально штатной для gbak. И вообще gbak это обычная программа, которая читает все данные и записывает в файл своего формата. www.ibase.ru/devinfo/gbak.htm Очень нужна данная функциональность. Отсутствует в Firebird-Net- Provider - сохранение бэкапа только в файловой системе сервера. В родном API клиента - не нашел, похоже тоже отсутствует. потому что клиент может только вызвать Services API. А Services API это команды сервера, поэтому выполняются ТОЛЬКО на сервере. см. статью по ссылке выше. Соответственно имитация gbak через API - это ахинея. Выходит gbak использует недокументированные возможности API? гм, что? Просто вариант с запуском из управляемого кода gbak (а значит придется утилиты отставлять на локальную машину из дистрибутива сервера для конкретной OS) в консоле слегка кривоват, может кто что подскажет? кривоват чем? И зачем бэкап нужен на локальной машине, если голый клиент с этим файлом бэкапа ничего сделать не может? Разве что кроме как заресторить его на сервер. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Backup, gbak vs api vs Firebird-Net-Provider (бэкап с удаленного сервера с доставкой результата на локальную машину)
Hello, Eugeny! Vinogradniy Eugeny wrote: Соответственно имитация gbak через API - это ахинея. И вправду уверен? Про имитацию не было и слова. я с Вами на брудершафт не пил. И да - уверен. Имитация, шмитация. Если не понимаете, как работает gbak, то чего API ковырять? Нужен например для того, чтобы автоматический бэкап осуществлялся с другой машины(может и не одной) в сети и при этом был кросплатформенным (.Net) gbak вполне кроссплатформенный. А про то, что gbak.exe это обычная программа, которую может написать любой, на чем угодно - я уже говорил. и не тащил за собой дистрибутивы серверов для всевозможных осей. На локальной машине бэкап нужен для более надежного хранения. если не трогать вопрос на тему более надежного хранения, то см. выше. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Backup, gbak vs api vs Firebird-Net-Provider (бэкап с удаленного сервера с доставкой результата на локальную машину)
Спасибо за ответ. On 26 июн, 11:58, Dmitri Kuzmenko k...@ibase.ru wrote: Hello, Eugeny! Соответственно имитация gbak через API - это ахинея. И вправду уверен? Про имитацию не было и слова. Просто вариант с запуском из управляемого кода gbak (а значит придется утилиты отставлять на локальную машину из дистрибутива сервера для конкретной OS) в консоле слегка кривоват, может кто что подскажет? кривоват чем? И зачем бэкап нужен на локальной машине, если голый клиент с этим файлом бэкапа ничего сделать не может? Разве что кроме как заресторить его на сервер. Нужен например для того, чтобы автоматический бэкап осуществлялся с другой машины(может и не одной) в сети и при этом был кросплатформенным (.Net) и не тащил за собой дистрибутивы серверов для всевозможных осей. На локальной машине бэкап нужен для более надежного хранения.
Re: Backup, gbak vs api vs Firebird-Net-Provider (бэкап с удаленного сервера с доставкой результата на локальную машину)
On Jun 26, 12:22 pm, Vinogradniy Eugeny vinograd...@gmail.com wrote: Нужен например для того, чтобы автоматический бэкап осуществлялся с другой машины(может и не одной) в сети и при этом был кросплатформенным (.Net) и не тащил за собой дистрибутивы серверов для всевозможных осей. На локальной машине бэкап нужен для более надежного хранения. дотнет считать кроссплатформенным можно лишь условно. Таки обычный gbak гораздо более кроссплатформенен :) И дистрибутив тащить не нужно - скопировать gbak, клиентская либу, firebird.msg и рунтайм от студии. Таки админские задачи нужно решать админскими методами, т.е. использовать готовый софт, а не писать/искать что-то невообразимое.
Re: gbak - новый параметр для задания имени файла ?
PEAKTOP wrote:
Можно даже без рара, когда-то подглядел в конфе:
for /F tokens=1,2,3 delims=/. %%a in ('date /T') do set
date_name=%%c.%%b.%%a
set history_dir=history\%date_name%
With best regards, Nikolay Ponomarenko
Спасибо. Идея, однако.
У меня сделано так (Win2003):
SET Max_Files=5
rem This value is needed for deleting old backups
rem without it we could not SET and READ new value inside FOR circle
SETLOCAL ENABLEDELAYEDEXPANSION
rem Get then current date: -MM-DD
rem !!! this code depends on computer locale settings !!!
rem FOR /F tokens=1-4 %%i in ('date/t') do set ttt=%%j
rem FOR /F tokens=1-4 delims=/ %%i in (%ttt%) do set curdate=%%k-%%j-%%i
FOR /F tokens=1-3 %%i in ('date/t') do set ttt=%%i
FOR /F tokens=1-4 delims=. %%i in (%ttt%) do set curdate=%%k-%%j-%%i
..Дальше дата стыкуется к имени файла и идет бэкап
..потом идет рестор
..если успешно - удаляем старые бэкапы:
:DEL_OLD
rem -- delete old backups --
for /F %%i in ('dir %back_dir%\*.gbk /b /o:-d') do (
if /i !Max_Files! GTR 0 (SET /A Max_Files -= 1) ELSE del %back_dir%\%%i
)
Re: gbak - новый параметр для задания имени файла ?
в лине вот так делаем curdate=`date +%F` echo `date` start backuping data gbak -B -G -user SYSDBA -pass sysdba localhost:ac $bkpath/ac_$curdate.fbk With best regards, Attid.
gbak - новый параметр для задания имени файла ?
Есть предложение: добавить в gbak параметр, котрый позволит к переданному в качестве параметра имени файла добавлять дату-время, например как это сделано в rar: -agMMDDHHMMSS. Например: gbak -b /mnt/sda5/db.MY_DATABASE.FDB /mnt/sdb5/backup/MY_DBBACKUP - NewParamMMDD_HHMMSS .. Смысл параметра - задание маски даты-времени, которая будет автоматом добавляться к имени файла. При этом можно сделать ограничения, что новый параметр работает только при резервировании, а в имени файла бэкапа можно пропускать расширение файла, gbak ему автоматом .FBK добавит. Практическую пользу вижу в профилактике идиётов-сисадминов заказчиков, складывающих бэкапы в одну папку, затирая при этом предыдущую копию без гарантии, что новый бэкап получиться. Сейчас пока борюсь с помощью добавления в батник новой строки, где полученный бэкап добавляется в rar-архив. З.Ы. я знаю, куда мне идти. :)
Re: gbak - ����� �������� ��� ������� ����� ����� ?
Hello, PEAKTOP!
You wrote on Thu, 4 Sep 2008 02:08:36 -0700 (PDT):
P Есть предложение: добавить в gbak параметр, котрый позволит к
P переданному в качестве параметра имени файла добавлять дату-время,
P например как это сделано в rar: -agMMDDHHMMSS.
Можно даже без рара, когда-то подглядел в конфе:
for /F tokens=1,2,3 delims=/. %%a in ('date /T') do set
date_name=%%c.%%b.%%a
set history_dir=history\%date_name%
--
-=Брюки важнее жены, потому что существует немало мест, куда можно пойти без
жены=-
With best regards, Nikolay Ponomarenko
Re: gbak - новый параметр для задания имени файла ?
Практическую пользу вижу в профилактике идиётов-сисадминов заказчиков, складывающих бэкапы в одну папку, затирая при этом предыдущую копию без гарантии, что новый бэкап получиться. Сейчас пока борюсь с помощью добавления в батник новой строки, где полученный бэкап добавляется в rar-архив. З.Ы. я знаю, куда мне идти. :) Полный П. Потом тебе захочется, что бы оно сразу - проверяло наличие места - рарило - копировало в несколько мест - рассылало уведомления о сбоях - было многопоточным Короче - фсад. Дайте идиёту админу заказчега нормальный инструмент в руки и не надо будет ни с чем бороться. Коваленко Дмитрий. PS. BAT-файлы - отстой. PSS. VBS - наше все.
Re: gbak - новый параметр для задания имени файла ?
Можно даже без рара, когда-то подглядел в конфе:
for /F tokens=1,2,3 delims=/. %%a in ('date /T') do set
date_name=%%c.%%b.%%a
set history_dir=history\%date_name%
With best regards, Nikolay Ponomarenko
Спасибо. Идея, однако.
Дайте идиёту админу заказчега нормальный инструмент в руки
и не надо будет ни с чем бороться.
Выгоднее за суппорт потом денег дополнительных взять. Но не всегда и
не везде успеваешь...
Да ну ладно, ф сад, так ф сад.
Re: gbak -se
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 осталось со старых времен, не перекладывали :) также вопрос в сторону - база лежит в каталоге установки. так и надо, или это недосмотр? есть ли разница? и вообще, все установлено в Program Files - не напрягает? нет
Re: gbak -se
Hello, Alex! Alexey Voytsehovich wrote: осталось со старых времен, не перекладывали :) ok. также вопрос в сторону - база лежит в каталоге установки. так и надо, или это недосмотр? есть ли разница? есть-ли разница между бардаком и порядком? и вообще, все установлено в Program Files - не напрягает? нет зря. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: gbak -se
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 также вопрос в сторону - база лежит в каталоге установки. так и надо, или это недосмотр? и вообще, все установлено в Program Files - не напрягает? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Зависший gbak
Наводил у себя на сервер порядок и сдуру удалил временную папку в которую gbak при резервном копировании складывал свои логи (через -y путь_к_файлу_лога). Ну то, что резервное копирование сломалось это одно, а вот gbak при таком действии вместо того, чтобы выйти с ошибкой, зависает и ждет пока его руками не закроешь, при этом удерживая соединение с сервером. Вопрос, правильное ли это поведение?
Re: Помогите с gbak
Dmitri Kuzmenko wrote: а что насчет -r o ? p.s. точняк надо было запретить такое вообще. Для о есть таки правильное применение: контрольный рестор бэкапа в файл с другим именем. Без о пришлось бы отресторенный в прошлый раз файл удялять каким-нибудь скриптом.
Re: Помогите с gbak
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:Cannot transliterate character between character sets не видит каталог intl ? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re[2]: Помогите с gbak
DK не видит каталог intl ? Каюсь, грешен был ... ;) Спасибо ... С уважением, Константин Григорьевич. ===
Re: Помогите с gbak
Hello, Konstantin! Константин wrote: DK не видит каталог intl ? Каюсь, грешен был ... ;) Спасибо ... а что насчет -r o ? p.s. точняк надо было запретить такое вообще. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Помогите с gbak
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: ERROR:arithmetic exception, numeric overflow, or string truncation gbak: ERROR:Cannot transliterate character between character sets gbak: ERROR:At trigger 'RDB$TRIGGER_33' gbak: ERROR:failed to create database l:\Client.fdb gbak:Exiting before completion due to errors PS: отесторить пробую с использованием embed dll С уважением, Константин Григорьевич. ===
Re: Помогите с gbak
Вдогонку: К PS: отесторить пробую с использованием embed dll при старте нормального Classic - всё ok :( но мне надо именно через embed ... С уважением, Константин Григорьевич. ===
gbak через сервисы. Засада.
Привет. Сижу значит, тихо балдею от скорости бакапа / рестора через сервисы. И на тебе. d:\Program Files\Firebird\bin\gbak.exe e:\database\data \Backup_Databases\t1\gbk\new_db_t1_123_20070402_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_restored.log gbak: ERROR:Internal error when using clumplet API: attempt to store 263 bytes in a clumplet with maximum size 255 bytes gbak:Exiting before completion due to errors Я так не играюсь! Коваленко Дмитрий.
Re: gbak через сервисы. Засада.
Kovalenko Dmitry ... Привет. Сижу значит, тихо балдею от скорости бакапа / рестора через сервисы. И на тебе. d:\Program Files\Firebird\bin\gbak.exe e:\database\data \Backup_Databases\t1\gbk\new_db_t1_123_20070402_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_restored.log gbak: ERROR:Internal error when using clumplet API: attempt to store 263 bytes in a clumplet with maximum size 255 bytes gbak:Exiting before completion due to errors Ну, ты и сам понял - пути у тебя длинные. Сходу не скажу что это - наша бага, или очередная родовая травма от так называемых архитекторов этого так называемого сервисного АПИ... Я так не играюсь! Бу га га (с) ;) -- Хорсун Влад
Re: gbak через сервисы. Засада.
Kovalenko Dmitry ... Ну, ты и сам понял - пути у тебя длинные. Сходу не скажу что это - наша бага, или очередная родовая травма от так называемых архитекторов этого так называемого сервисного АПИ... От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют киллометровые названия. То бишь бакап и ресторе через сервисы им заказан. Файлы - ладно, но пути-то зачем такие длинные ? -- Хорсун Влад
Re: gbak через сервисы. Засада.
Ну, ты и сам понял - пути у тебя длинные. Сходу не скажу что это - наша бага, или очередная родовая травма от так называемых архитекторов этого так называемого сервисного АПИ... От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют киллометровые названия. То бишь бакап и ресторе через сервисы им заказан. Файлы - ладно, но пути-то зачем такие длинные ? Для конспирации. Гы-гы. Коваленко Дмитрий.
Re: gbak через сервисы. Засада.
Hello, Kovalenko Dmitry! You wrote on Mon, 02 Apr 2007 05:00:58 -0700: KD От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют KD киллометровые названия. То бишь бакап и ресторе через сервисы им KD заказан. а если в формате 8.3 указать? Фёдоров Евгений. ЗАО Трест-М. Екатеринбург.
Re: gbak через сервисы. Засада.
KD От ведь уродство. У меня файлы и бакапы пакетов репликаций имеют KD киллометровые названия. То бишь бакап и ресторе через сервисы им KD заказан. а если в формате 8.3 указать? Накуй. Они в любом случае даже через TCP/IP считанные секунды бакапятся и ресторятся. Это я так - из зловредности ругаюсь. Коваленко Дмитрий.
Re: gbak через сервисы. Засада.
Hello, Dmitry! Kovalenko Dmitry wrote: Накуй. Они в любом случае даже через TCP/IP считанные секунды бакапятся и ресторятся. Это я так - из зловредности ругаюсь. ты будь последователен: 1. пишешь -SERVICE, тогда пиши -CREATE 2. пишешь -c, тогда пиши -se, -u -pas и так далее и я не понял, зачем localhost:service_mgr двойными кавычками обрамлен. Потому что с двоеточием? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: gbak через сервисы. Засада.
Dmitri Kuzmenko wrote: -c -g -совсем_опух? А есть ли в Липецке подходящая стенка? ;-) -- Regards. Ded.
Re: gbak через сервисы. Засада.
-c -g -совсем_опух? Ну почему совсем... В мои то годы? А есть ли в Липецке подходящая стенка? ;-) Есть тут одна, китайская стена. Но это не наш метод :)) Коваленко Дмитрий.
Re: gbak через сервисы. Засада.
Это я так - из зловредности ругаюсь. ты будь последователен: и я не понял, зачем localhost:service_mgr двойными кавычками обрамлен. Потому что с двоеточием? Не. Чиста для понтов :) Коваленко Дмитрий.
Информативность GBAK в FB 2.0
Попробовал перенести один старый проект под FB 2, и сразу наступил на граблю, на самом первом шаге. Забэкапил базу под FB 1.0.3, ресторю на FB 2.0. После рестора индексов (это я уже гадаю) идет рестор процедур, так? И вот на этом этапе выскакивает сообщение: gbak: ERROR:table ABONENTS is not referenced in plan. Естественно, в отресторенной базе процедур никаких нет, только таблицы с индексами. Т.е. я понимаю, что работа с планами в двойке изменилась, и там придется наверняка что-то править. Но нельзя хотя бы узнать, на какой процедуре все сломилось? Потому что их больше трехсот, ABONENTS используется примерно в полусотне. Просматривать их все глазками - утомительно, да и по закону подлости как раз ошибку-то сразу и не заметишь :-) Grue
Re: Информативность GBAK в FB 2.0
Valery Gruzdev пишет: Т.е. я понимаю, что работа с планами в двойке изменилась, и там придется наверняка что-то править. Но нельзя хотя бы узнать, на какой процедуре все сломилось? Потому что их больше трехсот, ABONENTS используется примерно в полусотне. Просматривать их все глазками - утомительно, да и по закону подлости как раз ошибку-то сразу и не заметишь :-) 1. Берем оглуплятор. 2. Комментируем все процедуре (можно и триггера). 3. Бэкап/рестор. 4. Пытаемся раскомментировать. 5. Долго думаем. -- С уважением, Андрей Еремин.
Re: Информативность GBAK в FB 2.0
On Mon, 19 Feb 2007 11:10:33 +0300, Valery Gruzdev [EMAIL PROTECTED] wrote: Но нельзя хотя бы узнать, на какой процедуре все сломилось? 1. Экспертом выгружаешь все метаданные в скрипт. 2. На 2-ке создаёшь базу из этого скрипта. Все ошибки тебе будут непосредственно носом потыканы. ЗЫ: Это именно ошибки, а не работа с планами поменялась. Сервер стал более строг к синтаксису. -- Сергей Смирнов.
Re: Информативность GBAK в FB 2.0
Dmitry Yemanov сообщил/сообщила в новостях следующее: Потому что их больше трехсот, ABONENTS используется примерно в полусотне. И во всех 50-ти процедурах планы прибиты гвоздиком? Не во всех, но в большинстве. Потому что большинство - отчеты, а в 1.0 без ручных планов серьезные объемы лопатить тоскливо получается. Но я не про то сейчас. Процедуры от планов почистить - не проблема, просто рутинная работа. Я про диагностику в GBAK :-) Grue
Re: Информативность GBAK в FB 2.0
Все ошибки тебе будут непосредственно носом потыканы. ЗЫ: Это именно ошибки, а не работа с планами поменялась. Сервер стал более строг к синтаксису. раньше можно было указать типа этого select ... from TABLE1, TABLE2, TABLE3 plan (TABLE2 nalural) на ошибку не похоже -- Булычев Алексей http://www.stella-npf.ru
Re: Информативность GBAK в FB 2.0
Boulitchev Aleksey сообщил/сообщила в новостях следующее: раньше можно было указать типа этого select ... from TABLE1, TABLE2, TABLE3 plan (TABLE2 nalural) Именно эта ситуация. Grue
Re: Информативность GBAK в FB 2.0
WildSery пишет: select ... from TABLE1, TABLE2, TABLE3 plan (TABLE2 nalural) на ошибку не похоже Действительно не похоже. Не знал, что и на такое ругается, у меня все соединения с алиасами, не попадался такой случай. Просто FB2 не переваривает _часть_ плана. Ему подавай или все, или ничего. -- С уважением, Андрей Еремин.
Re: Информативность GBAK в FB 2.0
On Mon, 19 Feb 2007 18:27:45 +0300, Andrei Yeryomin [EMAIL PROTECTED] wrote: Просто FB2 не переваривает _часть_ плана. Ему подавай или все, или ничего. Тьфу, действительно. Не обратил внимание, что только часть, обратил, что без алиаса... Мда, передохнуть надо, кофе попить... -- Сергей Смирнов.
Re: gbak -b vs gbak -b -g
ИМХО вообще убрать из GBAK возможность работы со сборкой мусора. -- Сергей Смирнов.
Re: gbak -b vs gbak -b -g
WildSery wrote: ИМХО вообще убрать из GBAK возможность работы со сборкой мусора. Какие вы все категоричные. Бекап - это чтение всего файла базы, свип - тоже. Нафига мне делать это дважды, если OIT у меня блокируется лишь раз в пятилетку? -- Дмитрий Еманов
Re: gbak -b vs gbak -b -g
On Tue, 19 Dec 2006 11:38:44 +0300, Dmitry Yemanov [EMAIL PROTECTED] wrote: Какие вы все категоричные. Бекап - это чтение всего файла базы, свип - тоже. Нафига мне делать это дважды, если OIT у меня блокируется лишь раз в пятилетку? Почему категоричные? Я ж сказал, что имха. -- Сергей Смирнов. ЗЫ: А у меня свип вообще не делается :)
gbak version WI-V1.5.0.4306 Firebird 1.5
Респект, Усем! Подскажите плиз как для сабжа указать где искать firebird.msg, сейчас он его ищет в папке выше уровнем. С наилучшими пожеланиями, Oleg Prosvetov.
Re: gbak version WI-V1.5.0.4306 Firebird 1.5
Oleg Prosvetov пишет: Подскажите плиз как для сабжа указать где искать firebird.msg, сейчас он его ищет в папке выше уровнем. instreg i -- С уважением, Андрей Еремин.
Re: gbak version WI-V1.5.0.4306 Firebird 1.5
Hi Andrei Yeryomin Oleg Prosvetov пишет: Подскажите плиз как для сабжа указать где искать firebird.msg, сейчас он его ищет в папке выше уровнем. instreg i так более мягко если стывтаь в bat файле set FIREBIRD=C:\Program Files\Firebird\FB2.1 WBR Evgeny Putilin.
Re: gbak version WI-V1.5.0.4306 Firebird 1.5
Evgeny Putilin wrote: так более мягко если стывтаь Евгений! Попрошу не выражаться в приличном обществе, даже так более мягко! Сюда ведь и дамы заглядывают. -- Regards. Ded.
gbak -b vs gbak -b -g
Hello, All! обновил статью www.ibase.ru/devinfo/garbage.htm#backup а то прямо опять блуждание в трех соснах начинается. :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Это лечится?: gbak: ERROR: message length error
FB 1.5.3 CS Linux Есть тестовая база, на которой новый функционал обкатываем и которую имеем и в хвост и в гриву ежесекундно и по любому поводу. Причем за ее здоровьем никто никогда не следит (что, видимо и привело к нижеследующему). Коннект к ней есть, все, вроде бы ОК. Но че-то с ней подозрительно не так стало на уровне субъективных ощущений и решил я ей заделать b/r. Ощущения меня не подвели и gbak -v -b при формировании бэкапа на очередной таблице выдал ... 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 Проверка gfix -v -full выдала в лог несколько orphan pages и несколько сообщений Relation has NN orphan backversions (KK in use) in TABLE имя_таблицы Таблицы фигурируют разные, но PB_SALE среди них нет. Ключик gfix -mend не помог. Выдает следующее: Summary of validation errors Number of record level errors : 5 Number of database page errors : 3 Куда копать дальше? Может проще создать новую базу и данные туда перезалить? -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Это лечится?: gbak: ERROR: message length error
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 Меняли формат записи. Скорее всего дропнули поле или укоротили его длину, т.к. судя по текущему формату длина записи 284 байта, а в данных 288. Можно попробовать вернуть как было. Тем же способом как меняли. Проверка gfix -v -full выдала в лог несколько orphan pages и несколько сообщений Relation has NN orphan backversions (KK in use) in TABLE имя_таблицы Это последствия абортированной сборки мусора, не страшно. Таблицы фигурируют разные, но PB_SALE среди них нет. Ибо это не связанные вещи. Ключик gfix -mend не помог. Выдает следующее: Summary of validation errors Number of record level errors : 5 Number of database page errors : 3 Куда копать дальше? Подробности в firebird.log -- Хорсун Влад
Re: Это лечится?: gbak: ERROR: message length error
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 Меняли формат записи. Скорее всего дропнули поле или укоротили его длину, т.к. судя по текущему формату длина записи 284 байта, а в данных 288. Можно попробовать вернуть как было. Тем же способом как меняли. К сожалению, не представляется выяснить, кто и чего менял. Не все изменения, увы, регистрируем в рабочей документации. А так никто не сознается. Быстрее данные, наверно, перезалью в новую базу. Хотелось бы механику возникновения этой ошибки понять. При наличии нескольких одновременно подключенных коллег теоретически могли менять метаданные НА ХОДУ. Обычно, следим за этим (все в одном помещении сидим) и просим всех ,кроме инициатора изменений, отключиться от базы. Но тут получается, что после изменения метаданных (ну, пусть поле урезали, например) кто-то ухитрился вставить в PB_SALE новую запись по старому формату. Так? -- Regards, ova at tkvc ru
Re: ��� �������?: gbak: ERROR: message length error
Hello, Vasily! Ovchinnikov Vasily wrote: Хотелось бы механику возникновения этой ошибки понять. При наличии нескольких одновременно подключенных коллег теоретически могли менять метаданные НА ХОДУ. Обычно, следим за этим (все в одном помещении сидим) и просим всех ,кроме инициатора изменений, отключиться от базы. Но тут получается, что после изменения метаданных (ну, пусть поле урезали, например) кто-то ухитрился вставить в PB_SALE новую запись по старому формату. Так? не так. например, было varchar(300), и запись с 288 символов в этой строке. alter table не позволяет урезать varchar в меньшую сторону. значит рубим через сист. таблицы (или IBExpert) - уменьшаем до varchar(284). В результате при чтении запись в старом формате преобразуется в новый формат, и возникает ошибка из-за невлезания. Запись найти можно через select * from table и fetchall дальше можно проверить через select id from table where и select id, problemfield from table where id = :id однако это прокатывает для блобов, т.к. они читаются отдельно. С varchar может не пройти. давно я уже проверкой таких вещей не занимался. если возможно, проще временно увеличить размер строки. -- Dmitri Kuzmenko, www.ibase.ru, (495) 953-13-34
Re: Это лечится?: gbak: ERROR: message length error
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_$receive failed gbak: Exiting before completion due to errors Меняли формат записи. Скорее всего дропнули поле или укоротили его длину, т.к. судя по текущему формату длина записи 284 байта, а в данных 288. Можно попробовать вернуть как было. Тем же способом как меняли. К сожалению, не представляется выяснить, кто и чего менял. Не все изменения, увы, регистрируем в рабочей документации. А так никто не сознается. Быстрее данные, наверно, перезалью в новую базу. Они всё равно не прочитаются целиком. Разве что вычислить RDB$DB_KEY проблемной записи и читать таблицу без неё Хотелось бы механику возникновения этой ошибки понять. При наличии нескольких одновременно подключенных коллег теоретически могли менять метаданные НА ХОДУ. Обычно, следим за этим (все в одном помещении сидим) и просим всех ,кроме инициатора изменений, отключиться от базы. Но тут получается, что после изменения метаданных (ну, пусть поле урезали, например) кто-то ухитрился вставить в PB_SALE новую запись по старому формату. Так? Вряд ли. Скорее это может произойти при самостоятельном ковырянии в системных таблицах. Например, прописали меньшую длину строковому полю. Или сменили тип поля с numeric(15) на numeric(5). А в реальных данных сидят значения длинее нового определения. -- Хорсун Влад
Re: ����� �������� �� ������� FB 1.0 �� FB 1.0 64IO - ��� gbak - restore ����?
÷ÏÌÛÅÂÎÏ
����� �������� �� ������� FB 1.0 �� FB 1.0 64IO - ��� gbak - restore ����?
úÄÁÓÔ×ÕÊÔÅ. íÏÖÎÏ ÚÁÍÅÎÉÔØ ÎÁ ÓÅÒ×ÅÒÅ FB 1.0 ÎÁ FB 1.0 64IO - ÂÅÚ gbak - restore ÂÁÚÙ? íÅÝÅÒÑËÏ× ÷ÁÄÉÍ
Re: ����� �������� �� ������� FB 1.0 �� FB 1.0 64IO - ��� gbak - restore ����?
Vadim Mescheryakov [EMAIL PROTECTED] wrote: íÏÖÎÏ ÚÁÍÅÎÉÔØ ÎÁ ÓÅÒ×ÅÒÅ FB 1.0 ÎÁ FB 1.0 64IO - ÂÅÚ gbak - restore ÂÁÚÙ? äÁ. -- äÍÉÔÒÉÊ åÍÁÎÏ×
Re: GBAK
Konstantin R. Beliaev [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] Dmitry Yemanov wrote: Второе, насколько я помню. Он ожидает команды в stdin. Блин... :-( А можно переделать? если вывод идет на диск, а не ленту Возьми и сам переделай. Исходники же есть! --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: GBAK
Dmitry Voroshin wrote: Возьми и сам переделай. Исходники же есть! Я не силен в С --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: GBAK
Konstantin R. Beliaev [EMAIL PROTECTED] wrote: А можно переделать? Не в 2.0. -- Дмитрий Еманов --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Странное поведение GBAK
Уже второй раз натыкаюсь на одно и то же: есть робот, который по расписанию стартует GBAK. Если по какой-то причине места на диске под бэкап не хватило - GBAK не завершается, а остается висеть, при этом робот кушает 100% проца. Кто тут виноват: робот или GBAK, честно говоря не знаю, но поведение странное. Да, файл протокола сохраняется на тот же диск что и бэкап, может в этом дело? --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Странное поведение GBAK
Konstantin R. Beliaev ... Уже второй раз натыкаюсь на одно и то же: есть робот, который по расписанию стартует GBAK. Если по какой-то причине места на диске под бэкап не хватило - GBAK не завершается, а остается висеть, при этом робот кушает 100% проца. gbak ждёт, пока место появится. А что твой робот делает gbak'у неведомо... -- Хорсун Влад --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
