You think that's good? Try this one...
Me
---
RedHat Linux 7.2 Oracle 9.2.0.2
dbca *always* hangs at 41% - "Creating and starting Oracle instance".
No background process ever gets started - no pmon, no smon, nothing.
This is regardless of kernel parameters, memory or any other such stuff.
Running a script to create an *identical* database works every time.
"Support"
----------
Are there any error messages reported in the database alert.log file?
Please upload alert.log file for more investigation. Thanks.
Me
---
New info : There are no messages in the alert log - except for the "shutdown
abort" after I cancel dbca. Prior to that, there is nothing. It is empty.
Support
--------
Can you please upload the alert.log file? Why do you think DBCA is hanging?
Maybe it was running catalog.sql , catproc.sql and other scripts. These
might take some time. This is normal. Can you see log files are switching in
the alert.log file before you abort?
Have you connected and checked from v$session_wait to see whether sessions
are moving or not? See <Note:68738.1> "Hang or Spin?".
column sid format 990
column seq# format 99990
column wait_time heading 'WTime' format 99990
column event format a30
column p1 format 9999999990
column p2 format 9999999990
column p3 format 9990
select sid,event,seq#,p1,p2,p3,wait_time
from V$session_wait
/
Me
---
New info : Perhaps I need to be more explicit...
Here is the *entire* alert log immediately before canceling dbca (after it
sat there motionless for over an hour):
--- Start of alert log ----
---- End of alert log -----
Here is the *entire* alert log after I cancelled dbca:
--- Start of alert log ----
Fri Feb 14 09:54:03 2003
Shutting down instance (abort)
---- End of alert log -----
Kind of ironic isn't it - saying that it is aborting an instance that never
existed?
I think that dbca is hanging because it *IS* hanging - no background
processes
*EVER* get started. (No pmon, no smon, nada... nothing.)
catalog.sql was not running. catproc.sql was not running. No other scripts
were running. One has to have an instance running before one can run any
SQL. v$session_wait is inaccessible - there are no background processes
and no instance.
It is going to be difficult to run any SQL when there are no background
processes and no instance is running.
"Support"
----------
Sorry for misunderstanding the problem. Since dbca hangs at 41% , I guessed
that instance was started. That is strange. You said that the problem does
not occur when you manually create the database using scripts. So this
should be a problem within the DBCA Java program.
I have done some search and I found followings :
<Bug:2461946>
Abstract: CREATE DATABASE HUNGS UP WHEN WE SET DISK_ASYNCH_IO TRUE
O/S: 46 Intel Based Server LINUX
Status: 95,Closed, Vendor OS Problem
The problem is identified as being OS configuration.
Workaround :
echo 1048576 >/proc/sys/fs/aio-max-size and reboot.
------------------------------
<Note:160891.1> "NETCA, DBCA, EMCA hangs and spins CPU in Oracle 9.0.1 on
RedHat Linux 7.1"
Solution:
Use JRE not JDK.
Me
---
Guessed? "No pmon, no smon, nothing" seems to indicate "no instance".
I'm using Linux 7.2, not 7.1. I have Oracle 9.2.0.2, not 9.0.1
/proc/sys/fs/aio-max-size is a problem as there is no fs aio in RH 7.2.
However, on our RH AS 2.1 machine, also with Oracle 9.2.0.2,
dbca hangs also - and aio-max-size is already 1M.
CPU was sleepy, not spinning (evidently in wash cycle).
J-R-E J-D-K ... M-O-U-S-E
Solution: Resurrect orainst /c
Please close this TAR! I can't take any more!
Thanks for your help!
----- TAR status is now SOFT CLOSED ---
-- epilog --
I realize that this was a bit sarcastic, but...
Every time I file a TAR anymore, I get this "are you sure its plugged in?"
sort of treatment. I've been tempted several times to ask them:
"If there is a CUSTOMER_IS_A_BOZO flag somewhere in your
database, could you please set it to FALSE - the default must be TRUE."
I finally just stopped using Metalink months ago because it is so entirely
useless and a huge waste of time. I thought this one might be easy
though. Evidently, I was wrong.
[It couldn't really be "a problem with the DBCA Java program" could it?
Nah! Not from a company famous for its "unbreakable" software!
And all their other Java-based GUI tools have always been flawless. ;-]
I filed a TAR about 5 months ago about a 9i bug - extremely
slow queries against v$datafile ("select name from v$datafile"). After
jumping through entirely irrelevant hoops at support's request for a month,
I just let the TAR die. Nobody was bothering to take anything I said
seriously. I had uploaded a '10046' level 8 trace on my own initiative, ran
tkprof against the query on both 8.1.7.4 (0.01 sec) and 9.2.0.2 (6.86 sec),
uploaded both the .trc and the tkprof output for both, wrote up a
detailed description of the differences (few except for time), and still
got the idiot treatment. I said it was a bug and nobody would even
consider the possibility.
For about twelve rounds, they kept saying stuff like that I couldn't expect
the query to run the same unless the hardware was identical (even after
I explained that 8.1.7.4 was running on a single 1.2 GHz PIII CPU Dell
desktop with Linux 7.2 and 256M RAM and a single IDE drive, but
9.2.0.2 was running on a dual 1.4 GHz Dell server with Linux 7.2,
4G RAM and the 9i database was alone on a Dell/EMC FC4700
array with 2 GB of cache and a bunch of 15k SCSI drives set up
with RAID 0+1 (except for redo on dedicated mirrored drives)
Or that I should consider moving redo logs off of disks with other
datafiles..
Or that the datafiles might need to be redistributed to balance I/O
(How much I/O does "select name from v$datafile" require?
Is I/O redistributi9on likely to make it 400-600 times faster?
Besides, the database and system was idle except for
me and a few background processes.)
Arrrrgh!
Guess what? It was a bug. When I later found and applied patch
#2773907, the problem disappeared entirely - the query went
from >6.5 sec to 0.01-0.02 sec. All the nonsense that support
suggested or asked for was entirely useless in solving the problem
- and I politely told them so at the time (but humored them anyway).
Don Granaman
OraSaurus on the brink...
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Thursday, February 20, 2003 2:26 PM
>
> Today I opened yet another iTar on the VERY buggy 9iAS R2 Reports Server.
>
> Below is a CLASSIC response to my report of errors being generated.
>
> "There is a Unix generic solution that you can try . Use the command like
> this :
>
> + rwclient.sh userid=mwh/*******@prod authid=orcladmin/******
> desformat=postscript
> server=repcosmora001 report=edi810ii destype=PRINTER desname=cohpfin013
> print_apunprinted=Y mode=default > /dev/null
>
> This would not display the error message on the terminal.
> Can you try this workaround and let me know whether this is okay?"
>
> So, the next time anybody gets an error message from Oracle
> simply wrap a blindfold over your eyes, send the message into
> the bit bucket, & go merrily on your way.
>
> Error? What error?
>
> UNBELIEVABLE!
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Don Granaman
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
