Re: Internal password confusion

"Chris S" <cschofie_at_nospam.home.com> wrote in message news:3a5d49b8.208713544_at_192.168.0.10...
> Platform: NT; Oracle version: 8.1.6 EM. Default install.
>
> I found myself unable to connect to a database using the userid
> 'internal', password 'oracle'. Same failure in both svrmgrl and DBA
> Studio.
>
> After much reading on these newsgroups, and experimenting, here's what
>
> I found.
>
> I used ORAPWD to recreate the password file with a password of
> 'oracle'. I could then connect as 'internal/oracle' in svrmgrl. I
> could also
> connect as 'sys/oracle' - which agrees with the various posts and help
>
> texts that say that ORAPWD changes BOTH 'internal' and 'sys' (contrary
> to what some posters have said).

It doesn't "change" SYS. It creates a superhero bersion of sys that is capable of exercising SYSDBA privileges, and yes -the password for that version of SYS is set to whatever you specify in the orapwd utility. The point being, that if you do a "connect internal" followed by a "select user from dual", you will discover that you've been logged on as SYS in any case.

In short, "internal" is a short-hand way of typing "connect sys/oracle as sysdba", but is functionally equivalent (and, since "internal" is disappearing in 8.1.7 onwards, you'd best get into the habit of using the long-hand format).

>
> However, in dba studio, I found that I could connect as
> 'sys/change_on_install' as a 'normal' user, or as 'sys/oracle' as
> sysdba user. So I concluded that there are really two 'versions' of
> the sys user in my environment at this point - 'sys/internal' and
> 'sys/oracle'!
>

SYS has an entry in the data dictionary. His password there is "change_on_install" by default. If you "connect sys/change_on_install", you are using data dictionary authentication: SYS gets on as a powerful, but ordinary User.

If you want SYS to exercise the SYSDBA privileges (ie, startup, shutdown, backup, recover and create) then you have to have an external authentication mechanism -either o/s or (as you have found by using orapwd) password file. If you are trying to start the damn thing up, you'd be pretty stuffed if your only authentication mechanism was contained within the data dictionary of the (closed!) database itself.

So, yes. SYS can take one of two possible guises. Ordinary, powerful SYS via the data dictionary. Or superher SYSDBA SYS, authenticated externally to the data dictionary.

> This is not reproducible in svrmgrl or sql*plus - in these apps, only
> the 'sys/change_on_install' works. But I just re-tested - dba studio
> allows me to connect as sysdba using sys/oracle!
>

Interesting. Rest assured that connect sys/oracle as sysdba *will* work in server manager (or sqlplus for that matter, in 8i onwards). I suspect that the problem is that dba studio knows where your password file is, but server manager doesn't. Time to check your environment variables. Password files reside in ORACLE_HOME/dbs (from memory). As a command line tool, you want to make sure that the ORACLE_HOME environment variable is set correctly before trying to use Server Manager.

Regards
HJR
> For what it's worth...
>
>
> ===========
> Remove 'nospam' from email to reply - Thanks
Received on Thu Jan 11 2001 - 02:11:07 CST