Улучшение производительности SELECT и UPDATE

Я попытаюсь объяснить свою проблему, так как я не использую SQL напрямую.

Я использую инструмент INFORMATICA с помощью сопоставлений, которые обрабатывают данные SQL, поэтому я попытаюсь объяснить логику, которую моя карта выполняет в SQL.

Моя карта в основном выбирает данные из SCD (медленно меняющееся измерение), где start_date = sysdate и ind = 1 (в этой таблице примерно 600 миллионов записей), используя этот запрос:

SELECT table.ACCOUNT_NUMBER, table.SUB_ACCOUNT_NUMBER, table.SUB_ACCOUNT_KEY 
FROM table
WHERE table.CURR_IND=1
  AND table.START_DATE=trunc(sysdate)

Эта таблица индексируется следующим образом:

SUB_ACCOUNT_KEY - UNIQUE

Затем добавьте еще один столбец и обновите другую таблицу, содержащую примерно 8 миллионов записей. Запрос этого, вероятно, обновляется с помощью соединения

SET table2.ind =The_New_Column,table_2.sub_account_key = table1.sub_account_key
WHERE Table.account_number = Table_2.account_number
  AND table.sub_account_number = table_2.sub_account_number

Эта таблица_2 индексируется следующим образом:

(ACCOUNT_NUMBER, SUB_ACCOUNT_NUMBER) - UNIQUE

И выбор, и обновление требуют некоторого времени для обработки в зависимости от объема данных, которые я получаю каждый день (у нас есть 1 день каждые три месяца, когда объем данных составляет около X30 обычного дня, что занимает вечность... около 2 часов)

Итак, мой вопрос: как я могу ускорить этот процесс, имея следующее ограничение:

Я не могу (без веской причины) добавить индекс к таблицам, так как он используется во многих других процессах и может снизить их производительность


person sagi    schedule 14.02.2016    source источник
comment
Если вы не можете создавать индексы или разбивать запрашиваемые таблицы, это кажется очень сложной задачей. Обратите внимание, что индекс в таблице, из которой вы делаете запрос, бесполезен, поскольку вы не используете столбец в качестве фильтра. Индексы в таблице 2 должны ускорить ваше обновление, но при попытке обрабатывать тома, о которых вы упоминаете, лучше всего использовать секционирование.   -  person Yaron Idan    schedule 14.02.2016
comment
Я с @Yaron здесь - большую часть времени вещи с изменяющимися измерениями по своей природе отчетные базы данных, и вам нужно столько индексов, сколько позволяет пространство для хранения. Индексы снижают производительность только при большом количестве обновлений или вставок данных (поэтому их иногда отключают для перестроения анализа), что обычно происходит в повседневных транзакционных базах данных. Даже в этом случае это баланс между результирующей ограниченной скоростью обновлений (возможно, меньше, чем вы думаете) и полезностью таблицы.   -  person Clockwork-Muse    schedule 14.02.2016


Ответы (2)


предложение 1: создать индекс на основе функции:

CREATE INDEX index_name
          ON table (TRUNC(START_DATE));

как вы упомянули, это может быть невозможно, потому что вы не можете использовать индексы.

предложение 2: используйте МЕЖДУ:

SELECT table.ACCOUNT_NUMBER, table.SUB_ACCOUNT_NUMBER, table.SUB_ACCOUNT_KEY 
  FROM table
 WHERE table.CURR_IND=1
   AND table.START_DATE BETWEEN TO_DATE('2016.02.14 12:00:00 AM', 'YYYY.MM.DD HH:MI:SS AM') 
                            AND TO_DATE('2016.02.15 11:59:59 PM', 'YYYY.MM.DD HH:MI:SS PM');

(см. также http://oraclecoder.com/tutorials/quick-tip-do-not-use-trunc-to-filter-on-a-date-and-time-field--2120)

person mi_h    schedule 14.02.2016

По сути, это тот же вопрос, который вы задали в разделе «получить формат текущей даты». Вам либо придется изменить свой sql, либо использовать индекс на основе функций. Да, индексы могут вызвать некоторые дополнительные накладные расходы на DML, но могут значительно улучшить SELECT. Как и во всех дизайнерских решениях, вы должны взвесить выгоду и стоимость и решить, что важнее.

person EdStevens    schedule 14.02.2016