Tony Jambu Melbourne, Australia

Exadata - The Facts and Myth Behind A Proof Of Concept

TJambu@wizard.cx

•  Myths and Facts of Benchmarks and PoCs

•  Exadata Proof of Concept

•  Learnings from Other Exadata sites

Agenda

Please note that the views and opinions expressed during this presentation are those of the presenters and not the respective companies they work for.

Exadata PoC

Proof of Concept •  19 days Proof of Concept carried out in Jan

2011 •  ‘Lift and Drop’ approach using one of

company’s data warehouse •  23 hours of testing was carried out on Exadata

X2-2 at Oracle Data Centre, Sydney

Exadata PoC - Summary

Transactions

11.6 X faster (avg) •  No code or schema changes

•  Up to 90X faster was observed

Exadata PoC - Summary

Storage Reduction

84% saving •  Using Oracle’s Hybrid Columnar Compression for Archive

mode

Exadata PoC - Summary

SQL Loader

10 X faster

Consumes less CPU

Section 1–Myths & Facts of Benchmarks and PoC

PoC Figures • What does all these figures mean?

• Are they just smoke and mirrors?

• What are the details?

What about the figures quoted by Oracle?

Understanding the Figures

Understanding the Figures

Comparing Apples to Apples?

Current System New System Legacy server vs New server Slower storage vs Latest disk technology Previous version of Oracle vs

Latest 11gR2

Full load vs Partial load Individual test results comparison vs

Average result times

Oracle Exadata Database Machine

Not just a database appliance

An ‘engineered’ solution of

•  Database servers

•  Flash Storage •  Storage

•  Interconnect (Infiniband) •  Infiniband & Ethernet switches

•  iDB (modified iSCSI on top of ZDP) •  KVM

The magic sauce – Exadata Storage Server software

Section 2 – Exadata Proof of Concept

The system chosen was a data warehouse

•  22 TB single instance database

• About 30 main production schema.

• Main schema, API5AFS with 8TB was chosen

• Work profile

•  Batch loads

•  Post load processing &

•  Reports and End user activities

GDW ADS Data Warehouse

• Production sever – SUN M8000

• DR, Test, Development server – SUN M9000

•  Storage – EMC’s latest storage

• Application Server – SUN T5240

• Database 10gR2

Testing Methodology

High Level Steps

1.  A clone of production is created on a SUN M9000 server

2.  Workload txns are captured on production

3.  Baseline tests are conducted on this clone

4.  Export data & Statistics

5.  Exadata: Import data & statistics

6.  Exadata: Conduct Baseline tests

7.  Exadata: Make changes and run tests again.

8.  Repeat (7) for different conditions

Testing Methodology

Test Scenarios 1.  Automated-Using Oracle’s RAT(Real ApplicationTesting)

2.  Manual –

(a)   SQLs (16 INSERT/SELECT and 2 SELECT)

(b)  SQL Loader (key component)

Preparatory Work

•  Source: Export using expdp (5 streams)

•  Source: Export Statistics only

•  Target: Import using impdp

•  Target: Import Statistics

Testing Methodology

RAT Capture 1.  Stop production

2.  Snap/clone database to Test server

3.  Start RAT capture for API5AFS txn only

4.  Stop RAT capture stopped after 3 hours

Subset of large production jobs

•  16 jobs with INSERT/SELECT, 2 jobs with SELECT

•  SQLs are heavily hinted

•  All 18 jobs were run executed concurrently to simulate production workload

Testing Methodology

Factors considered •  Eliminate network ie not App server to DB Server

(as test on Exadata were single tier)

•  Eliminate spool file (to /dev/null to eliminate O/S write delays)

•  Run a baseline test on Exadata with no modifications or tweeking

•  Run jobs concurrently

•  Ensure no other applications running on your test server and Exadata server

Preparatory: Baselining on SUN M9000

Baselining on the SUN M9000

JOB NAME Typical Duration Operation M9K Baseline (single exec)

M9K Baseline (concurrent)

WF802P01.sql 1.5 hr SELECT 00:11:12.0 00:47:38.0 WG189P03.sql 20-50 mins INS 00:06:57.9 00:39:10.2 WG634P06.sql 1-2 hrs INS 00:22:29.9 00:37:51.7 WG690P03.sql 60 mins INS 00:48:18.5 01:38:57.1 WG703P01.sql 60 mins INS 00:19:40.9 00:55:31.0 WG709P01.sql 45 mins INS 00:51:45.2 01:18:18.2 WG862P01.sql 30-60 mins INS 00:02:57.2 00:07:24.0 WG923P01.sql 30-60 mins INS 00:10:21.2 00:43:11.9 WG923P02.sql 50 mins INS 00:10:24.2 00:43:11.1 WG982P07.sql 2 hrs INS 02:15:27.3 03:06:47.9 WG982P17.sql 10 hrs INS 00:01:15.4 00:03:32.0 WGAVNP01.sql 30-50 mins INS 00:24:06.8 01:11:45.9 WGS41P02.sql 30-40 mins INS 00:15:38.2 00:50:26.3 WGS41P10.sql 40-60 mins INS 00:12:52.3 00:39:12.4 WGS41P14.sql 1 hr 20 mins INS 00:20:35.6 01:06:20.2 WH180P04.sql 40 mins INS 00:11:06.8 00:46:22.6 WH566P01.sql 2-3.5 hrs SELECT 01:24:57.0 02:18:34.0 WHBA3P01.sql 25 mins INS 00:27:57.0 01:19:21.7

Preparatory: Baselining on SUN M9000

Baselining on the SUN M9000

Results – SUN M9000 vs Exadata (No Changes)

Lift & Drop test on Exadata - Data JOB NAME

M9K Baseline

Exadata Test 1 (baseline)

Performance Gain M9k to Exadata

WF802P01.sql 00:47:38.0 00:14:26.0 3.3 WG189P03.sql 00:39:10.2 00:09:37.1 4.1 WG634P06.sql 00:37:51.7 00:41:17.6 -1.1 WG690P03.sql 01:38:57.1 01:27:35.2 1.1 WG703P01.sql 00:55:31.0 00:03:53.9 14.2 WG709P01.sql 01:18:18.2 00:03:11.9 24.5 WG862P01.sql 00:07:24.0 00:04:23.7 1.7 WG923P01.sql 00:43:11.9 00:03:33.5 12.1 WG923P02.sql 00:43:11.1 00:03:28.8 12.4 WG982P07.sql 03:06:47.9 01:33:20.9 2.0 WG982P17.sql 00:03:32.0 00:00:51.6 4.1 WGAVNP01.sql 01:11:45.9 01:48:17.4 -1.5 WGS41P02.sql 00:50:26.3 00:03:03.0 16.5 WGS41P10.sql 00:39:12.4 00:10:11.2 3.8 WGS41P14.sql 01:06:20.2 00:09:09.9 7.2 WH180P04.sql 00:46:22.6 00:04:14.8 10.9 WH566P01.sql 02:18:34.0 00:01:31.0 91.4 WHBA3P01.sql 01:19:21.7 00:31:07.5 2.5 Average 11.6

Results – SUN M9000 vs Exadata (No Changes)

Lift & Drop test on Exadata – Elapsed time

Results – SUN M9000 vs Exadata (No Changes)

Lift & Drop test on Exadata – Performance Gain

Results – SUN M9000 vs Exadata (*16 Degree)

Exadata – Increase Parallel Degree x16 - Data JOB NAME

M9K Baseline

Exadata Test 2 (*16 Degree)

Performance Gain M9k to Exadata (unchanged)

Performance Gain M9k to Exadata(*16DEG)

WF802P01.sql 00:47:38.0 00:19:43.0 3.3 2.4 WG189P03.sql 00:39:10.2 00:08:41.2 4.1 4.5 WG634P06.sql 00:37:51.7 01:15:08.4 -1.1 -2.0 WG690P03.sql 01:38:57.1 01:45:55.5 1.1 -1.1 WG703P01.sql 00:55:31.0 00:03:54.0 14.2 14.2 WG709P01.sql 01:18:18.2 00:02:21.0 24.5 33.3 WG862P01.sql 00:07:24.0 00:11:54.0 1.7 -1.6 WG923P01.sql 00:43:11.9 00:01:58.4 12.1 21.9 WG923P02.sql 00:43:11.1 00:01:54.5 12.4 22.6 WG982P07.sql 03:06:47.9 01:28:31.4 2.0 2.1 WG982P17.sql 00:03:32.0 00:00:43.3 4.1 4.9 WGAVNP01.sql 01:11:45.9 01:45:50.9 -1.5 -1.5 WGS41P02.sql 00:50:26.3 00:05:12.2 16.5 9.7 WGS41P10.sql 00:39:12.4 00:02:32.1 3.8 15.5 WGS41P14.sql 01:06:20.2 00:04:29.4 7.2 14.8 WH180P04.sql 00:46:22.6 00:12:50.0 10.9 3.6 WH566P01.sql 02:18:34.0 00:01:06.0 91.4 126.0 WHBA3P01.sql 01:19:21.7 00:26:52.3 2.5 3.0 Average 11.6 15.1

Avg Gain with no changes

Avg Gain with increase in Parallel degree

Results – SUN M9000 vs Exadata (*16 Degree)

Exadata –Parallel Degree x16 - Elapsed time

Results – SUN M9000 vs Exadata (*16 Degree)

Exadata –Parallel Degree x16 - Performance Gain

Results – SQL Loader

SQL Loader Test •  3.6 M rows

• Rows are ‘transformed’ on load

Results – SQL Loader

SQL Loader Result •  6X faster

•  94 % less CPU • CPU to Elapsed time 27%

Elapsed time CPU time consumed CPU to Elapsed %

M9000 server: 01:39:00.00 01:21:00.00 82% Exadata server: 00:17:30.92 00:04:42.18 27%

Exadata vs M9000: 18% 6% Performance gain: 6 X 17 X

Results – Exadata Hybrid Columnar Compression

Compression Test •  Single Table with

•  1+ billion rows

•  1 TB

•  430 Partitions

• Due to time constraint, only 254 partitions were compressed

Results – Exadata Hybrid Columnar Compression

Compression Result

Size before HCC: 555 GB Size with HCC: 89 GB Space savings: 466 GB

% savings: 84% Compression Ratio: 1:6.25

PoC – Summary

Apples to Apples comparison (M9000 test server to Exadata)

What worked •  Simple Lift and Drop approach

•  Minor changes can give significant performance advantage

What did not work/complete •  Real Application Testing

•  Removing embedded SQL hints

Section 3 - Learnings from Other Exadata sites • Are indexes still required?

• What skills are required to manage the machine?

• The DMA – Database Machine Administrator

• High Capacity or High Performance SAS drives?

• Do not under estimate data migration effort

• Last but not least – Managing expectation

Ran a Proof-of-Concept of Oracle’s Exadata Database machine using a real data warehouse and these are the results

•  A ‘Lift & Drop’ approach is feasible and found

•  Transactions were 11.6 X faster

•  84% space savings on uncompressed data

•  SQL Loader 6X faster and consume 94 % less CPU

Summary

Speaker : Tony Jambu Paper : Exadata - The Facts and Myth Behind A Proof Of Concept

For feedback & discussion: TJambu@Wizard.CX

Select Star Mailing list http://groups.yahoo.com/group/Select_Star/

or email Select_Star-subscribe@yahoogroups.com

Q & A