Start DEM14 VM, TMUX panes, run F10
Transcript of Start DEM14 VM, TMUX panes, run F10
Start DEM14 VM, TMUX panes, run F10
1
2
3
4
_column_tracking_level=1 (basic) ,2,3 (col group)sys.col_usage$
5
6
7
This is stored in SYSAUXFinding ID is
Hashed from OBJECT# and COLUMN# of related objectsDirective ID generated
8
DEMO new -> hash_stats
9
10
NEW: misestimate has net been determinedif stats then 1) use stats and 2) set HAS_STATSelse 1) dynamic sampling and 2) MISSING_STATS
HAS_STATS use statistics. If misestimate then PERMANENTPERMANENT ignores stats (until drop)
11
Invalidated -> HAS_STATS
12
13
14
No order
15
Displayed in alphabetical order
16
17
18
Internal tables has + 6.5 days for last used. Corrected on view
19
20
Hello Franck
We have reviewed the issue. This is not a defect:This update is not done at every SPD usage because it would be prohibitively expensive, requiring recursive DMLs. Instead, the timestamp is updated on disk when it is more than 6.5 days old. When directive is created, we save in it the current timestamp plus 6.5 days (i.e., a time in the future).Each time the SPD is used, we compare this saved time with the current timestamp. When the current timestamp is greater than initial plus 6.5 days, we know that it is time to update the last_used attribute of the SPD on disk.
Sane mechanism exists for LAST_EXECUTED column in DBA_SQL_PLAN_BASELINESA bug was opened for this and was closed as 'Not a bug',Bug 8864741 : LAST_EXECUTED DATE IN DBA_SQL_PLAN_BASELINE IS NOT GETTING UPDATED
Default retention is 53 weeks (SPD_RETENTION_WEEKS), which means a directive is purged if it has been left unused for little over a year, so mechanism in place will not cause SPD to be purged.
Regards,AndreiGlobal Customer Services
21
22
23
Note: if you drop extended stats, then HAS_STATS becomes PERMANENT.
24
SPD: Inserted felem, fid=1466386022896422988, ftype = 1, freason = 1, dtype = 1, dstate = 5, dflag = 1, ver = NO, keep = NO
25
BDE=http://www.oracle.com/us/corporate/acquisitions/hyperion/bugstatusdescription-072226.pdf
26
27
https://bdrouvot.wordpress.com/2014/10/17/watch-out-for-optimizer_adaptive_features-as-it-may-have-a-huge-negative-impact/
28
Queries on DBA_SQL_PLAN_DIR_OBJECTS are long
29
30
DEMO permanent+explain plan + disableDISABLEs the usage (dynamic sampling) but not the creation of extendedstats.Don’t drop them or they will reappear"_optimizer_ads_use_result_cache"=false;
31
SPD are not used in RULE
32
Only (NEW and HAS_STATS) will be purgedMISSING_STATS and PERMANENT will trigger dynamic sampling
33
Only (NEW and HAS_STATS) will be purgedMISSING_STATS and PERMANENT will trigger dynamic sampling
34
35
http://scn.sap.com/community/oracle/blog/2015/06/01/oracle-db-optimizer-part-xii--revealing-sql-plan-directive-details-for-existingloaded-cursor-from-cbo-and-sql-dynamic-sampling-services-tracePosted by Stefan Koehler in SAP on Oracle on Jun 1, 2015 11:33:52 AM
36
37
Return code in qosdSetupDirCtx4QB:
• NOCTX: no valid SQL Plan Directive• EXISTS: found valid SQL Plan Directive
38
qosdDSDirSetup: • NOCTX: no valid SQL Plan Directive, • EXISTS: SQL Plan Directive is USABLE, • NODIR: SQL Plan Directive is SUPERSEEDEDqosdRecDSDirChange
• EXISTS: state doesn’t change• UPDATED: state changedState:1:New, 2:Missing stats, 3:Has stats, 5:PermanentObject:E:Equality, C:Simple column, J:Index access by join, F:Filter on join
39
State:1:New, 2:Missing stats, 3:Has stats, 5:PermanentObject:E:Equality, C:Simple column, J:Index access by join, F:Filter on join
40
Return code in qosdSetupDirCtx4QB: • NOCTX: no valid SQL Plan Directive• EXISTS: found valid SQL Plan Directive
41
qosdDSDirSetup: • NOCTX: no valid SQL Plan Directive, • EXISTS: SQL Plan Directive is USABLE, • NODIR: SQL Plan Directive is SUPERSEEDEDqosdRecDSDirChange
• EXISTS: state doesn’t change• UPDATED: state changedState:1:New, 2:Missing stats, 3:Has stats, 5:PermanentObject:E:Equality, C:Simple column, J:Index access by join, F:Filter on join
42
qosdDSDirSetup: • NOCTX: no valid SQL Plan Directive, • EXISTS: SQL Plan Directive is USABLE, • NODIR: SQL Plan Directive is SUPERSEEDEDqosdRecDSDirChange
• EXISTS: state doesn’t change• UPDATED: state changedState:1:New, 2:Missing stats, 3:Has stats, 5:PermanentObject:E:Equality, C:Simple column, J:Index access by join, F:Filter on join
43
qosdDSDirSetup: • NOCTX: no valid SQL Plan Directive, • EXISTS: SQL Plan Directive is USABLE, • NODIR: SQL Plan Directive is SUPERSEEDEDqosdRecDSDirChange
• EXISTS: state doesn’t change• UPDATED: state changedState:1:New, 2:Missing stats, 3:Has stats, 5:PermanentObject:E:Equality, C:Simple column, J:Index access by join, F:Filter on join
44
qosdDSDirSetup: • NOCTX: no valid SQL Plan Directive, • EXISTS: SQL Plan Directive is USABLE, • NODIR: SQL Plan Directive is SUPERSEEDEDqosdRecDSDirChange
• EXISTS: state doesn’t change• UPDATED: state changedState:1:New, 2:Missing stats, 3:Has stats, 5:PermanentObject:E:Equality, C:Simple column, J:Index access by join, F:Filter on join
45
qosdDSDirSetup: • NOCTX: no valid SQL Plan Directive, • EXISTS: SQL Plan Directive is USABLE, • NODIR: SQL Plan Directive is SUPERSEEDEDqosdRecDSDirChange
• EXISTS: state doesn’t change• UPDATED: state changedState:1:New, 2:Missing stats, 3:Has stats, 5:PermanentObject:E:Equality, C:Simple column, J:Index access by join, F:Filter on join
46
qosdDSDirSetup: • NOCTX: no valid SQL Plan Directive, • EXISTS: SQL Plan Directive is USABLE, • NODIR: SQL Plan Directive is SUPERSEEDEDqosdRecDSDirChange
• EXISTS: state doesn’t change• UPDATED: state changedState:1:New, 2:Missing stats, 3:Has stats, 5:PermanentObject:E:Equality, C:Simple column, J:Index access by join, F:Filter on join
47
48
PERMANENT -> drop Extended Stats?HAS_STAT -> create Extended Stats from release?Is PERMANENT good? Is HAS_STATS good?
49
50