Как увеличить оракула запрос, когда 22 000 000 записей в одной таблице?

Question

У меня установлен Oracle 10g на Windows Server 2003. У меня 22 000 000 записей в одной таблице, и это транзакционная таблица,
увеличение записей в одной таблице ок. 50 000 в месяц.

Мой вопрос заключается в том, что всякий раз, когда я запускаю запрос к нему, мой запрос всегда выполняется слишком медленно. Есть ли какой-нибудь метод, с помощью которого я могу улучшить производительность запроса, например, разбиение таблицы или что-то еще?

запрос

select a.prd_code
       , a.br_code||'-'||br_title
       , a.size_code||'-'||size_title
       ,size_in_gms
       , a.var_code||'-'||var_title
      , a.form_code||'-'||form_title
      , a.pack_code||'-'||pack_title
      , a.pack_type_code||'-'||pack_type_title
      , start_date
      , end_date
      , a.price
from   prices a
       , brand br
       ,  (select distinct prd_code
                 , br_code
                 ,  size_code
                 , var_code
                 , form_code
                 ,packing_code
                 ,  pack_type_code 
            from cphistory 
            where prd_code = '01' 
            and flag = 'Y'  
            and project_yy = '2009' and '01' and '10') cp
       , (select prd_code
                , br_code
                , size_code
                , size_in_gms
          from sizes 
          where prd_code = '01' 
          and end_date = '31-dec-2050' 
          and flag = 'Y') sz
        ,  (select prd_code
                   , br_code
                   , var_code
                   , var_title 
              from varient) vt
          , (select prd_code
                    , br_code
                    , form_code
                    , form_title 
             from form) fm
          ,  (select prd_code
                     , pack_title 
               from package) pc
          ,    (select prd_code
                       , pack_type_title
                 from pakck_type) pt
where a.prd_code = br.prd_code 
and   a.br_code  = br_br_code
and   a.prd_code = sz.prd_code
and   a.br_code  = sz.br_code
and   a.size_code = sz.size_code
and   a.prd_code  = vt.prd_code
and   a.br_code   = vt.br_code
and   a.var_code  = vt.var_code
and   a.prd_code  = fm.prd_code
and   a.br_code   = fm.br_code
and   a.form_code = fm.form_code
and   a.prd_code  = pc.prd_code
and   a.br_code   = pc.br_code
and   a.pack_code = pc.pack_code
and   a.prd_code  = pt.prd_code
and   a.pack_type_code = pt.pack_type_code
and   end_date = '2009'
and   prd_code = '01'
order by a.prd_code
         , a.br_code
         , a.size_code
         , a.var_code
         , a.pack_code
         , a.form_code

таблиц, используемых в этом запросе:

prices    : has more than 2.1M rows
cphistory : has more than 2.2M rows
sizes     : has more than 5000 rows
brand     : has more than 1200 rows
varient   : has more than 1800 rows
package   : has more than 200 rows
pack_type : has more than 150 rows

Answer 1

1. Проверка индексов. Убедитесь, что у вас есть первичный ключ. Альтернативные ключи-кандидаты должны иметь уникальные ограничения и индексы.
2. Запустите EXPLAIN PLAN для запросов и посмотрите, как их выполняет оптимизатор. Если вы видите TABLE SCAN, добавьте индексы.
3. Убедитесь, что оптимизатор использует статистику для облегчения своей работы.
4. Перемещение исторических данных в хранилища, если необходимо.

22M записей не так уж и много.

Answer 2

Возможно, вам следует начать с объяснения планов, но сделайте следующее:

1. Возьмите каждый из запросов в «ОТ» предложение и сделать объяснение план на каждого. Убедитесь, что каждый каждый поражает соответствующий индекс. Если нет, то добавьте индексы для каждого из их так, чтобы каждый из подзапросов это быстро.
2. (только если возвращается много данных) Возьмите заказ от основного запрос и запустить его. Посмотрите, если это намного быстрее Если это так, то ваше время тратится на сортировку данных и вам нужно выяснить, почему вы имеют медленную сортировку.
3. Вытащить подзапросы. «В.Т.», «fm», «pc» и «pt» принимают целые таблицы в подзапросах. Когда я проверяю с этим положить в Подобные подзапросы вызывают 10g пропустить индексы на столе полностью. Просто поставь столы в от и оракула индексы использования оптимизатора.
4. Попробуйте сложить по всем критериям на "cp" и "sz" в основной запрос и удалите подзапросы и посмотрите если это имеет значение.

Много-много планов объяснений и более чем осторожно. Хотел бы я помочь больше.

Answer 3

Почему запросы медленные? Они делают сканы на большом столе? Обычно OLTP-запросы выбирают относительно небольшое количество строк на основе первичного ключа или другого индексированного столбца. Если в ваших запросах не используются индексы, и они являются типичным видом запросов OLTP, которые выиграют от использования индексов, это будет место для начала.

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