!oracle!database!! in.memory opon - aioug · •...

Oracle Database In-‐Memory

Op4on

Powering the Real-‐Time Enterprise

Available Now in Release 12.1.0.2

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 2

!  Configuring the In-‐Memory Column Store

!  Popula4ng the In-‐Memory Column Store

!  Querying the In-‐Memory Column Store

!  Mixed Workload – Including DML

!  How In-‐Memory Interacts With Exis4ng Func4onality

!  High Availability & the In-‐Memory Column Store

Program Agenda

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

System Global Area SGA

Buffer Cache Shared Pool Redo Buffer

Large Pool Other shared Memory

Components

In-‐Memory Area

Configuring : In-‐Memory Column Store


Configuring : In-‐Memory Column Store

•  New Component of SGA

•  Controlled by INMEMORY_SIZE parameter

• Minimum size of 100MB

•  SGA_TARGET must be large enough to accommodate

SELECT * FROM V$SGA;

NAME VALUE ------------------ --------- Fixed Size 2927176 Variable Size 570426808 Database Buffers 4634022912 Redo Buffers 13848576 In-Memory Area 1024483648


In-‐Memory A Store – Not A Cache

• What is a store?

• A sta4c pool of memory

• You decide what objects are populated in memory

• Objects don’t age out • Objects automa4cally kept transac4onally consistent

SMU SMU

SMU SMU

SMU SMU

SMU SMU

IMCU IMCU

IMCU IMCU

IMCU IMCU

IMCU IMCU

In Memory Area

Column Format Data Metadata

5

In-‐Memory Area


Composi4on 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 formaged data

• SMUs contain metadata and transac4onal informa4on

SMU SMU

SMU SMU

SMU SMU

SMU SMU

IMCU IMCU

IMCU IMCU

IMCU IMCU

IMCU IMCU

In Memory Area

Column Format Data Metadata

6

In-‐Memory Area


Composi4on of In-‐Memory Compression Unit (IMCU)

• Unit of column store alloca4on – Columnar representa4on of a large number of rows from an object

– Rows from one or more table extents

• Actual size depends on size of rows, compression factor, etc.

•  Each column stored as a separate con4guous Column Compression Unit (column CU) – Rowids also stored as a Column CU

IMCU header

Extent #13 Blocks 20-‐120



ROWID

EMPID NAME

DEPT SALARY Column CUs

7


Composi4on of In-‐Memory Area

• V$INMEMORY_AREA: Current sizes of pools and pool statuses

• V$IM_HEADER: List of IMCUs currently in the inmemory column store

SQL> SELECT OBJD, TSN, ALLOCATED_LEN, NUM_ROWS, NUM_COLS FROM V$IM_HEADER;

OBJD TSN ALLOCATED_LEN NUM_ROWS NUM_COLS ---------- ---------- ------------- ---------- ---------- 92918 5 19922944 532246 60 92918 5 19922944 532480 60 92918 5 19922944 522496 60 92918 5 11534336 532480 60 92918 5 19922944 530176 60 92918 5 19922944 532480 60 92918 5 15728640 419562 60

SQL> SELECT * from V$INMEMORY_AREA;

POOL ALLOC_BYTES USED_BYTES POPULATE_STATUS ---------- ----------- ---------- --------------- 1MB POOL 1307574272 135266304 DONE 64KB POOL 318767104 524288 DONE








Program Agenda


•  Populate is the term used to bring data into the In-‐Memory column store

•  Populate is used instead of load because load is commonly used to mean inser4ng new data into the database

•  Populate doesn’t bring new data into the database, it brings exis4ng data into memory and formats it in an op4mized columnar format

10

Popula4ng : In-‐Memory Column Store


Oracle In-‐Memory Columnar Technology

•  Pure in-‐memory column format

•  Not persistent, and no logging

•  Quick to change data: fast OLTP

•  2x to 20x compression typical

•  Enabled at table or par44on •  Just ac4ve data in-‐memory

•  Available on all hardware plaoorms

11

SALES

Pure In-‐Memory Columnar



• Popula4on completed by new set of background processes

ora_w001_orcl

• Number of processes controlled by parameter INMEMORY_MAX_POPULATE_SERVERS

• Default ½ CPU_COUNT


Popula4ng : In-‐Memory Column Store •  New INMEMORY ATTRIBUTE

•  Following segment types are eligible

•  Tables

•  Par44ons

•  Subpar44on

•  Materialized views

•  Following segment types not eligible

•  IOTs

•  Hash clusters

•  Out of line LOBs

CREATE TABLE customers …… PARTITION BY LIST (PARTITION p1 …… INMEMORY, (PARTITION p2 …… NO INMEMORY);

ALTER TABLE sales INMEMORY;

ALTER TABLE sales NO INMEMORY;

Pure OLTP Features



•  Possible to populate only certain columns from a table or par44on

•  Order in which objects are populated controlled by PRIORITY subclause

•  Cri4cal, high, medium, low

•  Default – none (populate on first access)

•  Does not control the speed of popula4on

ALTER TABLE sales INMEMORY NO INMEMORY (PROD_ID);

CREATE TABLE orders (c1 number, c2 varchar(20), c3 number) INMEMORY PRIORITY CRITICAL NO INMEMORY (c1);



•  Objects compressed during popula4on

•  New compression techniques •  Focused on scan performance

•  Controlled by MEMCOMPRESS subclause

•  Mul4ple levels of compression

•  Possible to use a different level for different par44ons in a table

ALTER MATERIALIZED VIEW mv1 INMEMORY MEMCOMPRESS FOR QUERY;

CREATE TABLE trades (Name varchar(20), Desc varchar(200)) INMEMORY MEMCOMPRESS FOR DML(desc);



•  Different levels •  FOR DML Use on tables or par44ons with very ac4ve DML ac4vity

•  FOR QUERY Default mode for most tables

•  FOR CAPACITY For less frequently accessed segments

•  Easy to switch levels as part of ILM strategy

CREATE TABLE ORDERS …… PARTITION BY RANGE …… (PARTITION p1 …… NO INMEMORY PARTITION p2 …… INMEMORY MEMCOMPRESS FOR DML, PARTITION p3 …… INMEMORY MEMCOMPRESS FOR QUERY, : PARTITION p200 …… INMEMORY MEMCOMPRESS FOR CAPACITY );


Early Adopter -‐ Schneider Electric

• Global Specialist in Energy Management™

• 25 billion € revenue

• 160,000+ employees in 100+ countries

17


0

5

10

15

20

Query Low Query High Capacity Low

Capacity High

Schneider General Ledger Compression Factors

8.6x

Schneider In-‐Memory Compression

13x 16x 19x

• Over 2 billion General Ledger Entries

•  900 GB on disk

Default

18


Iden4fying : Tables With INMEMORY Agribute

•  New INMEMORY column in *_TABLES dic4onary tables

•  INMEMORY is a segment agribute

SELECT table_name, inmemory FROM USER_TABLES;

TABLE_NAME INMEMORY ------------ -------- CHANNELS DISABLED COSTS CUSTOMERS DISABLED PRODUCTS ENABLED SALES TIMES DISABLED

•  USER_TABLES doesn’t display segment agributes for logical objects

•  Both COSTS & SALES are par44oned => logical objects

•  INMEMORY agribute also reported in *_TAB_PARTITIONS


Monitoring : In-‐Memory Column Store Popula4on • V$IM_SEGMENTS

– Indicates which objects are currently populated in-‐memory – Shows current size of each segment in-‐memory

– Shows how much remains to be populated

SQL> select segment_name, populate_status, inmemory_priority, inmemory_size, bytes_not_populated from v$im_segments;

SEGMENT_NAME POPULATE_STATUS INMEM_PRIORITY INME_SIZE BYTES_NOT_POPULATED -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ ACCOUNTS STARTED HIGH 196606 2434886912 SALES COMPLETED CRITICAL 135790592 0


Iden4fying : Columns Without the INMEMORY Agribute


Oracle Compression Advisor And In-‐Memory

•  Easy way to determine memory requirements

•  Use DBMS_COMPRESSION

•  Applies MEMCOMPRESS to sample set of data from a table

•  Returns es4mated compression ra4o


Oracle In-‐Memory Advisor

•  New In-‐Memory Advisor

•  Analyzes exis4ng DB workload via AWR & ASH repositories

•  Provides list of objects that would benefit most from being populated into IM column store

BETA








Program Agenda


Why is an In-‐Memory scan faster than the buffer cache?

SELECT COL4 FROM MYTABLE;

25

X X X X X

RESULT

Row Format

Buffer Cache


Why is an In-‐Memory scan faster than the buffer cache?

SELECT COL4 FROM MYTABLE;

26

RESULT

Column Format

IM Column Store

RESULT

X X X X


Oracle In-‐Memory Column Store Storage Index •  Each column is the made up

of mul4ple column units

•  Min / max value is recorded for each column unit in a storage index

•  Storage index provides par44on pruning like performance for ALL queries

27

Memory

SALES Column Format

Min 1 Max 3

Min 4 Max 7

Min 8 Max 12

Min 7 Max 15

Example: Find all sales from stores with a store_id of 8

?


Iden4fying : INMEMORY Table Scan

•  Op4mizer fully aware

•  Cost model adapted to consider INMEMORY scan

•  New access method TABLE ACCESS IN MEMORY FULL

•  Can be disabled via new parameter

•  INMEMORY_QUERY


•  NEW Session level sta4s4cs

•  Best way to determine if In-‐Memory was use

•  Best way to measure the benefits of In-‐Memory scan

• 

IM scan bytes in-‐memory IM scan bytes uncompressed IM scan CUs columns accessed IM scan CUs columns decompressed IM scan CUs columns theore4cal max IM scan rows IM scan rows range excluded IM scan rows excluded IM scan rows op4mized IM scan rows projected IM scan CUs predicates received IM scan CUs predicates applied IM scan CUs predicates op4mized IM scan CUs pruned IM scan segments minmax eligible ….

29



•  New stats visible in V$SYSSTAT or AWR

How many rows were scanned How many rows were avoided by dic4onary pruning How many predicates were op4mized How many IMCUs were min-‐max pruned

Etc ..

IM scan bytes in-‐memory IM scan bytes uncompressed IM scan CUs columns accessed IM scan CUs columns decompressed IM scan CUs columns theore4cal max IM scan rows IM scan rows range excluded IM scan rows excluded IM scan rows op4mized IM scan rows projected IM scan CUs predicates received IM scan CUs predicates applied IM scan CUs predicates op4mized IM scan CUs pruned IM scan segments minmax eligible ….

30



Orders of Magnitude Faster Analy4c Data Scans

•  Each CPU core scans local in-memory columns

•  Scans use super fast SIMD vector instructions •  Originally designed for

graphics & science

•  Billions of rows/sec scan rate per CPU core •  Row format is millions/sec

31

Vector Register

Load mul4ple region values

Vector Compare all values an 1 cycle

CPU

Memory

REGION

CA

CA CA

CA

Example: Find sales in region of CA

> 100x Faster


Joining and Combining Data Also Drama4cally Faster

•  Converts joins of data in multiple tables into fast column scans

•  Joins tables 10x faster

32

Example: Find total sales in outlet stores

Sales Stores

Store ID

StoreID in 15, 38, 64

Type=‘Outlet’

Type

Sum

Store ID

Amou

nt


Iden4fying : INMEMORY Joins •  Bloom filters enable joins to be

converted into fast column scans

•  Tried and true technology originally released in 10g

•  Same technique used to offload joins on Exadata


Generates Reports Instantly

•  Dynamically creates in-‐memory report outline

•  Then report outline filled-‐in during fast fact scan

•  Reports run much faster •  Without predefined cubes

•  Also offloads report filtering to Exadata Storage servers

34

Example: Report sales of footwear in outlet stores

Sales

Stores

Products In-‐Memory

Report Outline

Footwear

Outlets $

$$ $

$$$

Footwear

Sales Outlets


0

20

40

60

80

100 Seconds per Query

Schneider Speedup Across 1545 Queries 7x to 128x faster

Million rows returned by query 2000M 300M 30M 5M 0.5M

Buffer Cache

IN-‐MEMORY

•  2 billion General Ledger Entries

•  1545 queries – Currently take 34 hours to complete

– Combina4on of filter queries, aggrega4ons and summa4ons

35


0

200

400

600

800

1000

Schneider Speedup vs. Disk From 62x to 3259x faster

Million rows returned 2000M 300M 30M 5M 0.5M

Disk

IN-‐MEMORY

Seconds per Query

36








Program Agenda


Complex OLTP is Slowed by Analy4c Indexes

•  Most Indexes in complex OLTP (e.g. ERP) databases 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 Analy4c Indexes

38


OLTP is Slowed Down by Analy4c Indexes

Insert rate decreases as number of indexes

increases

# of Fully Cached Indexes (Disk Indexes are much slower)

39


Column Store Replaces Analy4c 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 In-‐Memory Column Store

40


Schneider Update Transac4ons Speedup From 5x to 9x faster

All Indexes

Primary Index Only

Primary Index Plus In-‐Memory Columns

• Data – Sales Accounts

• Main table has 1 Primary Key + 21 secondary indexes

•  Test -‐ 303 million transac4ons – Currently takes 21 hours

41


Schneider Storage Reduc4on Over 70% reduc]on in storage usage due to analy]c index removal

0 50

100 150 200 250 300 350

Objects Redo

Size in GBs

SECONDARY INDEXES

TABLES & PK INDEXES

42


Data Loading : With In-‐Memory

• DML comes in three forms – Single record transac4ons – Direct path / bulk data loads – Par44on exchange load

• In-‐Memory Column Store always transac4onally consistent – Similar to how an index is always maintained during DML


In-‐Memory Area

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 transac4on journal that is used to keep the column store transac4onally consistent

44

IMCU IMCU JOURNAL


In-‐Memory Area IMCU

JOURNAL


•  DML opera4ons processed in row store just as they are today

45

•  Corresponding entry in column store marked stale

•  Copy of changed row stored in the Transac4on Journal


In-‐Memory Area IMCU

JOURNAL


•  In-‐Memory Column Store is never out of date

•  Read consistency achieved by merging contents of column and the transac4on journal

46


In-‐Memory Area


•  When number of entries in transac4on journal hits an internal threshold CU automa4cally refreshed

•  This is an online opera4on – column store always available

47

IMCU

JOURNAL


Bulk loads with In-‐Memory

48

•  Bulk loads typically direct path opera4on •  Direct path opera4ons are all or nothing •  Data inserted into new DB blocks above high watermark

• 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

– If PRIORITY agribute set data automa4cally populated

High Water Mark

NEW DATA

High Water Mark


In-‐Memory and Par44on Exchange Loads

49

3. Set INMEMORY agribute

4. Populate TMP_SALES into IM column store

5. Alter table Sales exchange par44on May_24_2014 with table TMP_SALES

Sales table currently populated in IM column store

1. Create external table for flat files

2. Use CTAS command to create non-‐par44oned table TMP_SALES








Program Agenda


How In-‐Memory Interacts With Exis4ng Func4onality

In-‐Memory

Mul4tenant

RAC


In-‐Memory and Oracle Mul4tenant

52

ERP CRM DW Shared memory and background processes

•  In-‐Memory Area specified at the container Database level

•  INMEMORY_SIZE=20G

•  By default each Puggable Database inherits the INMEMORY_SIZE from CDB



53

ERP CRM DW

Container Database

INMEMORY_SIZE=0G INMEMORY_SIZE=4G INMEMORY_SIZE=16G

INMEMORY_SIZE=20G



54

ERP CRM DW

Container Database

INMEMORY_SIZE=0G INMEMORY_SIZE=10G INMEMORY_SIZE=16G

Over subscrip4on is possible!

INMEMORY_SIZE=20G


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

55


ORDERS PARTITION BY HASH ON ORDER_ID

0

1

2

3

4 ….

Scale-‐Out: Distribute by Par44on

56

•  Distribute by Par44on (top-‐level par44on for composite par44oned tables)

•  Ideal for Hash Par44ons

•  Also for other par44on types if uniformly accessed

•  Allows in-‐memory par44on-‐wise joins


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-‐Par44on

57

•  For composite par44ons, can distribute by Sub-‐Par44on

•  Ideal for Hash Sub-‐Par44ons

•  Also for other sub-‐par44on types if uniformly accessed

•  Allows in-‐memory par44on-‐wise joins


ORDERS

Rowid Ranges

1-‐105

106-‐201

202-‐310

311-‐421.

422-‐535

….

Scale-‐Out: Distribute by Rowid Range

58

•  Distributes IMCUs by uniform hash on first rowid

•  For non-‐par44oned tables

•  Also for par44oned tables with skewed access across par44ons

•  Ensures uniform distribu4on of load across instances


In-‐Memory and RAC

•  Distribu4on allows in memory segments larger than individual instance memory

•  Policy is automa4c or user-‐specifiable

•  Controlled by DISTRIBUTE subclause

•  Distribute by rowid range

•  Distribute by par44on

•  Distribute by subpar44on

•  Distribute AUTO

59

ALTER TABLE sales INMEMORY DISTRIBUTE BY PARTITION;

ALTER TABLE COSTS INMEMORY DISTRIBUTE AUTO;


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

•  Rest of the data comes from disk

60

User


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

•  Rest of the data comes from disk

61


Querying Oracle Database In-‐Memory in RAC environment •  Shared nothing architecture

means AutoDOP must be used to access Data In-Memory

•  With AutoDOP query coordinator is aware of IMCU locations

•  Query coordinator automatically starts parallel server processes on the correct nodes

62


In-‐Memory Speed + Capacity of Low Cost Disk

DISK

PCI FLASH

DRAM

Cold Data

Hogest Data

Ac4ve Data

•  Size not limited by memory

•  Data transparently accessed across 4ers

•  Each 4er has specialized algorithms & compression

•  Speed of DRAM

•  I/Os of Flash

•  Cost of Disk


IMCU

IMCU

IMCU

IMCU

In-‐Memory

In-‐Memory’s BFF – Par44oning Enables Table Expansion

64

P1: ORDER_STATUS=‘OPEN’

SELECT * FROM SALES where ORDER_DATE between‘2013-‐01-‐01’ and ‘2014-‐01-‐01’;

P2: ORDER_STATUS=‘CLOSED’

P1: Best access path is full table scan

SALES

P2: Best access path is index scan

Local index on ORDER_DATE

IDX_SALES: ORDER_DATE


In-‐Memory’s BFF – Par44oning Enables Table Expansion -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ | Id | Operation | Name | Pstart| Pstop | -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ | 0 | SELECT STATEMENT | | | | | 1 | SORT AGGREGATE | | | | | 2 | VIEW | VW_TE_2 | | | | 3 | UNION-‐ALL | | | | | 4 | PARTITION RANGE SINGLE | | 1 | 1 | |* 5 | TABLE ACCESS INMEMORY FULL| SALES | 1 | 1 | | 6 | PARTITION RANGE SINGLE | | 2 | 2 | |* 7 | INDEX RANGE SCAN | IDX_SALES | 2 | 2 | -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ 5 -‐ inmemory("ORDER_DATE“>=TO_DATE(' 2013-‐01-‐01 00:00:00', 'syyyy-‐mm-‐dd hh24:mi:ss') AND "ORDER_DATE"<=TO_DATE(' 2014-‐01-‐01 00:00:00', 'syyyy-‐mm-‐dd hh24:mi:ss')) filter("ORDER_DATE“>=TO_DATE(' 2013-‐01-‐01 00:00:00', 'syyyy-‐mm-‐dd hh24:mi:ss') AND "ORDER_DATE"<=TO_DATE(' 2014-‐01-‐01 00:00:00', 'syyyy-‐mm-‐dd hh24:mi:ss')) 7 -‐ access("ORDER_DATE“>=TO_DATE(' 2013-‐01-‐01 00:00:00', 'syyyy-‐mm-‐dd hh24:mi:ss') AND "ORDER_DATE"<=TO_DATE(' 2014-‐01-‐01 00:00:00', 'syyyy-‐mm-‐dd hh24:mi:ss'))








Program Agenda


Oracle In-‐Memory: Industrial Strength Availability

RAC

ASM

RMAN

Data Guard & GoldenGate •  Pure In-Memory format does not change Oracle’s storage format, logging, backup, recovery, etc.

•  All Oracle’s proven availability technologies work transparently

•  Protection from all failures •  Node, site, corruption,

human error, etc.

67


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

68

Only Available on Engineered Systems


Oracle Database In-‐Memory: Unique Fault Tolerance

•  Policy is user-‐specifiable

•  Controlled by DUPLICATE subclause

•  DUPLICATE

•  DUPLICATE ALL

69

ALTER TABLE sales INMEMORY DUPLICATE;

ALTER TABLE COSTS INMEMORY DISTRIBUTE AUTO DUPLICATE ALL;


Oracle In-Memory Requires Zero Application Changes

Full Func]onality -‐ ZERO restric]ons on SQL

Easy to Implement -‐ No migra4on of data

Fully Compa]ble -‐ All exis4ng applica4ons run unchanged

Fully Mul]tenant -‐ Oracle In-‐Memory is Cloud Ready

Uniquely Achieves All In-‐Memory Benefits With No Applica]on Changes

70


In-‐Memory Monitoring


New In-‐Memory Central Screen in EM

In-‐Memory Area (GB) :4.00

In-‐Memory Area Used (GB) :1.79

Object map integrated with 12c heatmap feature


New In-‐Memory Central Screen in EM


New In-‐Memory Entries in CPU Wait Class


In-‐Memory Query in SQL Monitor


Become a Real-‐Time Enterprise Using Oracle Database In-‐Memory

•  Data-‐Driven •  Get immediate answers to any ques]on

with real-‐]me analy]cs

•  Agile •  Eliminate latency with analy]cs directly

on OLTP data

•  Efficient •  Easily and Non-‐disrup]ve deployment

accelerates all applica]ons

79

AGILE

EFFICIENT

DATA-DRIVEN


Summary: Oracle Database In-‐Memory Powering the Real-‐Time Enterprise

•  Extreme Performance: Analy]cs & OLTP

•  Extreme Scale-‐Out & Scale-‐Up

•  Extreme Availability

•  Extreme Simplicity

80

AGILE

EFFICIENT

DATA-DRIVEN

!oracle!database!! in.memory opon - aioug · •...

Documents