There have been some cases of connection error messages caused by not enough
memory. Do you have a lot?
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
Received on Sat Aug 14 1999 - 21:46:31 CDT
