Performance Tuning Day - 8 Aug

Performance Tuning Day - Pune
Vivek Sharma
Introduction & Disclaimer

Around 14+ Years using Oracle Database
Specializes in Performance Optimization
Database Technologists
Member of Elite Engineering Exchange
Email : vivek.s.sharma@oracle.com
Blog : viveklsharma.wordpress.com
The technical observations & views are my own. These are purely based
on 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

900
800
User Load
700
600
500
400
Linear
300
200
100
0
4
12
16
20
Resources
24
28
32
Performance & Scalability

900
800
User Load
700
Desired
600
500
400
Linear
300
Actual
Problem
200
100
0
4
12
16
20
Resources
24
28
32
Performance Whos responsibility ?

Application Developers Proactive
Development DBAs Proactive
Production DBAs 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
A Mantra for a Successful Development Project

Dont treat Database as a Block Box
Know your Development tool(1)

|*
|
|*
|
|*
|
|*
|
|*
|
|*
|*
|
|*
|*
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HASH JOIN
|
TABLE ACCESS FULL
|
HASH JOIN
|
TABLE ACCESS FULL
|
HASH JOIN
|
TABLE ACCESS FULL
|
HASH JOIN
|
TABLE ACCESS FULL
|
HASH JOIN
|
TABLE ACCESS BY INDEX ROWID |
INDEX RANGE SCAN
|
HASH JOIN
|
TABLE ACCESS FULL
|
TABLE ACCESS BY INDEX ROWID|
INDEX RANGE SCAN
|
HZ_CUST_ACCT_SITES_ALL
HZ_PARTY_SITES
HZ_LOCATIONS
HZ_CUST_ACCOUNTS
MTL_SYSTEM_ITEMS_B
MTL_SYSTEM_ITEMS_B_N16
HR_LOCATIONS_ALL
WSH_DELIVERY_DETAILS
WSH_DELIVERY_DETAILS_TI4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
36983 |
23952 |
76710 |
22674 |
72598 |
22737 |
14291 |
22801 |
11073 |
11073 |
130K|
919 |
130K|
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/

|
|
|
|*
|*
|
|*
|
|*
|*
|
|*
|*
|*
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NESTED LOOPS
|
MERGE JOIN
|
INDEX RANGE SCAN
|
SORT JOIN
|
TABLE ACCESS BY INDEX ROWID|
INDEX RANGE SCAN
|
INDEX RANGE SCAN
|
INDEX RANGE SCAN
|
TABLE ACCESS BY INDEX ROWID
|
INDEX RANGE SCAN
|
TABLE ACCESS BY INDEX ROWID
|
INDEX RANGE SCAN
|
|
|
WSH_TRIP_STOPS
|
WSH_TRIP_STOPS_N1
|
|
WSH_TRIPS
|
WSH_TRIPS_U1
|
WSH_DELIVERY_LEGS
|
WSH_DELIVERY_LEGS_N2
|
WSH_DELIVERY_ASSIGNMENTS_N1 |
WSH_DELIVERY_ASSIGNMENTS
|
WSH_DELIVERY_ASSIGNMENTS_N1 |
WSH_DELIVERY_DETAILS
|
WSH_DELIVERY_DETAILS_TI4
|
127
72
187
187
72
72
72
2
2
3
4
4
1
1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is the Run Time Plan for the same Query, when executed from SQL*Plus
Run Time < 1 Minute
10

*******************************************
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
Bind#2
Bind#3
No oacdef for this bind.
Bind#4
No oacdef for this bind.
10053 CBO Trace Reveals problem with Bind Peeking
11
ArchitectureJust Enough Diagram

Shared Global Area - SGA
User or
App Server
Shared Pool
Log
Buffer
Network
Or Local
Redo Logs
LGWR
Oracle
Server
Process
Commits / Rollbacks
Cha
nge
DBWR
Disk Reads
Buffer Cache
11g
Op
iz
tim
ati
on
12
Concepts
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
Not an overhead, but generate as minimal as possible
14
Maintaining Concurrency
User 1 (seq 1)
Success
Update stocks set

qty=qty-100 where
product = A;
User 1 (seq 3)
Locked
Update stocks set

qty=qty-50 where
product=B;
User 2 (seq 2)
Success
Update stocks set

qty=qty-10 where
product = B;
User 2 (seq 4)
Deadlock
Update stocks set

qty=qty-75 where
product=A;
Readers do not block other Readers / Writers

Writers do not block other Readers / Writers
Writers block other Writers (ONLY) at ROW Level
15
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
Except for ITL, others are an Application Issue
itl.sql
16
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 ?
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
17
ITL Allocation
TM Contention
Table Level Lock
Primary Cause
Update to a Primary Key (A Bad Idea)
Unindexed Foreign Keys
User 1
(11:57:50) Updates
User 2
(11:57:51) Updates
update emp set empno=:b1, ename=:b2,

ename=:b3, job=:b4,
mgr=:b5, hiredate=:b6,
sal=:b7, comm=:b8,
deptno=:b9
where rowid=:rowid;
update dept set deptno=:b1,

dname=:b2,
loc=:b3
where rowid=:rowid;
19
TM Contention(Contd)
Table Level Lock
Primary Cause
Update to a Primary Key (A Bad Idea)
Unindexed Foreign Keys
Tools that UPDATE every column

Solution (Quantify the Pros & Cons)
Update only Relevant Columns (No Primary Keys)
Index Foreign Keys
Another Example of Critical to know your Development Tool
20
Row Level Lock(Implications)

Impacts Concurrency - Serializes Transaction
Lost Update Bad Application Design
Optimistic v/s Pessimistic
An Example of Lost Update
User 1
(11:55:53) Queries
(11:57:50) Updates
User 2
(11:56:23) Queries
(11:58:15) Updates
update emp set empno=:b1,

ename=:b2,
doj=:b3,
add1=:b4,
city=:b5
where empno=:empno;
update emp set empno=:b1,

ename=:b2,
doj=:b3,
add1=:b4,
city=:b5
where empno=:empno;
21
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
rowlock.sql
22
The Shared Pool

Objective to read as much as from Memory
Stores Parsed Version of SQLs / PLSQLs
Split into various components library cache, dictionary cache and
many more..
LRU Algorithm
Protected by Latches / Mutexes (Mutual Exclusive Lock)
Contention : Frequent Allocation / De-allocation of memory
Contention : Frequent Loading of Cursors
Sharing SQLs is key to effective Shared Pool Utilization

Maintain Coding Standards
23
Parsing Soft v/s Hard

Syntax / Semantics
Checks
Soft Parse
Sharable Parent
Cursor
Available ?
Y
Store Parent Cursor in
Library Cache
Sharable Child
Cursor
Available ?
N
Query Transformation /
Execution Plans
Store child Cursor in

Library Cache
Execute
24
Coding Standard(Multiple Parent Cursors)

Obvious
Problem
Parent
Parent
Parent
Parent
(select *
from emp)
(select *
from dept)
(SELECT *
FROM EMP)
(select *
from emp e)
Child
Child
Child
Child
A Parent requires at least one Child Cursor
25
Coding Standard(Multiple Child Cursors)

Parent
(select * from emp

where ename=:b1)
Child 0
(Schema
X)
Child 1
(Schema
Child 2
(Schema
Child 3
(Schema
Y)
X with
OICA=10)
X with
different
bind
length)
Obvious but a problem
Problem
My Blog Authorization Check Failed ! Multiple Child Cursors.. Dec 2013

mcc.sql
lc.sql
Coding Standard(Multiple Child Cursors)

12c Improvement
1 Child Cursor / Schema
Pre 12c
Around 8000+ Child Cursors
Cursor Concepts.(Bind Graduation)

select * from emp where ename=:b1;
Variable
:b1
:b1
:b1
:b1
:b1
:b1
Length
10
30
40
80
140
2040
1
2
Bind Variable
3
4
Varchar2 Rounding
32
128
Graduation
2000
4000
Event 10503
bind_graduation.sql
Sharing SQL
Why ?
For Performance Reason
Scalability
Effective Resource Utilization
Memory
CPU
How ?
Implement Bind (only when required)
Maintain Coding Standard
test_bind.sql
29
Production Downtime
Snap Id
(Real Life Example)
Snap Time
Sessions Curs/Sess
--------- ------------------- -------- --------24222 18-Apr-14 11:30:27
401
74.5
24223 18-Apr-14 12:30:16
783
86.0
59.81 (mins)
19 Active
1,133.51 (mins)
Begin Snap:
End Snap:
Elapsed:
DB Time:
Cache Sizes
~~~~~~~~~~~
Begin
End
---------- ---------Buffer Cache:
23,552M
23,552M
Shared Pool Size:
12,288M
12,288M
Load Profile
~~~~~~~~~~~~
Redo size:
Logical reads:
Block changes:
Physical reads:
Physical writes:
User calls:
Parses:
Hard parses:
Sorts:
Logons:
Executes:
Transactions:
Per Second
--------------859,548.86
154,690.90
3,634.57
1,515.71
296.98
2,817.43
2,842.89
156.49
664.11
0.97
6,454.01
33.45
Std Block Size:

Log Buffer:
8K
15,112K
Per Transaction
--------------25,693.53
4,624.00
108.64
45.31
8.88
84.225.5%
84.98
4.68
19.85
0.03
192.92
Production Downtime
(Real Life Example)
Top 5 Timed Events

Avg %Total
~~~~~~~~~~~~~~~~~~
wait
Call
Event
Waits
Time (s)
(ms)
Time Wait Class
------------------------------ ------------ ----------- ------ ------ ---------db file sequential read
4,874,348
35,300
7
51.9
User I/O
CPU time
22,056
32.4
ARCH wait on SENDREQ
2,787
13,399
4808
19.7
Network
gc cr block busy
238,851
2,833
12
4.2
Cluster
gcs 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.0
parse count (hard)
561,605
156.5
4.7
64% Failures
parse count (total)
10,202,613
2,842.9
85.0
Fix High Hard Parse Failures = Unwanted Work

Fix Hard Parses
https://viveklsharma.wordpress.com/2011/09/03/do-we-need-to-take-care-of-hard-parses-only-when-library-cache-relatedlatches-are-on-top/
Question Time
Give few Examples, when the Cursors are not shared
even after using Bind Variables ?
Optimizer Parameters
Bind Type Mismatch
Bind Variable Mismatch
SQL Trace
Sharing of Cursors Key to Scalability
32
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/Os
Contention : Concurrent Access to a Block
Logical Reads are faster than Disk Reads
Logical Reads consume CPU
Effective Utilization of Cache Optimizing I/Os
33
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/

select * from (
select hladdr, count(*) from x$bh group by hladdr
order by 2 desc)
where rownum<=10;
HLADDR
COUNT(*)
---------------- ---------07000003E2771BA8
197
07000003E661DE70
161
07000003E6305250
157
07000003E661CE90
157
07000003E3F2B0E8
154
07000003E199FA00
153
07000003E4E45FF0
153
07000003E6607150
153
07000003E76A42D0
152
07000003E19A19C0
151
HLADDR
COUNT(*)
---------------- ---------07000002570F7300
8734
070000025A786078
364
070000025A5020D8
167
0700000262E9A9E0
167
07000002562DD4D0
164
07000002583D9C00
164
07000002563162C0
161
07000002563BE270
161
07000002571D9AF0
161
0700000262E9C420
161
Good Period
Bad Period

select * from (
select hladdr, count(*) from x$bh group by hladdr
order by 2 desc)
where rownum<=10;
HLADDR
COUNT(*)
---------------- ---------07000003E2771BA8
197
07000003E661DE70
161
07000003E6305250
157
07000003E661CE90
157
07000003E3F2B0E8
154
07000003E199FA00
153
07000003E4E45FF0
153
07000003E6607150
153
07000003E76A42D0
152
07000003E19A19C0
151
HLADDR
COUNT(*)
---------------- ---------07000002570F7300
8734
070000025A786078
364
070000025A5020D8
167
0700000262E9A9E0
167
07000002562DD4D0
164
07000002583D9C00
164
07000002563162C0
161
07000002563BE270
161
07000002571D9AF0
161
0700000262E9C420
161
Good Period
Bad Period

Select a.file#, a.dbablk, a.tch, a.obj, b.object_name
from
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)
# Chains dictated by _db_block_hash_buckets & Size of the Cache

cbctest.sql

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
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
2306090
322980110 SELECT
FN_NEWBRANCH(CSTBS_CONTRACT.BRANCH),
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_
811376
Who is the Culprit ?

Queries with Millions of Logical Reads, and/or
A Query with 4 Logical Read/Execution but multiple executions

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
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
2306090
322980110 SELECT
FN_NEWBRANCH(CSTBS_CONTRACT.BRANCH),
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_
811376
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
Scalar Subqueries, DETERMINISTIC, RESULT_CACHE

Blog on Cache Buffers Chains Latch Contention May 2010
test_scalar.sql
Oracle Waitsto name a few

db file sequential read
Single Block Reads
db file scattered read
Multi Block Reads
read by other session
Block Level Contention
direct path read
Smart Scans - Exadata
Latches / Mutexes
Concurrency
Eliminating Waits critical for Response Sensitive Application
Multiblock Read Concept

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

Segment Block 1
Header

Block 2

CACHED

Block 4

Block 5

Block 6

Block 7

Block 8 Block 9 Block 10 Block 11 Block 12 Block 13 Block 14 Block 15

CACHED
CACHED
CACHED CACHED

Block 16 Block 17 Block 18 Block 19 Block 20 Block 21 Block 22 Block 23

CACHED

db file scattered reads Count
db file sequential reads Count
5
4
Question Time
Table
I/Os (300 Columns) I/Os (600 Columns)
Rows
10000
1 to 45 = 7 I/Os
1 to 90 = 7 I/Os
Blocks
100
46 to 300 = 8 I/Os
91 to 345 = 8 I/Os
Columns
300
346 onwards = 9 I/Os
In terms of performance
Is there any difference between these queries ?
select a1, a10 from a where rowid=:rowid;

Additional LIOs due to Intra-Block Chaining
Intra_block.sql
44
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
table fetch continued row
table fetch continued row+table scan rows gotten
High Ratio = Row Migration, Row Chaining, > 255 Columns
row_migration.sql
45
Why things go wrong ?
Improper Testing
Inefficient Queries
Inefficient Indexes / Index not being used
Optimizer Statistics
Stale / Incomplete Statistics
Caching Effect
Optimizers Inability to Quantify benefit of Caches
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
Gather_Plan_Statistics / Statistics_Level Critical for Investigation

qp.sql
Bind Peeking
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
How do you take care of a High Performance Application ?
bp.sql
Improper Testing
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);
Where
cust_last_name = nvl(:cust_last_name,cust_last_name)
and cust_first_name = nvl(:cust_first_name,cust_first_name);
pd.sql
Improper Testing
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
Indexes not being used(a real life example)

l_sql_stmt1 := l_sql_stmt1||'INSERT INTO A_INV_RIDS
SELECT ROWID FROM A_INV AI WHERE CASE WHEN
PAYMENT_STATUS=''Y'' THEN 0 ELSE 1 END = 1 ';
HISTORICAL_FLAG=''Y'' THEN 0 ELSE 1 END = 1 ';
NVL(REVALIDATION_FLAG,''N'')=''N'' THEN 0 ELSE 1 END = 1 ';
Introduced a GTT & Three New Indexes using CASE

Populated the ROWIDs 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
54
54
Indexes not being used(a real life example)

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
55
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)

Risk_headers b
where to_a.NUM_LOCATION_CD = b.location_code
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"))

Risk_headers b
where to_char(to_a.NUM_LOCATION_CD) = b.location_code
Datatype Mismatch Should be taken care during Design Phase
Improper Testing
Inefficient Queries
Caching Effect

Upto Date Statistics Object / System Statistics
Column Level relevant Inputs to Optimizer
Co-Related Column Stats
SEED_COL_USAGE Representative Workload

SQL PLAN DIRECTIVE Automatic Optimizer
os.sql
os12c.sql
Improper Testing
Inefficient Queries
Caching Effect

Caching Effect
Buffer Cache
Result Cache
Scalar Subquery Caching
Benefits Elapsed time.

Optimizers Inability to Quantify
cf.sql
Clustering Factor(12c Enhancement)

Most Important Statistics
Affects Optimizer Choice of Execution Plan
Measure of I/Os to read a Table via an Index
Assumes, each Table Block read is a new Block
TABLE_CACHED_BLOCK Preference (1 Default to 255)
63
Improper Testing
Inefficient Queries
Caching Effect

Functions in WHERE Predicate

Improper Cardinality Calculation
Impact on Indexes
Selectivity guess of 1%
Avoid Using Functions in WHERE Predicate

Associate Statististics for Functions to provide better Selectivity
fs.sql
Improper Testing
Inefficient Queries
Caching Effect

Bad Physical Design

Column Ordering matters ?
Column Skip consumes CPU
Frequently Queried columns @ Start
Performance v/s Storage Space
Bad Physical Design

Table
Num Rows
Num Blocks
T1
100000
846
T2
100000
846
Is there any difference between the two queries ?
select id, n1 from T1 where n2=:b1

No Indexes. Id, n1 and n2 are NUMBER Datatype
Bad Physical Design

Column_ID
T1
T2
ID
ID
N1
N1
N2
N3
N3
N4
N4
N5
N5
N6
N6
N7
N7
N8
N8
N9
10
N9
V6
11
V6
N10
12
N10
N11
13
N11
N2
Bad Physical Design

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
70
Bad Physical Design

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

Table
Num Rows
Num Blocks
T1
100000
846
T2
100000
846

No Indexes. Id, n1 and n2 are NUMBER Datatype
co.sql
Quick Questions
Mark a Query Interesting (to appear in AWR) ?
dbms_workload.add_colored_sql
Check Preferences for DBMS_STATS ?

optstat_hist_control$
What is the Usage of Bitmap Indexes ?

Low cardinality column ? Not necessarily
Q&
A
19/08/15 10:20 PM
74

Performance Tuning Day - 8 Aug

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Performance Tuning Day - 8 Aug

Încărcat de

Drepturi de autor:

Formate disponibile

Performance Tuning Day - Pune

Introduction & Disclaimer

Agenda for the day

Performance & Scalability

Performance & Scalability

Performance Whos responsibility ?

At High Level(in the order of priority)

A Mantra for a Successful Development Project

Know your Development tool(1)

Know your Development tool(2)

Know your Development tool(3)

10053 CBO Trace Reveals problem with Bind Peeking

ArchitectureJust Enough Diagram

Redo & Undo

Update stocks set

Update stocks set

Update stocks set

Update stocks set

Readers do not block other Readers / Writers

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

update dept set deptno=:b1,

Tools that UPDATE every column

Row Level Lock(Implications)

update emp set empno=:b1,

update emp set empno=:b1,

Row Level Lock(Implications)

The Shared Pool

Sharing SQLs is key to effective Shared Pool Utilization

Parsing Soft v/s Hard

Store child Cursor in

Coding Standard(Multiple Parent Cursors)

A Parent requires at least one Child Cursor

Coding Standard(Multiple Child Cursors)

(select * from emp

Obvious but a problem

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

Coding Standard(Multiple Child Cursors)

Cursor Concepts.(Bind Graduation)

(Real Life Example)

Std Block Size:

(Real Life Example)

Top 5 Timed Events

Instance Activity Stats

Fix High Hard Parse Failures = Unwanted Work

Sharing of Cursors Key to Scalability

SGA the Buffer Cache

CBC Latch Issue(A Real Life Example)

CBC Latch Issue(A Real Life Example)

CBC Latch Issue(A Real Life Example)

CBC Latch Issue(A Real Life Example)

HLADDR Hash Latch Address

TCH Touch Count

Buffer Cache Structure(Representation)

# Chains dictated by _db_block_hash_buckets & Size of the Cache

CBC Latch Issue(A Real Life Example)

Who is the Culprit ?

CBC Latch Issue(A Real Life Example)

Who is the Culprit ?

CBC Latch Issue(A Real Life Example)

Scalar Subqueries, DETERMINISTIC, RESULT_CACHE

Oracle Waitsto name a few

Single Block Reads

db file scattered read