This week I found a new (for me :-)) way to investigate Oracle problems.
We had a problem at a customer site with a new application. A query suddenly failed with very nasty error "not connected to Oracle". Same query runs smoothly at our office but we developed on 10.2 while this customer was still on 9.2.0.6
(by the way, not a very wise choice I suppose).
Anyway I had only little time to fix, the problem was blocking the first demo of this very important (for us) new app with the customer.
Firstly I gave a look in the core log. Initially I was a little hopeless because informations in there seemed a little confusing but looking at the stack trace
I had my idea of the week: looking at the following line:
------------------- Call Stack Trace ---------------------
Frameptr RetAddr Param#1 Param#2 Param#3 Param#4 Function Name
0x0a56b888 011c2fee 0a56b948 00000001 09849b10 050f7208 _qeruaRowProcedure+1
I guessed that a function called "qeruaRowProcedure" should have failed.
So I tried a search on Metalink by keyword qeruaRowProcedure and (voilĂ ) I found
quite some documents regarding problems with this function.
In one of them I found the workaround I was looking for, which was
setting the hidden parameter _complex_view_merging to false.
I immediately tried this workaround and it worked! The query started running again
and the new app demo was able to complete.
One thing to keep in mind: the first documents I read in my Metalink search were hopeless in the sense they stated that there was no workaround for the problem (unless upgrading go 11 which was impossibile for me at the moment: I had to fix the problem almost instantly....) but at last I found at least one doc with the above workaround. So the advice is: keep searching..
A couple of days after we had a similar accident, but this time at our office, with a developing instance of 10.2.0.4.
I applied the same technique: look in the stack trace in the core log, identify the failing function and search metalink.
This time the stack trace line was this:
Frameptr RetAddr Param#1 Param#2 Param#3 Param#4 Function Name
0x0cad7ad8 00eace2d 8152d9d8 09abd544 0e8f8b08 00000000 _delrefi+34
And the workaround was in this document:
ORA-7445 [Delrefi] Where Delete Occurs
Doc ID: Note:463899.1
In this doc there are actually a couple of workarounds:
#1 Set "_optimizer_join_elimination_enabled"=false .
or
#2 Apply the one off patch for this bug.
Since the note was about 10.2.0.3 and the db I was using was 10.2.0.4
I choose to follow #1.
Note that it seems you can't simply use:
alter session set "_optimizer_join_elimination_enabled"=false
because sqlplus gives error ("identifier is too long").
It seems to work as "alter system" only.
At the end I must say: thanks Metalink!
Sunday, June 8, 2008
Subscribe to:
Post Comments (Atom)
2 comments:
Thanks ! Your advice about "_optimizer_join_elimination_enabled"=false" saved my life !
Post a Comment