Re: Запрос в FB2.5 выполняется дольше чем в FB2.0
> > Все, hvlad помог разобраться в чем дело. OBJECT - текстовое поле, а сравнивается с числом. Видимо такие неявные преобразования в 2.0 были реализованы иначе чем в 2.5
Re: Trigger
Так должно быть по логике, вставка в таблицу мастер только после успешного выполнения триггеров, пока они не завершены, данные старые. On Mar 11, 6:05 pm, "Dmitry Lendel" wrote: > . > Master Details > > > new.masterfield=9 > update Details set Somefiled = Value where ... > > > Select masterfield from Master where ... > > , . . . > . ? > 2.1.4 > >
Re: Упала база, упала на пол...
07.03.2012 9:11, Dumitru Condrea пишет: Что делать? Куда "копать"? Активизировать индексы в правильном порядке. -- Дмитрий Еманов
Re: Упала база, упала на пол...
Alex Cherednichenko пишет: Hello, Dumitru Condrea! You wrote on Tue, 6 Mar 2012 21:11:32 -0800 (PST) при активации одного из индекса выдаёт ошибку: Unsuccessful execution caused by system error that precludes successful execution of subsequent statements. internal gds software consistency check (partner index description not found (175)) Что делать? Куда "копать"? http://www.ibase.ru/devinfo/errors.htm Сразу первое же из того, что там написано. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Упала база, упала на пол...
Hello, Dumitru Condrea! You wrote on Tue, 6 Mar 2012 21:11:32 -0800 (PST) > при активации одного из индекса выдаёт ошибку: > > Unsuccessful execution caused by system error that precludes > successful execution of subsequent statements. > internal gds software consistency check (partner index description not > found (175)) > > Что делать? Куда "копать"? Форин кей? И нет ему "партнёра"...
Re[2]: Различия версий снапшотов
Привет! Да, правильно Еманов говорит: "Никто README не читает". Он ещё при этом материся, наверняка. http://www.dqteam.com/fb2/README.TXT - сто лет там лежит. Что мне в about написать? Что это мои сборки и используете на свой страх и риск? По-моему это и так очевидно. Они собираются из публичных сорцов примерно раз в неделю или по просьбе тех, кому надо срочно. Ничем от обычных снапшотов не отличаются - разве что делаются реже. Я сам эти билды использую переодически - всплывающие проблемы рапортуются птицеводам. P.S. Специально для ворчунов - напишу, что мои сборки ничем от обычных не отличаются. -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Различия версий снапшотов
Hello, Khorsun Vlad! You wrote on Mon, 5 Mar 2012 13:55:59 +0200 > Не вижу ни единой проблемы или недоразумения в этом. Никто ни на кого не наезжает. Мои претензии к эбауту и отсутствию внятно прописанной связи с FB. (историческая ретроспектива не в счет)
Re: Различия версий снапшотов
"Alex Cherednichenko" ... Кто эти люди? Из http://www.dqteam.com/about.html нихрена не понял. Как они связаны с Firebird Development ? Конкретно DQTeam - делали новый сайт firebirdsql.org. Когда у нас не было возможности (по техническим причинам) собирать ежедневные снапшоты, Сергей Мереуца предложил свою помощь и линуксовые снапшоты "от dqteam" до сих пор живы. Не вижу ни единой проблемы или недоразумения в этом. -- Хорсун Влад
Re: Различия версий снапшотов
"reshetnyakvkt" ... Здравствуйте. Решил обновить версию сервера. Так вот, чем принципиально отличается снэпшоты выложеные здесь "http://www.dqteam.com/fb2/"; и здесь "http://web.firebirdsql.org/download/snapshot_builds/linux/fb2.5/"; ? А кто вообще надоумил ставить снапшот на боевой сервер ? Или есть реальная необходимость, например наступил на баг, исправленный в снапшоте ? Догадываюсь что они собраны разными людьми, и в разное время. Т.е. содержат разные изменения, и по сути представляют разные версии. Changelog читай. Что же мне ставить в производство, чему отдать предпочтение? Официальную релизную сборку. -- Хорсун Влад
Re: Различия версий снапшотов
>> Кто эти люди? Sergey Mereutsa serj собака dqteam -- Banzai, Dmitriy Kovalenko
Re: Различия версий снапшотов
> Кто эти люди? Republic of Moldova, Chisinau. -- Banzai, Dmitriy Kovalenko
Re: Различия версий снапшотов
Hello, reshetnyakvkt! You wrote on Mon, 5 Mar 2012 01:18:09 -0800 (PST) > Здравствуйте. Решил обновить версию сервера. Так вот, чем принципиально > отличается снэпшоты выложеные здесь "http://www.dqteam.com/fb2/"; и здесь > "http://web.firebirdsql.org/download/snapshot_builds/linux/fb2.5/"; ? > Догадываюсь что они собраны разными людьми, и в разное время. Т.е. содержат > разные изменения, и по сути представляют разные версии. Что же мне ставить в > производство, чему отдать предпочтение? Или тут уж "как карта ляжет"? Или > вопрос откуда чаще качают? Кто эти люди? Из http://www.dqteam.com/about.html нихрена не понял. Как они связаны с Firebird Development ?
Re: печалька для тестеров execute block+STATEMENT+ON EXTERNAL
(время мин:сек) Задача подключится на локальной машине к соседней базе и
скопировать записи таблицы.
В надежде ускорить вставку был в недоумении.
Думая что execute block+STATEMENT к другой базе даст прирост при вставке
переписал код.
Но каково было удивление, что прирост был не велик
/Коннект локальный\сетевой ? На таблице-приёмнике есть триггеры\индексы ?
/С чем вообще сравниваешь ? И какого прироста ты ожидал ? :-D
1.коннект только локальный т.к. нужно максимум производительности
2.На момент вставки триггеров нет. В большинстве случаев я применяю тупой
INSERT.
Но не в нижеприведенном. Т.к. там UPDATE OR INSERT то
- либо индексы есть (и это уже не ускоряет вставку) и чем их больше, тем хуже,
- либо их нет - что есть смерть для UPDATE OR INSERT.
3.Сравниваю старый вариант построчно вставляемый мной и вариант полностью
выполняемый блоком
Во втором варианте ты исключил как минимум передачу параметров на сервер-
приёмник.
4.В моем варианте, я думал, что сервер тратит много времени на чтение строки из одной базы и вставку в другую базу. Оказалось что
эти манипуляции настольно малы, что на это можно практически не обращать внимания.
Судя по загрузке процессора он не работает. Я думаю проблема в обмене данными с
дисками.
Не надо думать. Освой perfmon - и уже потом думай.
Вообще очень хотелось, чтобы кто нить поглядел место при вставке у сервера. Но с другой стороны не я один об этом подумываю, уже
наверное смотрели. Просто когда 3 Гб база переливается в новую базу 4 часа становится тоскливо. Для любителей тестов скажу SSD на
том же компе 1 час.
Патология какая-то, явно что-то не так. Ресторится она у тебя тоже 4 часа
на этом же железе ?
Последнее время прогресс стоит на месте. Все железо от 2006 года работает практически также как и новое от 2011 года узкое место
жесткий диск :).
теряем возможность получить ошибку и продолжить вставку, если надо продолжить.
/С чего бы это ?
По порядку я получаю такую конструкцию
'execute block returns (xCount integer) as'#13#10+
'%sParams%'#13#10+
'begin'#13#10+
' FOR EXECUTE STATEMENT (''select %sGetF% from (%sSql%)'')'#13#10+
'ON EXTERNAL ''%sBase%'''#13#10+
'AS USER CURRENT_USER PASSWORD ''masterkey'' -- just for example'#13#10+
'WITH AUTONOMOUS TRANSACTION -- note autonomous transaction'#13#10+
'--for update'#13#10+
'INTO %sInsP%'#13#10+
' do begin'#13#10+
' UPDATE OR INSERT INTO %sTable% (%sInsF%)'#13#10+
' VALUES (%sInsP%)'#13#10+
' MATCHING (%sPK%);'#13#10+
'suspend;'#13#10+
' end'#13#10+
'end;';
Вот нафига тут эта каша ? Сложно было реальный запрос показать ? Тебе
помощь нужна или кому ?
подключаемся ко второй базе и вставляем в текущую записи. Предположим при вставке произошла ошибка, но надо продолжить. Наши
действия без вывода вменяемой ошибке таковы WHEN ANY DO. С одной стороны достаточно но что за ошибка была? Ты скажешь убери WHEN
ANY DO, но тогда нельзя будет продолжить.
Я скажу - прочитай GDSCODE и выдай его SUSPEND'ом наружу для анализа,
если надо.
--
Хорсун Влад
PS xCount не вычисляется, накой он нужен
Re: печалька для тестеров execute block+STATEMENT+ON EXTERNAL
"Khorsun Vlad" сообщил(а) в новостях
следующее:jislai$obn$1...@dough.gmane.org...
"Boltik Evgeny" ...
Добрый день.
(время мин:сек) Задача подключится на локальной машине к соседней базе и
скопировать записи таблицы.
В надежде ускорить вставку был в недоумении.
Думая что execute block+STATEMENT к другой базе даст прирост при вставке
переписал код.
Но каково было удивление, что прирост был не велик
/Коннект локальный\сетевой ? На таблице-приёмнике есть триггеры\индексы
?
/С чем вообще сравниваешь ? И какого прироста ты ожидал ? :-D
1.коннект только локальный т.к. нужно максимум производительности
2.На момент вставки триггеров нет. В большинстве случаев я применяю тупой
INSERT.
3.Сравниваю старый вариант построчно вставляемый мной и вариант полностью
выполняемый блоком
4.В моем варианте, я думал, что сервер тратит много времени на чтение строки
из одной базы и вставку в другую базу. Оказалось что эти манипуляции
настольно малы, что на это можно практически не обращать внимания.
Судя по загрузке процессора он не работает. Я думаю проблема в обмене
данными с дисками. Вообще очень хотелось, чтобы кто нить поглядел место при
вставке у сервера. Но с другой стороны не я один об этом подумываю, уже
наверное смотрели. Просто когда 3 Гб база переливается в новую базу 4 часа
становится тоскливо. Для любителей тестов скажу SSD на том же компе 1 час.
Последнее время прогресс стоит на месте. Все железо от 2006 года работает
практически также как и новое от 2011 года узкое место жесткий диск :).
теряем возможность получить ошибку и продолжить вставку, если надо
продолжить.
/С чего бы это ?
По порядку я получаю такую конструкцию
'execute block returns (xCount integer) as'#13#10+
'%sParams%'#13#10+
'begin'#13#10+
' FOR EXECUTE STATEMENT (''select %sGetF% from (%sSql%)'')'#13#10+
'ON EXTERNAL ''%sBase%'''#13#10+
'AS USER CURRENT_USER PASSWORD ''masterkey'' -- just for example'#13#10+
'WITH AUTONOMOUS TRANSACTION -- note autonomous transaction'#13#10+
'--for update'#13#10+
'INTO %sInsP%'#13#10+
' do begin'#13#10+
' UPDATE OR INSERT INTO %sTable% (%sInsF%)'#13#10+
' VALUES (%sInsP%)'#13#10+
' MATCHING (%sPK%);'#13#10+
'suspend;'#13#10+
' end'#13#10+
'end;';
подключаемся ко второй базе и вставляем в текущую записи. Предположим при
вставке произошла ошибка, но надо продолжить. Наши действия без вывода
вменяемой ошибке таковы WHEN ANY DO. С одной стороны достаточно но что за
ошибка была? Ты скажешь убери WHEN ANY DO, но тогда нельзя будет продолжить.
Ошибки переноса данных можно разделить на 2 вида.
1=Критические - перенос дальше не возможет. потеря нужных данных
2=Не критические - т.к. были допущены ошибки разработчика или не повлекут
потерю важных данных(несвоевременное обновление базы данных или клиент не
обслуживался но все же решил перейти на новую версию с возможной потерей
неважных данных)
Желания.
1.Вообще хотелось бы чтобы в WHEN ANY DO можно было получить текст ошибки. И
уже самому решить этот текст вернуть или свой.
2.И могу сделать тест создания базы данных который делался 1 минуту, а
теперь 2 мин 30 сек. Где то в сервере что то поменялось однако ;)
Re: печалька для тестеров execute block+STATEMENT+ON EXTERNAL
"Boltik Evgeny" ... Добрый день. (время мин:сек) Задача подключится на локальной машине к соседней базе и скопировать записи таблицы. В надежде ускорить вставку был в недоумении. Думая что execute block+STATEMENT к другой базе даст прирост при вставке переписал код. Но каково было удивление, что прирост был не велик Коннект локальный\сетевой ? На таблице-приёмнике есть триггеры\индексы ? С чем вообще сравниваешь ? И какого прироста ты ожидал ? :-D теряем возможность получить ошибку и продолжить вставку, если надо продолжить. С чего бы это ? -- Хорсун Влад
Re: Firebird 3.0.0.29767
"Anton Zibrov" ... Добрый день, уважаемые! Решил установить и помучать сабж... получил: Your user name and password are not defined. Ask your database administrator to set up a Firebird login. Install incomplete, please read chapter "Initializing security database" in Quick Start Guide. Quick Start Guide для 3.0 не нашел. fb_devel читать надо :) Что делать? Добавить SYSDBA в security3.fdb вручную gsec -add sysdba -pw %new_password% -- Хорсун Влад
Re: Проблемы при использовании временных таблиц с индексами
подготовить базу с примером пока не могу - зело занят, как освобожусь непременно сделаю
Re: Проблемы при использовании временных таблиц с индексами
Доброе время суток. Сервер FB 2.5.1 64 бит есть база, в которой процедуры используют временные таблицы ON COMMIT DELETE ROWS с индексом по 3-м полям: integer, smallint, date Проблема заключается в следующем: Если после коннекта вызвать процедуру, использующую временную таблицу, то первый раз все проходит нормально, однако если после выполнения подтвердить или откатить транзакцию и в этом же коннекте запустить процедуру еще раз, то вылазит ошибка: cannot add index, index root page is full. После пререподключения ситуация возобновляется - первый вызов нормально, второй с ошибкой не смотря на то что они в разных транзакциях
Re: Проблемы при использовании временных таблиц с индексами
"plasmorf" ... Доброе время суток. Сервер FB 2.5.1 64 бит есть база, в которой процедуры используют временные таблицы ON COMMIT DELETE ROWS с индексом по 3-м полям: integer, smallint, date Проблема заключается в следующем: Если после коннекта вызвать процедуру, использующую временную таблицу, то первый раз все проходит нормально, однако если после выполнения подтвердить или откатить транзакцию и в этом же коннекте запустить процедуру еще раз, то вылазит ошибка: cannot add index, index root page is full. После пререподключения ситуация возобновляется - первый вызов нормально, второй с ошибкой не смотря на то что они в разных транзакциях Воспроизводимый пример - где он ? -- Хорсун Влад
Re: Чудеса при замене SQL-сервера FB 1.5 32bit --> FB 2.5 64bit
Vlad Khorsun пишет: "Ovchinnikov Vasily" wrote ... 32-бит и 64-бит FB может работать с одной и той же БД, начиная с ODS 11.1 Младшие ODS не совместимы. Т.е. БД в ODS < 11.1 будет читаться только 32-битными версиями FB. Спасибо, Влад Главное - не собственно сами грабли, а знание их месторасположения :) -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Чудеса при замене SQL-сервера FB 1.5 32bit --> FB 2.5 64bit
"Ovchinnikov Vasily" wrote ... 32-бит и 64-бит FB может работать с одной и той же БД, начиная с ODS 11.1 Младшие ODS не совместимы. Т.е. БД в ODS < 11.1 будет читаться только 32-битными версиями FB. -- Хорсун Влад
Re: Проблема с уникальным индексом на 2.5.1
03.01.2012 17:06, A K пишет: Что-то мне это напоминает :-) Спасибо за тестовую базу, будем разбираться. добрый день. не смотрели еще этот вопрос? Смотрел, но решения пока нет. -- Дмитрий Еманов
Re: Проблема с уникальным индексом на 2.5.1
On 29.11.2011 15:16, Dmitry Yemanov wrote: Что-то мне это напоминает :-) Спасибо за тестовую базу, будем разбираться. добрый день. не смотрели еще этот вопрос?
Re: Что-то непонятное с left join
23.12.2011 15:50, Dmitry Yemanov пишет: >> Проверяю на существование дырок: >> SQL> select s.ID, s.ORD_NUM, s2.ID, s2.ORD_NUM >> CON> from SYMPTOMS s left outer join SYMPTOMS s2 >> CON> on s.ORD_NUM + 1 = s2.ORD_NUM >> CON> where s.PARENT_ID = 450774 and s2.PARENT_ID = 450774 >> CON> /*and s2.ID is null*/; > Внеси "s2.PARENT_ID = 450774" в условие джойна. Иначе оно тебе > отбрасывает все записи, не найденные в левом потоке (где s2.PARENT_ID IS > NULL). Спасибо. От я затупил. :) -- Александр Замараев
Re: Что-то непонятное с left join
23.12.2011 12:50, Dmitry Yemanov пишет: отбрасывает все записи, не найденные в левом потоке В правом (внутреннем) потоке, конечно же :-) -- Дмитрий Еманов
Re: Что-то непонятное с left join
23.12.2011 11:31, Tonal пишет: > > Проверяю на существование дырок: > SQL> select s.ID, s.ORD_NUM, s2.ID, s2.ORD_NUM > CON> from SYMPTOMS s left outer join SYMPTOMS s2 > CON> on s.ORD_NUM + 1 = s2.ORD_NUM > CON> where s.PARENT_ID = 450774 and s2.PARENT_ID = 450774 > CON> /*and s2.ID is null*/; Внеси "s2.PARENT_ID = 450774" в условие джойна. Иначе оно тебе отбрасывает все записи, не найденные в левом потоке (где s2.PARENT_ID IS NULL). -- Дмитрий Еманов
Re: Путь к bin
Kirill Temnenkov wrote:
@echo off
set reg_path=HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird
Server\Instances
set reg_param=DefaultInstance
for /f "tokens=1,2,*" %%a in ('reg query "%reg_path%" /v
"%reg_param%"') do if "%%a"=="%reg_param%" set reg_value=%%c
echo "%reg_value%"
pause
Спасибо. То что надо.
Re: Путь к bin
Alexey Popov пишет: Ovchinnikov Vasily wrote: Кури утилиту REG C:\>reg QUERY "HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances" /v DefaultInstance Это хорошая идея, но над парсингом этого дела оператором for придётся попотеть... Вот тебе выше Кирилл и написал как распарсить. Я поленился - он нет. ;) За что ему огромное человеческое спасибо :) -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Путь к bin
Ответ на первый вопрос:
@echo off
set reg_path=HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird
Server\Instances
set reg_param=DefaultInstance
for /f "tokens=1,2,*" %%a in ('reg query "%reg_path%" /v
"%reg_param%"') do if "%%a"=="%reg_param%" set reg_value=%%c
echo "%reg_value%"
pause
16 Декабрь 2011 г. 10:10:49, Alexey Popov писал:
> Может кто уже решал подобную задачу? Нужно сделать bat файл, который
> бы интенсивно использовал утилиты fb из каталога bin. Причём без
> участия узера. Проблема в том, что пути нет в PATH и ничего не
> работает. Если способ извлечь в батник пусть из реестра?
>
> Ещё вопросик. Есть ли способ вызывать isql не посредством указания
> input-файла, а через перенаправление ввода типа
> echo exit; | isql base.db
>
Re: Путь к bin
Alexey Popov пишет: без файла, то на примере команды set echo set; >3 | isql <3 В принципе можно и так и так, вопрос в том что можно ли в isql обойтиcь без переноса строк? А деже если и с переносами echo set; >3 echo help; >>3 isql <3 -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Путь к bin
Ovchinnikov Vasily wrote: Кури утилиту REG C:\>reg QUERY "HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances" /v DefaultInstance HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances DefaultInstanceREG_SZC:\Program Files\Firebird\Firebird_1_5\ Результат ее работы, как видно, надо будет парсить. Можно попытаться даже средствами FOR Это хорошая идея, но над парсингом этого дела оператором for придётся попотеть... Есть, конечно. echo exit; > ddd.sql isql -i ddd.sql del ddd.sql Чё-то я поспешил... Если именно как ты хочешь без файла, то на примере команды set echo set; >3 | isql <3 В принципе можно и так и так, вопрос в том что можно ли в isql обойтиcь без переноса строк?
Re: Путь к bin
Yurij пишет: А зачем так извращаться, оно же и так работает : echo help; | isql Дык... Людям надо доверять :) Я даже без задней мысли, что он прежде не проверил "в лоб" :) Зато у него теперь несколько вариантов :) -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Путь к bin
Ovchinnikov Vasily пишет: В 2.x вроде (навскидку точно не помню), как ключик -q есть для isql, чтоб вывод спрятать. Ну, это так, на всякий случай напоминаю. Не, "гражданин соврамши!". -q только сообщение USE CONNECT ... прячет при старте. Ну да ладно, вопрос-то не про это. -- Regards, Ovchinnikov Vasily ova at tkvc ru P.S. Во наговорился сам с собою-то... Пойду чаю выпью :)
Re: Путь к bin
А зачем так извращаться, оно же и так работает : echo help; | isql
Re: Путь к bin
Ovchinnikov Vasily пишет: Ovchinnikov Vasily пишет: Есть, конечно. echo exit; > ddd.sql isql -i ddd.sql del ddd.sql Чё-то я поспешил... Если именно как ты хочешь без файла, то на примере команды set echo set; >3 | isql <3 Ну или уж совсем полный пример: Команда: echo show database; >3|isql localhost:mydatabase -user ABC -password 123 <3 Результат: Database: localhost:mydatabase, User: ABC SQL> Database: localhost:mydatabase Owner: SYSDBA PAGE_SIZE 8192 Number of DB pages allocated = 191 Sweep interval = 0 Forced Writes are ON Transaction - oldest = 89442 Transaction - oldest active = 93312 Transaction - oldest snapshot = 93312 Transaction - Next = 93388 Default Character set: NONE SQL> C:\Program Files\Firebird\Firebird_1_5\bin>_ В 2.x вроде (навскидку точно не помню), как ключик -q есть для isql, чтоб вывод спрятать. Ну, это так, на всякий случай напоминаю. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Путь к bin
Ovchinnikov Vasily пишет: Есть, конечно. echo exit; > ddd.sql isql -i ddd.sql del ddd.sql Чё-то я поспешил... Если именно как ты хочешь без файла, то на примере команды set echo set; >3 | isql <3 -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Путь к bin
Alexey Popov пишет: Может кто уже решал подобную задачу? Нужно сделать bat файл, который бы интенсивно использовал утилиты fb из каталога bin. Причём без участия узера. Проблема в том, что пути нет в PATH и ничего не работает. Если способ извлечь в батник пусть из реестра? Кури утилиту REG C:\>reg QUERY "HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances" /v DefaultInstance HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances DefaultInstanceREG_SZC:\Program Files\Firebird\Firebird_1_5\ Результат ее работы, как видно, надо будет парсить. Можно попытаться даже средствами FOR Ещё вопросик. Есть ли способ вызывать isql не посредством указания input-файла, а через перенаправление ввода типа echo exit; | isql base.db Есть, конечно. echo exit; > ddd.sql isql -i ddd.sql del ddd.sql -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Ubuntu и QIBASE - драйвер Firebird для Qt
> Описаная трабла характерна именно для Ubuntu и > производных, т. к. если > верить changelog-у в исходном Debian-овском пакете libqt4-sql-ibase > собирается. А в Ubuntu его отдельным местом отключают... > > Причём ежели скачать исходники Qt и включить его > обратно, то всё > собирается «на ура». Ответ неверный, интербейсовского драйвера нет в убунте потому что qt4 идет в репозитории main, а firebird идет в репозитории contrib или как его там, а полиси убунтовские запрещают зависимости main от contrib
Re: Глюки в рекурсивном запросе
13.12.2011 8:12, Tonal пишет: Похоже. Дык проверь. Скачай последний снапшот 3.0, создай новую базу и выполни свой тестовый пример. -- Дмитрий Еманов
Re: Глюки в рекурсивном запросе
13.12.2011 8:30, Tonal пишет: Вроде бы не было ограничений про неименованные вычисляемые поля в подзапросах. Или я опять что-то пропустил? В derived table все столбцы должны быть именованы, так всегда было. -- Дмитрий Еманов
Re: Глюки в рекурсивном запросе
Ещё странность на похожем запросе: Добавим в корневой подзапрос неименованную вычисляемую колонку with recursive SYM as ( select sr1.ID, sr1.PARENT_ID, count(*) -- Добавили count(*) from SYMPTOMS sr1 group by 1, 2 ), TREE as ( select 1 as LEV, sp.ID, sp.PARENT_ID from SYM sp where sp.ID = 450797 union all select t.LEV + 1, st.ID, st.PARENT_ID from SYM st inner join TREE t on st.PARENT_ID = t.ID ) select t.LEV, t.ID from TREE t Получаем ошибку: Message: isc_dsql_prepare failed SQL Message : -104 Invalid token Engine Code: 335544569 Engine Message : Dynamic SQL Error SQL error code = -104 Invalid command no column name specified for column number 3 in derived table SP Ежели колонку проименовать запрос выполнится. Вроде бы не было ограничений про неименованные вычисляемые поля в подзапросах. Или я опять что-то пропустил? -- Александр Замараев
Re: Глюки в рекурсивном запросе
12.12.2011 21:01, Khorsun Vlad пишет:
> "Tonal" ...
>> Наткнулся на такую глючу.
>Хорошо бы, чтобы DLL мог выполниться. На новой пустой БД.
--DDL:
CREATE DOMAIN D_ID AS integer NOT NULL;
CREATE DOMAIN D_ID_OR_NULL AS integer;
CREATE TABLE SYMPTOMS (
ID D_ID,
PARENT_ID D_ID_OR_NULL,
CONSTRAINT PK_SYMPTOMS PRIMARY KEY (ID),
CONSTRAINT FK_SYMP2SYM_ID FOREIGN KEY (PARENT_ID) REFERENCES SYMPTOMS (ID)
);
--Datas
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450797', null);
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450798', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450799', '450798');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450800', '450798');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450801', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450802', '450801');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450803', '450801');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645590', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645591', '645590');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645592', '645590');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645593', '645592');
> PS http://tracker.firebirdsql.org/browse/CORE-3683 - не оно ?
Похоже. Только в моём случае создание уникальности по обоим полям не влияет.
Создавал ткую:
alter table SYMPTOMS add constraint UNQ_ID_PARENT unique (ID, PARENT_ID)
--
Александр Замараев
Re: Глюки в рекурсивном запросе
"Tonal" ... Наткнулся на такую глючу. В запросе ниже Хорошо бы, чтобы DLL мог выполниться. На новой пустой БД. -- Хорсун Влад PS http://tracker.firebirdsql.org/browse/CORE-3683 - не оно ?
Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION
"reshetnyakvkt" ... Сама ось не висит, выполняет команды и т.д. А к серверу firebird не присоединится, все соединения уходят в никуда, т.е. висят без ответа на ошибку коннекта или другое. Бектрейс висячего процесса и копия лок-таблицы могут пролить свет на эту тайну -- Хорсун Влад
Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION
02.12.2011 15:05, reshetnyakvkt пишет: Во всех случаях сервер установлен из rpm. Старый удалялся ч/з rpm -e, с перезагрузкой оси. Сама ось не висит, выполняет команды и т.д. А к серверу firebird не присоединится, все соединения уходят в никуда, т.е. висят без ответа на ошибку коннекта или другое. А уже установленные на этот момент соединения продолжают работать? Или тоже виснут наглухо? Или прибиваются скриптом перед его подвисом? Такой скипт после установки новой версии FB выполнялся дважды оба раза с печальным итогом. А если убрать FOR-цикл с удаленным выполнением запросов, т.е. гасить только коннекты к своей базе? Если будет работать, то проблема не в MON$, а в коннектах к другим базам, см. ниже. Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32. Причем тут клиент? Версия клиентской библиотеки на это никак не влияет. Суммарный объем файлов баз к которым применяется скрипт около 28Гб, могу предположить что дело может быть в попытке поднять их в память которой только 8Гб, и сервер уходит в глубокий своппинг. Такое возможно, ведь EXECUTE STATEMENT не сразу закрывает свой коннект. Какой размер страничного кеша установлен для этих баз? Хотя раньше такого не наблюдалось. Может настройки какие-то менялись? Не знаю что ещё добавить. Если скрипт работает у других Точно такого же (с коннектами к другим базам) наверное ни у кого нет :-) А вот простой DELETE FROM MON$ATTACHMENTS есс-но работает. Дмитрий
Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION
Во всех случаях сервер установлен из rpm. Старый удалялся ч/з rpm -e, с перезагрузкой оси. Сама ось не висит, выполняет команды и т.д. А к серверу firebird не присоединится, все соединения уходят в никуда, т.е. висят без ответа на ошибку коннекта или другое. Такой скипт после установки новой версии FB выполнялся дважды оба раза с печальным итогом. Права на /tmp/firebird (rwx-rwx-__ [firebird/firebird]), вроде нормально. Висят в нем 8 файлов суммарно 8мб. Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32. Суммарный объем файлов баз к которым применяется скрипт около 28Гб, могу предположить что дело может быть в попытке поднять их в память которой только 8Гб, и сервер уходит в глубокий своппинг. Хотя раньше такого не наблюдалось. Не знаю что ещё добавить. Если скрипт работает у других, то подожду следущего раза и если ситуация повторится, буду отслеживать кто виноват пробуя с разными базами. Может отчленять по кускам. -- View this message in context: http://firebird.1100200.n4.nabble.com/delete-from-MON-ATTACHMENTS-where-MON-ATTACHMENTS-MON-ATTACHMENT-ID-CURRENT-CONNECTION-tp4145993p4146299.html Sent from the firebird-russian mailing list archive at Nabble.com.
Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION
02.12.2011 13:50, reshetnyakvkt пишет: До этого стоял *FirebirdSS-2.5.0.25946-ReleaseCandidate3.amd64* Как был установлен? Из RPM или из tar.gz или собран и установлен из сорцов? После установки *FirebirdSS-2.5.1.26351-0.amd64* Как был установлен? Из RPM или из tar.gz или собран и установлен из сорцов? такая конструкция валит сервер наглухо. Приложения выполняющее этот запрос висит не реагируя Так валит сервер или вешает коннект, выполняющий запрос? Это совсем разные вещи. Как при этом себя чувствуют остальные коннекты? Это уже второй раз так случается и прослеживается закономерность. Т.е. это выполнялось всего дважды и оба раза висло или же выполнялось многократно, но висло всего дважды? Какие права даны на каталог /tmp/firebird? Вопрос к разработчикам что происходит. Если конструкция с "MON$ATTACHMENTS.MON$ATTACHMENT_ID" больше не работает, то подскажите как теперь без последствий отключать непослушные коннекты? У всех остальных она работает. Дмитрий
Re: new / delete в UDF
>Проблема в том, что по умолчанию линкер gcc экспортирует все ф-ции. > Соответственно, UDF цепляет delete движка (embedded коннект), или isql. > Движок в 2.5 вроде как уже поправили на этот счёт, но утилиты по прежнему > всё выставляют наружу. Но тогда ведь и new бы цеплялась? Или в чем-то условия для этих двух операторов отличаются? Моя громоздкая UDF заработала. Еще раз большое спасибо за решение. С уважением, Владимир.
Re: Проблема с уникальным индексом на 2.5.1
29.11.2011 16:54, Yurij пишет: Забавно: При создании индекса оно валится вот на этих двух строках: BANKKEY BANKCODE BANKMFO SWIFT BANKBRANCH 148517044 749 153001749 150695489 749 153001749 Т.е. создание индексов не различает пустую строку и NULL в BANKBRANCH, а group by - различает. Что-то мне это напоминает :-) Спасибо за тестовую базу, будем разбираться. -- Дмитрий Еманов
Re: Проблема с уникальным индексом на 2.5.1
Забавно: При создании индекса оно валится вот на этих двух строках: BANKKEY BANKCODE BANKMFO SWIFT BANKBRANCH 148517044 749 153001749 150695489 749 153001749 Т.е. создание индексов не различает пустую строку и NULL в BANKBRANCH, а group by - различает.
Re: Проблема с уникальным индексом на 2.5.1
Ок, пакуй БД и выкладывай куда-нить для ознакомления. Если там ценные данные или их просто много, можно дропнуть не нужные таблицы и выложить бекап. ftp://gs.selfip.biz user: temp passw: temp там архив с бэкапом. при разбэкапе понадобится УДФ-ка http://gsbelarus.com/gs/modules.php?name=Downloads&d_op=getit&lid=63 она же, только 64 бита: http://gsbelarus.com/gs/modules.php?name=Downloads&d_op=getit&lid=95 индекс, с которым возникает проблема: GD_X_BANK_BANKCODE скажите, когда снимите с ФТП.
Re: new / delete в UDF
"Vladimir" ... Похоже, линкер/загрузчик где-то путается с разрешением символов и вместо rtl-ных new/delete подставляет какие-то левые. Тут немного непонятно. Если в моей udf используются new/delete от firebird, то почему они приводят к ошибке? Может быть, дело в другом? Например, такая ситуация. Firebird работает, что-то размещает своим new. Потом загружается моя библиотека, и firebird с этого момента переключается на загруженные с ней new, delete из libstdc++ При этом использует чужой delete для чего-то, размещенного ранее своим new. Именно это и было моим первым предположением. Только оно касалось экспортированных new\delete из UDF. -- Хорсун Влад
Re: new / delete в UDF
"Vladimir" ... Сегодня получился положительный результат. Большое спасибо за советы. Вчера долго не удавалось настроить сетевой коннект. Применял разные рекомендации, которые находил. Вероятно, сделал что-то лишнее. В firebird.log были записи INET/inet_error: send errno = 32 Версия точно Firebird CS 2.1.3.18185-0.ds1-6built1 Сегодня вернулся к исходной точке и применил минимум настроек. UDF отработала. При этом управление в перегруженные функции new, delete не передается. Буду проверять на более сложных примерах. На локальном коннекте ситуация не изменилась - Segmentation fault на операторе delete. Проверить версию 2.5 быстро точно не получится. В менеджере пакетов ubuntu ее нет, а другой путь установки сложнее, опыт в Linux у меня небольшой. Если надо - попробую проверить. Желательно Можно ли сейчас предположить, есть ли шансы добиться, чтобы new, delete заработали на локальном коннекте? Или не стоит и пытаться? В чем причина? http://tracker.firebirdsql.org/browse/CORE-3677 Проблема в том, что по умолчанию линкер gcc экспортирует все ф-ции. Соответственно, UDF цепляет delete движка (embedded коннект), или isql. Движок в 2.5 вроде как уже поправили на этот счёт, но утилиты по прежнему всё выставляют наружу. Точнее может Алекс сказать, он создал вышеупомянутый тикет по мотивам этого обсуждения по моей просьбе. -- Хорсун Влад
Re: new / delete в UDF
>> Вариант 3. Пытаюсь перегрузить операторы new и delete. > Попробуй в этом варианте сделать операторы инлайновыми или разместить их > в неименованном пространстве имён. > Т. е. скрыть от линкера. Пробовал объявить свои перегруженные операторы как inline - все равно в udf управление на них не передается. > Похоже, линкер/загрузчик где-то путается с разрешением символов и вместо > rtl-ных new/delete подставляет какие-то левые. Тут немного непонятно. Если в моей udf используются new/delete от firebird, то почему они приводят к ошибке? Может быть, дело в другом? Например, такая ситуация. Firebird работает, что-то размещает своим new. Потом загружается моя библиотека, и firebird с этого момента переключается на загруженные с ней new, delete из libstdc++ При этом использует чужой delete для чего-то, размещенного ранее своим new. С уважением, Владимир.
Re: new / delete в UDF
Сегодня получился положительный результат. Большое спасибо за советы. Вчера долго не удавалось настроить сетевой коннект. Применял разные рекомендации, которые находил. Вероятно, сделал что-то лишнее. В firebird.log были записи INET/inet_error: send errno = 32 Версия точно Firebird CS 2.1.3.18185-0.ds1-6built1 Сегодня вернулся к исходной точке и применил минимум настроек. UDF отработала. При этом управление в перегруженные функции new, delete не передается. Буду проверять на более сложных примерах. На локальном коннекте ситуация не изменилась - Segmentation fault на операторе delete. Проверить версию 2.5 быстро точно не получится. В менеджере пакетов ubuntu ее нет, а другой путь установки сложнее, опыт в Linux у меня небольшой. Если надо - попробую проверить. Можно ли сейчас предположить, есть ли шансы добиться, чтобы new, delete заработали на локальном коннекте? Или не стоит и пытаться? В чем причина? С уважением, Владимир.
Re: new / delete в UDF
"Vladimir" ... С сетевым коннектом ошибка проявляется по-другому, и isql при этом не падает. SQL> SELECT TestInsert(333) from RDB$Database; TESTINSERT Statement failed, SQLCODE = -902 Error reading data from the connection. SQL> quit; Это действительно 2.1.3 ? Не 2.0.х ? В firebird.log на сервере есть что-то ? Есть возможность проверить 2.5 ? -- Хорсун Влад
Re: new / delete в UDF
28.11.2011 18:27, Vladimir пишет: > Вариант 3. Пытаюсь перегрузить операторы new и delete. Попробуй в этом варианте сделать операторы инлайновыми или разместить их в неименованном пространстве имён. Т. е. скрыть от линкера. Похоже, линкер/загрузчик где-то путается с разрешением символов и вместо rtl-ных new/delete подставляет какие-то левые. Попробуй запустить под strace и/или gdb. -- Александр Замараев
Re: new / delete в UDF
С сетевым коннектом ошибка проявляется по-другому, и isql при этом не падает. SQL> SELECT TestInsert(333) from RDB$Database; TESTINSERT Statement failed, SQLCODE = -902 Error reading data from the connection. SQL> quit; С локальным коннектом isql падал. SQL> SELECT TestInsert(333) from RDB$Database; Segmentation fault root@ap:/home/v/TestCallAll# С уважением, Владимир.
Re: new / delete в UDF
"Vladimir" ... Да, все в isql с локальным коннектом. Имеет смысл попробовать сетевой коннект? Да -- Хорсун Влад
Re: new / delete в UDF
Да, все в isql с локальным коннектом. Имеет смысл попробовать сетевой коннект? С уважением, Владимир.
Re: new / delete в UDF
"Vladimir" ... А каким образом проверяется работоспособность UDF ? Запросы выполняются в isql с локальным коннектом ? Сетевой коннект не пробовал ? -- Хорсун Влад
Re: new / delete в UDF
Firebird CS 2.1.3.18185
g++ версии 4.4.3-4ubuntu5
Отладчиком пользоваться не пытался.
Проверил на простом примере. Получается следующее.
Вариант 1. Без new и delete.
#include
long TESTINSERT(long *theArg)
{
long* aTestItem = (long*) malloc(sizeof(long));
free(aTestItem);
long aResult = 777;
return(aResult);
}
Такая UDF успешно отрабатывает.
Вариант 2. Ошибка с new и delete.
long TESTINSERT(long *theArg)
{
long* aTestItem = new long;
delete aTestItem;
long aResult = 778;
return(aResult);
}
Ошибка Segmentation fault.
Вариант 3. Пытаюсь перегрузить операторы new и delete.
#include
#include
void* operator new(size_t sz)
{
void* m = malloc(sz);
return m;
}
void operator delete(void* m)
{
free(m);
}
long TESTINSERT(long *theArg)
{
long* aTestItem = new long;
delete aTestItem;
long aResult = 779;
return(aResult);
}
Ошибка Segmentation fault.
Если функция TESTINSERT вызывается не как UDF, а из обычной программы
- все три варианта работают.
Если подключить тестовый вывод, то в третьем варианте видно следующее.
При вызове из обычной программы отрабатывают перегруженные операторы.
Все происходит, как предполагалось.
При вызове UDF перегруженные операторы игнорируются. Выполнение туда
не передается.
Оператор new (не перегруженный) проходит без ошибки.
На операторе delete UDF падает.
С уважением, Владимир.
Re: Проблема с уникальным индексом на 2.5.1
"A K" ... Ок, пакуй БД и выкладывай куда-нить для ознакомления. Если там ценные данные или их просто много, можно дропнуть не нужные таблицы и выложить бекап. -- Влад
Re: Проблема с уникальным индексом на 2.5.1
On 28.11.2011 10:54, Khorsun Vlad wrote: Сначала на вопросы ответь :) 1. оба поля VARCHAR(20) CHARACTER SET WIN1251 2. первое поле NOT NULL 3. второе поле сейчас не содержит НУЛЛов. Они заменены на пустые строки. 4. первое поле содержит НЕ УНИКАЛЬНЫЕ значения 5. неуникальных коомбинаций по первому и второму полям нет. Проверено SELECT f1, f2, count(*) FROM t GROUP BY 1, 2 HAVING count(*) > 1 возвращает пустой набор. 6. при попытке создать уникальный индекс по этим двум полям -- ошибка. 7. база восстановлена из архива gbak-om с соответствующим ключем для отключения индексов 8. сервер 2.5.2 из снэпшотов 9. лично не проверял, но клиенты говорят, что у них восстанавливается. у них 2.5.0.
Re: new / delete в UDF
"Vladimir" ... Спасибо за совет. Очень было похоже, что это может помочь, но никакие опции редактора не изменили ситуацию. Какого-такого редактора ? Пробовал --no-export-dynamic --exclude-libs, никакого эффекта. Какая версия Firebird ? Есть возможность пройтись отладчиком по коду UDF и посмотреть - что за delete он вызывает? -- Хорсун Влад
Re: Проблема с уникальным индексом на 2.5.1
"A K" ... В базе есть уникальный индекс по двум строковым полям. Тип данных какой ? И чарсет. База перестала восстанавливаться из архива. А когда восстанавливалась ? На 2.5.0 восстанавливается ? Восстанавливаем без индексов. Пытаемся воссоздать этот индекс -- ругается на наличие повторяющихся строк. Но, 1) запрос с группировкой показывает что повторяющихся строк НЕТ. 2) более того, первое поле в индексе содержит только уникальные значения. Откуда это известно ? На первое поле уникальный индекс даёт создать ? 3) была идея, что наличие NULL в некоторых строках во второй колонке индекса приводит к такому эффекту, но замена NULL на пустые строки все равно не дает создать индекс. Что за проблема? Если что, базу могу на какой ФТП залить. Сначала на вопросы ответь :) -- Хорсун Влад
Re: Проблема с уникальным индексом на 2.5.1
проблема присутствует и в снэпшоте 2.5.2 от 24.11.2011
Re: Проблема с уникальным индексом на 2.5.1
проблема похожа на: http://tracker.firebirdsql.org/browse/CORE-3660
Re: Проблема с уникальным индексом на 2.5.1
Для поиска повторяющихся строк нужно отключить использование индекса в запросе. у меня итак база восстановлена без единого индекса.
RE: Проблема с уникальным индексом на 2.5.1
>1) запрос с группировкой показывает что повторяющихся строк НЕТ. >2) более того, первое поле в индексе содержит только уникальные значения. >3) была идея, что наличие NULL в некоторых строках во второй колонке >индекса приводит к такому эффекту, но замена NULL на пустые строки >все равно не дает создать индекс. Для поиска повторяющихся строк нужно отключить использование индекса в запросе. Например select id, count(*) from restaurant_accounts group by id having count(id) > 1 plan (restaurant_accounts natural) С уважением, Мещеряков Вадим директор ООО "Комплексные Системы" 454021 г. Челябинск ул. 40 лет Победы 31, 77 Тел: +7 (351) 2807917 Моб: +7 922 6395170 Web: www.del-fin.ru ICQ: 343-554-572 SKYPE: vadimmescheryakov
Re: new / delete в UDF
Спасибо за совет. Очень было похоже, что это может помочь, но никакие опции редактора не изменили ситуацию. Пробовал --no-export-dynamic --exclude-libs, никакого эффекта. С уважением, Владимир.
Re: new / delete в UDF
On Nov 18, 11:08 am, "Khorsun Vlad" wrote: > "Vladimir" ... > > > ! > > > Linux UDF, gcc, > > : > > > long* aTestItem = new long; > > delete aTestItem; > > > Segmentation fault delete. > > , > .so ӣ . > > --
Re: new / delete в UDF
"Vladimir" ... Здравствуйте! При попытке в Linux использовать UDF, собранную в gcc, столкнулся со следующим: long* aTestItem = new long; delete aTestItem; вызывает ошибку Segmentation fault на операторе delete. Насколько я помню, нужно явно сказать линкеру не экспортировать из .so всё подряд. -- Хорсун Влад
Re: Тозмоза простейших запросов
Пока возникло серьёзное подозрение на слубжу восстановление системы. Она включена и в файле filelist.xml было расширение gdb. Вероятно эта слубжа раз в сутки блокировала файл БД для создания точки восстановления...
Re: Тозмоза простейших запросов
Vlad Khorsun wrote: У винды есть perfmon, который ты конечно же настроил и изучаешь логи в моменты торможения... Пока не могу, т.к. управляю этим сервером по эл. почте. Нужно составить текстовую инструкцию админу широкого профиля по настройке этого перфмона...
Re: Тозмоза простейших запросов
"Alexey Popov" ... Может какие службы у винды есть типа дефрагметатора/индексатора? Кстати, расширение файла gdb. Может оно влияет? У винды есть perfmon, который ты конечно же настроил и изучаешь логи в моменты торможения... -- Хорсун Влад
Re: Тозмоза простейших запросов
Может какие службы у винды есть типа дефрагметатора/индексатора? Кстати, расширение файла gdb. Может оно влияет?
Re: Тозмоза простейших запросов
Arioch wrote: какое-нибудь обновление антивируса/файрвола, которое на 20 секунд блокирует TCP/IP ? Период чуть больше 24 часов. Инета там нет.
Re: Не выйти из isql позле вызова UDF в Linux
В письме от Thu, 20 Oct 2011 19:30:32 +0400, Vsevolod сообщал: Если кому интересно - новости нашего городка. В варианте, описаном выше, добился нормальной работы тестовой библиотеки, когда поменял клиентскую библиотеку fbclient.dll на версию от FB 2.1. Куда крестьянину податься теперь ... Возможно, описать это на http://tracker.firebirdsql.org/browse/CORE-3651 По крайней мере отслеживать :-) -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Тозмоза простейших запросов
В письме от Fri, 11 Nov 2011 15:30:35 +0400, Alexey Popov сообщал: Я писал, что лог поймал торможение запроса, который вообще ничего не читает: execute block as begin post_event 'my_event'; end какое-нибудь обновление антивируса/файрвола, которое на 20 секунд блокирует TCP/IP ? -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Тозмоза простейших запросов
Khorsun Vlad wrote: Памяти 2Гб, диск один SATA2. Но и база то мелкая, зато реалтайм. Если ты хочешь кешировать БД целиком, то по памяти ты на грани. Добавить её не помешает. Если реалтайм, то почему авто-свип не запрещён ? Далее. Кэшировать всю особо не нужно, т.к. интенсивно юзается инфа только за последнии 1-2 месяца. Да и половина базы в редко юзаемых блобах. Со свипом проблем никогда не было. Реалтайм от относительный. Т.е. обычно insert проходит мгновенно, но судя по логу примерно раз в сутки тормозит на 20-40 секунд. Что это - х.з. Может винда в дикий своп ухоит. По идее свип вообще должен редко запускаться, т.к. откаты и обрывы соединений крайне редки в нормальный работе. Свип может много писать на диск (если мусора много). Мусора много нет. В основном insert-select. Т.к. диск один, то запросы на чтение будут сильно проседать во время такой записи. С другой стороны, если добиться полного кеширования БД в файловом кеше, то запросов на чтение просто не станет. Я писал, что лог поймал торможение запроса, который вообще ничего не читает: execute block as begin post_event 'my_event'; end Так что я бы попробвал добить память до 3GB и тянуть всю БД в кеш при старте системы. Например, с помощью того же gstat -r, читающего всё, кроме разве что блобов. База там крутится круглосуточно без перерыва, и с ней работают несколько служб. Рестарт крайне редкий. b/r не делался уже полтора года.
Re: Тозмоза простейших запросов
"Alexey Popov" ... OIT застревает или от роллбека, или от лимбо. Это азы. Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е. есть долгоиграющая тр-ция с номером 67773711. С ней и разбирайся. Сама по себе долгоиграющая может появится штатно, т.к. юзеры днём там пасутся. Ну и что ? Основной вопрос в том, почему sweep полностью блокирует работу сервера даже на запросе execute block as begin post_event 'my_event'; end Дисковая никакая ? gstat -r давно смотрел ? Сколько памяти в наличии ? Памяти 2Гб, диск один SATA2. Но и база то мелкая, зато реалтайм. Если ты хочешь кешировать БД целиком, то по памяти ты на грани. Добавить её не помешает. Если реалтайм, то почему авто-свип не запрещён ? Далее. Свип может много писать на диск (если мусора много). Т.к. диск один, то запросы на чтение будут сильно проседать во время такой записи. С другой стороны, если добиться полного кеширования БД в файловом кеше, то запросов на чтение просто не станет. Так что я бы попробвал добить память до 3GB и тянуть всю БД в кеш при старте системы. Например, с помощью того же gstat -r, читающего всё, кроме разве что блобов. -- Хорсун Влад
Re: Тозмоза простейших запросов
Khorsun Vlad wrote: Виноват оказался sweep. Откуда это видно ? Сорри, тут я ступил, посмотрел на next OIT застревает или от роллбека, или от лимбо. Это азы. Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е. есть долгоиграющая тр-ция с номером 67773711. С ней и разбирайся. Сама по себе долгоиграющая может появится штатно, т.к. юзеры днём там пасутся. Основной вопрос в том, почему sweep полностью блокирует работу сервера даже на запросе execute block as begin post_event 'my_event'; end Дисковая никакая ? gstat -r давно смотрел ? Сколько памяти в наличии ? Памяти 2Гб, диск один SATA2. Но и база то мелкая, зато реалтайм.
Re: Тозмоза простейших запросов
"Alexey Popov" ... Ранее я писал: Есть БД под FB2.0.3 SS. С ней постоянно работают несколько служебных программ и периодически пользователи. В служебных программах происходят только простейшие select/insert, которые выполняются обычно мгновенно. Там так же сделана сигнализация (вывод в лог) если какой то запрос будет выполняться слишком долго. И иногда в попадаются единичные записи о слишком долгом выполнении таких примитивных sql запросов - до 44 секунд! Время суток - уже когда пользователи ушли домой, серьёзной нагрузки нет. Запись о замедлении есть с разных клиентов в одно и тоже время, один из клиентов находится там где и сервер БД, поэтому проблемы с сетью как бы отметаются. Виноват оказался sweep. Откуда это видно ? Вот наиболее важные свойства базы: Database size : 1409 Mb Page size 8192 ODS version 11.0 Oldest transaction 67773710 Oldest active 67773711 Oldest snapshot 67773711 Next transaction 67786537 Sweep interval: 2 Как вижно разница скоро достигнет 2 и сработает sweep. Почему транзацкции застревают - это отдельный вопрос, ранее такого не было. Может быть rollback виноват??? OIT застревает или от роллбека, или от лимбо. Это азы. Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е. есть долгоиграющая тр-ция с номером 67773711. С ней и разбирайся. Основной вопрос в том, почему sweep полностью блокирует работу сервера даже на запросе execute block as begin post_event 'my_event'; end ? Дисковая никакая ? gstat -r давно смотрел ? Сколько памяти в наличии ? -- Хорсун Влад
Re: Тозмоза простейших запросов
Alexey Popov wrote: Как вижно разница скоро достигнет 2 и сработает sweep. Почему транзацкции застревают - это отдельный вопрос, ранее такого не было. Может быть rollback виноват??? Получается что после sweep разница обнуляется продолжается сразу расти вновь? Что это может значить?
Re: перестают поступать события
Alexey Popov wrote: Есть FB2.0 SS и служба работающая на этом же компе. Служба подписывается на события и слушает их. Всё это работает много дней. В какой то момент перестают доходить события до службы. Для проверки этой гипотезы сделано тестовое событие, которые регулярно по таймеру генерируется самой службой и отслеживается появление соответствующего уведомления. И действительно, события перестают доходить. В чём может быть причина? Ранее такого вроде бы не наблюдалось. Чисто технически, внутри там вроде дополнительно TCP соединение, по которому передаются события. Предположим, что оно по каким то причинам протухло... Кто вернёт ошибку в этом случае? Итак, после замены IP на 127.0.0.1 в течении ~20 суток непрерывной работы проблема пока не появляется. Архитектурная проблема в API что нет способа определить отвал соединения для эвентов при асинхронной работе с ними.
Re: Оптимизатор 2.5.2 : учёт взаимодействия FK, JOIN, DISTINCT, GROUP BY в простейших случаях
08.11.2011 15:52, Arioch пишет: В ту же копилку, взаимодействие агрегатов и where select m.object as object_idx, max (m.turn) as max_turn from metrics m /* where m.turn > 45 */ group by m.object having max (m.turn) > 45 order by 2 descending select m.object as object_idx, max (m.turn) as max_turn from metrics m where m.turn > 45 group by m.object /* having max (m.turn) > 45 */ order by 2 descending Я даже комментировать это не хочу, уж извините. -- Дмитрий Еманов
Re: Оптимизатор 2.5.2 : учёт взаимодействия FK, JOIN, DISTINCT, GROUP BY в простейших случаях
В письме от Tue, 08 Nov 2011 15:38:30 +0400, Arioch сообщал: Таблица Objects (integer idx not null Primary key и еще столбцы) Таблица Metrics (integer idx not null Primary key, integer Object not null -> FK на Objects.idx, double Turn индексированное); В ту же копилку, взаимодействие агрегатов и where select m.object as object_idx, max (m.turn) as max_turn from metrics m /* where m.turn > 45 */ group by m.object having max (m.turn) > 45 order by 2 descending --- PLAN SORT ((M ORDER FK_METRICS_1)) Indexed Reads: 9351 select m.object as object_idx, max (m.turn) as max_turn from metrics m where m.turn > 45 group by m.object /* having max (m.turn) > 45 */ order by 2 descending -- PLAN SORT ((M ORDER FK_METRICS_1 INDEX (METRICS_IDX2))) Indexed Reads: 1352 -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)
07.11.2011 16:35, Arioch пишет: В случае ошибки вероятно исключение всплывает наверх и проплывает через код, который знает из каких строк он исходные значения взял. Никакой код об этом не знает, ибо работает на основе BLR. А привязка BLR к SQL существует лишь на уровне команд целиком. -- Дмитрий Еманов
Re: Ubuntu и QIBASE - драйвер Firebird для Qt
08.11.2011 03:09, Kochmin Alexandr пишет: > это ты бесплатный Qt юзаешь видимо? Отож. :) Он входит в большинство дистрибутивов. На нём основан KDE, идущий по умолчанию в OpenSUSE, Fedora, Kubuntu, и многих других сборках. А в случае использования других DE, например GNOME или XFCE, GPL-ный Qt поставится по зависимостям ежели установишь использующую его прогу. Так что чтобы использовать коммерческий Qt в linux-ах придётся линковать статиком, или заниматься каким другим извращением. :) К тому же сейчас нет различия в кодовой базе между коммерческим, GPL-ным и LGPL-ным вариантами. Описаная трабла характерна именно для Ubuntu и производных, т. к. если верить changelog-у в исходном Debian-овском пакете libqt4-sql-ibase собирается. А в Ubuntu его отдельным местом отключают... Причём ежели скачать исходники Qt и включить его обратно, то всё собирается «на ура». -- Александр Замараев
Re: Ubuntu и QIBASE - драйвер Firebird для Qt
это ты бесплатный Qt юзаешь видимо? 07.11.2011 18:04, Tonal wrote: Обнаружил тут неприятную вещь: драйвер QIBASE отключен при стандартной сборке пакета. Соответственно загрузить его из стандартного репозитория нельзя, приходится пересобирать. А это, понятно, дополнительные напряги при деплое... :( Пакет должен называться libqt4-sql-ibase_4.7.4-0ubuntu8_i386.deb, но он тупо отрублен в конфигах qt4-x11-4.x.x Начиная с 4.4.0 Можа кто знает, можно ли на это повлиять?
Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)
В письме от Fri, 04 Nov 2011 13:14:10 +0400, Dmitry Yemanov сообщал: А при arithmetic error что выводить? Движок понятия не имеет на этот момент, с какими строками/столбцами он работает. Код выполнения операций контекстно отвязан от выборки данных, ему все равно с чем работать на входе. Ну как-то он привязан же ? ведь результаты кладутся куда надо ? В случае ошибки вероятно исключение всплывает наверх и проплывает через код, который знает из каких строк он исходные значения взял. -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)
04.11.2011 1:22, Arioch пишет: А с какими данными это произошло? В какой строке в каком столбце какой таблицы ??? Ну и запросы у вас (с) а план запроса можно построить по BLR ? Конечно. Но причем тут план? select * from VIEW_VECTOR_COSINES Arithmetic overflow or division by zero has occurred. arithmetic exception, numeric overflow, or string truncation. Floating-point divide by zero. The code attempted to divide a floating-point value by zero. PLAN JOIN (VECTOR_COSINES P NATURAL, VECTOR_COSINES Q INDEX (PK_VECTORS)) План любопытный - показываются вьюхи, а не таблицы - но при этом показывают PK от таблицЫ, а не от вьюх. Показывается как имя вьюхи (VECTOR_COSINES) так и имя/алиас таблицы внутри вьюхи (Q). Но зато есть статистика - а в статистике уже показаны не вьюхи, а таблицы!!! Причем тут статистика? Так вот, зная таблицы и зная внутрение id каждой строки (RDB$ что-то там, не помню уже), движок же может для каждой таблицы выбрать поля, входящие в PK или уникакльные индексы, и для этих полей прочитать и сообщить значения ? Какие именно значения сообщить? Ну при нарушении PK/UK теоретически возможно сообщить значение ключа-дубликата. А при arithmetic error что выводить? Движок понятия не имеет на этот момент, с какими строками/столбцами он работает. Код выполнения операций контекстно отвязан от выборки данных, ему все равно с чем работать на входе. -- Дмитрий Еманов
Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)
В письме от Thu, 03 Nov 2011 22:22:43 +0400, Dmitry Yemanov сообщал: ФБ всегда сообщает о контексте ошибки (строка/столбец), если это произошло в процедуре. Если это не так - в трекер. Ну сообщает. Arithmetic overflow or division by zero has occurred. arithmetic exception, numeric overflow, or string truncation. Floating-point divide by zero. The code attempted to divide a floating-point value by zero. At procedure 'DO_CALCULATIONS' line: 13, col: 2. А с какими данными это произошло? В какой строке в каком столбце какой таблицы ??? будущем. Для нормальной диагностики нужен исходный код проблемного места. Из дерева выполнения (или даже BLR) реконструировать его - мягко а план запроса можно построить по BLR ? вот я соотв. кусок из процедуры забиваю напрямую: select * from VIEW_VECTOR_COSINES Arithmetic overflow or division by zero has occurred. arithmetic exception, numeric overflow, or string truncation. Floating-point divide by zero. The code attempted to divide a floating-point value by zero. PLAN JOIN (VECTOR_COSINES P NATURAL, VECTOR_COSINES Q INDEX (PK_VECTORS)) План любопытный - показываются вьюхи, а не таблицы - но при этом показывают PK от таблицЫ, а не от вьюх. Более сложный запрос: merge into metrics m using vector_angles_deg v on m.idx=v.metrics_idx when matched then update set m.turn = v.angle; Sorry, plan is unavailable for this statement... Ну ладно, хемуль с ним с планом, хотя раньше был, кажется. Но зато есть статистика - а в статистике уже показаны не вьюхи, а таблицы!!! Так вот, зная таблицы и зная внутрение id каждой строки (RDB$ что-то там, не помню уже), движок же может для каждой таблицы выбрать поля, входящие в PK или уникакльные индексы, и для этих полей прочитать и сообщить значения ? В итоге это помогло бы точно определить на какие данных запрос сломался. И столбец, и строки Operations Read : 0 Writes : 0 Fetches: 51 Marks : 3 Enchanced Info: +--+---+---+-+-+-+-+--+--+--+ |Table Name| Records | Indexed | Non-Indexed | Updates | Deletes | Inserts | Backouts | Purges | Expunges | | | Total | reads |reads| | | | | | | +--+---+---+-+-+-+-+--+--+--+ | METRICS| 0 | 1 | 0 | 1 | 0 | 0 |0 |0 |0 | | VECTORS| 0 | 1 | 2 | 0 | 0 | 0 |0 |0 |0 | +--+---+---+-+-+-+-+--+--+--+ -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)
ФБ всегда сообщает о контексте ошибки (строка/столбец), если это произошло в процедуре. Если это не так - в трекер. Но при этом не сообщается, где именно в отдельном PSQL-запросе произошла ошибка. И я сильно не уверен, что такого стоит ожидать в ближайшем будущем. Для нормальной диагностики нужен исходный код проблемного места. Из дерева выполнения (или даже BLR) реконструировать его - мягко говоря непросто. А хранить debug info в разрезе синтаксических конструкций вместо текущих line-column - я вообще не уверен, что это правильный подход. Так что пока придется мириться с тем, что есть. -- Дмитрий Еманов
Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)
В письме от Wed, 02 Nov 2011 23:03:07 +0400, Алексей Вишняков сообщал: Щас вам с таким предложением посоветуют пройти в трекер. И будут правы :) предложат - пройду но тут есть минимум два девела, кто инoгда может сразу влёт сказать "фигня вопрос" или "нет и не надейтесь, это только кажется легко" иногда полезно обсудить и до трекера. мой первый пост в этой ветке это доказывает :-) -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)
Щас вам с таким предложением посоветуют пройти в трекер. И будут правы :) С уважением, Алексей Вишняков 02.11.2011, в 23:00, Arioch написал(а): > В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov > сообщал: > >> 22.10.2011 9:21, Arioch пишет: >> > >> > Хорошая штука UPDATE с JOIN'ом :-) >> >> Чем MERGE не устроил? > > > Вот > Нарвался в данных на совпадение двух точек подряд. Отсюда нуевая длина и > деление на ноль. В одной строке из множества. > > И все это внутри процедуры, хотя это и не так важно. > > > Недостаток в том, что сообщив про деление на ноль, FB это просто > констатирует, не сообщая где. > > Между тем, объединяетсЯ таблица и вьюха, в которую в несколько шагов > объединяются ещё две таблицы. > Во всех таблицах есть PK, а в одной ещё и UNIQE индекс. > > Если бы FB нарвавшись на жесткую ошибку типа деления на ноль, сообщил бы в > каком месте - было бы проще искать. > Проанализировать таблицы, входящие в запрос, какие у них есть уникальные > или PK-шные индексы, и добавить к сообщению об ошибке что-то типа > > "Occured at: Table1(PK(field1=1; field2=2); Unique(field3 = "abc")); > Table2(PK(Field1=2)); Table2(PK(Field1�)); Table3(PK(Field1=0));" > > > -- > Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ >
Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)
В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov сообщал: 22.10.2011 9:21, Arioch пишет: > > Хорошая штука UPDATE с JOIN'ом :-) Чем MERGE не устроил? Вот Нарвался в данных на совпадение двух точек подряд. Отсюда нуевая длина и деление на ноль. В одной строке из множества. И все это внутри процедуры, хотя это и не так важно. Недостаток в том, что сообщив про деление на ноль, FB это просто констатирует, не сообщая где. Между тем, объединяетсЯ таблица и вьюха, в которую в несколько шагов объединяются ещё две таблицы. Во всех таблицах есть PK, а в одной ещё и UNIQE индекс. Если бы FB нарвавшись на жесткую ошибку типа деления на ноль, сообщил бы в каком месте - было бы проще искать. Проанализировать таблицы, входящие в запрос, какие у них есть уникальные или PK-шные индексы, и добавить к сообщению об ошибке что-то типа "Occured at: Table1(PK(field1=1; field2=2); Unique(field3 = "abc")); Table2(PK(Field1=2)); Table2(PK(Field1=-2)); Table3(PK(Field1=0));" -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Re: buffer overflow detected при вызове udf в isql
Коннект локальный. Была ошибка в UDF.
Re: buffer overflow detected при вызове udf в isql
> > Переполнение буффера, с 99.99% вероятностью проблема в UDF. > Действительно, отыскал ошибку. Большое спасибо.
