Preview of Oracle Database 12 c In-Memory Option

1. Preview of Oracle Database 12cIn-Memory Option Thomas Kyte http://asktom.oracle.com/

2. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

3. Flip Flops Core 1993 ~$25/mb; $26,214,400/tb 2014 ~$0.007/mb; $7,645/tb ICs on board SIMMs DIMMS Big Drives Floppy Small Drives Flash SSD

4. Oracle Database In-Memory Option Goals 100X Faster Queries: Real-Time Analytics • Get instantaneous query results • Querying OLTP database or data warehouse Faster Transaction Processing Trivial to Deploy for All Applications and Customers

5. Optimizing Transaction and Query Performance Row Format Databases versus Column Format Databases SALES Row • Transactions run faster on row format • Fast for processing few rows, many columns • Example: Insert or query a sales order ORDER SALES Column • Analytics run faster on column format • Fast for processing few columns, many rows • Example: Report on sales totals by state STATE Until Now You Choose One Format and Suffer Tradeoffs

6. Breakthrough: Dual Format In-Memory Database Memory Memory • BOTH row and column in-memory formats forsame table • Simultaneously active and transactionally consistent • Analytics & reporting use New Column format • OLTP usesrow format Sales Sales Analytics OLTP Column Format RowFormat Sales

7. Oracle In-Memory Columnar Technology • Pure in-memory format with no logging • Near zero overhead on changes • Even for OLTP • Uses memory-optimized compression • 2x to 10x memory reduction • Data loaded in-memory for active tables or partitions - on startup or first access • For in-memory tables, >90% of memory will be used for column format • Row format needs little memory Memory Pure Columnar

8. Find Any Business Data in Sub-second Example: Find all sales in state of CA • Each CPU scans local in-memory columns • Scans use super fast SIMD vector instructions • Billions of rows/secscan rate per CPU core In-Memory Column Store State column Sales >100X Faster “CA” SIMD Compare all values in 1 cycle Compare all values in 1 instruction Load multiple State values Vector Register CPU

9. Scans and Combines Data from Multiple Tables Example: Find all sales in outlet stores • Converts join processing into fast column scans • Joins up to 10x faster Sales Stores Storeid in 15,38,64 STOREID AMOUNT TYPE Sum Type=outlet

10. OLTP is Slowed Down by Analytic Indexes • Most Indexes in mixed-use OLTP (e.g. ERP) databases are only used for analytics • Indexes work well for known access patterns both in-memory and on-disk • But every change to the table requires changing all analytic indexes – Slow! 1 to 3 OLTP Indexes 5 to 15 Analytics Indexes Table

11. Column Store Replaces Analytic Indexes 1 to 3 OLTP Indexes • In-Memory Column Store replaces analytic indexes for tables that fit in memory • Removes analytic index overhead on changes • Both predefined and ad-hoc analytic queries run fast • Less tuning & admin needed • OLTP & batch often run 2x or more faster Table In-Memory Column Store

12. Extreme Capacity and Cost Effectiveness • Size not limited by memory • Data transparently accessible across tiers • Each tier has specialized algorithms & compression • Capacity of Disk IOs of FlashSpeed of DRAM Hottest Data DRAM PCI FLASH Active Data DISK Cold Data

13. Scale-Out In-Memory Database to Any Size • Scale-Out across servers to grow memory and CPUs • In-Memory queries are parallelized across servers to access local column data • Direct-to-wire InfiniBand protocol speeds messaging In MemoryColumn Store In MemoryColumn Store In MemoryColumn Store In MemoryColumn Store

14. Scale-Up for Maximum In-Memory Performance • Scale-Up on large SMPs • SMP scaling removes overhead of distributing queries across servers or coordinating transactions • Inter-processor bandwidth far exceeds any network

15. Oracle In-Memory is Trivial to Deploy • Configure Memory Capacity • inmemory_size = XXXX GB • Configure tables or partitions to be in memory • alter table | partition … inmemory; • Later Drop analytic indexes to speed up OLTP

16. Oracle In-Memory is Transparent to Applications Existing Applications Just Run Faster Full Functionality - No restrictions on SQL Trivial to Implement - No migration of data or change of product Fully Compatible - All existing applications run unchanged DB as a Service Ready - Oracle Multitenant in-memory And All Other Apps that Support Oracle Database Uniquely Achieves All In-Memory Benefits With No Application Changes

17. Oracle In-Memory Delivers Extreme Availability Data Guard & GoldenGate • Pure In-Memory format does not change Oracle’s storage format, logging, backup, recovery, etc. • All Oracle’s mature availability technologies work transparently • Protection from all failures • Node, site, corruption, human error, change, etc. RAC ASM RMAN

18. Summary: Oracle Database In-Memory Option • Faster Queries: Real-Time Analytics • Querying OLTP database or data warehouse • Increase Transaction Processing Rates • Less Management and Tuning • Best of Memory, Flash, Disk • Scale-Out and Scale-Up • Extreme Availability • Trivial to Deploy for All Applications and Customers