Re: Intermittent '1013' errors, who can explain them?

We have had this problem occur once in a while during some nightly interface runs. The best explanation I was able to receive from Oracle Support was that it was because of SQL*NET timing out. We are trapping the error within the procedure and continuing with the process. It does not close the connection.

In article <FGMCur.38_at_world.std.com>,
  shf_at_world.std.com (Steve Fick) wrote:
> Van Messner <vmessner_at_netaxis.com> wrote on Sat, 14 Aug 1999:
>
> >There have been some cases of connection error messages caused by not
enough
> >memory. Do you have a lot?
> >
>
> The servers have 512MB of physmem each.
>
> The other non-Oracle processing on these systems --all of which stems
> from the layered publishing application atop the Oracle instances--
> rarely adds up to enough to cause even as much as 100MB of swap space
> to be used, according to 'top' 'swap -s' etc.
>
> Did you mean that pinning only a small amount of memory
> to the Oracle instances themselves might cause connection error
messages?
> The Oracle instances are using only about 10 to 16 MB each,
> so this might apply in our situation. The sizings were suggested
> by the publishing app VAR, up till now we've not tinkered with them.
> There are 5 of these instances running on the production server.
>
> >Steve Fick <shf_at_world.std.com> wrote in message
> >news:FGH3s5.4sI_at_world.std.com...
> >> Hello there,
> >>
> >> Intermittently at our site, users running a purchased
> >> publishing application that is layered on top of Oracle are
> >> experiencing session crashes accompanied by Oracle 12571
> >> and 1012 error messages in the user environment and 1013
> >> error messages in the trace log environment.
> >>
> >> MIS staff have been able to intermittently duplicate the
> >> user session crashes using a database on a development
> >> system, and a pertinent fragment from an Oracle trace log
> >> of such a session is shown below. (We stopped using Oracle
> >> trace on the production server after confirming we got the
> >> same '1013' error message in the Oracle trace logs there,
> >> as on the development server.)
> >>
> >> We have support contracts with both Oracle and the
> >> application vendor. Both have given some initial responses
> >> that do not resolve or even entirely explain the problem,
> >> so we are trying to dig deeper.
> >>
> >> In particular we wonder whether other sites have
> >> experienced the 1013 error even when the user did NOT touch
> >> the keyboard after submitting the update request, while
> >> working in a non-client-server environment. (Us: Solaris
> >> 2.5.1 server, Oracle 7.3.4, publishing application resides
> >> on same server, users login directly to same server and
> >> invoke the application there.) I've searched the last 2
> >> year's worth of Usenet Oracle newsgroup archives and all
> >> the references to 12571/1013 problems appear to have
> >> related to client-server scenarios. Thus, the fixes
> >> mentioned there (bug patches, eliminating timeouts for
> >> SQLplus) cannot be used here.
> >>
> >> Also, on first seeing the trace logs it seems odd that
> >> even after the 1013 error, Oracle continued to receive and process
> >> additional SQL statements submitted to it by this
> >> application. Isn't the 1013 intended to signify that the
> >> connection between the server processes and the application
> >> has been terminated? Should the application be able to
> >> 'hear' the 1013 from Oracle, and take appropriate action,
> >> rather than simply dying?
> >>
> >> We have not gotten this kind of error from our
> >> client-server-based Oracle applications, which include some
> >> large update statements and some very long running
> >> queries. We get this kind of error from the
> >> non-client-server publishing application in situations
> >> where the update statement takes longer than perhaps 20 or
> >> 30 seconds--but even then, only intermittently. The value
> >> being updated is a blob that usually contains a quarter to
> >> a half a megabyte or sometimes more of data.
> >>
> >>
> >> Following is a fragment from a typical Oracle trace log
> >> related to the user session crash:
> >>
> >> =====================
> >> PARSING IN CURSOR #33 len=76 dep=0 uid=22 oct=3 lid=22
> >> tim=0 hv=3854099742 ad='805acff0' select revcode
> >> ,backup_revcode into :b0,:b1 from domain where
> >> name='GLOBAL' END OF STMT PARSE
> >> #33:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0 EXEC
> >> #33:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0 FETCH
> >> #33:c=0,e=0,p=0,cr=1,cu=2,mis=0,r=1,dep=0,og=4,tim=0 EXEC
> >> #11:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=4,tim=0 FETCH
> >> #11:c=0,e=0,p=0,cr=3,cu=0,mis=0,r=1,dep=0,og=4,tim=0 XCTEND
> >> rlbk=0, rd_only=1
> >> =====================
> >> PARSING IN CURSOR
> >> #34 len=89 dep=0 uid=22 oct=6 lid=22 tim=0 hv=3600377017
> >> ad='805abf58' update textbuf set
> >> inclen=:b0,increv=:b1,inc=:b2,baselen=:b3,baserev=:b4 where
> >> recid=:b5 END OF STMT PARSE
> >> #34:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0 EXEC
> >> #34:c=0,e=0,p=1,cr=4,cu=9,mis=0,r=1,dep=0,og=4,tim=0
> >>
> >> =====================
> >> PARSING IN CURSOR #35 len=90 dep=0
> >> uid=22 oct=6 lid=22 tim=0 hv=2420169612 ad='805a9368'
> >> update basebuf set
> >> inclen=:b0,increv=:b1,baselen=:b2,baserev=:b3,base=:b4
> >> where recid=:b5 END OF STMT PARSE
> >> #35:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0 EXEC
> >> #35:c=0,e=0,p=601,cr=306,cu=1060,mis=0,r=0,dep=0,og=4,tim=0
> >>
> >> ERROR #35:err=1013 tim=0
> >>
> >> =====================
> >> PARSING IN CURSOR #36 len=139 dep=1
> >> uid=0 oct=3 lid=0 tim=0 hv=111919063 ad='805fa8e0' select
> >> name,online$,undofile#,undoblock#,blocksize,dflmaxext,dflinit,
> >> dflincr,dflextpct,dflminext,owner#,scnwrp,scnbas
> >> from ts$ where ts#=:1 END OF STMT PARSE
> >> #36:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0 EXEC
> >> #36:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=0 FETCH
> >> #36:c=0,e=0,p=2,cr=2,cu=0,mis=0,r=1,dep=1,og=4,tim=0 STAT
> >> #36 id=1 cnt=1 pid=0 pos=0 obj=15 op='TABLE ACCESS CLUSTER
> >> TS$ ' STAT #36 id=2 cnt=1 pid=1 pos=1 obj=6 op='INDEX
> >> UNIQUE SCAN '
> >> =====================
> >> PARSING IN CURSOR #36
> >> len=35 dep=0 uid=22 oct=7 lid=22 tim=0 hv=4102331310
> >> ad='805c9a74' delete from users where lockid=:b0 END OF
> >> STMT PARSE
> >> #36:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=0 EXEC
> >> #36:c=0,e=0,p=2,cr=1,cu=4,mis=0,r=1,dep=0,og=4,tim=0 XCTEND
> >> rlbk=0, rd_only=0 XCTEND rlbk=0, rd_only=1 STAT #3 id=1
> >> cnt=0 pid=0 pos=0 obj=0 op='SORT AGGREGATE '
> >>
> >> (...and so forth...)
> >>
> >>
> >> Thanks in advance for any light you can shed on this,
> >> Steve Fick
> >> Unix System Manager
> >> Facts and Comparisons / A Wolters Kluwer Company
> >> 111 West Port Plaza, Suite 300, St. Louis, MO 63146-3098
> >> sfick_at_drugfacts.com
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Tue Aug 17 1999 - 15:53:58 CDT