Ткну пальцем в небо — оптимизатор решил не использовать индекс в случае union. Произошло это потому, что по базе плохо собрана статистика и оптимизатор оценил результат запроса слишком большим. Ну или просто ошибся.
Ещё ткну пальцем в небо — в запросе на самом деле было написано union, а не union all. Другая семантика, другой план. Если union all, то, конечно, странно это всё.
Здравствуйте, Alex.Che, Вы писали:
AC>для зачем там скобки?
для красоты.
AC>зы: без плана обсуждать нечего.
планы и запросы большие, мне лень это аплоадить. если это легко не фиксится без подробного анализа плана — значит я лучше разделю запросы на две штуки.
пс: какого хрена оно пытается делать что-то умное вместо того чтоб последовательно выполнять оба подзапроса и потом мерджить результаты?
Здравствуйте, зиг, Вы писали:
зиг> я бы сказала что человеку нужно синхронайзд поставить. чтоб оно всегда последователньо выполнялось. и что это не очень хорошо по перфомансу, но зато надежно работает. в общем я бы ХОТЬ что-нибудь по делу сказала вместо того чтоб сразу исходный код требовать и строить из себя умную.
Ну и сели бы в лужу с вероятностью 50%. Может там совсем не Synchronized нужен.
В том-то и дело, что "ХОТЬ что-нибудь сказать" — это не по делу. Это просто засорение ветки.
Если человек не дает ответ сразу, а просит дополнительную информацию, то это не оттого, что ему нечего ответить. Наоборот, это значит что у него есть большой опыт, и он не хочет направлять по ложному пути.
select ...
from ...
where ...
union all (
select ..
from ...
where ...
)
первая часть запроса (до union all) работает быстро сама по себе, и план у нее выглядит хорошим.
Вторая часть запроса (после union all) работает тоже быстро, и план у нее тоже ок. Но когда я выполняю запрос целиком он ужасно тормозит, и план превращается в какой-то кошмар (подробно я не смотрела что именно там плохо, но суммарный cost у него гигантский).
Почему так?!
чем лечить (ну кроме как выполнять оба под запроса по отдельности, и потом мерджить результаты на клиенте)?
Здравствуйте, зиг, Вы писали:
зиг>Вторая часть запроса (после union all) работает тоже быстро, и план у нее тоже ок. Но когда я выполняю запрос целиком он ужасно тормозит, и план превращается в какой-то кошмар (подробно я не смотрела что именно там плохо, но суммарный cost у него гигантский). зиг>Почему так?!
У верблюда два горба,
потому что жизнь -- борьба!
Дело в том, что всё дело как раз в этом самом "подробно я не смотрела что именно там плохо, но..."
Не смотрела -- посморти...
MZ>Дело в том, что всё дело как раз в этом самом "подробно я не смотрела что именно там плохо, но..." MZ>Не смотрела -- посморти...
мне недосуг, я не DBA и мне за это не платят. мне лично быстрее будет разделить два мало связанных запроса на две штуки и выполнять их последовательно если оракл такой тупой и не может сделать это сам.
быстрого ответа нету получается? я думала может хинт какой есть сказать ораклу не выделываться и выполнять подзапросы последовательно
Здравствуйте, Alex.Che, Вы писали:
>> пс: какого хрена оно пытается делать что-то умное вместо того чтоб >> последовательно выполнять оба подзапроса и потом мерджить результаты?
AC>есть мнение, и не только моё, что собака зарыта где-то между строчек.
каких строчек? хотелось бы по-русски получить ответ
Здравствуйте, Softwarer, Вы писали:
зиг>> хотелось бы по-русски получить ответ S>На форумах обычно банят за мат.
а мат тут причем? не можете обойтись без мата- вам обратно к гопоте в среднюю школу, а не на проф форуме ответы отвечать
Здравствуйте, Alex.Che, Вы писали:
AC>прошлый ник "злая и глупая" был ближе к телу.
господи какие мы нежные. не можете отвечать по делу — зачем тогда влезаете в тему-то?
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, зиг, Вы писали:
S>Обходимся. Поэтому на Ваш унылый вброс никто и не реагирует.
унылый вброс это вы так любую тему называете на которую не можете ответить внятно, по-русски и без мата? логично
Здравствуйте, зиг, Вы писали:
зиг>унылый вброс это вы так любую тему называете на которую не можете ответить внятно, по-русски и без мата? логично
Внятно, по-русски и без мата Вам давно ответили, повторять смысла не вижу. А унылым вбросом я называю Ваши попытки изображать дуру и применять манипуляции детсадовского уровня.
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, зиг, Вы писали:
зиг>>унылый вброс это вы так любую тему называете на которую не можете ответить внятно, по-русски и без мата? логично
S>Внятно, по-русски и без мата Вам давно ответили, повторять смысла не вижу. А унылым вбросом я называю Ваши попытки изображать дуру и применять манипуляции детсадовского уровня.
никто не ответил мне на вопрос. с планом-то каждый дурак может, а ты попробуй без плана и без запроса _хоть что-нибудь_ подсказать. не хочется тратить свое время на расписывание множества валидных вариантов которые я хочу услышать? боишься ткнуть пальцем в небо? ну и нефиг тогда лезть в тему, оценок не получишь. а так бы глядишь и получил, и разошлись бы мирно и полюбовно
Здравствуйте, Alex.Che, Вы писали:
>> а так бы глядишь и получил, и разошлись бы мирно и полюбовно
AC>знаете, наташа, просто не хочется (с)
ладно врать-то. просто не можется. не умеется. не получается.
"хочется/не хочется" тут уже вторично
Здравствуйте, зиг, Вы писали:
зиг>первая часть запроса (до union all) работает быстро сама по себе, и план у нее выглядит хорошим. зиг>Вторая часть запроса (после union all) работает тоже быстро, и план у нее тоже ок. Но когда я выполняю запрос целиком он ужасно тормозит, и план превращается в какой-то кошмар (подробно я не смотрела что именно там плохо, но суммарный cost у него гигантский). зиг>Почему так?! зиг>чем лечить (ну кроме как выполнять оба под запроса по отдельности, и потом мерджить результаты на клиенте)?
Информации крайне недостаточно, так Вам никто не сможет помочь. Попробуйте не/использовать хинт RULE, посмотрите изменится ли от этого план.
Мерджить на клиенте это не по феншую.
Здравствуйте, зиг, Вы писали:
зиг>Есть запрос примерно такого вида:
зиг>
зиг>select ...
зиг>from ...
зиг>where ...
зиг>union all (
зиг> select ..
зиг> from ...
зиг> where ...
зиг>)
зиг>
зиг>первая часть запроса (до union all) работает быстро сама по себе, и план у нее выглядит хорошим. зиг>Вторая часть запроса (после union all) работает тоже быстро, и план у нее тоже ок. Но когда я выполняю запрос целиком он ужасно тормозит, и план превращается в какой-то кошмар (подробно я не смотрела что именно там плохо, но суммарный cost у него гигантский). зиг>Почему так?! зиг>чем лечить (ну кроме как выполнять оба под запроса по отдельности, и потом мерджить результаты на клиенте)?
а если обернуть каждый запрос в CTE а потом UNION ALL по двум CTE&
Вы там на чем программируете, на Java кажется? Давайте я приведу вам аналогичный вопрос в Java форуме, в таком же стиле.
"В нашей корпоративной мега-системе есть бин XXX. Что там внутри я не знаю, его разрабатывают в другом отделе. У него есть два метода YYY и ZZZ. Если я дергаю их по отдельности, все работает хорошо. А если я дергаю их вместе, в параллельных потоках, то все зависает, а потом валится Exception. Подскажите, как мне это быстренько пофиксить. Как сказать JVM, чтобы не выполняла эти методы вместе, а только последовательно?
Что, стектрейс нужен? Да он огромный, я его особо не смотрела, мне лень его аплоадить. И вообще, со стектрейсом каждый дурак может, а ты попробуй без стектрейса и без кода методов _хоть что-нибудь_ подсказать. Не можешь? Зачем тогда влезаешь в тему-то?
Вы вот примерно так же сейчас выглядите. Так что не обижайтесь на ответы.
P.S. Вы там не пытались намекнуть руководству, что неплохо бы иметь ораклиста в команде?
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, зиг, Вы писали:
зиг>>Есть запрос примерно такого вида: С>Напишите сюда все три плана — два для каждого запроса и третий для UNION.
разбежалась. уже сутки прошли, проблема давно решена другим способом. но местные кулибины все еще неторопливо ждут что им все принесут на тарелке
С>PS: Вы часом не в Сбертехе или R-Style работаете? DBA, план не смотрела... можно я у вас DBA поработаю? Я тоже ничего не знаю!
не возьмут вас. с планом каждый дурак сможет. а вот расскать чо да как да почем без плана и запроса — тогда приходите к нам. нет, это не в россии
и я не oracle dba, я ж сказала, я джава-программист и с базами разынми привыкла работать, мне оракловские или скл серверные тонкости по барабану
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, зиг, Вы писали:
W>Вы там на чем программируете, на Java кажется? Давайте я приведу вам аналогичный вопрос в Java форуме, в таком же стиле. W>"В нашей корпоративной мега-системе есть бин XXX. Что там внутри я не знаю, его разрабатывают в другом отделе. У него есть два метода YYY и ZZZ. Если я дергаю их по отдельности, все работает хорошо. А если я дергаю их вместе, в параллельных потоках, то все зависает, а потом валится Exception. Подскажите, как мне это быстренько пофиксить. Как сказать JVM, чтобы не выполняла эти методы вместе, а только последовательно?
я бы сказала что человеку нужно синхронайзд поставить. чтоб оно всегда последователньо выполнялось. и что это не очень хорошо по перфомансу, но зато надежно работает. в общем я бы ХОТЬ что-нибудь по делу сказала вместо того чтоб сразу исходный код требовать и строить из себя умную.
W>Что, стектрейс нужен? Да он огромный, я его особо не смотрела, мне лень его аплоадить. И вообще, со стектрейсом каждый дурак может, а ты попробуй без стектрейса и без кода методов _хоть что-нибудь_ подсказать. Не можешь? Зачем тогда влезаешь в тему-то?
см выше.
и да, я ожидала от вас что-нибудь типа "это нормальная типичная ситуация. такое происходит каждый день. union all работают в оракле через жопу и никто не знает какой план он выберет. да, это не просто тупо выполнить два запроса по отдельности и смержить результаты, оракл в принципе так не делает, Никогда. или Должен в теории, но это надо какой-нибудь хинт поставить. в данном случае пытается быть умным, да. смиритесь. поэтому чтоб решить проблему не разбивая запрос на два отдельных — нужно анализировать подзапросы не каждый по отдельности, а смотреть чем отличаются планы. оракл — проклятая ебанина."
вот такого ответа я бы ожидала. вместо этого местные аналитеки пытаются строить из себя "have you tried switch it on and off again"
W>Вы вот примерно так же сейчас выглядите. Так что не обижайтесь на ответы.
да я ваще не обижаюсь нисколько, это вы тут все обиделись что вам ответ на тарелке не несут.
W>P.S. Вы там не пытались намекнуть руководству, что неплохо бы иметь ораклиста в команде?
причем тут руководство и компания? я написала вопрос на рсдн не от лица компании или бизнеса, а от себя лично, не можете ответить — не отвечайте. вас никто вообще не заставляет. в чем проблема-то ваще??
Здравствуйте, londinium, Вы писали:
зиг>>первая часть запроса (до union all) работает быстро сама по себе, и план у нее выглядит хорошим. зиг>>Вторая часть запроса (после union all) работает тоже быстро, и план у нее тоже ок. Но когда я выполняю запрос целиком он ужасно тормозит, и план превращается в какой-то кошмар (подробно я не смотрела что именно там плохо, но суммарный cost у него гигантский). зиг>>Почему так?! зиг>>чем лечить (ну кроме как выполнять оба под запроса по отдельности, и потом мерджить результаты на клиенте)?
L> а если обернуть каждый запрос в CTE а потом UNION ALL по двум CTE&
а что такое CTE? простите если глупый вопрос, я не ораклист совсем
Здравствуйте, vsb, Вы писали:
vsb>Ткну пальцем в небо — оптимизатор решил не использовать индекс в случае union. Произошло это потому, что по базе плохо собрана статистика и оптимизатор оценил результат запроса слишком большим. Ну или просто ошибся.
vsb>Ещё ткну пальцем в небо — в запросе на самом деле было написано union, а не union all. Другая семантика, другой план. Если union all, то, конечно, странно это всё.
нет, union all там был
спасибо
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, зиг, Вы писали:
зиг>> я бы сказала что человеку нужно синхронайзд поставить. чтоб оно всегда последователньо выполнялось. и что это не очень хорошо по перфомансу, но зато надежно работает. в общем я бы ХОТЬ что-нибудь по делу сказала вместо того чтоб сразу исходный код требовать и строить из себя умную.
W>Ну и сели бы в лужу с вероятностью 50%. Может там совсем не Synchronized нужен.
ну села не села, а человеку хоть чото сказали и дополнительная информация не помешает, есть над чем поразмыслить
кстати почему села-то? синхронайзд именно и есть простейшее решение описанной проблемы
W>В том-то и дело, что "ХОТЬ что-нибудь сказать" — это не по делу. Это просто засорение ветки.
с точки зрения вопрошающего находящегося в непонятной ситуации — больше всего бесит недостаток информации и когда эту информацию от него скрывают "мы тебеничего не скажем пока не покажешь план"
W>Если человек не дает ответ сразу, а просит дополнительную информацию, то это не оттого, что ему нечего ответить. Наоборот, это значит что у него есть большой опыт, и он не хочет направлять по ложному пути.
ну и дурак
лучше б направил. меня лично. ненавижу быть в информационной изоляции
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, зиг, Вы писали:
зиг>> никто не ответил мне на вопрос. с планом-то каждый дурак может S>Не каждый. Вы же не можете.
так я ж не ораклистка и не DBA слава те господи. мне что план что не план — однофигственно, мне не за планы зарплату платят а чтоб я делала things done
иг>> а ты попробуй без плана и без запроса _хоть что-нибудь_ подсказать. S>Легко. Скажите начальнику, что вам нужно нанять программиста.
зачем? программистов у нас много и они прекрасно работают. DBA в принципе тоже, но это отдельный отдел и много бюрократии чтоб заставить их что-то сделать, мне казалось уж на рсдне то не будет такой бюрократии и ответят ХОТЬ ЧТО-НИБУДЬ в 5 минут. но на рсдн (за исключением пары товарищей) все оказалось еще хуже
зиг>> яж сказала, я джава-программист S>Наглая ложь.
хаха. я вижу у вас пукан рвет от зависти
Здравствуйте, зиг, Вы писали:
W>>В том-то и дело, что "ХОТЬ что-нибудь сказать" — это не по делу. Это просто засорение ветки. зиг>с точки зрения вопрошающего находящегося в непонятной ситуации — больше всего бесит недостаток информации и когда эту информацию от него скрывают "мы тебеничего не скажем пока не покажешь план"
1. "мы тебеничего не скажем пока не покажешь план"
2. если вы хотите что-то получить без плана см. п. 1
3. как вы себе представляете какие-либо гадалки без плана? он для этого и существует
4. "мы тебеничего не скажем пока не покажешь план"
Здравствуйте, зиг, Вы писали:
зиг>Здравствуйте, londinium, Вы писали:
зиг>>>первая часть запроса (до union all) работает быстро сама по себе, и план у нее выглядит хорошим. зиг>>>Вторая часть запроса (после union all) работает тоже быстро, и план у нее тоже ок. Но когда я выполняю запрос целиком он ужасно тормозит, и план превращается в какой-то кошмар (подробно я не смотрела что именно там плохо, но суммарный cost у него гигантский). зиг>>>Почему так?! зиг>>>чем лечить (ну кроме как выполнять оба под запроса по отдельности, и потом мерджить результаты на клиенте)?
L>> а если обернуть каждый запрос в CTE а потом UNION ALL по двум CTE&
зиг>а что такое CTE? простите если глупый вопрос, я не ораклист совсем
Common Table Expression
WITH QUERY1 AS
(
SELECT ......
),
QUERY2 AS
(
SELECT ......
)
SELECT Q.*
FROM QUERY1 Q
UNION ALL
SELECT W.*
FROM QUERY2 W
