рекомендация для долгосрочного запроса

Question

У нас есть простой запрос, который работает навсегда. Могу сказать более 10 часов. Таблица фактов имеет более 17 миллиардов строк. Любые рекомендации или рекомендации по улучшению производительности запросов?

SELECT 
    /*+ parallel(f 4) */ 
    F.DM_CUSTOMER_DKEY, 
    P.PRODUCT_YEAR, 
    SUM(F.ADVG_COST_ACTUALS) advg_cost_actuals 
FROM DM_CUST_RENEWAL_ADV_FACT F 
INNER JOIN DM_PRODUCT_HIERARCHY p 
ON F.DM_PRODUCT_HKEY = P.DM_PRODUCT_HKEY 
GROUP BY F.DM_CUSTOMER_DKEY, 
    P.PRODUCT_YEAR 
ORDER BY P.PRODUCT_YEAR 

Вот план

OPERATION OBJECT_NAME OPTIONS COST PARTITION_START PARTITION_STOP 
SELECT STATEMENT 10931402 
PX COORDINATOR 
PX SEND :TQ10005 QC (ORDER) 10931402 
SORT ORDER BY 10931402 
PX RECEIVE 10931402 
PX SEND :TQ10004 RANGE 10931402 
SORT GROUP BY 10931402 
PX RECEIVE 10931402 
PX SEND :TQ10003 HASH 10931402 
SORT GROUP BY 10931402 
HASH JOIN 1964410 
Access Predicates 
F.DM_PRODUCT_HKEY=P.DM_PRODUCT_HKEY 
PX RECEIVE 335 
PX SEND :TQ10002 BROADCAST 335 
VIEW index$_join$_002 335 
HASH JOIN BUFFERED 
Access Predicates 
ROWID=ROWID 
PX RECEIVE 136 
PX SEND :TQ10000 HASH 136 
PX 
BLOCK 
ITERATOR 136 
INDEX DM_PRODUCT_HIERARCHY_PK FAST FULL 
SCAN 
136 
PX RECEIVE 280 
PX SEND :TQ10001 HASH 280 
PX 
BLOCK 
ITERATOR 280 
INDEX DM_PRODUCT_HIERARCHY_LPK FAST FULL 
SCAN 
280 
PX BLOCK ITERATOR 1878718 1 369 
TABLE ACCESS DM_CUST_RENEWAL_ADV_FACT FULL 1878718 1 369 

Answer 1

Как уже было сказано, попытайтесь правильно индексировать таблицу. . Я полагаю, что этот раздел http://docs.oracle.com/cd/B10501_01/server.920/a96524/c12parti.htm

раздел его либо F.DM_CUSTOMER_DKEY или P.PRODUCT_YEAR, либо оба из них. Или, по крайней мере, вы можете поместить инструкцию where to shrink product_year или так и запустить несколько запросов

Answer 2

Я предполагаю, что таблица DM_PRODUCT_HIERARCHY достаточно мала, чтобы вставлять ее в память во время выполнения запроса. В этом случае предпочтительнее хеш-соединение, и вам не нужен индекс. Вы можете попробовать подсказку NO_INDEX, возможно, вместе с подсказкой USE_HASH.

Вы группируете результат по DM_CUSTOMER_DKEY из очень большой таблицы фактов. Разделение таблицы фактов на этот атрибут, скорее всего, значительно улучшит производительность.

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

Чтобы получить представление о «наилучшем» времени выполнения, вы должны измерить время полного сканирования таблицы в своей таблице фактов. Убедитесь, что вы подсчитали столбец (COLUMN_X в образце), который не имеет индекса, иначе вы будете измерять время сканирования индекса вместо таблицы.

SELECT count(COLUMN_X) from DM_CUST_RENEWAL_ADV_FACT;