Re: insufficient privileges as sysdba 8.1.7 on Win2k

"todhsals" <todhsals_at_hotmail.com> wrote in message news:RZOm9.20426$xI5.4066_at_sccrnsc02...
> I'm really trying to figure out why anything other than connect internal
> will not work to shutdown and startup the database. As I understand it
> internal is depreciated. Isn't sysdba necessary to startup and shutdown?

You are right: INTERNAL is the Oracle 7 way of connecting as a privileged user, and ...AS SYSDBA is the 8.0 and above way of doing the same thing. You must be one or the other to do privileged actions.

Your particular scenario, I can't work out. You've got a password file (meaning that system...as sysdba should fail unless you've done the dirty and granted SYSDBA to system), but you also said in your original post:

"The OS
account I'm using is a domain account the local ORA_DBA and Administrators groups"

Noe that's appalling grammar, but never mind: are you saying that the account I've logged onto this Windows box is a domain account, and it happens to be a member of the *LOCAL* ORA_DBA group?

If you log onto that box as Domain_Fred and Domain_Fred is a member of the local ORA_DBA group, then a connect / as sysdba should elicit a perfectly reasonable connection, and startups and shutdowns should be no problem.

O/S group membership always over-rides whatever you may have extant in your password file.

But it's a LOCAL group, not a domain one, though domain users can be a member of it.

My only suggestion to you is: do you want password file authentication, or O/S authentication?? Pick one and stick with it. If O/S, set remote_login_passwordfile=NONE, set up memberships of the local ORA_DBA group (I tend to find that "Everyone" is a good go when debugging these sorts of things). If you want passwordfile authentication, then get rid of the ORA_DBA group, create a new password file, make absolutelty sure the remote_login_passwordfile parameter is set to EXCLUSIVE, grant SYSDBA to a select few users, and then all should be well.

This ain't rocket science. Be clear in what you want to achieve, then make sure the various settings are appropriate to the need.

Regards
HJR
>
> Just to add to my original post, the password file was recreated with
orapwd
> & nothing changed. The password file is being used when I connect
internal.
> I'm prompted for a password & it only works with the correct password.
>

PS... Did you re-grant SYSDBA to the relevant users? It's only that which transfers their data dictionary entries into the password file.

> Thanks,
> Tod
>
>
> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
> news:EIOm9.45127$g9.128744_at_newsfeeds.bigpond.com...
> >
> > "Rauf Sarwar" <rs_arwar_at_hotmail.com> wrote in message
> > news:92eeeff0.0210021908.1aafc164_at_posting.google.com...
> > > > Use oradim to drop the Oracle Windows service
> > > > Delete the password file PWD<sid_name>.ora
> > > > Recreate the Oracle Windows service with oradim
> > > >
> > > > That should do it unless somehow you have been playing around in the
> > > > registry and dropped the pointer to the password file.
> > > >
> > > > Daniel Morgan
> > >
> > >
> > > You can also just recreate the password file using orapwd.
> > > 1) Shutdown database as internal from svrmgrl
> > > 2) Delete old PWD<SID>.ora file
> > > 3) orapwd file=%ORACLE_HOME%\database\pwd<sid>.ora password=xxxxxx
> > > 4) Start database as internal from svrmgrl
> > > 5) grant sysdba to system;
> >
> > Ye Gods! Why Oh Why would you want to grant sysdba to SYSTEM???? When
you
> > connect system....AS SYSDBA, you are actually logged on as SYS. Half the
> > things you then proceed to do are never replicable via export/import
(just
> > for starters).
> >
> > PLEASE don't suggest we all connect as SYS. It's extremely bad news,
and
> > very bad practice.
> >
> > Don't do it.
> >
> > Regards
> > HJR
> >
> > > 6) Exit from svrmgrl and login as system then try again
> > >
> > > /Rauf Sarwar
> >
> >
>
>
Received on Wed Oct 02 2002 - 22:56:48 CDT