Re: Errors in Trace and Alert Files Concerning Disappearing Processes

On Jan 23, 5:39 pm, "Dereck L. Dietz" <diet..._at_ameritech.net> wrote:
> "joel garry" <joel-ga..._at_home.com> wrote in message
>
> news:6568d695-4e7f-4642-8a4f-df0d1bd3b9d1_at_i29g2000prf.googlegroups.com...
> On Jan 23, 3:55 pm, "Dereck L. Dietz" <diet..._at_ameritech.net> wrote:
>
>
>
>
>
> > Oracle 10.2.0.3.0,
> > Windows 2003 Server
> > 8GB Memory
> > 8 CPU
> > Shared Server
>
> > I finally received the trace and alert files from the off-site DBA and
> > went
> > through them to try to figure out the root cause of the processes we've
> > had
> > at my workplace that just disappear.
>
> > Here are two segments. Could someone possibly direct me to more details
> > that I can present to my management and the off-site DBA for possible
> > correction?
>
> > --- trace file: tiermed_s002_1864.trc ---
>
> > *** 2008-01-19 07:28:06.562
> > *** ACTION NAME:(Elapsed - 4921.63 sec) 2008-01-19 07:28:06.359
> > *** MODULE NAME:(PROCESS_CLAIMS: Rows - 24,450,000) 2008-01-19
> > 07:28:06.359
> > *** SERVICE NAME:(SYS$USERS) 2008-01-19 07:28:06.359
> > *** SESSION ID:(35.9234) 2008-01-19 07:28:06.359
> > *********START PLSQL RUNTIME DUMP************
> > ***Got internal error Exception caught in pfrrun() while running PLSQL***
> > ***Got ORA-3135 while running PLSQL***
> > PACKAGE BODY SNDBX.HMP_LOAD:
> > library unit=b02d7608 line=4640 opcode=164 static link=12011f68 scope=1
> > FP=1200e028 PC=9b64ca84 Page=23 AP=12011f68 ST=1200e568
> > DL0=11fde048 GF=11fde3e8 DL1=11fde208 DPF=11fde3d0 DS=9b649c90
>
> > --- alert log ---
>
> > Wed Jan 02 17:16:13 2008
> > Errors in file d:\oracle\admin\tiermed\bdump\tiermed_s002_1864.trc:
> > ORA-07445: exception encountered: core dump [ACCESS_VIOLATION]
> > [unable_to_trans_pc] [PC:0x0] [ADDR:0x0] [UNABLE_TO_WRITE] []
> > Wed Jan 02 17:16:58 2008
> > found dead shared server 'S002', pid = (110, 1)
>
> See metalink Note:211909.1 and open an SR.  Also search on
> unable_to_trans_pc.
>
> jg
> --
> @home.com is bogus.
> "Any ship can be a minesweeper. Once." - Unknown
>
> Is this scenario possible?
>
> An SGA which is sized too large, causing excessing virtual memory paging on
> a host operating system where the available free disk space is critically
> low which in turn could cause "memory" errors if there isn't enough free
> disk space for the virtual memory?

I don't know about windows, but on unix and VMS those kind of things usually mean dead computer, one way or another. I'm not too familiar with how windows does things without doing research, but just as a user it seems to be a bit aggressive about putting things out to disk that haven't been used, whenever I sqlplus XE it takes forever to wake up.

Excessive paging by itself can look like hanging. That's why you see advice laying about that says things like don't make your SGA so large that swapping starts. But you might not see it too often, since it is often a gross configuration mistake to get there. It could also come from memory leaks and configuring too close to the edge of swapping. So how big is your SGA and are you swapping?

In your case, you need to pursue the 7445 to its root cause. Like Charles did in the querying V$ACCESS thread. There are views specific to shared server you might be checking, in case that last alert log message is related. Maybe the real problem is dying shared servers not releasing memory or something. You don't want to use shared servers with long running processes, they block shorter running processes. It's been a while since I've looked, but I'm pretty sure that's explained in the docs.

jg

--
@home.com is bogus.
Commuting by Amtrak now.  Hour late after getting soaked in the rain
Wednesday night walking from the parking lot, two hours late this
morning because the engine blew an oil line next to the nuke plant,
had to wait for next train to give it a push.