| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: starting Oracle on Linux
A Checklist for CONNECT INTERNAL PASSWORD Issues
Introduction:
This bulletin lists the documented causes of getting prompted for a
password
when trying to CONNECT INTERNAL through "sqldba" or "svrmgrl". In
other words,
if you get prompted for a password when trying to CONNECT INTERNAL,
use the
following to troubleshoot the problem. This article also contains
information
on some additional errors that you may receive while connecting
internal.
$TNS_ADMIN/sqlnet.ora
$HOME/sqlnet.ora
$ORACLE_HOME/network/admin/sqlnet.ora
Depending upon your operating system, it may also be located in:
/var/opt/oracle/sqlnet.ora
/etc/sqlnet.ora
A corrupted "sqlnet.ora" file, or one with security options set, will cause
a 'connect internal' request to prompt for a password. To determine if this
is the problem, locate the "sqlnet.ora" that is being used. The one being
used will be the first one found according to the search order listed above.
Next, move the file so that it will not be found by this search:
% mv sqlnet.ora sqlnet.ora_save
Try to connect internal again. If it still fails, search for other "sqlnet.ora" files according to the search order listed above and repeat
using the move command until you are sure there are no other "sqlnet.ora"
files being used. If this does not resolve the issue, use the move command
to put all the "sqlnet.ora" files back where they were before you made the
change:
% mv sqlnet.ora_save sqlnet.ora
If moving the "sqlnet.ora" resolves the issue, then verify the contents
of the file:
setting it to:
SQLNET.AUTHENTICATION_SERVICES = (BEQ,NONE) b) SQLNET.CRYPTO_SEED
This should not be set in a "sqlnet.ora" file on UNIX. If it is,
comment the line out. (This setting is added to the "sqlnet.ora" if
it is built by one of Oracle's network cofiguration products shipped
with client products.)
c) AUTOMATIC_IPC
If this is set to "ON" it can force a "TWO_TASK" connection.
Try setting this to "OFF":
AUTOMATIC_IPC = OFF
2. Set the permissions correctly in the "TNS_ADMIN" files. The environment
variable TNS_ADMIN defines the directory where the "sqlnet.ora", "tnsnames.ora", and "listener.ora" files reside. These files must contain
the correct permissions, which are set when "root.sh" runs during installation.
As root, run "root.sh" or edit the permissions on the "sqlnet.ora", "tnsnames.ora", and "listener.ora" files by hand as follows:
$ cd $TNS_ADMIN $ chmod 644 sqlnet.ora tnsnames.ora listener.ora $ ls -l sqlnet.ora tnsnames.ora listener.ora -Rw-R--R-- 1 oracle dba 1628 Jul 12 15:25 listener.ora -Rw-R--R-- 1 oracle dba 586 Jun 1 12:07 sqlnet.ora -Rw-R--R-- 1 oracle dba 82274 Jul 12 15:23 tnsnames.ora
B. Software and Operating System Issues:
% cd $ORACLE_HOME
% pwd
If this returns a location other than your "ORACLE_HOME" or is invalid,
you will need to reset the value of this environment variable:
sh or ksh:
----------
% ORACLE_HOME=<path_to_ORACLE_HOME>
% export ORACLE_HOME
Example:
% ORACLE_HOME=/u01/app/oracle/product/7.3.3
% export ORACLE_HOME
csh:
----
% setenv ORACLE_HOME <path_to_ORACLE_HOME>
Example:
% setenv ORACLE_HOME /u01/app/oracle/product/7.3.3
If your "ORACLE_HOME" contains a link or the instance was started with
the "ORACLE_HOME" set to another value, the instance may try to start
using the memory location that another instance is using. An example of
this might be:
You have "ORACLE_HOME" set to "/u01/app/oracle/product/7.3.3" and start
the instance. Then you do something like:
% ln -s /u01/app/oracle/product/7.3.3 /u01/app/oracle/7.3.3
% setenv ORACLE_HOME /u01/app/oracle/7.3.3
% svrmgrl
SVRMGR> connect internal
If this prompts for a password then most likely the combination of your
"ORACLE_HOME" and "ORACLE_SID" hash to the same shared memory address of
another running instance. Otherwise you may be able to connect internal
but you will receive an ORA-01034 "Oracle not available" error.
In most cases using a link as part of your "ORACLE_HOME" is fine as long
as you are consistent. Oracle recommends that links not be used as part
of the "ORACLE_HOME", but their use is supported.
2. Check that $ORACLE_SID is set to the correct SID, (including capitalization),
and does not have any typos:
% echo $ORACLE_SID
Refer to article [NOTE:1048876.6]
<ml2_documents.showDocument?p_id=1048876.6&p_database_id=NOT> for more
information.
3. Ensure $TWO_TASK is not set. To check if "TWO_TASK" is set, do the following:
sh, ksh or on HP/UX only csh:
-----------------------------
env |grep -i two
csh:
----
setenv |grep -i two
If any lines are returned such as:
TWO_TASK=
or
TWO_TASK=PROD
You will need to unset the environment variable "TWO_TASK":
sh or ksh:
----------
unset TWO_TASK
csh:
----
unsetenv TWO_TASK
If you are running Oracle release 8.0.4, and upon starting "svrmgrl" you
receive an ORA-06401 "NETCMN: invalid driver designator" error, you should
also unset two_task. The login connect string may be getting its value
from the TWO_TASK environment variable if this is set for the user.
4. Check the permissions on the Oracle executable:
% cd $ORACLE_HOME/bin
% ls -l oracle ('ls -n oracle' should work as
well)
The permissions should be rwsr-s--x, or 6751. If the permissions are incorrect, do the following as the "oracle" software owner:
% chmod 6751 oracle
If you receive an ORA-03113 "end-of-file on communication" error followed
by a prompt for a password, then you may also need to check the ownership and
permissions on the dump directories. These directories must belong to Oracle,
group dba, (or the appropriates names for your installation). This error may occur
while creating a database.
Permissions should be: 755 (drwxr-xr-x)
Also, the alert.log must not be greater than 2 Gigabytes in size.
When you start up "nomount" an Oracle pseudo process will try to write the
"alert.log" file in "udump". When Oracle cannot do this (either because of
permissions or because of the "alert.log" being greater than 2 Gigabytes in
size), it will issue the ORA-03113 error.
5. Make sure the operating system user issuing the CONNECT INTERNAL belongs
to the "osdba" group as defined in the "$ORACLE_HOME/rdbms/lib/config.s"
or "$ORACLE_HOME/rdbms/lib/config.c". Typically this is set to "dba". To
verify the operating system groups the user belongs to, do the following:
% id
uid=1030(oracle) gid=1030(dba)
The "gid" here is "dba" so the "config.s" or "config.c" may contain an
entry such as:
/* 0x0008 15 */ .ascii "dba\0"
If these do not match you will either need to add the operating system user
to the group as it is seen in the "config" file, or modify the "config" file
and relink the "oracle" binary. Refer to entry [NOTE:50507.1] <ml2_documents.showDocument?p_id=50507.1&p_database_id=NOT> section
3 for more details.
6. Verify that the file system is not mounted no set uid:
% mount
/u07 on /dev/md/dsk/d7 nosuid/read/write
If the filesytem is mounted "nosuid", as seen in this example, you will
need to unmount the filesystem and mount it without the "nosuid" option.
Consult your operating system documentation or your operating system vendor
for instruction on modifying mount options.
7. Be sure you are not logged in as the "root" user and that the environment
variables "USER", "USERNAME", and "LOGNAME" are not set to "root". The
"root" user is a special case and cannot connect to Oracle as the "internal"
user unless the effective group is changed to the "osdba" group, which is
typically "dba". To do this you would either have to modify the "/etc/password" file (not recommended) or use the "newgrp" command:
# newgrp dba
"newgrp" will always open a new shell, so you can not issue "newgrp" from
within a shell script. Keep this in mind if you plan on executing scripts
as the "root" user.
8. Verify that the "osdba" group is only listed once in the "/etc/group" file:
% grep dba /etc/group
dba::1010:
dba::1100:
If more than one line starting with the "osdba" group is returned you will
need to remove the ones that are not correct. It is not possible to have
more than one group use a group name.
9. Please read the following warning before you attempt to use the information
in this step:
If an instance crashed or was killed off using "kill" there may be shared
memory segments hanging around that belong to the down instance. If there
are no other instances running on the machine you can issue:
% ipcs -b
T ID KEY MODE OWNER GROUP SEGSZ
Shared Memory:
m 0 0x50000ffe --rw-r--r-- root root
68
m 1601 0x0eedcdb8 --rw-r----- oracle dba
4530176
In this case the "ID" of "1601" is owned by "oracle" and if there are no
other instances running in most cases this can safely be removed:
% ipcrm -m 1601
If your SGA is split into multiple segments you will have to remove all
segments associated with the instance. If there are other instances running, and you are not sure which memory segments belong to the failed
instance, you can do the following:
% svrmgrl
SVRMGR> connect internal
SVRMGR> oradebug ipc
In Oracle8:
-----------
Area #0 `Fixed Size', containing Subareas 0-0
Total size 000000000000b8c0, Minimum Subarea size
00000000
Subarea Shmid Size Stable Addr
0 7205 000000000000c000 80000000
In Oracle7:
-----------
-------------- Shared memory --------------
Seg Id Address Size
2016 80000000 4308992
Total: # of segments = 1, size = 4308992
Note the "Shmid" for Oracle8 and "Seg Id" for Oracle7 for
each
running instance. By process of elimination find the
segments that
do not belong to an instance and remove them.
Check your "pfile". It is typically in the "$ORACLE_HOME/dbs" directory
and will be named "init<your_sid>.ora, where "<your_sid>" is the value
of "ORACLE_SID" in your environment. If the "init<your_sid>.ora" file has
the "ifile" parameter set, you will also have to check the included file
as well. You are looking for the parameter "audit_file_dest".
If "audit_file_dest" is set, change to that directory; otherwise change to
the "$ORACLE_HOME/rdbms/audit" directory, as this is the default location
for audit files. If the directory does not exist, create it. Ensure that
you have enough space to create the audit file. The audit file is generally
600 bytes in size. If it does exist, verify you can write to the directory:
% touch afile
If it could not create the called "afile", you need to change the permissions on your audit directory:
% chmod 751
ld:so.1: oracle_home/bin/svrmgrl fatal relocation error
symbol not found kgffiop
RDBMS v7.3.2 is installed. RDBMS v8.0.4 is a separate "oracle_home", and you
are attempting to have it coexist. This is due to the wrong version of the client shared
library "libclntsh.so.1" being used at runtime. Verify environment variable settings.
You need to ensure that "ORACLE_HOME" and "LD_LIBRARY_PATH" are set correctly.
For C-shell, type:
% setenv LD_LIBRARY_PATH $ORACLE_HOME/lib
% setenv ORACLE_HOME /u01/app/oracle/product/8.0.4
For Bourne or Korn shell, type:
$ LD_LIBRARY_PATH=$ORACLE_HOME/lib
$ export LD_LIBRARY_PATH
$ ORACLE_HOME=/u01/app/oracle/product/8.0.4
$ export ORACLE_HOME
% df -k
If it has reached 100% capacity, this may be the cause of 'connect internal'
prompting for a password. Additional disk space will need to be made
available before 'connect internal' will work.
For additional information refer to [NOTE:97849.1] <ml2_documents.showDocument?p_id=97849.1&p_database_id=NOT>.
$ SET DEFAULT SYS$SYSTEM:
$ RUN AUTHORIZE
If the list returned by AUTHORIZE does not contain ORA_<SID>_DBA, or
ORA_DBA, then you do not have the correct OS privileges to issue a connect
internal. If ORA_<SID>_DBA was added AFTER ORA_DBA, then ORA_DBA needs to
be removed and granted again to be updated. Please refer to [NOTE:1010852.6] <ml2_documents.showDocument?p_id=1010852.6&p_database_id=NOT>
for more details.
2. On Windows NT, check if DBA_AUTHORIZATION is set to BYPASS in the registry.
Refer to [NOTE:1027664.6]
<ml2_documents.showDocument?p_id=1027664.6&p_database_id=NOT> for more
details.
3. On Windows NT, if you are able to connect internally but then startup fails
for some reason, successive connect internal attempts might prompt for a
password. You may also receive errors such as:
ORA-12705: invalid or unknown NLS parameter value specified
ORA-01012: not logged on
LCC-00161: Oracle error (possible syntax error)
ORA-01031: insufficient privileges
Refer to entry [NOTE:1027964.6]
<ml2_documents.showDocument?p_id=1027964.6&p_database_id=NOT> for
suggestions on how to resolve this
problem.
4. If you are using Multi-Threaded Server (MTS), make sure you are using a
dedicated server connection. A dedicated server connection is required to
start up or shutdown the database. Unless the database alias in the "TNSNAMES.ORA" file includes a parameter to make a dedicated server connection, it will make a shared connection to a dispatcher. See [NOTE:1058680.6] <ml2_documents.showDocument?p_id=1058680.6&p_database_id=NOT> for more details.
5. On Solaris, if the file "/etc/.name_service_door" has incorrect permissions,
Oracle cannot read the file. You will receive a message that "The Oracle
user cannot access "/etc/.name_service_door" (permission denied). This file
is a flavor of IPC specific to Solaris which Oracle software is using. This
can also cause connect internal problems. See entry [NOTE:1066589.6] <ml2_documents.showDocument?p_id=1066589.6&p_database_id=NOT>.
6. You are on Digital Unix, running SVRMGRL (Server Manager line mode),
and you recieve an ORA-12547 "TNS:lost contact" error and a password
prompt.
This problem occurs when using Parallel Server and the True Cluster software together. If Parallel Server is not linked in, svrmgrl works as
expected.
Oracle V8.0.5 requires an Operating System patch which previous versions of
Oracle did not require. The above patch allows svrmgrl to communicate with the
TCR software.
You can determine if the patch is applied by running: % nm /usr/ccs/lib/libssn.a | grep adjust
If this returns nothing, then you need to:
If REMOTE_OS_AUTHENT is set to true, users who are members of the
dba group on the remote machine are able to connect as INTERNAL
without a password.
However, if you are connecting remotely, that is connecting via anything
except the bequeath adapter, you will be prompted for a password regardless
of the value of "REMOTE_OS_AUTHENT". Received on Fri Oct 26 2001 - 13:14:26 CDT
 |
 |