Re: Oracle problems.

If this database is vital for your enterprise, I would strongly recommend an upgrade, as Oracle 7.1.5 is no longer supported. You may find patches if it's a known problem, but other than that you'll be pretty much left to yourself.

For information (and comparison) I`ve been running Oracle 7.3.4 on VMS 7.2-1 and never had this kind of problems. I have since upgraded Oracle to 8.0.5.1 then 8.1.6.0 and all versions were stable enough (save for one or two thing not related to your current issue).

By the way you put this you seem not to be very familiar with Oracle ("As far as I am aware it is using Oracle 7.1.5 "). Have a look at your alert log. It may contain some information pertaining to the error. Also check for trace files. These should be located in: Trace files = ORA_ROOT:[DB_sid.TRACE]*.TRC (possibly many files; none if no errors occurred)
Alert log = ORA_ROOT:[DB_sid.TRACE]*ALERT*.LOG (always 1 file)

sid is you database name.

HTH

--

Syltrem
http://pages.infinit.net/syltrem (OpenVMS related web site - en français)
To reply to myself directly, remove .spammenot from my address

"David J. Dachtera" <djesys.nospam_at_fsi.net> a écrit dans le message news:
3C0C5050.9C4F1828_at_fsi.net...


> Hoff Hoffman wrote:

> >

> > In article <9uh0g8$7kk$1_at_newsg1.svr.pol.co.uk>, "Leigh G. Bowden"


<LGBowden_at_bowdenfamily.fsnet.co.uk> writes:


> > :We have an AlphaServer 2100 4/200 with two CPU's and 1GB of memory and

> > :plenty of disks - all shadowed.

> >

> >   That's a comparitively old and slow EV4-class Alpha platform, and one


> >   gigabbyte of main memory is comparatively small by current

configuration


> >   standards.


> >

> > :As far as I am aware it is using Oracle 7.1.5 on OpenVMS 6.2 AXP.

> >

> >   You will want to confirm this, since this version information will

> >   be central to most of the subsequent research that is required here.

> >   Your version of OpenVMS Alpha lacks various of the enhancements around

> >   sixty-four bit addressing that were added for V7.0, and thus has the

> >   VAX limitations around stuffing most everything of consequence into

> >   the S0 and S1 space (2TB) address range -- this probably likely will

> >   not help with the apparent leak reported here, but I've encountered

> >   numerous Alpha (pre-V7) systems with the resulting addressing limits.

> >

> > :It appears to be unreliable. After about three weeks this system will

lock


> > :up and the console will report "Insufficient memory for operation" type


> > :errors

> >

> >   You will want to get the specific error message, not the type of

> >   message.  (No offense is intended.)  There are many similar error

> >   messages, and the specific and full error message text is invaluable

> >   evidence when determining the details of the particular problem.

> >   Abbreviations or any other alterations to the reported text should

> >   be carefully avoided, given the likelyhood these changes will serve

> >   only to introduce ambigiuity.

> >

> > :...and will allow nobody to logon even at the console. The only way to

> > :get out of this to power cycle it.

> >

> >   This initially appears to be a memory leak, either in OpenVMS or in

> >   the database software.  You will want to apply the mandatory ECO kits

> >   for OpenVMS Alpha, and you will want to check with Oracle (classic,

> >   I assume, since that is not an Rdb version) for any database patches,

> >   and you will want to configure a sufficiently large system crashdump

> >   file and learn how to force an OpenVMS system crash from the system

> >   console.

>


> Sounds familiar! Like Hoff said, check for patches - VMS *AND* Oracle!


> If memory serves (and it frequently doesn't), this may be a known

> problem with a fix available.

>


> --

> David J. Dachtera

> dba DJE Systems


> http://www.djesys.com/


>


> Unofficial Affordable OpenVMS Home Page:


> http://www.djesys.com/vms/soho/