ORA-xxxxx – 第9页 – Database SOS

dbca创建数据库报ORA-00443

今天早上一个朋友和我说他们RAC dbca创建库不成功提示ORA-00443错误,让我帮他们分析下是什么原因导致
提示错误如图

环境状况

OS:LINUX REDHAT x86_64  5.7
kernel:2.6.18-194.el5
memory:100G
CPU:ntel(R) Xeon(R) CPU E7- 8837  @ 2.67GHz   *  64
ORACLE:10.2.0.4

查看alert日志错误

Wed Sep  5 01:32:33 2012
cluster interconnect IPC version:Oracle UDP/IP (generic)
IPC Vendor 1 proto 2
PMON started with pid=2, OS id=17859
DIAG started with pid=7, OS id=17861
PSP0 started with pid=12, OS id=17863
LMON started with pid=17, OS id=17865
LMD0 started with pid=22, OS id=17867
MMAN started with pid=27, OS id=17869
DBW0 started with pid=32, OS id=17871
Wed Sep  5 01:32:33 2012
Errors in file /u01/app/oracle/admin/dtjcdb/bdump/dtjcdb1_ora_17873.trc:
ORA-00600: internal error code, arguments: [ksbmoveme4], [], [], [], [], [], [], []
ORA-27300: OS system dependent operation:run on node failed with status: 2
ORA-27301: OS failure message: No such file or directory
ORA-27302: failure occurred at: skgpmoveme:1
Wed Sep  5 01:32:34 2012
Trace dumping is performing id=[cdmp_20120905013234]
Wed Sep  5 01:32:34 2012
Process DBW1 died, see its trace file
USER: terminating instance due to error 443
Instance terminated by USER, pid = 17857

trace文件中内容

*** 2012-09-05 01:32:33.996
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ksbmoveme4], [], [], [], [], [], [], []
ORA-27300: OS system dependent operation:run on node failed with status: 2
ORA-27301: OS failure message: No such file or directory
ORA-27302: failure occurred at: skgpmoveme:1
Current SQL information unavailable - no session.
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFFC4ABA4C0 ? 7FFFC4ABA520 ?
                                                   7FFFC4ABA460 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7FFFC4ABA4C0 ? 7FFFC4ABA520 ?
                                                   7FFFC4ABA460 ? 000000000 ?
ksfdmp()+21          call     ksedmp()             000000003 ? 000000001 ?
                                                   7FFFC4ABA4C0 ? 7FFFC4ABA520 ?
                                                   7FFFC4ABA460 ? 000000000 ?
kgerinv()+161        call     ksfdmp()             000000003 ? 000000001 ?
                                                   7FFFC4ABA4C0 ? 7FFFC4ABA520 ?
                                                   7FFFC4ABA460 ? 000000000 ?
kgesinv()+33         call     kgerinv()            0068966E0 ? 000000000 ?
                                                   7FFFC4ABA520 ? 7FFFC4ABA460 ?
                                                   000000000 ? 000000000 ?
ksesin()+211         call     kgesinv()            0068966E0 ? 000000000 ?
                                                   7FFFC4ABA520 ? 7FFFC4ABA460 ?
                                                   000000000 ? 000000000 ?
ksbmoveme()+350      call     ksesin()             00533D5C8 ? 000000000 ?
                                                   006896FA3 ? 000000001 ?
                                                   000000001 ? 000000000 ?
ksosp_set_current()  call     ksbmoveme()          000000001 ? 000000000 ?
+117                                               006896FA3 ? 000000001 ?
                                                   000000001 ? 000000000 ?
kso_init()+161       call     ksosp_set_current()  151056D10 ? 000000000 ?
                                                   006896FA3 ? 000000001 ?
                                                   000000001 ? 000000000 ?
opirip()+523         call     kso_init()           151056D10 ? 000000000 ?
                                                   006896FA3 ? 000000001 ?
                                                   000000001 ? 000000000 ?
opidrv()+582         call     opirip()             000000032 ? 000000004 ?
                                                   7FFFC4ABC128 ? 000000001 ?
                                                   000000001 ? 000000000 ?
sou2o()+114          call     opidrv()             000000032 ? 000000004 ?
                                                   7FFFC4ABC128 ? 000000001 ?
                                                   000000001 ? 000000000 ?
opimai_real()+317    call     sou2o()              7FFFC4ABC100 ? 000000032 ?
                                                   000000004 ? 7FFFC4ABC128 ?
                                                   000000001 ? 000000000 ?
main()+116           call     opimai_real()        000000003 ? 7FFFC4ABC190 ?
                                                   000000004 ? 7FFFC4ABC128 ?
                                                   000000001 ? 000000000 ?
__libc_start_main()  call     main()               000000003 ? 7FFFC4ABC190 ?
+244                                               000000004 ? 7FFFC4ABC128 ?
                                                   000000001 ? 000000000 ?
_start()+41          call     __libc_start_main()  000723088 ? 000000001 ?
                                                   7FFFC4ABC2E8 ? 000000000 ?
                                                   000000001 ? 000000003 ?
--------------------- Binary Stack Dump ---------------------

通过查询MOS发现[ID 422908.1]有类此的错误提示,但是该提示说是因为系统重新增加了过多CPU导致数据库crashed掉并且出现 ORA-27300 ORA-27301 ORA-27302 错误.在该案例中,起始就是64c,根据经验在win的10.2.0.4中如果cpu超过32c也是在dbcd创建数据库2%的地方hang住,所以怀疑该错误也是由于cpu太多导致.

处理方法

To solve the problem:
1) apply patch:6471079
- or -
2) apply the 10.2.0.5 (when available)
- or -
3) upgrade to 11g

朋友打上patch:6471079,dbca正常建库

双机mount数据库出现ORA-00600[kccsbck_first]

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：双机mount数据库出现ORA-00600[kccsbck_first]

一朋友的数据库在做数据库恢复的时候,数据库不能启动到mount状态,检查发现
alert日志错误如下

Mon Aug 27 10:00:18 2012
ALTER DATABASE   MOUNT
Mon Aug 27 10:00:23 2012
Errors in file /oracle/admin/wf2009/udump/orcl_ora_7042.trc:
ORA-00600: internal error code, arguments: [kccsbck_first], [1], [1208656276], [], [], [], [], []
Mon Aug 27 10:00:23 2012
ORA-600 signalled during: ALTER DATABASE   MOUNT...

查询mos发现解释

The ORA-600 [kccsbck_first] error occurs when Oracle detects that another instance
has this database already mounted. For some reason, Oracle already sees a thread
with a heartbeat. This could be the expected behaviour if running OPS. In such a
case the parallel_server parameter needs to be set. In cases where Parallel Server
is not linked in, this is not the expected behaviour.

在非集群环境中,当该数据库已经在一个节点启动,然后另外一个节点再尝试启动数据库可能出现该错误.
检查环境发现是使用roseha的双机环境,当关闭当前节点的数据库时候,另外一个节点认为oracle down掉了,然后自动在该节点去尝试启动数据库,而当前操作节点去尝试mount数据库的时候发生该错误,因为该数据库的另外一个节点已经mount了.出现这样的情况,和朋友的存储资源的配置也有不合理之处,在接管资源之前,应该先分析和处理存储的挂载情况,而不是不卸载这边,另外一遍直接挂载(也就是存储两边都挂载)

解决办法
这个问题的本质就是因为ha的两边都启动了数据库导致,关闭一边的roseha或者关闭主机就可以了
在做数据库恢复的时候,尽量排查掉其他因素的影响,比如:rac在一个节点上操作,ha关闭双机软件等

ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log

数据库alert日志出现如下错误

Fatal NI connect error 12537, connecting to:
 (LOCAL=NO)
  VERSION INFORMATION:
        TNS for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
        TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
        Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
  Time: 21-AUG-2012 09:50:15
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12537
TNS-12537: TNS:connection closed
    ns secondary err code: 12560
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
opiodr aborting process unknown ospid (15204768) as a result of ORA-609

错误的原因

The ORA-609 error is thrown when a client connection of any kind failed to complete or
aborted the connection process before the connection/authentication process was complete.
Very often, this connection abort is due to a timeout.  Beginning with 10gR2, a default value for
inbound connect timeout has been set at 60 seconds.
This time limit is often inadequate for the entire connection process to complete.
We have also discovered that the ORA-609 occurs frequently in installations
where the database is monitored by DB Console and the Enterprise Manager agent (emagent).
After the DB Console is started and as a matter of routine, the emagent will repeatedly try to
connect to the target instances.
We can see frequent emagent connections in the listener.log without error.
However, on occasion it may have failed to complete the connection process at the database so an ORA-609 is thrown.
The emagent will simply retry the connection and may be successful on the subsequent try.
(Provided there is no real fault occurring at the listener or database).
This temporary failure to connect will not be reported back to DB Console and there will be no indication,
 except for the ORA-609, that a fault occurred.

出现这个问题的主要原因是因为从10.2开始inbound connect timeout默认为60 seconds,而在很多建立连接过程可能超过这个时间从而出现类此错误,常见的诱因是DB Console 和 Enterprise Manager agent (emagent). EM会重复的尝试连接到数据库。其过程中会偶尔的出现连接超时的问题，但是接下来会继续尝试，并获得成功。这种临时的失败不会导致EM报错而只会以ora-609的形式记录在alert log中.

处理方法

For that reason, we often recommend increasing the values for INBOUND_CONNECT_TIMEOUT at both listener
and server side sqlnet.ora file as a preventive measure.
If the problem  is due to connection timeouts, an increase in the following parameters should eliminate
or reduce the occurrence of the ORA-609s.
e.g.
Sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180
Listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=120
These settings are in seconds.  Again, the default is 60.

问题跟踪方法

If the issue persists and inbound connect does not have any effect, the following steps are intended to
help locate  the client that may be causing the errors.
1)  Suppress the TNS errors in the alert.log by setting the following listener.ora file parameter:
DIAG_ADR_ENABLED_listener_name=OFF
This will cause the TNS errors to be posted to the ORACLE_HOME/network/log/sqlnet.log file that is
local to the database and
may yield useful information about the client's address.
For example, here's a snippet from a server side sqlnet.log where client address info was posted:
Production Time: 15-FEB-2010 07:15:01
Fatal NI connect error 12537, connecting to:
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=yourhost)(Port=1521))(CONNECT_DATA=(SID=PROD1DR)
(CID=(PROGRAM=sqlplus)(HOST=client_host)(USER=client))))
Observe the PROGRAM and HOST fields on the last line.  This is where the connection originated.
Be sure to match timestamps in the sqlnet.log with the timestamps of the alert.log errors.
Once you've located the offending client,
you can enable client tracing to try and determine the cause:
TRACE_LEVEL_CLIENT=16
TRACE_DIRECTORY_CLIENT=<dir location>
TRACE_TIMESTAMP_CLIENT=TRUE
DIAG_ADR_ENABLED=off   <<<<<11g or newer client requirement
If you need assistance with client or server tracing, please open an SR with Global Customer Support.
2)  Check the listener.log for client connections that were logged at timestamps that match the ORA-609
timestamps as they appear in the alert.log.
The client information is recorded in each listener.log entry.
Since this error occurs AFTER the listener has handled the connection,
do not expect to see errors in the listener.log.
Here's an example snippet of an incoming client connection that was posted to the listener.log:
20-JAN-2009 17:08:45 (CONNECT_DATA=(SID=orcl)(CID=
(PROGRAM=D:\oracle\product\10.1.0\Db_1\perl\5.6.1\bin\MSWin32-x86\perl.exe)(HOST=myclient)
Note that the exact timestamp, program name and client host will often be recorded.  Again,
once you've located the offending client,
enable tracing (see above) to try to capture the connection failure.
3)  Enable server side Oracle Net tracing and capture the TNS error along with the incoming connection.
Match the PID that accompanies the ORA-609 to the server trace label.  e.g.
ORA-609 : opiodr aborting process unknown ospid (4799_1)  *Note the PID
This PID would correspond to server trace labeled:  svr_4799.trc.  Check the server trace for either
TNS error (the 609 will not appear)
and try to locate the originating client address.  If assistance is needed for this investigation,
please open an SR with Oracle Support.
See below for instuctions on enabling Oracle Net server tracing.
The following details the discovery of the source of an ORA-609 for a real case:
The alert.log reports the following messages intermittently but frequently:
Mon Nov 16 22:39:22 2009
ORA-609 : opiodr aborting process unknown ospid (nnnn)
Enabled Oracle Net server tracing:
TRACE_LEVEL_SERVER=16
TRACE_DIRECTORY_SERVER=<dir location>
TRACE_TIMESTAMP_SERVER=TRUE
DIAG_ADR_ENABLED=off
Reloaded listener and wait for error to appear again.:
ORA-609 : opiodr aborting process unknown ospid (5233_1)
Note that the server trace file set that corresponded to this event was named svr_5233*.trc.
Of course the timestamps of the alert.log event and the server trace creation matched as well.
A review of the server trace showed only an EOF failure and the  TNS-12537 error:
Read unexpected EOF ERROR
nserror: nsres: id=0, op=68, ns=12537
In this particular case, there was no information about the client in the trace.
This is atypical for a server trace.
It may be that the client aborted before all the client information was posted to the file.
However, there was post in the listener.log f
or an emagent connection that was established at the same point in time.
Here's an excerpt from a listener.log entry where an emagent establishes a connection:
PROGRAM=D:\oracle\product\10.1.0\Db_1\bin\emagent.exe)
Checked the EM Agent traces and logs and discovered the following entry:
Fatal NI connect error 12547, connecting to:
(LOCAL=NO)
VERSION INFORMATION:
TNS for Solaris: Version 11.1.0.7.0 - Production
Oracle Bequeath NT Protocol Adapter for Solaris: Version 11.1.0.7.0 - Production
TCP/IP NT Protocol Adapter for Solaris: Version 11.1.0.7.0 - Production
Time: 16-NOV-2009 22:39:22
****Tracing to file: /backup/sid_traces/sqlnetlog/svr_5233.trc
Tns error struct:
ns main err code: 12547
TNS-12547: TNS:lost contact
ns secondary err code: 12560
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
****Note the name of the server trace which contains the PID:  svr_5233.trc
Also, the timestamp of the agent event matches the timestamp of the alert.log error.
Check the following locations for EM Agent traces. If working with support on this issue and
the EM Agent is suspected, upload ALL files under:
$ORACLE_HOME/sysman/log/emagent.trc < Single node agent trace location
$ORACLE_HOME/host/sysman/log/emagent.trc < RAC agent trace location
It was determined that in this case, the emagent was aborting the connection
before it was complete and then simply reconnecting
and succeeding on the subsequent try.  No errors were reported in the listener log or listener trace.
No errors were returned to the DB Console.
There was no apparent outage of any kind.  No action was taken to correct the ORA-609 in this case.
It was decided that the message was informational and completely benign.

参考文档：
ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log (Doc ID 1116960.1)
Troubleshooting Guide ORA-609 : Opiodr aborting process unknown ospid (Doc ID 1121357.1)

创建控制文件遭遇ORA-00600[3753]故障解决

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：创建控制文件遭遇ORA-00600[3753]故障解决

一位网友的数据库正常关闭,然后控制文件意外丢失,需要通过trace中的信息重建控制文件,但是在重建的过程中,出现ORA-00600[3753]错误,远程帮忙处理,记录处理过程如下
1.启动数据库至nomount状态,然后尝试noresetlogs模式重建控制文件

SQL>@XFF_NORESETLOGS_CTL.sql
CREATE CONTROLFILE REUSE DATABASE "ORA10G" NORESETLOGS  ARCHIVELOG
*
第 1 行出现错误:
ORA-01503: CREATE CONTROLFILE 失败
ORA-00600: 内部错误代码, 参数: [3753], [3], [2], [], [], [], [], []

2.检查alert日志

Tue Aug 07 20:40:47 2012
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Tue Aug 07 20:40:48 2012
Errors in file d:\oracle\product\10.2.0\db_1\admin\ora10g\udump\ora10g_ora_11596.trc:
ORA-00600: 内部错误代码, 参数: [3753], [3], [2], [], [], [], [], []
Tue Aug 07 20:40:53 2012
Errors in file d:\oracle\product\10.2.0\db_1\admin\ora10g\udump\ora10g_ora_11596.trc:
ORA-00600: 内部错误代码, 参数: [3753], [3], [2], [], [], [], [], []
ORA-1503 signalled during: CREATE CONTROLFILE REUSE DATABASE "ORA10G" NORESETLOGS  ARCHIVELOG

3.分析trace文件

Tue Aug 07 20:40:48 2012
ORACLE V10.2.0.1.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Windows NT Version V6.1 Service Pack 1
CPU                 : 2 - type 586, 2 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:166M/1901M, Ph+PgF:619M/5536M, VA:812M/2047M
Instance name: ora10g
Redo thread mounted by this instance: 0 <none>
Oracle process number: 16
Windows thread id: 11596, image: ORACLE.EXE (SHAD)
*** SERVICE NAME:() 2012-08-07 20:40:48.413
*** SESSION ID:(158.7) 2012-08-07 20:40:48.413
*** 2012-08-07 20:40:48.413
ksedmp: internal or fatal error
ORA-00600: 内部错误代码, 参数: [3753], [3], [2], [], [], [], [], []
Current SQL statement for this session:
CREATE CONTROLFILE REUSE DATABASE "ORA10G" NORESETLOGS  ARCHIVELOG
…………
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
_ksedst+38           CALLrel  _ksedst1+0           0 1
_ksedmp+898          CALLrel  _ksedst+0            0
_ksfdmp+14           CALLrel  _ksedmp+0            3
603A816A             CALLreg  00000000             87CF110 3
603A83FF             CALLrel  603A80D8             87CF110 8191090 EA9 2 8CCC438
_ksesic2+59          CALLrel  _kgesiv+0            87CF110 8191090 EA9 2 8CCC438
                                                   EA9 2 8CCC438
__VInfreq__kctbce+1  CALLrel  _ksesic2+0           EA9 0 3 0 0 2 0
63
_kcfccfl+356         CALLrel  _kctbce+0            543414C 81DB8A8
_cdbdrv+1037         CALLrel  _kcfccfl+0           543414C 1 8CCD060 8CCD04C
                                                   19000 3
_opiexe+11999        CALLrel  _cdbdrv+0            1
_opiosq0+6088        CALLrel  _opiexe+0            4 0 8CCD894
_kpooprx+232         CALLrel  _opiosq0+0           3 E 8CCD9AC A4
_kpoal8+775          CALLrel  _kpooprx+0           8CCF6CC 8196414 A16 1 0 A4
_opiodr+1099         CALLreg  00000000             5E 17 8CCF6C8
60FEFF8D             CALLreg  00000000             5E 17 8CCF6C8 0
_opitsk+1017         CALL???  00000000
_opiino+1087         CALLrel  _opitsk+0            0 0
_opiodr+1099         CALLreg  00000000             3C 4 8CCFC60
_opidrv+819          CALLrel  _opiodr+0            3C 4 8CCFC60 0
_sou2o+45            CALLrel  _opidrv+0            3C 4 8CCFC60
_opimai_real+112     CALLrel  _sou2o+0             8CCFC54 3C 4 8CCFC60
_opimai+92           CALLrel  _opimai_real+0       2 8CCFC8C
_OracleThreadStart@  CALLrel  _opimai+0
4+708
__pRawDllMain+10931  CALLptr  00000000
2903
__pRawDllMain+12925  CALLreg  00000000
4809
__pRawDllMain+12925  CALLrel  __pRawDllMain+12925
4761                          4772
--------------------- Binary Stack Dump ---------------------
    ----------------------------------------
    SO: 4FB3DF5C, type: 4, owner: 4FA4CBFC, flag: INIT/-/-/0x00
    (session) sid: 158 trans: 4EBB8954, creator: 4FA4CBFC, flag: (41) USR/- BSY/-/-/-/-/-
              DID: 0000-0010-0000000A, short-term DID: 0000-0000-00000000
              txn branch: 00000000
              oct: 0, prv: 0, sql: 00000000, psql: 4F707298, user: 0/SYS
    O/S info: user: superv06-PC\superv06, term: SUPERV06-PC, ospid: 7788:11636, machine: WORKGROUP\SUPERV06-PC
              program: sqlplus.exe
    application name: sqlplus.exe, hash value=0
    last wait for 'log file sequential read' blocking sess=0x00000000 seq=31
    wait_time=159 seconds since wait started=0
                log#=0, block#=1, blocks=1
    Dumping Session Wait History
     for 'log file sequential read' count=1 wait_time=159
                log#=0, block#=1, blocks=1
     for 'log file sequential read' count=1 wait_time=502
                log#=0, block#=1, blocks=1
     for 'log file sequential read' count=1 wait_time=163
                log#=0, block#=1, blocks=1
     for 'db file sequential read' count=1 wait_time=18840
                file#=ffffffff, block#=1, blocks=1
     for 'db file sequential read' count=1 wait_time=254
                file#=ffffffff, block#=1, blocks=1
     for 'db file sequential read' count=1 wait_time=7654
                file#=ffffffff, block#=1, blocks=1
     for 'db file sequential read' count=1 wait_time=150
                file#=ffffffff, block#=1, blocks=1
     for 'db file sequential read' count=1 wait_time=102
                file#=ffffffff, block#=1, blocks=1
     for 'db file sequential read' count=1 wait_time=123
                file#=ffffffff, block#=1, blocks=1
     for 'db file sequential read' count=1 wait_time=14010
                file#=ffffffff, block#=1, blocks=1

通过这里我们发现创建控制文件的进程在读取redo log的时候出现了等待比较多而且时间比较长,而对于ORA-00600[3753]错误互联网上没有任何更多的信息.通过对于创建控制文件时候因为使用noresetlogs的分析:这种模式下需要读取redo log,所以导致等待较多,从而出现ORA-00600[3753]错误使得创建控制文件失败.因为本库是shutdown immediate关闭,所以我们完全可以通过resetlogs模式来创建控制文件,从而避免读取redo log.

4.创建resetlogs控制文件

SQL>@XFF_RESETLOGS_CTL.sql
Control file created.

5.然后不完全恢复使用resetlogs open数据库

这次的处理我也没有什么经验可以借鉴,MOS和互联网上没有该错误的任何信息,解决这个问题关键凭的是自己对于noresetlogs和resetlogs的理解.对于数据库原理的理解,对解决一些陌生问题帮助很大;在学习ORACLE过程中注重对原理的理解和消化

重现ORA-600 4000异常

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：重现ORA-600 4000异常

对于数据库恢复感兴趣的人,一定对于ORA-600[4000]这个著名的错误记忆犹新,这里通过试验重现ORA-600[4000]
查询数据库obj$.con$记录

[oracle@xifenfei ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Fri Nov 4 06:32:36 2011
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area  318767104 bytes
Fixed Size                  1219160 bytes
Variable Size              92276136 bytes
Database Buffers          218103808 bytes
Redo Buffers                7168000 bytes
Database mounted.
Database opened.
SQL> select OBJ#,dbms_rowid.rowid_relative_fno(rowid) rel_fno,
  2  dbms_rowid.rowid_block_number(rowid) block_num from obj$
  3  where name='CON$';
      OBJ#    REL_FNO  BLOCK_NUM
---------- ---------- ----------
        28          1        122
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

bbed修改数据块
根据催华的研究,当OBJ$中部分数据块中的csc和itl的scn都大于header scn的时候,数据库启动就会报ORA-600[4000]

[oracle@xifenfei ~]$ bbed listfile=list mode=edit password=blockedit
BBED: Release 2.0.0.0.0 - Limited Production on Fri Nov 4 06:47:09 2011
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> info
 File#  Name                                                        Size(blks)
 -----  ----                                                        ----------
     1  /u01/oracle/oradata/XFF/system01.dbf                                 0
     2  /u01/oracle/oradata/XFF/undotbs01.dbf                                0
     3  /u01/oracle/oradata/XFF/sysaux01.dbf                                 0
     4  /u01/oracle/oradata/XFF/users01.dbf                                  0
     5  /u01/oracle/oradata/XFF/datfttuser.dbf                               0
BBED> set block 1
        BLOCK#          1
BBED> set file 1 block 1
        FILE#           1
        BLOCK#          1
BBED>  p kcvfhckp.kcvcpscn
struct kcvcpscn, 8 bytes                    @484
   ub4 kscnbas                              @484      0x00210f97
   ub2 kscnwrp                              @488      0x0000
BBED> set block 122
        BLOCK#          122
BBED> p ktbbh
struct ktbbh, 48 bytes                      @20
   ub1 ktbbhtyp                             @20       0x01 (KDDBTDATA)
   union ktbbhsid, 4 bytes                  @24
      ub4 ktbbhsg1                          @24       0x00000012
      ub4 ktbbhod1                          @24       0x00000012
   struct ktbbhcsc, 8 bytes                 @28         <==csc(SCN of the last block cleanout)
      ub4 kscnbas                           @28       0x0020770d
      ub2 kscnwrp                           @32       0x0000
   sb2 ktbbhict                             @36       1
   ub1 ktbbhflg                             @38       0x02 (NONE)
   ub1 ktbbhfsl                             @39       0x00
   ub4 ktbbhfnx                             @40       0x00000000
   struct ktbbhitl[0], 24 bytes             @44
      struct ktbitxid, 8 bytes              @44
         ub2 kxidusn                        @44       0x0005  <==回滚段序号
         ub2 kxidslt                        @46       0x0029
         ub4 kxidsqn                        @48       0x0000029a
      struct ktbituba, 8 bytes              @52
         ub4 kubadba                        @52       0x00802381
         ub2 kubaseq                        @56       0x01f9
         ub1 kubarec                        @58       0x03
      ub2 ktbitflg                          @60       0x2001 (KTBFUPB)
      union _ktbitun, 2 bytes               @62
         sb2 _ktbitfsc                      @62       0
         ub2 _ktbitwrp                      @62       0x0000
      ub4 ktbitbas                          @64       0x0020770e <==itl commit scn
BBED> set count 16
        COUNT           16
BBED> m /x 0d772010 offset 28
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /u01/oracle/oradata/XFF/system01.dbf (1)
 Block: 122              Offsets:   28 to  60           Dba:0x0040007a
------------------------------------------------------------------------
 0d772010 00000000 01000200 00000000
 <32 bytes per line>
BBED> m /x 0e772010 offset 64
 File: /u01/oracle/oradata/XFF/system01.dbf (1)
 Block: 122              Offsets:   64 to  96           Dba:0x0040007a
------------------------------------------------------------------------
 0e772010 00016c00 ffffea00 53046903
 <32 bytes per line>
BBED> p ktbbh
struct ktbbh, 48 bytes                      @20
   ub1 ktbbhtyp                             @20       0x01 (KDDBTDATA)
   union ktbbhsid, 4 bytes                  @24
      ub4 ktbbhsg1                          @24       0x00000012
      ub4 ktbbhod1                          @24       0x00000012
   struct ktbbhcsc, 8 bytes                 @28
      ub4 kscnbas                           @28       0x1020770d
      ub2 kscnwrp                           @32       0x0000
   sb2 ktbbhict                             @36       1
   ub1 ktbbhflg                             @38       0x02 (NONE)
   ub1 ktbbhfsl                             @39       0x00
   ub4 ktbbhfnx                             @40       0x00000000
   struct ktbbhitl[0], 24 bytes             @44
      struct ktbitxid, 8 bytes              @44
         ub2 kxidusn                        @44       0x0005
         ub2 kxidslt                        @46       0x0029
         ub4 kxidsqn                        @48       0x0000029a
      struct ktbituba, 8 bytes              @52
         ub4 kubadba                        @52       0x00802381
         ub2 kubaseq                        @56       0x01f9
         ub1 kubarec                        @58       0x03
      ub2 ktbitflg                          @60       0x2001 (KTBFUPB)
      union _ktbitun, 2 bytes               @62
         sb2 _ktbitfsc                      @62       0
         ub2 _ktbitwrp                      @62       0x0000
      ub4 ktbitbas                          @64       0x1020770e
BBED> sum apply
Check value for File 1, Block 122:
current = 0xc902, required = 0xc902

启动数据库

SQL> startup
ORACLE instance started.
Total System Global Area  318767104 bytes
Fixed Size                  1219160 bytes
Variable Size              92276136 bytes
Database Buffers          218103808 bytes
Redo Buffers                7168000 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced

查看日志

Fri Nov  4 06:50:38 2011
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Fri Nov  4 06:50:38 2011
ALTER DATABASE OPEN
Fri Nov  4 06:50:38 2011
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=16, OS id=7048
Fri Nov  4 06:50:38 2011
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=17, OS id=7050
ARC1: STARTING ARCH PROCESSES
Fri Nov  4 06:50:38 2011
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
Fri Nov  4 06:50:38 2011
Thread 1 opened at log sequence 38
  Current log# 3 seq# 38 mem# 0: /u01/oracle/oradata/XFF/redo03.log
Successful open of redo thread 1
Fri Nov  4 06:50:38 2011
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Fri Nov  4 06:50:38 2011
SMON: enabling cache recovery
Fri Nov  4 06:50:38 2011
ARC2: Archival started
ARC1: STARTING ARCH PROCESSES COMPLETE
ARC1: Becoming the heartbeat ARCH
ARC2 started with pid=18, OS id=7052
Fri Nov  4 06:50:38 2011
Errors in file /u01/oracle/admin/XFF/udump/xff_ora_7046.trc:
ORA-00600: internal error code, arguments: [4000], [5], [], [], [], [], [], []
Fri Nov  4 06:50:40 2011
Errors in file /u01/oracle/admin/XFF/udump/xff_ora_7046.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [5], [], [], [], [], [], []
Fri Nov  4 06:50:40 2011
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 7046
ORA-1092 signalled during: ALTER DATABASE OPEN...

在ORACL 11.2的版本中,同样的方法无法重新该错误,数据库依然能够正常打开,所以如果要测试的朋友请选择11G以下版本进行.

TOAD导致ORA-00600[17281]

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：TOAD导致ORA-00600[17281]

alert日志报ORA-00600[17281]

Thu Aug  2 01:49:39 2012
Errors in file /oracle9/app/admin/acc/udump/acc2_ora_647350.trc:
ORA-00600: internal error code, arguments: [17281], [1001], [0x7000007AB9F0A30], [], [], [], [], []
ORA-01001: invalid cursor
Thu Aug  2 01:49:39 2012
Errors in file /oracle9/app/admin/acc/udump/acc2_ora_647350.trc:
ORA-00600: internal error code, arguments: [17281], [1001], [0x7000007AB9F0A30], [], [], [], [], []
ORA-01001: invalid cursor
ORA-00600: internal error code, arguments: [17281], [1001], [0x7000007AB9F0A30], [], [], [], [], []
ORA-01001: invalid cursor

分析trace文件

Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
ORACLE_HOME = /oracle9/app/product/9.2.0
System name:    AIX
Node name:      zwq_acc2
Release:        3
Version:        5
Machine:        00CFFB554C00
Instance name: acc2
Redo thread mounted by this instance: 2
Oracle process number: 1598
Unix process pid: 647350, image: oracle@zwq_acc2 (TNS V1-V3)
*** SESSION ID:(1643.29233) 2012-08-02 00:01:44.423
*** 2012-08-02 00:01:44.423
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [17281], [1001], [0x7000007AB9F0A30], [], [], [], [], []
ORA-01001: invalid cursor
Current SQL statement for this session:
DECLARE
   CURSOR NlsParamsCursor
   IS
      SELECT * FROM nls_session_parameters;
BEGIN
   SELECT NVL (LENGTHB (CHR (65536)), NVL (LENGTHB (CHR (65536)), 1))
     INTO :CharLength
     FROM DUAL;
   FOR NlsRecord IN NlsParamsCursor
   LOOP
      IF NlsRecord.parameter = 'NLS_DATE_LANGUAGE'
      THEN
         :NlsDateLanguage := NlsRecord.VALUE;
      ELSIF NlsRecord.parameter = 'NLS_DATE_FORMAT'
      THEN
         :NlsDateFormat := NlsRecord.VALUE;
      ELSIF NlsRecord.parameter = 'NLS_NUMERIC_CHARACTERS'
      THEN
         :NlsNumericCharacters := NlsRecord.VALUE;
      ELSIF NlsRecord.parameter = 'NLS_TIMESTAMP_FORMAT'
      THEN
         :NlsTimeStampFormat := NlsRecord.VALUE;
      ELSIF NlsRecord.parameter = 'NLS_TIMESTAMP_TZ_FORMAT'
      THEN
         :NlsTimeStampTZFormat := NlsRecord.VALUE;
      END IF;
   END LOOP;
END;
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp+0148          bl       ksedst               1029746FC ?
ksfdmp+0018          bl       01FD4014
kgeriv+0118          bl       _ptrgl
kgeasi+00cc          bl       kgeriv               000000000 ? 110347AE0 ?
                                                   1101A1738 ? 110380110 ?
                                                   110380420 ?
kgicli+0164          bl       kgeasi               110006308 ? 110386088 ?
                                                   438100004381 ? 200000002 ?
                                                   200000002 ? 000000000 ?
                                                   0000003E9 ? 000000002 ?
kgidlt+03a0          bl       kgicli               110287AA0 ? 000000168 ?
kgidel+0018          bl       kgidlt               11003DD08 ? 110062138 ?
                                                   000000069 ? 000000000 ?
                                                   000000000 ?
perabo+00cc          bl       kgidel               000000000 ? 000000000 ?
perdcs+0038          bl       perabo               000000120 ? 000000012 ?
                                                   70000000005C390 ?
peidcs+00ac          bl       perdcs               110002A20 ? 70000000007A450 ?
kkxcls+00bc          bl       peidcs               FFFFFFFFFFFA298 ? 110349708 ?
kxscln+0048          bl       kkxcls               1031628A8 ?
kkscls+0268          bl       kxscln               110349F60 ?
opicca+00f0          bl       kkscls               1009E8034 ? FFFFFFFFFFFA4C0 ?
opiclo+0020          bl       opicca               FFFFFFFFFFFA810 ?
kpoclsa+004c         bl       opiclo               000000002 ?
opiodr+08cc          bl       _ptrgl
ttcpip+0cc4          bl       _ptrgl
opitsk+0d60          bl       ttcpip               11000CF90 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
opiino+0758          bl       opitsk               000000000 ? 000000000 ?
opiodr+08cc          bl       _ptrgl
opidrv+032c          bl       opiodr               3C00000018 ? 4101FAF78 ?
                                                   FFFFFFFFFFFF7A0 ? 0A000F000 ?
sou2o+0028           bl       opidrv               3C0C000000 ? 4A02C3B50 ?
                                                   FFFFFFFFFFFF7A0 ?
main+0138            bl       01FD3A28
__start+0098         bl       main                 000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------
SO: 70000067d802e90, type: 2, owner: 0, flag: INIT/-/-/0x00
  (process) Oracle pid=1598, calls cur/top: 7000006f50c45f0/7000006f50c45f0, flag: (0) -
            int error: 0, call error: 0, sess error: 0, txn error 0
  (post info) last post received: 0 0 0
              last post received-location: No post
              last process to post me: 70000067d5eedf8 2 6
              last post sent: 0 0 0
              last post sent-location: No post
              last process posted by me: none
    (latch info) wait_event=0 bits=0
    Process Group: DEFAULT, pseudo proc: 7000006815fe518
    O/S info: user: oraacc, term: UNKNOWN, ospid: 647350
    OSD pid info: Unix process pid: 647350, image: oracle@zwq_acc2 (TNS V1-V3)
    ----------------------------------------
    SO: 70000068169e7b8, type: 4, owner: 70000067d802e90, flag: INIT/-/-/0x00
    (session) trans: 0, creator: 70000067d802e90, flag: (41) USR/- BSY/-/-/-/-/-
              DID: 0000-0000-00000000, short-term DID: 0000-0000-00000000
              txn branch: 0
              oct: 0, prv: 0, sql: 700000980c32508, psql: 700000980c32508, user: 44/DBRPT
    O/S info: user: wusp9, term: AHMWUSP9, ospid: 2812:1900, machine: AH\AHMWUSP9
              program:
    last wait for 'SQL*Net message from client' blocking sess=0x0 seq=13 wait_time=3647540
                driver id=54435000, #bytes=1, =0
    temporary object counter: 0

这里可以看出当前执行的sql是一种框架中发生,但是从PROCESS STATE未找到登录客户端名称,但是从machine中大概可以估算出来是windows机器.通过查询V$sql找出MODULE

SQL> select module,last_load_time  from V$sql where sql_text like 'declare  cursor NlsParamsCursor is%';
MODULE          LAST_LOAD_TIME
--------------- ----------------------------------
Toad.exe        2012-08-02/00:01:44

从这里可以确定,是因为TOAD登录数据库出现该错误,查询MOS发现相关内容ORA-600 [17281] using TOAD [ID 329531.1]

解决方法

 You can also overcome this by patching the Oracle Client software as follows.:
1. Fix unpublished Bug 4359111, if the Oracle software is 10.1.0.4 or below.
   Patches for this bug can be found on My Oracle Support under Patch:4359111.
2. Fix unpublished bug 5910901 by applying Patch:5910901 if the Oracle software is 10.1.0.5 or above,
3. Apply the 10.2.0.4 patch set or above on the client.
4. You can change the non-Oracle client software being used,
5. You can just ignore the error as it is non-corruptive.
6. Run the queries directly through SQLPLUS instead of using TOAD.
**Ensure that your version of TOAD is compatible with the version of the database as well.
If the errors continue when using TOAD, but not with SQL*Plus, contact TOAD support to request a fix.**

ORA-00600[kgscLogOff-notempty]

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-00600[kgscLogOff-notempty]

在查看一网友alert日志时发现很多ORA-00600[kgscLogOff-notempty]记录,通过查询MOS分析记录结果如下:
alert日志出现ORA-00600[kgscLogOff-notempty]

Wed Aug  1 10:28:35 2012
Errors in file /vgdata/oracle/admin/orcl1/udump/orcl1_ora_18430.trc:
ORA-00600: internal error code, arguments: [kgscLogOff-notempty], [1], [], [], [], [], [], []
Wed Aug  1 10:28:38 2012
Errors in file /vgdata/oracle/admin/orcl1/udump/orcl1_ora_18508.trc:
ORA-00600: internal error code, arguments: [kgscLogOff-notempty], [3], [], [], [], [], [], []

trace结合MOS分析原因

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /vgdata/oracle/product
System name:	HP-UX
Node name:	hpdc1
Release:	B.11.31
Version:	U
Machine:	ia64
Instance name: orcl1
Redo thread mounted by this instance: 1
Oracle process number: 230
Unix process pid: 18430, image: oracleorcl1@hpdc1
*** SERVICE NAME:(orcl1) 2012-08-01 10:28:35.937
*** SESSION ID:(191.141) 2012-08-01 10:28:35.937
*** 2012-08-01 10:28:35.937
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kgscLogOff-notempty], [1], [], [], [], [], [], []
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+64          call     _etext_f()+23058430  000000000 ? 000000001 ?
                              09017233648
ksedmp()+1680        call     _etext_f()+23058430  000000000 ?
                              09017233648          C000000000000D20 ?
                                                   40000000052C8C90 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ?
ksfdmp()+48          call     _etext_f()+23058430  000000003 ?
                              09017233648
kgerinv()+400        call     _etext_f()+23058430  40000000093F4370 ?
                              09017233648          000000003 ?
                                                   C000000000000612 ?
                                                   000008F07 ? 000000000 ?
                                                   000000000 ?
kgeasnmierr()+144    call     _etext_f()+23058430  6000000000015190 ?
                              09017233648          6000000000016248 ?
                                                   6000000000013770 ?
                                                   600000000009C808 ?
                                                   60000000000165B0 ?
$cold_kgscLogOff()+  call     _etext_f()+23058430  6000000000015190 ?
144                           09017233648          9FFFFFFFBF562160 ?
                                                   9FFFFFFFBF562170 ?
                                                   60000000000165C0 ?
                                                   000000000 ? 000000001 ?
kkslof()+320         call     _etext_f()+23058430  6000000000015190 ?
                              09017233648
opifcs()+592         call     _etext_f()+23058430  C000000360365908 ?
                              09017233648          C000000000000E21 ?
                                                   4000000002E1BF20 ?
                                                   000000000 ? 000000000 ?
ksuxds()+1568        call     _etext_f()+23058430  C000000360365908 ?
                              09017233648          4000000002EBA7A0 ?
                                                   000008F9F ? 000004810 ?
                                                   9FFFFFFFBF56BEF6 ?
                                                   C000000360365908 ?
                                                   4000000001354140 ?
                                                   00000003F ?
ksudel()+128         call     _etext_f()+23058430  60000000000A7B54 ?
                              09016643752          60000000000A7CF8 ?
                                                   9FFFFFFFFFFF6C20 ?
                                                   600000000009D8A0 ?
opilof()+3664        call     _etext_f()+23058430  60000000000A7B54 ?
                              09016643752          60000000000A7CF8 ?
                                                   4000000003D681E0 ?
                                                   C00000000000122A ?
                                                   00000814F ?
                                                   60000000000A7CE0 ?
opiodr()+2016        call     opilof()+3664        60000000002BE7B0 ?
                                                   60000000002BE7B8 ?
                                                   000000001 ?
                                                   9FFFFFFFFFFF71B0 ?
                                                   600000000009D8A0 ?
                                                   60000000002BE7E0 ?
ttcpip()+1824        call     _etext_f()+23058430  60000000000AA0BC ?
                              09017243504          000000001 ?
                                                   6000000000015310 ?
                                                   6000000000015310 ?
                                                   9FFFFFFFFFFF8250 ?
                                                   600000000009D8A0 ?
                                                   9FFFFFFFFFFF8250 ?
                                                   6000000000020D88 ?
opitsk()+2224        call     _etext_f()+23058430  6000000000020D80 ?
                              09017192128          9FFFFFFFFFFFA3D4 ?
                                                   6000000000020EE8 ?
                                                   000000001 ?
                                                   9FFFFFFFFFFFAA90 ?
                                                   9FFFFFFFFFFFA884 ?
                                                   6000000000020E88 ?
                                                   000000000 ?
opiino()+2144        call     _etext_f()+23058430  000000000 ? 000000000 ?
                              09016681384          600000000009D8A0 ?
                                                   4000000002AE7E10 ?
                                                   000008001 ?
                                                   9FFFFFFFFFFFA874 ?
opiodr()+2016        call     _etext_f()+23058430  00000003C ?
                              09016681384          9FFFFFFFFFFFF260 ?
                                                   9FFFFFFFFFFFF250 ?
                                                   9FFFFFFFFFFFBF90 ?
                                                   0000000B0 ?
                                                   600000000008F560 ?
opidrv()+1136        call     _etext_f()+23058430  60000000000AA0BC ?
                              09017243504          000000001 ?
                                                   6000000000015310 ?
                                                   6000000000015310 ?
                                                   9FFFFFFFFFFFCAE0 ?
                                                   600000000009D8A0 ?
sou2o()+240          call     9fffffffffffcae0     00000003C ? 000000004 ?
                                                   9FFFFFFFFFFFF250 ?
opimai_real()+480    call     9fffffffffffcae0     9FFFFFFFFFFFF270 ?
                                                   00000003C ? 000000004 ?
                                                   9FFFFFFFFFFFF250 ?
main()+352           call     9fffffffffffcae0     000000000 ?
                                                   9FFFFFFFFFFFF2A0 ?
main_opd_entry()+80  call     9fffffffffffcae0     000000002 ?
                                                   9FFFFFFFFFFFF750 ?
                                                   C000000000033910 ?
                                                   000000000 ?
--------------------- Binary Stack Dump ---------------------

通过查询MOS发现ORA-600 [kgscLogOff-notempty] On Session Logoff [ID 413120.1]中记录有

The following error may occur on session logoff
ORA-600 [kgscLogOff-notempty], [1]
or ORA-600 [kgscLogOff-notempty], [2]
with a Call Stack like:
... kgscLogOff  kkslof opifcs ksuxds ksudel ...

和该数据库中的Stack Dump记录一致,数据库版本也在该bug范围内,从而可以确定是unpublished Bug 4887675

解决方案
该错误是在logoff时产生,对数据库影响不大,如果偶尔出现可以忽略,出现频率过高,建议按照下列方法解决

There is No Data Corruption (or) Data Loss due to this Error.
This error occurs during the logoff operation, hence the impact should be negligible.
This is fixed in 10.2.0.4 and above releases.
One-off patches may be available depending on your current release and operating system.
To obtain a patch from MetaLink:
1) Click on Patches.
2) Click on Simple Search
3) Enter patch number: 4887675
4) Select your O/S
5) Click Go.
As workaround, avoid  Killing/Terminating the Session Abnormally.

因为高版本引起ORA-00600[17059]

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：因为高版本引起ORA-00600[17059]

alert日志出现ORA-00600[17059]

Wed Aug 01 03:19:29 2012
Errors in file /oracle/diag/rdbms/sgerp5/sgerp5/trace/sgerp5_ora_5177388.trc  (incident=682625):
ORA-00600: 内部错误代码, 参数: [17059], [0x700000A18EE85E0], [0x70000085506A820], [0x700000A51F56E40], [], [], [], []
Incident details in: /oracle/diag/rdbms/sgerp5/sgerp5/incident/incdir_682625/sgerp5_ora_5177388_i682625.trc

查看trace文件

Dump continued from file: /oracle/diag/rdbms/sgerp5/sgerp5/trace/sgerp5_ora_5177388.trc
ORA-00600: 内部错误代码, 参数: [17059], [0x700000A3ED7B240], [0x7000007C19384F8], [0x70000078BC51048], [], [], [], []
========= Dump for incident 682624 (ORA 600 [17059]) ========
*** 2012-07-31 22:38:06.130
----- Current SQL Statement for this session (sql_id=03vurqhdanbv6) -----
begin
 insert into "000".tbExhRes(DeptCode,ERCode,ERName,CategoryCode,GoodsCategoryCode,TermMoney,IsAllowOwned,CategoryItemCode,GoodsCategoryItemCode)
values('1521','20070115210130','连云港通灌路购物广场地堆130','200701','0201',1200,1,'0000','0000');
 insert into "000".tbExhRes(DeptCode,ERCode,ERName,CategoryCode,GoodsCategoryCode,TermMoney,IsAllowOwned,CategoryItemCode,GoodsCategoryItemCode)
values('1521','20070115210131','连云港通灌路购物广场地堆131','200701','0201',1200,1,'0000','0000');
 …………近5万条类此sql
end;
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+002c      bl       105e27f1c
ksedst1()+0064       bl       101fadb74
ksedst()+0028        bl       ksedst1()            000000000 ? 000000000 ?
dbkedDefDump()+07fc  bl       101faf398
ksedmp()+0048        bl       101fadb70
ksfdmp()+0058        bl       ksedmp()             000000000 ?
dbgexPhaseII()+0130  bl       _ptrgl()
dbgexProcessError()  bl       dbgexPhaseII()       110383690 ? 000000000 ?
+09bc                                              600000006 ?
dbgeExecuteForError  bl       dbgexProcessError()  110383690 ? 110388B10 ?
()+0040                                            1729C5E38 ? 000004028 ?
dbgePostErrorKGE()+  bl       dbgeExecuteForError  FFFFFFFFFFF02C0 ? 110000328 ?
03c0                          ()                   FFFFFFFFFFF0350 ?
                                                   484222407FFFFFF8 ?
                                                   100154D20 ?
dbkePostKGE_kgsf()+  bl       dbgePostErrorKGE()   000000258 ? 110000328 ?
003c                                               25810594518 ?
kgeade()+0300        bl       _ptrgl()
kgeriv_int()+0068    bl       kgeade()             1070DA620 ? 1070DADB8 ?
                                                   1070D9E48 ? 1070DB208 ?
                                                   1070DA784 ? 1070DA788 ?
                                                   1070DA77C ? 1070DA794 ?
kgeriv()+0020        bl       kgeriv_int()         7000007C19384F8 ? 000000000 ?
                                                   000000001 ? FFFFFFFFFFF11E0 ?
                                                   700000A62228320 ?
                                                   7000007C19384F8 ?
kgesiv()+007c        bl       kgeriv()             10102D590 ? 700000A3ED7B350 ?
                                                   700000A62228320 ? 000000005 ?
                                                   000000000 ?
kgesic3()+0040       bl       kgesiv()             7000007C19384F8 ? 000000000 ?
                                                   000000001 ? FFFFFFFFFFF11E0 ?
                                                   700000A62228320 ?
kgltba()+0134        bl       kgesic3()            110000328 ? 110594518 ?
                                                   42A3000042A3 ? 000000002 ?
                                                   700000A3ED7B240 ? 000000002 ?
                                                   7000007C19384F8 ? 000000002 ?
kglrdtin()+01d4      bl       kgltba()             FFFFFFFFFFF1470 ? 000000000 ?
                                                   FFFFFFFFFFF1318 ? 000000000 ?
                                                   000000001 ? 12BFB90F8 ?
kglrtl()+0020        bl       kglrdtin()           000000001 ? 000000000 ?
                                                   000000001 ? 169F90F18 ?
                                                   169F8E7F0 ? 12BFB90F8 ?
                                                   FFFFFFFFFFF1470 ?
pdy3M06_Add_Sql_Str  bl       kglrtl()             FFFFFFFFFFF14F0 ?
ing()+00c4                                         7FFF000000007FFF ?
                                                   10262A2A8 ? 11032DD20 ?
                                                   26FDBFA00 ?
pdy8M92_Fill_SQD()+  bl       pdy3M06_Add_Sql_Str  102683768 ? 000000000 ?
006c                          ing()                10267265C ?
pdy8M74_Fill_Descri  bl       101faf1a4
ptor()+0124
pdy8F07_Materialize  bl       pdy8M74_Fill_Descri  164B00E58 ? 165BD0380 ?
_Descriptors()+038c           ptor()               7000008C99BA368 ?
pdy1F82_Write_MCode  bl       pdy8F07_Materialize  FFFFFFFFFFF3968 ? 000000000 ?
()+0084                       _Descriptors()
pdy1F01_Driver()+01  bl       pdy1F82_Write_MCode  FFFFFFFFFFF18D0 ? 10726667C ?
58                            ()                   7000008EA0F18D8 ?
pdw0F82_Run_Code_Ge  bl       pdy1F01_Driver()     1028771D4 ? 000000000 ?
n()+0088
pdw0F01_Code_Gen()+  bl       pdw0F82_Run_Code_Ge  FFFFFFFFFFF1A50 ? 12BFC3E48 ?
0250                          n()
phpcog()+0010        bl       pdw0F01_Code_Gen()   FFFFFFFFFFF3968 ?
                                                   70000078BC51048 ? 000000004 ?
phpcmp()+13a0        bl       phpcog()             11037D140 ? 700000000003640 ?
pcicog()+0234        bl       phpcmp()             FFFFFFFFFFF3968 ?
                                                   70000078BC51048 ? 000000000 ?
                                                   000000000 ? 400000110000BEC ?
                                                   FFFFFFFFFFF33F0 ? 000000000 ?
                                                   000000000 ?
kkxcog()+01cc        bl       pcicog()             FFFFFFFFFFF3968 ?
                                                   70000078BC51048 ?
opitca()+0a50        bl       kkxcog()             10009697C ?
kksFullTypeCheck()+  bl       opitca()             11082EDB8 ? 7000008C99BA740 ?
001c
rpiswu2()+03c0       bl       _ptrgl()
kksLoadChild()+31e4  bl       rpiswu2()            700000A717262C8 ?
                                                   7000008EA0F1970 ?
                                                   7000008C99BAA78 ? 107267650 ?
                                                   000000000 ? 55D16B348 ?
                                                   FFFFFFFFFFF72B8 ? 000000000 ?
kxsGetRuntimeLock()  bl       kksLoadChild()       110000328 ? 70000078BC51048 ?
+083c                                              700000A57852278 ?
kksfbc()+2230        bl       kxsGetRuntimeLock()  110000328 ? 11082EDB8 ?
                                                   FFFFFFFFFFF72B8 ?
                                                   12C00000000 ?
                                                   100006300000000 ?
kkspsc0()+106c       bl       kksfbc()             11082EDB8 ? 3FFFF8150 ?
                                                   1085D16C170 ? 149510630 ?
                                                   000AE3AD5 ? 000000000 ?
                                                   000000000 ? 000000000 ?
kksParseCursor()+00  bl       kkspsc0()            1105B2748 ? 149510630 ?
cc                                                 000AE3AD5 ? 31032DD20 ?
                                                   600000000 ? A4000000000000 ?
                                                   000000000 ?
opiosq0()+0b18       bl       103ecdd38
kpooprx()+019c       bl       101fadff0
kpoal8()+04c0        bl       kpooprx()            FFFFFFFFFFFB454 ? 149510630 ?
                                                   AE3AD400AE3AD4 ? 100000001 ?
                                                   000000000 ? A40000000000A4 ?
opiodr()+0b48        bl       103ec82b0
ttcpip()+114c        bl       _ptrgl()
opitsk()+169c        bl       103eca2bc
opiino()+09a0        bl       opitsk()             1100981E8 ? 000000000 ?
opiodr()+0b48        bl       103ec82b0
opidrv()+0440        bl       opiodr()             3C2F736765 ? 41032DD20 ?
                                                   FFFFFFFFFFFF8C0 ? 05F353137 ?
sou2o()+0090         bl       opidrv()             3C05C052EC ? 4A0071E60 ?
                                                   FFFFFFFFFFFF8C0 ?
opimai_real()+01b0   bl       101fad8cc
main()+0090          bl       opimai_real()        000000000 ? 000000000 ?
__start()+0070       bl       main()               000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------

ORA-00600[17059]错误大部分都是因为高版本导致,对于本库的分析:因为该库的shared pool老化比较频繁,到我介入的时候,发现相关该类此sql已经不能找到,不能非常肯定的找出来原因,猜测可能原因是:这个库(版本为11.1.0.6 FOR AIX)因为开发基本上没有绑定参数,设置cursor_sharing=force,这里5万多条的insert会自动转换为参数形式,因为每个insert参数对应的值长度区别较大,使得BIND_MISMATCH不匹配导致高版本现象严重,从而出现了该Bug 9689310.

解决该问题
1.不要通过程序拼接sql出来,使用绑定参数形式
2.升级到相应新版本解决该问题
3.一次减少执行的sql数量,定时刷新shared pool[临时办法]

补充说明相关bug
Bug 5177766 OERI[17059] with SESSION_CACHED_CURSORS
Bug 8946311 Increase max children before reporting ORA-600 [17059]
BUG 9094984 ORA-600 [17059] WITH VERY HIGH CHILD CURSOR COUNTS BEING GENERATED
Bug 8922013 OERI [17059] / excess child cursors for SQL referencing REMOTE objects
Bug 9689310 Excessive child cursors / high VERSION_COUNT / OERI:17059 due to bind mismatch
BUG 8981059 HIGH VERSION COUNT:BIND_MISMATCH,USER_BIND_PEEK_MISMATCH,OPTIMIZER_MODE_MISMATCH

truncate table强制终止导致ORA-00600[ktspfundo-2]

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：truncate table强制终止导致ORA-00600[ktspfundo-2]

朋友的金蝶erp系统异常abort,让我帮忙分析原因.
ORA-00600[ktspfundo-2]错误

Fri Jul 27 08:53:33 2012
Errors in file /u01/oracle/admin/finance/udump/finance_ora_7687.trc:
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
ORA-01013: user requested cancel of current operation
Fri Jul 27 08:53:33 2012
Errors in file /u01/oracle/admin/finance/udump/finance_ora_7687.trc:
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
ORA-01013: user requested cancel of current operation
Fri Jul 27 08:54:16 2012
Errors in file /u01/oracle/admin/finance/udump/finance_ora_7687.trc:
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
ORA-01013: user requested cancel of current operation
Fri Jul 27 08:57:12 2012
Errors in file /u01/oracle/admin/finance/bdump/finance_smon_4156.trc:
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
Fri Jul 27 08:57:20 2012
ORACLE Instance finance (pid = 15)-Error 600 encountered while recovering transaction (8, 3) on object 34294107.
Fri Jul 27 08:57:20 2012
Errors in file /u01/oracle/admin/finance/bdump/finance_smon_4156.trc:
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
Fri Jul 27 09:07:14 2012
Errors in file /u01/oracle/admin/finance/bdump/finance_smon_4156.trc:
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
Fri Jul 27 09:07:15 2012
Errors in file /u01/oracle/admin/finance/bdump/finance_pmon_4130.trc:
ORA-00474: SMON process terminated with error

从这里可以大概看出数据库在进行一个参数,然后用户终止该操作导致,导致ORA-00600[ktspfundo-2]错误,然后出现smon回滚,因为回滚失败从而使得数据块down掉

分析trace文件

*** 2012-07-27 08:53:33.293
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [ktspfundo-2], [], [], [], [], [], [], []
ORA-01013: user requested cancel of current operation
Current SQL statement for this session:
TRUNCATE TABLE VTC3B8DR2G7J926FWOBK839XOR
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFF41B0EE70 ? 7FFF41B0EED0 ?
                                                   7FFF41B0EE10 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7FFF41B0EE70 ? 7FFF41B0EED0 ?
                                                   7FFF41B0EE10 ? 000000000 ?
ksfdmp()+21          call     ksedmp()             000000003 ? 000000001 ?
                                                   7FFF41B0EE70 ? 7FFF41B0EED0 ?
                                                   7FFF41B0EE10 ? 000000000 ?
kgerinv()+161        call     ksfdmp()             000000003 ? 000000001 ?
                                                   7FFF41B0EE70 ? 7FFF41B0EED0 ?
                                                   7FFF41B0EE10 ? 000000000 ?
kgeasnmierr()+163    call     kgerinv()            0068966E0 ? 2AE87C6E1168 ?
                                                   7FFF41B0EED0 ? 7FFF41B0EE10 ?
                                                   000000000 ? 000000000 ?
ktspfundo()+3902     call     kgeasnmierr()        0068966E0 ? 2AE87C6E1168 ?
                                                   7FFF41B0EED0 ? 7FFF41B0EE10 ?
                                                   000000010 ? 00689C0C0 ?
kcoubk()+351         call     ktspfundo()          7FFF41B10810 ? 2AE80C800CFA ?
                                                   4D6EE6014 ? 000000002 ?
                                                   000000010 ? 7FFF41B11128 ?
ktundo()+1208        call     kcoubk()             7FFF41B111F8 ? 7FFF41B10810 ?
                                                   2AE87E384024 ? 000000002 ?
                                                   000000002 ? 000000000 ?
ktubko()+499         call     ktundo()             000000001 ? 010E5C341 ?
                                                   2AE87E384020 ? 000000058 ?
                                                   000008430 ? 7657E9990 ?
ktuabt()+810         call     ktubko()             7657E9990 ? 7FFF41B1188C ?
                                                   000000002 ? 7FFF41B11648 ?
                                                   7FFF41B11570 ? 7FFF41B11870 ?
ktcrab()+292         call     ktuabt()             7657E98F8 ? 000000002 ?
                                                   000000002 ? 7FFF41B11648 ?
                                                   7FFF41B11570 ? 7FFF41B11870 ?
ktccle()+516         call     ktcrab()             7657E98F8 ? 000000002 ?
                                                   000000002 ? 7FFF41B11648 ?
                                                   7FFF41B11570 ? 7FFF41B11870 ?
ksepop()+384         call     ktccle()             000000006 ? 000000002 ?
                                                   000000002 ? 7FFF41B11648 ?
                                                   7FFF41B11570 ? 7FFF41B11870 ?
kgepop()+123         call     ksepop()             0068966E0 ? 000000006 ?
                                                   000000002 ? 7FFF41B11648 ?
                                                   7FFF41B11570 ? 7FFF41B11870 ?
kgesev()+315         call     kgepop()             0068966E0 ? 2AE87C6E1168 ?
                                                   0000003F5 ? 7FFF41B11648 ?
                                                   7FFF41B11570 ? 7FFF41B11870 ?
ksesec0()+186        call     kgesev()             0068966E0 ? 2AE87C6E1168 ?
                                                   0000003F5 ? 000000000 ?
                                                   7FFF41B11B30 ? 7FFF41B11870 ?
ksqcmi()+2322        call     ksesec0()            000000000 ? 000000000 ?
                                                   000001000 ? 000000000 ?
                                                   000000013 ? 000000005 ?
ksqcnv()+496         call     ksqcmi()             77E586B88 ? 000000006 ?
                                                   00000FFFF ? 00147AE14 ?
                                                   7FFF41B126A0 ? 7FFF41B128A8 ?
ksqcov()+44          call     ksqcnv()             77E586B88 ? 000000006 ?
                                                   000000000 ? 00147AE14 ?
                                                   7FFF41B128A8 ? 000000004 ?
kcbo_reuse_obj()+14  call     ksqcov()             77E586B68 ? 000000006 ?
09                                                 000000000 ? 00147AE14 ?
                                                   7FFF41B128A8 ? 000000004 ?
kcbrbo()+1126        call     kcbo_reuse_obj()     7FFF41B12F04 ? 7FFF41B12F0C ?
                                                   000000001 ? 00147AE14 ?
                                                   7FFF41B128A8 ? 000000004 ?
ktsstrn_segment()+3  call     kcbrbo()             7FFF41B12F04 ? 7FFF41B12F0C ?
941                                                000000001 ? 00147AE14 ?
                                                   7FFF41B128A8 ? 000000004 ?
kkbtts_trunc_tbl_se  call     ktsstrn_segment()    7FFF41B13180 ? 000000000 ?
g()+1018                                           0020C6444 ? 000000000 ?
                                                   7FFF41B14C00 ? 7FFF00000001 ?
kkbtrn()+8156        call     kkbtts_trunc_tbl_se  735ACA058 ? 77BC78D18 ?
                              g()                  000000000 ? 000000002 ?
                                                   000000000 ? 7FFF41B14C00 ?
opiexe()+15805       call     kkbtrn()             735ACA058 ? 000000000 ?
                                                   718831208 ? 000000000 ?
                                                   000000002 ? 7FFF00000000 ?
opiosq0()+3316       call     opiexe()             000000004 ? 000000000 ?
                                                   7FFF41B15F48 ? 00000000B ?
                                                   000000002 ? 7FFF00000000 ?
kpooprx()+315        call     opiosq0()            000000003 ? 00000000E ?
                                                   7FFF41B160B8 ? 0000000A4 ?
                                                   000000002 ? 7FFF00000000 ?
kpoal8()+799         call     kpooprx()            7FFF41B19264 ? 7FFF41B17280 ?
                                                   000000029 ? 000000001 ?
                                                   000000000 ? 7FFF00000000 ?
opiodr()+984         call     kpoal8()             00000005E ? 000000017 ?
                                                   7FFF41B19260 ? 000000001 ?
                                                   000000001 ? 7FFF00000000 ?
ttcpip()+1012        call     opiodr()             00000005E ? 000000017 ?
                                                   7FFF41B19260 ? 000000000 ?
                                                   0059C09B0 ? 7FFF00000000 ?
opitsk()+1322        call     ttcpip()             00689E3B0 ? 7FFF41B17248 ?
                                                   7FFF41B19260 ? 000000000 ?
                                                   7FFF41B18D58 ? 7FFF41B193C8 ?
opiino()+1026        call     opitsk()             000000003 ? 000000000 ?
                                                   7FFF41B19260 ? 000000001 ?
                                                   000000000 ? 4E58D8C00000001 ?
opiodr()+984         call     opiino()             00000003C ? 000000004 ?
                                                   7FFF41B1A428 ? 000000000 ?
                                                   000000000 ? 4E58D8C00000001 ?
opidrv()+547         call     opiodr()             00000003C ? 000000004 ?
                                                   7FFF41B1A428 ? 000000000 ?
                                                   0059C0460 ? 4E58D8C00000001 ?
sou2o()+114          call     opidrv()             00000003C ? 000000004 ?
                                                   7FFF41B1A428 ? 000000000 ?
                                                   0059C0460 ? 4E58D8C00000001 ?
opimai_real()+163    call     sou2o()              7FFF41B1A400 ? 00000003C ?
                                                   000000004 ? 7FFF41B1A428 ?
                                                   0059C0460 ? 4E58D8C00000001 ?
main()+116           call     opimai_real()        000000002 ? 7FFF41B1A490 ?
                                                   000000004 ? 7FFF41B1A428 ?
                                                   0059C0460 ? 4E58D8C00000001 ?
__libc_start_main()  call     main()               000000002 ? 7FFF41B1A490 ?
+244                                               000000004 ? 7FFF41B1A428 ?
                                                   0059C0460 ? 4E58D8C00000001 ?
_start()+41          call     __libc_start_main()  000723088 ? 000000002 ?
                                                   7FFF41B1A5E8 ? 000000000 ?
                                                   0059C0460 ? 000000002 ?
--------------------- Binary Stack Dump ---------------------

这里可以得到更加准确的信息,数据库在truncate table的时候,有人异常终止程序,导致数据库出现ORA-00600[ktspfundo-2].查询mos未发现相关bug记录,从这些信息初步判断是因为oracle的bug导致在truncate表的时候异常终止,然后出现该对象上的回滚记录异常(当然truncate本身不需要回滚,但是可能记录一些附带的回滚信息),然后出现对象回滚异常是的数据库down.重启数据库,对象回滚段信息已经自动回滚完成,数据库正常.因为truncate表被异常终止的情况本身不多见,引发该bug更不常见,如果只是偶尔发生一次,建议忽略该错误.当然如果有时间和兴趣,可以提交sr

客户端版本导致ORA-00600[kssadd_stage: null parent]

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：客户端版本导致ORA-00600[kssadd_stage: null parent]

有客户一台应用不能正常工作,报ORA-00600[kssadd_stage: null parent]错误，重启中间件后工作正常.
alert日志

ORA-00600: internal error code, arguments: [kssadd_stage: null parent], [], [], [], [], [], [], []
Tue Jul 17 14:57:37 2012
Trace dumping is performing id=[cdmp_20120717145742]
Tue Jul 17 14:57:39 2012
Errors in file /oracle/10g/admin/fdjdb/udump/fdjdb2_ora_307720.trc:
ORA-00600: internal error code, arguments: [kssadd_stage: null parent], [], [], [], [], [], [], []
Tue Jul 17 14:57:45 2012
Errors in file /oracle/10g/admin/fdjdb/udump/fdjdb2_ora_357344.trc:
ORA-00600: internal error code, arguments: [kssadd_stage: null parent], [], [], [], [], [], [], []

trace文件

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
ORACLE_HOME = /oracle/10g/db
System name:    AIX
Node name:      ora2
Release:        1
Version:        6
Machine:        00CCFD354C00
Instance name: fdjdb2
Redo thread mounted by this instance: 2
Oracle process number: 89
Unix process pid: 111068, image: oracle@ora2
*** ACTION NAME:() 2012-07-17 15:08:42.043
*** MODULE NAME:(gsrvr.exe) 2012-07-17 15:08:42.043
*** SERVICE NAME:(fdjdb) 2012-07-17 15:08:42.043
*** SESSION ID:(991.44140) 2012-07-17 15:08:42.043
*** 2012-07-17 15:08:42.043
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kssadd_stage: null parent], [], [], [], [], [], [], []
No current SQL statement being executed.
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst+001c          bl       ksedst1              40D1A9663F9E7ABB ?
                                                   6ED89E14D59386B5 ?
ksedmp+0290          bl       ksedst               104A2CDB0 ?
ksfdmp+0018          bl       03F2735C
kgerinv+00dc         bl       _ptrgl
kgeasnmierr+004c     bl       kgerinv              11041D938 ? 700000220FFBFC8 ?
                                                   110000770 ? 7000004FDF0C700 ?
                                                   FFFFFFFFFFF89C0 ?
kssadd_stage+0080    bl       kgeasnmierr          110195490 ? 110450040 ?
                                                   104AC46B8 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 7000004F0FA9208 ?
kqreqa+0058          bl       kssadd_stage         105670038 ? 104CF7BA0 ?
                                                   000000000 ? 000000000 ?
kqrpre1+0850         bl       kqreqa               100203514 ? 1101A2B20 ?
kqrpre+001c          bl       kqrpre1              710000770 ? 000000009 ?
                                                   FFFFFFFFFFF9088 ?
                                                   28A4202200000000 ?
                                                   10012AEE4 ? FFFFFFFFFFF9080 ?
                                                   000000000 ? 11022A3E0 ?
opiosq0+009c         bl       kqrpre               000000000 ? 000000000 ?
                                                   000000000 ? 1101A2B20 ?
                                                   FFFFFFFFFFF9198 ? 1104B7C60 ?
                                                   FFFFFFFFFFF9458 ?
kpooprx+0168         bl       opiosq0              4A00000001 ? 000000001 ?
                                                   000000000 ? A40000000000FF ?
kpoal8+0400          bl       kpooprx              FFFFFFFFFFFB964 ?
                                                   FFFFFFFFFFFB680 ?
                                                   5000000050 ? 100000001 ?
                                                   000000000 ? A40000000000A4 ?
                                                   000000000 ? 1103A1AD8 ?
opiodr+0ae0          bl       _ptrgl
ttcpip+1020          bl       _ptrgl
opitsk+1124          bl       01F971E8
opiino+0990          bl       opitsk               000000000 ? 000000000 ?
opiodr+0ae0          bl       _ptrgl
opidrv+0484          bl       01F96034
sou2o+0090           bl       opidrv               3C02D9A29C ? 4A006E298 ?
                                                   FFFFFFFFFFFF8A0 ?
opimai_real+01bc     bl       01F939B4
main+0098            bl       opimai_real          000000000 ? 000000000 ?
__start+0070         bl       main                 000000000 ? 000000000 ?
--------------------- Binary Stack Dump ---------------------

咨询客户得知访问该数据库的是通过中间件(OCI)+10g Release 1 (10.1) for Windows访问数据库,然后查询MOS[ID 752149.1]发现stack trace
kssadd_stage <- kqreqa <- kqrpre1 <- kqrpre <- opiosq0 <- kpooprx <- kpoal8 <- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o <- opimai_real <- main <- start 和客户端版本和访问环境都和unpublished Bug 4937225相似
处理建议
客户端升级到10.2.0.3或者更高版本

分类目录归档：ORA-xxxxx