Advanced Oracle DB tuningPerformance can be defined in very different ways (OLTP versus DSS)Specific goals and targets must be set => clear recognition of successFactors include response time and throughputOracle specific tuning

Response timeSum of service time + wait timeProcessing strategy has key effect on response timeEg: Sequential processingIn a queue, wait time for a job = sum of service time of all previous jobsIf queue gets longer parallel processing required

response time in Sequential and Parallel processing

timejobsWait timeService timejobs

System ThroughputAmount of work completed in a given timeReduced service time = increased throughputIncrease in resources = reduced response timeUnder load, contention increasesService may remain the sameBut queues get longerIn practice, wait time raises exponentiallyO/S schedulerDB dispatcherWait timecontentionarbitration

Critical resourcesCPU, memory, I/O capacity, network broadbandCapacity (how many?)Demand (how many?)Wait time (how long?)Consumption (how long?)Software issue as much as hardware issueQuality of design / programmingPrioritise jobsPerformance lossdemandResource shift

Performance adjustmentsReduce 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 DBAsMany performance parameters are set at design stage => limited scope to adjustImportant targets set at outset => bottlenecks can be identifiedAdminister trade-offsMore $$$Else reschedule to limit contentionProperly manage user expectationsEg DB versus network problemsNever sacrifice ability to recover data!

Performance tuningAlways better pro-active =>DBA in development teamOn-going tasks minimised by good planningService time marginal improvements onlyEg SOCRATE case studyOracle prioritised tuning steps for application dev.

Oracle tuning methodologyTune business rulesTune data designTune application designTune logical structureTune database operationsTune access pathsTune memory allocationTune I/O and physical structureTune resource contentionTune platform

Business rulesNormally other direction, but sometime business rule changed for better perf.Also, IT deployment strategyDistributedCentralisedStick to high level analysis of req. => more freedom (!?)Cheque printing versus direct depositThreshold value for automatic approuvalMore flexibility in design

Data DesignStructure for data consistency AND performanceDenormalisationFAReportsSummary valuesData hot spot

Application DesignIn view of DBIn view of OracleData entry acceleration+ Refer to business rules and notes on critical db operations

Logical DB structureMostly indexingAlso locking strategy

DB operationsPost relational DBs eg: oracleExtended SQL functionsNew DB functionsSee Oracle stats on query executionAlso pl/sql server side programming better than application codeQuery optimiser may provide cluesEg: Temporary index on non key attribute

Memory allocationDynamic process in OracleShared poolParameters can be set manuallyMake sure to keep decent SGASee notes on DB creation

I/O and physical designUse multiple disks + parallel controllersOptimise block size (see notes on DB creation)Use extents large enough for indexesAvoid use of pctincrease in OLTP tablesUse raw device

Resource contentionBlock contentionShared pool contentionLock contentionAll these can be diagnosed with Oracle stats

PlatformNeed to talk to specialistEg: oracle staffDifferent for different OSCache sizePaging strategies etc

Application Always start with specific objectives else never achieve anything!Max response times for inquirymaximum processing time for documentPicking listInvoiceMonth endGoals may conflict, DBA arbitrates

Create repeatable testsSQL statementsNew versus old in SQL +SQL Trace enabledTrial and error in a trial environmentUse multiple scenarios to test effect of each changeAlso test in combination Test for scalability (growth)

Keep records and automate testingWrite recording into your scripts (table)Run scripts on a timerMeasure against objectives and past perf.Stop when goals achieved

Oracle diagnostic toolExplain planOracle traceCan be run in combination to compare actuals to estimates

Oracle Enterprise ManagerCommon interface for all utilitiesDiagnosis + implementation of changesSee table 17.4

BenchmarkingUse in product selectionVendor bias?Env tuned for test onlyNot repeatable without access to unlimited resourcesHidden cost of table maintenance outside the test.Cited by every DB vendor on this planetCreation of the TPC (Transaction Processing Performance Council)TPC C: order entry benchmarkTPC H and TCP R: decision support benchmarkTPC A: web transaction benchmarkOpen source DB benchmark

Steps ordered diminishing returnsIterative aspects = benefits from later materialise on earlierSeveral passesOverview of plan for query optimisationRecords all SQL statements RE a process = total picture of resource drain (parse, exec, i/o, cpu)Onus on vendor to prove compliance to test conditions