Разликата е, че събирането на статистика опреснява метаданните за текущия индекс, докато премахването и повторното създаване на индекса е, ъъъъ, премахване и повторно създаване на индекса.
Може би е лесно да се разбере разликата с работещ пример. И така, нека създадем таблица и индекс:
SQL> create table t23
2 as select object_id as id, object_name as name from user_objects
3 /
Table created.
SQL> create index i23 on t23(id)
2 /
Index created.
SQL> select o.object_id, i.last_analyzed, i.distinct_keys
2 from user_objects o
3 join user_indexes i
4 on (i.index_name = o.object_name)
5 where o.object_type = 'INDEX'
6 and i.index_name = 'I23'
7 /
OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS
---------- -------------------- -------------------- -------------
116353 23-NOV-2013 00:15:39 23-NOV-2013 00:15:39 167
1 row selected.
SQL>
От 11g Oracle автоматично събира статистика, когато създаваме индекс. Така че създаването на индекс и последният анализ показват една и съща дата и час. В предишни версии трябваше изрично да събираме статистически данни, след като създадохме индекса. Научете повече .
След това ще добавим някои данни и ще опресним статистиката:
SQL> insert into t23 values (9999, 'TEST1')
2 /
1 row created.
SQL> insert into t23 values (-8888, 'TEST 2')
2 /
1 row created.
SQL> exec dbms_stats.gather_index_stats(user, 'I23')
PL/SQL procedure successfully completed.
SQL> select o.object_id, i.last_analyzed, i.distinct_keys
2 from user_objects o
3 join user_indexes i
4 on (i.index_name = o.object_name)
5 where o.object_type = 'INDEX'
6 and i.index_name = 'I23'
7 /
OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS
---------- -------------------- -------------------- -------------
116353 23-NOV-2013 00:15:39 23-NOV-2013 00:26:28 169
1 row selected.
SQL>
Сега метаданните, свързани със статистиката, са променени, но индексът е същият обект на база данни. Докато ако изпуснем и създадем отново индекса, получаваме нов обект на база данни:
SQL> drop index i23
2 /
Index dropped.
SQL> create index i23 on t23(id)
2 /
Index created.
SQL> select o.object_id, i.last_analyzed, i.distinct_keys
2 from user_objects o
3 join user_indexes i
4 on (i.index_name = o.object_name)
5 where o.object_type = 'INDEX'
6 and i.index_name = 'I23'
7 /
OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS
---------- -------------------- -------------------- -------------
116354 23-NOV-2013 00:27:50 23-NOV-2013 00:27:50 169
1 row selected.
SQL>
При нормални операции почти никога не се налага да премахваме и създаваме отново индекс. Това е техника, която понякога е подходяща при зареждане на много големи количества данни и в много редки случаи на повреда на индекса. Интеруебовете все още извеждат сайтове, които препоръчват редовно възстановяване на индексите от съображения за производителност (твърди се, че „ребалансират“ изкривените индекси), но тези сайтове не създават показателите за доказване на дългосрочните ползи и със сигурност никога не включват времето и Циклите на процесора са пропилени от упражнението за повторно изграждане.
Повторното изграждане на индекс изисква повече работа, отколкото опресняването на статистиката. Очевидно е вярно, защото възстановяването включва събиране на статистика като подзадача. Въпросът е дали е по-ефективно да се предприеме масово DML срещу таблица с нейните индекси на място в сравнение с премахването на индексите и повторното им създаване след това. Може да бъде по-бързо да заредите данни в таблица без индекси и да ги създадете отново след това.
Тук няма твърдо правило:зависи от това колко индекса имате, съотношението на засегнатите редове спрямо целия размер на таблицата, дали имате нужда от индексите, за да наложите ограничения за релационна цялост и т.н. Има и голяма разлика между операциите:може да искате да премахнете индекси за групови вмъквания, но да ги запазите за актуализации, в зависимост от това какви индекси са ви необходими за вашата клауза WHERE и дали актуализацията засяга индексираните колони.
Накратко, трябва да сравните вашия собствен специфичен сценарий. Това често е отговорът, когато става дума за въпроси относно ефективността.
