Advanced Oracle DB tuning
Performance can be defined in very different ways (OLTP versus DSS) Specific goals and targets must be set => clear recognition of success Factors include response time and throughput Oracle specific tuning
Response time
Sum of service time + wait time Processing strategy has key effect on response time
Eg: Sequential processing In a queue, wait time for a job = sum of service time of all previous jobs
If queue gets longer parallel processing required
response time in Sequential and Parallel processing
Wait time jobs Service time
time jobs
System Throughput
Amount of work completed in a given time Reduced service time = increased throughput Increase in resources = reduced response time Under load, contention increases
Service may remain the same But queues get longer
In practice, wait time raises exponentially
O/S scheduler DB dispatcher
Wait time
contention
Critical resources
CPU, memory, I/O capacity, network broadband
Capacity (how many?) Demand (how many?) Wait time (how long?) Consumption (how long?)
Software issue as much as hardware issue
Quality of design / programming Prioritise jobs Performance loss
demand
Performance adjustments
Reduce consumption (use fewer resources & reduce I/O per transac.) Demand (reschedule / redistribute work) Capacity (increase / relocate res. eg: move to parallel proc, increase mem.)
Problems for DBAs
Many performance parameters are set at design stage => limited scope to adjust Important targets set at outset => bottlenecks can be identified Administer trade-offs
More $$$ Else reschedule to limit contention
Properly manage user expectations
Eg DB versus network problems
Never sacrifice ability to recover data!
Performance tuning
Always better pro-active =>DBA in development team On-going tasks minimised by good planning
Service time marginal improvements only Eg SOCRATE case study
Oracle prioritised tuning steps for application dev.
Oracle tuning methodology
Tune business rules Tune data design Tune application design Tune logical structure Tune database operations Tune access paths Tune memory allocation Tune I/O and physical structure Tune resource contention Tune platform
Business rules
Normally other direction, but sometime business rule changed for better perf. Also, IT deployment strategy
Distributed Centralised
Stick to high level analysis of req. => more freedom (!?)
Cheque printing versus direct deposit Threshold value for automatic approuval
More flexibility in design
Data Design
Structure for data consistency AND performance Denormalisation
FAReports Summary values
Data hot spot
Application Design
In view of DB In view of Oracle Data entry acceleration + Refer to business rules and notes on critical db operations
Logical DB structure
Mostly indexing Also locking strategy
DB operations
Post relational DBs eg: oracle Extended SQL functions New DB functions See Oracle stats on query execution Also pl/sql server side programming better than application code Query optimiser may provide clues
Eg: Temporary index on non key attribute
Memory allocation
Dynamic process in Oracle Shared pool Parameters can be set manually
Make sure to keep decent SGA
See notes on DB creation
I/O and physical design
Use multiple disks + parallel controllers Optimise block size (see notes on DB creation) Use extents large enough for indexes Avoid use of pctincrease in OLTP tables Use raw device
Resource contention
Block contention Shared pool contention Lock contention All these can be diagnosed with Oracle stats
Platform
Need to talk to specialist
Eg: oracle staff
Different for different OS Cache size Paging strategies etc
Application
Always start with specific objectives else never achieve anything!
Max response times for inquiry maximum processing time for document
Picking list Invoice Month end
Goals may conflict, DBA arbitrates
Create repeatable tests
SQL statements
New versus old in SQL + SQL Trace enabled
Trial and error in a trial environment Use multiple scenarios to test effect of each change Also test in combination Test for scalability (growth)
Keep records and automate testing
Write recording into your scripts (table) Run scripts on a timer Measure against objectives and past perf. Stop when goals achieved
Oracle diagnostic tool
Explain plan Oracle trace Can be run in combination to compare actuals to estimates
Oracle Enterprise Manager
Common interface for all utilities Diagnosis + implementation of changes See table 17.4
Benchmarking
Use in product selection
Vendor bias? Env tuned for test only Not repeatable without access to unlimited resources Hidden cost of table maintenance outside the test.
Cited by every DB vendor on this planet Creation of the TPC (Transaction Processing Performance Council)
TPC C: order entry benchmark TPC H and TCP R: decision support benchmark TPC A: web transaction benchmark
Open source DB benchmark