1. Oracle Database Performance Tuning Presented By-Rahul Gaikwad

2. What is Database Tuning? Database tuning is a group of activities used tooptimize the performance of a database. Goal Of Database Tuning? To maximize use of system resources To perform task as efficiently To work rapidly as possiblewww.yogijicreations.com 3. Why and when should one tune? Slow Physical I/O-caused by poorly-configured disks-caused by unnecessary physical I/O-caused by poorly-tuned SQL. Excessive CPU usage-It means that there is little idle CPU on the system-caused by an inadequately-sized system,-caused by untuned SQLstatements-caused inefficient application programs. Latch ContentionRarely is latch contention tunable by reconfiguringthe instance. Rather, latch contention usually isresolved through application changes.www.yogijicreations.com 4. Causes for low Performance Bad Connection Management Bad Use of Cursors and the Shared Pool Bad SQL Use of Nonstandard Initialization Parameters Getting Database I/O Wrong Redo Log Setup Problems Long Full Table Scans High Amounts of Recursive (SYS) SQLwww.yogijicreations.com 5. Where should we do the tuning? Database Design Poor system performance usually results from a poor database design. One should generally normalize to the 3NF. Selective denormalization can provide valuable performanceimprovements.. Application Tuning: Approximately 80% of all Oracle system performance problems areresolved by coding optimal SQL. Memory Tuning: By Properly size your database buffers (shared pool, buffer cache, logbuffer, etc) By looking at your wait events, buffer hit ratios, system swapping andpaging, etc. Disk I/O Tuning: Database files needs to be properly sized. Also look for frequent disk sorts, full table scans, data fragmentation, etc. Eliminate Database Contention: Study database locks, latches and wait events carefully and eliminatewhere possible. Tune the Operating System:www.yogijicreations.com Monitor and tune operating system CPU, I/O and memory utilization. 6. Optimizing the optimizer Optimizer inputsTable and indexCardinality Structure EstimatesDB parametersIO and CPUObject Statistics And config Estimates System Statistics Cost estimate www.yogijicreations.com 7. Database Statistics Database statistics provide information onthe type of load on the database, as well asthe internal and external resources usedby the database. 8. Performance Data StatisticsTime Model SQL Wait Metrics Stats Sessions 9. Wait Events Wait events are statistics that indicate that ithave to wait for an event to complete beforebeing able to continue the processing. common examples of the waits- Application: locks waits caused by row level locking Commit: waits for redo log write confirmation after acommit Idle: signify the session is inactive Network: waits for data to be sent over the network User I/O: wait for blocks to be read off a disk 10. Time Model Statistics The V$SESS_TIME_MODEL and V$SYS_TIME_MODELviews provide time model statistics The most important of the time model statistics is DB time. This statistics represents the total time spent indatabase calls and is a indicator of the total instanceworkload. It is calculated by aggregating the CPU and wait timesof all sessions DB time is measured cumulatively from the time that theinstance was started. For example, a instance that has been running for 30minutes could have four active user sessions whosecumulative DB time is approximately 120 minutes. 11. Active Session History (ASH) The V$ACTIVE_SESSION_HISTORY view providessampled session activity in the instance. Active sessions are sampled every second and arestored in a circular buffer in SGA. Active Session includes any session that was on theCPU at the time of sampling. 12. System and Session Statistics A large number of cumulative database statistics areavailable on a system and session level through theV$SYSSTAT and V$SESSTAT views. Operating System Statistics Operating system statistics provide information on the usageand performance of the main hardware components of thesystem, as well as the performance of the operating systemitself. It is always best to consider operating system statistics as adiagnostic tool, similar to the way many doctors use bodytemperature, pulse rate, and patient pain when making adiagnosis.. Operating system statistics include the following: CPU Statistics Virtual Memory Statistics Disk Statistics Network Statistics 13. Automatic Workload Repository The Automatic Workload Repository (AWR) collects, processes, andmaintains performance statistics for problem detection and self-tuningpurposes. This data is stored both in memory and in the database. AWR include: Time model statistics i.e. V$SYS_TIME_MODEL and V$SESS_TIME_MODEL views Some of the system and session statistics collected in the V$SYSSTAT and V$SESSTAT views Active Session History (ASH) statistics, representing the history of recent sessions activity AWR automatically generates snapshots of the performance dataonce every hourand collects the statistics in the workload repository. 14. Metric A metric is defined as the rate of change insome cumulative statistic. That rate can be measured against time,transactions, or database calls. For example, the number database calls per second isa metric. A history of recent metric values is available throughV$ views. 15. Tools or Utilities for PT V$SQL_PLAN Find SQLs with high resource costs EXPLAIN PLAN & DBMS_STAT Determine the execution plan SQL Trace/Tkprof Best drilldown at the session level 16. V$SQL_PLAN Used to display the execution plan of a SQLstatement: After the statement has executed, you candisplay the plan by querying theV$SQL_PLAN view. The V$SQL_PLAN_STATISTICS viewprovides the actual execution statistics forevery operation in the plan, such as thenumber of output rows and elapsed time.www.yogijicreations.com 17. EXPLAIN PLAN The EXPLAIN PLAN statement displays execution plans forSELECT, UPDATE, INSERT, and DELETE statements. A statements execution plan is the sequence of operations Oracleperforms to run the statement. The row source tree is the core of the execution plan. It shows : ordering of the tables access method for each table join method for tables Data operations like filter, sort, or aggregation The plan table Also contains information : Optimization, such as the cost and cardinality of each operation Partitioning, such as the set of accessed partitions Parallel execution, such as the distribution method of join inputswww.yogijicreations.com 18. PLAN_TABLE Output Table The PLAN_TABLE is automatically created tohold the output of an EXPLAIN PLAN statementfor all users. PLAN_TABLE is the default sample output tableinto which the EXPLAIN PLAN statementinserts rows describing execution plans. While a PLAN_TABLE table is automatically setup for each user, you can use the SQL scriptutlxplan.sql to manually create a localPLAN_TABLE in your schema.www.yogijicreations.com 19. uses EXPLAIN PLAN To examine a SQL statement thatSelect employee_id, job_title, salary, anddepartment_name for the employeeswhose IDs are less than 103. Example Using EXPLAIN PLANSELECT e.employee_id, j.job_title, e.salary,d.department_nameFROM employees e, jobs j, departments dWHERE e.employee_id < 103AND e.job_id = j.job_idAND e.department_id = d.department_id;www.yogijicreations.com 20. EXPLAIN PLAN Output-----------------------------------------------------------------------------------| Id | Operation| Name |Rows|Bytes | Cost (%CPU)|-----------------------------------------------------------------------------------| 0 | SELECT STATEMENT||3 | 189| 10 (10)|| 1 | NESTED LOOPS ||3 | 189| 10(10)|| 2 | NESTED LOOPS ||3 | 141 | 7 (15)||* 3 | TABLE ACCESS FULL| EMPLOYEES | 3 | 60 | 4 (25)|| 4 | TABLE ACCESS BY INDEX ROWID | JOBS | 19 | 513| 2 (50)||* 5 | INDEX UNIQUE SCAN| JOB_ID_PK | 1 | ||| 6 | TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 27 | 432 | 2 (50)||* 7 | INDEX UNIQUE SCAN| DEPT_ID_PK | 1 | | |-----------------------------------------------------------------------------------Predicate Information (identified by operation id):---------------------------------------------------3 - filter("E"."EMPLOYEE_ID"