当前位置:首页 > 开发 > 数据库 > 正文

Oracle 10.2.0.4的一个BUG--dbspicao10

发表于: 2012-04-25   作者:aijuans   来源:转载   浏览次数:
摘要: 今天在查找相关call stack的内容时,很偶然看到一个哥们写的关于在metalink中搜索相关oracle bug中描述相关call stack的方式,可以利用这种方式对相关dump文件的call stack同样在metalink中进行搜索。查看是否是相关bug引起的。具体方式和列子如下(请注意精彩的在最后): ########################### 据库环境 Oracle

今天在查找相关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的一个BUG--dbspicao10

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
一. Bug 问题表现 2011年安装Oracle 10.2.0.4 和10.2.0.5 版本时,在配置OEM的时候会报错。 忽略这
一. Bug 问题表现 2011年安装Oracle 10.2.0.4 和10.2.0.5 版本时,在配置OEM的时候会报错。 忽略这
接上文的 windows server2008下oracle10.2.0.3安装 现在开始打补丁,升级到oracle 10.2.0.4 环境:
今天出现了一个问题,linux下root用户不能切换到oracle用户,但是能切换到其他的用户, 症状如下 [r
下面是一个用于计算,每个月从4月起各个月的记录条数统计,直到当前月 1.打开PLSQL,新建一个存储过
下面是一个用于计算,每个月从4月起各个月的记录条数统计,直到当前月 1.打开PLSQL,新建一个存储过
一:环境说明 源库: 操作系统:LINUX 32位 数据库:Oracle 10.2.0.4.0 32位 目标库: 操作系统:LI
假如有如下表,其中各个i值对应的行数是不定的 SQL> select * from t; I A D ———- ———- —
前两天接到一个工作,某网站无法访问了,重启后也一直挂在哪里,起不来。 我刚开始怀疑是程序配置问
前两天接到一个工作,某网站无法访问了,重启后也一直挂在哪里,起不来。 我刚开始怀疑是程序配置问
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号