Тюнинг индексов.

← →
Тих (2003-06-27 01:16) [0]

Проблема интересная.
Итак,

в MS SQL 2000 имеется некая таблица на 15 млн записей. 4 поля типа uniqueidentifier not null. На первые три поля повешены неуникальные индексы. Кластерных индексов нет.

в Oracle имеем такую же таблицу, поля типа raw(16) not null (конвертированные GUIDы, с учетом перестановки байт; короче -полный аналог), индексы те же самые на тех же полях, кроме того, таблица сделана индексно-организованной (Oracle 9i), primary key составлен из первых трех полей.

Производим по, например, первому полю в MS SQL запрос навроде
select * from LARGETABLE where FIELD1 = "{гуид-заведомо-в-этом-столбце-отсутствующий}"

Время выполнения - менее секунды.

Тот же самый запрос в ORACLE выполняется от полутора минут (без хинтов) до 30 секунд (если вставить хинт parallel), притом, несмотря на все расписанные в документации прелести B*деревьев, производится fast full index scan.

Если такой гуид (т.е. конвертированный гуид) в этом столбце есть, время поиска сокращается до 3-10 секунд, но один черт, ищется ЗНАЧИТЕЛЬНО медленней, чем в MS SQL.

Применены оптимизации: 1) хинт parallel 2) вынос индекса в другой tablespace 3) опция индекса KEEP 4) увеличение SGA и PGA

Не помогает. Как бороть?

← →
Тих (2003-06-27 01:29) [1]

вынести индексы на отдельный диск просьба не предлагать :-)

← →
sniknik © (2003-06-27 08:45) [2]

а что значит "конвертированные GUIDы"? в MSSQL они тоже конвертированы? и на ккком этапе происходит конвертация?

я к чему, индексы не работают когда есть преобразования в условии поля по которому сравнение. может твой случай?
(просто предположение, ORACLE не знаю т.что :о( )

← →
Тих (2003-06-27 10:23) [3]

Гуиды в MS SQL обычные, а в Oracle представлены как массив[16] байт (raw(16)), импорт произведен bcp + sqlldr c нек. особенностями (переставлены байты) но это не суть важно.
Запрос в MS SQL выглядит как
select * from LARGETABLE where field1 = "aabbccdd-aabb-aabb-aabb-aabbccddeeff"

в оракле

select * from LARGETABLE where field1 = "ddccbbaabbaabbaaaabbaabbccddeeff" --поправка на фактическое побайтовое представление гуида (см. MSDN, структуру GUID, OLE DB binding)

т.е. в теле запроса преобразований не делается.

← →
roottim (2003-06-27 10:42) [4]

raw
это битовое поле...
вообще обычные индексы помоему на нем не особо и работали...
1. создайте поле varchar2(16)с индексирование
2. используйте битовый индекс.. хотя сам я его никогда не использовал

← →
Тих (2003-06-27 12:56) [5]

от varchar2 и char - Отказались, выходило еще медленней.

← →
sniknik © (2003-06-27 13:05) [6]

а в структуру переделать, можно? или достаточно длинный тип чтобы все влезло и индексы были
TGUID = packed record
D1: LongWord;
D2: Word;
D3: Word;
D4: array[0..7] of Byte;
end;
ечть там число из 16 байт?
может это и бредовая идея, и странно что ORACLE не поддерживает его(guid) индексацию, может не так делается?

← →
roottim (2003-06-27 13:08) [7]

с таким объемом сталкиваться не приходилось конечно...
спросика у Sir -а на форуме http://www.oraсlub.ru

← →
Alexey Dubovsky (2003-06-27 14:01) [8]

я думаю вот в чём дело - тут замешана статистика.
либо включи опцию (*+ RULE*) (отключить выбор по статистике), либо обнови статистику

← →
Тих (2003-06-27 15:15) [9]

Rule включена, COMPUTE STATISTICS выполняем периодически, эдак раз по десять на дню.
Всем спасибо, пойду ораклуб донимать )

> 1) хинт parallel
опасно, на более слабой технике можно вообще ответа на запрос не дождаться, лучше указать parallel при создании таблицы
> 3) опция индекса KEEP
ну будет он дольше db block buffer`е сидеть, а fast full index ( так же как и table ) scan его не использует, а гонит блоки через особые буфера в PGA
> 4) увеличение SGA и PGA
??? это как? :) SGA=big и PGA=large? :)
alter system set __application_work_fast не пробовали? :)

Телепатическими способностями не обладаю, но варианты могут быть следующие:
hint /*+ FIRST_ROWS */
index_cost_adj - поменьше ( но до нуля не догоняйте :)
db_multiblock_read_count - поменьше

вообще при элементе индекса в 48 байт ( при максимальных 64 ) CBO вполне может прийти в некотрое смущение. Возможно, неуникальный индекс по 1 или 2 первым полям будет даже лучше

> ...время поиска сокращается до 3-10 секунд
Совершенно резонно - при full index scan, чтоб убедиться, значения в индексе нет, надо просмотреть его весь, а если оно нашлось, то, зная, что индекс уникальный, дальнейший просмотр блоков можно прекратить

Тюнинг индексов. Найти похожие ветки