Re: urgent connect '/ as sysdba' insufficient privs

Hi Kip,
yes I have had this issue recently whilst setting up RAC in a test environment..different GID and UID between the nodes caused a few ownership issues on the datafiles depending on what instance was last writing to the datafiles. This was corrected this by setting the UID and GID for oracle to the same values for both nodes resolving the ownership problems however I could not connect "/ as sysdba". Resolved this through a relink of the binaries. From memory and unfortunately I dont have any notes to back this up the uid and gid are stamped on the oracle binary along with the datafile headers. I have done a little research and the UID and GID are stored in the file inode for the oracle binary. One could assume that changing the uid or gid for the oracle unix user without changing the oracle binary would result in a mis-match between the two ids. The relink resolves this through recreating the oracle binary which in turn I suspect resets the uid and gid for the inode for the oracle executable. Perhaps someone on the list could offer some more insight into how this works...

Regards,

Mark

Kip.Bryant_at_Vishay.com wrote:
> Hi Mark,
>
> Interesting note about UID. Have you experienced this yourself? I went
> through a disaster recovery drill at an outsourced site where everything was
> built up from bare metal including accounts. My notes are not clear on when I
> finally got annoyed enough to have the SA's create accounts with the original
> UID so maybe I just got lucky. Startup with svrmgrl was OK. I added need for
> documenting of original UID to procedures in the event that accounts still had
> to be created from scratch.
>
> Kip
>
> |Hi April,
> |have there been any previous changes to gid or uid for the oracle unix
> |user after the last relink of the oracle executable? if so then you
> |might have to relink the oracle binaries:
>
> |$ORACLE_HOME/bin/relink all
>
> |also check the permissions on $ORACLE_HOME/bin/oracle as well..they
> |should be 6751 or rwsr-s--x
>
> |from memory the uid and gid is stored in the oracle executable on
> |relink..subsequent changes to the uid or gid for the oracle user can
> |result in this sort of permissions error..
>
> |aj wells wrote:
> |> 9i instance
> |> Linux
> |>
> |> Okay, we have an instance that we can log into connect sys/password as
> |> sysdba and it works fine
> |> however...
> |> if we try to log in '/ as sysdba' it complains about insufficient privs...
> |>
> |>
> |> suggestions would be most welcome
> |>
> |> have deleted password file and recreated password file
> |> oracle user is a member of the dba group
> |> relinked sqlplus
> |> what are we missing?
> |>
> |> ajw
> |> --
> |> http://www.freelists.org/webpage/oracle-l
> |>
>
>
>
> |--
> |http://www.freelists.org/webpage/oracle-l
> --
> http://www.freelists.org/webpage/oracle-l
>

--
http://www.freelists.org/webpage/oracle-l