Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: can't connect '/ as sysdba'

Re: can't connect '/ as sysdba'

From: Tim Gorman <>
Date: Thu, 7 Dec 2006 10:37:43 -0700
Message-Id: <>


I don't know if it's too late to chime in now, but you can get ORA-01031 if Oracle cannot read files like "/etc/hosts", "/etc/services", and other network config files in the OS on the database server. Nowadays, it is very common for systems administrators to restrict access to these files, whereas in the past it was not very common...

The way I pinpoint these issues is to use the appropriate system debugging utility (i.e. Linux = "strace", HP-UX = "tusc", or Solaris/AIX = "truss") to find a failed "open" system call. What's annoying is that neither Oracle nor SQL*Plus fail immediately on the failed open, but much further down the line, quite often. Still, it provides a clue...

Using "strace" on Linux as an example, use something like:

strace -o /tmp/sqlplus_strace.out sqlplus "/ as sysdba"

This will trace only the SQL*Plus process and not the Oracle server process. Since the error is "ORA-" and not "SP2-", the error is almost certainly within the Oracle server process, not SQL*Plus.

To "strace" your Oracle server processes is a little more tricky, and can get kinda icky. This technique is called a "trojan horse":

1. Shutdown the Oracle database instance
2. cd $ORACLE_HOME/bin
3. mv oracle oracle.tmpexe
4. echo "strace -o /tmp/oracle_strace_$$.out $ORACLE_HOME/bin/oracle.tmpexe \$*" > oracle
5. chmod 755 oracle
6. startup the Oracle database instance

Needless to say, make sure you understand exactly what steps #3-5 are doing here!!! If you don't, then think it through carefully, ask questions, or don't proceed.

After you've created this "trojan horse", then run "sqlplus '/ as sysdba'" as normal, obtain the error message, and get out immediately. Then, undo all of the steps above by running:

7. shutdown the Oracle database instance
8. mv oracle.tmpexe oracle
9. startup the Oracle database instance

Step #8 will wipe out the "trojan horse" and set everything back to normal.

Examine the generated ".out file from "strace" by looking at all of the "open" system calls and looking for the unexpected anomaly:

grep open /tmp/oracle_strace_12345.out

Hope this helps...


Stefan Knecht wrote:
Try to relink the binary. Perhaps conifg.c was changed intermittedly and the binary hasn't got the change yet ?

cd $ORACLE_HOME/rdbms/lib

make -f ioracle


On 12/7/06, Janine Sisk <> wrote:
[oracle@goethals oracle]$ id
uid=510(oracle) gid=506(devel) groups=506(devel),100(users),503(dba)
[oracle@goethals oracle]$ ls -l $ORACLE_HOME/bin/oracle
-rwsr-s--x 1 oracle devel 53734878 Sep 21 12:48 /home/oracle/

On Dec 6, 2006, at 3:29 PM, Kevin Closson wrote:

> remit :
> output from the id(1) command and ls -l $ORACLE_HOME/bin/oracle
>>>> -----Original Message-----
>>>> From:
>>>> [] On Behalf Of Janine Sisk
>>>> Sent: Wednesday, December 06, 2006 3:20 PM
>>>> To: Mladen Gogala
>>>> Cc: 'Oracle-L Freelists'
>>>> Subject: Re: can't connect '/ as sysdba'
>>>> I wish it would! But I think this part is correct. Of
>>>> course, I've been staring at it long enough to be well into
>>>> stupid mistake territory...

-- Received on Thu Dec 07 2006 - 11:37:43 CST

Original text of this message