Transcript
www.partner.fors.ru 1
Новая опция Oracle Database 12c In-Memory
Валерий Юринский Директор отделения технологического консалтинга
vyourinsky@fors.ru
14 октября 2015 г.
www.partner.fors.ru 2
План
Введение
Oracle Database In-Memory Option
Несколько примеров
Заключение
www.partner.fors.ru 3
Введение
www.partner.fors.ru 4
Оперативная память: тренды и влияние Сегодня память быстрее, дешевле и ее объем больше
Объемы памяти растут
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:
www.partner.fors.ru 5
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
www.partner.fors.ru 6
Приходилось выбирать один формат и идти на компромиссы
Давнее противоречие Строчный формат и поколоночный формат
Row
OLTP-операции работают быстрее со построчным форматом
– Пример: Выборка или добавление заказа
– Быстрая обработка немного строк, много столбцов
Column
Аналитика работает быстрее с поколоночным форматом
– Пример: Отчет о сумме продаж по штату
– Быстрый доступ немного столбцов, много строк
ORDER
SALES
SALES
S
T
A
T
E
www.partner.fors.ru 7
Давнее противоречие Строчный формат и поколоночный формат
Row
Выборка одного заказа в построчном формате
- Обращение к одной непрерывной строке
= БЫСТРО
Column
Выборка одного заказа в поколоночном формате
- Обращение к нескольким столбцам
= М Е Д Л Е Н Н О
SALES
Stores SALES
Query
Query Query
Query
Query
Приходилось выбирать один формат и идти на компромиссы
www.partner.fors.ru 8
Database In-Memory Option
www.partner.fors.ru 9
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)
www.partner.fors.ru 10
Аналитика в
реальном
времени
Неизменность приложений
Простота
внедрения
100x 2x
10
Задачи Oracle Database In-Memory
Призводитель-
ность при сме-
шаной нагрузке
www.partner.fors.ru 11
Задачи Oracle Database In-Memory Option
В 100 раз быстрее запросы для аналитики в
реальном времени
Мгновенное получение результата
Запросы к OLTP базе или хранилищу данных
Актуальные данные в результатах!
В 2 раза ускоряется обработка транзакций
Вставка строк в 3 – 4 раза быстрее
www.partner.fors.ru 12
Прорыв: база данных с двойным форматом
• Использует OБA (два) формата
для одной таблицы: строчный и
поколоночный • Работают совместно,
транзакционно согласованы
• Аналитика и отчетность
используют новый
поколоночный формат In-
Memory
• OLTP использует проверенный
построчный формат
1
2
Обычный Buffer Cache
Новый формат In-Memory
SALES SALES
Строчный формат
Поколоночный формат
SALES
www.partner.fors.ru 13
Oracle In-Memory Columnar Technology
Оперативная память
Истинно поколоночный
In-Memory Column Store (IMCS) -
постолбцовое оперативное
хранилище
Истинно поколоночное (pure
columnar) хранение в памяти
изменяемые данные
нет генерации REDO-данных
Минимальные затраты на
изменения – даже для OLTP-
транзакций
Данные загружаются в кэш при
первом обращении
www.partner.fors.ru 14
И строчный, и поколоночный
формат хранения в памяти для
одних и тех же данных/таблиц
Данные одновременно активны
и транзакционно согласованы
В 100 раз быстрее аналитика &
отчетность: поколоночный
формат
В 2 раза быстрее OLTP:
строчный формат
In-Memory Option: Оба формата в памяти СУБД
Column
Format
Memory
Row
Format
Memory
Analytics OLTP Sales Sales
www.partner.fors.ru 15
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
DBWR SMON PMON CKPT LGWR Others
www.partner.fors.ru 16
Oracle In-Memory: отдельный кэш в SGA
Instance
SGA
Redo log
buffer cache
Shared pool
Data Dict.
cache
Library
cache
DBWR SMON PMON CKPT LGWR Others
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
DBWR SMON PMON CKPT LGWR Others
In-row
buffer cache
In-Memory
Columnar
Cache
Статический параметр INMEMORY_SIZE
www.partner.fors.ru 17
Статический пул в 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
www.partner.fors.ru 18
Почему сканирование In-Memory быстрее чем в буферном кэше?
SELECT COL4 FROM MYTABLE;
1
8
X X X X X
РЕЗУЛЬТАТ
Строчный формат
Буферный кэш
www.partner.fors.ru 19
SELECT COL4 FROM MYTABLE;
1
9
RESULT
Колоночный формат
In-Memory кэш
РЕЗУЛЬТАТ
X X X X
Почему сканирование In-Memory быстрее чем в буферном кэше?
www.partner.fors.ru 20
Включение постолбцового представления для таблицы или 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.
•Служебные столбцы – не
участвуют в отчетах:
нужны только для бизнес-
логики
www.partner.fors.ru 21
Включение постолбцового представления для табличного пространства и секции
Все таблицы и 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);
www.partner.fors.ru 22
Изменение плана запроса 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 | |
---------------------------------------------------------------------
www.partner.fors.ru 23
Сканирование миллиарда строк в секунду на процессорном ядре
SIMD
Compare all
values in 1
cycle
Сравнение
всех
значений за
один цикл
Загрузка
значений
множества
штатов
Vecto
r
Reg
iste
r
In-Memory Column Store
State column Sales
Пример: Найти все продажи в штате CA
“CA”
более чем в 100
раз быстрее
• Каждое процессорное ядро
сканирует одну колонку
• При сканировании
используются быстрые
векторные SIMD-
инструкции
• Миллиарды строк в
секунду сканируются
одним ядром CPU
www.partner.fors.ru 24
При первом обращении к сегменту для которого включен атрибут
in-memory начинается наполнение постолбцового оперативного
хранилища (In-Memory Column Store = IMCS)
Oracle In-Memory: “разогрев” IMCS
www.partner.fors.ru 25
Сканирование и соединение данных из нескольких таблиц
Продажи Магазины
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
www.partner.fors.ru 26
Multiple Bloom Filter Несколько соединений с использованием In-Memory
www.partner.fors.ru 28
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
www.partner.fors.ru 29
Cжатие столбцов в IMCS - пример
Сжатие разными методами для группы столбцов
SQL> ALTER TABLE cities
INMEMORY
INMEMORY MEMCOMPRESS FOR CAPACITY HIGH(Country_Id, Time_Zone)
INMEMORY NO MEMCOMPRESS (Id, Name, Name_Eng);
Table altered.
•Уникальные столбцы – не
сжимаются!
www.partner.fors.ru 30
Поддержка в 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;
www.partner.fors.ru 31
Атрибут 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
www.partner.fors.ru 32
Системное представление [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
Мониторинг использования кэша
www.partner.fors.ru 33
Управление приоритетом загрузки в кэш
Приоритет Синтаксис Описание
• NONE
(default)
PRIORITY NONE • Приоритет загрузки определяется СУБД. Загрузка может быть задержана, если память используется для другого более приоритетного сегмента. - Запрос переключаетcя на обычный (in-row) кэш.
• LOW PRIORITY LOW • Низкий приоритет
• MEDIUM PRIORITY MEDIUM • Средний приоритет
• HIGH PRIORITY HIGH • Высокий приоритет
• CRITICAL PRIORITY CRITICAL • Наивысший приоритет
www.partner.fors.ru 34
Приоритет загрузки в IMCS - пример
Один приоритет для всей таблицы/секции/мат. представления
SQL> ALTER TABLE cities
INMEMORY
PRIORITY CRITICAL
INMEMORY MEMCOMPRESS FOR CAPACITY HIGH(Country_Id, Time_Zone)
INMEMORY MEMCOMPRESS NO (Id, Name, Name_Eng);
Table altered.
www.partner.fors.ru 35
OLTP работает медленно из-за аналитических индексов
Таблица 1 - 3
OLTP
индекса
10 - 20
аналитических
индексов Большинство индексов в OLTP
(например, в ERP) базах
строится только для
аналитических запросов
Индексы хорошо подходят для
предсказуемых запросов (и в
памяти, и на диске)
Вставка одной строки в таблицу
приводит к обновлению 10-20
аналитических индексов:
Медленно!
Поколоночное
хранение в памяти
www.partner.fors.ru 36
Oracle In-Memory – высокая доступность
Представление по столбцам в
памяти не влияет на формат данных
на диске: datafiles, logging, backup,
recovery, и т.д.
Все технологии, в том числе ASM,
RAC, DG, GG работают прозрачно
для In-Memory Option
Защита от любых видов ошибок
• На уровне железа
• Логические ошибки
приложения (Flashback)
RAC
ASM
RMAN
Data Guard & GoldenGate
www.partner.fors.ru 37
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
www.partner.fors.ru 38
Полный синтаксис кэширования таблицы
Мощный и гибкий синтаксис
SQL> ALTER TABLE cities
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.
www.partner.fors.ru 39
Подсказки для оптимизатора Включение/выключение 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
www.partner.fors.ru 40
Хранит минимальное
и максимальное
значение столбца в
каждом экстенте
памяти кэша
Прозрачно исключает
ненужные
сканирования столбцов,
например:
WHERE prod_id > 14
AND prod_id < 29
Storage Index в In-Memory Columnar Store
www.partner.fors.ru 41
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
www.partner.fors.ru 42
DML and the In-Memory Column Store
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/
www.partner.fors.ru 43
DML and the In-Memory Column Store
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
www.partner.fors.ru 44
JOURNAL
DML and the In-Memory Column Store
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
www.partner.fors.ru 45
JOURNAL
DML and the In-Memory Column Store
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
www.partner.fors.ru 46
DML and the In-Memory Column Store
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
www.partner.fors.ru 47
Space Manager
Управляет памятью в In-
Memory Column Store
(create, extend, drop)
Загружает данные в кэш
Transaction Manager
Обеспечивает
согласованность данных
в In-Memory Column
Store с буферным
кэшем
Обеспечивает
версионность
In-Memory Option - архитектура
www.partner.fors.ru 48
Новые параметры в 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
www.partner.fors.ru 49
Для каких приложений подходит Database In-Memory Option?
Если в приложении есть много запросов сканирующих много строк
с фильтрами такими как: “=, <, >, и IN”
Запрашивает всего лишь несколько столбцов, напр: 5 столбцов из
100 столбцов таблицы
Приложение часто делает соединение большой таблицы фактов с
таблицами измерений с фильтрами по ним (выборка не по всем
значениям измерений, а по их части)
Типы приложений предпочтительные для использования In-
Memory Option: – хранилища данных (Data Warehouse)
– cмешанного типа (Mixed Application)
www.partner.fors.ru 50
Oracle In-Memory Options не требует изменения приложений
Полная функциональность - Нет ограничений на SQL
Простота реализации - Не нужна миграция данных
Полная совместимость - Не надо изменять приложения
Полностью Multitenant - Oracle In-Memory готова для cloud
Приложения получают все преимущества In-Memory опции без изменения кода приложения
www.partner.fors.ru 51
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
www.partner.fors.ru 52
Oracle Database In-Memory Advisor (Doc ID 1965343.1)
Пример рекомендаций
www.partner.fors.ru 53
Несколько примеров
www.partner.fors.ru 54
Тестовый стенд
Сервер 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
www.partner.fors.ru 55
Данные для "тренировочных забегов" в 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
www.partner.fors.ru 56
In-Memory Column Store
Конфигурирование 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)
www.partner.fors.ru 57
Заполнение 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;
www.partner.fors.ru 58
Заполнение Buffer Cache и In-Memory Column Store
In-Memory Column Store
-- Заполнение 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;
www.partner.fors.ru 59
Заполнение Buffer Cache и In-Memory Column Store
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
www.partner.fors.ru 60
Enterprise Manager Cloud Control 12c Release 4
In-Memory Central
www.partner.fors.ru 61
Enterprise Manager Cloud Control 12c Release 4
www.partner.fors.ru 62
MIN / MAX
www.partner.fors.ru 63
Выборка из 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
www.partner.fors.ru 64
Выборка из Buffer Cache и In-Memory Column Store
Запуск-1 (с трассировкой) SQL> SELECT /*+ NO_INMEMORY */ MAX(LO_ORDTOTALPRICE) AS most_expensive_order FROM LINEORDER;
MOST_EXPENSIVE_ORDER
--------------------
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
245 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
Buffer_cache/InMemory
= 95s/12s = 8
www.partner.fors.ru 65
Выборка из Buffer Cache и In-Memory Column Store
Запуск-2 (без трассировки) SQL> SELECT MAX(lo_ordtotalprice) AS MOST_EXPENSIVE_ORDER FROM lineorder;
MOST_EXPENSIVE_ORDER
--------------------
564829.26
Elapsed: 00:00:00.52 (1s)
SQL> SELECT /*+ NO_INMEMORY */ max(lo_ordtotalprice) most_expensive_order From LINEORDER;
MOST_EXPENSIVE_ORDER
--------------------
564829.26
Elapsed: 00:01:35.59 (96s)
Buffer_cache/InMemory
= 96s/1s = 96
www.partner.fors.ru 66
Выборка из Buffer Cache и In-Memory Column Store
Запуск-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)
Buffer_cache/InMemory
= 95s/1s = 95
www.partner.fors.ru 67
In-Memory Column Store vs Buffer Cache
www.partner.fors.ru 68
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
www.partner.fors.ru 69
Поиск по точному значению
www.partner.fors.ru 70
Выборка из Buffer Cache и In-Memory Column Store
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;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ---------- ----------
5000000 9532031 145267
. . .
Elapsed: 00:01:30.60 (91s)
Buffer_cache/InMemory
= 91s/1s = 91
www.partner.fors.ru 71
Выборка из Buffer Cache и In-Memory Column Store
Buffer Cache
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4 | 76 | 1022K (1)| 00:01:20 |
|* 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
332 bytes sent via SQL*Net to client
388 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
5 rows processed
Buffer_cache/InMemory
= 91s/1s = 91
www.partner.fors.ru 72
Работа Storage Index
www.partner.fors.ru 73
Использование 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
www.partner.fors.ru 74
Индексный доступ или поиск в памяти?
www.partner.fors.ru 75
Построен невидимый индекс
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
www.partner.fors.ru 76
In-Memory Scan
SQL> Select /* Without index */ lo_orderkey, lo_custkey, lo_revenue
2 From LINEORDER
3 Where lo_orderkey = 5000000;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ---------- ----------
5000000 9532031 145267
. . .
Elapsed: 00:00:00.44
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4 | 76 | 41612 (32)| 00:00:04 |
|* 1 | TABLE ACCESS INMEMORY FULL| LINEORDER | 4 | 76 | 41612 (32)| 00:00:04 |
----------------------------------------------------------------------------------------
www.partner.fors.ru 77
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;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ---------- ----------
5000000 9532031 145267
. . .
Elapsed: 00:00:00.45
---------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4 | 76 | 7 (0)| 00:00:01 |
| 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.
www.partner.fors.ru 78
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
www.partner.fors.ru 79
Множественные условия выборки
www.partner.fors.ru 80
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)
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 92 | 30248 (6)| 00:00:03 |
|* 1 | TABLE ACCESS INMEMORY FULL| LINEORDER | 2 | 92 | 30248 (6)| 00:00:03 |
----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
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
"LO_ORDERPRIORITY"='5-LOW')
www.partner.fors.ru 81
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)
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 92 | 1032K (2)| 00:01:21 |
|* 1 | TABLE ACCESS FULL| LINEORDER | 2 | 92 | 1032K (2)| 00:01:21 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("LO_CUSTKEY"=5641 AND "LO_SHIPMODE"='XXX AIR' AND
"LO_ORDERPRIORITY"='5-LOW')
Buffer_cache/InMemory
= 85s/1s = 85
www.partner.fors.ru 82
Выборка не по равенству
www.partner.fors.ru 83
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)
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 39671 (28)| 00:00:04 |
| 1 | SORT AGGREGATE | | 1 | 8 | | |
|* 2 | TABLE ACCESS INMEMORY FULL| LINEORDER | 12M| 93M| 39671 (28)| 00:00:04 |
-----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - inmemory("LO_QUANTITY">49)
filter("LO_QUANTITY">49)
www.partner.fors.ru 84
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
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 1027K (2)| 00:01:21 |
| 1 | SORT AGGREGATE | | 1 | 8 | | |
|* 2 | TABLE ACCESS FULL| LINEORDER | 12M| 93M| 1027K (2)| 00:01:21 |
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("LO_QUANTITY">49)
Buffer_cache/InMemory
= 88s/2s = 44
www.partner.fors.ru 85
Более сложная выборка
www.partner.fors.ru 86
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)
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 44 | 572 | 112K (24)| 00:00:09 |
|* 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 | | |
|* 5 | TABLE ACCESS INMEMORY FULL| LINEORDER | 489M| 3736M| 42200 (33)| 00:00:04 |
--------------------------------------------------------------------------------------------
www.partner.fors.ru 87
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)
-----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 44 | 572 | 3092K (2)| 00:04:02 |
|* 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 | | |
|* 5 | TABLE ACCESS FULL| LINEORDER | 489M| 3736M| 1030K (2)| 00:01:21 |
-----------------------------------------------------------------------------------
Buffer_cache/InMemory
= 182s/40s = 4,5
www.partner.fors.ru 88
Соединения и агрегация
www.partner.fors.ru 89
Соединять или фильтровать? To join or to filter?
www.partner.fors.ru 90
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)
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 48 | 47924 (41)| 00:00:04 |
| 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 |
|* 6 | TABLE ACCESS INMEMORY FULL| LINEORDER | 79M| 1513M| 47503 (40)| 00:00:04 |
-------------------------------------------------------------------------------------------
www.partner.fors.ru 91
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)
---------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 48 | 1030K (2)| 00:01:21 |
| 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 |
|* 4 | TABLE ACCESS FULL| LINEORDER | 79M| 1513M| 1030K (2)| 00:01:21 |
---------------------------------------------------------------------------------
Buffer_cache/InMemory
= 95s/2s = 48
www.partner.fors.ru 92
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 | |
----------------------------------------------------------------------------------------------------------------------------------------
www.partner.fors.ru 93
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
www.partner.fors.ru 94
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
www.partner.fors.ru 95
Заключение
www.partner.fors.ru 96
Наблюдения-выводы
– Database In-Memory – это панацея от многих, но не от всех бед
– При адекватном применении Database In-Memory дает огромный
прирост производительности запросов
– Упразднение индексов для поиска данных в хранилище (DWH)
существенно повышает скорость выполнения операций
запоминания (INSERT, UPDATE, DELETE)
Не снижает скорость выполнения запросов, поскольку выборка
средствами In-Memory, как минимум, не медленнее индексного
доступа
– Не стоит "пихать" In-Memory "во все углы", т.к. некоторые углы могут
"рассыпаться" :-(
– Никогда не забываем: Все проблемы решаемы при вдумчивой
аккуратной работе!
9
6
www.partner.fors.ru 97
"Каждому делу учиться надо!" (с) Незнайка из Цветочного города
www.partner.fors.ru 98
Приходите в наш Центр решений! Все покрутим, повертим, попробуем! У нас есть чему и на чём поучиться!
(с) Валерий Юринский и все, все, все ФОРС
www.partner.fors.ru 99
"ФОРС Дистрибуция"
http://www.partner.fors.ru
129626, Москва,
Графский переулок, 14, стр. 2
Телефон: +7 (495) 913-3-913
Oracle Partner Hub
Центр решений ФОРС
ФОРС ExaStack Studio
http://exastack.ru
www.partner.fors.ru 102
top related