Re: RE: distributed timeout error
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/0072194
RE: distributed timeout error
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 si
RE: distributed timeout error
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: distributed timeout error
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 __ 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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 P Sale INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
RE: distributed timeout error
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 <[EMAIL PROTECTED]> 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 > > __ > 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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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 P Sale > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
distributed timeout error
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 __ 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
