Oracle Database In- Memory & Rest of the Database Performance Features

(1)

Oracle Database In-‐Memory

& Rest of the Database Performance Features

(2)

Safe Harbor Statement

The following is intended to outline our general product direcMon. It is intended for

informaMon purposes only, and may not be incorporated into any contract. It is not a

commitment to deliver any material, code, or funcMonality, and should not be relied upon

in making purchasing decisions. The development, release, and Mming of any features or

funcMonality described for Oracle’s products remains at the sole discreMon of Oracle.

(3)

Program Agenda

Data Loading and Database In-‐Memory

TradiMonal Summary Objects and Database In-‐Memory

Scale Out and Database In-‐Memory

MulM-‐Tenant and Database In-‐Memory

Resource Manager and Database In-‐Memory

High Availability and Database In-‐Memory

1

2

3

4

3

5

6

(4)

Data Loading

: With In-‐Memory

• DML comes in three forms

– Single record transacMons

– Direct path / bulk data loads

– ParMMon exchange load

• In-‐Memory Column Store always transacMonally consistent

(5)

Data Loading

: With In-‐Memory

• DML comes in three forms

– 

Single record transacMons

• Inserts

• Updates

• Deletes

– Direct path / bulk data loads

– ParMMon exchange load

• In-‐Memory Column Store always transacMonally consistent

(6)

ConvenMonal DML

6

Online

Redo Log

Online

Redo Log

Online

Redo Log

System Global Area

LGWR

User

Oracle Database Instance

Data

Files

DBWR

(7)

ComposiMon of

In-‐Memory Area

• Contains two subpools:

– 

IMCU pool: Stores In Memory

Compression Units (IMCUs)

– 

SMU pool: Stores Snapshot Metadata

Units (SMUs)

• IMCUs contain column

forma^ed data

• SMUs contain metadata and

transacMonal informaMon

SMU SMU

IMCU

In Memory Area

Column Format Data

Metadata

(8)

Single Row DML

and the In-‐Memory Column Store

• Each IMCU contains the column

entries for a subset of rows in

the object

• It also has a transacMon journal

that is used to keep the column

store transacMonally consistent

8

In Memory Area

Column Format Data

Metadata

IMCU

Column Format Data

(9)

Single Row DML

and the In-‐Memory Column Store

9

In Memory Area

Column Format Data

Metadata

IMCU

Column Format Data

IMCU

• DML operaMons processed in

row store just as they are today

• Corresponding entry in column

store marked stale

• Copy of changed row stored in

the TransacMon Journal

(10)

Single Row DML

and the In-‐Memory Column Store

10

In Memory Area

Column Format Data

Metadata

IMCU

Column Format Data

IMCU

• In-‐Memory Column Store is

never out of date

• Read consistency achieved by

merging contents of column and

the transacMon journal

(11)

Single Row DML

and the In-‐Memory Column Store

11

In Memory Area

Column Format Data

Metadata

IMCU

Column Format Data

IMCU

• When number of entries in

transacMon journal hits an

internal threshold CU

automaMcally refreshed

• This is an online operaMon –

column store always available

(12)

ConvenMonal DML With In-‐Memory

12

Online

Redo Log

Online

Redo Log

Online

Redo Log

In-‐Memory Area

IMCU

JOURNAL

System Global Area

LGWR

User

IMCO

Wnnn

Instance

Update/Delete

Select

Data

Files

DBWR

(13)

Data Loading

: With In-‐Memory

• DML comes in three forms

– Single record transacMons

– 

Direct path / bulk data loads

• Create Table As Select (CTAS)

• Insert /+ APPEND /

– ParMMon exchange load

• In-‐Memory Column Store always transacMonally consistent

(14)

Direct Path loads

with In-‐Memory

14

Sales Table

High Water Mark

On Disk

In Memory

SALES TABLE

In-‐Memory Column Store

SQL> select segment_name, populate_status, bytes_not_populated

from v$im_segments;

SEGMENT_NAME POPULATE_STATUS BYTES_NOT_POPULATED

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

SALES COMPLETED 0

(15)

Direct Path loads

with In-‐Memory

15

Sales Table

High Water Mark

On Disk

In Memory

SALES TABLE

In-‐Memory Column Store

SQL> select segment_name, populate_status, bytes_not_populated

from v$im_segments;

SEGMENT_NAME POPULATE_STATUS BYTES_NOT_POPULATED

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

SALES COMPLETED 0

NEW DATA

• Direct path operaMons are all or

nothing

• Data inserted into new DB blocks

above high watermark

• No other process in the Database

sees the new data

(16)

Direct Path loads

with In-‐Memory

16

Sales Table

High Water Mark

On Disk

In Memory

SALES TABLE

In-‐Memory Column Store

SQL> select segment_name, populate_status, bytes_not_populated

from v$im_segments;

SEGMENT_NAME POPULATE_STATUS BYTES_NOT_POPULATED

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

SALES

STARTED

87960

NEW DATA

• New DB blocks incorporated into

table on commit

• IM column store becomes aware

of new data on commit

• Size of new data visible in the

BYTES_NOT_POPULATED

column of

V

$IM_SEGMENTS

High Water Mark

SQL> select segment_name, populate_status, bytes_not_populated

from v$im_segments;

SEGMENT_NAME POPULATE_STATUS BYTES_NOT_POPULATED

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

SALES COMPLETED 0

(17)

Direct Path loads

with In-‐Memory

17

Sales Table

High Water Mark

On Disk

In Memory

SALES TABLE

In-‐Memory Column Store

SQL> select segment_name, populate_status, bytes_not_populated

from v$im_segments;

SEGMENT_NAME POPULATE_STATUS BYTES_NOT_POPULATED

-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐

SALES COMPLETED 0

NEW DATA

• If the Sales Table has PRIORITY

speciﬁed on it data is

automaMcally populated on

commit

• If no PRIORITY speciﬁed then

missing data is populated on

next access

(18)

Data Loading

: With In-‐Memory

• DML comes in three forms

– Single record transacMons

– Direct path / bulk data loads

– 

ParMMon exchange load

• In-‐Memory Column Store always transacMonally consistent

(19)

In-‐Memory’s BFF -‐ ParMMoning

Large Table

Diﬃcult to Manage

ParMMons

Divide and Conquer

Easier to Manage

Improve Performance

Transparent to applicaAons

SALES

JANUARY 2014

MARCH 2014

FEBRUARY 2014

APRIL 2014

19

(20)

Smart distribuAon of data from disk to memory

Oracle ParMMoning

Flash

SSD

DISK

In Memory

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013

June 2013

April 2013

March 2013

February 2013

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013

June 2013

April 2013

March 2013

February 2013

SALES

(21)

Oracle ParMMoning

Smart data access through parAAon eliminaAon

What is the total sales

ﬁgure for March 1

st

2014 compared to

February 1

st

_2014?

Jun 2014

SALES

May 2014

Apr 2014

Mar 2014

Feb 2014

Jan 2014

Dec 2013

Nov 2013

Oct 2013

• ParMMoning eliminaMon

– 

DramaMcally reduces amount of data retrieved

from storage

– 

Performs operaMons only on relevant parMMons

– 

Transparently improves query performance and

opMmizes resource uMlizaMon

• Zone map pruning

– 

Further reduces amount of data retrieved from

storage

– 

For Oracle Engineered Systems

– 

Transparently improves query performance and

(22)

PopulaMng parMMons into the In-‐Memory Column Store

• Not all parMMons need to be

populated in-‐memory

• Diﬀerent levels of

MEMCOMPRESS allow more data

to be populated

• Easy to switch levels as part of

ILM strategy

• Smart processing through table

expansion for parMally populated

parMMoned tables

CREATE TABLE ORDERS ……

PARTITION BY RANGE ……

(PARTITION p1 ……

INMEMORY

MEMCOMPRESS FOR DML

,

PARTITION p2 ……

INMEMORY

MEMCOMPRESS FOR QUERY

,

PARTITION p3 ……

INMEMORY

MEMCOMPRESS FOR CAPACITY

:

PARTITION p200 ……

NO INMEMORY

(23)

In-‐Memory and

ParMMon Exchange Loads

23

3. Set INMEMORY a^ribute

4. Populate TMP_SALES into IM column store

5. Alter table Sales exchange parMMon May_24_2014

with table TMP_SALES

Sales table

currently

populated in IM

column store

1. Create external table for ﬂat ﬁles

(24)

Program Agenda

Data Loading and Database In-‐Memory

TradiMonal Summary Objects and Database In-‐Memory

Scale Out and Database In-‐Memory

MulM-‐Tenant and Database In-‐Memory

Resource Manager and Database In-‐Memory

High Availability and Database In-‐Memory

1

2

3

4

24

5

6

(25)

What Are TradiMonal Summary Objects?

Oracle ConﬁdenMal – Internal/Restricted/Highly Restricted 25

INDEXES

MATERIALIZED

OLAP CUBES

(26)

TradiMonal Indexing Strategy

•  Most Indexes in a mixed workload

environment are only used for

analytic queries

•  Inserting one row into a table

requires updating 10-20 analytic

indexes:

Slow!

•  Indexes only speed up

predictable queries & reports

Table

1 – 3

OLTP

Indexes

10 – 20

AnalyMc

Indexes

26

(27)

In-‐Memory Column Store Replaces AnalyMc Indexes

•  Fast analytics on any columns

•  Better for unpredictable analytics

•  Less tuning & administration

•  Column Store not persistent so

update cost is much lower

•  OLTP & batch run faster

Table

1 – 3

OLTP

Indexes

_{Column
Store}

In-‐Memory

27

(28)

QuesMons To Determine Which Indexes To Drop

• Is the index needed for referenMal integrity?

– Primary Key Index

– Foreign Key Index

• How selecMve is the index?

– Number of rows returned

• Is the index used by transacMonal workload or analyMcal queries?

Hidden advantage from dropping indexes

Foot print of database drops as no tablespace, redo or undo necessary for

indexes

(29)

Materialized Views

• Summary object containing pre-‐calculated results

• Typically created to speed up Resource intensive joins and aggregaMons

• AutomaMcally or manually refreshed

• Queries automaMcally rewri^en to use MV where applicable

• Underlying table can be parMMoned

Excellent candidate to be put in the In-‐Memory column store

Together they speed up all aspects of the execuAon plan

(30)

Materialized View Example – The SQL

SELECT

d.d_year, c.c_nation,

SUM

(lo_revenue - lo_supplycost) profit

FROM

lineorder l, date_dim d, part p,

supplier s, customer C

WHERE

l.lo_orderdate = d.d_datekey

AND

l.lo_partkey = p.p_partkey

AND

l.lo_suppkey = s.s_suppkey

AND

l.lo_custkey = c.c_custkey

AND

s.s_region =

'AMERICA'

AND

c.c_region =

'AMERICA'

GROUP BY

d.d_year, c.c_nation

ORDER BY

d.d_year, c.c_nation;

(31)

Materialized View Example – The original Plan (10 seconds)

(32)

Materialized View Example – Create MV

CREATE MATERIALIZED VIEW

maria_mv

ON prebuilt TABLE WITH reduced PRECISION

ENABLE query rewrite

AS SELECT

d.d_year, c.c_nation,

SUM

(lo_revenue - lo_supplycost) profit

FROM

lineorder l, date_dim d, part p, supplier s,

customer C

WHERE

l.lo_orderdate = d.d_datekey

AND

l.lo_partkey = p.p_partkey

AND

l.lo_suppkey = s.s_suppkey

AND

l.lo_custkey = c.c_custkey

AND

c.c_region =

'AMERICA'

GROUP BY

d.d_year, c.c_nation

ORDER BY

d.d_year, c.c_nation;

(33)

Materialized View Example – The MV Plan (0.04 seconds)

(34)

Program Agenda

Data Loading and Database In-‐Memory

TradiMonal Summary Objects and Database In-‐Memory

Scale Out and Database In-‐Memory

MulM-‐Tenant and Database In-‐Memory

Resource Manager and Database In-‐Memory

High Availability and Database In-‐Memory

1

2

3

4

34

5

6

(35)

Scale-‐Out In-‐Memory Database to Any Size

•  Scale-Out across servers to

grow memory and CPUs

•  In-Memory

queries

parallelized

across servers to

access local column data

• Direct-to-wire

InfiniBand

protocol speeds messaging on

Engineered Systems

(36)

ORDERS

PARTITION

BY HASH ON

ORDER_ID

0

1

2

3

4 ….

Scale-‐Out:

Distribute by ParMMon

36

• Distribute by ParMMon (top-‐

level parMMon for composite

parMMoned tables)

• Ideal for Hash ParMMons

• Also for other parMMon types

if uniformly accessed

• Allows in-‐memory parMMon-‐

wise joins

(37)

ORDERS

PARTITION BY

RANGE ON

ORDER_DATE

SUBPARTITION

BY HASH ON

ORDER_ID

Nov ‘13

1 Nov ‘13

2 Nov ’13

3 Nov ’13

4 Dec ‘13

1 ….

Scale-‐Out:

Distribute by Sub-‐ParMMon

37

• For composite parMMons, can

distribute by Sub-‐ParMMon

• Ideal for Hash Sub-‐ParMMons

• Also for other sub-‐parMMon

types if uniformly accessed

• Allows in-‐memory parMMon-‐

(38)

ORDERS

Rowid Ranges

1-‐105

106-‐201

202-‐310

311-‐421.

422-‐535

….

Scale-‐Out:

Distribute by Rowid Range

38

• Distributes IMCUs by

uniform hash on ﬁrst rowid

• For non-‐parMMoned tables

• Also for parMMoned tables

with skewed access across

parMMons

• Ensures uniform distribuMon

of load across instances

(39)

In-‐Memory and RAC

• DistribuMon allows in memory segments

larger than individual instance memory

• Policy is automaMc or user-‐speciﬁable

• Controlled by

DISTRIBUTE

subclause

• Distribute by rowid range

• Distribute by parMMon

• Distribute by subparMMon

• Distribute AUTO

39

ALTER TABLE sales

INMEMORY

DISTRIBUTE BY PARTITION

;

ALTER TABLE COSTS

INMEMORY

DISTRIBUTE ROWID RANGE

;

(40)

(41)

Querying

Oracle Database In-‐Memory in RAC environment

•  Serial queries will only

access a

fraction

of the data

from the IM column store on

its node

•  IMCUs not shipped across

interconnect

41

User

Note:

Rest of the data

comes from disk

(42)

Querying

Oracle Database In-‐Memory in RAC environment

•  Parallel execution helps as it

starts multiple processes

•  BUT we

can’t control

where

the parallel server processes

are started

•  IMCUs not shipped across

interconnect

42

Note:

Rest of the data

comes from disk

(43)

What is

Auto DOP

?

OpMmizer determines

execuMon plan

If esMmated Mme

greater than threshold

OpMmizer determines

Auto DOP

Actual DOP =

MIN(

PARALLEL_DEGREE_LIMIT

, Auto DOP)

Statement executes

in parallel

If esMmated Mme less than

threshold

PARALLEL_DEGREE_THRESHOLD

Statement

executes serially

(44)

Enable Auto DOP

• Set PARALLEL_DEGREE_POLICY=AUTO

– 

Enables Auto DOP, statement queuing, in-‐memory PX

• Run DBMS_RESOURCE_MANAGER.CALIBRATE_IO

– 

Default IO rate is 200MB/sec

• For Oracle Database In-‐Memory

– 

Ensures that the query coordinator is IMCU home locaMon aware

– 

Ensures that at least one parallel server slave is allocated on each database instance

Note:

New Adaptive setting

for Parallel_degree_policy

not recommended for DBIM

(45)

Querying

Oracle Database In-‐Memory in RAC environment

•  Shared nothing architecture

means

AutoDOP

must be

used to access Data

•  With AutoDOP query

coordinator is aware of IMCU

locations

•  Query coordinator

automatically starts parallel

server processes on the

correct nodes

(46)

Program Agenda

Data Loading and Database In-‐Memory

TradiMonal Summary Objects and Database In-‐Memory

Scale Out and Database In-‐Memory

MulM-‐Tenant and Database In-‐Memory

Resource Manager and Database In-‐Memory

High Availability and Database In-‐Memory

1

2

3

4

46

5

6

(47)

Oracle Database Architecture

Requires memory, processes and database ﬁles

47

System Resources

(48)

AP

OE

GL

New MulMtenant Architecture

Memory and processes required at container level only

48

System Resources

(49)

In-‐Memory and Oracle MulMtenant

49

ERP

CRM

DW

Shared memory and background

processes

• In-‐Memory Area speciﬁed at the container Database

level

• INMEMORY_SIZE=20G

• By default each Puggable Database inherits the

INMEMORY_SIZE from CDB

(50)

In-‐Memory and Oracle MulMtenant

50

ERP

CRM

DW

Container Database

INMEMORY_SIZE=

0G

INMEMORY_SIZE=

4G

INMEMORY_SIZE=

16G

(51)

In-‐Memory and Oracle MulMtenant

51

ERP

CRM

DW

Container Database

INMEMORY_SIZE=

0G

INMEMORY_SIZE=

10G

INMEMORY_SIZE=

16G

Over

subscripMon is

possible!

(52)

Program Agenda

Data Loading and Database In-‐Memory

TradiMonal Summary Objects and Database In-‐Memory

Scale Out and Database In-‐Memory

MulM-‐Tenant and Database In-‐Memory

Resource Manager and Database In-‐Memory

High Availability and Database In-‐Memory

1

2

3

4

52

5

6

(53)

CPU Resource Manager

• IniMal populaMon can be CPU resource intensive

• Resource Manager can control CPU usage during In-‐Memory column store

populaMon

• Default or custom resource plans can be used

• Default or custom consumer group can be used

(54)

Resource Manager Plan With In-‐Memory Example

• Use the SET_CONSUMER_GROUP_MAPPING procedure to set the

consumer group:

BEGIN

dbms_resource_manager.set_consumer_group_mapping(

attribute => 'ORACLE_FUNCTION',

value => 'INMEMORY',

consumer_group => 'BATCH_GROUP');

END;

• CPU uMlizaMon will be limited to the value speciﬁed for the BATCH_GROUP

(55)

Program Agenda

Data Loading and Database In-‐Memory

TradiMonal Summary Objects and Database In-‐Memory

Scale Out and Database In-‐Memory

MulM-‐Tenant and Database In-‐Memory

Resource Manager and Database In-‐Memory

High Availability and Database In-‐Memory

1

2

3

4

55

5

6

(56)

Oracle Database In-‐Memory: Unique Fault Tolerance

•  Similar to storage mirroring

•  Duplicate in-memory columns

on another node

•  Enabled per table/partition

•  Application transparent

•  Downtime eliminated by

using duplicate after failure

56

(57)

Oracle Database In-‐Memory: Unique Fault Tolerance

• Policy is user-‐speciﬁable

• Controlled by

DUPLICATE

subclause

• DUPLICATE

• DUPLICATE ALL

57

ALTER TABLE sales

INMEMORY

DUPLICATE

;

ALTER TABLE COSTS

INMEMORY

(58)

Example: Duplicate Strategy For a Star Schema

• Fact tables are distributed by parMMon

• Dimension tables are duplicated (DUPLICATE ALL)

• Co-‐locates joins between the distributed fact table parMMons and the

dimension tables

58

D

F

_D

D

F

_D

D

F

(59)

Data Guard

• Since no on-‐disk formats are

changed there is no impact to Data

Guard

• The inmemory_size parameter must

be conﬁgured on the standby for

failover

• The IM column store will be

populated at failover (same rules as

a normal instance startup)

• Supported for logical standby

59

Primary

SALES_1_MONTH

In-‐Memory

Column Store

In-‐Memory

Column Store

SALES_1_MONTH

(60)

AcMve Data Guard

• In-‐memory on AcMve Data Guard

– 

Standby has its own In-‐Memory Column

Store

– 

Must be allocated if used on the primary

• Currently IM Column Store not

useable on standby

60

Primary

SALES_1_MONTH

In-‐Memory

Column Store

In-‐Memory

Column Store

SALES_1_MONTH

• 

12.2 Enables reports run on the

standby to take advantage of

Database In-‐Memory

(61)

Golden Gate

• Since no on-‐disk formats are changed there is no impact to Golden Gate

• Golden Gate replays transacMons

• In-‐Memory Column automaMcally kept in sync

61

LAN/WAN

Internet

TCP/IP

Capture

Trail

Pump

Trail

Delivery

Source

Oracle & Non-Oracle

Database(s)

Target

Oracle &

Non-Oracle

Database(s)

Bi-directional

(62)

RMAN

• Since no on-‐disk formats are

changed there is no impact to

RMAN backups

62

Tape Drive

Amazon S3

RMAN

Fast Recovery

Area (FRA)

O

ra

cl

e

Se

cu

re

Backup

Oracle Public

Cloud

(Future)

(63)

Oracle Database In-‐Memory

& Security

(64)

Transparent Data EncrypMon

Feature Summary

Disk

Backups

Exports

Oﬀ-‐Site

FaciliMes

! 

Encrypts columns or enMre applicaMon tablespaces

! 

Protects the database ﬁles on disk and on backups

! 

Securely manages the keys, assists with key rotaMon

! 

Supports Oracle Exadata engineered systems

! 

CompaMble with applicaMons, no changes required

ApplicaMons

Encrypted

Data

(65)

In-‐Memory and Column Level EncrypMon

• Enables encrypMon on a narrow set of columns

• EncrypMon is done in upper layers

– 

Data encrypted on the way in and on the way out of Database

• Completely transparent to the IM column store

– 

Data Stored in the IM column store is encrypted

(66)

In-‐Memory and Tablespace Level EncrypMon

• All objects in the tablespace are encrypted

• EncrypMon is done in the data layer

• Data populated into the IM column store decrypted

• Data can be compressed in the IM column store

• Data from the IM column store

cannot

be to dumped out in clear

(67)

In-‐Memory and VPD

• VPD used to enforce row and/or column level security

• All table column data populated into the IM column store

• Data can be compressed in the IM column store

• VPD policies applied as addiMonal predicates added to queries

(68)

Takeaways

• Oracle Database In-‐Memory fully supports all data loading features

• Supports not just base tables but Materialized views and query rewrite

• RAC provides transparent In-‐Memory data scale out when used with Auto DOP

• Only fault tolerant In-‐Memory column store thanks to duplicate feature

• Fully supports the MulMtenant architecture

• Does not impact an of Oracle’s exisMng HA technologies

• Works seamlessly with all of Oracle’s Security features

(69)

Join the ConversaAon

69

h^ps://twi^er.com/db_inmemory

h^ps://blogs.oracle.com/in-‐memory/

Related White Papers

• Oracle Database In-‐Memory White Paper

• Oracle Database In-‐Memory AggregaMon Paper

Related Database In-‐Memory Free Webcasts

• Oracle Database In-‐Memory meets Data Warehousing

• In-‐Memory Demo

• Database Industry Experts Discuss Oracle Database In-‐

Memory (11:10)

• Sozware on Silicon

Any AddiAonal QuesAons

• Oracle Database In-‐Memory Blog

• My email: [email protected]

h^ps://www.facebook.com/OracleDatabase

h^p://www.oracle.com/goto/dbim.html

AddiMonal

Resources

(70)

Oracle Database In- Memory & Rest of the Database Performance Features

Oracle Database In-­‐Memory

& Rest of the Database Performance Features

Safe Harbor Statement

The following is intended to outline our general product direcMon. It is intended for

informaMon purposes only, and may not be incorporated into any contract. It is not a

commitment to deliver any material, code, or funcMonality, and should not be relied upon

in making purchasing decisions. The development, release, and Mming of any features or

funcMonality described for Oracle’s products remains at the sole discreMon of Oracle.

Program Agenda

Data Loading and Database In-­‐Memory

TradiMonal Summary Objects and Database In-­‐Memory

Scale Out and Database In-­‐Memory

MulM-­‐Tenant and Database In-­‐Memory

Resource Manager and Database In-­‐Memory

High Availability and Database In-­‐Memory

1

2

3

4

5

6

Data Loading

: With In-­‐Memory

•

DML comes in three forms

– Single record transacMons

– Direct path / bulk data loads

– ParMMon exchange load

•

In-­‐Memory Column Store always transacMonally consistent

Data Loading

: With In-­‐Memory

•

DML comes in three forms

–

Single record transacMons

•

Inserts

•

Updates

•

Deletes

– Direct path / bulk data loads

– ParMMon exchange load

•

In-­‐Memory Column Store always transacMonally consistent

ConvenMonal DML

Online

Redo Log

Online

Redo Log

Online

Redo Log

System Global Area

LGWR

User

Oracle Database Instance

Data

Files

DBWR

ComposiMon of

In-­‐Memory Area

•

Contains two subpools:

–

IMCU pool: Stores In Memory

Compression Units (IMCUs)

–

SMU pool: Stores Snapshot Metadata

Units (SMUs)

•

IMCUs contain column

forma^ed data

•

SMUs contain metadata and

transacMonal informaMon

SMU SMU

SMU SMU

SMU SMU

Oracle Database In-‐Memory

Data Loading and Database In-‐Memory

TradiMonal Summary Objects and Database In-‐Memory

Scale Out and Database In-‐Memory

MulM-‐Tenant and Database In-‐Memory

Resource Manager and Database In-‐Memory

High Availability and Database In-‐Memory

: With In-‐Memory

• 

– Single record transacMons

– Direct path / bulk data loads

– ParMMon exchange load

• 

In-‐Memory Column Store always transacMonally consistent

: With In-‐Memory

• 

– 

• 

• 

• 

– Direct path / bulk data loads

– ParMMon exchange load

• 

In-‐Memory Column Store always transacMonally consistent

In-‐Memory Area

• 

– 

– 

• 

• 

and the In-‐Memory Column Store

• 

• 

and the In-‐Memory Column Store

• 

• 

• 

and the In-‐Memory Column Store

• 

In-‐Memory Column Store is

• 

and the In-‐Memory Column Store