关于oracle的稳定性

Question

做压力测试一般是要测出系统的最大负载能力和健壮性，crash是正常的。没有crash说明没有测试工作没有做到位。另外估算一下系统的tpmc值，看看硬件的tpc指标（在tpc或者spec网站上查询）是否满足你的应用需求，如果能满足就要在性能调整上多下些功夫。

Answer 1

稳定性问题常常是不好的设计、性能不高等引起的，除非你发现了bug，否则升级补丁不能解决你的问题。

Answer 2

但我认为我们碰到的问题极有可能是oracle本身的问题,因为在oracle的log里面可以看到发生了一些内部错误,而且我觉得我们的压力还不回让oracle死掉,而且压力过后oracle也恢复不了.我想可能是本身的稳定性问题引起的.所以希望打完补丁后再看看.
而且以前我们在9i碰到同样的问题,通过打补丁后就消失了.大家有metalink帐号或者补丁发我一个,我测试完给大家报告情况.

Answer 3

下载软件不需要metalink帐号，随便注册一个都可以。

Answer 4

只有metalink里面才有补丁包的，我现在就是用在metalink外面下载的那些版本，出现很多不稳定的问题。这是oracle的log的一部份：
Mon Aug 28 06:33:46 2006
Trace dumping is performing id=[cdmp_20060828063346]
Mon Aug 28 06:38:29 2006
Restarting dead background process MMON
MMON started with pid=26, OS id=4892
Mon Aug 28 06:39:35 2006
Errors in file e:\oracle\product\10.2.0\admin\gome\bdump\gome2_mmon_4892.trc:
ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [keltfill+94] [PC:0xDED9F0] [ADDR:0x0] [UNABLE_TO_READ] []

Answer 5

ORA-07445是一个常见的错误，有两种原因：1是bug ；2是sql问题。先看看trace文件里的sql吧，10.2.0.1已经是很新的版本了.

Answer 6

出现异常错误: 核心转储 [ACCESS_VIOLATION] [keltfill+94] [PC:0xDED9F0] [ADDR:0x0] [UNABLE_TO_READ] []
关键看这个,用过C的人都知道,这是发生了非法指针错误,通常是程序本身bug造成的.

Answer 7

当然,还有很多其他的错误的,综合考虑,应该是oracle crash了.

Answer 8

至于看trace文件里面的SQL,我以前看过，不是某条，出错的时候会出现很多不同的SQL,例如这次是这条，下次是那条。还有，例如会出现伴随的ORA-00600错.此外,不要对oracle或者任何大公司有迷信,如果你去metalink查查,其实oracle crash是很多的,oracle也是承认的.不过我现在没有了 metalink帐号了,大家有没有呀?