« SPFILE参数修改错误的解决办法 | Blog首页 | Oracle Database 11g 体系结构图下载 »
ORA-07445 数据库也会旧病复发
作者：eygle | 【转载请注出处】|【云和恩墨 领先的zData数据库一体机 | zCloud PaaS云管平台 | SQM SQL审核平台 | ZDBM 数据库备份一体机】
链接：https://www.eygle.com/archives/2008/07/again_ora_07445.html
链接：https://www.eygle.com/archives/2008/07/again_ora_07445.html
去年曾经帮助客户处理了一则ORA-07445的错误，当时客户的症状是每个月出一次07445错误，然后Down机。
主机上SUN V880，采用的双机热备的系统。第一次出现故障是在2007年6月左右。我在9月底帮助客户解决了问题。
昨天客户找到我，说数据库7月初又出现了07445错误，我摘录一下错误信息：
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x166, PC: [0x10289ce30, 000000010289CE30]
*** 2008-07-11 23:58:40.743
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [000000010289CE30] [SIGSEGV] [Address not mapped to object] [0x000000166] [] []
Current SQL information unavailable - no session.
我开玩笑说，一年了，数据库旧病复发！数据库问题不会复发么？会的，不要以为这是玩笑。
如果一个问题可能会反复出现，那它就一定会反复出现，系统会在一定周期内出问题，数据库逢节假就问题频发。
还有些上市公司，总是在出财报时出现问题，所以，墨菲定律无处不在。
上一次我在客户现场待了三天，解决问题之后稳定运行了9个月，也算是不错的业绩了，可是客户总是在问题解决之后就觉得不再需要技术人员了。这是做技术的悲哀。
-The End-
历史上的今天...
>> 2018-07-16文章:
>> 2012-07-16文章:
>> 2011-07-16文章:
>> 2007-07-16文章:
>> 2006-07-16文章:
By eygle on 2008-07-16 15:15 | Comments (11) | Case | 1975 |
还有4月1号down机日
这种客户，第二次，先收费，而且收很贵的费.
这种情况不少见,很多
人都是在需要某些资源
的时候,才觉得那种资源
重要.
在这一点上我们没必要去评论那个customer做的不对，毕竟他们还是遵循国内人的思想习惯，很少有企业会聘请一个技术人员仅仅是为了有可能发生的错误。
读了一下文中提到的墨菲定律，受益匪浅
同意楼上，从HR的角度来看，这种方式节约企业成本，而且比较灵活。
客户就是上帝，很多时候他们也不得以，而且现在很多企业实际上并不重视信息系统。
可是客户总是在问题解决之后就觉得不再需要技术人员了。这是做技术的悲哀。
------------------
偶有同感。
你好eygle:
看上面的信息在metalik里对应的是BUG，在10.2.0.4中修复。能大概说一下，你是怎么解决的吗？
大哥，能告诉下怎么解决的么？
07445 会的原因可能各不相同，我这个案例是由于内存使用越界导致的。
你说的这个案例是内存使用越界导致，是不是在报07445的问题前，日志中就有报类似：在尝试分配XXX字节时进程内存不足这样的问题，而导致07445的问题出现？我遇到了07445的问题了，好几天了未能解决。