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

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
Received on Tue Aug 17 1999 - 12:06:27 CDT