Здравствуйту уважаемые! Возникла такая проблема
База Oracle 8 запросы с использованием group by по стринговым индексам сортировались нормально по алфавиту.
(select KltName,KltKod,sum(Summa) from Jurnal group by KltName,KltKod)
Перешел на Oracle 9.2 базу перенес экспорт/импорт-ом
(единственно в старой базе индексы хранились в tablespace USR, вместе с данными, а вновой перенес в отдельный tablespace)
Сейчас теже запросы сортируются по длине поля KltName, т.е. сначала все длиной 5 символов, потов 6 и т.д. по возрастанию, а если одинаковой длины, то они по алфавиту.
Не могу понять в чем причина???????????
Может кто подскажет!!!!!! Заранее спасибо.

> vlgrig1961  (30.03.2011 09:27:00)  [0]

А где тут в запросе сортировка, надеешься на везение?

сортировка в group by программа работала лет десять и все время нормально сортировалось по алфавиту!!!

Вам идеолог Oracla говорит

NO, NO, NO, NO, NOT TRUE
never been true
never was true
never will be true.
There is ONLY one way to get sorted output "gauranteed" and that is.......

           TO USE ORDER BY

> сортировка в group by программа работала лет десять и все
> время нормально сортировалось по алфавиту!!!


тебе повезло. но везение не может быть вечным

А повлияет ли на скорость выполнения запроса добавление ORDER BY???

обязательно, быстрее будет
чем больше написать, тем более быстрее работает
главное написать секретный модификатор перед запросом
do_it_fast = true
:)

а сами как считаете?
что быстрее - операция или операция + еще что-то

потеря скорости скорее всего будет практически невидна на незначительных объемах

> vlgrig1961  (30.03.2011 10:23:03)  [3]

Никогда она там не работало, было просто везение.
Теперь тебе не на кого обижаться, везение кончилось.

> vlgrig1961  (30.03.2011 11:57:06)  [6]

Конечно повлияет, ничего даром не дает, но ты уж решай сам, нужен ли тебе
сортированый набор или будем играть в рулетку.

> OW  (30.03.2011 12:04:07)  [7]

Но может быть и быстрее с сортировкой, если она совпадает с ключом, будет
другой план исполнения

> Anatoly Podgoretsky ©   (30.03.11 12:11) [10]

это да

> Никогда она там не работало, было просто везение.
не знаю за оракл, но вообще "сортировка группировкой" была, надежды на всегда правильную не было (не гарантировано, в доке не прописано), но сама она была... т.к. в процессе "группирования" удобнее манипулировать сортированными данными.

вот, чтобы не быть голословным, проверил на информиксе, первой попавшейся таблице
SELECT Code, Count(*) FROM StepTable
GROUP BY Code
строго по порядку.

я так понимаю и в оракле будет/есть, если например по числовому полю сделать... а у него текстовое, и сортировка тоже присутствует, просто оракл в какой то момент "решил" что манипулировать ему проще не просто отсортированными строками, а еще и разделенными по длине...
ну и получилось то что получилось.

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

sniknik ©   (30.03.11 12:52) [12]


> я так понимаю и в оракле будет/есть, если например по числовому
> полю сделать... а у него текстовое, и сортировка тоже присутствует,
>  просто оракл в какой то момент "решил" что манипулировать
> ему проще не просто отсортированными строками, а еще и разделенными
> по длине...


Я вот про MS SQL, информикс и прочее сказки не рассказываю, давай ты про Oracle их не будешь рассказывать.

есть такая штука, как стандарт SQL, в нем ясно английским по белому написано, что сортированный набор появляется после клаузы ORDER BY и никак иначе.

там же он пишет

group by
   o HAS NEVER HAD TO SORT
   o ALWAYS DID A BINARY SORT (meaning for most of the world, the sort
     would have been WRONG even if it happened by accident)

> sniknik  (30.03.2011 12:52:12)  [12]

И с Информиксом тебе тоже пока везет

> И с Информиксом тебе тоже пока везет
я таким никогда не пользуюсь. приведенный запрос чисто ради попытки понимания как оно там "у нутрях" работает.

>Anatoly Podgoretsky ©   (30.03.11 12:11) [10]
Но может быть и быстрее с сортировкой, если она совпадает с ключом, будет
другой план исполнения

Какое использование индекса в сгруппированном наборе?

> Какое использование индекса в сгруппированном наборе?
не в сгруппированном, а для группировки (сортированность в этом случае сама собой получится). использовать в процессе уже готовый сортированный индекс проще чем сначала сортировать, или сканировать не сортированный (для обеспечения оригинального порядка).
а раз проще/меньше действий то и быстрее тоже.

p.s. вообще, чем строить предположения/домыслы/(сказки, как ИШ говорит) посмотрели бы план запросов с индексом у поля и без/с установленным order by и без... глядишь что то и прояснилось бы.

>sniknik ©   (31.03.11 07:54) [20]
речь шла об ускорении сортировки, если в order by clause после group by содержится индексированное поле.
а это, в общем случае, не так.


не в сгруппированном, а для группировки (сортированность в этом случае сама собой получится)

в общем случае, сортировки не будет, т.к. и в Oracle и в MS SQL, например, существует распараллеливание, т.е. сканирование, в частности, индекса не будет сериализованным, последовательным.


вообще, чем строить предположения/домыслы/(сказки, как ИШ говорит) посмотрели бы план запросов с индексом у поля и без/с установленным order by и без... глядишь что то и прояснилось бы.

проверил до того, как написать первый пост
никакой магии - ожидаемо индекс не оказывает влияния.

> никакой магии - ожидаемо индекс не оказывает влияния.
магия, блин
http://saveimg.ru/show-image.php?id=e0eebbe0752624ed4e1e071e39d6d81e
надеюсь разницу в картинках объяснять не надо?

>sniknik ©   (31.03.11 09:55) [22]

Кщд   (31.03.11 09:22) [21]
речь шла об ускорении сортировки, если в order by clause после group by содержится индексированное поле.

я говорил именно об этом

но проблем, вот с сортировкой, нет индекса и есть
http://saveimg.ru/show-image.php?id=a47c6902f7de7a82945dc981ee995a4f

> нет индекса и есть
вернее наоборот есть и нет.
количество действий посчитать?

>sniknik ©   (31.03.11 10:05) [25]
в плане с индексом не видно сортировки.
очевидно,  MS SQL считает набор УЖЕ отсортированным при сканировании индекса. на это можно закладываться, но не при параллельном сканировании.
версия сервера - 2000?

> на это можно закладываться
на это вообще нельзя закладываться (иначе бы в доке было явно написано что group by = order by), и в ветке много это повторяли, но можно основываясь на этом, по предполагать, как оно работает.

> версия сервера - 2000?
да. но не думаю, что версия, что то изменит в плане "делает так как ему кажется лучше, и использует индекс если оно нужно, а если использует то может ускорить", про что, по смыслу, говорилось ранее.

> в плане
Anatoly Podgoretsky ©   (30.03.11 12:11) [10]
> Но может быть и быстрее с сортировкой, если она совпадает с ключом, будет другой план исполнения

план, другой. это очевидно по скриншотам.

> sniknik  (31.03.2011 10:27:28)  [28]

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

>sniknik ©   (31.03.11 10:25) [27]
>на это вообще нельзя закладываться
из плана явно видно, что в случае с наличием индекса, сервер не производит сортировку. т.о. оптимизатор как раз таки "закладывается" на то, что результирующий набор отсортирован.

>да. но не думаю, что версия, что то изменит в плане...
распараллеливание появилось с 2005?
при параллельном сканировании индекса, сортировка появится в плане.
и её стоимость никоим образом не будет зависеть от индексирования поля сортировки.

> а то что при дополнительной операции в некоторых случаях может работать быстрее.
ну, вообще то, order by тут это не дополнительная операция, скорее параметр...
почему вы рассматриваете это как программу, где написание доп кода означает доп действия?
селект это скорее как процедура, где это доп. параметр, и он может пустить обработку по другой ветке, что кстати и произошло у меня (второй скриншот). т.е. пишешь вроде лишние команды, а действий меньше.

> распараллеливание появилось с 2005?
> при параллельном сканировании индекса, сортировка появится в плане.
> и её стоимость никоим образом не будет зависеть от индексирования поля сортировки.
ты моих "если нужно" "а если то" в упор не видишь? пытаешься свести все к частному случаю когда не используется. зачем? и так понятно, что если "если не сработает" и даже при наличие индекса будет выбран полный скан, как и в случае без индекса, то никакого влияния не будет...
в КЭП-а играешься?

>sniknik ©   (31.03.11 11:27) [31]
>ты моих "если нужно" "а если то" в упор не видишь?
налицо взаимное недопонимание.)
я всего лишь утверждал, что наличие индексированного поля в секции order by, следующей за секцией group by, НЕ УСКОРИТ выборку.))
если Вы оппонировали не этому тезису, то вопрос закрыт.

> НЕ УСКОРИТ выборку.))
> если Вы оппонировали не этому тезису
как я мог "оппонировать к этому тезису" если вообще не говорил тезисов/конкретного?
я согласился с АП (не в понимании процесса, оно у нас похоже разное, а по сути), в том, что order by / индекс на поле / версия / вообще что угодно, может повлиять на план, а от него точно зависит и скорость выполнения. что значит оно МОЖЕТ УСКОРИТЬ выборку.