Re: ORA-01031 following install of 8.1.7.4 patch

Dave,

Many thanks for your reply - spot on.

I also eventually managed to find the info I required - from this metalink article - from a previous poster [Andrea Salzano, May 21 2003 in group it.comp.software.database... thanks also!]

To assist future frustrated readers, I'll try and summarise the found problem & solution, and include as much info as possible

For future purposes, the extract from this metalink note 69642.1 is given at the foot of the mail.

Here was the cause of the problem (and hence why the metalink note - in particular STEP 6 - solved it.

Summary of problem:
My connect internal was prompting for a password [instead of just connecting] was due to a problem with UNIX groups. Although I was logged in as the oracle user, right group etc... I had had an earlier problem linking the binaries during install of patch 8.1.7.4.

Initial Problem - problems installing the patch:

This problem was principally due to me *not* including the $ORACLE_HOME/lib64 path in the LD_LIBRARY_PATH environment variable.

This caused during Oracle to have problems running the installer of the patch, in particular the following issues:

[for these issues, look into your .../oraInventory/logs directory, in particular installActions.log (there may be previously named logs with timestamps in the name also)]

Note: I ignored some of these errors using the oracle installer. Once install had been complete, I tried to re-run it, but it said I didn't need to (patches already installed)... in this case, look at the log and run the make files individually, at the command-line... for this, you'll run something like:

make -f <long path to a .mk file> <target> e.g. make -f /...oraclepath.../network/lib/ins_net_client.mk client_sharedlib

... once you're sure all runs ok, you can (8.1.7+ I believe) then run
"relink all" to relink all libraries.

OK: as a result of missing lib64, I received an error in the make.log of

if [ -d <oracle_home>/lib64] ; then \

   ; \
fi

...error ; not expected in line 2.

Looking into the ins_net_client.mk I see that this line evaluated to the variable $(GENCLNTSH64) and this must have been blank. I then put in the actual path of the genclntsh64 program, and got over that compilation step.

The next step compained that v9 commands were being used in a non -v9 binary in $ORACLE_HOME/rdbms/lib/config.s ... I was stumped here, so I copied that file from another - working install; ok, after that, I could then relink all binaries and my patch & db worked ok.

Main problem - ORA-01031

In summary (and see step 6 of the metalink note): the config.s file had in it a *different* groupname to the one I was using...

I edited this, re-ran
relink all

and hey presto... all worked.

"Note:69642.1" of METALINK:

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

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

 $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

 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.

2.
 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:

 $ ORACLE_HOME=<path_to_ORACLE_HOME>
 $ export ORACLE_HOME

 Example:  

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

3.
 Check that $ORACLE_SID is set to the correct SID,  (including capitalization)

4.
 Ensure $TWO_TASK is not set.

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

6.
 Make sure the operating system user issuing the CONNECT INTERNAL  (sysdb) 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.

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

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

9.
 Verify that the "osdba" group is only listed once in the "/etc/group"  file.

10.
 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:

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

Dave Hau <davehau_nospam_123_at_nospam_netscape.net> wrote in message news:<3F60D0F0.4000505_at_nospam_netscape.net>...

> See Metalink Note 69642.1
> 
> "UNIX: Checklist for Resolving Connect AS SYSDBA Issues"
> 
> "This bulletin lists the documented causes of getting prompted for a 
> password when trying to CONNECT INTERNAL (or as SYSDBA) through 
> "svrmgrl" or "sqlplus".  In other words, if you get prompted for a 
> password when trying to CONNECT INTERNAL, use the following to 
> troubleshoot the problem."
> 
> Also see Note 1048876.6
> 
> "UNIX: Connect internal prompts for password after install"
> 
> HTH,
> Dave
> 
>