Re: sqlplus /nolog can't manage instance

From: Howard J. Rogers <howardjr2000_at_yahoo.com.au>
Date: Tue, 13 Aug 2002 15:49:03 +1000
Message-ID: <3d589da7@dnews.tpgi.com.au>

"Pan Tao" <pantao_fz_at_21cn.com> wrote in message news:aja2oq$1uq1$1_at_mail.cn99.com...
>
> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
> news:3d587236_at_dnews.tpgi.com.au...
> > That description of the error states that you should "Check addresses
used
> > for proper protocol specification. Before reporting this error, look at
> the
> > error stack and check for lower level transport errors.For further
> details,
> > turn on tracing and re-execute the operation. Turn off tracing when the
> > operation is complete."
> >
> > >
> > > And my question is: ORA-12560 error means the oracle instance is not
> > > started(?).
> > > But while connect sys/change_on_install as sysdba under sqlplus /nolog
> > > condition,
> > > it seems the instance need not has been started. Bacause in normal
case,
> > > startup
> > > commmand will be used to start the instance. So what may be the
problem?
> > >
> >
> > Sort out your networking components (just a daft question, but why do
you
> > insist on the bequeath protocol?).
> >
> Because I had try to stop the listener service, and if the oracle instance
> is started, the sqlplus can connect to it, so I think the tnsname.ora is
not
> used.
> And since use connect user/password without specifing the network service
> name,
> listener service is not used is reasonably, I think without the network
> service name,
> only bequeath protocol can be used. Also in my impression there are some
> error using bequeath protocol connection in sqlnet.log, I think the error
> may be
> produced the this opeation( I were no sure then, I am a newby for oracle).
>
> Now I have found the error message created by the operation:
>
> /***********************
> Fatal NI connect error 12560, connecting to:
>
>

(DESCRIPTION=(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=oracle)(ARGV0=oraclehappy)(ARGS
>

='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))'))(CONNECT_DATA=(SID=hap
>

py)(CID=(PROGRAM=F:\oracle\ora81\bin\SQLPLUS.EXE)(HOST=PANTAO)(USER=Administ
> rator))))
>
> VERSION INFORMATION:
> TNS for 32-bit Windows: Version 8.1.7.0.0 - Production
> Oracle Bequeath NT Protocol Adapter for 32-bit Windows: Version
8.1.7.0.0 -
> Production
> Time: 13-8月 -2002 11:16:10
> Tracing not turned on.
> Tns error struct:
> nr err code: 0
> ns main err code: 12560
> TNS-12560: TNS：协议适配器出现错误
> ns secondary err code: 0
> nt main err code: 530
> TNS-00530: 协议适配器错误
> nt secondary err code: 2
> nt OS err code: 0
>
> > > Another insteresting question is : since the instance has not been
> > started,
> > > how the
> > > username/password is verified? The sqlplus(svrmgrl) problem read the
> user
> > > table
> > > itself? It seems be so, isn't it?
> >
> > Asked and answered regularly. Privileged users (which is what the 'as
> > sysdba' means you are) are authenticated either by a password file, or
by
> > you, the machine user, having logged onto the Windows box, and thus
> acquired
> > membership of the ORA_DBA local group.
>
> Oh, it is so. So in normal case, connect to privileged users will not
> connect
> to the database instance. But in my situation, it connects to, so I think
> there may be some wrong with the privileged setting so priveleged can't be
> verified normally, and it try to connect to instance to verify it. I think
> the user sys and system can also be verify by the user table since they
> can change their password.
> And then I check the ORA_DBA local group, the user Administrator is in it.
> Oh, a little disappoint. But I think it may be the privilege problem lies
> somewhere. I will try to find.
>
> thanks a lot
> PanTao
>

Without wishing to be rude, but it is quite hard to understand what you are talking about, so I may just be misunderstanding, but you seem to be all over the place here.

If you are just starting out with Oracle, get rid of this Bequeath nonsense, and stick to TCP/IP as your protocol. The Listener needs to run for *remote* connections to the database. Whatever your protocol, it doesn't need to be running for connections as SYS on the local machine. You've got the fact that the listener bequeaths server processes to users mixed up with the bequeath protocol.

As a for example, I've just done this on my server (which uses the TCP/IP protocol for connections from clients):

C:\>lsnrctl stop
C:\>sqlplus /nolog
SQL>connect / as sysdba

connected

Naturally, if I try a connection from my workstation I get the 'No Listener' error.

If all you are trying to do is to be able to get users connected remotely without them having to specify an Instance name, then (a) that's a false economy and (b) stick with the simple stuff and get it working first, and worry about things like that later.

As for the rest of what you wrote, I'll take it a step at a time:

"So in normal case, connect to privileged users will not connect to the database instance".

What? Of course privileged users connect to an Instance, just like non-privileged users. There's just one exception: when the database is shutdown, and the privileged user seeks a connection in order to start it up, then obviously they don't connect to the Instance. They connect to the Listener, request a Server Process, and that Server Process then goes about the business of creating the Instance, mounting the database and opening the database.

"But in my situation, it connects to, so I think there may be some wrong with the privileged setting so priveleged can't be verified normally, and it try to connect to instance to verify it."

I honestly haven't a clue what you are talking about here. You mean you get a 'connected' response when you connect as a privileged user, but the database is down? Great: you've connected to the Listener, and are ready to issue the 'startup' command. If your database is down, you can't connect to an Instance, to verify anything, because there isn't one. Perfectly normal.

"I think the user sys and system can also be verify by the user table since they can change their password."

Naturally. Both SYS and SYSTEM are users with entries in the DBA_TABLES data dictionary view. So yes, they can use DATA DICTIONARY authentication. SYSTEM is NOT a privileged user, however, and can ONLY use data dictionary authentication. SYS (in 8i) can log on EITHER as a privileged user OR as an ordinary dictionary-authenticated user. To log on normally, he does 'connect sys/something'. To log on as a privileged user, he does 'connect sys/something AS SYSDBA'. The extra two words invoke the external authentication mechanisms I mentioned earlier: either a password file or a check to see if you, the NT user, are a member of the ORA_DBA group.

Have you read the concepts manual?

HJR Received on Tue Aug 13 2002 - 00:49:03 CDT