Может ли растровое изображение слияния оракула во время быстрого полного сканирования?

Question

У меня есть большая таблица фактов с 300-миллиметровыми рядами и 50 столбцами. В этой таблице есть несколько отчетов, и каждый отчет использует только пару из 50 столбцов из таблицы.

Каждый столбец в таблице фактов индексируется BITMAP INDEX. Идея состоит в том, чтобы использовать эти индексы как одностолбцовую версию исходной таблицы, предполагая, что оракул может легко объединить BITMAP INDEX.

Если я использую несколько столбцов из таблицы в инструкции WHERE, я вижу, что оракул может эффективно объединить эти индексы. Существует BITMAP AND операции в плане выполнения, как ожидалось.

Если я использую несколько столбцов из таблицы в SELECT заявления, я могу видеть, что в зависимости от столбцов селективности, оракул либо выполнить ненужный TABLE ACCESS или BITMAP CONVERSION [to rowids], а затем HASH JOIN этих преобразований.

Есть ли способ устранить HASH JOIN в случае присоединения нескольких BITMAP INDEX es? Есть ли намек на оракул, чтобы заставить BITMAP MERGE, когда столбцы отображаются в SELECT, а не WHERE?

Наглядно это кажется как HASH JOIN для BITMAP INDEX хся ненужная операции в SELECT заявлении, принимая во внимание, что на самом деле не нужно в WHERE заявления. Но я не мог найти никаких доказательств того, что оракул может это избежать.

Вот некоторые примеры:

SELECT a, b, c /* 3 BITMAP CONVERSIONs [to rowids] and then 2 unneeded HASH JOINS */ 
    FROM fact; 

SELECT a, b, c, d, e /* TABLE ACCESS [full] instead of reading all the data from indexes */ 
    FROM fact; 

SELECT a /* BITMAP INDEX [fast full scan] as expected*/ 
    FROM fact 
    WHERE b = 1 and c = 2; /* BITMAP AND over two BITMAP INDEX [single value] as expected */ 

Есть ли какие-либо намеки оптимизировать примеры # 1 и # 2?

В производстве я использую oracle11g, но я пробовал подобные запросы на oracle12c, и это похоже, что в обеих версиях oracle ведут себя одинаково.

Answer 1

После некоторого исследования похоже, что oracle12c не может соединяться с BITMAP INDEX es, если они используются в статье SELECT эффективно.

В этом случае нет выделенного пути доступа, чтобы присоединиться к BITMAP INDEX es в пункте SELECT, и поэтому в этом случае используется HASH JOIN.

Oracle не может использовать BITMAP MERGE путь доступа в этом случае он выполняет операцию OR между двумя точечными изображениями:

Как Bitmap Merge Работает Слияние использует OR операцию между двумя точечными изображениями. Полученная растровая карта выбирает все строки из первого растрового изображения, плюс все строки из каждого последующего растрового изображения.

Подробный анализ показал, что только HASH JOIN был рассмотрен оптимизатором затрат в моем случае. Я не смог найти никаких доказательств того, что BITMAP INDEX es может эффективно использоваться в заявлении SELECT. Oracle documentation предлагает использовать BITMAP INDEX es только в WHERE оговорка относительно размеров.

И одно из следующих условий:

• индексированного столбца будет ограничен в запросах (упоминаемых в статье о WHERE).

или

• индексированный столбец внешний ключ для таблицы измерений. В этом случае такой индекс скорее сделает преобразование звезды.

В моем случае это не одно из двух.

Answer 2

Я думаю, что вы видите по существу «путь доступа к индексу» в действии :) Oracle необходимо объединить данные из обоих сканов на ROWID, чтобы сшить строки вместе. Хеш-соединение - единственный метод, открытый для Oracle. Тот факт, что вы используете растровые индексы, фактически не имеет значения; вы видите такое же поведение с индексами b-tree

------------------------------------------------------------------------------------------- 
| Id | Operation    | Name    | Rows | Bytes | Cost (%CPU)| Time  | 
------------------------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT  |     | 1973K| 43M| 137K (30)| 00:00:06 | 
| 1 | VIEW     | index$_join$_001 | 1973K| 43M| 137K (30)| 00:00:06 | 
|* 2 | HASH JOIN   |     |  |  |   |   | 
|* 3 | INDEX FAST FULL SCAN| IO    | 1973K| 43M| 17201 (78)| 00:00:01 | 
|* 4 | INDEX FAST FULL SCAN| IT    | 1973K| 43M| 17201 (78)| 00:00:01 | 
-------------------------------------------------------------------------------------------