Date post: | 22-Nov-2014 |
Category: |
Technology |
Upload: | insync2011 |
View: | 1,830 times |
Download: | 1 times |
Tony Jambu Melbourne, Australia
Exadata - The Facts and Myth Behind A Proof Of Concept
• 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: [email protected]
Select Star Mailing list http://groups.yahoo.com/group/Select_Star/
or email [email protected]
Q & A