Я новичок в этом сообществе, и я действительно искал этот вопрос. Извиняюсь, если я спрашиваю что-то, о чем спрашивали раньше.
Я работаю над хранилищем данных измерений с таблицами фактов и измерениями. Это база данных Oracle 12. Измерения имеют столбец суррогатного ключа, который также отображается в таблице фактов, а затем столбец с бизнес-значением, который отображается один в один с суррогатным ключом (вместе с другими столбцами атрибутов). Таблицы фактов имеют ряд внешних ключей, а затем несколько столбцов для агрегирования. Некоторые из этих внешних ключей имеют очень неравномерно распределенные данные, поэтому мы сгенерировали гистограммы для этих столбцов в таблице фактов, чтобы оптимизатор на основе затрат знал, когда в качестве критерия выбрано очень распространенное значение, что оно не будет очень избирательным. Например, мы используем значение измерения, которое «пустое» около 85% времени в наших данных фактов, но имеет 20000 различных значений для остальных 15% строк. У нас есть строка в нашей таблице измерений с суррогатным ключом, который представляет «пустое» для этого значения измерения, плюс строки для других 20 000 значений. Без гистограммы оптимизатор считает, что эти 20 000 значений распределены одинаково, поэтому он может сделать очень плохой выбор, если кто-то укажет пустое значение.
Это прекрасно работает, когда я запускаю запрос с критериями, указанными в нашей таблице фактов. Оптимизатор распознает статистику гистограммы и предоставляет оценки количества элементов, которые находятся на правильном этапе. Однако если я укажу критерии для бизнес-ключа на стороне измерения объединения, статистика не будет использоваться, и оценка количества элементов будет далека.
select *
from FACT
, DIM
where FACT.surrogate_key = DIM.surrogate_key
and DIM.surrogate_key = 0 -- (zero means blank)
Объясните план количественной оценки: 53 миллиона строк (примерно справа). Всего в таблице фактов около 65 миллионов строк, и около 53 миллионов из них представляют данные, в которых этот атрибут пуст.
Однако, если я отфильтрую по бизнес-ключу, что на самом деле делают пользователи, тогда оценка мощности будет далека.
select *
from FACT
, DIM
where FACT.surrogate_key = DIM.surrogate_key
and DIM.business_key = '(blank)'
Объясните оценку количества элементов плана: 14 000 строк (даже не близко)
Как заставить CBO использовать гистограмму, если критерии указаны в таблице измерений (а не в столбце соединения)?
Спасибо.