AWS Community Day CPH - Three problems of Terraform
Oracle Systems _ Tony Jambu _ Exadata The Facts and Myths behing a proof of concept.pdf
1. Exadata - The Facts and Myth
Behind A Proof Of Concept
Tony Jambu
Melbourne, Australia
TJambu@wizard.cx
2. Agenda
• Myths and Facts of Benchmarks and PoCs
• Exadata Proof of Concept
• Learnings from Other Exadata sites
Please note that the views and opinions expressed during this
presentation are those of the presenters and not the respective
companies they work for.
3. 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
4. Exadata PoC - Summary
Transactions
11.6 X faster (avg)
• No code or schema changes
• Up to 90X faster was observed
5. Exadata PoC - Summary
Storage Reduction
84% saving
• Using Oracle’s Hybrid Columnar Compression for Archive
mode
6. Exadata PoC - Summary
SQL Loader
10 X faster
Consumes less CPU
7. 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?
9. 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 Latest 11gR2
Oracle vs
Full load vs Partial load
Individual test results Average result times
comparison vs
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. Preparatory: Baselining on SUN M9000
Baselining on the SUN M9000
M9K Baseline M9K Baseline
JOB NAME Typical Duration Operation (single exec) (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
19. Results – SUN M9000 vs Exadata (No Changes)
Lift & Drop test on Exadata - Data
M9K Baseline Exadata Test 1 Performance Gain
JOB NAME (baseline) 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
20. Results – SUN M9000 vs Exadata (No Changes)
Lift & Drop test on Exadata – Elapsed time
21. Results – SUN M9000 vs Exadata (No Changes)
Lift & Drop test on Exadata – Performance Gain
22. Results – SUN M9000 vs Exadata (*16 Degree)
Exadata – Increase Parallel Degree x16 - Data
Performance Gain
M9K Baseline Exadata Test 2 M9k to Exadata Performance Gain
JOB NAME (*16 Degree) (unchanged) 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 Avg Gain with
00:07:24.0 00:11:54.0 1.7 -1.6
WG923P01.sql increase in
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 Parallel degree
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 Avg Gain with no
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 changes
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
23. Results – SUN M9000 vs Exadata (*16 Degree)
Exadata –Parallel Degree x16 - Elapsed time
24. Results – SUN M9000 vs Exadata (*16 Degree)
Exadata –Parallel Degree x16 - Performance Gain
25. Results – SQL Loader
SQL Loader Test
• 3.6 M rows
• Rows are ‘transformed’ on load
26. 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: 6X 17 X
27. 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
28. 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
29. 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
30. 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
31. Summary
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
32. Speaker : Tony Jambu
Paper : Exadata - The Facts and Myth
Behind A Proof Of Concept
Q&A
Select Star Mailing list
http://groups.yahoo.com/group/Select_Star/
or email Select_Star-subscribe@yahoogroups.com
For feedback & discussion: TJambu@Wizard.CX