ORACLE高手请看过来，CPU使用率100% (100分)

上周装的ORACLE9.2,瞎子摸象搞了几天，真他妈不顺，遇到两个问题困饶我几天了，
到www.itpub.net翻了个底朝天，还是搞不定，希望各位虾哥虾姐指点一二，不胜感激！
1.操作系统为WINK PRO+SP2,配置为p4 1.4+DDR256M,运行OEM时独立启动没问题，登录到
Oracle Enterprise Managment Server过不了多久cpu的使用率就会达到100%，我只是通
过向导创建了一个数据库，开始在库中建了一个表没索引，最后看到别人说表没索引会
造成cpu使用率超高,于是我加索引--不行，删掉我建的表--现在只有向导创建的表，关机
后，重新启动oracle.exe的cpu使用率还是100%，我该怎么办？
2. SQL*PLUS 中连接后能对数据库select等操作！但是sqlplus WorkSheet中能正常连接，
但是无法对数据库操作，连接成功后写了一个selece语句返回如下信息：
警告: 您不再连接到 ORACLE。
在WWW.ITPUB.NET找到相同问题可是就是搞不明白，只怪自己太笨，
搞不定。

多谢各位了，除了WWW.ITPUB.NET里,还有人气比较旺的ORACLE的论坛吗？

看你的问题应该是OEM Server的问题了，你看看它的LOG文件。
这不关表及索引的事

to xianjun:
不好意思，再明白点好吗，哪一个文件？

看看sysman/log/oms.nohup
还可以看一下数据库的LOG文件： oracle/Admin/

看不出什么问题 oms.nohup 好像正常
总之云里雾里
剪了最后一段青帮忙看看
用于 Windows NT 的 OEMCTL: 版本 9.2.0.1.0 正式版
版权所有 (c) 1998, 2002, Oracle Corporation。保留所有权利。
启动 Oracle Management Server...VXA-3008 : 正在启动 OMS 服务, 请稍候。


OMS 现已启动并就绪。
*** VDD: INITIATING OMS SHUTDOWN : OMS REPOSITORY SESSION LOST ***
::: org.omg.CORBA.UNKNOWN
VXA: Doing a shutdown and restart
用于 Windows NT 的 OEMCTL: 版本 9.2.0.1.0 正式版
版权所有 (c) 1998, 2002, Oracle Corporation。保留所有权利。
启动 Oracle Management Server...VXA-3008 : 正在启动 OMS 服务, 请稍候。


OMS 现已启动并就绪。
java.lang.Throwable
at oracle.sysman.vdb.VdbUtil.addCachedResultSetInstance(VdbUtil.java:473)
at oracle.sysman.vdb.VdbCachedResultSetImpl.addInstance(VdbCachedResultSetImpl.java:240)
at oracle.sysman.vdb.VdbCachedResultSetImpl.<init>(VdbCachedResultSetImpl.java:344)
at oracle.sysman.vdb.VdbAutoCommitSession.doExecCachedQuery(VdbAutoCommitSession.java:1984)
at oracle.sysman.vdb.VdbAutoCommitSession.doExecCachedQuery(VdbAutoCommitSession.java:1964)
at oracle.sysman.vdb.VdbAutoCommitSession.doExecCachedQuery(VdbAutoCommitSession.java:1957)
at oracle.sysman.vdb.VdbAutoCommitSession.executeCachedQueryWithBindsLimited(VdbAutoCommitSession.java:1836)
at oracle.sysman.vdb.VdbAutoCommitSession.executeCachedQueryWithBinds(VdbAutoCommitSession.java:1802)
at oracle.sysman.vdb._tie_VdbCORBASession.executeCachedQueryWithBinds(_tie_VdbCORBASession.java:794)
at oracle.sysman.vdb._VdbCORBASessionImplBase._execute(_VdbCORBASessionImplBase.java:718)
at oracle.sysman.vdb._VdbCORBASessionImplBase._execute(_VdbCORBASessionImplBase.java:466)
at com.visigenic.vbroker.orb.SkeletonDelegateImpl.execute(SkeletonDelegateImpl.java:129)
at com.visigenic.vbroker.orb.GiopProtocolAdapter.doRequest(GiopProtocolAdapter.java:290)
at com.visigenic.vbroker.orb.GiopProtocolAdapter.dispatchMessage(GiopProtocolAdapter.java:462)
at com.visigenic.vbroker.orb.ThreadPoolDispatcher.run(ThreadPoolDispatcher.java:155)
at com.visigenic.vbroker.orb.WorkerThread.run(WorkerThread.java:146)
java.lang.Throwable
at oracle.sysman.vdb.VdbUtil.addCachedResultSetInstance(VdbUtil.java:473)
at oracle.sysman.vdb.VdbCachedResultSetImpl.addInstance(VdbCachedResultSetImpl.java:240)
at oracle.sysman.vdb.VdbCachedResultSetImpl.<init>(VdbCachedResultSetImpl.java:344)
at oracle.sysman.vdb.VdbAutoCommitSession.doExecCachedQuery(VdbAutoCommitSession.java:1984)
at oracle.sysman.vdb.VdbAutoCommitSession.doExecCachedQuery(VdbAutoCommitSession.java:1964)
at oracle.sysman.vdb.VdbAutoCommitSession.doExecCachedQuery(VdbAutoCommitSession.java:1957)
at oracle.sysman.vdb.VdbAutoCommitSession.executeCachedQueryLimited(VdbAutoCommitSession.java:1699)
at oracle.sysman.vdb.VdbAutoCommitSession.executeCachedQuery(VdbAutoCommitSession.java:1438)
at oracle.sysman.vdb._tie_VdbCORBASession.executeCachedQuery(_tie_VdbCORBASession.java:768)
at oracle.sysman.vdb._VdbCORBASessionImplBase._execute(_VdbCORBASessionImplBase.java:699)
at oracle.sysman.vdb._VdbCORBASessionImplBase._execute(_VdbCORBASessionImplBase.java:466)
at com.visigenic.vbroker.orb.SkeletonDelegateImpl.execute(SkeletonDelegateImpl.java:129)
at com.visigenic.vbroker.orb.GiopProtocolAdapter.doRequest(GiopProtocolAdapter.java:290)
at com.visigenic.vbroker.orb.GiopProtocolAdapter.dispatchMessage(GiopProtocolAdapter.java:462)
at com.visigenic.vbroker.orb.ThreadPoolDispatcher.run(ThreadPoolDispatcher.java:155)
at com.visigenic.vbroker.orb.WorkerThread.run(WorkerThread.java:146)
"Management server shutdown normally"

问题是不是出在这里
ora92/network/log/dbsnmp.log
...
DBSNMP for 32-bit Windows: Version 9.2.0.1.0 - Production on
17-8月 -2002 07:39:21
Copyright (c) 2002 Oracle Corporation. All rights reserved.
系统参数文件为E:/oracle/ora92/network/admin/snmp_ro.ora
写入E:/oracle/ora92/network/log/dbsnmp.log的日志信息
写入E:/oracle/ora92/network/trace/dbsnmp_864.trc的跟踪信息
跟踪级别当前为0

ora92/network/log/nmiconf.log
...
NMS-00001: 警告: dbsnmp 无法连接到 SNMP 主代理程序
DBSNMP for 32-bit Windows: release 9.2.0.0.0 - Production on 17-AUG-02 07:39:16
Discovering services on 052-06 configured on host addresses {052-06.DGLDC.NET 192.168.0.78}
Warning : Error while sourcing third party discovery file emddiscover.tcl : unable to get
value "em_loc" from key "HKEY_LOCAL_MACHINE/Software/Oracle": 系统找不到指定的文件。

应该不是这个问题，因为在我这里也没有启动，也不会出现你说的情况：
DBSNMP for 32-bit Windows: Version 9.2.0.1.0 - Production on 08-6月 -2002 15:02:20

Copyright (c) 2002 Oracle Corporation. All rights reserved.

系统参数文件为H:/oracle/ora920/network/admin/snmp_ro.ora
写入H:/oracle/ora920/network/log/dbsnmp.log的日志信息
写入H:/oracle/ora920/network/trace/dbsnmp_1408.trc的跟踪信息
跟踪级别当前为0

NMS-00001: 警告: dbsnmp 无法连接到 SNMP 主代理程序
08-6月 -2002 22:59:56: NMS-00908: 正在正常关闭

TO xianjun:
能用QQ交流吗？
我的QQ48542332

QQ用得比较少 []

ORACLE以耗费资源闻名，没十分必要的话，建议降8i
其次，你的配置是否合理！
，按我的经验是回滚段不够大，
不知道9i有没有了--rollback segment
ORACLE上手是麻烦些，但用顺了，几乎可以无人驾驶，
我从6.0用到了8.0十年,如今下岗了，
哈哈，改学DELPHI，自己创业喽。
--记得，给我一点点分，我学DELPHI时能用上。

to samboy111;
8i 好像跟P4有仇哟，不敢玩！
我现在把原来那个数据库DEL掉了另建了个数据库
TNND暂时没问题了！
真他妈搞不懂！

8i在P4上装好象要改一个文件，网上查查就知道了
不过现在9i都出到第二版了，没必要再用回8i了吧
而且9i的许多新功能不论对开发、管理都是非常好的

照这么说来，应该是你装第一个的时候哪儿出了什么问题吧。

辛苦两位了，分了吧