iBase.ru Forum

Ох, мама ...

а это шутил flamerobin. А в базе все прекрасно. Материться не буду в публичном месте.

Firebird 2.5.1, работаю из Си через ODBC (драйвер 2.0.1) В таблице есть поле varchar(32000) при добавлении умеренного большого объема данных (~5000 символов) в базе оказывается пустое поле. Firebird не выдает никаких ошибок. Критический размер зависит от того, что я пишу. Первый тест, на котором я н...

Дошло ... На самом деле надо было слегка напрячь фантазию. Правильный вариант выглядел так: SELECT first 1 * FROM OPERATIONS where account=? order by account desc,tm desc и firebird прекрасно воспользовался для выборки индексом по двум полям, который был создан в самом начале, выдав ожидаемое неболь...

Dimitry Sibiryakov писал(а):Почитай это.

Да я там не увидел ничего, что могло бы мне помочь

с нее и начинал

Есть у меня простая проблема, для которой я нашел только очень кривое решение: есть таблица, в которой хранятся некоторые данные (на самом деле задача типовая), пусть будет такая: table operations account integer,tm integer,... данные по операциям клиентов в системе, клиент идентифицируется полем ac...

Докладываю: 1. Не дожидаясь ответа я сделал b/r и проблема вылечилась 2. Копия БД есть и до b/r, и до добавления поля с конвертированием - у меня ежедневные автобекапы есть, причем сделанные с помоью copy, а не gbak :) Так что если интересно, то я могу снять статистику и прислать. Мне-то уже не акту...

kdv писал(а):b/r делал?

Нет.

При этом поле starttime накапливалось с начала существования БД, а starttm было добавлено недавно и заполнено большим пакетным конвертированием. Не знаю, влияет ли это на что-либо

Была у меня простая табличка (smena) - время работы людей в системе: userid integer starttime timestamp endtime timestamp по обоим - индексы и захотелось мне изжить у себя в системе timestamp'ы, жившие в ней со стародавних времен (для всех новых дел использую время в секундах с 2000 года, INTEGER) д...

Т.е. для cid='2290000' есть ID, близкий к максимальному ? Да, причем я так подобрал, чтобы все имеющиеся записи имели ID близкий к максимуму. Максимальный ID=1690161, а записи с CID 2290000 имеют ID=1690115, 1690112, 1690110 1506 фетчей чётко указывает на долгий скан индекса. Я на это тоже обратил ...

А на пункте "б" возможно 2 варианта: - полное сканирование второго индекса от начала к концу с проверкой на то, попадает ли запись номер X в список с пункта "а", если попадает - вывод Именно это я и написал Спасибо, переспросить никогда не вредно. В общем, это упростило понимание проблемы. Напрягши...

а поиск - просмотр трех страниц (в соответствии с глубиной индекса) мда, это уже начинает напоминать цирк. Глубина индекса определяет стоимость однократного поиска, т.е. выборки одного ключа, например в уникальном индексе. То есть, сколько страниц придется пройти от корневой до конечной, где находи...

Наверное :( Я вообще не понимаю, что может тормозить в сортировке по индексу одной записи, пр иглубине индекса 3 :( Это ж не 7 ms, это 170, и процессор далеко не 286. Ибо совершенно не понимаешь, как работает PLAN ORDER. PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID)) означает, что а) сканируется и...

я тебе говорю что происходит в соответствии с планом. Ну а я комментирую, что ка краз на описываемой процедуре он и не тормозит, а тормозит на сортировке по ID. Я наблюдаю прямо противоположное: 1. при сортировке по индексу певый фетч тормозит нереально, дальше - работает быстро потому что первое и...

И тут я решил посмотреть, как выполняются заросы без +0 при выборках номеров с разным количеством записей: Нет никакой зависимости от числа записей. Время первого фетча = сколько шуровать в порядке индекса до первой подходящей записи. Он "шурует" на большинстве записей по 200 мс. Нереально много. П...

план PLAN (INCALLS ORDER INCALLS_ID_D INDEX (INCID)) означает следующее - берется индекс incid, и сервер по нему шурует в поиске ключей, попадающих под заданное условие. Как находит - обращается к таблице, выводит запись, и едет дальше. Опять находит, и опять едет дальше. потому и время для разных ...

Лирика-лирикой, но попробуем вернуться к теме этого треда. У меня новый повод для ступора возник в отй же самой ситуации. Итак - на некоторых часто выполняющихся запросах я благополучно добавил +0 и получил разумное время выполнения в доли миллисекунды там, где начали мы с 250 миллисекунд. И было у ...

Ну задержка у нас тут не с потолка берется - это же загрузка CPU + ожидание чтения в очереди к диску. Загрузка CPU - все равно, в один коннект или в кучу, все равно суммируется. Что там с оптимизацией чтения - не знаю. Т.е. у тебя всё в загрузку CPU и дисковой системы упёрлось? Так что ты тогда на ...

Скажем - службу 09. В час пик - пара клиентов в минуту на девочку - не сказки. Итого: 300 * n (n - количество запросов на поиск, все же уложить поиск в 1 запрос сложно). Итого - 10 * n запросов в секунду. Тут напрягаться придется всяко не от 0.5 s - и 100 ms уже проблема. Но, конечно, 10ms еще можн...

Представьте себе сервер с нагрузкой в сотню запросов в секунду я знал, что дойдет и до этого. Представьте себе сервер ФБ с 300 одновременно что-то делающими пользователями, над базой размером 30 гигабайт. Например. И это не сказать чтобы выдающийся случай. ну представил. Скажем - службу 09. В час п...

250 ms против 0.2 ms после добавления +0, последний, на котором я понял, что проблема какая-то системная - это 35x (3500%) - 7 ms против 0.2 ms после добавления +0. я уже говорил, что для большинства приложений это не разница, особенно между 7 и 0.2 миллисекунд. На это вообще никто не смотрит. Пред...