Хинты
OKuka...@hotmail.com
особливо по поводу /*+ index_ffs(...) */
Все наконец встало на свои места, в результате переписки с Oracle
support.
/*+ INDEX(table index) */ explicitly chooses an index scan for the
specified table
Этот хинт даст просто index full scan, и не полезет в таблицу,
если все колонки уже есть в индексе (это очевидно)
И результат будет точно в порядке индекса (т.е. как при index_desc)
Возможны варианты:
/*+ INDEX_ASC(table index) */ explicitly chooses an ascending-range
index scan for the specified
table.
/*+ INDEX_DESC(table index) */ explicitly chooses a descending-range
index scan for the specified
table
А вот где я "обшибся"
/*+ INDEX_FFS(table index) */ causes a fast full index scan to be
performed rather than a full
table scan
Этот хинт даст уже index FAST full scan.
Т.е. при использовании этого хинта оптимизатор пойдет только по листьям
индекса, и его совершенно не волнуют ветки! Я не настолько силен в
английском, чтобы понять это из описания.
М.б. Валера Сорокин переведет? :-)
Очевидно, после
alter index ... rebuild;
все листья будут упорядочены и результат будет тот же что и у
/*+ INDEX(table index) */ , только быстрее, т.к. "мы не лазим по
дереву"!
Для чего этот балаган?
Просто хинты можно использовать в подзапросах, а order by только в 8I
Мне пришлось использовать INDEX_FFS т.к. разница в скорости была почти в
6 раз...
Могу кинуть скрипт, если кого интересует, как все это выглядит "в
натуре" :-)
OK
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Alex Malkovsky
OKuka...@hotmail.com пишет в сообщении <7qhl5q$coo$1...@nnrp1.deja.com> ...
>/*+ INDEX(table index) */ explicitly chooses an index scan for the
>specified table
>Этот хинт даст просто index full scan, и не полезет в таблицу,
>если все колонки уже есть в индексе (это очевидно)
>И результат будет точно в порядке индекса (т.е. как при index_desc)
Индекс всегда читается по одному блоку, в то время как full table scan
использует многоблочное чтение, и это может оказаться быстрее. Fast full
index scan использует многоблочное чтение индекса, т.е. сочетает
преимущества индекса и full table scan. Если надо выбрать все строки, и все
столбцы входят в индекс, то для этого случая лучше всего fast full index
scan.
>Очевидно, после
>alter index ... rebuild;
>все листья будут упорядочены и результат будет тот же что и у
>/*+ INDEX(table index) */ , только быстрее, т.к. "мы не лазим по
>дереву"!
Fast full index scan не гарантирует отсортированный результат.
Valeri Sorokine
Alex Malkovsky wrote:
>
> OKuka...@hotmail.com пишет в сообщении <7qhl5q$coo$1...@nnrp1.deja.com> ...
> >/*+ INDEX(table index) */ explicitly chooses an index scan for the
> >specified table
> >Этот хинт даст просто index full scan, и не полезет в таблицу,
> >если все колонки уже есть в индексе (это очевидно)
> >И результат будет точно в порядке индекса (т.е. как при index_desc)
>
> Индекс всегда читается по одному блоку, в то время как full table scan
> использует многоблочное чтение, и это может оказаться быстрее. Fast full
> index scan использует многоблочное чтение индекса, т.е. сочетает
> преимущества индекса и full table scan. Если надо выбрать все строки, и все
> столбцы входят в индекс, то для этого случая лучше всего fast full index
> scan.
>
> >Очевидно, после
> >alter index ... rebuild;
> >все листья будут упорядочены и результат будет тот же что и у
> >/*+ INDEX(table index) */ , только быстрее, т.к. "мы не лазим по
> >дереву"!
>
> Fast full index scan не гарантирует отсортированный результат.
А где можно поподробнее узнать про INDEX_FFS?
Спасибо.
> >
> >Для чего этот балаган?
> >Просто хинты можно использовать в подзапросах, а order by только в 8I
> >Мне пришлось использовать INDEX_FFS т.к. разница в скорости была почти в
> >6 раз...
--
Valeri Sorokine
ProSoft, Russia, Moscow, Information Systems Division
Phone: +7 (095) 234 0636 (6 lines) FAX: +7 (095) 234 0640
E-mail: vsor...@dd.ru OR vsor...@prosoft.ru
http://www.dd.ru
Anton Nozdrin
>
> Hi Alex!
>
> Alex Malkovsky wrote:
> >
> > OKuka...@hotmail.com пишет в сообщении <7qhl5q$coo$1...@nnrp1.deja.com> ...
> > >/*+ INDEX(table index) */ explicitly chooses an index scan for the
> > >specified table
> > >Этот хинт даст просто index full scan, и не полезет в таблицу,
> > >если все колонки уже есть в индексе (это очевидно)
> > >И результат будет точно в порядке индекса (т.е. как при index_desc)
> >
> > Индекс всегда читается по одному блоку, в то время как full table scan
> > использует многоблочное чтение, и это может оказаться быстрее. Fast full
> > index scan использует многоблочное чтение индекса, т.е. сочетает
> > преимущества индекса и full table scan. Если надо выбрать все строки, и все
> > столбцы входят в индекс, то для этого случая лучше всего fast full index
> > scan.
> >
> > >Очевидно, после
> > >alter index ... rebuild;
> > >все листья будут упорядочены и результат будет тот же что и у
> > >/*+ INDEX(table index) */ , только быстрее, т.к. "мы не лазим по
> > >дереву"!
> >
> > Fast full index scan не гарантирует отсортированный результат.
>
> А где можно поподробнее узнать про INDEX_FFS?
>
> Спасибо.
>
может, поможет... http://www.oracle.com/oramag/oracle/98-Jul/dba.html
--
Dr. Anton A. Nozdrin
SIE NAMIP [AN1883]
Valeri Sorokine
Anton Nozdrin wrote:
>
> Valeri Sorokine wrote:
> >
<skip>
> > > Fast full index scan не гарантирует отсортированный результат.
> >
> > А где можно поподробнее узнать про INDEX_FFS?
> >
> > Спасибо.
> >
>
> может, поможет... http://www.oracle.com/oramag/oracle/98-Jul/dba.html
Классно! Спасибо за статью!
А может еще где подробно описана работа с различными типами индексов?
> --
> Dr. Anton A. Nozdrin
> SIE NAMIP [AN1883]
--
OKuka...@hotmail.com
"Alex Malkovsky" <al...@vrn.sterling.ru> wrote:
>
> OKuka...@hotmail.com пишет в сообщении <7qhl5q$coo$1...@nnrp1.deja.com>
...
> >/*+ INDEX(table index) */ explicitly chooses an index scan for the
> >specified table
> >Этот хинт даст просто index full scan, и не полезет в таблицу,
> >если все колонки уже есть в индексе (это очевидно)
> >И результат будет точно в порядке индекса (т.е. как при index_desc)
>
> Индекс всегда читается по одному блоку, в то время как full table scan
> использует многоблочное чтение, и это может оказаться быстрее. Fast
full
> index scan использует многоблочное чтение индекса, т.е. сочетает
> преимущества индекса и full table scan. Если надо выбрать все строки,
и все
> столбцы входят в индекс, то для этого случая лучше всего fast full
index
> scan.
Огромные спасибы Alex Malkovsky и особенно Dr. Anton A. Nozdrin за URL
http://www.oracle.com/oramag/oracle/98-Jul/dba.html
отличная статья объясняет все абсолютно, кроме одного, см. ниже:
> >Очевидно, после
> >alter index ... rebuild;
> >все листья будут упорядочены и результат будет тот же что и у
> >/*+ INDEX(table index) */ , только быстрее, т.к. "мы не лазим по
> >дереву"!
> Fast full index scan не гарантирует отсортированный результат.
Т.е. даже после alter index ... rebuild _ПО ИДЕЕ_
отсортированный результат не гарантируется?
Или как раз rebuild и выстраивает все блоки "по порядку"?
OKuka...@hotmail.com
OKuka...@hotmail.com wrote:
> Могу кинуть скрипт, если кого интересует, как все это выглядит "в
> натуре" :-)
rem This script create table Test_index_ffs in scott/tiger schema
rem with two fields Id integer and Name varchar(50)
rem and populate it with data
rem insert into test_index_ffs values(1, 'AAA');
rem insert into test_index_ffs values(1, 'BAA');
rem insert into test_index_ffs values(1, 'CAA');
rem ...
rem insert into test_index_ffs values(1, 'ZZE');
rem
rem There is an index index Ak_test_index_ffs on Test_index_ffs(Name,
Id)
rem And it is used select with index_ffs hint
rem Results are stored in files before_rebuild.txt and after_rebuild.txt
rem
rem your database ->vvvvv
connect scott/tiger@devdb
drop table Test_index_ffs;
create table Test_index_ffs(
Id integer not null
constraint Pk_test_index_ffs primary key,
Name varchar(50)
) pctfree 0;
create index Ak_test_index_ffs on Test_index_ffs(Name, Id) pctfree 0;
-- This value should be last
insert into test_index_ffs values(-2, 'ZZZZ');
-- This value should be first
insert into test_index_ffs values(-1, 'AA');
commit;
-- perform bulk insert
declare
V_Id Test_index_ffs.Id%Type := 0;
V_Name Test_index_ffs.Name%Type;
begin
for a in ASCII('A')..ASCII('Z') loop
for b in ASCII('A')..ASCII('Z') loop
for c in ASCII('A')..ASCII('Z') loop
-- for d in ASCII('A')..ASCII('Z') loop
-- V_Name := CHR(d) || CHR(c) || CHR(b) || CHR(a);
V_Name := CHR(c) || CHR(b) || CHR(a);
insert into test_index_ffs values(V_Id, V_Name);
V_Id := V_Id + 1;
-- end loop;
end loop;
end loop;
end loop;
end;
/
commit;
set termout off
set echo on
/* Do each select twice */
select /*+ index_ffs(test_index_ffs ak_test_index_ffs) */
ID, Name
from Test_index_ffs;
set timing on
spool before_rebuild_ffs.txt
select /*+ index_ffs(test_index_ffs ak_test_index_ffs) */
ID, Name
from Test_index_ffs;
/* Line with Name = 'ZZZZ' should be last, but it is not */
spool off
select /*+ index(test_index_ffs ak_test_index_ffs) */
ID, Name
from Test_index_ffs;
spool before_rebuild.txt
select /*+ index(test_index_ffs ak_test_index_ffs) */
ID, Name
from Test_index_ffs;
/* Line with Name = 'ZZZZ' is last */
spool off
alter index Ak_test_index_ffs rebuild;
select /*+ index_ffs(test_index_ffs ak_test_index_ffs) */
ID, Name
from Test_index_ffs;
spool after_rebuild_ffs.txt
select /*+ index_ffs(test_index_ffs ak_test_index_ffs) */
ID, Name
from Test_index_ffs;
/* After index was rebuilded, line with Name = 'ZZZZ' become last */
spool off
select /*+ index(test_index_ffs ak_test_index_ffs) */
ID, Name
from Test_index_ffs;
spool after_rebuild.txt
select /*+ index(test_index_ffs ak_test_index_ffs) */
ID, Name
from Test_index_ffs;
spool off
exit
Dmitri Blinov
> > >Очевидно, после
> > >alter index ... rebuild;
> > >все листья будут упорядочены и результат будет тот же что и у
> > >/*+ INDEX(table index) */ , только быстрее, т.к. "мы не лазим по
> > >дереву"!
> > Fast full index scan не гарантирует отсортированный результат.
> Т.е. даже после alter index ... rebuild _ПО ИДЕЕ_
> отсортированный результат не гарантируется?
> Или как раз rebuild и выстраивает все блоки "по порядку"?
Rebuild их может и выстраивает, но если еще кто-то
в этот момент с этим индексом что-то делает ?
То есть я хочу сказать, что между ALTER INDEX и SELECT существует
некий промежуток времени, в который что угодно может произойти.
Дмитрий.
OKuka...@hotmail.com
(накапливаем данные на одном сервере и реплицируем ночью на др.)
а потом сразу делаем rebuild всех нужных index-ов
OK
>
> Дмитрий.
Mikhail Elashkin
> > может, поможет... http://www.oracle.com/oramag/oracle/98-Jul/dba.html
> Классно! Спасибо за статью!
> А может еще где подробно описана работа с различными типами индексов?
Один из любителей этой темы Сергей Мосин, но он теперь это только за деньги
т.к. работает в Oracle тех. поддержке :)
Второй, кого я знаю, Виталий Сиколенко - в США теперь. Может Юринский чего
порекомендует.
--
WBR
Mikhail Elashkin
Marketing Manager, Oracle Russia
*************************************************************************
Ph. +7(095) 721-3235
Mob. +7(095) 761-8007
Fax +7(095) 258-4190
Oracle CIS +7(095) 258-4180
e-mail mela...@ru.oracle.com
*************************************************************************
"In theory there is no difference between theory and practice. In practice
there is"
Yogi Berra