Starting dbconsole kills database

Question

Mac OS X 10.3.6, kernel patch applied, default install, blah, blah, blah. OK, I can start the database, and it runs fine. No problem. However, whenever I issue the 'emctl start dbconsole', CPU activity spikes to 100%, memory is consumed, and ultimately, all oracle processes just die. A crash reporter log is generated, indicating /bin/oracle threw a EXC_BAD_ACCESS (0x0001). Since the virtual memory drive gets tapped, I'm guessing that I'm just running out of VM swap space, but that's not really the error. I've noted several other things: after issuing the emctl start dbconsole, several 'perl' processes are started, as is the JVM. Issuing the command 'select s1.program, s1.OSUSER, s1.type, s.value from V$sesstat s, v$statname n, v$instance i, v$session s1 where s.statistic# = n.statistic# and n.name = 'CPU used by this session' and s1.SID = s.sid order by s.value desc' indicates that the program 'OMS' starts a session, and starts some work, then spawns several more times, ultimately taking lots of oracle time. Several additional 'oracle' processes are started, each trying to grab as much CPU as possible. Eventually, the database goes down. I'd love to figure out what is going on, rather than nuke the machine and start over. It appears that each of the 'OMS' sessions are issuing SQL commands. 'INSERT INTO MGMT_METRICS(...', 'begin dbms_application_info....', etc., so work is being done.
Does anyone have any ideas of what I should check first? The logs don't seem to be too much help.
-Darryl

Answer 1

I may have an answer, but I'm not certain. It appears that by default, a database is created using a dedicated server process (ie, an 'oracle' process is spawned for each connection). At some point, there are a bunch of connections that get spawned by the dbconsole startup, and ultimately, the server simply runs out of memory, both ram and swap. I've since been explicitly setting up my test boxes as shared servers, limiting the number of shared servers based on how much memory the machine has. So far, it has reduced/eliminated the problems. The annoying part of this is that I have customers that are 100% Macintosh shops, who I would really like to deploy with Oracle, but so far, Oracle support has been pretty much useless, especially on these memory consumption issues. For the price that is paid for support, you would hope that someone in there gets it.....I've mostly been gleening the forums for help, and trying to apply bits-n-pieces of that collective wisdom to the problems at hand. Such fun......
-Darryl