Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 
 

Details on world record data warehouse benchmark

Oracle Database Tips by Donald Burleson

Learn Oracle data warehouse tuning from the world records

Vendors spend millions of dollars tuning their benchmarks, and the TPC disclosure report are a goldmine of Oracle tuning tips.  You can learn a lot about Oracle tuning by reading the TPC benchmark full disclosure reports.

For details on running your own Oracle benchmarks, see the book "Database Benchmarking" by Bert Scalzo.  Also, see my notes on Oracle benchmarks.

The previous world record for Oracle TPC-H (data warehouse) benchmark was 1,500 QphH (query per hour), and this record has now been broken with an HP Superdome at 1,700 QphH.  This benchmark used:

  • large data blocks - 32k blocksize

  • Huge PGA - 50g PGA region size (pga_aggregate_target)

  • Huge SGA - 90g SGA target (sga_target)

But the most recent world record is even more impressive, with this world record TPC-H Oracle data warehouse benchmark report.

  • Tiny disks - Smaller disk give higher bandwidth and this benchmark used tiny 32 gig disks.
     

  • Huge RAM buffers - This benchmark used a 30 gig data buffer and a 150 gig pga_aggregate_target.

Let's take a closer look that the Oracle tuning tips hidden inside this benchmark.

The Oracle Benchmark Server

This benchmark noted 170k data warehouse transactions per hour, using an HP superdome (with a 3 year server cost of $6.6m), using an astounding 512 gigabytes of RAM:

  • Processors  = 64 CPU's, each 64-bit (Intel Itanium2)
     

  • Database size = 10,000 gig - made-up of "tiny" 32 gig platters
     

  • Server RAM = 512 gig - Yes, that's half a trillion bytes of RAM

Tuning tricks for Oracle data warehouse configuration

Here are the "tricks" that Oracle used to get super-fast performance in this data warehouse test, a lesson for anyone who tunes a data warehouse environment:

  • Tiny disks - Each disk was only 32 gigabytes, and each disk was not full.  This provides higher bandwidth.  Read my notes on the plague of super-large disks for details.
     

  • RAID 10 - This benchmark used Oracle ASM with SAME (stripe and mirror everywhere, a.k.a. RAID1+0).
     

  • Giant RAM regions - Remember, disks are now 50 years-old, and there is a limited to this 1950's technology of magnetic-coated platters.  This benchmark used a 30 gigabyte data buffer (db_cache_size) and pga_aggregate_target = 150g.  This benchmark also chose a giant shared pool with shared_pool_size = 50g.
     

  • Large data blocks - Numerous proofs have shown that Oracle indexes build cleaner tree structures in 32k blocks, plus a single I/O results in more data being delivered into the SGA/PGA.
     

  • Server-specific parameters - There are special parameters for most server types that can dramatically help performance.  In this case, the test used the Oracle parameter hpux_sched_noage and the HP-UX parameter ASYNC_BUF_CONF.
     

  • Huge log buffer - Oracle used to recommend keeping the log_buffer small (under 10 meg), but our experience is that a larger log_buffer can increase throughput for high DML transactions.  This benchmark used log_buffer=268,435,456, about 250 megabytes!
     

  • Adjust Oracle optimizer parameters - Adjusting optimizer_index_cost_adj has a profound system-wide influence on the cost-based SQL optimizer, and most OLTP system use a smaller value (10-50) for influence higher index usage, and data warehouses use a larger value (100-300) to "prefer" full-table-scans.  This benchmark used optimizer_index_cost_adj = 200.  Important Note:  Prior to Oracle 10g, adjusting these optimizer parameters was the only way to compensate for sample size issues with dbms_stats.  As of 10g, the use of dbms_stats.gather_system_stats and improved sampling within dbms_stats had made adjustments to these parameters far less important.  Ceteris Parabus, always adjust CBO statistics before adjusting optimizer parms.  For more details on optimizer parameters, see my latest book "Oracle Tuning: The Definitive Reference". 
     

  • High Query Parallelism - Server with multiple CPU's can greatly increase the speed of full-table scans with Oracle parallel query.  This benchmark used these parallel parms:

parallel_adaptive_multi_user = true
parallel_execution_message_size = 65535
parallel_max_servers = 1600
parallel_min_servers = 1600
parallel_threads_per_cpu = 3

 


For more on learning from Oracle benchmarks, see my notes:


Here are the complete Oracle initialization parameters used in this benchmark:

instance_type = rdbms
aq_tm_processes = 0
audit_trail = FALSE
compatible = 10.1.0.2
control_files = (+DG1/control1,+DG1/control2)
cpu_count = 64
db_block_checksum = false
db_block_size = 32768
db_cache_size = 30g
db_file_multiblock_read_count = 64
db_files = 2400
db_name = 10tb
db_writer_processes = 16
dml_locks = 40000
global_names = FALSE
hpux_sched_noage = 180
instance_name = tpch
job_queue_processes = 0
log_buffer = 268435456
log_checkpoints_to_alert = true
log_checkpoint_interval = 18000
max_dump_file_size = unlimited
nls_date_format = YYYY-MM-DD
open_cursors = 1024
optimizer_features_enable = 10.2.0.1.1
optimizer_index_cost_adj = 200
optimizer_mode = CHOOSE
parallel_adaptive_multi_user = true
parallel_execution_message_size = 65535
parallel_max_servers = 1600
parallel_min_servers = 1600
parallel_threads_per_cpu = 3
pga_aggregate_target = 150g
processes = 5000
recovery_parallelism = 32
replication_dependency_tracking = false
session_cached_cursors = 0
shared_pool_size = 50g
statistics_level = basic
undo_management = auto
undo_retention = 200000

 Here are the parms for the ASM instance:

instance_type=asm
shared_pool_size=4G
db_cache_size=2g
asm_diskgroups=DG1
ASM.instance_number=1
instance_number=1
processes=500
ASM_DISKSTRING='/dbms/links/roradsk*'
lock_sga=TRUE
background_dump_dest='/opt/app/admin/ASM/log'
core_dump_dest='/opt/app/admin/ASM/log'
user_dump_dest='/opt/app/admin/ASM/log'

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


 

 

��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.