Создание материализованного представления, заполняющего все временное пространство

Я хочу создать материализованное представление (mv), см. SQL-запрос ниже. Когда я пытаюсь создать материализованное представление, мое временное табличное пространство полностью (~ 128 г) используется и приводится ниже ошибка Ошибка SQL: ORA-12801: сообщение об ошибке на сервере параллельных запросов P007 ORA-01652: невозможно расширить временный сегмент на 64 в табличном пространстве TEMP1 12801. 00000 - "Сообщение об ошибке в параллельном сервере запросов% s"

Затем я проверил в OEM, используется параллелизм 8 градусов. Поэтому я отключил параллелизм с помощью оператора alter (ALTER SESSION DISABLE PARALLEL QUERY). Затем mv работал долго, занял несколько часов и был создан. Пожалуйста, предложите, есть ли какие-либо подходы к его созданию без использования большого временного пространства. Количество запросов на выборку для этого MV составляет около 55 миллионов строк. Любые предложения очень ценятся.

БД: Oracle 11gR2

CREATE MATERIALIZED VIEW TEST NOLOGGING REFRESH FORCE ON DEMAND ENABLE QUERY REWRITE AS выберите table4.num как «Number», table4.num как «SNum», table4.status как «S_status», «Open» как «NLP», create_table2.fmonth как «SMN», table6.wgrp как «SOW», (table2.end_dt - create_table2.dt) как «elp», table6.d_c как «SDC», create_table2.fiscal_quarter_name как «SQN», 'TS' как «SSL», table3.table3_id как "SR Owner CEC ID", table4.sev как "ssev", SUBSTR (table8.stech, 1, INSTR (table8.stech, '=>') - 1) как "srtech", SUBSTR (table8. stech, INSTR (table8.stech, '=>') + 2) как "srstech", table5.sr_type как "Тип SR", table5.problem_code как "Код проблемы SR", --null как "Канал входа SR", --null как "Время SR в состоянии (дни)", table6.center, table6.th1col, table6.master_theater, table6.rol_3, table7.center hier_17_center, table7.rol_1 table7.rol_2, table7.rol_3 wg, table2.dt как "SBD", table2.wk_n как "SBF" W ", table2.fmonth как" SBFM ", table3.defect_indicator как" Имеет дефект ", table2.sofw, table2.sofm из A table1 присоединиться к B table2 на (table1.date_id = table2.dw_date_key) присоединиться к C table3 on (table1. date_id = table3.date_id и table1.incident_id = table3.incident_id) присоединяются к D table4 на (table3.incident_id = table4.incident_id и table4.key_d ‹= table3.date_id и table3.table3_id = table4.current_owner_table3_id) присоединяются к E table5 на table4. инцидент_id = table5.incident_id присоединиться к B create_table2 на (table5.creation_dw_date_key = create_table2.dw_date_key) присоединиться к F table6 на (table1.objectnumber = table6.DW_WORKGROUP_KEY) присоединиться к G table7 на (table1.objectnumber = table7.DW_WORKEY) слева (table8.natural_key = table5.UPDATED_COT_TECH_KEY), где table4.bl_incident_key in (выберите max (bl_incident_key) из D b, где b.incident_id = table3.incident_id и b.key_d ‹= table3.date_id и b.current_owner_table3_id = table3. d table2.fiscal_year_name в ('FY2013', 'FY2014')


person user3171342    schedule 25.06.2014    source источник


Ответы (1)


Не зная вашей системы, таблиц или данных, я предполагаю, что

  • некоторые из 8 таблиц имеют много строк (>> 55 миллионов)
  • объединение-предикаты и фильтры не уменьшат значительно объем данных
  • поэтому почти все данные будут записаны в mv

Вероятно, в плане выполнения будут использоваться какие-то хеш-операции и / или сортировка-агрегация. Это хеширование и сортировка не могут выполняться в памяти, если сегменты хеширования и сортировки слишком велики. Так что это будет сделано в темп.

8 параллельных слотов, вероятно, будут использовать больше времени, чем 1 сеанс. Так что это может быть причиной ора.

Вы можете

  • принимаю несколько часов. Обычно такие операции производятся ночью или в выходные дни, неважно, 4 или 1 час.
  • Увеличить температуру
  • Попробуйте масштабировать степень параллелизма с помощью подсказки: create .... as select / * + parallel (n) * / table4.num ... Используйте 2 или 4 или 8 для n, чтобы иметь 2,4,8 слота
  • Попробуйте использовать индексы для объединенных столбцов, например TABLE1 (DATE_ID, INCIDENT_ID) TABLE1 (OBJECTNUMBER)

    ТАБЛИЦА2 (DW_DATE_KEY) ТАБЛИЦА2 (FISCAL_YEAR_NAME)

    ТАБЛИЦА3 (DATE_ID, INCIDENT_ID, TABLE3_ID) ТАБЛИЦА3 (INCIDENT_ID, TABLE3_ID, DATE_ID)

    ТАБЛИЦА 4 (INCIDENT_ID, CURRENT_OWNER_TABLE3_ID, KEY_D, BL_INCIDENT_KEY)

    ТАБЛИЦА5 (INCIDENT_ID) ТАБЛИЦА5 (CREATION_DW_DATE_KEY) ТАБЛИЦА5 (UPDATED_COT_TECH_KEY)

    ТАБЛИЦА 6 (DW_WORKGROUP_KEY)

    ТАБЛИЦА 7 (DW_WORKGROUP_KEY)

    ТАБЛИЦА 8 (NATURAL_KEY)

И используйте план объяснения для разных sqls, чтобы увидеть, какой план сгенерирует Oracle.

person oratom    schedule 26.06.2014
comment
Спасибо за ваш ответ. Да, есть одна таблица, в которой более 55 миллионов записей. Я уже пробовал создавать индексы для таблиц, но это не оказало большого влияния, поскольку мы извлекали больше данных из этих таблиц. Я попробую 2/4 параллельной подсказки и посмотрю, работает ли она. - person user3171342; 01.07.2014