Oracle mechanics

19.08.2014

Большой план выполнения и трассировка рекурсивных запросов с помощью ASH

Filed under: Active Session History,memory management,Oracle,SQL Tuning — Игорь Усольцев @ 00:18
Tags: ,

Спустя час с небольшим после начала выполнения запроса была получена следующая ошибка*:

ORA-04030: выход за пределы памяти процесса при попытке выделить 4120 байт (kksfr: qkesSet,frame segment)

Из автоматически сгенерированного трейса инциндента можно получить много информации, включая, например, раскладку использованных процессом 10GB из 15GB PGA (!):

=======================================
PRIVATE MEMORY SUMMARY FOR THIS PROCESS
---------------------------------------
******************************************************
PRIVATE HEAP SUMMARY DUMP
10 GB total:
    10 GB commented, 1103 KB permanent
  1452 KB free (0 KB in empty extents),
    6596 MB,   1 heap:    "kxs-heap-c     "            72 KB free held
    3646 MB,   2 heaps:   "callheap       "            1127 KB free held

*** 2014-07-17 13:12:32.395
------------------------------------------------------
Summary of subheaps at depth 1
10 GB total:
  4175 MB commented, 1527 MB permanent
  4508 MB free (0 KB in empty extents),
    3613 MB,   1 heap:    "TCHK^6f1a0bb0  "
    1177 MB, 187983 chunks:  "qkkele                    " 794 MB free held
    1039 MB, 298563 chunks:  "subHeap:qkspmTransformPred" 987 MB free held
     812 MB, 198230 chunks:  "allocator state           " 800 MB free held
     676 MB, 187983 chunks:  "qkkkey                    " 663 MB free held
...

, но для начала, зная указанный в том же трейсе SID.SERIAL сессии и SQL_ID:

*** SESSION ID:(972.11477) 2014-07-17 13:12:25.342
...
----- Current SQL Statement for this session (sql_id=fq5vmt1rjn2xh) -----
insert into t_base_source
        select s.*, sysdate as insert_dt
          from v_base_source s

, полезно посмотреть в ASH чем занималась пользовательская сессия до падения: (more…)

12.08.2014

Кластерные ожидания и запросы Advanced Queuing

Filed under: Active Session History,Диагностика системы (instance),Oracle,RAC — Игорь Усольцев @ 22:08
Tags: ,

Периодически в Oracle 11.2 RAC системе возникают характерные кластерные проблемы, в основном, по причинам неверной конфигурации, например, выбора неподходящего сервиса для выполнения ресурсоёмких бизнес процессов / пакетных заданий

Далее описана наглядная краткосрочная проблема этого типа и, в частности, роль AQ запросов

Итак, AWR показал:

              Snap Id      Snap Time      Sessions Curs/Sess
            --------- ------------------- -------- ---------
Begin Snap:    296087 07-Aug-14 12:00:39       451       2.2
  End Snap:    296088 07-Aug-14 12:30:40       504       2.1
   Elapsed:               30.02 (mins)
   DB Time:            2,615.89 (mins)                       -- завышенный DB Time для 16 ядерного сервера

Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
gc buffer busy acquire              354,144      67,484    191   43.0 Cluster    -- и богатый набор кластерных ожиданий
gc cr block 2-way                   319,644      16,234     51   10.3 Cluster
gc current grant busy               117,362      11,066     94    7.1 Cluster
gc current block 2-way              169,545       9,974     59    6.4 Cluster

(more…)

23.07.2014

12.1.0.2

Filed under: Oracle — Игорь Усольцев @ 10:56
Tags:

Похоже, вчера появилась доступная для скачивания для Linux / Solaris

А сегодня — обновили документацию версии 12.1 описаниями добавленной опции Using the In-Memory Column Store, из которой в частности следует, что заполнением/обновлением содежимого поколоночного хранилища в памяти будут заниматься background процессы, кол-во которых регулируется параметрами INMEMORY_MAX_POPULATE_SERVERS и INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT

Будет интересно

UPD. В частности, любопытное замечание можно видеть в спмске Features Not Available or Restricted in This Release of Oracle Database 12.1.0.2:

  • Oracle Automatic Storage Management Cluster File System (Oracle ACFS) does not currently support Hybrid Columnar Compression (HCC)

- значит ли это, что планируется поддержка HCC на ACFS ?

21.07.2014

JPPD в присутствии удалённой таблицы и View Merging

Filed under: CBO,heuristics,Oracle — Игорь Усольцев @ 00:50
Tags: ,

На продакшн системе версии 11.2.* наблюдал, как сам факт использования удалённой (remote) таблицы блокировал использование Join Predicate Push-Down (JPPD) в запросе следующего типа:

select t.char_column, analytic_view.max_id, analytic_view.max_char_column
  from t,
       t@SCOTT_LOOPBACK
         t2,
       (select id1,
               max(id2) keep(dense_rank first order by id1 desc) max_id,
               max(char_column) max_char_column
          from t
         group by id1) analytic_view
 where t.id1 = t2.id1
   and t.id2 = analytic_view.id1
   and t.id1 = 10

- несмотря на то, что удалённая таблица, казалось бы, никакими условиями запроса с inline view связана не была. Т.е. JPPD работает для локальной таблицы T2 и не работает для удалённой.
Использование аналитического запроса в inline view препятствием для применения JPPD не является

Тестовая схема для версий 11.2.0.3/12.1.0.1: (more…)

12.07.2014

Дочерние процессы LGWR 12c

Filed under: Диагностика системы (instance),Oracle,Oracle new features — Игорь Усольцев @ 12:32
Tags:

Лог процесса LGWR, начиная с версии 12c, указывает:

Created 2 redo writer workers (2 groups of 1 each)
...
Adaptive scalable LGWR disabling workers
...
Adaptive scalable LGWR enabling workers

- на вновь реализованную идею использовать множество процессов для записи логов, в последний раз наблюдавшуюся в версиях до 8i через ныне неиспользуемый (depricated) параметр _lgwr_io_slaves

В новой версии Oracle 12c это называется Adaptive scalable LGWR workers и грубо регулируется параметром скрытым _use_single_log_writer: (more…)

25.06.2014

Особенности преобразования Table Expansion

Filed under: bugs,Oracle,Partitioning — Игорь Усольцев @ 00:03
Tags: ,

Полезное стоимостное (CBQT) преобразование Table Expansion (TE), доступное с версии 11.2, кроме несомненных достоинств имеет ряд недоработок-багов особенностей реализации и применения, периодически омрачающих радость столкновений с лучшим из стоимостных оптимизаторов (CBO)

Далее — краткий обзор случаев неоднозначного поведения TE, доступных в версиях 11.2 — 12.1.0.1

И вначале — о хорошем: для случая простого Range Partitioning технология успешно отрабатывает независимо от количества и порядка расположения Unusable Index Partitions: (more…)

22.06.2014

x86 серверы для Database In-Memory Oracle 12c

Filed under: Hardware,Oracle — Игорь Усольцев @ 11:09
Tags:

Ожидаемое появление опции Database In-Memory потребует серверов со значительным объёмом памяти (DRAM), и Oracle не заставил себя ждать, анонсировав для сектора SMB условно доступное (x86) собственное решение — Sun Server X4-4 / X4-8 со следующими топовыми характеристиками:

  • 5U
  • 6 TB DRAM
  • 8 x Sun Flash Accelerator F80 PCIe Cards = 6.4 TB PCIe flash
  • 8 x Intel Xeon E7-8895 v2 (120 cores) с гибкой технологией Elastic Computing:

x4-8-graph[1]- позволяющей без перезагрузки системы менять количество/частоту доступных физических ядер
Цель «эластичности» при столь незначительном ~10% максимальном изменении частоты остающихся ядер в плане получения выигрыша производительности не очень понятна, в отличие от гибкости по кол-ву лицензий СУБД и опций при покупке системы с большой памятью, объём которой линейно зависит от кол-ва установленных процессоров — если такой вариант допустим, конечно. Неочевидным местом конфигурации мне также показалось соотношение макс.объёмов DRAM к PCIe Flash — 1:1

При беглом осмотре можно заметить, что прочие производители верхнего сегмента commodity hardware также совсем неплохо подготовились к приходу технологий In-Memory-DB
Например, новый сервер Huawei RH8100 V3: (more…)

20.06.2014

И ещё про Filter Push-Down

Filed under: Optimizer features,Oracle — Игорь Усольцев @ 00:04
Tags:

При попытке отключения всех типов трансформаций запроса (на примере из предыдущей записи): (more…)

14.06.2014

Filter Push-Down и избыточные предикаты

Filed under: Oracle,Partitioning — Игорь Усольцев @ 12:27
Tags: ,

Александр Шакура показал интересное: в простом запросе добавление очевидно избыточного условия (redundant predicate) включает partition pruning, заметно улучшая тем самым стоисмость (Cost) и скорость выполнения запроса к обзору, построенному на помесячно партиционированной таблице

SELECT
 *
  FROM (SELECT /* эта часть запроса станет view */
         TRUNC(a.DT, 'mm')                    BEG_MONTH,
         ADD_MONTHS(TRUNC(a.DT, 'mm'), 1) - 1 END_MONTH,
         SUM(a.SUM_RUR)                       SUM_RUR
          FROM MVIEW__DAILY_SALES a
          WHERE a.dt BETWEEN TRUNC (a.DT, 'mm') AND ADD_MONTHS (TRUNC (a.DT, 'mm'), 1) - 1 -- redundant predicate?
         GROUP BY TRUNC(a.DT, 'mm'), ADD_MONTHS(TRUNC(a.DT, 'mm'), 1) - 1)
 WHERE beg_month = DATE '2013-04-01'
   AND end_month = DATE '2013-04-30'

Без избыточного предиката запрос демонстрирует типичный PARTITION RANGE ALL как ожидаемое поведение: (more…)

07.06.2014

Dynamic Sampling для индексов с отсутствующей статистикой

Filed under: CBO,heuristics,Oracle,statistics — Игорь Усольцев @ 18:12
Tags:

План удаления 80+ млн.строк радовал простотой и доступностью:

11.2.0.3.@ SQL> explain plan for
  2  DELETE FROM SYSTEM.DB_AUDIT_TRAIL_STORE
  3  /

------------------------------------------------------------------------------------------------
| Id  | Operation        | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT |                             |    83M|  2792M|    26   (0)| 00:00:01 |
|   1 |  DELETE          | DB_AUDIT_TRAIL_STORE        |       |       |            |          |
|   2 |   INDEX FULL SCAN| DB_AUDIT_TRAIL_STORE_ACTION |    83M|  2792M|    26   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

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

Получение более реалистичного плана через сбор/установку реальной статистики индекса очевидно, однако, возникает вопрос: почему в таком случае не используются разного рода динамические технологии, типа Dynamic Sampling/Dynamic Statistics (DS), к примеру, и можно ли заставить их работать?

Итак, после создания тестовой таблицы на версии 11.2.0.3: (more…)

Следующая страница →

Тема: Rubric. Блог на WordPress.com.

Отслеживать

Get every new post delivered to your Inbox.

Join 113 other followers