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 shift

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