Oracle Optimizer / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Oracle Optimizer

38 сообщений из 38, показаны все 2 страниц

все

Oracle Optimizer

#32051788

gminter

Гость

Привет All.
Есть вопрос к оптимизатору:

1)
select id, name from _table order by id;
Оптимизатор отвечает, что будет использовать план по уникальному индексу_ID; все пока хорошо.

2) select id, name from _table order by name;
По name так же есть индекс, правда не уникальный но очень селективный.
При любых комбинациях этого запроса (не учитывая задействования индекса в where), несмотря даже на прописывание плана запроса, оптимизатор неуклонно стремится к TABLE ACCESS FULL.

Почему? Как с этим БОРОТЬСЯ ???!!! Неужели Interbase круче..

...

Рейтинг:

0 / 0

19.09.2002, 20:05

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051796

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

Похоже оптимизатор молчит ;)

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

Попробуйте сравнить время этого запроса с другим, где прописан хинт на использование индекса.

Разумеется Interbase однозначно круче тут и спорить нечего.

...

Рейтинг:

0 / 0

19.09.2002, 21:40

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051806

Sergius

Гость

Значит, оптимизатор считает, что так лучше :)

Само по себе TABLE ACCESS FULL - ничего страшного не значит. Посмотри по значениям COST'a в Explain Plan'e , может все не так плохо?

А еще можно попробовать порционирование (если таблица большая).

...

Рейтинг:

0 / 0

20.09.2002, 02:50

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051822

lvv

Гость

а почему оптимизатор должен использовать индекс?
надо выбрать все записи из таблицы и отсортировать их, если Interbase при этом выбирает по одной записи, то это его проблема, Oracle делает по другому - считывает всю таблицу, а потом сортирует ее

...

Рейтинг:

0 / 0

20.09.2002, 09:08

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051827

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

lw прав.

Я кстати очень сомневаюсь, что в первом селекте используется индекс.

...

Рейтинг:

0 / 0

20.09.2002, 09:28

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051861

buzz

Гость

Select Name from table1 order by name

А теперь сравним стоимость двух вариантов исполнения.

1. Используя индекс по Name
Сервак просто вычитывает по одной строке и отдает клиенту. Сортировка обеспечена порядком используемого индекса. Все вычитывать сразу не обязательно вычитывается столько сколько клиент попросит

2. Не используя индекс.
Вычитывание идет в хаотическом порядке, посему вычитать надо все и отсортировать результат. Только после этого начинается выдача клиенту первых записей.

Если оракл не умеет действовать по варианту 1 - это убожество. Не хочется в это верить. Впрочем
Select /*+ FIRST_ROWS/ ID,Name from table1 order by ID

вправляет ему мозги и он работает по варианту 1. Но только в том случае когда order по первичному ключу... Остается вопрос как ему вернуть сообразительность в случае когда ордер по другому индексированному полю.

В заключение вопрос на засыпку. Что вернет

Select Name from table1
where RowNum<20
order by name

Лично меня результат позабавил. Его можно даже расценивать как баг.

...

Рейтинг:

0 / 0

20.09.2002, 11:06

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051869

nick

Гость

Select Name from table1
where RowNum<20
order by name
это не баг это фича :)
order by выполняется только после where !!!
т.е. сначала выборка а уж потом сортировка
а то что ты хочешь делается так
select * from(Select Name from table1
order by name) where RowNum<20

...

Рейтинг:

0 / 0

20.09.2002, 11:15

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051870

buzz

Гость

Большое спасибо. Теперь по этому пункту я просвещен.
Но остается вопрос с сортировкой. Не устраивает меня что этот гад делает у себя всю выборку и ее сортирует.

...

Рейтинг:

0 / 0

20.09.2002, 11:20

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051874

nick

Гость

при указание FIRST_ROWS мой oracle всегда использут индекс в не зависимости от того первичный это ключ или нет
поробуй сначала дать analyze или указать явное использование индекса

...

Рейтинг:

0 / 0

20.09.2002, 11:37

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051879

buzz

Гость

Я уже и индекс указывал и статистику пересчитывал, монитор протирал, с бубном плясал. Он меня игнорит.
Може чего в глобальных настройках сервака крутануть надо? Ткните носом ...

...

Рейтинг:

0 / 0

20.09.2002, 11:45

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051880

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

2 buzz

Этот "гад" делает все правильно.

В исходном запросе

select id, name from table order by id;

Вы же упростили ситуацию до

select id from table order by id; где индекс по id становится покрывающим

В первом случае поле name не входит в индекс. В этом вся разница.

Поэтому вправлять ему мозги не стоит, CBO гораздо умнее, чем вы предполагаете ;-)

Кстати FIRST_ROWS - это бестолковый хинт. Если есть нужда, то лучше использовать INDEX, INDEX_FFS и т.п.

...

Рейтинг:

0 / 0

20.09.2002, 11:46

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051887

buzz

Гость

По вашему в

Select Name from table1 order by name

индекс по Name не покрывающий? Тогда что Вы имеете в виду под термином "Покрывающий"?

...

Рейтинг:

0 / 0

20.09.2002, 12:00

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051912

buzz

Гость

Идеи кончились?

...

Рейтинг:

0 / 0

20.09.2002, 12:49

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051921

lvv

Гость

Ну во первых для случая с ID он пишет
INDEX FULL SCAN, т.е. ему достаточно пробежаться по всему индексу, а данные уже в нем и ходить за ними в таблицу не надо.

Варианты:
Для случая name, вроде тоже все данные в индексе(а может и нет)

В один блок индекса по id помещается значительно больше значений ключа, чем в блок данных. Значит по индексу бежать быстрее. Для случая с name ситуация другая, в блок индекса помещается значений почти столько же сколько и в блок данных, значит по таблице бежать выгоднее

...

Рейтинг:

0 / 0

20.09.2002, 13:10

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051925

user1

Участник

Откуда: г. Москва

Сообщения: 70

Рейтинг: 0 / 0

2 buz

А в чем собственно вопрос.
1. Почему СВО не подхватывает индекс - потому что ему быстрее выдать данные с помощью полного просмотра.
Оптимизатор потому и называеться оптимизатором, что выбирает ОПТИМАЛЬНЫЙ путь.

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

...

Рейтинг:

0 / 0

20.09.2002, 13:18

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051936

buzz

Гость

2 lvv

Чтоб не было отвлекающих рассуждений на тему integer vs varchar, скажу что ситуация сохраняется и для полей типа integer, но не входящих в первичный ключ.
То бишь

Select MyIntegerField from Table1 order by MyIntegerField
тоже не хочет пользовать индекс по MyIntegerField.

Далее насчет стоимости. Сортировка выборки 54000 записей по любому хуже выборки из индекса. Хотя бы за счет того что не нужно вычитать все записи для того, чтоб получить первую. К тому же понятно что сортируется вся выборка...

То бишь
Select * from Table1 order by MyIntegerField
сортируется на порядок медленней чем
Select MyIntegerField from Table1 order by MyIntegerField

В общем плохо это. Наглядно можно сравнивать результаты выполнения

Select * From Table1 order by ID
Скорость исполнения 2.3 сек.

с
Select /*+ FIRST_ROWS*/ * From Table1 order by ID
Скорость исполнения 0.07 сек.

На 54000 записей. Второй случай практически не зависит от количества полей в выборке. В первом все очень сильно зависит от того сколько в этой самой звездочке.
Результаты совершенно не удивительные. Удивительно что никакими силами не удается заставить оракл работать по варианту 2 в случае ордера с полями не входящими в первичный ключ.

...

Рейтинг:

0 / 0

20.09.2002, 13:33

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051937

ora600

Участник

Откуда: Москва

Сообщения: 286

Рейтинг: 0 / 0

2buzz
Поищите в init.ora
optimizer_index_caching
optimizer_index_cost_adj
и/или почитайте про них.
А сколько записей в табличке ?

2killed
FIRST/ALL_ROWS еще может повлиять на способ соединения или antijoin, так что иногда это удобнее (но менее интересно :-) ), чем делать длинные хинты типа ordered ... use_nl ... index...
Так что не так уж и бестолковый :)

...

Рейтинг:

0 / 0

20.09.2002, 13:33

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051941

buzz

Гость

2ora600

Поищите в init.ora
optimizer_index_caching
optimizer_index_cost_adj
и/или почитайте про них.

Насколько я понял это будет влиять только на использование индексов в джойнах. Ордер бай вроде как побоку. Так?

А сколько записей в табличке ?

54000. Табличка тестовая, в общем то на ней пытаюсь оттестировать возможности Оракла и свои возможности повлиять на возможности Оракла. Гм... немного запутанно получилось.

...

Рейтинг:

0 / 0

20.09.2002, 13:39

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051947

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

2 buzz

Ну почему же сразу кончились? :-) Их есть у меня. Я ведь не раскруткой этого форума занимаюсь. Извольтес подождать малость ;)

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

Ниже не ваш случай ?

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.

eshevtsov@AFK1.SYSTEMA.RU>; create table t3(name varchar2( 30 ));

Table created.

eshevtsov@AFK1.SYSTEMA.RU>; insert into t3 values('Маша');

 1  row created.

eshevtsov@AFK1.SYSTEMA.RU>; insert into t3 values('Петя');

 1  row created.

eshevtsov@AFK1.SYSTEMA.RU>; insert into t3 values('Эдик');

 1  row created.

eshevtsov@AFK1.SYSTEMA.RU>; insert into t3 values(null);

 1  row created.

eshevtsov@AFK1.SYSTEMA.RU>; commit;

Commit complete.

eshevtsov@AFK1.SYSTEMA.RU>; create index t3_ix on t3(name);

Index created.

eshevtsov@AFK1.SYSTEMA.RU>; analyze table t3 compute statistics;

Table analyzed.

eshevtsov@AFK1.SYSTEMA.RU>; set null  "Это NULL" 
eshevtsov@AFK1.SYSTEMA.RU>; select name from t3;

NAME
 -------------------------
 
Маша
Петя
Эдик
Это NULL

eshevtsov@AFK1.SYSTEMA.RU>; set autotrace on exp
eshevtsov@AFK1.SYSTEMA.RU>; 
eshevtsov@AFK1.SYSTEMA.RU>; select name from t3 order by name;

NAME
 -------------------------
 
Маша
Петя
Эдик
Это NULL


Execution Plan
 ----------------------------------------------------------
 
    0    SELECT STATEMENT Optimizer=CHOOSE (Cost= 7  Card= 4  Bytes= 12 )
     NULL

    1      0    SORT (ORDER BY) (Cost= 7  Card= 4  Bytes= 12 )                   
    2      1      TABLE ACCESS (FULL) OF 'T3' (Cost= 1  Card= 4  Bytes= 12 ) 



eshevtsov@AFK1.SYSTEMA.RU>; select name from t3 where name is not null order by name;

NAME
 -------------------------
 
Маша
Петя
Эдик


Execution Plan
 ----------------------------------------------------------
 
    0    SELECT STATEMENT Optimizer=CHOOSE (Cost= 1  Card= 3  Bytes= 9 )  
     NULL

    1      0    INDEX (FULL SCAN) OF 'T3_IX' (NON-UNIQUE) (Cost= 1  Card= 3  B 
          ytes= 9 )

...

Рейтинг:

0 / 0

20.09.2002, 13:44

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051959

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

2 Ora600

этот хинт модифицирует значение стоимости в отличие от дефолтного поведения (ALL_ROWS) а вот как модифицирует - это знает только весьма ограниченный круг людей в Редмонде :-) Далее он не эквивалентен набору хинтов, который ты упомянул. Ставя хинт INDEX ты четко понимаешь чего ожидаешь. Ставя FIRST_ROWS ты полагаешься на интеллект оптимизатора, не зная, что будет точно сделано и как. Хинты не всегда есть гуд, но раз уж ими пользоваться, то нужна абсолютная однозначность (в этом собственно смысл хинтов), а чтобы ее добиться нужно очень хорошо знать внутренние алгоритмы CBO. Я их не знаю, поэтому пытаюсь использовать хинты по минимуму и те, которые попроще.

...

Рейтинг:

0 / 0

20.09.2002, 13:58

| Ответить | Цитировать | Написать

Oracle Optimizer

#32051975

buzz

Гость

Спасибо. Это действительно тот самый случай который я анализирую. Беда в том что

для
select name from t3 where name is not null order by name
У меня получается не тот план что вы привели, а:

0 Это SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=3 Bytes=9) Это NULL
NULL

1 0 SORT (ORDER BY) (Cost=3 Card=3 Bytes=9) Это NULL
2 1 INDEX (FULL SCAN) OF 'T3_IX' (NON-UNIQUE) (Cost=1 Card=3 Это NULL
Bytes=9)

Так что ... вопрос остается в силе. Где непорядок?

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

Там же где все по правильному план выглядит как

1 0 TABLE ACCESS BY INDEX ROWID
2 1 INDEX (FULL SCAN)

...

Рейтинг:

0 / 0

20.09.2002, 14:22

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052001

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

А какая версия ?

Последний план для какого селекта был привиден?

...

Рейтинг:

0 / 0

20.09.2002, 15:03

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052007

buzz

Гость

Версия -921

План по

select /*+ FIRST_ROWS*/
* from myprobtovar
order by id

Или так

select
/*+INDEX(myprobtovar PK_TOVAR) */ * from myprobtovar
order by id

Все тот же первичный ключ.

Не понимаю почему

select
/*+INDEX(myprobtovar IND_TOVAR_NAME) */
* from myprobtovar
order by name

Не производит на сервер никакого впечатления. Он по прежнему думает за

TABLE ACCESS FULL
с последующим
SORT ORDER BY

...

Рейтинг:

0 / 0

20.09.2002, 15:17

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052026

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

Я вот смысла не улавливаю.

В первом случае ты говоришь ораклу:
Прочти каждое значение id из каждого листа индекса, затем иди и читай каждую строку таблицы. Общее число блоков = блоки индекса + блоки таблицы.

Вместо того, чтобы через фул скан прочесть все блоки таблицы за n/db_file_multiblocl_count число операций, где n - кол-во блоков таблицы. И затем сортировка.

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

Во втором случае, я так понял, что поле name определено как NULL

...

Рейтинг:

0 / 0

20.09.2002, 16:03

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052028

buzz

Гость

В первом случае ты говоришь ораклу:
Прочти каждое значение id из каждого листа индекса, затем иди и читай каждую строку таблицы. Общее число блоков = блоки индекса + блоки таблицы.

Вместо того, чтобы через фул скан прочесть все блоки таблицы за n/db_file_multiblocl_count число операций, где n - кол-во блоков таблицы. И затем сортировка.

Ключевое слово - сортировка. Я ее просто избегаю. Кроме того я ж не фетчу сразу все. Реально ~30 чтений... пусть даже блоки индекса + блоки таблицы - это все равно быстрей чем все блоки таблиц + сортировка 54000 записей. Быстрей во много раз. И не зависит ни от количества записей, ни от количества полей в таблице вообще.

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

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

Select name from T1 order by name.
Индекс по Name покрывающий? То бишь с любой точки зрения достаточно читать именно его? Так почему ж Оракл его игнорит????

Во втором случае, я так понял, что поле name определено как NULL

В смысле может быть нуллом? Специально сделал только что нот нулл. Анфас тот же только в профиль.

...

Рейтинг:

0 / 0

20.09.2002, 16:16

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052056

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

Первое утверждение неверное

Остальное на примере:

Код: plaintext

scott@DEEP.SISTEMA.RU>; select * from v$version;

BANNER
 ----------------------------------------------------------------
 
Oracle9i Enterprise Edition Release  9 . 2 . 0 . 1 . 0  - Production
PL/SQL Release  9 . 2 . 0 . 1 . 0  - Production
CORE     9 . 2 . 0 . 1 . 0        Production
TNS for Linux: Version  9 . 2 . 0 . 1 . 0  - Production
NLSRTL Version  9 . 2 . 0 . 1 . 0  - Production


scott@DEEP.SISTEMA.RU>; create table t1(id number, name varchar2( 30 ) not null);

Table created.

scott@DEEP.SISTEMA.RU>; insert into t1 values( 1 , 'Vasya');

 1  row created.

scott@DEEP.SISTEMA.RU>; insert into t1 values( 2 , 'Petya');

 1  row created.

scott@DEEP.SISTEMA.RU>; insert into t1 values( 3 , 'Masha');

 1  row created.

scott@DEEP.SISTEMA.RU>; commit;

Commit complete.

scott@DEEP.SISTEMA.RU>; create index t1_ix on t1(name);

Index created.

scott@DEEP.SISTEMA.RU>; analyze table t1 compute statistics;

Table analyzed.

scott@DEEP.SISTEMA.RU>; set autotrace on exp
scott@DEEP.SISTEMA.RU>; 
scott@DEEP.SISTEMA.RU>; 
scott@DEEP.SISTEMA.RU>; select  /*+ INDEX(t1 t1_ix) */  * from t1 order by name;

        ID NAME
 ---------- -------------------------
 
          3  Masha
          2  Petya
          1  Vasya


Execution Plan
 ----------------------------------------------------------
 
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 2  Card= 3  Bytes= 21 )
    1      0    TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost= 2  Card= 3  Bytes
          = 21 )

    2      1      INDEX (FULL SCAN) OF 'T1_IX' (NON-UNIQUE) (Cost= 1  Card= 3 
          )

Попробуйте пошагово, если получится другой результат, я буду сильно удивлен. Видимо у меня Оракл лучше ;-)

...

Рейтинг:

0 / 0

20.09.2002, 16:51

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052064

buzz

Гость

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=3 Bytes=21)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=3 Bytes
=21)

2 1 INDEX (FULL SCAN) OF 'T1_IX' (NON-UNIQUE) (Cost=1 Card=3
)

Другой.

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=3 Bytes=21)
1 0 SORT (ORDER BY) (Cost=4 Card=3 Bytes=21)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=3 Byt
es=21)

3 2 INDEX (FULL SCAN) OF 'T1_IX' (NON-UNIQUE) (Cost=1 Card
=3)

У вас нет доп сортировки. У меня есть. И статистика выполнения показывает что таки да он результат отсортировал прежде чем мне выдать.
Откель у нас такая разница в выполнениях?

ЗЫ. Кстати что вы имели в виду под "Первое утверждение неверное"?

...

Рейтинг:

0 / 0

20.09.2002, 17:02

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052072

killed

Участник

Откуда: Moscow

Сообщения: 3 025

Рейтинг: 0 / 0

Да, вот этого я пока понять не могу :(
А что говорит select * from v$version; ??

Утверждение относительно сортировки. Единств. проблема может возникнуть если у таблицы задран HWM.

...

Рейтинг:

0 / 0

20.09.2002, 17:12

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052089

vskv

Участник

Откуда: Рига

Сообщения: 536

Рейтинг: 0 / 0

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

В общем плохо это. Наглядно можно сравнивать результаты выполнения 

Select * From Table1 order by ID 
Скорость исполнения  2 . 3  сек. 

Select  /*+ FIRST_ROWS*/  * From Table1 order by ID 
Скорость исполнения  0 . 07  сек. 

На  54000  записей. Второй случай практически не зависит от количества полей в выборке. В первом все очень сильно зависит от того сколько в этой самой звездочке. 
Результаты совершенно не удивительные. Удивительно что никакими силами не удается заставить оракл работать по варианту  2  в случае ордера с полями не входящими в первичный ключ.

Сравниваем время и убеждаемся, что во втором случае время 0.07 сек не есть время полной работы запроса, а только время до получения первый строк выборки . У вас же в момент тестирования "fetch all records" не стоял, did it?

...

Рейтинг:

0 / 0

20.09.2002, 17:40

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052097

buzz

Гость

Да, вот этого я пока понять не могу :(
А что говорит select * from v$version; ??

Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
PL/SQL Release 9.2.0.1.0 - Production
TNS for Linux: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production

Утверждение относительно сортировки. Единств. проблема может возникнуть если у таблицы задран HWM.

Помедленней. Я в оракле не копенгаген пока что. Что есть HWM?

...

Рейтинг:

0 / 0

20.09.2002, 17:47

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052101

buzz

Гость

Сравниваем время и убеждаемся, что во втором случае время 0.07 сек не есть время полной работы запроса, а только время до получения первый строк выборки. У вас же в момент тестирования "fetch all records" не стоял, did it?

Конечно не стоял. При полном фетче

1) Без индекса
Select * From myprobtovar order by ID
20.048 сек

2)
Select /*+ FIRST_ROWS*/ * From myprobtovar order by ID
19.358 сек

Все равно запрос по индексу быстрей. Даже при полном фетче. И еще надо учесть что его скорость практически не зависит от количества полей. Так что он предпочтительней даже в случае фетч олл. Правда тут разница минимальна.

В статистике разница.
1)
Name,Last,Total
CPU used by this session,37
physical reads,437
physical writes,423
session logical reads,1578
sorts (disk),1
sorts (memory),0
sorts (rows),54210
table fetch by rowid,0
table scan blocks gotten,1566
table scan rows gotten,54210
table scans (long tables),1
table scans (short tables),0

2)
Name,Last,Total
CPU used by this session,43
physical reads,0
physical writes,0
session logical reads,73889
sorts (disk),0
sorts (memory),0
sorts (rows),0
table fetch by rowid,54210
table scan blocks gotten,0
table scan rows gotten,0
table scans (long tables),0
table scans (short tables),0

Кардинальная разница в
session logical reads и
sorts (rows)

...

Рейтинг:

0 / 0

20.09.2002, 18:02

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052105

gminter

Гость

Для VSKV.
Дык беда в чем - когда мы видим первый результат, то выкладываем его в сетку, и пользователь счаслив, так как он ждал всего 0.07 секунды. Ежели мы работаем 1.5 секунды, то пользователь уже ждет и нервничает.
В любом случае финальный фетч на клиента идет одинаково долго, но он то нам НЕ НУЖЕН СРАЗУ

...

Рейтинг:

0 / 0

20.09.2002, 18:11

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052132

vskv

Участник

Откуда: Рига

Сообщения: 536

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

20.09.2002, 19:45

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052134

buzz

Гость

Эа, ну нельзя же так ставить вопросы...

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

Хотя странно, обычно CBO под FIRST_ROWS и оптимизирует. У вас случаем нигде не стоит чего-нибудь типа set optimizer mode=all_rows?

Конечно сорри, но... вроде ж не раз было сказано что запрос запускался в том числе и с прямым указанием индекса и с хинтом FIRST_ROWS . Беда в том что оракл на эти указания ... с высокой колокольни короче. Вопрос был именно в том что именно могло привести к такому его поведению.
set optimizer mode завтра гляну. Но как по моему это не должно оказывать влияние на реакцию на прямые хинты в запросе. Я неправ?

...

Рейтинг:

0 / 0

20.09.2002, 20:10

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052149

gdi

Гость

Может проблема в параметре NLS_SORT?

If the value is a named linguistic sort, sorting is based on the order of the
defined linguistic sort. Most (but not all) languages supported by the NLS_LANGUAGE parameter also support a linguistic sort with the same name.

Note: Setting NLS_SORT to anything other than BINARY causes a sort to use a full table scan, regardless of the path chosen by the optimizer. BINARY is the exception because indexes are built according to a binary order of keys. Thus the optimizer can use an index to satisfy the ORDER BY clause when NLS_SORT is set to BINARY. If NLS_SORT is set to any linguistic sort, the optimizer must include a full table scan and a full sort in the execution plan.

...

Рейтинг:

0 / 0

21.09.2002, 02:45

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052153

buzz

Гость

NLS_SORT очень близко к теме.По крайней мере очень похоже.

Я не могу взять в толк две вещи.
1. Почему этот параметр должен влиять на ордер по нумерик полям.
2. Зачем собственно ALTER SESSION NLS_SORT=....

По второму пункту. Если индекс уже построен по каким-то правилам, то как изменение флага внутри сессии может повлиять на то можно использовать этот индекс или нет?
Ну и напоследок вопрос бывалым.
Как обычно вы настраиваете все эти NLS ?

...

Рейтинг:

0 / 0

21.09.2002, 11:00

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052161

gminter

Гость

К GDI

Таки помогло ))) Но все же если мы имеем сорт по какому-то number-у, отличному от первичного ключа, но так же с индексом, то проблема остается.

...

Рейтинг:

0 / 0

21.09.2002, 13:29

| Ответить | Цитировать | Написать

Oracle Optimizer

#32052288

buzz

Гость

Огромное человеческое спасибо GDI. Без всяких демагогий ткнул носом туда куда нужно.

Теперь маленькое промежуточное резюме.

Суть проблемы сводилась к тому что NLS_SORT сессии не совпадал с NLS_SORT индекса. Посему оракл просто был уверен, что индекс для ордера не подходит никак. Выхода два. Либо для сессии установить NLS_SORT=BINARY, либо создать индекс с NLS_SORT=Russian . После чего Оракл без всяких дополнительных хинтов начинает юзать этот индекс в полный рост.

Остается вопрос с нестринговыми полями. Для всяких интегеров этот финт не проходит. К тому же мне совершенно неясно почему NLS_SORT вообще должен влиять на не стринговые поля. Куды глядеть еще?

ЗЫ. Срывать мне крышу сказками о том что вычитать хаотически все и потом отсортировать, будет дешевле чем сразу читать по индексу первые записи.. не надо. Если мои аргументы идут мимо кассы, то примите во внимание что оракл тоже так считает. Когда ему дают правильный индекс , то он с него слазит крайне неохотно. Даже когда ему говоришь чтоб оптимайзил под выдачу всех записей а не первых, он совершенно правильно продолжает юзать индекс.
Но все-таки... какой индекс будет ему правильным для нестринговых полей?

...

Рейтинг:

0 / 0

23.09.2002, 10:49

| Ответить | Цитировать | Написать

38 сообщений из 38, показаны все 2 страниц

все

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Oracle Optimizer

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=52&tid=1993055]:	0ms
get settings:	9ms
get forum list:	12ms
check forum access:	4ms
check topic access:	4ms
track hit:	30ms
get topic data:	12ms
get forum data:	2ms
get page messages:	70ms
get tp. blocked users:	2ms
others:	256ms

total:	401ms