Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: database create tool (dbca) hangs on "creating instance" 9i

Re: database create tool (dbca) hangs on "creating instance" 9i

From: Howard J. Rogers <howardjr_at_www.com>
Date: Tue, 4 Sep 2001 06:37:57 +1000
Message-ID: <3b93e91c@news.iprimus.com.au>

"buckwheat" <aceducy_at_yahoo.com> wrote in message news:xhOk7.4639$ZJ.105955_at_e3500-atl2.usenetserver.com...
> I tried that too.
> Did the install, then did a dbca/create database.
> Let it default to everything, then it hung on "creating the instance".
> Waited 30 mins, then aborted.

From my experiences just yesterday, I think you might be being a tad impatient. Give it 2 hours, and then start frothing!

> This left a process called "oracle" is still running, using about 90% cpu.
> Only way to ice it is kill -9.
> Tried this 9i install on another Sol8 machine, same results.
>
> Now I can't believe I'm the only one having this problem - oh well, back
to
> 8i
>

If I can get it running on Linux, barely knowing one end of a grep from the other, it's not an Oracle software issue. You said you checked the kernel parameters ... what did you set ALL of them to?

Another thing you can try: go to $ORACLE_HOME/dbs and copy the default init.ora to be initSID.ora (whatever your ORACLE_SID is set to, obviously). Then fire up sqlplus, and try a startup nomount. See what errors you get then (if it's the end of file on communication channel one, I'd strongly suspect your kernel parameters or a permissions problem).

One more thing: you have the right version of the JRE? And you correctly pointed to that during the install?

And finally... is this a "clean" Solaris installation, or are you shoe-horning it into a previously-used box. No telling what's been set if it's not clean, which might be a contributing issue.

> You know Oracle - you guys put buggy s/w like this on your download site.
> You do this knowning full well the *only* people that will get it going
are
> those with "gold" support, and can call in to get the fix. So why put it
> out there?

Like I say, it isn't buggy (well, this part of it isn't at any rate). It's a darned sight more tricky than a mere Windows user is used to, but I've found no need for a gold suport contract to get it working.

I guess I'm just saying that it's no good giving up at this stage: something you are doing (or not doing) is causing the problem.

In case it helps, here is what Dave Haas posted here in response to my please for help on Linux (so your paths might need to be different). I followed the steps he outlined, and it worked (though I had also to remember to set the kernel parameters first):

Quote on:



To create mount points, simply use the mkdir command, like:

mkdir -p /oracle/mnt1 /oracle/mnt2 /oracle/mnt3

The -p option simply creates the upper directories if they don't already exist (for example, the /oracle directory in the example above).

Now we would have to change the ownership of those directories (and the group as well) to the oracle user, otherwise noone but root can write to them.

chown oracle /oracle
chgrp dba /oracle

While we are on the topic of the oracle user, on Suse7.1 the Suse ppl have already created the oracle account. You don't have to do it. According to the install docs though, it says you are supposed to make the primary group for the oracle user the oinstall group, and a secondary group the dba group. That's bad advice. I would recommend switching those around:

usermod oracle -g dba -G oinstall

You probably want to change the password for the oracle account as well:

passwd oracle

So, you should have three directories plus the directory for the software (something like the following, YMMV). Make sure all are owned by oracle and the group is set to either oinstall or dba (I recommend dba, it makes the db creation cleaner. If it's not dba then the background processes have trouble writing trace files, etc)

/oracle/mnt1
/oracle/mnt2
/oracle/mnt3
/oracle/software

Log out of root and in as the oracle user. Then you set some evironment variables (in .bashrc most likely):

export ORACLE_SID=xxxx
export ORACLE_BASE=/oracle/software
export ORACLE_HOME=$ORACLE_BASE/9i

export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export PATH=$ORACLE_HOME/bin:$PATH

and then start a new terminal for them to take effect. You can also put them in .bash_profile if you want, it doesn't really matter.

Run the installer and you are off to the races.



Quote off.

Hope it helps you as much as it helped me, Regards
HJR
> Not a dang thing on technet about this either.
>
>
> "Howard J. Rogers" <howardjr_at_www.com> wrote in message
> news:3b935e49_at_news.iprimus.com.au...
> > Having just gone through much the same on Linux, I found the answer to
my
> > prayers to be to opt for a software install only, and then run dbca
> > (Database Configuration Assistant) once the install was completed.
> >
> > Worked fine.
> >
> > Perhaps if you were in control of the process there might be some better
> > indication of where it was failing.
> >
> > Just a thought.
> >
> > Regards
> > HJR
> >
> >
> > "buckwheat" <aceducy_at_yahoo.com> wrote in message
> > news:tYBk7.917$ZJ.32120_at_e3500-atl2.usenetserver.com...
> > > 9i on Sol 8. Same box ran 8i no problems. Running the
> create-a-database
> > > assistant with user "oracle".
> > >
> > > I did all the "set SEMMNI=100..." in the /etc/system file.
> > > ORACLE_HOME set correctly, in all shells.
> > > Pre-install done per the manual, as was post-install.
> > > Always hangs on "creating instance", even creating the instance is
done
> > > AFTER the creation of the DB files (like from a template).
> > >
> > > This one's got me stumped - any ideas?
> > >
> > > Thanks - Greg
> > >
> > > Sorry for xpost, unsure where it went
> > >
> > >
> > >
> >
> >
>
>
>
Received on Mon Sep 03 2001 - 15:37:57 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US