Re: Help! We're down with ORA-7332 on Digital Unix box

kyle hailey wrote:
>
> Try removing the .dat files in $ORACLE_HOME/otrace/admin as a quick
> solution. This should turn Oracle tracing off. Give a call to Oracle
> support and they can send you a bulliten on turning trace off. Another
> method is to set EPC_DISABLED=true in the enviroment to turn tracing
> off.
> If this doesn't work it is probably a question of not having the right
> kernel paramenters or having old shared memory segments hanging around
> taking up space.
>
> JPeter5558 wrote:
> >
> > Help! We’re running a DEC Alpha Server 4100 with Digital Unix v3.2. After a
> > reboot the database has failed to come up, with ORA-7332.
> >
> > We haven’t changed the OS or the database config and everything looks okay.
> > Perhaps something got zapped. As an experiment, I tried starting the db with
> > a minimally configured SGA, but no effect.
> >
> > Got any clues? The error diagnostics (below) suggest a problem with Unix
> > kernel shared memory parameters but we haven’t touched those. (We would know
> > if we had because it would require rebuilding the Unix kernel.)
> >
> > We believe the machine has been running for months without changes. A “clone”
> > machine is running fine.
> >
> > SRMGR> startup
> >
> > ORA-7332: smsmat: shmat error unable to attach sga
> > DEC OSF/1 (AXP) Error 12: Not enough space
> > Additional information : 2
> >
> > =========================
> > ORA-7332,00000 “smsmat: shmat error, unable to attach sga”
> >
> > //* Cause: Failed to attach shared memory segment, after having gotten it.
> >
> > //* Action: Check errno returned. Verify that SGA attach address is valid.
> > // Additional information indicates the SGA model attempted
> >
> > =========================
> >
> > We’re stuck. Any comments are appreciated. Please respond to **both** email
> > addresses below.
> >
> > Thanks,
> >
> > Jim Peterson
> > jpeter5558_at_aol.com
> > GHill_at_evalcomp.corr.ca.gov
>
> --
> Kyle Hailey
> Oracle Support France
>
> [ What's Oracle got to do with it? These opinion's don't neccessarily
> reflect my employer. ]

This might be a wild guess , but I believe I encountered the same problem before on another UNIX platform (though I'm not sure) ,
Just check your swap area for any large file ?

Or It is also possible that some one did reconfigured the Unix parameters , build it but didn't boot up the machine . Check the date of your old pamameter files.

Or You could try this .

07332, 00000, "smsnsg: unable to allocate redo buffers." // *Cause: Redo block size is too big, preventing each buffer from being
// allocated contiguously.
// *Action: Reconfigure the UNIX kernel to have bigger segments, or reduce
// the value of log_buffer parameter in init.ora.

I hope this helps !

Joseph

----0000-----0000----0000----

The opinions expressed above are of my own and doesn't necessarily reflect
the opinions of any of my client companies or my employer . Received on Wed Oct 22 1997 - 00:00:00 CDT