iBase.ru Forum

Одну или null строк для каждого kv.
про сам запрос - мог бы, но не вернёт - больше нет (проверка в тригере на таблице специально стоит, чтоб такого не случилось).

да. Мне по каждой KV нужно найти 1 заявку.

fb 2.1 План PLAN JOIN (A INDEX (ZAIVKA_IDX1), SS3 INDEX (RDB$PRIMARY14)) PLAN JOIN (SS1 NATURAL, SKV1 INDEX (ZAIVKA_IDX3)) Адаптированный план PLAN JOIN (A INDEX (ZAIVKA_IDX1), SS3 INDEX (PK_ZAIVKA_STATUS)) PLAN JOIN (SS1 NATURAL, SKV1 INDEX (ZAIVKA_IDX3)) ------ Performance info ------ Prepare time...

select * from zaivka skv1, zaivka_status ss1 where ss1.id=skv1.sost and ss1.otboy='F' and SKV1.in_d+skv1.id_t/24=(select min(a.in_d+a.id_t/24) from zaivka a, zaivka_status ss3 where ss3.id=a.sost and ss3.otboy='F' and a.in_d>=:dd and a.KV=skv1.KV) zaivka_status - маленькая (30 записей) zaivka - нес...

ага, я также проверил. Только меньше извращался. причём я ожидал что на примерно равных таблицах join догонит exist, но это оказалось не так.

Как ни странно, но в fb2.1 exist работает неплохо.
Так что возможно мой вариант будет медленне при прочих выборках.

Эти два пункта мне понятны
Execute time = 688ms
Avg fetch time = 49,14 ms
А вот это нет
Prepare time = 703ms

Вопрос про скорость дисков снят этим:
Reads from disk to cache = 0

Они на общую скорость жалуются. Ни на что конкретного не жалуются. Вот например один из спорных запросов: SELECT ID, NAME, CMNT, case WHEN (NAME is null) then '*' else NAME end||case WHEN (CMNT is null) then '' else ' '||CMNT end NNN, SOTR, FU, SRT, TEL, EMAIL, P, BDAY, INN, ADR, DREG, USR, USR_TM, ...

Как вариант:
select * from table1 t1
left join table t2 on t1.id=t2.id
where t2.id is null
или через exists, но я его не люблю. Хотя то или иное решение имеют место быть в зависимости от объёма таблиц (текущего и расчётного)

>500 GB ? Или всё-таки MB ? мб. Тяжело переключаться ;) >Сколько памяти всего ? 2Гб >Какой р-р страницы ? 8К >Какой р-р кеша БД ? 10000 блоков, увеличивал до 80000 >Пример запроса с планом и статистикой выполнения ? начиная с простейших: select count(*) from clients План PLAN (KLIENT NATURAL) Адапти...

С недовольством пользователей стало понятно.
На полу-пустой базе - 40-200мс с фетчем данных.
На базе в 0,5Тб 2000-3000мс. Загоняем всё в кеш - скорость подрастает (на процентов 10-20).

Про своп понятней не стало. Упорно пишет про виртуальную память в 770м. и 107м оперативной. Я в шоке.

Всем большое спасибо, особенно hvlad за ответ про необходимость разогрева базы. Сегодня ночью рестартую базу и проведу эксперимент с её разогревом натуральными запросами. По результатам отчитаюсь. Промежуточный результат мониторинга запросов приложения - нет ни одного запроса который выполняется дол...

Здесь все стебаются Нет, здесь неправильные советы дают. Читать CONTAINING, в том числе тебе. Первое, что сделал при проектировании FB - понял как НЕ писать его к месту и не к месту. Слишком лениво столько писать, да ещё в каждом запросе где нужен like. Да и всё равно забуду - поддержка ANSI SQL ру...

Были б курсы в ёбурге - попробовал бы от работы оторваться. А так... не в этом году. И так дочку не вижу. Можно я тогда по порядку помучаю? Начинаю мучать ;) Читая форум и статьи на ibase пришёл к выводам, что в тормозах виновато: 1. Кривость приложения. 2. Мусор. 3. Дисковая подсистема. 4. настройк...

гугл нашёл и пояснил про FBScanner.

Но ощущение от общения - как будто на разных языках говорим.

Я эту тему и начал с вопроса про своп. Увеличение кеша привело к тому что вырос своп и увеличились тормоза, а в оперативке сколько было Fb, столько и осталось. И про привязку к процу. Что-то я запутался. Класик прекрасно работает с кучей процов, а супер пока умеет работать только с одним. Так почему...

Запустил монитор - смотрю. нагрузки на сервак почти нет. Спит. То что идёт на запись - вообще копейки - даже не заметно. На чтение - пики проц + диск. краткосрочные. отдельные (2-3 сек, загрузка 100% одного ядра, + активное чтение диска той же продолжительности). Явно какой-то запрос читается не по ...

Здесь все стебаются
select <val>[,val[...]]
from <table>
where <field> like '%привет%'

если регист неважен - то upper (есть такая функция).

А вообще смотри основы SQL. Ребята правы, что стебаются.

Про кривость запросов - может быть. Писалось давно и левой пяткой, но над этим понятно как работать. Чтоб не сильно напирали на это - вставлю фразу "под ораклом мной спроектированные базы в несколько терабайт работают на отлично". Диски проверю в понедельник и отпишусь. Про мусор - я и говорю что вс...

Сейчас Fb 2.0.3. Сборка мусора была автоматом - переделал на ежедневно ночью (как и бекап 2-3 раза в день перенёс только на ночь). Это помогло избавится от резкого замедленияпри их запуске автоматом. Сервер появился тем летом, до этого был ПК пользователя. Про диски подумаю чем померить (если есть с...