одно условие добавляет 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

> Что то можно сделать с места?
запрос с этим условием из подзапроса с остальными, можно попробовать.
или перенести проблемное условие в конец, хотя это не так радикально, и скорее всего не поможет.

> запрос с этим условием из подзапроса с остальными, можно
> попробовать.

спасибо, те же 5 минут
5+!

Нет. Опять началось.
Похоже не в этом дело

вообще довольно глупо делать выборку всего в openquery, во вьющке, чтобы после отобрать часть уже на другом сервере...
лучше вставить условия отбора в запрос самого openquery... + те же на таблицу отбора в mssql. и union  уже готовых результатов.
пусть параметры придется проверять в двух местах, но зато не будет закачки 10 миллионов (или сколько там) в mssql чтобы после отобрать 5 тысяч (если данных в таблицах "в пополаме").

попробуй без вюьшки, оформи запрос сам, по описанному, скорее всего будет меньше 5 мин.

хотя это конечно не объясняет почему временами тормозит... ну да, оракл, сер. ;) я его без проблем и не видел то ни разу.

Условие однозначно должно быть в openquery, чтобы с ним работал оракловый оптимизатор.
Не зная структуры исходных таблиц, наличия/отсутствия индексов и их селективности, не наблюдая планов выполнения(и на Oracle, и на MS SQL), любые выводы - это гадание на кофейной гуще.

Гость, cделай выборку ID ( или какое уникальное поле есть) и aon, во временную таблицу.
Из временной таблицы вторым запросом (в этом же скопе) с тормозящим условием сделай уже чистовую выборку.
Потом дропнуть временную таблицу не забудь.
Как бонус, на временную таблицу можно индекс прикрутить, если есть желание.

> Из временной таблицы вторым запросом (в этом же скопе) с тормозящим условием сделай уже чистовую выборку.
подзапрос в [1] = аналог временной таблицы, и раз не помогло [3], то дело не в условии/обработки им "временной", а в тормозах работы изначального запроса в openquery которым заполняют "временную"... и который можно координально ускорить если последовать советам [4], [6].
и никаких бонусов прикручивать не нужно. а желание плодить сущности нужно искоренять.

Сегодня рискну еще одну безумную идею,
а  именно,  не like, а substring(
ведь совсем без like все так здорово..

а нет, так [4], [6].

>>ведь совсем без like все так здорово..
значит dblink работает нормально

[3] и substring вместо like, и пока все тесты не более 5минут. Посмотрим, что будет дальше

> а  именно,  не like, а substring(
like с таким условием (начало без %) пытается использовать индекс... а индекс "остался" в оракле... substring вроде никогда.

p.s. ты бы лучше все-таки попробовал с параметрами внутри openquery, чем фигней страдать.