db in-memory-overview 2015-10_14

www.partner.fors.ru 1

Новая опция Oracle Database 12c In-Memory

Валерий Юринский Директор отделения технологического консалтинга

[email protected]

14 октября 2015 г.


План

Введение

Oracle Database In-Memory Option

Несколько примеров

Заключение


Введение


Оперативная память: тренды и влияние Сегодня память быстрее, дешевле и ее объем больше

Объемы памяти растут

2002 256 MB/DIMM

2012 16 GB/DIMM

Стоимость памяти падает

2002 $0.2/MB

2012 $0.009/MB

Память становится

значительно быстрее

Disk 5ms – скорость

доступа

DRAM 100ns – скорость

доступа

64x больше емкости 25x дешевле 50,000х быстрее

Ускорение OLTP и DW приложений, больше пользователей, больше данных

DRAM:

2012 $0.0005/MB 2012 100 GB/DOM Flash 0.25ms – скорость

доступа

400x больше емкости 400x дешевле 20x быстрее Flash:


Oracle In-Memory Database Лучшие технологии для обработки данных в памяти

12c Release 1

• Big Memory Cluster

& 2x more index compression

on Exadata

• Rowset Processing

• In-Memory Column Store

for Unstructured Data

• OLTP Wide Table

Compression

• HCC Row Level Locking

Приложение

работает с

памятью без

изменений!

Комбинация DRAM, Flash и HDD

Быстрой памяти и стоимости дисков

Без ограничений на размер БД

2007 2012 До 2007 2009 2008

• 20+ years of scale-up

optimizations

• 10+ years of scale-out

optimizations

• Prefix Index Compression

• Bitmap Index Compression

• Basic & IOT Table

Compression

• And much more

• In-Memory Parallel Query

• OLTP Compression

• Unstructured Data

Compression

• Client SQL/PL/SQL Result

Cache

• Server SQL/PL/SQL Result

Cache

• In-Memory Column Store for

DW

• Columnar Compression

• Columnar Processing

• Cache Fusion Optimizations

• In-Memory Parallel Query

Optimizations

• In-Memory Storage Index on

Exadata Storage


Приходилось выбирать один формат и идти на компромиссы

Давнее противоречие Строчный формат и поколоночный формат

Row

OLTP-операции работают быстрее со построчным форматом

– Пример: Выборка или добавление заказа

– Быстрая обработка немного строк, много столбцов

Column

Аналитика работает быстрее с поколоночным форматом

– Пример: Отчет о сумме продаж по штату

– Быстрый доступ немного столбцов, много строк

ORDER

SALES

SALES

S

T

A

T

E


Давнее противоречие Строчный формат и поколоночный формат

Row

Выборка одного заказа в построчном формате

- Обращение к одной непрерывной строке

= БЫСТРО

Column

Выборка одного заказа в поколоночном формате

- Обращение к нескольким столбцам

= М Е Д Л Е Н Н О

SALES

Stores SALES

Query

Query Query

Query

Query

Приходилось выбирать один формат и идти на компромиссы


Database In-Memory Option


Oracle Database In-Memory Option

В опцию Oracle Database In-Memory входят

следующие функциональные возможности: – In-Memory Column Store

– In-Memory Aggregation

– Fault Tolerant In-Memory Column Store (Requires Exadata or

Supercluster)


Аналитика в

реальном

времени

Неизменность приложений

Простота

внедрения

100x 2x

10

Задачи Oracle Database In-Memory

Призводитель-

ность при сме-

шаной нагрузке


Задачи Oracle Database In-Memory Option

В 100 раз быстрее запросы для аналитики в

реальном времени

Мгновенное получение результата

Запросы к OLTP базе или хранилищу данных

Актуальные данные в результатах!

В 2 раза ускоряется обработка транзакций

Вставка строк в 3 – 4 раза быстрее


Прорыв: база данных с двойным форматом

• Использует OБA (два) формата

для одной таблицы: строчный и

поколоночный • Работают совместно,

транзакционно согласованы

• Аналитика и отчетность

используют новый

поколоночный формат In-

Memory

• OLTP использует проверенный

построчный формат

1

2

Обычный Buffer Cache

Новый формат In-Memory

SALES SALES

Строчный формат

Поколоночный формат

SALES


Oracle In-Memory Columnar Technology

Оперативная память

Истинно поколоночный

In-Memory Column Store (IMCS) -

постолбцовое оперативное

хранилище

Истинно поколоночное (pure

columnar) хранение в памяти

изменяемые данные

нет генерации REDO-данных

Минимальные затраты на

изменения – даже для OLTP-

транзакций

Данные загружаются в кэш при

первом обращении


И строчный, и поколоночный

формат хранения в памяти для

одних и тех же данных/таблиц

Данные одновременно активны

и транзакционно согласованы

В 100 раз быстрее аналитика &

отчетность: поколоночный

формат

В 2 раза быстрее OLTP:

строчный формат

In-Memory Option: Оба формата в памяти СУБД

Column

Format

Memory

Row

Format

Memory

Analytics OLTP Sales Sales


Oracle Instance 12c без In-Memory

Instance

SGA

Redo log

buffer cache

Shared pool

Data Dict.

cache

Library

cache

DBWR SMON PMON CKPT LGWR Others

Database

buffer cache

Shared pool

Data Dict.

cache

Library

cache



Oracle In-Memory: отдельный кэш в SGA

Instance

SGA

Redo log

buffer cache

Shared pool

Data Dict.

cache

Library

cache


Database

buffer cache

SQL> ALTER SYSTEM SET inmemory_size=512G SCOPE=SPFILE;

Instance

SGA

Redo log

buffer cache

Shared pool

Data Dict.

cache

Library

cache


In-row

buffer cache

In-Memory

Columnar

Cache

Статический параметр INMEMORY_SIZE


Статический пул в SGA Соответственно должен быть увеличен параметр SGA_TARGET

SQL> SELECT * FROM V$SGA;

NAME VALUE

------------------ ---------

Fixed Size 2927176

Variable Size 570426808

Database Buffers 4634022912

Redo Buffers 13848576

In-Memory Area 1024483648


Почему сканирование In-Memory быстрее чем в буферном кэше?

SELECT COL4 FROM MYTABLE;

1

8

X X X X X

РЕЗУЛЬТАТ

Строчный формат

Буферный кэш


SELECT COL4 FROM MYTABLE;

1

9

RESULT

Колоночный формат

In-Memory кэш

РЕЗУЛЬТАТ

X X X X

Почему сканирование In-Memory быстрее чем в буферном кэше?


Включение постолбцового представления для таблицы или mview

Включение постолбцового представления для группы столбцов

Кэшироваться может не вся таблица, а только часть её столбцов!

SQL> ALTER TABLE cities

INMEMORY

INMEMORY (Id, Name, Country_Id, Time_Zone)

NO INMEMORY (Created, Modified, State);

Table altered.

SQL> ALTER MATERIALIZED VIEW cities_mv INMEMORY;

Materialized view altered.

•Служебные столбцы – не

участвуют в отчетах:

нужны только для бизнес-

логики


Включение постолбцового представления для табличного пространства и секции

Все таблицы и mview в табличном пространстве будут

представлены в постолбцовом оперативном хранилище (IMCS)

SQL> ALTER TABLESPACE tbs_data DEFAULT INMEMORY

MEMCOMPRESS FOR CAPACITY HIGH

PRIORITY LOW;

Tablespace altered.

То же, на уровне секций таблицы SQL> CREATE TABLE customers ……

PARTITION BY LIST

(PARTITION p1 …… INMEMORY,

(PARTITION p2 …… NO INMEMORY);


Изменение плана запроса SQL-оптимизатор перестраивает план запроса

SQL> SELECT count(*) FROM cities;

Execution Plan

----------------------------------------------------------

Plan hash value: 2756775702

---------------------------------------------------------------------

| Id | Operation | Name | Rows | Cost (%CPU)|

---------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 0 (0)|

| 1 | SORT AGGREGATE | | 1 | |

| 2 | TABLE ACCESS INMEMORY FULL| CITIES | 1 | |

---------------------------------------------------------------------


Сканирование миллиарда строк в секунду на процессорном ядре

SIMD

Compare all

values in 1

cycle

Сравнение

всех

значений за

один цикл

Загрузка

значений

множества

штатов

Vecto

r

Reg

iste

r

In-Memory Column Store

State column Sales

Пример: Найти все продажи в штате CA

“CA”

более чем в 100

раз быстрее

• Каждое процессорное ядро

сканирует одну колонку

• При сканировании

используются быстрые

векторные SIMD-

инструкции

• Миллиарды строк в

секунду сканируются

одним ядром CPU


При первом обращении к сегменту для которого включен атрибут

in-memory начинается наполнение постолбцового оперативного

хранилища (In-Memory Column Store = IMCS)

Oracle In-Memory: “разогрев” IMCS


Сканирование и соединение данных из нескольких таблиц

Продажи Магазины

Type=outlet

Пример: Найти все продажи в outlet-магазинах

T

Y

P

E

Storeid

in

15,38,64

S

T

O

R

E

I

D

A

M

O

U

N

T

Преобразует

соединения (joins) в

быстрые фильтры по

столбцам

За счет этого

соединения (joins)

выполняются в 10 раз

быстрее Sum


Multiple Bloom Filter Несколько соединений с использованием In-Memory


Cжатие столбцов в IMCS

Метод сжатия Описание

NO MEMCOPRESS Данные не сжимаются

MEMCOMPRESS FOR DML Метод сжатия оптимизированный для DML-

операций

MEMCOMPRESS FOR QUERY LOW Метод по умолчанию. Наилучший вариант для

выполнения запросов.

MEMCOMPRESS FOR QUERY HIGH Сжатие выше, чем при FOR QUERY LOW, но ниже,

чем при FOR CAPACITY LOW

MEMCOMPRESS FOR CAPACITY LOW Сжатие выше, чем при FOR QUERY HIGH, но ниже,

чем при FOR CAPACITY HIGH

MEMCOMPRESS FOR CAPACITY

HIGH Сжатие выше, чем при FOR CAPACITY LOW


Cжатие столбцов в IMCS - пример

Сжатие разными методами для группы столбцов


INMEMORY

INMEMORY MEMCOMPRESS FOR CAPACITY HIGH(Country_Id, Time_Zone)

INMEMORY NO MEMCOMPRESS (Id, Name, Name_Eng);

Table altered.

•Уникальные столбцы – не

сжимаются!


Поддержка в Compression Advisor DECLARE

l_blkcnt_cmp BINARY_INTEGER;

l_blkcnt_uncmp BINARY_INTEGER;

l_row_cmp BINARY_INTEGER;

l_row_uncmp BINARY_INTEGER;

l_cmp_ratio NUMBER;

l_comptype_str VARCHAR2(100);

BEGIN

dbms_compression.get_compression_ratio

--input parameters

scratchtbsname => 'USERS', -- scratch tablespace

ownname => ‘INMEM_DEMO', -- owner of the table

objname => ‘TICKETS', -- table name

subobjname => NULL, -- partition name

comptype => DBMS_COMPRESSION.COMP_INMEMORY_QUERY, -- compression algorithm

--output parameters

blkcnt_cmp => l_blkcnt_cmp, -- number of compressed blocks

blkcnt_uncmp => l_blkcnt_uncmp, -- number of uncompressed blocks

row_cmp => l_row_cmp, -- number of rows in a compressed block

row_uncmp => l_row_uncmp, -- number of rows in an uncompressed block

cmp_ratio => l_cmp_ratio, -- compression ratio

comptype_str => l_comptype_str);-- compression type

END;


Атрибут INMEMORY в *_TABLES

SQL> SELECT table_name,

inmemory

FROM USER_TABLES;

TABLE_NAME INMEMORY

------------ --------

CHANNELS DISABLED

COSTS

CUSTOMERS DISABLED

PRODUCTS ENABLED

SALES

TIMES DISABLED

Новый столбец INMEMORY в

представлениях словаря

*_TABLES

INMEMORY – это атрибут

сегмента

*_TABLES не отображают

атрибуты логических объектов

COST и SALES –

секционированные таблицы

(логические объекты)

Столбец INMEMORY также

появился в *_TAB_PARTITIONS


Системное представление [G]V$IM_SEGMENTS

SQL> SELECT

segment_name,inmemory_size,bytes,bytes_not_populated,populate_status

FROM

v$im_segments;

SEGMENT_NAME INMEMORY_SIZE BYTES BYTES_NOT_POPULATED POPULATE_STATUS

--------------------------------------------------------------------------

COUNTRIES 131072 5242880 425984 STARTED

CITIES 1179648 5242880 0 COMPLETED

COMPANIES 1179648 5242880 0 COMPLETED

AIRPORTS 1179648 5242880 0 COMPLETED

Мониторинг использования кэша


Управление приоритетом загрузки в кэш

Приоритет Синтаксис Описание

• NONE

(default)

PRIORITY NONE • Приоритет загрузки определяется СУБД. Загрузка может быть задержана, если память используется для другого более приоритетного сегмента. - Запрос переключаетcя на обычный (in-row) кэш.

• LOW PRIORITY LOW • Низкий приоритет

• MEDIUM PRIORITY MEDIUM • Средний приоритет

• HIGH PRIORITY HIGH • Высокий приоритет

• CRITICAL PRIORITY CRITICAL • Наивысший приоритет


Приоритет загрузки в IMCS - пример

Один приоритет для всей таблицы/секции/мат. представления


INMEMORY

PRIORITY CRITICAL

INMEMORY MEMCOMPRESS FOR CAPACITY HIGH(Country_Id, Time_Zone)

INMEMORY MEMCOMPRESS NO (Id, Name, Name_Eng);

Table altered.


OLTP работает медленно из-за аналитических индексов

Таблица 1 - 3

OLTP

индекса

10 - 20

аналитических

индексов Большинство индексов в OLTP

(например, в ERP) базах

строится только для

аналитических запросов

Индексы хорошо подходят для

предсказуемых запросов (и в

памяти, и на диске)

Вставка одной строки в таблицу

приводит к обновлению 10-20

аналитических индексов:

Медленно!

Поколоночное

хранение в памяти


Oracle In-Memory – высокая доступность

Представление по столбцам в

памяти не влияет на формат данных

на диске: datafiles, logging, backup,

recovery, и т.д.

Все технологии, в том числе ASM,

RAC, DG, GG работают прозрачно

для In-Memory Option

Защита от любых видов ошибок

• На уровне железа

• Логические ошибки

приложения (Flashback)

RAC

ASM

RMAN

Data Guard & GoldenGate


Oracle In-Memory в RAC

Управление распределением объектов в кэше между узлами RAC: – AUTO DISTRIBUTE – синхронизацией кэша управляет СУБД

(поведение по умолчанию)

– DUPLICATE – (ES-only) кэши принудительно синхронизируются между

узлами RAC (2 копии chunk-а кластер)

– DUPLICATE ALL – ( ES-only) кэши одинаковы

на всех узлах RAC

– DISTRIBUTE BY

ROWID RANGE,

PARTITION,

SUBPARTITION

SQL> ALTER TABLE cites INMEMORY

DUPLICATE;

Table altered.

In Memory

Column

Store

In Memory

Column

Store

In Memory

Column

Store

In Memory

Column

Store


Полный синтаксис кэширования таблицы

Мощный и гибкий синтаксис


INMEMORY

PRIORITY CRITICAL

DUPLICATE

INMEMORY MEMCOMPRESS FOR CAPACITY HIGH (Country_Id, Time_Zone)

INMEMORY MEMCOMPRESS NO (Id, Name, Name_Eng)

NO INMEMORY (Created, Modified, State);

Table altered.


Подсказки для оптимизатора Включение/выключение columnar-кэширования и pruning-а

SQL> SELECT /*+ NO_INMEMORY (mytbs) */

sum(a.amount)

FROM

cities c,

amounts a

WHERE

c.id = a.city_id;

Новые хинты: – INMEMORY, NO_INMEMORY

– INMEMORY_PRUNING, NO_INMEMORY_PRUNING


Хранит минимальное

и максимальное

значение столбца в

каждом экстенте

памяти кэша

Прозрачно исключает

ненужные

сканирования столбцов,

например:

WHERE prod_id > 14

AND prod_id < 29

Storage Index в In-Memory Columnar Store


DML and the In-Memory Column Store

4

1

• Каждый объект помещенный в Column

Store состоит из множества колоночных

элементов (column units=IMCU)

/Each object populated in the Column Store is

actually made up of multiple column units (IMCU)/

• Каждый колоночный элемент содержит

значения столбца для подмножества

(нескольких) строк объекта

/Each column unit contains the column

entries for a subset of rows in the object/

• В зависимости от типа данных и степени

сжатия колоночные элементы могут

быть разного размера

/Column units can vary in size depending

on datatypes used and compression rates/

Memory

SALES Column Format



4

2

Memory

Column Format

IMCU IMCU

IMCU IMCU

IMCU IMCU

IMCU IMCU

IMCU IMCU

• Каждый объект помещенный в Column

Store состоит из множества колоночных

элементов (column units=IMCU)

/Each object populated in the Column Store is

actually made up of multiple column units (IMCU)/

• Каждый колоночный элемент содержит

значения столбца для подмножества

(нескольких) строк объекта

/Each column unit contains the column

entries for a subset of rows in the object/

• В зависимости от типа данных и степени

сжатия колоночные элементы могут

быть разного размера

/Column units can vary in size depending

on datatypes used and compression rates/



4

3

• Каждый колоночный элемент (IMCU) содержит значения столбца для подмножества (нескольких) строк объекта /Each IMCU contains the column entries for a subset of rows in the object/

• У каждого IMCU имеется связанный с ним журнал транзакций /Each IMCU also has a transaction journal associated with it/

• Журнал транзакций используется для поддержания транзакционной согласованности Column Store /The transaction journal is used to keep the IM column store transactionally consistent/

Memory

Column Format

IMCU

JOURNAL


JOURNAL


4

4

• Операции DML обрабатываются обычным образом в обычном строчном хранилище /DML operations processed in row store just as they are today/

Memory

Column Format

• Соответствующие измененным строкам элементы Column Store помечаются, Как "устаревшие" /Corresponding entry in column store marked stale/

• Копия измененных строк хранятся в транзакционном журнале /Copy of changed row stored in the Transaction Journal/

IMCU


JOURNAL


4

5

• In-Memory Column Store никогда не устаревает /In-Memory Column Store is never out of date/

• Согласованность по чтению достигается объединением актуального содержимого столбцов и транзакционного журнала /Read consistency achieved by merging contents of column and the transaction journal/

Memory

Column Format

IMCU



4

6

• Когда число записей в транзакционном журнале достигает определенного порогового значения, колоночный элемент автоматически обновляется /When number of entries in transaction journal hits an internal threshold CU automatically refreshed/

• Column Store всегда доступен, Поскольку обновление выполняется online /This is an online operation – column store always available/

Memory

Column Format

JOURNAL

IMCU


Space Manager

Управляет памятью в In-

Memory Column Store

(create, extend, drop)

Загружает данные в кэш

Transaction Manager

Обеспечивает

согласованность данных

в In-Memory Column

Store с буферным

кэшем

Обеспечивает

версионность

In-Memory Option - архитектура


Новые параметры в init.ora

INMEMORY_SIZE

INMEMORY_FORCE = { DEFAULT | OFF }

INMEMORY_CLAUSE_DEFAULT = [INMEMORY] [NO INMEMORY]

[compression-clauses][priority-clauses]

INMEMORY_QUERY = {ENABLE | DISABLE}

INMEMORY_MAX_POPULATE_SERVERS

OPTIMIZER_INMEMORY_AWARE

INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT


Для каких приложений подходит Database In-Memory Option?

Если в приложении есть много запросов сканирующих много строк

с фильтрами такими как: “=, <, >, и IN”

Запрашивает всего лишь несколько столбцов, напр: 5 столбцов из

100 столбцов таблицы

Приложение часто делает соединение большой таблицы фактов с

таблицами измерений с фильтрами по ним (выборка не по всем

значениям измерений, а по их части)

Типы приложений предпочтительные для использования In-

Memory Option: – хранилища данных (Data Warehouse)

– cмешанного типа (Mixed Application)


Oracle In-Memory Options не требует изменения приложений

Полная функциональность - Нет ограничений на SQL

Простота реализации - Не нужна миграция данных

Полная совместимость - Не надо изменять приложения

Полностью Multitenant - Oracle In-Memory готова для cloud

Приложения получают все преимущества In-Memory опции без изменения кода приложения


Oracle Database 12c Runs SAP Applications 2x Faster Than SAP HANA

По Why Risk Disrupting Your Business with SAP HANA?

Oracle Database In-Memory is 100 percent compatible with all existing

applications, therefore there is no need to rewrite your application to take

advantage of it. No complexity, no compromises, no risks. Modern in-memory

technology that simply and seamlessly works with your business—not the other

way around. In contrast, with SAP HANA, the application will need to be

rewritten, spending precious resources, time, and budget.

Get Analytics 2x Faster Than with SAP HANA

Oracle Database In-Memory implements state-of-the-art technology to

accelerate analytics by orders of magnitude to allow users to get

immediate answers to business questions that previously took hours. This

same Oracle in-memory technology is proven to speed up SAP

applications 2x faster than SAP HANA on SAP's own benchmarks.

Read the Benchmark white paper*

https://www.oracle.com/corporate/features/oracle-powers-sap.html

15-sep-2015

http://www.oracle.com/technetwork/database/in-memory/overview/benefits-of-dbim-for-sap-apps-2672504.html








Oracle Database In-Memory Advisor (Doc ID 1965343.1)

Пример рекомендаций


Несколько примеров


Тестовый стенд

Сервер Oracle Sun T5-2 – 2 x Sixteen-core 3.6 GHz SPARC T5 processor = 32 cores

– 32 cores x 8 threads/core = 256 threads

– 512 ГБ RAM

Oracle Database 12.0.1.2 – Буферный кэш: 240Gb

– In-Memory Columnar Cache: 100Gb


Данные для "тренировочных забегов" в In-Memory

Схема данных Схема типа "Звезда"

Вариация стандартной

схемы теста TPC-H –

производительность

хранилища данных (DWH)

Схема построена для

масштаба 100 ГБ (100 GB

scale factor) Таблица Объем, МБ Кол-во строк

CUSTOMER 2 309,2 15 000 000

DATE_DIM 0,2 2 556

LINEORDER 42 279,0 600 019 253

PART 1 778,1 20 000 000

SUPPLIER 147,5 1 000 000

Compression BASIC



Конфигурирование Sun Server T5-2 – RAM 512 GB

SQL> SHOW SGA

Total System Global Area 498 216 206 336

Fixed Size 7 663 664

Variable Size 147 102 633 936

Database Buffers 243 202 523 136

Redo Buffers 529 203 200

In-Memory Area 107 374 182 400

Размер устанавливается параметром INMEMORY_SIZE

(Minimum IN_MEMORY_SIZE = 100MB)


Заполнение Buffer Cache и In-Memory Column Store

Установка параметров Cache и In-Memory

-- Устанавливается для эксперимента, чтобы не было дисковых операций

ALTER TABLE CUSTOMER CACHE;

ALTER TABLE DATE_DIM CACHE;

ALTER TABLE LINEORDER CACHE STORAGE (BUFFER_POOL KEEP);

ALTER TABLE PART CACHE;

ALTER TABLE SUPPLIER CACHE;

-- Указание на размещение в In-Memory Column Store

ALTER TABLE CUSTOMER INMEMORY;

ALTER TABLE DATE_DIM INMEMORY;

ALTER TABLE LINEORDER INMEMORY;

ALTER TABLE PART INMEMORY;

ALTER TABLE SUPPLIER INMEMORY;




-- Заполнение Buffer Cache

-- и инициирование заполнения In-Memory Column Store

SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM CUSTOMER T;

SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM DATE_DIM T;

SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM LINEORDER T;

SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM PART T;

SELECT /*+ FULL(T) NO_PARALLEL */ COUNT(*) FROM SUPPLIER T;



100 GB Scale Factor WITH bh AS (SELECT objd, file#, ROUND(COUNT(block#)*16384/1024/1024, 1) AS mbytes

FROM v$bh group by objd, file#)

SELECT T.table_name, bh.mbytes AS buff_cache_mb

, ROUND(T.blocks*16384/1024/1024,1) AS tab_mb, num_rows

FROM bh, user_objects O, user_tables T

WHERE bh.objd = O.object_id AND T.table_name = O.object_name

AND O.object_name IN ('LINEORDER', 'DATE_DIM', 'CUSTOMER', 'SUPPLIER', 'PART')

ORDER BY O.object_name;

TABLE_NAME BUFF_CACHE_MB TAB_MB NUM_ROWS CUSTOMER 2303,1 2309,2 15 000 000 DATE_DIM 0,2 0,2 2 556 LINEORDER 42234,1 42279 600 019 253 PART 1772,6 1778,1 20 000 000 SUPPLIER 146,1 147,5 1 000 000


Enterprise Manager Cloud Control 12c Release 4

In-Memory Central


Enterprise Manager Cloud Control 12c Release 4


MIN / MAX


Выборка из Buffer Cache и In-Memory Column Store

Запуск-1 (с трассировкой) SQL> SELECT MAX(LO_ORDTOTALPRICE) AS most_expensive_order FROM lineorder;

MOST_EXPENSIVE_ORDER

--------------------

564829.26

Elapsed: 00:00:11.95 (12 s)

-----------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 6 | 41510 (31)| 00:00:04 |

| 1 | SORT AGGREGATE | | 1 | 6 | | |

| 2 | TABLE ACCESS INMEMORY FULL| LINEORDER | 600M| 3433M| 41510 (31)| 00:00:04 |

-----------------------------------------------------------------------------------------

4 recursive calls

0 db block gets

10 consistent gets

1 physical reads

0 redo size

230 bytes sent via SQL*Net to client

387 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed



Запуск-1 (с трассировкой) SQL> SELECT /*+ NO_INMEMORY */ MAX(LO_ORDTOTALPRICE) AS most_expensive_order FROM LINEORDER;


--------------------

564829.26

Elapsed: 00:01:34.95 (95 s)

--------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 6 | 1027K (2)| 00:01:21 |

| 1 | SORT AGGREGATE | | 1 | 6 | | |

| 2 | TABLE ACCESS FULL| LINEORDER | 600M| 3433M| 1027K (2)| 00:01:21 |

--------------------------------------------------------------------------------

4 recursive calls

0 db block gets

2703058 consistent gets

0 physical reads

0 redo size




0 sorts (memory)

0 sorts (disk)

1 rows processed

Buffer_cache/InMemory

= 95s/12s = 8



Запуск-2 (без трассировки) SQL> SELECT MAX(lo_ordtotalprice) AS MOST_EXPENSIVE_ORDER FROM lineorder;


--------------------

564829.26

Elapsed: 00:00:00.52 (1s)

SQL> SELECT /*+ NO_INMEMORY */ max(lo_ordtotalprice) most_expensive_order From LINEORDER;


--------------------

564829.26

Elapsed: 00:01:35.59 (96s)


= 96s/1s = 96



Запуск-3 SQL> SELECT MIN(lo_ordtotalprice) least_expensive_order FROM lineorder;

LEAST_EXPENSIVE_ORDER

---------------------

903.95

Elapsed: 00:00:00.50 (1s)

SQL> SELECT /*+ NO_INMEMORY */ MIN(lo_ordtotalprice) least_expensive_order FROM lineorder;

LEAST_EXPENSIVE_ORDER

---------------------

903.95

Elapsed: 00:01:34.98 (95s)


= 95s/1s = 95


In-Memory Column Store vs Buffer Cache


In-Memory Column Store vs Buffer Cache Statistics In-Memory Buffer Cache consistent gets 4 2 703 055 consistent gets from cache 4 2 703 055 consistent gets pin 4 2 703 055 consistent gets pin (fastpath) 4 2 703 055 CPU used by this session 2 899 9 517 CPU used when call started 2 899 9 517 DB time 2 900 9 517 IM scan bytes in-memory 36 353 580 495 0 IM scan bytes uncompressed 61 888 813 221 0 IM scan CUs columns accessed 1 058 0

IM scan CUs columns theoretical max 17 986 0

IM scan CUs memcompress for query low 1 058 0

IM scan CUs split pieces 1 073 0 IM scan rows 600 019 253 0 IM scan rows projected 600 019 253 0 IM scan rows valid 600 019 253 0 IM scan segments disk 0 1 logical read bytes from cache 65 536 44 286 853 120 no work - consistent read gets 0 2 702 974 table scans (IM) 1 0


Поиск по точному значению



SQL> -- In-Memory Column Store query

SQL> Select lo_orderkey, lo_custkey, lo_revenue From LINEORDER Where lo_orderkey = 5000000;

LO_ORDERKEY LO_CUSTKEY LO_REVENUE

----------- ---------- ----------

5000000 9532031 145267

. . .

Elapsed: 00:00:00.25 (1s)

SQL> -- Buffer Cache query with the column store disables via NO_INMEMORY hint

SQL> select /*+ NO_INMEMORY */ lo_orderkey, lo_custkey, lo_revenue

3 from LINEORDER where lo_orderkey = 5000000;


----------- ---------- ----------

5000000 9532031 145267

. . .

Elapsed: 00:01:30.60 (91s)


= 91s/1s = 91



Buffer Cache

-------------------------------------------------------------------------------


|* 1 | TABLE ACCESS FULL| LINEORDER | 4 | 76 | 1022K (1)| 00:01:20 |

-------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter("LO_ORDERKEY"=5000000)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

2703056 consistent gets

0 physical reads

0 redo size




0 sorts (memory)

0 sorts (disk)

5 rows processed


= 91s/1s = 91


Работа Storage Index


Использование Storage Index

IM scan CUs pruned 125

IM scan CUs columns accessed 935

IM scan segments minmax eligible 1058

Был доступ к 933 IMCU (1058 – 125 = 933)

плюс еще к двум для получения lo_custkey и lo_revenue

933 + 1 + 1 = 935


Индексный доступ или поиск в памяти?


Построен невидимый индекс

SQL> CREATE INDEX LINEORDER#I#LO_ORDERKEY

2 ON LINEORDER(LO_ORDERKEY)

3 INVISIBLE;

Index created.

Elapsed: 00:23:35.28

SQL> SELECT segment_name, ROUND(bytes/1024/1024) AS mbytes

2 FROM user_segments

3 WHERE segment_name = 'LINEORDER#I#LO_ORDERKEY';

SEGMENT_NAME MBYTES

----------------------- -------

LINEORDER#I#LO_ORDERKEY 11520 <-- 11.5 GB


In-Memory Scan

SQL> Select /* Without index */ lo_orderkey, lo_custkey, lo_revenue

2 From LINEORDER

3 Where lo_orderkey = 5000000;


----------- ---------- ----------

5000000 9532031 145267

. . .

Elapsed: 00:00:00.44

----------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

----------------------------------------------------------------------------------------


|* 1 | TABLE ACCESS INMEMORY FULL| LINEORDER | 4 | 76 | 41612 (32)| 00:00:04 |

----------------------------------------------------------------------------------------


Index Range Scan

SQL> ALTER SESSION SET OPTIMIZER_USE_INVISIBLE_INDEXES = TRUE;

Session altered.

SQL> Select /* With index */ lo_orderkey, lo_custkey, lo_revenue

2 From LINEORDER

3 Where lo_orderkey = 5000000;


----------- ---------- ----------

5000000 9532031 145267

. . .

Elapsed: 00:00:00.45

---------------------------------------------------------------------------------------------------------------


---------------------------------------------------------------------------------------------------------------


| 1 | TABLE ACCESS BY INDEX ROWID BATCHED| LINEORDER | 4 | 76 | 7 (0)| 00:00:01 |

|* 2 | INDEX RANGE SCAN | LINEORDER#I#LO_ORDERKEY | 4 | | 3 (0)| 00:00:01 |

---------------------------------------------------------------------------------------------------------------

SQL> ALTER SESSION SET OPTIMIZER_USE_INVISIBLE_INDEXES = FALSE;

Session altered.


In-Memory Scan vs Index Range Scan

SQL> SELECT segment_name, ROUND(bytes/1024/1024) AS mbytes

2 FROM user_segments

3 WHERE segment_name = 'LINEORDER#I#LO_ORDERKEY';

SEGMENT_NAME MBYTES

----------------------- -------

LINEORDER#I#LO_ORDERKEY 11520 <-- 11.5 GB

Время одинаковое, но индекс занимает место, замедляет

DML и его нужно администрировать: наблюдать,

перестраивать, собирать статистику и т.п.

Index range Scan/In-Memory Scan

= 0.44s/0.45s = 1


Множественные условия выборки


In-Memory Scan

SQL> Select lo_orderkey, lo_custkey, lo_revenue

2 From LINEORDER

3 Where lo_custkey = 5641

4 And lo_shipmode = 'XXX AIR'

5 And lo_orderpriority = '5-LOW';

no rows selected

Elapsed: 00:00:00.32 (1s)

----------------------------------------------------------------------------------------


----------------------------------------------------------------------------------------


|* 1 | TABLE ACCESS INMEMORY FULL| LINEORDER | 2 | 92 | 30248 (6)| 00:00:03 |

----------------------------------------------------------------------------------------


---------------------------------------------------

1 - inmemory("LO_CUSTKEY"=5641 AND "LO_SHIPMODE"='XXX AIR' AND

"LO_ORDERPRIORITY"='5-LOW')

filter("LO_CUSTKEY"=5641 AND "LO_SHIPMODE"='XXX AIR' AND



Buffer Cache

SQL> Select /*+ NO_INMEMORY */ lo_orderkey, lo_custkey, lo_revenue

2 From LINEORDER

3 Where lo_custkey = 5641

4 And lo_shipmode = 'XXX AIR'

5 And lo_orderpriority = '5-LOW';

no rows selected

Elapsed: 00:01:24.73 (85s)

-------------------------------------------------------------------------------


-------------------------------------------------------------------------------


|* 1 | TABLE ACCESS FULL| LINEORDER | 2 | 92 | 1032K (2)| 00:01:21 |

-------------------------------------------------------------------------------


---------------------------------------------------

1 - filter("LO_CUSTKEY"=5641 AND "LO_SHIPMODE"='XXX AIR' AND



= 85s/1s = 85


Выборка не по равенству


In-Memory Scan

Scale Factor 100 GB SQL> Select max(lo_supplycost) most_expensive_bluk_order

2 From LINEORDER

3 Where lo_quantity > 49;

MOST_EXPENSIVE_BLUK_ORDER

-------------------------

1000

Elapsed: 00:00:01.89 (2s)

-----------------------------------------------------------------------------------------


-----------------------------------------------------------------------------------------


| 1 | SORT AGGREGATE | | 1 | 8 | | |

|* 2 | TABLE ACCESS INMEMORY FULL| LINEORDER | 12M| 93M| 39671 (28)| 00:00:04 |

-----------------------------------------------------------------------------------------


---------------------------------------------------

2 - inmemory("LO_QUANTITY">49)

filter("LO_QUANTITY">49)


Buffer Cache

Scale Factor 100 GB SQL> SELECT /*+ NO_INMEMORY */

2 max(lo_supplycost) most_expensive_bluk_order

3 From LINEORDER

4 Where lo_quantity > 49;

MOST_EXPENSIVE_BLUK_ORDER

-------------------------

1000

Elapsed: 00:01:27.86

--------------------------------------------------------------------------------


--------------------------------------------------------------------------------


| 1 | SORT AGGREGATE | | 1 | 8 | | |

|* 2 | TABLE ACCESS FULL| LINEORDER | 12M| 93M| 1027K (2)| 00:01:21 |

--------------------------------------------------------------------------------


---------------------------------------------------

2 - filter("LO_QUANTITY">49)


= 88s/2s = 44


Более сложная выборка


In-Memory Scan

SQL> Select lo_orderkey, lo_revenue

2 From LINEORDER

3 Where lo_revenue = (Select min(lo_revenue)

4 From LINEORDER

5 Where lo_supplycost = (Select max(lo_supplycost)

6 From LINEORDER

7 Where lo_quantity > 10)

8 And lo_shipmode LIKE 'TRUCK%'

9 And lo_discount between 2 and 5);

no rows selected

Elapsed: 00:00:39.82 (40s)

--------------------------------------------------------------------------------------------


--------------------------------------------------------------------------------------------


|* 1 | TABLE ACCESS INMEMORY FULL | LINEORDER | 44 | 572 | 39609 (28)| 00:00:04 |

| 2 | SORT AGGREGATE | | 1 | 25 | | |

|* 3 | TABLE ACCESS INMEMORY FULL | LINEORDER | 78 | 1950 | 30248 (6)| 00:00:03 |

| 4 | SORT AGGREGATE | | 1 | 8 | | |


--------------------------------------------------------------------------------------------


Buffer Cache

SQL> SELECT /*+ NO_INMEMORY */ lo_orderkey, lo_revenue

2 From LINEORDER

3 Where lo_revenue = (Select /*+ NO_INMEMORY */ min(lo_revenue)

4 From LINEORDER

5 Where lo_supplycost = (Select /*+ NO_INMEMORY */ max(lo_supplycost)

6 From LINEORDER

7 Where lo_quantity > 10)

8 And lo_shipmode LIKE 'TRUCK%'

9 And lo_discount between 2 and 5);

no rows selected

Elapsed: 00:03:02.45 (182s)

-----------------------------------------------------------------------------------


-----------------------------------------------------------------------------------


|* 1 | TABLE ACCESS FULL | LINEORDER | 44 | 572 | 1030K (2)| 00:01:21 |

| 2 | SORT AGGREGATE | | 1 | 25 | | |

|* 3 | TABLE ACCESS FULL | LINEORDER | 78 | 1950 | 1032K (2)| 00:01:21 |

| 4 | SORT AGGREGATE | | 1 | 8 | | |


-----------------------------------------------------------------------------------


= 182s/40s = 4,5


Соединения и агрегация


Соединять или фильтровать? To join or to filter?


Filter Create – Filter Use

SQL> Select sum(lo_extendedprice * lo_discount) revenue

2 From LINEORDER l, DATE_DIM d

3 Where l.lo_orderdate = d.d_date_as_date

4 And l.lo_discount between 0.02 and 0.03

5 And l.lo_quantity < 24

6 And d.d_date='December 24, 1996';

REVENUE

----------

9751240

Elapsed: 00:00:01.35 (2s)

-------------------------------------------------------------------------------------------


-------------------------------------------------------------------------------------------


| 1 | SORT AGGREGATE | | 1 | 48 | | |

|* 2 | HASH JOIN | | 33003 | 1547K| 47924 (41)| 00:00:04 |

| 3 | JOIN FILTER CREATE | :BF0000 | 1 | 28 | 1 (0)| 00:00:01 |

|* 4 | TABLE ACCESS INMEMORY FULL| DATE_DIM | 1 | 28 | 1 (0)| 00:00:01 |

| 5 | JOIN FILTER USE | :BF0000 | 79M| 1513M| 47503 (40)| 00:00:04 |


-------------------------------------------------------------------------------------------


Hash Join

SQL> SELECT /*+ NO_INMEMORY */

2 SUM(lo_extendedprice * lo_discount) revenue

3 FROM lineorder l,

4 date_dim d

5 WHERE l.lo_orderdate = d.d_date_as_date

6 AND l.lo_discount BETWEEN 0.02 AND 0.03

7 AND l.lo_quantity < 24

8 AND d.d_date='December 24, 1996';

REVENUE

----------

9751240

Elapsed: 00:01:54.97 (95s)

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------


| 1 | SORT AGGREGATE | | 1 | 48 | | |

|* 2 | HASH JOIN | | 33003 | 1547K| 1030K (2)| 00:01:21 |

|* 3 | TABLE ACCESS FULL| DATE_DIM | 1 | 28 | 6 (0)| 00:00:01 |


---------------------------------------------------------------------------------


= 95s/2s = 48


Filter Create – Filter Use - 3 PARALLEL(2)

SQL> Select /*+ PARALLEL(2) */ p.p_name, sum(l.lo_revenue)

2 From LINEORDER l, DATE_DIM d, PART p

3 Where l.lo_orderdate = d.d_date_as_date And l.lo_partkey = p.p_partkey

5 and p.p_type = 'PROMO BRUSHED STEEL' And d.d_year = 1996 And d.d_month = 'December'

8 Group by p.p_name;

5800 rows selected.

Elapsed: 00:00:21.98 (22s) ----------------------------------------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |

----------------------------------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 45681 | 4684K| | 30192 (44)| 00:00:03 | | | |

| 1 | PX COORDINATOR | | | | | | | | | |

| 2 | PX SEND QC (RANDOM) | :TQ10001 | 45681 | 4684K| | 30192 (44)| 00:00:03 | Q1,01 | P->S | QC (RAND) |

| 3 | HASH GROUP BY | | 45681 | 4684K| 5200K| 30192 (44)| 00:00:03 | Q1,01 | PCWP | |

| 4 | PX RECEIVE | | 45681 | 4684K| | 30192 (44)| 00:00:03 | Q1,01 | PCWP | |

| 5 | PX SEND HASH | :TQ10000 | 45681 | 4684K| | 30192 (44)| 00:00:03 | Q1,00 | P->P | HASH |

| 6 | HASH GROUP BY | | 45681 | 4684K| 5200K| 30192 (44)| 00:00:03 | Q1,00 | PCWP | |

|* 7 | HASH JOIN | | 45681 | 4684K| | 29849 (45)| 00:00:03 | Q1,00 | PCWP | |

| 8 | JOIN FILTER CREATE | :BF0000 | 27 | 621 | | 2 (0)| 00:00:01 | Q1,00 | PCWP | |

|* 9 | TABLE ACCESS INMEMORY FULL | DATE_DIM | 27 | 621 | | 2 (0)| 00:00:01 | Q1,00 | PCWP | |

|* 10 | HASH JOIN | | 4126K| 322M| | 29836 (45)| 00:00:03 | Q1,00 | PCWP | |

| 11 | JOIN FILTER CREATE | :BF0001 | 133K| 8072K| | 954 (25)| 00:00:01 | Q1,00 | PCWP | |

|* 12 | TABLE ACCESS INMEMORY FULL | PART | 133K| 8072K| | 954 (25)| 00:00:01 | Q1,00 | PCWP | |

| 13 | JOIN FILTER USE | :BF0000 | 600M| 11G| | 27293 (42)| 00:00:03 | Q1,00 | PCWP | |

| 14 | JOIN FILTER USE | :BF0001 | 600M| 11G| | 27293 (42)| 00:00:03 | Q1,00 | PCWP | |

| 15 | PX BLOCK ITERATOR | | 600M| 11G| | 27293 (42)| 00:00:03 | Q1,00 | PCWC | |

|* 16 | TABLE ACCESS INMEMORY FULL| LINEORDER | 600M| 11G| | 27293 (42)| 00:00:03 | Q1,00 | PCWP | |

----------------------------------------------------------------------------------------------------------------------------------------


Database In-Memory When will an object benefit from being in the IM column store?

Storing a database object in the IM column store can improve

performance significantly for the following types of operations performed

on the database object: – A query that scans a large number of rows and applies filters that use

operators such as the following: =, <, >, and IN

– A query that selects a small number of columns from a table or materialized

view with a large number of columns, such as a query that selects five

columns from a table with 100 columns

– A query that joins a small table to a large table

– A query that aggregates data

9

3


Database In-Memory When will an object not benefit from being in the IM column store?

– Queries with complex predicates

– Queries that select a large number of columns

– Queries that return a large number of rows

– Queries with multiple large table joins

9

4


Заключение


Наблюдения-выводы

– Database In-Memory – это панацея от многих, но не от всех бед

– При адекватном применении Database In-Memory дает огромный

прирост производительности запросов

– Упразднение индексов для поиска данных в хранилище (DWH)

существенно повышает скорость выполнения операций

запоминания (INSERT, UPDATE, DELETE)

Не снижает скорость выполнения запросов, поскольку выборка

средствами In-Memory, как минимум, не медленнее индексного

доступа

– Не стоит "пихать" In-Memory "во все углы", т.к. некоторые углы могут

"рассыпаться" :-(

– Никогда не забываем: Все проблемы решаемы при вдумчивой

аккуратной работе!

9

6


"Каждому делу учиться надо!" (с) Незнайка из Цветочного города


Приходите в наш Центр решений! Все покрутим, повертим, попробуем! У нас есть чему и на чём поучиться!

(с) Валерий Юринский и все, все, все ФОРС


"ФОРС Дистрибуция"

http://www.partner.fors.ru

129626, Москва,

Графский переулок, 14, стр. 2

Телефон: +7 (495) 913-3-913

Oracle Partner Hub

Центр решений ФОРС

ФОРС ExaStack Studio

http://exastack.ru

db in-memory-overview 2015-10_14

Software