? :) Довольно обидные Ваши слова
(с) Полиграф Полиграфыч
предположение оттуда, что при ошибках gbak обычно оставляет базу в
состоянии shutdown, а в этом состоянии подключиться может только SYSDBA.
Все пользователи ходят под своими логинами, которые включены в
соответствующие роли.
ну и
Привет!
Влад в приватной беседе посоветовал пожаловаться Трекеру По опыту
могу сказать, что вменяемое требование или описание бага в трекере
всегда либо внедряется, либо фиксится.
А Влад что на нелегальном положении ?
Я за него говорить правов не имею, но рискну предположить, что у него
выйдет.
С уважением,
Всеволод.
--
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.
сняли.
Собственно, по идее, когда происходят ошибки при restore,
то база должна оставаться в состоянии shutdown.
Я тоже так думаю, но gbak думает иначе :)
если у тебя все пользователи SYSDBA, то понятно, почему
никто ничего не заметил.
А откуда такое предположение интересно ? :) Довольно
Привет!
И мне показалось, что на
будущее неплохо иметь такую инфу в конце лога. Я же не требую, никого не
обвиняю, и так понял, что сам виноват. Нет так нет - приспособимся Но как
никогда хотелось бы все же услышать начальника транспортного цеха (с)
Влад в приватной беседе посоветовал
Hello, Vsevolod!
Vsevolod wrote:
Хотелось бы послушать начальника транспортного цеха (с)
надо было ставить FBDataGuard. Он бы предупредил про отсутствие
места.
Собственно, по идее, когда происходят ошибки при restore,
то база должна оставаться в состоянии shutdown.
если у тебя все
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
ðÒÉ×ÅÔ!
ÔÁËÏÍ ÓÌÕÞÁÅ ÎÁÄÏ ÐÒÏÓÔÏ ÐÏÓÌÁÔØ Õ×ÅÄÏÍÌÅÎÉÅ ÁÄÍÉÎÕ É ×Ó£. é gbak
ÞÅÓÔÎÏ ×ÏÚ×ÒÁÝÁÅÔ ÎÅÎÕÌÅ×ÏÊ ËÏÄ ÏÛÉÂËÉ ÔÏÍÕ ÐÒÏÃÅÓÓÕ, ËÏÔÏÒÙÊ ÅÇÏ
×ÙÚ×ÁÌ.
gbak ÞÅÓÔÎÏ ×ÏÚ×ÒÁÝÁÅÔ ÎÅÎÕÌÅ×ÏÊ ËÏÄ ÏÛÉÂËÉ ÅÓÌÉ ÅÍÕ îå ÕËÁÚÁÌÉ ÐÁÒÁÍÅÔÒ -v
ÔÏÇÄÁ ÄÅÊÓÔ×ÉÔÅÌØÎÏ %ERRORLEVEL%=1
É × ÌÏÇÅ:
...
gbak
.nabble.com/GBAK-restore-tp3677712p3683801.html
Sent from the firebird-russian mailing list archive at Nabble.com.
жаловаться на отсутствие средств
проверки в таких случаях.
Мерси за комплиман (с) :)
Но я, к сожалению, не являюсь специалистом в Linux.
За скрипт отдельное спасибо :)
С уважением,
Всеволод
--
View this message in context:
http://firebird.1100200.n4.nabble.com/GBAK-restore-tp3677712p3680057
Привет!
А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В
таком случае надо просто послать уведомление админу и всё. И gbak
честно возвращает ненулевой код ошибки тому процессу, который его
вызвал.
Удивлен.
Есть gbak, консоль и админ за консолью, запускающий _штатный_ gbak
Vsevolod пишет:
В связи с этим у меня вопрос - это так и должно было быть и всегда было и я
сам дурак или все же неплохо было бы выводить какие-то сообщения в конце
лога в случае каких-либо ошибок ?
Присоединяюсь. Хотя бы счетчик ошибок в конце лога.
Привет!
Присоединяюсь. Хотя бы счетчик ошибок в конце лога.
А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В
таком случае надо просто послать уведомление админу и всё. И gbak
честно возвращает ненулевой код ошибки тому процессу, который его
вызвал.
--
Best regards,
Sergey
Sergey Mereutsa пишет:
Присоединяюсь. Хотя бы счетчик ошибок в конце лога.
А зачем? Если есть _хотя бы одна_ ошибка - с базой что-то не то. В
таком случае надо просто послать уведомление админу и всё. И gbak
честно возвращает ненулевой код ошибки тому процессу, который его
вызвал.
Удивлен
внимательно посмотрел на лог
последнего рестора БД и нашел упоминание этого индекса:
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
/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
Добрый день!
Если из приложения бэкапить/разбэкапливать базу через сервисы, то на
клиента в случае ошибки/предупреждения передается только текст или еще
и код какой-нибудь?
Очень надо отличить фатальную ошибку от предупреждения, например, о
том, что уменьшен размер страницы.
Андрей
Если из приложения бэкапить/разбэкапливать базу через сервисы, то на
клиента в случае ошибки/предупреждения передается только текст или еще
и код какой-нибудь?
Лучше всего - полный лог. Даже если все вдруг прошло успешно. :)
Andrei пишет:
Если из приложения бэкапить/разбэкапливать базу через сервисы, то на
клиента в случае ошибки/предупреждения передается только текст или еще
и код какой-нибудь?
Текст передается через текстовый буфер, ошибки - через статус-вектор.
Дмитрий
Привет!
memtest прогоняли на сервере?
Нет, там память ECC, сервер сурьезный, ни каких дампов памяти не создается,
Я бы не молился на магическое буквосочетание ECC - всякое бывает и
не все ошибки ейный контроллер ловит. Судя по описанию проблем выше -
железо, 99.99%. Может BB на винте?
--
Здравствуйте.
Обновил у заказчика firebird 1.0 на firebird 2.1
(нужно было использовать временные таблицы и склеивать запросы в
процедурах)
На сервере стоит ASP Linux 9.0 Ядро 2.4.20-9asp (libs-2.3.2)
Получил такие проблемы:
1. Периодически стал умирать gbak -r на восстановлении базы (база
Привет!
Обновил у заказчика firebird 1.0 на firebird 2.1
Разрядность ОС и билд Птица выдашь только под пытками?
memtest прогоняли на сервере?
--
Best regards,
Sergeymailto:gebele...@gmail.com
ничего не отражается
Просто работал gbak и прервался прям на полуслове в логе. Segmentation fault
увидел всего раз - когда в консоли без ключа -y запустил.
С уважением, Мещеряков Вадим
директор ООО Комплексные Системы
454021 г. Челябинск ул. 40 лет Победы 31, 77
Тел: +7 (351) 2807917
Моб: +7 922
Vadim Mescheryakov ...
Здравствуйте.
Обновил у заказчика firebird 1.0 на firebird 2.1
(нужно было использовать временные таблицы и склеивать запросы в
процедурах)
На сервере стоит ASP Linux 9.0 Ядро 2.4.20-9asp (libs-2.3.2)
Получил такие проблемы:
1. Периодически стал умирать gbak -r на
разном месте.
Падает именно gbak или процесс сервера ?
Я копию восстанавливаю без localhost, и если я правильно понимаю gbak сам и
создает новую базу
Gbak исчезает из памяти
Что в firebird.log ?
Есть несколько ошибок:
mainserver.book.ru Mon Sep 28 14:31:19 2009
INET/inet_error
При попытке перекомпилировать процедуру в 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 сам и
создает новую базу
Gbak
Vadim Mescheryakov ...
Если использую в select функцию из своей UDF, так же коннект рвется, без
записи в протокол
Откатился на официальную версию, выложенную на сайте firebirdsql
UDF заработали
А до этого какая версия была ?
Но что с gbak ещё не понятно
Если рестор одного и тогоже
смог использовать - разрыв соединений.
Откатился на официальную сборку 2.1.3.18185
Сегодня ночью Gbak не прошел, так же умер внезапно.
До этого стоял FB 1.0 64 I/O, все началось после обновления сервера и
установки моей udf
С уважением, Мещеряков Вадим
директор ООО Комплексные Системы
454021 г
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
т.е. база
Здравствуйте, уважаемые.
Накануне пятницы задам глупый вопрос. Просьба сильно не пинать
Вводная:
имеется сервер на базе Intel D805, Centos 5.3,
FirebirdSS-2.1.3.18156-0.i686 брал с http://www.dqteam.com/fb2/ сборка
от Sergey Mereutsa.
Обратил внимание, что при работе GBAK
Привет!
Обратил внимание, что при работе GBAK утилита top показывает 200%
использования CPU. До сего дня просто не интересовался.
Вопрос:
Как такое возможно? Напомню: FB SuperServer
Пусть меня Птицеводы поправят, но сие возможно только если:
1) top глючит и плющит нипадеццки
On Thu, 16 Jul 2009 12:40:45 +0500, Sergey Mereutsa
gebele...@gmail.com wrote:
Пусть меня Птицеводы поправят, но сие возможно только если:
1) top глючит и плющит нипадеццки и он врёт
2) gbak использует 2 нити, обе хавают по ядру на 100%
Ну слава Богу, с головой значит у меня все в
Гоголь Дмитрий wrote:
2) gbak использует 2 нити, обе хавают по ядру на 100%
оно так бывает?
Нет.
--
Дмитрий Еманов
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% на процесс,
если
Гоголь Дмитрий wrote:
А через ServicesAPI?
Там на сервере не может быть никакого процесса gbak. Разве что тот,
который ты вызвал с -se (если ты это делаешь локально). Но он процессор
грузить почти не будет.
Сейчас проверял: если запускать gbak с ключом -se, то 200% на процесс,
Два
óÅÊÞÁÓ ÐÒÏ×ÅÒÑÌ: ÅÓÌÉ ÚÁÐÕÓËÁÔØ gbak Ó ËÌÀÞÏÍ -se, ÔÏ 200% ÎÁ ÐÒÏÃÅÓÓ,
ÅÓÌÉ ÂÅÚ ÔÁËÏ×ÏÇÏ - 100%.
ÓÔÅÓÎÑÀÓØ ÓÐÒÏÓÉÔØ: ÐÏÌÎÕÀ ÓÔÒÏËÕ ÚÁÐÕÓËÁ Ó ËÌÀÞÅÍ -se ÍÏÖÎÏ Õ×ÉÄÅÔØ?
ÒÁÚ×Å ÞÔÏ ÐÁÒÏÌØ ÍÏÖÎÏ ÐÒÏÐÕÓÔÉÔØ :-)
On Thu, 16 Jul 2009 17:22:28 +0500, Dmitry Yemanov
dim...@users.sf.net wrote:
Гоголь Дмитрий wrote:
А через ServicesAPI?
Там на сервере не может быть никакого процесса gbak. Разве что тот,
который ты вызвал с -se (если ты это делаешь локально). Но он процессор
грузить почти не
А gbak и не вижу, есть процесс fbserver и он грузит до 200%.
Чтобы не быть голословным: http://alf2.nm.ru/fb_top.gif
--
Гоголь Дмитрий
ÄÁ ÔÁÍ ×ÓÅ ÔÏ ÖÅ ÓÁÍÏÅ ÔÏÌØËÏ ÄÏÂÁ×ÌÑÅÔÓÑ -se hostname:service_mgr
ÏË, ÐÅÒÅÆÒÁÚÉÒÕÀ (ÞÔÏ ÈÏÔÅÌ Õ×ÉÄÅÔØ):
ÐÕÔØ Ë âä - ÔÏÞÎÏ ÕËÁÚÁÎ ÌÏËÁÌØÎÙÊ, ÂÅÚ hostname:?
У gbak есть полезная возможность - бэкап с удаленного сервера с
доставкой результата на локальную машину.
Очень нужна данная функциональность. Отсутствует в Firebird-Net-
Provider - сохранение бэкапа только в файловой системе сервера. В
родном API клиента - не нашел, похоже тоже отсутствует
Hello, Eugeny!
Vinogradniy Eugeny wrote:
У gbak есть полезная возможность - бэкап с удаленного сервера с
доставкой результата на локальную машину.
мда. Эта полезная возможность является изначально штатной для
gbak. И вообще gbak это обычная программа, которая читает все
данные и записывает в
Hello, Eugeny!
Vinogradniy Eugeny wrote:
Соответственно имитация gbak через API - это ахинея.
И вправду уверен? Про имитацию не было и слова.
я с Вами на брудершафт не пил. И да - уверен.
Имитация, шмитация. Если не понимаете, как работает
gbak, то чего API ковырять?
Нужен например для
Спасибо за ответ.
On 26 июн, 11:58, Dmitri Kuzmenko k...@ibase.ru wrote:
Hello, Eugeny!
Соответственно имитация gbak через API - это ахинея.
И вправду уверен? Про имитацию не было и слова.
Просто вариант с запуском из управляемого кода gbak (а значит придется
утилиты отставлять на
машине бэкап нужен для более надежного
хранения.
дотнет считать кроссплатформенным можно лишь условно. Таки обычный
gbak гораздо более кроссплатформенен :)
И дистрибутив тащить не нужно - скопировать gbak, клиентская либу,
firebird.msg и рунтайм от студии.
Таки админские задачи нужно решать
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
в лине вот так делаем
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 параметр, котрый позволит к
переданному в качестве параметра имени файла добавлять дату-время,
например как это сделано в rar: -agMMDDHHMMSS.
Например:
gbak -b /mnt/sda5/db.MY_DATABASE.FDB /mnt/sdb5/backup/MY_DBBACKUP -
NewParamMMDD_HHMMSS ..
Смысл
Hello, PEAKTOP!
You wrote on Thu, 4 Sep 2008 02:08:36 -0700 (PDT):
P Есть предложение: добавить в gbak параметр, котрый позволит к
P переданному в качестве параметра имени файла добавлять дату-время,
P например как это сделано в rar: -agMMDDHHMMSS.
Можно даже без рара, когда-то подглядел
Практическую пользу вижу в профилактике идиётов-сисадминов заказчиков,
складывающих бэкапы в одну папку, затирая при этом предыдущую копию
без гарантии, что новый бэкап получиться. Сейчас пока борюсь с помощью
добавления в батник новой строки, где полученный бэкап добавляется в
rar-архив.
З.Ы.
Можно даже без рара, когда-то подглядел в конфе:
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
Спасибо. Идея, однако.
Дайте идиёту админу заказчега нормальный инструмент в руки
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 -
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
также вопрос в сторону - база лежит в каталоге установки.
так и надо, или это недосмотр?
и
Наводил у себя на сервер порядок и сдуру удалил временную папку в
которую gbak при резервном копировании складывал свои логи (через -y
путь_к_файлу_лога). Ну то, что резервное копирование сломалось это
одно, а вот gbak при таком действии вместо того, чтобы выйти с
ошибкой, зависает и ждет пока
Dmitri Kuzmenko wrote:
а что насчет -r o ?
p.s. точняк надо было запретить такое вообще.
Для о есть таки правильное применение: контрольный рестор бэкапа в
файл с другим именем. Без о пришлось бы отресторенный в прошлый раз
файл удялять каким-нибудь скриптом.
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
DK не видит каталог intl ?
Каюсь, грешен был ... ;)
Спасибо ...
С уважением,
Константин Григорьевич.
===
Hello, Konstantin!
Константин wrote:
DK не видит каталог intl ?
Каюсь, грешен был ... ;)
Спасибо ...
а что насчет -r o ?
p.s. точняк надо было запретить такое вообще.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
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
Вдогонку:
К PS: отесторить пробую с использованием embed dll
при старте нормального Classic - всё ok :(
но мне надо именно через embed ...
С уважением,
Константин Григорьевич.
===
\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
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
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:
Накуй. Они в любом случае даже через TCP/IP считанные секунды
бакапятся и ресторятся.
Это я так - из зловредности ругаюсь.
ты будь последователен:
1. пишешь -SERVICE, тогда пиши -CREATE
2. пишешь -c, тогда пиши -se, -u -pas и так далее
и я не понял,
Dmitri Kuzmenko wrote:
-c -g -совсем_опух?
А есть ли в Липецке подходящая стенка? ;-)
--
Regards. Ded.
-c -g -совсем_опух?
Ну почему совсем... В мои то годы?
А есть ли в Липецке подходящая стенка? ;-)
Есть тут одна, китайская стена. Но это не наш метод :))
Коваленко Дмитрий.
Это я так - из зловредности ругаюсь.
ты будь последователен:
и я не понял, зачем localhost:service_mgr двойными кавычками
обрамлен. Потому что с двоеточием?
Не. Чиста для понтов :)
Коваленко Дмитрий.
Попробовал перенести один старый проект под FB 2, и сразу наступил на
граблю, на самом первом шаге.
Забэкапил базу под FB 1.0.3, ресторю на FB 2.0. После рестора индексов (это
я уже гадаю) идет рестор процедур, так? И вот на этом этапе выскакивает
сообщение: gbak: ERROR:table ABONENTS
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)
на ошибку не похоже
--
Булычев Алексей
Boulitchev Aleksey сообщил/сообщила в новостях следующее:
раньше можно было указать типа этого
select ... from TABLE1, TABLE2, TABLE3
plan (TABLE2 nalural)
Именно эта ситуация.
Grue
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 возможность работы со сборкой мусора.
--
Сергей Смирнов.
WildSery wrote:
ИМХО вообще убрать из GBAK возможность работы со сборкой мусора.
Какие вы все категоричные. Бекап - это чтение всего файла базы, свип -
тоже. Нафига мне делать это дважды, если OIT у меня блокируется лишь раз
в пятилетку?
--
Дмитрий Еманов
On Tue, 19 Dec 2006 11:38:44 +0300, Dmitry Yemanov [EMAIL PROTECTED] wrote:
Какие вы все категоричные. Бекап - это чтение всего файла базы, свип -
тоже. Нафига мне делать это дважды, если OIT у меня блокируется лишь раз
в пятилетку?
Почему категоричные? Я ж сказал, что имха.
--
Сергей
Респект, Усем!
Подскажите плиз как для сабжа указать где искать firebird.msg, сейчас он его
ищет в папке
выше уровнем.
С наилучшими пожеланиями, Oleg Prosvetov.
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.
Hello, All!
обновил статью
www.ibase.ru/devinfo/garbage.htm#backup
а то прямо опять блуждание в трех соснах начинается. :-)
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
подозрительно не так стало на уровне субъективных ощущений и решил я ей
заделать b/r. Ощущения меня не подвели и gbak -v -b при формировании
бэкапа на очередной таблице выдал
...
gbak: writing data for table PB_SALE
gbak: ERROR: message length error (encountered 288, expected 284)
gbak: 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
Меняли формат записи. Скорее всего дропнули поле или укоротили его
длину, т.к
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
Меняли формат записи. Скорее всего дропнули поле или
Hello, Vasily!
Ovchinnikov Vasily wrote:
Хотелось бы механику возникновения этой ошибки понять. При наличии
нескольких одновременно подключенных коллег теоретически могли менять
метаданные НА ХОДУ. Обычно, следим за этим (все в одном помещении сидим)
и просим всех ,кроме инициатора
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
Меняли формат записи
÷ÏÌÛÅÂÎÏ
úÄÁÓÔ×ÕÊÔÅ.
íÏÖÎÏ ÚÁÍÅÎÉÔØ ÎÁ ÓÅÒ×ÅÒÅ FB 1.0 ÎÁ FB 1.0 64IO - ÂÅÚ gbak - restore ÂÁÚÙ?
íÅÝÅÒÑËÏ× ÷ÁÄÉÍ
Vadim Mescheryakov [EMAIL PROTECTED] wrote:
íÏÖÎÏ ÚÁÍÅÎÉÔØ ÎÁ ÓÅÒ×ÅÒÅ FB 1.0 ÎÁ FB 1.0 64IO - ÂÅÚ gbak - restore ÂÁÚÙ?
äÁ.
--
äÍÉÔÒÉÊ åÍÁÎÏ×
Konstantin R. Beliaev [EMAIL PROTECTED]
сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED]
Dmitry Yemanov wrote:
Второе, насколько я помню. Он ожидает команды в stdin.
Блин... :-(
А можно переделать? если вывод идет на диск, а не ленту
Возьми и сам переделай. Исходники же есть!
Dmitry Voroshin wrote:
Возьми и сам переделай. Исходники же есть!
Я не силен в С
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Konstantin R. Beliaev [EMAIL PROTECTED] wrote:
А можно переделать?
Не в 2.0.
--
Дмитрий Еманов
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
Уже второй раз натыкаюсь на одно и то же:
есть робот, который по расписанию стартует GBAK. Если по какой-то
причине места на диске под бэкап не хватило - GBAK не завершается, а
остается висеть, при этом робот кушает 100% проца.
Кто тут виноват: робот или GBAK, честно говоря не знаю, но поведение
Konstantin R. Beliaev ...
Уже второй раз натыкаюсь на одно и то же:
есть робот, который по расписанию стартует GBAK. Если по какой-то
причине места на диске под бэкап не хватило - GBAK не завершается, а
остается висеть, при этом робот кушает 100% проца.
gbak ждёт, пока место появится.
А
Результаты 1 - 100 из 111 matches
Mail list logo
