[Date Prev][Date Next][Thread Prev][Thread Next]
[Author Index] [Date Index] [Thread Index]
[SQR-USERS Info] [SQRUG Home Page]

RE: [sqr-users] ORA-01013 and SQR 3725 errors


There was something a few years ago about a memory leak in unix based oracle 
systems.
A memory leak is where the memory is not managed correctly and some data in 
memory are overwritten in an unpredictable and downright discouraging way.

Richard Knapp
Database Programmer/Analyst
Institutional Research and Planning
University of Missouri System
573-882-8856
knappr@umsystem.edu


-----Original Message-----
From: Christine Sessler [mailto:cms41@cornell.edu]
Sent: Thursday, December 12, 2002 1:09 PM
To: sqr-users@sqrug.org
Subject: RE: [sqr-users] ORA-01013 and SQR 3725 errors


All -

Yet another update in the 1013 saga:

We've been trying every suggestion that has been posted and my DBA has also 
been discussing this problem with Oracle people.  Oracle has asked for 
certain traces and we've been able to include the following in the SETUP 
section of the SQR for them:

begin-sql
set transaction use rollback segment rbsbig;
alter session set events '1013 trace name errorstack forever, level 3';
end-sql

'Lo and behold, if this combination is turned on, the program runs 
successfully for the entire population.  Comment the "alter" statement out, 
we crash and burn.  My DBA has suggested something about a "data leak" (ie, 
moving a value into a field not large enough) but that just doesn't make 
sense to me as we define variables on the fly and if a temp table value 
wasn't large enough, I'd get an error that made sense.

Does anyone have any thoughts on why this combination *may* work?

Chris


At 12:01 AM 12/11/2002 -0500, you wrote:
>Strange thing happened to me the other day.  I was running a new SQR and
>started getting this error.  I spoke with my DBA today and mentioned it.
>Seems as though we get this occasionally.
>
>Last time this happened, he investigated.  The database logs showed
>contention with the rollback segments.  This is why it only happened
>periodically.  This is also why it rarely happened when anything else
>was going on with the system.  This also explains why our production
>system has never seen this error (our production system has quite a bit
>more rollback space than test or development).
>
>I hope this gives a bit of experienced insight.
>
>---John Berlo
>Lend Lease REI
>john.berlo@lendleaserei.com
>
>
>-----Original Message-----
>From: sqr-users-admin@sqrug.org [mailto:sqr-users-admin@sqrug.org] On
>Behalf Of Christine Sessler
>Sent: Wednesday, December 04, 2002 5:31 PM
>To: sqr-users@sqrug.org
>Subject: RE: [sqr-users] ORA-01013 and SQR 3725 errors
>
>Oh heck, it cracked me and my DBA up so in it went.  Why not share the
>humor as well as the pain?
>
>We had 4 successful runs, let everyone back in and Poof! Crash and burn.
>
>Doing some searching on PS's Customer Connection site, revealed others
>receiving the mysterious ORA-01013 error - so my DBA is off checking out
>
>Rules vs Cost Based indices to see if that makes any difference.
>
>I just commented out every single call in the PS delivered section of
>the
>program and gee, it ran.  Imagine that.  Anyway, we're still plugging
>away
>at it and I'm glad that someone appreciated my warped sense of humor!
>
>
>At 04:23 PM 12/4/2002 -0600, you wrote:
>
> >I know this is probably not funny to you but the bit about 'only seems
>to
> >run successfully on Wednesdays' was a laugh out loud chuckler for me
>and I
> >needed one.  Hope you get yours.
> >
> >Richard Knapp
> >Database Programmer/Analyst
> >Institutional Research and Planning
> >University of Missouri System
> >573-882-8856
> >knappr@umsystem.edu
> >
> >
> >-----Original Message-----
> >From: Christine Sessler [mailto:cms41@cornell.edu]
> >Sent: Wednesday, December 04, 2002 12:48 PM
> >To: sqr-users@sqrug.org
> >Cc: sn94@cornell.edu
> >Subject: Re: [sqr-users] ORA-01013 and SQR 3725 errors
> >
> >
> >All -
> >
> >Thank you for all of the suggestions.  My friendly DBA and I have spent
>the
> >majority of the last 2 days banging our heads together and trying
>different
> >things.  We were able to finally get 4 (count them 4!) successful runs
>of
> >the program this afternoon AFTER doing the following:
> >
> >* Changed the order by of a procedure that builds a pay calendar array
>- in
> >essence, to run the smallest paygroup first
> >* Increased the pay calendar array size from 100 to 1000
> >* Added On-Error statements to a few PS delivered SELECTS to get better
>(?)
> >error statements
> >* Changed a PS delivered SELECT to NOT use LOOPS=1 and modified the
>Order By
> >* Added an Alter Session SQL to set the date format (although our setup
> >sets this up somewhere)
> >* Upped the Processing Limits in the PSSQR.INI file
> >
> >After we made these changes, it ran once and then the next timed, died
>again.
> >
> >We brought our development instance down and my job was the only one
> >running in there when we had our 4 successful runs.
> >
> >Oh, might I also mention that it seems to also only want to run
> >successfully on Wednesdays.
> >
> >I'll see what tomorrow brings.
> >
> >Thanks again and if there are any more suggestions, I'd love to hear
>them.
> >Chris
> >
> >
> >At 09:25 AM 12/4/2002 -0500, you wrote:
> > >Hi,
> > >
> > >I have also seen the error "Bad return fetching row from database."
> > occur when
> > >there is data contention (user was updating data while SQR was trying
>to
> > >access
> > >it).  If that is the problem, that would explain why it happens at
>different
> > >times within the program; it is due to something external, and not to
>an
> > error
> > >in the code.  This is really a kind of catch-all error, and it is
> > difficult to
> > >resolve. "Program stopped by user request." frequently does not seem
>to have
> > >anything to do with the user; I think it might be the Process
>Scheduler
> > >that it
> > >thinks is the user.
> > >
> > >Denise White
> > >Sr. Software Engineer
> > >Vicor
> > >
> > >--__--__--
> > >
> > >Message: 7
> > >Date: Tue, 3 Dec 2002 14:10:32 -0600
> > >From: "Knapp, Richard" <KnappR@umsystem.edu>
> > >To: <sqr-users@sqrug.org>
> > >Subject: [sqr-users]
> >
> >=?iso-8859-1?Q?RE=3A_=5Bsqr-users=5D_Re=3A_=5Bsqr-users=5D_RE=3A_=5Bsqr
>?=
> > >
>=?iso-8859-1?Q?-users=5D_R=E9f=2E_=3A_=5B_sqr-users=5D_ORA-0_1013_and?=
> > >  =?iso-8859-1?Q?_SQR_3725_errors?=
> > >Reply-To: sqr-users@sqrug.org
> > >
> > >
> > >Well, I'm thinking that, since the errors all refer to a user
>request,
> > >that this
> > >is where the request is coming from.  You'll have to trace the code
>to
> > see why
> > >that stop is issued.
> > >
> > >Richard Knapp
> > >Database Programmer/Analyst
> > >Institutional Research and Planning
> > >University of Missouri System
> > >573-882-8856
> > >knappr@umsystem.edu
> > >
> > >
> > >-----Original Message-----
> > >From: Christine Sessler [mailto:cms41@cornell.edu]
> > >Sent: Tuesday, December 03, 2002 1:56 PM
> > >To: sqr-users@sqrug.org
> > >Subject: [sqr-users] Re: [sqr-users] RE: [sqr-users] Rf. : [
>sqr-users]
> > >ORA-0 1013 and SQR 3725 errors
> > >
> > >
> > >Yes, as PS delivered, 'STOP' is in the program.
> > >
> > >
> > >At 01:45 PM 12/3/2002 -0600, you wrote:
> > >
> > > >Does the command 'STOP' appear anywhere in the text of the program?
> > > >
> > > >Richard Knapp
> > > >Database Programmer/Analyst
> > > >Institutional Research and Planning
> > > >University of Missouri System
> > > >573-882-8856
> > > >knappr@umsystem.edu
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Tha Le Tat [mailto:thai.le-tat@creditlyonnais.fr]
> > > >Sent: Tuesday, December 03, 2002 10:23 AM
> > > >To: sqr-users@sqrug.org
> > > >Subject: [sqr-users] Rf. : [sqr-users] ORA-01013 and SQR 3725
>errors
> > > >
> > > >
> > > >
> > > >
> > > >Timeouts (whether explicitly or implicitly specified or reported)
>are a
> > > >frequent cause of ORA-01013.
> > > >=> Check your Oracle timeout.
> > > >
> > > >Are you performing update in your database ?
> > > >Do you manage commit manually ?
> > > >
> > > >Regards
> > > >Thai LE TAT
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Christine Sessler <cms41@cornell.edu>@sqrug.org le 03/12/2002
>17:02:44
> > > >
> > > >Veuillez rpondre  sqr-users@sqrug.org
> > > >
> > > >Envoy par :      sqr-users-admin@sqrug.org
> > > >
> > > >
> > > >Pour : sqr-users@sqrug.org
> > > >cc :    (ccc : Tha Le Tat/DED/DSTI/CLY)
> > > >
> > > >Objet :     [sqr-users] ORA-01013 and SQR 3725 errors
> > > >
> > > >
> > > >All -
> > > >
> > > >I'm running into a problem that is causing me some grief.
> > > >
> > > >I receive the following error(s) when running a SQR.  The problem
>is
> > that I
> > > >can not pinpoint where in the SQR the program is failing.  It
>moves.  I've
> > > >had the SQR fail quickly with this error, I run it again and it
>runs
> > 3/4 of
> > > >the way through before failing.  I've also successfully run the SQR
>and
> > > >then run it again and it fails.  I feel like I'm looking for a
>needle in a
> > > >haystack.
> > > >
> > > >As a side note, this is a cloned and modified version of PS
>PAYGL02.
> > > >
> > > >Can anyone shed any light on where I might try to find out what is
>causing
> > > >this problem?
> > > >
> > > >I'm on:  Oracle, PeopleSoft 8.1.6
> > > >
> > > >
> > > >(SQR 5528) ORACLE OCIStmtFetch error 1013 in cursor 14:
> > > >     ORA-01013: user requested cancel of current operation
> > > >
> > > >Error on line 1644:   <-- various line numbers are returned
> > > >     (SQR 3725) Bad return fetching row from database.
> > > >
> > > >SQR for PeopleSoft: Program Aborting.
> > > >
> > > >Sometimes I get this:
> > > >SQL-STATEMENT-ERROR
> > > >PAYGL02, Select Error - TAX-LIABILITIES    <--- various procedures
>are
> > > >returned  and the bind variables below return valid data when
>running just
> > > >the SQL
> > > >Bind Variables: Company END, Paygroup EB1, Pay End_Date
>09-JAN-2002, Off
> > > >Cycle N, PAGE_NUM 9.000000, LINE_NUM 5.000000, Separate Check
> > 0.000000, Tax
> > > >Class is not W, and State is not Blank
> > > >   Error : ORA-01013: user requested cancel of current operation
> > > >   SQL Status : -1.000000
> > > >
> > > >Error on line 7233:
> > > >     (SQR 3301) Program stopped by user request.
> > > >
> > > >SQR for PeopleSoft: Program Aborting.
> > > >
> > > >
> > > >Thanks,
> > > >Chris
> > > >
> > >************************************************************
> > >Christine Sessler
> > >Cornell University
> > >CIT/Business Information Systems
> > >120 Maple Avenue
> > >Ithaca, NY  14850
> > >
> > >607.255.8149  - Office
> > >607.255.6982  - Fax
> > >cms41@cornell.edu
>
>_______________________________________________
>sqr-users mailing list
>sqr-users@sqrug.org
>http://www.sqrug.org/mailman/listinfo/sqr-users
>
>
>_______________________________________________
>sqr-users mailing list
>sqr-users@sqrug.org
>http://www.sqrug.org/mailman/listinfo/sqr-users

_______________________________________________
sqr-users mailing list
sqr-users@sqrug.org
http://www.sqrug.org/mailman/listinfo/sqr-users

_______________________________________________
sqr-users mailing list
sqr-users@sqrug.org
http://www.sqrug.org/mailman/listinfo/sqr-users