Two points – I have no idea what “a list of failing instructions” means (is it a set of SQL statements that raise errors), and I don’t have total recall of all the Oracle error messages – so you might consider including the error text when quoting the error number.

In your position I would set event 10046 at level 4 (bind variable capture) when running the code that fails, and then read the trace file. I would hope to see the actual failing statement (with the error code reported) and capture the current values of the bind variables that caused the error.

I caught this discussion following an issue I met with Oracle SPA. I’m testing ugrade from 10.2.0.4 to 11.2.0.3.

The second trial on 11g triggered a list of failing instructions. All of them using sys_op_lbid and getting an ORA-01760. The only note (ID 317254.1) I found on Metalink didn’t help.Sorry if I’m out-of-scope of the discussion but more than interested in any clue you may have.

Thank you,
Guillaume

No, not that I know of.
You just have to kill the query and restart it after dealing with the cause of the problem.

Is there a to change the plan of the running sql? (it is running for 8 hours, still it has long way to go). It picked up wrong plan due to wrong statistics. Is there a way to force the running sql to take new plan that we have identified.

Thank you
Suresh

There are various diffrences between analyze and dbms_stats – not the least of which is what they collect stats on by default. In 10g the default is for dbms_stats to collect histograms which analyze does not do, and that particular difference has affected a lot of people badly in the past.

In your case there’s also the possible difference due to an estimate being taken by dbms_stats, compared to your compute from analyze.

If you check the different behaviour between the two commands by testing on a small test schema you may be able to identify the specific detail thats been giving you problems.

Regards,
Shadi

I think you’re probably thinking of Chapter 5 of Cost Based Oracle – Fundamentals (the chapter that can be downloaded as a free pdf file from Apress) where I suggest that we could “hi-jack” the sys_op_countchg() function used by Oracle to calculate the clustering_factor of an index.

You’re probably correct to suggest that I could have made some comments about the function being undocumented and that my suggestion to trace the gather_index_stats() call should be repeated on every upgrade of Oracle to ensure that the mechanism was still appropriate.

In fact, as Richard Foote points out in one of the comments to his postings on Oracle Open World 2009, this may be particularly significant in some future (12+) version of Oracle because the Optimizer Group is looking at better ways of calculating the clustering_factor (and may, apparently, do something that looks remarkably similar to the suggestion I voiced in the book).

A quick search on MetaLink shows precious little (practically nothing) about sys_op_countchg() – so, is it wise to promote its usage? Is it something that looks good, but could go nasty in a next release/patchset?