Здравствуйте, Neco, Вы писали:

N>Здравствуйте, B0rG, Вы писали:

BG>>Уважаемый, пишите запросы крупным почерком — берегите глаза чекистов.
N>переписал вот так:

Спасибо, теперь хоть более-менее понятно, что именно вы хотите получить.

Еще бы очень хотелось посмотреть на полный (не порезанный план), за порезанный план я уже -1 поставил.

У тоада есть интересные особенности во-первых он высасывает поначалу только n первых записей из resultseta, что существенно влияет на производительность, другая особенность (как я подозреваю) он начинает тащить записи еще до того как запрос полностью выполнился (не совсем точно, но смысл, надеюсь ясен). поэтому "кажется", что запрос работает быстрее.

Воткнуть материальные вьюхи — это самое правильное решение. Судя по названию таблиц они более-менее статичные, и можно не боятся быстрого изменения данных. К тому же высасывать данные из прилинкованной базы подзапросами вида NVL(ID, some_value) in (SELECT ID FROM DB_LINK_VIEW) быстро никогда не будет.

BG>>дальше комментарии по запросу —
BG>>1. поменять на константу, потому как оно и будет константой, это уберет NVL и поможет оптимайзеру
N>заменил переменной. в приниципе да — могу вычислять это перед запросом (лишний поход в базу, ну да фиг с ним).

Если это статичная константа, то можно ее инитить один раз при запуске аппликухи, вместе с остальными статичными константами.

BG>>3. сделайте union на первую и вторую часть условия и по этому юниону уже select from cost_center_master where id in ( select a.id union all select b.id).
N>это тоже меняет суть запроса. тогда выбираются и те и другие, а надо тех, которые и там и там. заменил на intersect.

N>немного поясню вопрос:
N>1. код SQL генерируется. причём различные участки повторно используются, что собственно и делает генерацию нужной — замена статическим оптимизированным SQL-выражением приведёт к многочисленным копи-пастам, чего не хотелось бы.
N>2. у меня уже есть workaround — если я делаю вьюшку материализованными представлениями, то всё начинает летать как в тоаде, так и в софте. вьюшки обновляются раз в сутки ночью — можно себе это позволить. другой workaround — внутри одной из вьюшек добавить хинт NO_USE_HASH. тогда запрос начинает выполняться за 6 секунд в обоих случаях (toad vs .net).

надо брать тоад и внимательно смотреть на план, но если с материальными вьюхами работает, то баг можно и нужно закрывать.

N>3. вопрос не в том, как улучшить SQL-запрос или вьюшки, а в том, как добиться одинакового поведения и узнать почему оно собственно рознится. почему принимая запрос из toad'а оракл выполняет TEMP TABLE TRANSFORMATION, а принимая тот же запрос из дотнета, почему-то не хочет.

Если вас так гложет любопытство, то возьмите план и внимательно его прочитайте. Так же стоит запустить тот же самый запрос в тоаде через "Execute As Script", боюсь получите тот же результат, что и в .net.

И скажите плз что и в том и том случае выдает

select value from v$parameter where name='optimizer_mode'

Здравствуйте, rumatavz, Вы писали:

R>И скажите плз что и в том и том случае выдает
R>

R>select value from v$parameter where name='optimizer_mode'
R>

о, вот это надо глянуть — интересный момент.
только приболел я сегодня — не пошёл на работу. теперь только в понедельник смогу посмотреть. :(

N>что может приводить к такому поведению?
выяснилось, что причиной является то, что дотнетовские библиотеки (заразы) по умолчанию готовят оракл к распределённой транзакции, что заставляет оракл "мыслить" иначе.
Добавление Enlist=false для ODP.Net и Omit Oracle Connection Name=true для System.Data.OracleClient решает проблему.

тема на форуме оракла https://forums.oracle.com/forums/message.jspa?messageID=9875573

Здравствуйте, Neco, Вы писали:

N>выяснилось, что причиной является то, что дотнетовские библиотеки (заразы) по умолчанию готовят оракл к распределённой транзакции, что заставляет оракл "мыслить" иначе.
N>Добавление Enlist=false для ODP.Net и Omit Oracle Connection Name=true для System.Data.OracleClient решает проблему.
Это получается, что TransactionScope в пределах одного коннекшина не будет работать, или будет?

Здравствуйте, fddima, Вы писали:

N>>Добавление Enlist=false для ODP.Net и Omit Oracle Connection Name=true для System.Data.OracleClient решает проблему.
F> Это получается, что TransactionScope в пределах одного коннекшина не будет работать, или будет?
а с ораклом у меня TransactionScope никогда не работал. Всегда выдавал ошибку "Unable to load DLL 'oramts.dll'", поэтому я использовал только OracleTransaction в явном виде.
Попробовал сейчас с указанными параметрами — так и есть, к текущей транзакции не цепляется (и не выдаёт ошибку конечно). Ну до тех пор пока не понадобились на практике распределённые транзакции с этим можно жить. А когда понадобятся, то просаживание производительности будет хоть чем-то оправдано.

Здравствуйте, Neco, Вы писали:

Понятно. Ну, как по мне — главная фишка TransactionScope — это как раз возможность не получать распределенную транзакцию для вложенных соединений (с одинаковыми параметрами), это работает для mssql 2008. Жаль, что с оракловым клиентом традиционно какие-то проблемы.