The document discusses best practices for using Oracle Database In-Memory. It provides an overview of In-Memory and describes how to configure and populate the In-Memory Column Store. It also discusses how the optimizer utilizes In-Memory statistics and hints to optimize queries for In-Memory. Several examples of queries that benefit from In-Memory, such as aggregation queries and queries with predicates, are also provided.

1. Do’s and Don’ts of
Oracle Database In-Memory
Jorge Barba
Infrastructure Principal at Accenture Enkitec Group
https://jorgebarbablog.wordpress.com
Email: jorge.barba@accenture.com
Mar 2016

2. Agenda
2
A. Overview
B. Configuration
C. Optimizer
D. Queries
E. Usage with Oracle Technologies
F. Do's and Don'ts
G. Conclusion

3. Overview

4. 4
Database In-Memory
In-Memory Column Store is an optional,
static SGA pool that stores segments in
columnar format.
It is a supplement to the Buffer Cache.
The database keeps the columnar data
transactionally consistent with the Buffer
Cache.

5. 5
Row Format vs. Column Format
Transactions run faster on row format
Example: Query or Insert a sales order
Fast processing a few rows, many columns.
Analytics run faster on column format
Example: Report on sales totals by region
Fast accessing few columns, many rows

6. 6
Dual Format Database
Same table on both formats
Analytics use the new in-memory Column Format
OLTP uses the Row Format

7. 7
Scanning Memory
Buffer Cache
Have to walk along that row until we find
col4.
IM Column Store
Go directly to the col4 structure and scan
all the entries.

8. 8
Storage Index
Storage Indexes
Automatically created and maintained
for each column in the Column Store.
Allow data pruning based on filter
predicates in the SQL statement.
Keeps track of minimum and maximum
values for each column in an IMCU.
If the column value is outside the
minimum and maximum range for an
IMCU, the scan of that IMCU is
avoided.

9. 9
In-Memory Join and Bloom Filter (BF)
• A Bloom filter transforms a join into a filter that can be
applied as part of the scan of the larger table.
• Very efficiently applied to column format data via SIMD
vector processing.
• Appears in two places, at creation time and again
when it is applied.
SELECT count(*)
FROM lineorder lo, part p
WHERE lo.lo_partkey=p.p_partkey
AND lo.lo_shipmode='TRUCK'
AND lo.lo_ordtotalprice between
55000000 and 56000000
AND p.p_name='papaya burlywood’;

10. 10
Vector Group By
• New optimizer transformation introduced with Oracle 12.1.0.2.0.
• Find the total sales of footwear products in outlet stores.
• The combination of these two phases dramatically improves the efficiency of a
multiple table join with complex aggregations.
| 9 | KEY VECTOR (USE) | :KV0000
| 10 | KEY VECTOR (USE) | :KV0001

11. 11
SIMD Single Instruction Multiple Data
SIMD
A set of column values are evaluated together in a
single CPU instruction.
Designed to maximize the number of column
entries loaded and evaluated in a single CPU
instruction.
8 entries are loaded into the register for evaluation.

12. Configuration

13. 13
Configuring the In-Memory Column Store
Configuration
• INMEMORY_SIZE=1520M
• Minimum of 100M
• Part of the SGA
• Fixed size
SQL> select * from v$sga;
NAME VALUE
-------------------- ----------
Fixed Size 2932632
Variable Size 587202664
Database Buffers 2097152000
Redo Buffers 13844480
In-Memory Area 1593835520
alter system set inmemory_size=1520M scope=spfile;
shutdown immediate;
startup

14. 14
Populating the In-Memory Column Store
ALTER TABLE lineorder INMEMORY;
ALTER TABLE lineorder NO INMEMORY;
CREATE TABLE customer …
PARTITION BY LIST
(PARTITION p1 …… INMEMORY,
PARTITION p2 …… NO INMEMORY);
Eligible segments are:
• Tables
• Partitions
• Subpartitions
• Materialized Views
Not supported:
• IOTs, Hash clusters, Out of line
LOBs.

15. 15
Composition of In-Memory Area and DML
SQL> select pool, alloc_bytes
2 from v$inmemory_area;
POOL ALLOC_BYTES
-------------- -----------
1MB POOL 1274019840
64KB POOL 301989888

16. 16
Composition of In-Memory Area and DML
• Bulk Data Loads
• Typically conducted as a direct path load.
• The size of the missing data will be visible in
the BYTES_NOT_POPULATED column (V
$IM_SEGMENTS).
• Partition Exchange Loads
• Partition big tables or fact tables.
• Transaction Processing
• Single row data change operations (DML)
execute via the Buffer Cache.

17. 17
Repopulation
• Oracle Database will repopulate an IMCU when the
number of entries reaches a threshold.
• Repopulation is more frequent for IMCUs that are
accessed frequently or have higher percentage of stale
rows.
• Also the IMCO background process may also
repopulate.

18. 18
Overhead
• Keeping the IM Column Store
transactionally consistent.
• Rate of change, compression level,
location of the changed rows, type of
operations being performed.

19. Optimizer

20. 20
Optimizer
1. In 12c the optimizer is fully aware of the In-
Memory Column Store. This means that the
optimizer will cost the read from the In-
memory Column Store.
2. Using the same statistics and also new In-
Memory statistics

21. 21
Optimizer 10053 trace
SELECT /* opt_trace_test */ sum(lo_revenue)
FROM lineorder lo, customer c
WHERE lo.lo_custkey=c.c_custkey
AND c_region='AFRICA';
column sql_text format a30
select sql_id, child_number,
sql_text from v$sql
where sql_text like
'%opt_trace_test%';
SQL_ID
-------------
5b8n5m6gtx71r

22. 22
Optimizer 10053 trace (cont)
alter session set max_dump_file_size = unlimited;
execute DBMS_SQLDIAG.DUMP_TRACE(-
p_sql_id='5b8n5m6gtx71r', -
p_child_number=0, -
p_component='Optimizer', -
p_file_id='TRACE_10053');
How to Obtain Tracing of Optimizer Computations (EVENT 10053) (Doc ID 225598.1)
col value format a90
SELECT value
FROM v$diag_info
WHERE name='Default Trace File';
VALUE
---------------------------------------------------------------------------------------
/u01/app/oracle/diag/rdbms/db_inst2/DBNAME/trace/DB_INST2_ora_130114_TRACE_10053.trc

23. 23
Optimizer 10053 trace (cont)
***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
Table: CUSTOMER Alias: C
#Rows: 120000 SSZ: 0 LGR: 0 #Blks: 1882 AvgRowLen: 107.00 NEB: 0 ChainCnt:
0.00 SPC: 0 RFL: 0 RNF: 0 CBK: 0 CHR: 0 KQDFLG: 1
#IMCUs: 1 IMCRowCnt: 120000 IMCJournalRowCnt: 3000 #IMCBlocks: 0 IMCQuotient:
1.000000
Column (#1): C_CUSTKEY(NUMBER)
AvgLen: 5 NDV: 120000 Nulls: 0 Density: 0.000008 Min: 1.000000 Max: 120000.000000
***********************
Table Stats::
Table: LINEORDER Alias: LO
#Rows: 23996670 SSZ: 0 LGR: 0 #Blks: 335060 AvgRowLen: 96.00 NEB: 0 ChainCnt:
0.00 SPC: 0 RFL: 0 RNF: 0 CBK: 0 CHR: 0 KQDFLG: 1
#IMCUs: 23 IMCRowCnt: 23996670 IMCJournalRowCnt: 599917 #IMCBlocks: 0
IMCQuotient: 1.000000
Column (#3): LO_CUSTKEY(NUMBER)
AvgLen: 5 NDV: 80504 Nulls: 0 Density: 0.000012 Min: 1.000000 Max: 119999.000000

24. 24
Disabling and Enabling In-Memory
To disable In-Memory scans set the parameter
INMEMORY_QUERY = DISABLE
Plans will get the cost based on disk statistics and scans will be from the IM Column Store.
Use hint INMEMORY to force In-Memory Scan even if INMEMORY_QUERY is disabled.
NO_INMEMORY disables In-Memory scan even if the table is in the In-Memory Column Store.
SELECT /*+ INMEMORY */ sum(lo_revenue)
FROM lineorder lo, customer c
WHERE lo.lo_custkey=c.c_custkey
AND c_region='AFRICA’;
SELECT /*+ NO_INMEMORY */ sum(lo_revenue)
FROM lineorder lo, customer c
WHERE lo.lo_custkey=c.c_custkey
AND c_region='AFRICA’;

25. 25
Optimizer Summary
• In 12.1.0.2 the Optimizer is In-Memory aware.
• In-Memory statistics automatically generated at parse.
• Cost model adjusted for costing In-Memory Scans
• New INMEMORY and NO_INMEMORY hints

26. Queries

27. 27
Queries
• We have chosen some of the
queries that are candidates to
benefit from Database In-
Memory.

28. 28
Function MAX(column)
select max(lo_ordtotalprice)
from lineorder;
MAX(LO_ORDTOTALPRICE)
---------------------
55903140
Elapsed time: 0.004
select /*+ NO_INMEMORY */
max(lo_ordtotalprice)
from lineorder;
MAX(LO_ORDTOTALPRICE)
---------------------
55903140
Elapsed time: 4.014

29. 29
Function MAX(column)
B-tree index on lo_ordtotalprice
create index ordtotalprice_ix on
lineorder(lo_ordtotalprice);
select /*+ NO_INMEMORY */
max(lo_ordtotalprice)
from lineorder;
MAX(LO_ORDTOTALPRICE)
---------------------
55903140
Elapsed time: 0.001

30. 30
Function MAX(column)
How about Result Cache?
SQL show parameter result_cache_max_size
big integer 22000K
select /*+ RESULT_CACHE */
max(lo_ordtotalprice)
from lineorder;
MAX(LO_ORDTOTALPRICE)
---------------------
55903140
Elapsed time: 0.001

31. 31
How do we know it used the In-Memory Column Store?
select n.name, s.value
from v$mystat s, v$statname n
where s.statistic#=n.statistic#
and n.name like 'IM scan CUs columns accessed';
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 | 2224 (12)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
| 2 | TABLE ACCESS INMEMORY FULL| LINEORDER | 24M| 68M| 2224 (12)| 00:00:01 |
-----------------------------------------------------------------------------------------
NAME VALUE
---------------------------------------------------------------- ----------
IM scan CUs columns accessed 45

32. 32
One equality predicate
SELECT lo_orderkey,
lo_custkey, lo_revenue
FROM lineorder
WHERE lo_orderkey = 4000000;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ----------- -----------
4000000 51832 6983797
4000000 51832 917952
4000000 51832 2501733
4000000 51832 7895007
Elapsed time: 0.002
SELECT /*+ NO_INMEMORY */
lo_orderkey, lo_custkey,
lo_revenue
FROM lineorder
WHERE lo_orderkey = 4000000;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ----------- -----------
4000000 51832 6983797
4000000 51832 917952
4000000 51832 2501733
4000000 51832 7895007
Elapsed time: 4.528
IM scan CUs columns accessed 3
IM scan segments minmax eligible 44
IM scan CUs pruned 43

33. 33
One equality predicate
B-tree index on lo_orderkey
create index lo_orderkey_ix
on lineorder (lo_orderkey);
SELECT /*+ NO_INMEMORY */
lo_orderkey, lo_custkey,
lo_revenue
FROM lineorder
WHERE lo_orderkey = 4000000;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ----------- -----------
4000000 51832 6983797
4000000 51832 917952
4000000 51832 2501733
4000000 51832 7895007
Elapsed time: 0.001

34. 34
Three equality predicate
SELECT lo_orderkey, lo_custkey, lo_revenue
FROM lineorder
WHERE lo_custkey = 13286
AND lo_shipmode = 'TRUCK’
AND lo_orderpriority = '3-MEDIUM’;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ----------- -----------
8268262 13286 6777268
8268262 13286 6207689
9048868 13286 6394887
17521920 13286 2905822
19397281 13286 3573400
Elapsed time: 0.002
SELECT /*+ NO_INMEMORY */ lo_orderkey,
lo_custkey, lo_revenue
FROM lineorder
WHERE lo_custkey = 13286
AND lo_shipmode = 'TRUCK’
AND lo_orderpriority = '3-MEDIUM’;
LO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ----------- -----------
8268262 13286 6777268
8268262 13286 6207689
9048868 13286 6394887
17521920 13286 2905822
19397281 13286 3573400
Elapsed time: 4.868
IM scan CUs columns accessed 3
IM scan segments minmax eligible 44
IM scan CUs pruned 43

35. 35
How about composite index?
create index cust_ship_pri_ix
on lineorder
(lo_custkey, lo_shipmode,
lo_orderpriority);
SELECT /*+ NO_INMEMORY */ lo_orderkey,
lo_custkey, lo_revenue
FROM lineorder
WHERE lo_custkey = 13286
AND lo_shipmode = 'TRUCK’
AND lo_orderpriority = '3-MEDIUM’;
Customer#000118324 JORDAN
Customer#000119371 ETHIOPIA
Customer#000119386 SAUDI ARABIA
Customer#000118412
VIETNAMLO_ORDERKEY LO_CUSTKEY LO_REVENUE
----------- ----------- -----------
8268262 13286 6777268
8268262 13286 6207689
9048868 13286 6394887
17521920 13286 2905822
19397281 13286 3573400
Elapsed time: 0.001

36. 36
Greater Than () Instead of Equality (=)
SELECT MAX(lo_ordtotalprice)
FROM lineorder
WHERE lo_quantity 74;
Elapsed time: 0.002
SELECT MAX(lo_ordtotalprice)
FROM lineorder
WHERE lo_quantity 74;
Elapsed time: 4.82
IM scan CUs columns accessed 3
IM scan segments minmax eligible 44
IM scan CUs pruned 43

37. 37
How about an index?
create index lo_quantity_ix on
lineorder(lo_quantity);
SELECT /*+ INDEX(a lo_quantity_ix) */
MAX(lo_ordtotalprice)
FROM lineorder a
WHERE lo_quantity 74;
Elapsed time: 0.001

38. 38
Bloom Filter Example
SELECT c.c_name, c.c_nation
FROM customer c, part p,
lineorder lo
WHERE lo.lo_custkey = c.c_custkey
AND lo.lo_partkey = p.p_partkey
AND p.p_name = 'white salmon';
C_NAME C_NATION
------------------------- ---------------
Customer#000118324 JORDAN
Customer#000119371 ETHIOPIA
Customer#000119386 SAUDI ARABIA
Customer#000118412 VIETNAM
...
...

39. 39
Vector Group By Example
SELECT /*+ VECTOR_TRANSFORM */
c.c_name, c.c_nation,
sum(lo_ordtotalprice)
FROM customer c, part p,
lineorder lo
WHERE lo.lo_custkey = c.c_custkey
AND lo.lo_partkey = p.p_partkey
AND p.p_name = 'white salmon'
group by c.c_name, c.c_nation;
...
...
C_NAME C_NATION SUM(LO_ORDTOTALPRICE)
------------------------- --------------- ---------------------
Customer#000118540 ROMANIA 12634439
Customer#000119051 ARGENTINA 28032775
Customer#000118129 JAPAN 22258279
Customer#000118198 UNITED STATES 17849279

40. Usage with Oracle Technologies

41. 41
RAC
Each node in a RAC environment has its own IM
column store.
Objects populated into memory will be
distributed across all of the IM column stores in
the cluster.
ALTER TABLE lineorder INMEMORY
DISTRIBUTE BY PARTITION;
ALTER TABLE lineorder INMEMORY
DISTRIBUTE AUTO DUPLICATE ALL;

42. 42
M6-32
M6-32
SMP removes the overhead of distributing
queries across a cluster and coordinating
transactions.
Algorithms NUMA optimized.
Memory interconnect far faster than any
network.

43. 43
Exadata
Exadata
Complete fault-tolerant In-Memory
solution.
Exceed DRAM limits and transparently
scale across Memory, Flash and Disk.
Initial population of data into the In-
Memory column store from storage is very
fast.
The In-Memory Aggregation optimization,
can be offloaded to Exadata storage cells

44. 44
Oracle Technologies
• Data Guard
• Golden Gate
• Oracle Multitenant
• Partitioning
• Parallelism
• Resource Manager
• RMAN
• ALTER TABLE EXCHANGE

45. 45
Partition Exchange
1. Create external table for flat files
2. Use CTAS to create non part table and
gather table stats
3. Set INMEMORY attribute ON
4. Populate non part table in column store
5. Alter table table_name exchange partition
part name with table non part table;

46. Do’s and Don’ts

47. 47
The benefits of IM Column Store
Speed up Scans, Joins, Aggregates.
Scan of large tables and using predicates like =, , , IN
Querying a subset of columns in a table, for example, selecting 5 of 100 columns.
Accelerating joins by converting predicates on small dimension tables into filters on a large
fact table.

48. 48
Do or Don’t?
Business applications
Ad-hoc analytic queries
Data warehouse workloads

49. 49
Do or Don’t?
OLTP databases
short transactions
using index lookups

50. 50
Do
Queries that scan a large number of rows and apply filters that use operators such as the
following: =, , , and IN.
Queries that select 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.
Queries that join a small table to a large table.
Queries that aggregate data.

51. 51
Don’t
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.

52. 52
Don’t
In-memory speeds up analytic data access, not:
Network round trips, logon/logoff
Parsing, PL/SQL, complex functions
Data processing (as opposed to access)
Complex joins or aggregations where not much data is filtered before processing
Load and select once - Staging tables, ETL, temp tables

53. Is it for me?
Conclusion

54. 54
KEEP
CALM
AND
ASK
ME
Tú Pregúntame …
Please visit my blog at:
https://jorgebarbablog.wordpress.com
Email: jorge.barba@accenture.com