FAQ
If you set the errorstack level to 3 then support should at least be able to give you the "cause" of the error as it will give the process state and stack of the process at the time of the error. If they didn't find this helpful it is likely that they are pursuing the application of the bug I spoke of previously. If this doesn't solve your problem these trace files will be essential in identifying the cause.

Good Luck!

Mike
Thanks for the input, Michael.

You are correct in your error number assumption. It is
the 2064 error.

We did set the 2064 event in a logon trigger and last
week and got a trace, not much help there either. I
tried to get the analyst to choose between oradebug
and dbms_system.set_ev so that I could set it
independently of the session, but we finally just put
a good old alter session in our load script.

We ran a 10053 trace since the problem seems that it
might be some sort of parse error on the source side.

We wanted the 10046 trace to see exactly where the
error was occuring since it is in a stored procedure
and what it was waiting on.

In working the theory that it might be
object/stats/parse related I rebuilt the tables and
recreated the indexes, no effect.

The strange thing is that this error just started
showing up two weeks ago, in two stored procedures
(both doing the same thing, different tables) having
the exact same frequency, scope, and duration of
error. There must be a connection, but unfortunately
this is a very hot problem for us and I don't have the
window to figure it out. It is too bad, it is a very
good puzzle. Almost hate to solve it with an upgrade.

The main reason that I am upgrading is that Oracle
support has tentatively identified a possible bug
(although it is internal, so no details) that will be
fixed by 8.1.7.4. Their position is that unless I
upgrade they won't pursue this further. So, upgrading
I am, even though I do not feel that they have really
nailed the problem, but they won't give further
support. Reasonable on their part, since they might
find that we have a bug that is already solved.


jack



--- Michael P Sale wrote:
Ahh yes, the elusive "Why". If you are already
working with support then
I would set an errorstack on the ora-2064 error
number you are getting(I
suspect that is what it is, you never say). This
will give them
extensive information as to the state of the call at
the time of the
error.

If you are running a high enough version of the db
this statement will
work:
alter system set events '2064 trace name errorstack
level 3';

Otherwise you can set it in the init.ora:
event = "2064 trace name errorstack level 3"
Where 2064 is the error number you are getting.

You can also set it at the session level with the
"alter session syntax"
and on another session with oradebug. This is
obviously the much more
painful route.

The 10053 would only be relevant if you were running
into a CBO issue,
not likely unless you are running with certain
events and/or underscore
parameters in place, and the 10046 should show the
sql being run (if
taken at the proper level) but not why the error
message, only that this
particular sql was run and resulted in this error.

An upgrade to address this problem directly might
not solve it
**UNLESS** you are running into bug 2140287 "CREATE
TABLE AS SELECT WITH
DECODE CORRUPTING DATA" (see the 8.1.7.4 patchset
readme or metalink
note 120613.1). In which case you could possibly
have serious issues
that would require you move to this patchset!!!

Either way, the errorstack will give you the "why"
even though only
Oracle support or development would likely be able
to interpret this for
you.


Regards,

Michael Sale
Author: Oracle9i for Windows(R) 2000 Tips &
Techniques
http://www.amazon.com/exec/obidos/ASIN/0072194626


-----Original Message-----
Silvey
Sent: Friday, June 21, 2002 2:28 PM
To: Multiple recipients of list ORACLE-L


Oracle support is saying much the same thing. They
are
advising an upgrade to 8.1.7.4 (from 8.1.7.2).
Doesn't
give us the reason WHY it is happening, but it might
fix it. We have run 10053 and 10046 traces and can
see
no obvious issues.




--- Michael P Sale wrote:
Without seeing more information, I have seen this
type of a response
where either the instance is not registered with
the listener, or the
db is not accepting connections for a variety of
reasons (e.g. no more
memory all the way to the db is shut down).

Regards,

Michael Sale
Author: Oracle9i for Windows(R) 2000 Tips &
Techniques
http://www.amazon.com/exec/obidos/ASIN/0072194626


-----Original Message-----
Silvey
Sent: Friday, June 21, 2002 12:08 PM
To: Multiple recipients of list ORACLE-L


Listers,

We have two stored procedures that are suddenly
throwing random "distributed operation not
supported"
errors.

These pieces of code are doing an "insert into as
select" across a database link. The data is being
pushed, not pulled. They have been running for
months
in production without a problem. Suddenly, they
start
throwing these errors, but will often succeed on the
retry.

Anyone have a similiar problem?

thx,

jack
--
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
--
Author: Michael P Sale
INET: Michael.Sale_at_oracle.com

Fat City Network Services -- (858) 538-5051 FAX:
(858) 538-5051
San Diego, California -- Public Internet
access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an
E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of
'ListGuru') and in
the message BODY, include a line containing: UNSUB
ORACLE-L
(or the name of mailing list you want to be removed
from). You may
also send the HELP command for other information
(like subscribing).

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jack Silvey
INET: jack_silvey_at_yahoo.com

Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing
Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L (or the
name of mailing list you want to be removed from). You may also
send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: MICHAEL.SALE
INET: MICHAEL.SALE_at_oracle.com

Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedJun 24, '02 at 1:08a
activeJun 24, '02 at 1:08a
posts1
users1
websiteoracle.com

1 user in discussion

MICHAEL.SALE: 1 post

People

Translate

site design / logo © 2022 Grokbase