ORACLE 12.2 - Значительная потеря производительности с локальными индексами в «сильно» секционированной модели - PullRequest
Новая
       20

ORACLE 12.2 - Значительная потеря производительности с локальными индексами в «сильно» секционированной модели

0 голосов
/ 28 мая 2018

Проблема

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

Моя настройка

  • 54 таблиц
  • 10 000 разделов и 1 подраздел на таблицу (на данный момент)
  • в среднем 10 индексов на таблицу

Настройка DDL: https://drive.google.com/open?id=13V8Tcv5kTl6QuPqTya6kqImbZlWGd1jk

...

Вариант использования

Моими тестами были две инструкции, работающие на почти пустой базе данных

1 - один простой выбор, который всегда выполняется для ключа раздела и подраздела

2 - один этап удаления с разделом и подразделом

Тестовый пример 1 - трассировка и выполнение: https://drive.google.com/open?id=19eWUoxckaIPCyFU0jorK8wrSf-HgjhWA

Устранение неполадок

  • удалены все индексы, и проблема была "решена"
  • Сканирование диапазона индексов заняло почти 100% времени выполнения
  • та же настройка, но с 1.6k разделами на таблицу все в порядке

Враг номер один (извлечен из трассы)

> 

SQL ID: 9b4m3fr3vf9kn Plan Hash: 2436900644

select obj#, dataobj#, subpart#, hiboundlen, hiboundval, flags, ts#, file#, 
  block#, pctfree$, initrans, maxtrans, analyzetime, samplesize, rowcnt, 
  blevel, leafcnt, distkey, lblkkey, dblkkey, clufac, spare2, 
  length(bhiboundval), bhiboundval 
from
 indsubpart$ where pobj# = :1 order by subpart#


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       23      0.00       0.00          0          0          0           0
Execute 230000     19.13      20.91          0          0          0           0
Fetch   460000     25.59      27.83       3357    1380000          0      230000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   690023     44.73      48.75       3357    1380000          0      230000

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: USERNAME   (recursive depth: 1)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
         1          1          1  TABLE ACCESS BY INDEX ROWID INDSUBPART$ (cr=5 pr=4 pw=0 time=1813 us starts=1 cost=4 size=69 card=1)
         1          1          1   INDEX RANGE SCAN I_INDSUBPART_POBJSUBPART$ (cr=4 pr=3 pw=0 time=1317 us starts=1 cost=3 size=0 card=1)(object id 815)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PGA memory operation                            2        0.00          0.00
  cell single block physical read              3357        0.01          1.68
  latch: shared pool                              1        0.00          0.00
********************************************************************************

Сомнения - Я далек от логических пределов: https://docs.oracle.com/cd/B28359_01/server.111/b28320/limits003.htm#i288032,, но по-прежнему имею большое снижение производительности, яЯ делаю что-то не так с моим DDL или это просто слишком большая установка?

Примечание - Возможно, установка неверна, но первый вопрос: должен ли он ломаться в этот момент?

Спасибо

...