Intermittent '1013' errors, who can explain them?

From: Steve Fick <shf_at_world.std.com>
Date: Sat, 14 Aug 1999 21:02:29 GMT
Message-ID: <FGH3s5.4sI@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 - 16:02:29 CDT