SUMMARY: Oracle/SQL/DU Error 13

From: <RORY_O'CONNOR_at_US.WFL.COM>
Date: Tue, 07 May 96 09:22:00 EDT

Has anyone seen this, and have a solution?

======================================================================
SQL*Plus: Release 3.2.3.0.0 - Production on Tue Apr 23 14:42:31 1996

Copyright (c) Oracle Corporation 1979, 1994. All rights reserved.

Enter password:
ERROR: ORA-01034: ORACLE not available
ORA-07320: smsget: shmat error when trying to attach sga.
DEC OSF/1 (AXP) Error: 13: Permission denied

======================================================================

Our Oracle support guru is out for a while, and is supposed to work on resolving
it when he gets back, but if there's anything I can do from the Unix side, it
would be good to know.

tia,
Rory O'Connor rory_o'connor_at_us.wfl.com


RESPONSES:
The first one, from Louis Bouchard, was what we specifically needed to
implement, but the others covered useful points.
Our thanks to all.
===========================================================================

FROM: bouchard_l_at_decusf.fr

Hello,

Check if the file $ORACLE_HOME/bin/oracle has its "suid" bit set. It
should look like :
$ ls -l $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle dba 12861216 Dec 12 15:50 oracle

It is needed to allow any user to run the Oracle program with the
appropriate permissions. It might not be that but that's one thing to look at.

...Louis
----------------------------------------------------------------------------
| Louis Bouchard J'aimes que ca cesse quand c'est fini. Quand
| Ingenieur Systeme ca recommence, ca me scie.
| bouchard_l_at_decusf.fr R. Ducharme
| Bouygues Telecom
| 39-26-66-73
----------------------------------------------------------------------------




FROM: Deya_at_Pyramids.apana.org.au

Looks like a permission problem , you have to also set the super userid bit ,
this is in bin dir, under $ORACLE_HOME
Hope this helps

Deya
-------------------------------------------------------------------------
Deya Motawie Tel(O): (015) 414130
School Of Computing Science. Fax : (02) 5645341
UTS - Msc Researcher AI Lab. Email : Dhmotawi_at_Socs.uts.edu.au
University Of Technology, Sydney P.O. Box 123, Broadway NSW 2007
APANA System Administrator
(02 ) 692-0151 (Vox) Email : Deya_at_Pyramids.apana.org.au
-------------------------------------------------------------------------

From: Armando.Dias_at_pscmail.ps.net

We also had this problem for users logging in as users (oracle users group).

In our case it was a UNIX security issue with some oracle files:

. all executables in the $ORACLE_HOME/bin should be writeable by the oracle
software owner. Set modes 751 or 755 for these files with the exception of
executables such as sqldba, svrmgr*, dbstart, dbshut which should be set 750.
make sure all users have access to script dbhome.

. the oracle executable itself should have permissions set to mode 6771.

. orasrv (for sqlnet v1) and/or tnslsnr (for sqlnet v2) should be owned by root
and set to mode 4751.


. make sure your oracle environment variables are set right such as
ORACLE_SID.

Hope it helps.

Armando.

===========================================================================

FROM: bathurst_at_blegga.freerange.com

Check the following:

1) Do you have the environment variables ORACLE_HOME and ORACLE_SID set
before you run sqlplus.

2) Check the Oracle documentation to check to see if you have all your
kernel parameters set correctly. These are set in /sys/conf/HOSTNAME.

3) Call Oracle support. If you don't have it I recommend purchasing it
asap (:

===========================================================================

FROM: dgj_at_omega.rtpnc.epa.gov
 [Food for thought, but I did not need to get this deep into it -- thanks
anyway, Doug]

It sounds like a semaphore syncronization problem. In the case where you have a
frontend - backend process that uses IPC, typically the processes are started in
such a manner that both sides have the same idea of which semaphores are in use.
 If this were implemented as a frontend and backend daemon, for example, they
would both be started in such a way as to initialize the semaphore list
properly.
If the backend then crashed, or even exited and restarted, the frontend would
still have the old semaphore list while the backend would have
a new different list. killing and restarting all of the associated processes
usually remedies the problem; you might want to let this happen under the
control of a reboot ... assuming this
guess is on target ...
-Doug Gould.
Received on Tue May 07 1996 - 16:23:18 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:46 NZDT