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

time

jobs

Wait time

Service 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

arbitration

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

Resource sh

ift

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