ORA-03113 error on start of svrmgrl

[Dave Chamberlin]

Hello,

I just installed 64bit oracle on my RP8400 (hpux 11.11). I patched the Oracle Home to 8.1.7.4. When I run svrmgrl, I get ora-03113 error. I have increased SHMMAX to 1.8G. I just did the same install on an N4000 (hpux 11.0), and had no issues. The kernel parms on this box are higher or equal to those on the N.
Any ideas?

[Warren_9 · Accepted solution]

it seems to shmmax is too high...

cut from metalink docid Note:213599.1

* fact: Oracle Server - Enterprise Edition
* fact: HP 9000 Series HP-UX (64-bit)
* symptom: Sqlplus fails to start
* symptom: Svrmgrl fails to start
* symptom: ORA-03113: end-of-file on communication channel
* symptom: Segmentation Fault (coredump)
* cause: The kernel parameters SHMMAX and MAXDSIZ64 are misconfigured or not set.

fix:

Set MAXDSIZ64 = 1GB
AND
Set SHMMAX >= MAXDSIZ64

[Indira Aramandla]

Hi Dave,

The error "ORA-03113 end-of-file on communication channel" on new installations when starting svrmgrl...the reasons could be

when Oracle is unable to start the SGA because semphores were not available or there were not enough semaphore identifiers (semmni). Or the Kernel parameter SEMMNS which is used to calculate the total semaphores available on the system is too small.

Set to the sum of the PROCESSES parameter for each Oracle database, adding the largest one twice, then add an additional 10 for each database."


Indira A

[D Block 2]

Dave, have you searched http://metalink.oracle.com ? register, if not.
-----------------------------------------


Note:1020463.6
Subject: DIAGNOSING ORA-3113 ERRORS
Type: PROBLEM
Status: PUBLISHED
Content Type: TEXT/X-HTML
Creation Date: 13-AUG-1996
Last Revision Date: 24-JUN-2005



Problem Description:
====================

How do I diagnose the ora-3113 error?



ora-3113 end of file on communication channel reached


Additional Search Words: svrmgrl sqldba server manager

Solution Description:
=====================

The ORA-3113 error is a general error reported by Oracle client tools,
which signifies that they cannot communicate with the oracle shadow
process. As it is such a general error more information must be collected
to help determine what has happened.

This short article describes what information to collect for an
ORA-3113 error when the Oracle server is on a Unix platform.

General Issues:
===============

1) Is it only one tool that encounters the error or
do you get an ORA-3113 from any tool doing a similar operation?
If the problem reproduces in SQL*Plus, use this in all tests
below.

2) Check if the problem is just restricted to:

[ ] One particular UNIX user,
[ ] Any UNIX user
or [ ] Any UNIX user EXCEPT as the Oracle user.


3) Check if the problem is just restricted to:

[ ] One particular ORACLE logon
or [ ] Any ORACLE logon that has access to the
relevant tables.

4) If you have a client-server configuration does this occur from:

[ ] Any client
[ ] Just one particular client
or [ ] Just one group of clients ?
If so what do these clients have in common ?
Eg: Software release .

5) Do you have a second server or database version where the
same operation works correctly?




Connecting to Oracle
====================

If the ORA-3113 error occurs when actually connecting to Oracle then
follow the section below. If you connect to Oracle successfully and get
the error on an established connection, please go to the next section
'An Established Connection'.


Local Connections
~~~~~~~~~~~~~~~~~
For local connections check the following:


1) Try using the SQL*Net V1 driver for local connections:

setenv TWO_TASK P:

Then try the client tool. If this now works you may have a
problem with the default SQL*Net driver.


2) Your 'oracle' executable may be corrupt. Relink it as follows:

For 7.3.X thru 8.1.7

Log in as the 'oracle' user.
% script /tmp/relink.out
% cd $ORACLE_HOME/rdbms/lib
% rm -f oracle
% make -f oracle.mk ioracle
% exit

For 9.2.X use the relink executible
relink
usage:
relink
parameters: all, oracle, network,
client, client_sharedlib interMedia,
ctx, precomp, utilities, oemagent, ldap

If this reports any errors Oracle support will need to see
the contents of the file /tmp/relink.out .

3) If you cannot connect as the Oracle user AND your system has
the 'truss' command try the following when logged in as
'oracle' (using the relevant client tool):

% truss -o /tmp/truss.out -f sqlplus user/password
Exit from sqlplus (or the problem tool)

Keep the file /tmp/truss.out safe - Oracle MAY need to see it.


Remote Connections
==================

For remote connections check the following:

1) Check if you can make LOCAL connections. If not then follow
the steps above for LOCAL connection problems.

2) If you have truss available try to truss the Oracle
connection. You will normally need the root privilege to do this
and should use truss on the relevant listener process (see
Table C1)
Eg: For TCP/IP the listener is 'orasrv' so enter these
commands as 'root':

% truss -o /tmp/truss.out -f -eall -p

Attempt the connection to reproduce the ORA-3113 then
interrupt this 'truss' session.



An Established Connection:
==========================

If the ORA-3113 error occurs AFTER you have connected to Oracle, then
it is most likely that the oracle executable has terminated unexpectedly.

1) Determine which database you were connected to and
obtain the following init.ora parameter values:

Parameter Default


USER_DUMP_DEST $ORACLE_HOME/rdbms/log
BACKGROUND_DUMP_DEST $ORACLE_HOME/rdbms/log
CORE_DUMP_DEST $ORACLE_HOME/dbs

Eg: To find these log into SQL*DBA or Server Manager and:

SQLDBA> show parameter dump


2) Check in your 'USER_DUMP_DEST' for any Oracle trace file.
It is important to find the correct trace file. Use the
command 'ls -ltr' to list files in time order with the
latest trace files appearing LAST. If you are not sure
which trace file may be relevant, move all the current trace
files to a different directory and reproduce the problem.
The trace file will typically be of the form 'ora_.trc'.


3) If there is no trace file check for a core dump in the
CORE_DUMP_DEST. Check as follows:

% cd $ORACLE_HOME/dbs # Or your CORE_DUMP_DEST
% ls -l core*

If there is a file called core, check that its time matches
the time of the problem. If there are directories called
'core_' check for core files in each of these. It is
IMPORTANT to get the correct core file. Now obtain a stack
trace from this core file. Check each of the sequences below
for the procedure. One of the following should work for your
platform:


If you have dbx:
% script /tmp/core.stack
% dbx $ORACLE_HOME/bin/oracle core
(dbx) where
...
(dbx) quit
% exit

If you have sdb:
% script /tmp/core.stack
% sdb $ORACLE_HOME/bin/oracle core
* t
...
* q
% exit

If you have xdb:
% script /tmp/core.stack
% xdb $ORACLE_HOME/bin/oracle core
(xdb) t
...
(xdb) q
% exit


If you have adb:
% script /tmp/core.stack
% adb $ORACLE_HOME/bin/oracle core
$c
...
$q
% exit


If you have gdb:
% script /tmp/core.stack
% gdb $ORACLE_HOME/bin/oracle core
(gdb) bt > stack.out
(gdb) quit




4) Try to isolate the SQL command that is executing when
the error occurs. Eg: Is it a particular SQL statement
or PL/SQL block that causes the error ?

To help establish this turn on SQL_TRACE for the client
tool.

Eg: Product Action
~~~~~~~ ~~~~~~
SQL*Forms Use the '-s' statistics option at run time.
SQL*Plus Issue 'ALTER SESSION SET SQL_TRACE TRUE;'
Pro* EXEC SQL ALTER SESSION SET SQL_TRACE TRUE;

This should force a server side SQL trace file as detailed
in #2 above. The trace file should give a clue as to what
SQL was being executed.


5) Try to obtain any SQL*Net trace to show what the latest
operation sent to the oracle process was.
For SQL*Net V2 ask for the article Note 16564.1
For SQL*Net V1 check which SQL*Net protocol you are using
and note the Debug environment variable from table C1 above.
Then catch SQL*Net trace from the client. Eg: For SQL*Net
TCP/IP and sqlplus:

% setenv OSNTDBUG -1 # Use correct OSN*DBUG
variable
% sh
% sqlplus scott/tiger@t:hostname:sid 2>/tmp/net1.out


6) Based on information collected above try to determine a small
test case which will reproduce the problem. This is important
for two reasons:

a) It gives Oracle support a small test case if the
problem does not look like a known problem.

b) It gives you a simple way to check if any patch
supplied will fix the problem.



7) It may be useful to follow the instructions in step (4) above.
This will produce a lot of output but MAY be useful if no
other information is available.


.

--------------------------------------------------------------------------------

Copyright © 2005, Oracle. All rights reserved. Legal Notices and Terms of Use.

[Yogeeraj_1]

hi,

review these kernel parameters as mentioned above and i would recommend that you use "sqlplus" instead of "svrmgrl" since the latter has been obsoleted with newer versions.

e.g.
============================================
$ sqlplus

SQL*Plus: Release 8.1.7.0.0 - Production on Tue Jun 28 08:51:08 2005

(c) Copyright 2000 Oracle Corporation. All rights reserved.

Enter user-name: / as sysdba

Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
With the Partitioning option
JServer Release 8.1.7.4.0 - 64bit Production

SQL>

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

good luck!
regards
yogeeraj

[Eric Antunes]

Hi Dave,

From my experience the major issues are with listener.ora and tnsnames.ora bad configurations.

First of all, check the status of your listener:

$lsnrctl status

If you don't something like:

"
...
Services Summary...
has 1 service handler(s)
...
The command completed successfully"

Then you problem are on the $ORACLE_HOME/network/admin/listener.ora and $ORACLE_HOME/network/admin/tnsnames.ora net configuration files...

Best Regards,

Eric Antunes