DBAsupport.com Forums - Powered by vBulletin
Results 1 to 10 of 10

Thread: ORA-01031

  1. #1
    Join Date
    Oct 2001
    Hello all need some help...

    I am at a new site that runs 8.1.6 on Solaris. I get this error while trying to connect as internal to shutdown the database in svrmgrl it actually ask me for a password. I have never experience this error before please help me. I need to be able to connect as internal....

    $ ./bin/svrmgrl

    Oracle Server Manager Release - Production

    Copyright (c) 1997, 1999, Oracle Corporation. All Rights Reserved.

    Oracle8i Enterprise Edition Release - Production
    With the Partitioning option
    JServer Release - Production

    SVRMGR> connect internal
    ORA-01031: insufficient privileges

  2. #2
    Join Date
    Dec 2000
    Virginia, USA
    Try connecting with Internal/oracle
    If your inetrnal password never been changed before you should be able to connect just fine.

  3. #3
    Join Date
    Jan 2001


    Careful with that axe Eugene

  4. #4
    Join Date
    Oct 2001
    I try the internal/oracle and it still gave me the same error. I spoke to the consultant that originally install the database at this site and he said he did not change the password. I also try internal/manager to no avail.

  5. #5
    Join Date
    Oct 2001
    it seem that they install the default configuration for the Solaris platform with Oracle as the user and dba as the group. but I did not see a Oinstall group in the etc/group file. would that make a difference?

  6. #6
    Join Date
    Oct 2000
    Saskatoon, SK, Canada
    Do you have metalink support.? If so take a look at Note:69642.1

    Else let us know.


    Life is a journey, not a destination!

  7. #7
    Join Date
    Oct 2001
    Sorry this site does not have the metalink support. If you can email or post the note I would greatly appreciated.

  8. #8
    Join Date
    Oct 2000
    Saskatoon, SK, Canada

    Post Curtesy of Oracle Metalink


    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.

    A. SQLNET.ORA Checks:

    1. The "sqlnet.ora" can be found in the following locations (listed by search


    Depending upon your operating system, it may also be located in:


    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

    % mv sqlnet.ora_save sqlnet.ora

    If moving the "sqlnet.ora" resolves the issue, then verify the contents
    of the file:


    If you arenot using database links, comment this line out or try
    setting it to:



    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.)


    If this is set to "ON" it can force a "TWO_TASK" connection.
    Try setting this to "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

    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:

    1. Be sure $ORACLE_HOME is set to the correct directory and does not have any
    typing mistakes:

    % 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:

    % export ORACLE_HOME


    % ORACLE_HOME=/u01/app/oracle/product/7.3.3
    % export ORACLE_HOME


    % setenv ORACLE_HOME


    % 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] 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


    setenv |grep -i two

    If any lines are returned such as:




    You will need to unset the environment variable "TWO_TASK":

    sh or ksh:

    unset TWO_TASK


    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] 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

    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:

    * *
    * WARNING: If you remove segments that belong to a running *
    * instance you will crash the instance, and this may *
    * cause database corruption. *
    * *
    * Please call Oracle Support Services for assistance *
    * if you have any doubts about removing shared memory *
    * segments. *
    * *

    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

    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:

    a) Shut down all the instances on the machine and remove whatever
    shared memory still exists that is owned by the software owner.

    b) Reboot the machine.

    c) If your Oracle software is release 7.3.3 or newer, you can connect
    into each instance that is up and identify the shared memory owned
    by that instance:

    % 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.

    10. If you are prompted for a password and then receive error ORA-09925 "unable
    to create audit trail file" or error ORA-09817 "write to audit file failed",
    along with "SVR4 Error: 28: No space left on device", do the following:

    Check your "pfile". It is typically in the "$ORACLE_HOME/dbs" directory
    and will be named "init.ora, where "" is the value
    of "ORACLE_SID" in your environment. If the "init.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

    11. If connect internal prompts you for a password and then you receive an
    ORA-12705 "invalid or unknown NLS parameter value specified" error, you
    need to verify the settings for "ORA_NLS", "ORA_NLS32", "ORA_NLS33" or
    "NLS_LANG". You will need to consult your Installation and Configuration
    Guide for the proper settings for these environment variables.

    12. If you have installed Oracle software and are trying to connect with
    Server Manager to create or start the database, and receive a TNS-12571
    "packet writer failure" error, please refer to [NOTE:1064635.6].

    13. If in SVRMGRL (Server Manager line mode), you are running the "startup.sql"
    script and receive the following error:

    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 ORACLE_HOME /u01/app/oracle/product/8.0.4

    For Bourne or Korn shell, type:

    $ export LD_LIBRARY_PATH

    $ ORACLE_HOME=/u01/app/oracle/product/8.0.4
    $ export ORACLE_HOME

    14. Ensure that the disk the instance resides on has not reached 100% capacity.

    % 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].

    15. Delete process.dat and regid.dat files in $ORACLE_HOME/otrace/admin directory.
    Oracle Trace is enabled by default on 7.3.2 and 7.3.3 (depends on platform)
    This can caused high disk space usage by these files and cause a number of
    apparently mysterious side effects. See note:45482.1 for more details.

    C. Operating System Specific checks:

    1. On OpenVMS, check that the privileges have been granted at the Operating
    System level:


    If the list returned by AUTHORIZE does not contain ORA__DBA, or
    ORA_DBA, then you do not have the correct OS privileges to issue a connect
    internal. If ORA__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]
    for more details.

    2. On Windows NT, check if DBA_AUTHORIZATION is set to BYPASS in the registry.
    Refer to [NOTE:1027664.6] 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] for suggestions on how to resolve this

    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] 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].

    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

    This problem occurs when using Parallel Server and the True Cluster
    software together. If Parallel Server is not linked in, svrmgrl works as

    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:

    1. Obtain the patch for TCR 1.5 from Digital. This patch is for the
    MC SCN and adds the symbol "adjustSequenceNumber" to the library

    2. Apply the patch.

    3. Relink Oracle

    7. You are on version 6.2 of the Silicon Graphics UNIX (IRIX) operating system
    and you have recently installed RDBMS release 8.0.3. If you are logged on
    as "oracle/dba" and an attempt to log in to Server Manager using
    "connect/internal" prompts you for a password, you should refer to entry

    D. Additional Information:

    1. In the "Oracle7 Administrator's Reference for UNIX", there is a note that

    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". Refer to [BUG:644988].


    Life is a journey, not a destination!

  9. #9
    Join Date
    Oct 2001

    Thanks you, the first one on the list fixed it. The sqlnet.ora file was the problem. owe you a beer!


  10. #10
    Join Date
    Oct 2000
    Saskatoon, SK, Canada


    Life is a journey, not a destination!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Click Here to Expand Forum to Full Width

We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.