Оптимизируйте SELECT из секционированной таблицы фактов в Oracle 10

Question

У меня есть таблица фактов, содержащая 8 миллионов строк с увеличением на 1 миллион строк в месяц.Таблица уже содержит индексы по ней.Таблица используется средой IBM Cognos для генерации отчетов.В настоящее время я ищу способ оптимизации таблицы операторов SELECT.

При первой попытке я разделил таблицу (каждый раздел имеет одинаковое распределение строк), и запрос подходит для разделов, но по какой-то причине я получаю равную или даже худшую производительность, что странно.На один запрос влияет только один раздел.Может кто-нибудь объяснить, как это оптимизировать?

Вторая идея, к которой я пришел, заключается в реализации таблицы фактов в виде таблицы, организованной по индексу, но она должна иметь все столбцы в качестве первичного ключа.Это нормально, и будет ли повышение производительности?

Третья идея - реализовать таблицу фактов таким образом, чтобы она содержала все столбцы, объединенные из звездообразной схемы.Будет ли повышение производительности?

РЕДАКТИРОВАТЬ: Вот план выполнения:

Мне удалось сократить время доступа к таблице фактов FT_COSTS в 3 раза (стоимость 42000, сейчас14900) ПОСЛЕ того, как я создал индексы, содержащие критерии разделения, но до этого у меня были худшие результаты, чем в неразмеченной таблице.Я использовал эту ссылку, чтобы решить мою проблему с разделами Проверка пропуска разделов диапазона

Из того, что я вижу сейчас, основным узким местом является GROUP BY, который увеличивает стоимость с 34000 до 85 000, чтоболее чем вдвое.У кого-нибудь есть идеи по поводу этого?

Answer 1

Что такое GROUP BY на самом деле GROUP BY?

В плане объяснения указывается, что в хеш-соединении содержится 1238320 строк, входящих в GROUP BY, и такое же число, выходящее из SELECT верхнего уровня.Это говорит о том, что оптимизатор на самом деле не верит в то, что вы будете выполнять здесь реальную агрегацию.

Answer 2

Для уменьшения стоимости группы обычно требуется создание pe-вычисленных агрегатов, обычно путем создания одного или нескольких материализованных представлений.

Answer 3

Обрезка перегородок может быть сложной задачей.

Есть ли у вас ОБЪЯСНЕННЫЙ ПЛАН вашего запроса?Это показывает PARTITION RANGE SINGLE?Если это не так, то запрос игнорирует раздел.Если это так, то у вас есть другая проблема.

Мои деньги находятся в первой из этих веток: физическое разбиение переупорядочивает таблицу.Это означает, что планы выполнения, которые не соответствуют стратегии разделения, могут выполняться хуже, чем в случае неразделенной таблицы.

Чтобы продолжить это, нам нужно увидеть некоторые детали.По крайней мере, предложение разделения для вашей таблицы и части запроса, которую вы говорите, подходит для этого подхода.ПЛАН ОБЪЯСНЕНИЯ также был бы очень полезен.Чем больше деталей вы нам дадите, тем лучше: настройка - это все особенности, потому что каждый случай особенный.

---

«Не могли бы вы объяснить, почему стоимость группы по так высока и как ее можно уменьшить?»

GROUP BY означает сортировку.Это может быть дорого, если у вас много данных, потому что это требует памяти - или записи на диск - и циклов ЦП.

Что касается снижения затрат, то немного сложно дать совет по запросу, которого я не видел.Я могу сказать следующее: запросы занимают время, а запросы, которые используют много данных, занимают больше времени.Секрет настройки заключается в том, чтобы понять, сколько времени занимает определенный запрос.Стоимость не имеет значения, если запрос выполняется достаточно быстро .

Answer 4

Если вы видите в конце плана выполнения, это показывает, что к таблице FT_COSTS обращаются полностью (доступ к таблице полный).поскольку он полностью доступен, во всех соединениях, которые вы добавили, просто добавляются данные, и, наконец, стоимость кажется большой.Я предлагаю поставить соответствующий индекс для таблицы, чтобы он ссылался на индекс, а не на всю таблицу, чтобы получить доступ к данным, а затем увидеть резкое изменение вашей производительности !!!!!