今天在查找相关call stack的内容时，很偶然看到一个哥们写的关于在metalink中搜索相关oracle bug中描述相关call stack的方式，可以利用这种方式对相关dump文件的call stack同样在metalink中进行搜索。查看是否是相关bug引起的。具体方式和列子如下(请注意精彩的在最后)：
###########################
据库环境
Oracle Database10gEnterprise
Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/product/10.2.0
System name: HP-UX
Node name: SD7pp6
Release: B.11.31
Version: U
Machine: ia64
Instance name: gtsdb
一个数据库的UDUMP老是满，各个连接老是在进行DUMP
*** ACTION NAME:() 2009-11-19 13:20:50.978
*** MODULE NAME:(dbspicao10@SD7pp6(TNS V1-V3)) 2009-11-19 13:20:50.978
*** SERVICE NAME:(gtsdb) 2009-11-19 13:20:50.978
*** SESSION ID:(1469.12060) 2009-11-19 13:20:50.978
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+64 call ksedst1() C00000019A4AA348 ?
000000001 ?
$cold_kteinicnt1()+ call ksedst() C00000019A4AA348 ?
608 C000000000000EA5 ?
40000000032FEA00 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ?
ktsapsblk()+1408 call $cold_kteinicnt1() 9FFFFFFFFFFEE850 ?
000002000 ? 000000000 ?
9FFFFFFFFFFEE804 ?
9FFFFFFFFFFEE680 ?
000000002 ? 000000000 ?
C00000016451E014 ?
$cold_spefcifa()+30 call ktsapsblk() 9FFFFFFFFFFF19E0 ?
56 000000006 ? 000000000 ?
000000400 ? 000000000 ?
00000006B ? 000000000 ?
000000008 ?
spefmccallstd()+720 call $cold_spefcifa() 9FFFFFFFFFFF0DA0 ?
9FFFFFFF7F36E758 ?
9FFFFFFF7F36E740 ?
9FFFFFFFFFFEF2C8 ?
9FFFFFFF7F36E750 ?
C000000000000797 ?
60000000000D45D0 ?
400000000396B500 ?
pextproc()+128 call spefmccallstd() 9FFFFFFFFFFF1A40 ?
9FFFFFFFFFFF0CB0 ?
9FFFFFFFFFFF0DC0 ?
9FFFFFFFFFFEF2C8 ?
000000000 ?
peftrusted()+288 call pextproc() 9FFFFFFFFFFF1A40 ?
9FFFFFFFFFFF0CB0 ?
9FFFFFFFFFFF0DC0 ?
9FFFFFFFFFFF0D20 ?
psdexsp()+448 call peftrusted() 9FFFFFFFFFFF1A40 ?
60000000000D45D0 ?
C000000000000E22 ?
400000000396C030 ?
00001E33B ?
9FFFFFFFFFFF1AB0 ?
rpiswu2()+960 call psdexsp() 600000000004E8C0 ?
9FFFFFFFFFFEF2E0 ?
60000000000D45D0 ?
9FFFFFFFFFFEF860 ?
C000000000000EA3 ?
4000000002E3A920 ?
psdextp()+816 call rpiswu2() 9FFFFFFFFFFF0540 ?
40000000031E8110 ?
00001E22F ?
9FFFFFFFFFFEFFE0 ?
600000000004F818 ?
C000000000000FA7 ?
000000000 ?
9FFFFFFFFFFF0620 ?
pefccal()+1120 call psdextp() 600000000004F818 ?
9FFFFFFFFFFF0660 ?
9FFFFFFFFFFF0660 ?
9FFFFFFFFFFF0B90 ?
4000000001B72CC0 ?
60000000000E2700 ?
4000000001B6FD10 ?
9FFFFFFFFFFF0570 ?
pefcal()+432 call pefccal() 9FFFFFFFFFFF1A40 ?
9FFFFFFFFFFF0BB0 ?
60000000000D45D0 ?
9FFFFFFFFFFF1420 ?
C000000000000D22 ?
9FFFFFFF7F1C1850 ?
9FFFFFFFFFFF1ADC ?
9FFFFFFFFFFF0EF0 ?
pevm_FCAL()+288 call pefcal() 9FFFFFFFFFFF1A40 ?
9FFFFFFFFFFF1440 ?
60000000000D45D0 ?
9FFFFFFFFFFF19C0 ?
C000000000000715 ?
9FFFFFFFFFFF1440 ?
600000000004F818 ?
pfrinstr_FCAL()+176 call pevm_FCAL() 9FFFFFFF7F1C1848 ?
9FFFFFFFFFFF1A58 ?
60000000000D45D0 ?
pfrrun_no_tool()+19 call pfrinstr_FCAL() 9FFFFFFF7F1C1848 ?
2 C000000274E4BC4A ?
9FFFFFFF7F1C18B0 ?
pfrrun()+13376 call pfrrun_no_tool() 9FFFFFFF7F1C1848 ?
000002001 ?
9FFFFFFF7F1C18B0 ?
60000000000D45D0 ?
C00000000000099B ?
40000000030414E0 ?
9FFFFFFF7F1C1C98 ?
9FFFFFFF7F1C1910 ?
plsql_run()+1328 call pfrrun() 9FFFFFFFFFFF1B50 ?
9FFFFFFFFFFF1B40 ?
60000000000D45D0 ?
9FFFFFFFFFFF2740 ?
9FFFFFFFFFFF2740 ?
C000000000000DA2 ?
4000000002AC7390 ?
peidxr_run()+496 call plsql_run() 9FFFFFFF7F300200 ?
000000010 ?
9FFFFFFF7F320218 ?
9FFFFFFFFFFF2750 ?
60000000000D45D0 ?
9FFFFFFFFFFF3260 ?
peidxexe()+128 call peidxr_run() 9FFFFFFF7F36E028 ?
000000010 ?
9FFFFFFF7F320218 ?
9FFFFFFFFFFF3270 ?
60000000000D45D0 ?
9FFFFFFFFFFF37F0 ?
C000000000000491 ?
400000000318D060 ?
kkxdexe()+608 call peidxexe() 9FFFFFFF7F1C15F8 ?
60000000000D45D0 ?
C000000000000F26 ?
4000000003186480 ?
9FFFFFFF7F1C18C0 ?
9FFFFFFF7F1C1600 ?
9FFFFFFF7F1C1670 ?
9FFFFFFF7F1C1848 ?
kkxmpexe()+384 call kkxdexe() 9FFFFFFF7F1C15F8 ?
9FFFFFFF7F32CD10 ?
9FFFFFFF7F32CBA8 ?
60000000000D45D0 ?
C000000000000C1E ?
40000000039A1160 ?
kgmexec()+752 call kkxmpexe() 9FFFFFFFFFFF3DD0 ?
C00000000000132E ?
40000000039A14F0 ?
9FFFFFFF7F1C15F8 ?
00001854B ?
9FFFFFFF7F32CBA8 ?
9FFFFFFF7F32CD00 ?
9FFFFFFFFFFF3850 ?
evapls()+1264 call kgmexec() 600000000004E8C0 ?
000000001 ?
9FFFFFFFFFFF4420 ?
9FFFFFFFFFFF43F0 ?
C0000002525873A0 ?
600000000004F818 ?
9FFFFFFFFFFF3E90 ?
000000000 ?
evaopn2()+1056 call evapls() C000000256CC2BF8 ?
9FFFFFFFFFFF4420 ?
60000000000D45D0 ?
9FFFFFFFFFFF4A10 ?
C00000000000112A ?
4000000002E1C860 ?
00001858F ?
9FFFFFFFFFFF4430 ?
$cold_evamul()+160 call evaopn2() C000000256CC2BF8 ?
9FFFFFFFFFFF4A40 ?
60000000000D45D0 ?
9FFFFFFFFFFF5000 ?
C000000000000816 ?
4000000003753E20 ?
qesaAggNonDistSS()+ call $cold_evamul() C000000256CC2CB0 ?
896
qerhjInnerProbeHash call qesaAggNonDistSS() C00000021CEEAE00 ?
Table()+928 000007FFF ?
60000000000D45D0 ?
C000000000000A9A ?
4000000002DCFE80 ?
kdstf0000101km()+66 call qerhjInnerProbeHash 9FFFFFFFFFFF5BC0 ?
08 Table() 000007FFF ?
60000000000D45D0 ?
C000000000001838 ?
4000000002DCD740 ?
00001810B ?
9FFFFFFFFFFF5C38 ?
000000003 ?
kdsttgr()+65328 call kdstf0000101km() 9FFFFFFF7F32A9B0 ?
000000000 ?
4000000001B63850 ?
9FFFFFFFFFFF5BC0 ?
000007FFF ?
9FFFFFFFFFFF524F ?
C00000018018A044 ?
00000001B ?
qertbFetch()+3792 call kdsttgr() 9FFFFFFF7F32A9B0 ?
000000000 ?
C00000021CEEB4A0 ?
9FFFFFFF7F32A358 ?
C00000021CEEB510 ?
4000000001B63850 ?
9FFFFFFFFFFF5BC0 ?
000007FFF ?
rwsfcd()+256 call qertbFetch() 9FFFFFFFFFFF5BB0 ?
4000000002C149A0 ?
000018233 ?
9FFFFFFFFFFF5680 ?
qerhjFetch()+896 call rwsfcd() 9FFFFFFF7F32B060 ?
4000000001B63850 ?
9FFFFFFFFFFF5BC0 ?
000007FFF ?
60000000000D45D0 ?
qergsFetch()+864 call qerhjFetch() C00000021CEEB068 ?
4000000001B8B400 ?
C00000021CEEAE00 ?
000007FFF ?
60000000000D45D0 ?
C000000000000EA5 ?
4000000002F36050 ?
000018271 ?
opifch2()+9632 call qergsFetch() C00000021CEEAE00 ?
4000000001B931D0 ?
9FFFFFFFFFFF5E70 ?
000000002 ?
60000000000D45D0 ?
C000000000001F46 ?
4000000002E19320 ?
000018333 ?
opiefn0()+672 call opifch2() 9FFFFFFFFFFF6E30 ?
40000000030445A0 ?
000010217 ?
9FFFFFFFFFFF5CE0 ?
60000000000D45D0 ?
C000000000000F26 ?
600000000004E8C0 ?
040002D89 ?
kpoal8()+10256 call opiefn0() C0000000000015B3 ?
9FFFFFFF7F3B190A ?
9FFFFFFFFFFF6E88 ?
9FFFFFFFFFFF6F90 ?
9FFFFFFFFFFF6F70 ?
9FFFFFFFFFFF6F74 ?
000000005 ? 000000020 ?
opiodr()+2128 call kpoal8() 9FFFFFFFFFFF7650 ?
C000000000001530 ?
000000000 ?
9FFFFFFFFFFF6F70 ?
60000000000D45D0 ?
9FFFFFFF7F3C3758 ?
ttcpip()+1680 call opiodr() 00000005E ? 000000017 ?
4000000001AAB0F0 ?
0000046B0 ?
9FFFFFFFFFFF7660 ?
opitsk()+2336 call ttcpip() 600000000005A4C0 ?
000000001 ?
9FFFFFFFFFFF9D30 ?
000000001 ?
9FFFFFFFFFFF9EA0 ?
9FFFFFFFFFFF9C94 ?
4000000001B90E90 ?
000000000 ?
opiino()+1840 call opitsk() 000000000 ? 000000000 ?
60000000000D45D0 ?
400000000279B470 ?
0000180CD ?
4000000001AAB108 ?
opiodr()+2128 call opiino() 00000003C ?
9FFFFFFFFFFFC6F0 ?
9FFFFFFFFFFFEE90 ?
9FFFFFFFFFFFBBB0 ?
60000000000D45D0 ?
C000000000001530 ?
opidrv()+1088 call opiodr() 00000003C ? 000000004 ?
4000000001AAABA0 ?
0000046B0 ?
9FFFFFFFFFFFC700 ?
60000000000D45D0 ?
sou2o()+336 call opidrv() 00000003C ?
9FFFFFFFFFFFEE90 ?
60000000000E24E0 ?
opimai_real()+224 call sou2o() 9FFFFFFFFFFFEEB0 ?
00000003C ? 000000004 ?
9FFFFFFFFFFFEE90 ?
main()+368 call opimai_real() 000000000 ?
9FFFFFFFFFFFEEE0 ?
main_opd_entry()+80 call main() 000000002 ?
9FFFFFFFFFFFF390 ?
60000000000D45D0 ?
C000000000000004 ?
alert日志无任何报错信息。这个时候，就只有借助伟大的metalink
metalink有个习惯，就是很多BUG，都会把错误的函数链用这样的方式列出来ksedst <- $cold_kteinicnt1 <- 608 <- ktsapsblk <- $cold_spefcifa
由于这个DUMP有其调用的函数方法名Call Stack，于是就用这个到metalink去搜
搜索 ksedst $cold_kteinicnt1 ktsapsblk $cold_spefcifa
接可以查到BUG信息了 Trace files generated on by dbspicao module after upgrade to 10.2.0.4 [ID 741820.1]
Applies to:
OracleServer-
Enterprise Edition - Version: 10.2.0.4 to 10.2.0.4
This problem can occur on any platform.
Symptoms
After upgrade to 10.2.0.4, huge trace files are generated in udump directory without any error message in alert.log. These trace files can be generated periodically every 10-15 minutes, or another period.
They don't contain any error message, but have the following call stack:
ksedst <- $cold_kteinicnt1 <- 608 <- ktsapsblk <- $cold_spefcifa
<- spefmccallstd <- pextproc <- peftrusted <- psdexsp <- rpiswu2
<- psdextp <- pefccal <- pefcal <- pevm_FCAL <- pfrinstr_FCAL
<- pfrrun_no_tool <- pfrrun <- plsql_run <- peidxr_run <- peidxexe
<- kkxdexe <- kkxmpexe <- kgmexwi <- kgmexec <- evapls
<- evaopn2 <- $cold_evamul <- qesaAggNonDistSS <- 896 <- qerhjWalkHashBucket
<- qerhjInnerProbeHash <- Table <- kdstf0000101km <- kdsttgr <- qertbFetch
<- rwsfcd <- qerhjFetch <- qergsFetch <- opifch2 <- opiefn0
<- opiefn <- opiodr <- ttcpip <- opitsk <- opiino
<- opiodr <- opidrv <- sou2o <- opimai_real <- main
<- main_opd_entry
The module that generates them is dbspicao.
分享到：
相关推荐
Oracle 10.2.0.4 X64是一个针对64位操作系统的数据库服务器版本。这个版本在Oracle数据库的10g系列中是相对稳定和广泛使用的，它提供了多种功能和服务，对于需要处理大量数据的企业级应用尤其适用。下面我们将深入...
oracle 10.2.0.4安装包 windows
Oracle 10.2.0.4 是一个补丁程序，旨在解决 Oracle 10.2.0.1 中的一些问题和bug。这个补丁程序带来了许多新的特性和改进，例如改进的性能、安全性和稳定性。 在升级之前，我们需要停止相关的应用程序和服务，包括...
Oracle 10.2.0.4 X64客户端是一个专为64位操作系统设计的数据库连接工具，它提供了对Oracle数据库服务器的访问能力。Oracle 10g是Oracle公司的一个重要版本，它在功能、性能和管理方面都有显著提升。这个64位客户端...
oracle linux 10.2.0.4安装包
"10.2.0.4"是Oracle数据库的一个特定版本，表示这是Oracle Database 10g Release 2的第4次修正版。这个版本可能包含了一些性能优化、新功能以及对之前版本中已知问题的修复。使用这个版本的Instant Client和SQL*Plus...
Oracle10.2.0.4 服务器,客户端office2010 在 windows server 2008 64 下安装 压缩包内容: oraparam.ini refhost.xml mini-KMS_Activator_v1.3_Office2010_VL_ENG.exe oracle10.2.0.4在win2008 64 下安装.docx(图解)
标题中的“instantclient-basiclite-win32-10.2.0.4.zip”是一个Oracle Instant Client的基础轻量级版本，适用于32位Windows操作系统。这个压缩包包含了运行Oracle数据库应用程序所需的一些基本组件，主要用于连接到...
本文档旨在提供一个详细的步骤指南，用于将Oracle RAC (Real Application Clusters) 数据库从10.2.0.1版本升级至10.2.0.4版本的过程。此升级过程非常重要，因为它涉及到关键的生产数据库系统的更新，因此必须在业务...
### Oracle 10.2.0.4 RAC 安装文档知识点总结 #### 一、基础环境准备 **1.1 主机名与操作系统设置** - **操作系统**: 使用AIX 5.3版本，确保包含必要的bundles和filesets，并且语言环境中包含中文语言包。 - **...
### Windows Server 2003 上安装 Oracle 10g (10.2.0.1) 并升级至补丁 (10.2.0.4) #### 图解第一部分：安装 Oracle 10.2.0.1 **1. 选择安装方法** 在安装过程中首先会提示用户选择安装方法，这一步主要是为了确认...
包含oracle11.2.0.4_x86-64位linux版本全套安装包： p13390677_112040_Linux-x86-64_1of7.zip p13390677_112040_Linux-x86-64_2of7.zip p13390677_112040_Linux-x86-64_3of7.zip p13390677_112040_Linux-x86-64_4of7...
Redhat linux5.6下Oracle 10g （10.2.0.1）安装及升级到10.2.0.4
在Window 7 64位操作系统上安装Oracle 10g 及 配置PLSQL Developer 8.0.时将用到它，详情请看我的博客http://blog.csdn.net/youqishini/article/details/7014532
1. Oracle数据库版本升级概念：Oracle数据库版本升级是指将当前使用的Oracle数据库软件从一个较旧的版本升级到较新的版本。Oracle数据库的版本通常由四个数字组成，例如**.*.*.*，其中第一个数字代表主版本号，第二...
【Oracle 10G 升级至 10.2.0.4 步骤详解】 Oracle 数据库的升级是一个重要的任务，确保系统的稳定性和兼容性。本文将详细阐述如何将 Oracle 10G 从早期版本升级到 10.2.0.4 版本，包括单实例环境下的补丁安装和...
升级Oracle RAC从10.2.0.1至10.2.0.4是一项复杂但必要的任务，旨在提高系统性能、稳定性和安全性。遵循上述指南，结合详细的规划和谨慎的操作，可以有效地完成升级，同时最小化对业务的影响。在整个过程中，保持与...
Oracle 10.2.0.4 EM证书过期补丁p8350262_10204_Generic是针对Oracle Database 10g Release 2（10.2.0.4）版本的Enterprise Manager (EM) 系统的一个关键更新。这个补丁解决了一个重要的安全问题，即EM证书过期的...