Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Sumit.

Asked: September 21, 2016 - 11:01 am UTC

Last updated: September 22, 2016 - 7:48 pm UTC

Version: 11.2.0.4

Viewed 1000+ times

You Asked

Hi Tom,
A tricky question, recently we upgraded our systems to 11.2.0.4 and started to observe some queries taking much longer (from mins to 10+ hours).
On analysing the taces / explain we found the access path had changed from the previous one, so if initiated a full stats update, but to no benefit.

A copy of database was made prior to upgrade and we ran the same query there which worked as it had worked before.
Parameter comparison resulted no difference.

On analysing the 2 traces (optimiser) we found that the only difference on the 2 DB's on that tables / indexes for the particular index (BSAD~1) is different which forces the optimiser to select it over primary index is the value of RESC_IO (in bold).
The extract is place here (Production : bad perfomance, Non Prod - good performance)

The key question is
1. Can we influence the RESC_IO value
2. How is this resource cost built by Oracle in first place
3. What other steps can we take to influence this to force selection of BSAD~0 index (without using hints).
If required I can attache the full trace of both the systems.


Prod
DB1
Index: BSAD~0
resc_io: 7.000000 resc_cpu: 96689
ix_sel: 7.1054e-09 ix_sel_with_filters: 4.4767e-14
***** Logdef predicate Adjustment ******
Final IO cst 0.000000 , CPU cst 12300
***** End Logdef Adjustment ******
Cost: 1.401104 Resp: 1.401104 Degree: 1
ColGroup Usage:: PredCnt: 3 Matches Full: Partial: #7 (1 2 3 )
ColGroup Usage:: PredCnt: 3 Matches Full: Partial: #7 (1 2 3 )
Access Path: index (RangeScan)
Index: BSAD~1
resc_io: 7.000000 resc_cpu: 101437
ix_sel: 7.1054e-09 ix_sel_with_filters: 7.1054e-09
Cost: 1.400923 Resp: 1.400923 Degree: 1
Considering index with inlist as filter
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
ColGroup Usage:: PredCnt: 3 Matches Full: Partial: #7 (1 2 3 )
Access Path: index (RangeScan)
Index: BSAD~1
resc_io: 6.000000 resc_cpu: 88046
ix_sel: 8.5975e-07 ix_sel_with_filters: 7.1054e-09
***** Logdef predicate Adjustment ******
Final IO cst 0.000000 , CPU cst 0
***** End Logdef Adjustment ******

NonProd
Access Path: index (RangeScan)
Index: BSAD~0
resc_io: 7.000000 resc_cpu: 122089
ix_sel: 6.5239e-07 ix_sel_with_filters: 4.5333e-12
***** Logdef predicate Adjustment ******
Final IO cst 0.000000 , CPU cst 12300
***** End Logdef Adjustment ******
Cost: 7.069318 Resp: 7.069318 Degree: 1
ColGroup Usage:: PredCnt: 3 Matches Full: Partial: #5 (1 2 3 ) Sel: 6.5239e-07
ColGroup Usage:: PredCnt: 3 Matches Full: Partial: #5 (1 2 3 ) Sel: 6.5239e-07
Access Path: index (RangeScan)
Index: BSAD~1
resc_io: 59.000000 resc_cpu: 1052825
ix_sel: 6.5239e-07 ix_sel_with_filters: 6.5239e-07
Cost: 59.042709 Resp: 59.042709 Degree: 1
Considering index with inlist as filter
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
ColGroup Usage:: PredCnt: 3 Matches Full: Partial: #5 (1 2 3 ) Sel: 6.5239e-07
Access Path: index (RangeScan)
Index: BSAD~1
resc_io: 58.000000 resc_cpu: 936485
ix_sel: 9.3269e-07 ix_sel_with_filters: 6.5239e-07
***** Logdef predicate Adjustment ******
Final IO cst 0.000000 , CPU cst 0
***** End Logdef Adjustment ******

and Connor said...

RESC_IO is the I/O resource cost as derived by the optimizer. The *how* is obviously a large topic in its own right. A slightly dated but still excellent resource is Wolfgang's 10053 paper

http://www.centrexcc.com/A%20Look%20under%20the%20Hood%20of%20CBO%20-%20the%2010053%20Event.pdf

In terms of manipulating a plan, rather than manipulating statistics, I'd probably recommend you take a look at sql plan management, which is our general direction for handling plans

http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-sql-plan-management-11gr2-133099.pdf


Is this answer out of date? If it is, please let us know via a Comment

More to Explore

Security

All of the vital components for a secure database are covered in the Security guide.