ORA-01031: insufficient privileges when connecting as sysdba

Yesterday i ran into a server which did not allow to connect with “sqlplus / as sysdba” ( or sqlplus “/as sysdba”) but would allow sqlplus sys as sysdba.
I needed the server to allow this as scripts are using this connect method to execute nightly database operations.

[DXP01] xxx:admin> sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 – Production on Wed Jul 7 20:45:54 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

ERROR:
ORA-01031: insufficient privileges

Enter user-name:

After recreating the passwd files by using

orapwd file=$ORACLE_HOME/dbs/orapwDXP01 password=manager entries=5

And double checking the group membership of oracle were the users oracle should be part of the group “dba”.

[DXP01] xxx:admin> id
uid=1000(oracle) gid=1000(oinstall) groups=1000(oinstall),1001(dba)

I found myself with an SQLNET.ORA which causes this behaviour.

SQLNET.AUTHENTICATION_SERVICES=(NTS)

After commenting out this line i was able to connect as sysdba again.

[DXP01] xxx:admin> sqlplus / as sysdba

SQL*Plus: Release 10.2.0.3.0 – Production on Wed Jul 7 20:57:05 2009

Copyright (c) 1982, 2006, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – 64bit Production
With the Partitioning, OLAP and Data Mining options

SQL>

Problems with the BACKSPACE key on Solaris or AIX

Every ran into the problem that the BACKSPACE key does not work ?
Instead you will get “^?” or “^h” on the screen when BACKSPACE is used.
^? will be returned on ksh shell and ^h will be returned when using a bash shell

When you want to lose this behaviour in your session you could execute the following command :

stty erase [BACKSPACE]

After this the BACKSPACE works again ! After logout the setting is gone and should be executed again.

Using SPident to reveal the running SuSE release

To verify the Suse 10 release and its Service Packs you can either consult the /etc/SuSE-release file or execute the following command.

[] xxx:/> SPident -v

Summary (using 840 packages)
Product/ServicePack conflict match update (shipped)
SLE-10-x86_64 0 0% 306 36.4% 0 (2754 11.1%)
SLE-10-x86_64-SP1 0 0% 443 52.7% 0 (2938 15.1%)
SLE-10-x86_64-SP2 0 0% 840 100% 0 (2337 35.9%)

CONCLUSION: System is up-to-date!
found SLE-10-x86_64-SP2

[] xxx:/>