Ensuring Optimal Performance. Vivek Sharma. 3 rd November 2012 Sangam PDF Free Download

Ensuring Optimal Performance Vivek Sharma 3 rd November 2012 Sangam 2012

Who am I? Around 12 Years using Oracle Products Certified DBA versions 8i Specializes in Performance Optimization COE Lead with ACS India Regular Speaker for AIOUG A Technical Hands on Consultant Email : vivek.s.sharma at oracle.com Blog : viveklsharma.wordpress.com

Scalability User Load 900 800 700 600 500 400 300 200 100 0 4 8 12 16 20 24 28 32 Resources Available Resources > Total Work Done Linear 3

Scalability User Load 900 800 700 600 500 400 300 200 100 0 Desired Problem 4 8 12 16 20 24 28 32 Resources An Example of Available Resources < Total Work Done Linear Actual 4

Why this Session? Maintain Scalability Ensure High Availability Whose Responsibility? Development DBA Production DBA Developers Co-ordination between all of these is essential to meet the Objective 5

Agenda Architecture Operating System Statistics Production Architecture (An Example) Database Design Understanding CBO Selectivity Cardinality Indexing (Careful Consideration) Why is my SQL misbehaving? Application Design Inefficient Query Power of Scalar 6

Architecture Just Enough Diagram Shared Global Area - SGA User or App Server Shared Pool Network Or Local Log Buffer LGWR Redo Logs Oracle Server Process Commits / Rollbacks DBWR Disk Reads Buffer Cache 7

Life Cycle of a Cursor Syntax / Semantics Checks N Sharable Parent Cursor Available? Store Parent Cursor in Library Cache Y Sharable Child Cursor Available? Y N Query Transformation / Execution Plans Store child Cursor in Library Cache Execute 8

Operating System Statistics CPU CPU Utilization SYS% = Time spent executing OS system calls (like file read, file write, allocate memory, etc) USR% = Time spent executing user code IDLE% = 100% - %USER - %SYS Run queue Run Q is the number of processes that can run and are waiting for CPU Thresholds to watch: %SYS < 20% overhead Total Run Queue > Total Number of CPUs 10

Operating System Statistics Memory Page Ins / Page Outs Memory being allocated due to a Demand Small, Incremental movement of Memory to the Swap Device Health of an Operating System is Key to Production Performance / Availability 11

Production Architecture An Example 6. Summary Displayed 1. Client Connects Application Server 5. Summary Fetched 2. Authenticates 3. Validated 4. Fetch Summary Oracle Database Non-Oracle Database 7. Connections established in steps 2 & 4 are then Released for other requests 13

Production Architecture An Example Response Time Client to Application Server < ms Authentication & Validation < ms Fetch Summary < 5 ms The Challenge Client to Application Server < ms Authentication & Validation < ms What if Fetch Summary takes more time? A Profound Impact on the Entire Production System 14

Database Design Number of Columns Table A with 300 Columns (A1..A300) In terms of performance Is there any difference between the three queries? select A1, A8 from A where rowid= some_value ; select A1, A50 from A where rowid= some_value ; select A1, A300 from A where rowid= some_value ; Additional LIO s due to Intra-Block Chaining ib.sql 16

Database Design Column Ordering Table A with 13 Columns (A1..A13) In terms of performance Is there any difference between the two queries? select A1 from A where rowid= some_value ; select A13 from A where rowid= some_value ; Additional CPU Cycles for Column Skipping CPU Cycles for Table Column Skip 20 CPU Cycles for Scanning Table Row 130 17

Database Design Number of Columns create table cpu_test as select * from all_objects where rownum<=50; explain plan for select owner from cpu_test; #Rows 50 #Blocks 4 CPU_Cost 35986 cpu_cost = 7121.44 x #blks + (130 x #Rows) + (20 x #Rows x Col#) select distinct cpu_cost from plan_table; cpu_costing.sql 18

Database Design Number of Columns 30000 25000 20000 15000 10000 5000 0 CPU Cycles 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 1st Column 13th Column 19

Cost Based Optimizer Object Statistics Query Transformation I/O v/s CPU Least Costly Plan 10g mandatory System Statistics (9i Onwards 10g mandatory) Optimizer Parameters 21

Understanding CBO Selectivity Selectivity of Predicate deptno = :b1 is 1/NDV = 1/3 = 0.333 Selectivity of Predicate (deptno = :b1 and job = :b2) = (1/3) * (1/5) =.06667 Selectivity of Predicate (deptno = :b1 or job = :b2) = (1/3)+(1/5)-(1/3)*(1/5) =.46667 DEPTNO JOB SAL 10 MANAGER 2450 10 PRESIDENT 5000 10 CLERK 1300 20 MANAGER 2975 20 ANALYST 3000 20 CLERK 1100 20 CLERK 800 20 ANALYST 3000 30 SALESMAN 1250 30 SALESMAN 1500 30 SALESMAN 1600 30 CLERK 950 30 MANAGER 2850 30 SALESMAN 1250 NDV : # of Distinct Values 22

Understanding CBO Selectivity Lower the Selectivity, better the Predicates 1/Num_Distinct v/s Density Probability theory in calculating Selectivity of Predicates p(a and B) = p(a) x p(b) p(a or B) = p(a) + p(b) p(a) x p(b) 23

Understanding CBO Cardinality Estimated Number of Rows from a Row Source Next Step to calculation of Selectivity Cardinality = Selectivity x Number of Rows Very Crucial Affects Access Path / Join Orders Improper Calculation of Cardinality is a Root Cause to many of the Query Performance Issues 24

Understanding CBO Cardinality Cardinality of Predicate deptno = :b1 is (selectivity x #Rows) = 0.333 x 14 = 4.6662 = 5 Cardinality Deptno = Estimated Actual Change 10 5 3 20 5 5 = 30 5 6 DEPTNO JOB SAL 10 MANAGER 2450 10 PRESIDENT 5000 10 CLERK 1300 20 MANAGER 2975 20 ANALYST 3000 20 CLERK 1100 20 CLERK 800 20 ANALYST 3000 30 SALESMAN 1250 30 SALESMAN 1500 30 SALESMAN 1600 30 CLERK 950 30 MANAGER 2850 30 SALESMAN 1250 NDV : # of Distinct Values 25

Indexing Careful Consideration Query 1 - Where X=:b1 Query 2 Where X=:b1 and Y=:b2 There is an Index on X. Adding Column Y needs Careful Consideration cf.sql 27

Why is my SQL misbehaving? Misleading Object Statistics Misleading Column Level Statistics Correlation Issues (extended_stats.sql) Non-Default Optimizer Parameters In efficient Application Queries Dynamic Sampling / Cardinality Feedback rescues to some extent cf.sql 29

Application Design (Entry Screen) Mandatory Column Optional Column, Leave Blank for ALL Optional Column, Leave Blank for ALL Optional Column, Leave Blank for ALL 31

Application Design (Entry Screen) SYNONYM 32

Application Design (Inefficient Query) Select a.owner, a.object_name, b.data_object_id, a.last_ddl_time From vivek_test a, vivek_test1 b Where a.object_type = :v_object_type and and and and a.temporary = nvl(:v_temporary,a.temporary) a.owner = nvl(:v_owner,a.owner) a.last_ddl_time = nvl(:v_last_ddl_time,a.last_ddl_time) a.object_id = b.object_id; nvl_query.sql 33

Application Design (Inefficient Query) SELECT groupid,supergroupid,branchid, LOANID, NAME, AMTFIN, CLOSUREDATE, PRODUCTFLAG,BRANCHDESC,STATUS,lesseeid,AGREEMENTNO FROM( SELECT A.AGREEMENTID LOANID,A.BRANCHID,A.AMTFIN, B.BRANCHDESC, A.AGREEMENTNO, C.CUSTOMERNAME NAME, A.PRODUCTFLAG, A.STATUS, A.CLOSUREDATE, A.LESSEEID, C.GROUPID, DSUPERGROUPID FROM LAD A, NBM B, NCM C, LEM D WHERE A.BRANCHID=B.BRANCHID AND A.LESSEEID=C.CUSTOMERID AND A.EMPLOYERID=D.EMPLOYERID(+) AND (A."STATUS='A' OR A.STATUS='C')) WHERE STATUS IN (:B1) AND LOANID = :b2 ORDER BY NAME; View Unique Column Why do I need ORDER BY? 34

Application Design (Inefficient Query) ORDER BY sort SORT ressource Sort statistics Sort width: 6142 Area size: 1048576 Max Area size: 1073735680 Degree: 1 Blocks to Sort: 1 Row size: 124 Total Rows: 1 Initial runs: 1 Merge passes: 1 IO Cost / pass: 934 Total IO sort cost: 468 Total CPU sort cost: 0 Total Temp space used: 0 Best:: JoinMethod: NestedLoop Cost: 472.00 Degree: 1 Resp: 471.50 Card: 0.22 Bytes: 103 *********************** Best so far: Table#: 0 cost: 1.0000 card: 0.2222 bytes: 41 Table#: 1 cost: 2.0000 card: 0.2222 bytes: 58 Table#: 2 cost: 3.0000 card: 0.2222 bytes: 76 Table#: 3 cost: 472.0000 card: 0.2222 bytes: 103 Cost of Sorting in Serial 35

Application Design (Inefficient Query) ****** Recost for parallel table scan ******* ORDER BY sort SORT ressource Sort statistics Sort width: 6142 Area size: 1048576 Max Area size: 1073735680 Degree: 1 Blocks to Sort: 1 Row size: 124 Total Rows: 1 Initial runs: 1 Merge passes: 1 IO Cost / pass: 934 Total IO sort cost: 468 Total CPU sort cost: 0 Total Temp space used: 0 SORT response Sort statistics Sort width: 638 Area size: 22369485 Max Area size: 111847424 Degree: 192 Blocks to Sort: 1 Row size: 124 Total Rows: 1 Initial runs: 1 Merge passes: 1 IO Cost / pass: 2 Total IO sort cost: 3 Total CPU sort cost: 0 Total Temp space used: 0 Best:: JoinMethod: NestedLoop Cost: 9.00 Degree: 192 Resp: 8.33 Card: 0.22 Bytes: 103 *********************** Best so far: Table#: 0 cost: 2.0000 card: 0.2222 bytes: 41 Table#: 1 cost: 3.0000 card: 0.2222 bytes: 58 Table#: 2 cost: 4.0000 card: 0.2222 bytes: 76 Table#: 3 cost: 9.0000 card: 0.2222 bytes: 103 Cost of Sorting in Parallel is Cheaper 36

Application Design (Power of Scalar) Select fn_getbranch(branchid), column1, column2.. From emp Where deptno in (10,20); Statistics EMP 2000 Rows DEPTNO 10 Distinct Values Where Deptno in (10,20) Returns 200 Rows What would be the total no. of executions of function fn_getbranch? test_scalar.sql 37

11/12/2012 11:21:01 AM 38

Ensuring Optimal Performance. Vivek Sharma. 3 rd November 2012 Sangam 2012