Форум: "Базы";
Текущий архив: 2014.04.06;
Скачать: [xml.tar.bz2];
ВнизПочему запрос так долго выполняеется Найти похожие ветки
← →
Гость (2011-02-12 11:12) [0]одно условие добавляет 7 часов выполнения
есть подозрение, что проблема в таблицах. К бд доступа нет, к сожалению. Что то можно сделать с места?
select
....
where
r.id_sct in (33, 34, 49)
and start_time between @FDATE and @SDATE
and r.id_object in (183,184)
and len(r.aon) = 10
-- and r.aon like "842%" --Вот оно. С этим условием 7 часов. Без него минут 5.
and r.ring_id_cisco is not null
and r.ring_id_cisco not in ("<нет данных>", "Исх. вызов", "outcallarm09")
and r.ring_id is null
полная выборка порядка 10 000 записей, с условием and r.aon like "842%" порядка 7 000 , мелочи собственно
Есть мысль получить все, пробежаться циклом, да выбрать нужные. Но опять же хочу запросом.
запрос гетерогенный. Таблица R - на самом деле вьюшка, таблица из mssql union с таблицей oracle через openquery
← →
sniknik © (2011-02-12 12:06) [1]> Что то можно сделать с места?
запрос с этим условием из подзапроса с остальными, можно попробовать.
или перенести проблемное условие в конец, хотя это не так радикально, и скорее всего не поможет.
← →
Гость (2011-02-12 13:44) [2]
> запрос с этим условием из подзапроса с остальными, можно
> попробовать.
спасибо, те же 5 минут
5+!
← →
Гость (2011-02-12 17:41) [3]Нет. Опять началось.
Похоже не в этом дело
← →
sniknik © (2011-02-12 18:03) [4]вообще довольно глупо делать выборку всего в openquery, во вьющке, чтобы после отобрать часть уже на другом сервере...
лучше вставить условия отбора в запрос самого openquery... + те же на таблицу отбора в mssql. и union уже готовых результатов.
пусть параметры придется проверять в двух местах, но зато не будет закачки 10 миллионов (или сколько там) в mssql чтобы после отобрать 5 тысяч (если данных в таблицах "в пополаме").
попробуй без вюьшки, оформи запрос сам, по описанному, скорее всего будет меньше 5 мин.
← →
sniknik © (2011-02-12 18:05) [5]хотя это конечно не объясняет почему временами тормозит... ну да, оракл, сер. ;) я его без проблем и не видел то ни разу.
← →
Кщд (2011-02-14 08:14) [6]Условие однозначно должно быть в openquery, чтобы с ним работал оракловый оптимизатор.
Не зная структуры исходных таблиц, наличия/отсутствия индексов и их селективности, не наблюдая планов выполнения(и на Oracle, и на MS SQL), любые выводы - это гадание на кофейной гуще.
← →
JRTeston (2011-02-14 23:37) [7]Гость, cделай выборку ID ( или какое уникальное поле есть) и aon, во временную таблицу.
Из временной таблицы вторым запросом (в этом же скопе) с тормозящим условием сделай уже чистовую выборку.
Потом дропнуть временную таблицу не забудь.
Как бонус, на временную таблицу можно индекс прикрутить, если есть желание.
← →
sniknik © (2011-02-14 23:56) [8]> Из временной таблицы вторым запросом (в этом же скопе) с тормозящим условием сделай уже чистовую выборку.
подзапрос в [1] = аналог временной таблицы, и раз не помогло [3], то дело не в условии/обработки им "временной", а в тормозах работы изначального запроса в openquery которым заполняют "временную"... и который можно координально ускорить если последовать советам [4], [6].
и никаких бонусов прикручивать не нужно. а желание плодить сущности нужно искоренять.
← →
Гость (2011-02-15 09:27) [9]Сегодня рискну еще одну безумную идею,
а именно, не like, а substring(
ведь совсем без like все так здорово..
а нет, так [4], [6].
← →
Гость (2011-02-15 09:49) [10]>>ведь совсем без like все так здорово..
значит dblink работает нормально
[3] и substring вместо like, и пока все тесты не более 5минут. Посмотрим, что будет дальше
← →
sniknik © (2011-02-15 11:33) [11]> а именно, не like, а substring(
like с таким условием (начало без %) пытается использовать индекс... а индекс "остался" в оракле... substring вроде никогда.
p.s. ты бы лучше все-таки попробовал с параметрами внутри openquery, чем фигней страдать.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2014.04.06;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.002 c