Performance Tuning Day- 8 Aug

8/16/2019 Performance Tuning Day- 8 Aug

http://slidepdf.com/reader/full/performance-tuning-day-8-aug 1/74

Performance Tuning Day - PuneVivek Sharma



Introduction & Disclaimer !

•

Around 14+ Years using Oracle Database• Specializes in Performance Optimization

• Database Technologists

• Member of Elite Engineering Exchange

•

Email : [email protected]

• Blog : viveklsharma.wordpress.com

The technical observations & views are my own. These are purely basedon my understanding, learning and resolution of various customer

issues.



Agenda for the day !

•

Database Concepts• Best Practices

• Query Optimizer

• Discussions

• Lunch & Tea Breaks!.



Performance & Scalability

4

0

100

200

300

400

500

600

700

800900

4 8 12 16 20 24 28 32

U s e

r L o a d

Resources

Linear



5

0

100

200

300

400

500

600

700

800

900

4 8 12 16 20 24 28 32

U s

e r L o a d

Resources

Linear

Actual

Desired

Problem

Performance & Scalability



Performance – Who’s responsibility ?

6

•

Application Developers – Proactive• Development DBA’s – Proactive

• Production DBA’s – Reactive

• Optimal Performance – Always

• Highly Scalable – Nearly Linear

• Ensure High Availability



Why Concepts ?

•

Database Architecture! SGA (Shared Pool / Buffer Cache)

! Read Consistency

! Logical Reads / Current Gets

•

Concurrency Controls

• Optimization, from Day ONE

• Database Features

!

The way these Work v/s Assumptions



At High Level !(in the order of priority)

Know! your Database

! your Development Tool

! your Data

8

A Mantra for a Successful Development Project

“Don’t treat Database as a Block Box”



Know your Development tool !(1)

9

|* 15 | HASH JOIN | | 1 | | 16 | TABLE ACCESS FULL | HZ_CUST_ACCT_SITES_ALL | 36983 | |* 17 | HASH JOIN | | 23952 | | 18 | TABLE ACCESS FULL | HZ_PARTY_SITES | 76710 | |* 19 | HASH JOIN | | 22674 | | 20 | TABLE ACCESS FULL | HZ_LOCATIONS | 72598 | |* 21 | HASH JOIN | | 22737 | | 22 | TABLE ACCESS FULL | HZ_CUST_ACCOUNTS | 14291 | |* 23 | HASH JOIN | | 22801 | | 24 | TABLE ACCESS BY INDEX ROWID | MTL_SYSTEM_ITEMS_B | 11073 | |* 25 | INDEX RANGE SCAN | MTL_SYSTEM_ITEMS_B_N16 | 11073 | |* 26 | HASH JOIN | | 130K| | 27 | TABLE ACCESS FULL | HR_LOCATIONS_ALL | 919 |

|* 28 | TABLE ACCESS BY INDEX ROWID| WSH_DELIVERY_DETAILS | 130K| |* 29 | INDEX RANGE SCAN | WSH_DELIVERY_DETAILS_TI4 | 143K|

This is the Run Time Plan for a Query executed from Oracle Reports

Run Time > 60 Minutes

https://viveklsharma.wordpress.com/2012/02/27/query-performance-issue-sqlplus-vs-oracle-reports/




10

This is the Run Time Plan for the same Query, when executed from SQL*Plus

Run Time < 1 Minute

| 18 | NESTED LOOPS | | 127 || 19 | MERGE JOIN | | 72 || 20 | TABLE ACCESS BY INDEX ROWID | WSH_TRIP_STOPS | 187 ||* 21 | INDEX RANGE SCAN | WSH_TRIP_STOPS_N1 | 187 ||* 22 | SORT JOIN | | 72 || 23 | TABLE ACCESS BY INDEX ROWID| WSH_TRIPS | 72 ||* 24 | INDEX RANGE SCAN | WSH_TRIPS_U1 | 72 || 25 | TABLE ACCESS BY INDEX ROWID | WSH_DELIVERY_LEGS | 2 ||* 26 | INDEX RANGE SCAN | WSH_DELIVERY_LEGS_N2 | 2 ||* 27 | INDEX RANGE SCAN | WSH_DELIVERY_ASSIGNMENTS_N1 | 3 || 28 | TABLE ACCESS BY INDEX ROWID | WSH_DELIVERY_ASSIGNMENTS | 4 ||* 29 | INDEX RANGE SCAN | WSH_DELIVERY_ASSIGNMENTS_N1 | 4 ||* 30 | TABLE ACCESS BY INDEX ROWID | WSH_DELIVERY_DETAILS | 1 |

|* 31 | INDEX RANGE SCAN | WSH_DELIVERY_DETAILS_TI4 | 1 |




11

10053 CBO Trace Reveals problem with Bind Peeking

*******************************************Peeked values of the binds in SQL statement

*******************************************----- Bind Info (kkscoacd) ----- Bind#0 oacdty=02 mxl=22(01) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=1000000 frm=00 csi=00 siz=72 off=0 No bind buffers allocated Bind#1 oacdty=02 mxl=22(01) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=1000000 frm=00 csi=00 siz=0 off=24 No bind buffers allocated

Bind#2 oacdty=02 mxl=22(01) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=1000000 frm=00 csi=00 siz=0 off=48 No bind buffers allocated Bind#3 No oacdef for this bind. Bind#4 No oacdef for this bind.



Architecture!Just Enough Diagram

12

User or App Server

Oracle

ServerProcess

NetworkOr Local

Shared Pool

LogBuffer

Buffer Cache

Shared Global Area - SGA

LGWR

DBWR

C h a n g e s

Disk Reads

1 1 g O p t i m

i z a t i o

n

Redo Logs

Commits / Rollbacks



Concepts!

13

•

Redo & Undo• Read Consistency

• Delayed Block Cleanout

• Snapshot too old (ora-01555)

• Concurrency

– Locks

– Latches / Mutexes

13



Redo & Undo!

•

Redo – Replay a Transaction

– Flushed from SGA to On-disk Logs

• Undo

–

Opposite of Redo – Put back the Data – as it was

– Critical for Read-Consistency

14

Not an overhead, but generate as minimal as possible



Maintaining Concurrency !

15

Readers do not block other Readers / WritersWriters do not block other Readers / Writers

Writers block other Writers (ONLY) at ROW Level

•

User 1 (seq 1)

– Update stocks setqty=qty-100 whereproduct = ‘A’;

•

User 2 (seq 2)

– Update stocks setqty=qty-10 whereproduct = ‘B’;

•

User 1 (seq 3)

– Update stocks setqty=qty-50 whereproduct=‘B’;

•

User 2 (seq 4)

– Update stocks setqty=qty-75 whereproduct=‘A’;

Success Success

Locked Deadlock



Maintaining Concurrency !(Contd)

•

Locks – Application Enforced

" Row Level Locking (TX Contention)

" Ora-00060

–

Oracle Enforced"

ITL (TX Lmode 4)

" Bitmap (TX Lmode 4)

" Duplicate Unique / Primary Key

" TM Contention

16

Except for ITL, others are an Application Issue

itl.sql



Question Time!

•

Is Initrans a Block level or a Table Level Parameter ?• What is the default value of Initrans for a table ?

• What is the default value of Initrans for an Index ?

• What is the value1 of Maxtrans ?

17

Maxtrans is Dictated by Block Size and is limited to max 255

Database Block Size 8192

Variable Header 48 Bytes

ITL 24 Bytes

8192-48 8144

50% of 8144 4072

4072/24 169 (round(169.66))itl.sql



ITL Allocation!



TM Contention!

•

Table Level Lock• Primary Cause

– Update to a Primary Key (A Bad Idea)

–

Unindexed Foreign Keys

19

User 1(11:57:50) Updates

update emp set empno=:b1, ename=:b2,ename=:b3, job=:b4,mgr=:b5, hiredate=:b6,sal=:b7, comm=:b8,

deptno=:b9where rowid=:rowid;

User 2(11:57:51) Updates

update dept set deptno=:b1,dname=:b2,loc=:b3

where rowid=:rowid;



TM Contention!(Contd)

•

Table Level Lock• Primary Cause

– Update to a Primary Key (A Bad Idea)

–

Unindexed Foreign Keys

20

Another Example of Critical to know your Development Tool

•

Tools that UPDATE every column

• Solution (Quantify the Pros & Cons)

–

Update only Relevant Columns (No Primary Keys)

– Index Foreign Keys



Row Level Lock !(Implications)

•

Impacts Concurrency - Serializes Transaction• Lost Update – Bad Application Design

• Optimistic v/s Pessimistic

21

An Example of Lost Update

User 1(11:55:53) Queries(11:57:50) Updates

update emp set empno=:b1,ename=:b2,doj=:b3,

add1=:b4,city=:b5where empno=:empno;

User 2(11:56:23) Queries(11:58:15) Updates

update emp set empno=:b1,ename=:b2,doj=:b3,

add1=:b4,city=:b5where empno=:empno;



Row Level Lock !(Implications)

•

Impacts Concurrency - Serializes Transaction• Lost Update – Bad Application Design

• Optimistic v/s Pessimistic

• Issue due to Transaction Restart

–

Difficult to Identify

22

rowlock.sql



The Shared Pool !

23

•

Objective – to read as much as from Memory

•

Stores Parsed Version of SQL’s / PLSQL’s

•

Split into various components – library cache, dictionary cache andmany more..

•

LRU Algorithm

•

Protected by Latches / Mutexes (Mutual Exclusive Lock)

•

Contention : Frequent Allocation / De-allocation of memory

• Contention : Frequent Loading of Cursors

23

Sharing SQL’s is key to effective Shared Pool UtilizationMaintain Coding Standards



24

Syntax / SemanticsChecks

Sharable ParentCursor

Available ?

Execute

Store Parent Cursor inLibrary Cache

Query Transformation /Execution Plans

Store child Cursor inLibrary Cache

Sharable ChildCursor

Available ?

N

N

Y

Y

Soft Parse

Parsing ! Soft v/s Hard



Coding Standard !(Multiple Parent Cursors)

25

Parent(select *from emp)

Child

Parent(select *from dept)

Child

Parent(SELECT *FROM EMP)

Child

Parent(select *from emp e)

Child

A Parent requires at least one Child Cursor

Obvious Problem



My Blog “Authorization Check Failed ! Multiple Child Cursors..” Dec 2013

Coding Standard !(Multiple Child Cursors)

Child 0

(Schema X)

Child 1

(Schema Y)

Child 2

(SchemaX with

OICA=10)

Child 3

(Schema

X withdifferent

bindlength)

Parent(select * from empwhere ename=:b1)

Obvious – but a problem Problem

mcc.sql

lc.sql



12c Improvement

Coding Standard !(Multiple Child Cursors)

1 Child Cursor / Schema

Pre 12c

Around 8000+ Child Cursors



Cursor Concepts!.(Bind Graduation)

Event 10503

select * from emp where ename=:b1;

Variable Length

:b1 10

:b1 30

:b1 40

:b1 80

:b1 140:b1 2040

1

2

3

4

Varchar2 Rounding

32

128

2000

4000

Bind Variable Graduation

bind_graduation.sql



Sharing SQL!

• Why ?

– For Performance Reason

– Scalability

– Effective Resource Utilization

" Memory

"

CPU

29

• How ?

– Implement Bind (only when required)

–

Maintain Coding Standard

test_bind.sql



Production Downtime !(Real Life Example)

Snap Id Snap Time Sessions Curs/Sess--------- ------------------- -------- ---------

Begin Snap: 24222 18-Apr-14 11:30:27 401 74.5

End Snap: 24223 18-Apr-14 12:30:16 783 86.0Elapsed: 59.81 (mins)DB Time: 1,133.51 (mins)

Cache Sizes~~~~~~~~~~~ Begin End

---------- ----------Buffer Cache: 23,552M 23,552M Std Block Size: 8K

Shared Pool Size: 12,288M 12,288M Log Buffer: 15,112K

Load Profile~~~~~~~~~~~~ Per Second Per Transaction

--------------- ---------------Redo size: 859,548.86 25,693.53

Logical reads: 154,690.90 4,624.00Block changes: 3,634.57 108.64Physical reads: 1,515.71 45.31Physical writes: 296.98 8.88

User calls: 2,817.43 84.22Parses: 2,842.89 84.98

Hard parses: 156.49 4.68Sorts: 664.11 19.85Logons: 0.97 0.03

Executes: 6,454.01 192.92Transactions: 33.45

19 Active

5.5%



Production Downtime !(Real Life Example)

Top 5 Timed Events Avg %Total~~~~~~~~~~~~~~~~~~ wait CallEvent Waits Time (s) (ms) Time Wait Class------------------------------ ------------ ----------- ------ ------ ----------db file sequential read 4,874,348 35,300 7 51.9 User I/OCPU time 22,056 32.4ARCH wait on SENDREQ 2,787 13,399 4808 19.7 Networkgc cr block busy 238,851 2,833 12 4.2 Clustergcs log flush sync 1,017,044 2,672 3 3.9 Other

-------------------------------------------------------------

Instance Activity Stats DB/Inst: IIMSP/IIMSP2 Snaps: 24222-24223

Statistic Total per Second per Trans-------------------------------- ------------------ -------------- -------------parse count (failures) 357,665 99.7 3.0parse count (hard) 561,605 156.5 4.7parse count (total) 10,202,613 2,842.9 85.0

64% Failures

Fix High Hard Parse Failures = Unwanted Work

Fix Hard Parseshttps://viveklsharma.wordpress.com/2011/09/03/do-we-need-to-take-care-of-hard-parses-only-when-library-cache-related-latches-are-on-top/



Question Time!

•

Give few Examples, when the Cursors are not sharedeven after using Bind Variables ?

32

–

Optimizer Parameters

– Bind Type Mismatch

–

Bind Variable Mismatch –

SQL Trace

Sharing of Cursors – Key to Scalability



SGA! the Buffer Cache

• Objective – to read as much as from Memory

•

Caches Database Blocks to eliminate Disk I/O

•

Blocks are either Dirty or Clean

•

LRU Algorithm, Mid Point Insertion & Touch Count (TCH)

•

Protected by Latches to maintain LRU and TCH

•

Contention : Unwanted I/O’s

• Contention : Concurrent Access to a Block

33

Logical Reads are faster than Disk Reads

Logical Reads consume CPU

Effective Utilization of Cache – Optimizing I/O’s



CBC Latch Issue!(A Real Life Example)

• Oracle Database Version 9204

• Issue – Severe Cache Buffers Chain Latch Contention

• Impact – Production DB Hang

• Analysis

–

Latch Distribution & Comparison (Good v/s Bad Period) –

Hot Block & Object – Top Latch

– Top Queries – Based on the Object/Block

Concurrent Access to a Block can cause Concurrency Issue

https://viveklsharma.wordpress.com/2010/05/13/cache-buffers-chains-latch-contention/




HLADDR COUNT(*)---------------- ----------07000003E2771BA8 19707000003E661DE70 161

07000003E6305250 15707000003E661CE90 15707000003E3F2B0E8 15407000003E199FA00 15307000003E4E45FF0 15307000003E6607150 15307000003E76A42D0 15207000003E19A19C0 151

select * from (

select hladdr, count(*) from x$bh group by hladdrorder by 2 desc) where rownum<=10;

HLADDR COUNT(*)---------------- ----------07000002570F7300 8734070000025A786078 364

070000025A5020D8 1670700000262E9A9E0 16707000002562DD4D0 16407000002583D9C00 16407000002563162C0 16107000002563BE270 16107000002571D9AF0 1610700000262E9C420 161

Good Period Bad Period




Select a.file#, a.dbablk, a.tch, a.obj, b.object_namefrom x$bh a,

dba_objects b where (a.obj = b.object_id or a.obj = b.data_object_id)and hladdr='07000002570F7300'order by 3 desc;

• HLADDR – Hash Latch Address

– P1RAW from v$session

–

P2 – Latch Number (Versions <=9i)

– Hot Block & Object – Top Latch

– Bigger the Chain, Higher the chances of Contention

• TCH – Touch Count

–

High the TCH, Hot is the Block

–

Is Incremented every 3 Seconds



Buffer Cache Structure!(Representation)

cbctest.sql

# Chains dictated by _db_block_hash_buckets & Size of the Cache




HASH_VALUE SQL_TEXT EXEC GETS/EXEC---------- -------------------------------------------------- ---- --------- 603848796 SELECT FN_NEWBRANCH(A.BRANCH) BRANCH, A.PROD 1 5294194 UCT_CODE PRODUCT, B.PRODUCT_DESCRIPTION PROD_DE SCRIPTION, A.CONTRACT_REF_NO CONTRACT_REF_NO, A.USER_REF_NO USER_REF_NO, C.COLLECTION_REF, C.BILL_CCY BILL_CCY, C.BILL_AMT BILL_AMOUNT, 784509366 SELECT FN_NEWBRANCH(C.BRANCH) BRANCH, C.PROD 8 2306090 UCT_CODE PROD_CODE, C.CONTRACT_REF_NO, C.USE R_REF_NO, B.PARTY_ID DRAWER_ID, B.PARTY_N AME DRAWER, B.PARTY_REFNO DRAWER_REF, A.PART

Y_ID DRAWEE_ID, A.PARTY_NAME DRAWEE, A.PARTY 322980110 SELECT FN_NEWBRANCH(CSTBS_CONTRACT.BRANCH), 3 811376 CSTBS_CONTRACT.PRODUCT_CODE, CSTMS_PRODUCT.PROD UCT_DESCRIPTION, BCTB_CONTRACT_MASTER.CUSTOMER_ ID, STTMS_CUSTOMER.CUSTOMER_NAME1, CSTBS_CON TRACT.CONTRACT_REF_NO, CSTBS_CONTRACT.USER_REF_

•

Who is the Culprit ?

–

Queries with Millions of Logical Reads, and/or

– A Query with 4 Logical Read/Execution but multiple executions




• Optimization

–

In 9204 (& 10g)

–

Starting 11g

– Alternative, Reducing #Rows/Blocks

test_scalar.sql

Blog on “Cache Buffers Chains Latch Contention!

” May 2010

Scalar Subqueries, DETERMINISTIC, RESULT_CACHE



•

db file sequential read• db file scattered read

• read by other session

• direct path read

• Latches / Mutexes

Single Block ReadsMulti Block Reads

Block Level Contention

Smart Scans - Exadata

Concurrency

Eliminating Waits critical for Response Sensitive Application

Oracle Waits!to name a few



A Full Table Scan of a 24 Block Table with dfmrc = 4

"#$%#&'

(#)*#+

,-./0 1 ,-./0 2 343(56 ,-./0 7 ,-./0 8 ,-./0 9 ,-./0 :

,-./0 ; ,-./0 <

343(56

,-./0 1= ,-./0 11

343(56

,-./0 12 ,-./0 1> ,-./0 17

343(56

,-./0 18

343(56

,-./0 19 ,-./0 1: ,-./0 1;

343(56

,-./0 1< ,-./0 2= ,-./0 21 ,-./0 22 ,-./0 2>

db file scattered reads Count

db file sequential reads Count

5

4

Multiblock Read Concept !



Question Time!

44

In terms of performance –

Is there any difference between these queries ?

select a1, a10 from a where rowid=:rowid;

Additional LIO’s due to Intra-Block Chaining

Table A

Rows 10000

Blocks 100

Columns 300



Intra_block.sql

I/O’s (300 Columns) I/O’s (600 Columns)

1 to 45 = 7 I/O’s 1 to 90 = 7 I/O’s

46 to 300 = 8 I/O’s 91 to 345 = 8 I/O’s

346 onwards = 9 I/O’s



Row Migration!

•

Usual – Index Block to Table Block• Issue – Index Block to Table Block to Table Block

• Impact due to Additional Hop (IO)

• Impact Index Scans

•

Improper PCTREE Settings

45

row_migration.sql

table fetch continued row

table fetch continued row+table scan rows gotten

High Ratio = Row Migration, Row Chaining, > 255 Columns



Why things go wrong ?

• Improper Testing

•

Inefficient Queries

• Inefficient Indexes / Index not being used

• Optimizer Statistics

–

Stale / Incomplete Statistics

•

Caching Effect –

Optimizer’s Inability to Quantify benefit of Cache’s

• Functions in WHERE predicate

• Bad Physical Design / Change in the Environment –

Database / Application level changes



Improper Testing !

• Explain Plan Trap

• Issue with Autotrace

• Bind with Bind / Literal with Literal

• UAT Equivalent to Production

ep.sql



Investigating Query Performance!

•

Use dbms_xplan.display_cursor – Current Plan

•

Use dbms_xplan.display_awr – History

•

Divide & Rule – Smaller Query, Easier to work

• Test with Bind for Bind & Literal for Literal – v$sql_bind_capture

•

Gather_Plan_Statistics / Statistics_level – allstats last

•

Compare E-Rows & A-Rows – Issue if high discrepancy

qp.sql

Gather_Plan_Statistics / Statistics_Level Critical for Investigation



• Introduced in 9i

•

Hard Parse, as if Bind is a Literal

• Appropriate Plan based on Bind Value

• 9i & 10g, Hard Parse Bind Value Wins

•

11g Introduced Adaptive Cursor Sharing• Plan Upgraded, post subsequent executions

• Bad Query Performance, at least once

bp.sql

How do you take care of a High Performance Application ?

Bind Peeking !





•

Inefficient Queries



–


•

Caching Effect –







Inefficient Queries!

Leave Blank for ALL

Leave Blank for ALL

Note : Either or Both column selection is mandatory

where (cust_last_name=:cust_last_name or :cust_last_name is null)and (cust_first_name=:cust_first_name or :cust_first_name is null);

pd.sql

Where cust_last_name = nvl(:cust_last_name,cust_last_name)and cust_first_name = nvl(:cust_first_name,cust_first_name);





•

Inefficient Queries



–


•

Caching Effect –







Indexes not being used !

• Mismatch in Column Data Type & Bind Variable

•

Avoid masking an Indexed column with a Function

•

Feed additional Statistics on Column Dependency

•

Use NULLS instead of using Too Higher or Lower Range

•

Histograms, wherever required

•

Reduce Throwaway – Better Indexing

ne.sql



54

l_sql_stmt1 := l_sql_stmt1||'INSERT INTO A_INV_RIDSSELECT ROWID FROM A_INV AI WHERE CASE WHEN

PAYMENT_STATUS=''Y'' THEN 0 ELSE 1 END = 1 ';

l_sql_stmt2 := l_sql_stmt2||'INSERT INTO A_INV_RIDSSELECT ROWID FROM A_INV AI WHERE CASE WHENHISTORICAL_FLAG=''Y'' THEN 0 ELSE 1 END = 1 ';

l_sql_stmt3 := l_sql_stmt3||'INSERT INTO A_INV_RIDSSELECT ROWID FROM A_INV AI WHERE CASE WHENNVL(REVALIDATION_FLAG,''N'')=''N'' THEN 0 ELSE 1 END = 1 ';

•

Introduced a GTT & Three New Indexes using CASE

•

Populated the ROWID’s in the GTT

•

SubQuery Factoring joining Original Table with GTT

•

Only the filtered rows were then joined to other Tables

•

Query Run Time = Around 3 Minutes

Indexes not being used !(a real life example)!



Indexes not being used !(a real life example)!

55

l_sql_stmt :=l_sql_stmt||

'SELECT invoice_id from A_INV AI WHERE AI. REQUEST_ID IS NULL

AND AI.APPROVAL_READY_FLAG <> ''S'' AND AI.INVOICE_TYPE<>''INVOICE REQUEST’’

AND AI.CANCELLED_DATE IS NULL AND NOT (NVL(AI.PAYMENT_STATUS,''N'') = ''Y''

AND NVL(AI.HISTORICAL_FLAG,''N'') = ''Y'' AND NVL(AI.REVALIDATION_FLAG,''N'') = ''N'')

AND ……

• The 3 Predicates (in RED) filters out 96% of Data

•

Mismatch in Column Data Type & Bind Variable

•

Indexes exists on NVL but not getting used

•

Query Run Time = Around 70 Minutes



Indexes not being used !(Real Life Example)

INST_ID SQL_ID SQL_TEXT EXECUTIONS BUFFER_GETS-------- ------------- ---------------------------------------- ---------- ----------- 1 1kfxns3m02pu3 select distinct TXT_ADDRESS_LINE_1 , TXT 28 1213546962

_ADDRESS_LINE_2 , TXT_APARTMENT , TXT_ST REET , TXT_CITYDISTRICT , TXT_AREAVILLAG E , TXT_STATE , NUM_PINCODE from genmst_ location a, Risk_headers b where a.NUM_L OCATION_CD = b.location_code and a.num_l ocation_cd = (SELECT location_code FROM risk_headers WHERE reference_num = :"SYS _B_0" AND reference_date = TO_DATE (:"SY S_B_1", :"SYS_B_2") and POLICY_RISK_SERI AL = :"SYS_B_3")

Enter value for table: RISK_HEADERS

OWNER NUM_ROWS BLOCKS---------- ---------- ----------INS 14844896 846555

select distinct TXT_ADDRESS_LINE_1, TXT_ADDRESS_LINE_2, TXT_APARTMENT, TXT_STREET ,TXT_CITYDISTRICT , TXT_AREAVILLAGE , TXT_STATE , NUM_PINCODE

From genmst_location a,Risk_headers b

where to_a.NUM_LOCATION_CD = b.location_code and a.num_location_cd = (SELECT location_code FROM INS.risk_headers

WHERE reference_num = '201412200014630’ AND reference_date = TO_DATE('20/12/2014','DD/MM/YYYY’)and POLICY_RISK_SERIAL = 1)




Plan hash value: 3915633919--------------------------------------------------------------| Id | Operation | Name |--------------------------------------------------------------

| 0 | SELECT STATEMENT | || 1 | HASH UNIQUE | || 2 | NESTED LOOPS | || 3 | TABLE ACCESS BY INDEX ROWID | GENMST_LOCATION ||* 4 | INDEX UNIQUE SCAN | PK_GENMST_LOCATION || 5 | TABLE ACCESS BY INDEX ROWID| RISK_HEADERS ||* 6 | INDEX UNIQUE SCAN | PK_RISK_HEADERS ||* 7 | TABLE ACCESS FULL | RISK_HEADERS |--------------------------------------------------------------

Predicate Information (identified by operation id):---------------------------------------------------

4 - access("A"."NUM_LOCATION_CD"=TO_NUMBER()) 6 - access("REFERENCE_NUM"=TO_NUMBER(:SYS_B_0) AND "REFERENCE_DATE"=TO_DATE(:SYS_B_1,:SYS_B_2) AND "POLICY_RISK_SERIAL"=:SYS_B_3) 7 - filter("A"."NUM_LOCATION_CD"=TO_NUMBER("B"."LOCATION_CODE"))


From genmst_location a,Risk_headers b

where to_a.NUM_LOCATION_CD = b.location_code and a.num_location_cd = (SELECT location_code FROM INS.risk_headers






From genmst_location a,Risk_headers b where to_char(to_a.NUM_LOCATION_CD) = b.location_code and a.num_location_cd = (SELECT location_code FROM INS.risk_headers


Datatype Mismatch – Should be taken care during Design Phase





•

Inefficient Queries



–


•

Caching Effect –







os.sql

• Upto Date Statistics – Object / System Statistics

•

Column Level relevant Inputs to Optimizer

• Co-Related Column Stats

Optimizer Statistics!

os12c.sql

SEED_COL_USAGE – Representative Workload

SQL PLAN DIRECTIVE – Automatic Optimizer





•

Inefficient Queries



–


•

Caching Effect –







cf.sql

Benefits Elapsed time.

Optimizer’s Inability to Quantify

•

Buffer Cache• Result Cache

• Scalar Subquery Caching

Caching Effect !



63

TABLE_CACHED_BLOCK Preference (1 – Default to 255)

•

Most Important Statistics•

Affects Optimizer Choice of Execution Plan

• Measure of I/O’s to read a Table via an Index

•

Assumes, each Table Block read is a new Block

Clustering Factor !(12c Enhancement)





•

Inefficient Queries



–


•

Caching Effect –







•

Improper Cardinality Calculation• Impact on Indexes

• Selectivity guess of 1%

fs.sql

Avoid Using Functions in WHERE Predicate

Associate Statististics for Functions to provide better Selectivity

Functions in WHERE Predicate!





•

Inefficient Queries



–


•

Caching Effect –







•

Column Ordering matters ?• Column Skip consumes CPU

• Frequently Queried columns @ Start

Performance v/s Storage Space

Bad Physical Design!




Is there any difference between the two queries ?

select id, n1 from T1 where n2=:b1

Table Num Rows Num Blocks

T1 100000 846

T2 100000 846


No Indexes. Id, n1 and n2 are NUMBER Datatype




Column_ID T1 T2

1 ID ID

2 N1 N1

3 N2 N3

4 N3 N4

5 N4 N5

6 N5 N6

7 N6 N7

8 N7 N8

9 N8 N9

10 N9 V6

11 V6 N10

12 N10 N1113 N11 N2




•

Table A with 13 Columns (A1..A13)



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




0

5000

10000

15000

20000

25000

30000

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49

CPU Cycles

1st Column 13th Column







Table Num Rows Num Blocks

T1 100000 846

T2 100000 846

select id, n1 from T2 where n2=:b1No Indexes. Id, n1 and n2 are NUMBER Datatype

co.sql


Q i k Q ti



Quick Questions!

• Mark a Query Interesting (to appear in AWR) ?

• Check Preferences for DBMS_STATS ?

dbms_workload.add_colored_sql

optstat_hist_control$

•

What is the Usage of Bitmap Indexes ?Low cardinality column ? Not necessarily

Performance Tuning Day- 8 Aug

Documents

Transcript of Performance Tuning Day- 8 Aug