Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

startup pfile and connect internal problem

0 views
Skip to first unread message

byunghee shin

unread,
Jul 17, 1999, 3:00:00 AM7/17/99
to

hi all !
today, I upgrade oracle from 7.3.2. to 7.3.4 on NetWare4.11,
on the base of Oracel manual for netware, I upgrade oracle.
everything is OK but two problem.

----------------
the first,
-----------------
We usually connect internal command like below
svrmgr> connect internal

but my problem happen right after I press enter key.
oracle ask me passwd. when I use oracel 7.3.2 version, I just type
connect internal command.
oracle never ask for password before.
what should I check out for this problem ?


-------------
the Second
--------------

After upgrade oracle( same version above), I should specify databasse
pfile like below,

svrmgr>startup pfile=%oracle_home%\database\initorcl.ora

if I omit exact pfile path, oracle return error message
I never specified ini[SID].ora file before I upgrade oracle
I guess that I missed some things when I upgade...

I'm not expert in oracle.
please help !


Ben F Oliver

unread,
Jul 19, 1999, 3:00:00 AM7/19/99
to
In article <379036D6...@ditco.com>,
byunghee shin <sic...@ditco.com> wrote:

1.) Appears like your login group of DBA is no longer assigned to your login ID. Normally,
all Oracle requires from connect internal is that the uid belong to the DBA group.
There are however, ways to force a password on the connect internal but I cannot
presently recall how.

2.) To be able to startup without pfile you require two elements to be present.
a) You must have an init${ORACLE_SID}.ora file in the $ORACLE_HOME/dbs directory.
b) The environment variable ORACLE_SID must be set to the database SID.

Check these and if that doesn't fix the problem, re-post results.

Martin Haltmayer

unread,
Jul 24, 1999, 3:00:00 AM7/24/99
to Ben F Oliver
Hi,

we had a similar problem on Sun Solaris 2.5.1. Some day we were not able
to connect internally although the Solaris user id belonged to the dba
group.

Cause of the problem: as there was no additional user authentication
except the check for dba group each internal connect wrote a *.aud file
to "audit_file_dest". Because this directory was full Oracle asked for a
password. Cleaning up the directory by removing all the *.aud files did
the trick.

HTH.

Martin

0 new messages