weird problem with svrmgrl

[Kirill Cherkashin]

Hi,

we have 8i DB on A-server(1CPU,512Mb). When I tried to connect to DB by svrmgrl as user oracle everything is fine. But any unix user even from dba group got the ORA-03113 error.Kernel settings were set according oracle's metalink recomendations. But problem persists.Any idea what is going on?

Kirill
p.s. sqlplus is working fine for any user.

[Steve Steel]

Hi


Saw something similar once.

Try to disable the memory windows configuration, just replace the
/etc/services.window file with a default one.


Then try again. I believe Oracle can better help you.


Steve Steel

[Tom Geudens]

Hi,
Sorry for stating the obvious, but did you indicate "dba" as the SYSDBA group during the oracle installation ? If not, your executable is not linked with the right group and svrmgrl will only work for oracle ...

Regards,
Tom

[Kirill Cherkashin]

we use default /etc/services.window. No changes has been made.

[John Palmer]

Hi,

Is the Oracle environment set-up the same as oracle when you log in to one of the other users?

Regards,
John

[Ian Dennison_1]

-rwsr-s--x 1 root dba 9605120 Aug 21 2001 dbsnmp
-rwsr-s--x 1 oracle8i dba 8200192 Aug 21 2001 oemevent
-rwsr-s--x 1 oracle8i dba 30769152 Aug 21 2001 oracle
-rwsr-s--x 1 root dba 9625600 Aug 21 2001 oratclsh
-rwsr-s--x 1 oracle8i dba 7876608 Aug 21 2001 tnslsnr

Check your sticky bits are set on $ORACLE_HOME/bin, the above file list shows an 817 install.

This usually occurs when people try to upgrade Oracle by copying files rather than using the installer.

Share and Enjoy! Ian

[T G Manikandan]

The problem should definitely be with the shared memory and semaphore parameters in the kernel.

What are the values of

SEMMNI
SEMMNS
SHMMAX


Revert

[Kirill Cherkashin]

Thanks Ian,
I really just moved oracle intstallation from another machine to this one. ;-)
Anyway,I forgot to mention. This weird behevior of svrmgrl happened only with one DB and at the same time I have no problem with another two Oracle DB.

Kirill

[Brian Crabtree]

This will take some work. Most likely, you have a shared memory segment that is hung. This can happen when you do not have a high emough kernel parameter for shmmax or maxdsiz(_64bit). The easiest way is to bring the other databases down, then run "ipcs" and look for memory segments and semaphores owned by "oracle" (or whatever user owns your installation). THen remove the ones left with the "ipcrm" command.

The other way, you have to login to each database, and run "oradebug". This will create a trace file in the userdump destination. Look through the file for the semaphore and memory segments for each database that is running, and then remove any of the segments that are not in the trace files using ipcs and ipcrm.

Hope this helps,

Brian