ORA-600(ktspgfb-inc)错误

Posted on 2012/01/24 by yangtingkun

又是一个和空间优化有关的bug。
告警日志中错误如下：

Wed Mar 16 22:21:01 2011
Errors IN file /oracle/admin/oasisdb/bdump/oasisdb1_j000_16029.trc:
ORA-00600: internal error code, arguments: [ktspgfb-inc], [1], [0], [], [], [], [], []
Wed Mar 16 22:21:37 2011
Errors IN file /oracle/admin/oasisdb/bdump/oasisdb1_j000_16029.trc:
ORA-00600: internal error code, arguments: [ORA-00600: internal error code, arguments: [ktspgfb-inc], [1], [0], [], [], [], [], []
ORA-06512: at "SYS.PRVT_ADVISOR", line 1624
ORA-06512: at "SYS.DBMS_ADVISOR", line 186
ORA-06512: at "SYS.DBMS_SPACE", line 1500
ORA-06512: at "SYS.DBMS_SPACE", line 1566
], [], [], [], [], [], [], []
Wed Mar 16 22:21:37 2011
Trace dumping IS performing id=[cdmp_20110316222137]

从第一个报错还看不出是什么原因导致的，只是知道出现错误的是JOB进程。但是随后第二次报错就说明了错误出现的具体位置，显然是DBMS_SPACE包调用的DBMS_ADVISOR包时，出现了这个错误。
即使不查MOS，也可以判断这个bug的影响和如何解决。禁用空间建议就可以避免这个错误的产生，而且这个bug并不会造成什么危害，完全可以简单的忽略掉。
查询MOS，没有找到完全符合条件的bug描述，相比较可能和Bug 7260057 Instance crash after failed RESIZE on NFS描述的最为接近。不过当前的问题并不会导致实例崩溃这么严重的后果，而只是自动执行任务失败而已。随后这个错误并没有再次出现，说明这个错误的出现具有一定的偶然性，而并非每次空间管理的JOB运行都会触发。Oracle在10.2.0.5和11.2解决了这个问题。

Posted in BUG | Tagged , , , | Leave a comment

ORA-600(kghuclientasp_03)错误

Posted on 2012/01/23 by yangtingkun

告警日志中出现这个ORA-600错误。
错误信息如下：

Thu Jan 6 10:26:55 2011
Errors IN file /oracle/admin/oasisdb/udump/oasisdb1_ora_5597.trc:
ORA-00600: 内部错误代码, 参数: [kghuclientasp_03], [0x2A97673008], [0], [0], [0], [], [], []
Thu Jan 6 10:26:56 2011
Errors IN file /oracle/admin/oasisdb/udump/oasisdb1_ora_5597.trc:
ORA-00600: 内部错误代码, 参数: [kghuclientasp_03], [0x2A97673008], [0], [0], [0], [], [], []
ORA-00600: 内部错误代码, 参数: [kghuclientasp_03], [0x2A97673008], [0], [0], [0], [], [], []
Thu Jan 6 10:26:56 2011
Trace dumping IS performing id=[cdmp_20110106102656]
Thu Jan 6 10:26:58 2011
Trace dumping IS performing id=[cdmp_20110106102658]

根据MOS的信息，这个错误的描述在Bug 5094828 – Dequeue of RAW message gets ORA-600 [kghuclientasp_03] [ID 5094828.8]。简单的说，用户在COPY RAW类型的数据时，所提供的变量长度不足，导致拷贝数据的时候会覆盖其他区域，从而引发了这个问题。
其实解决问题的方法很简单，提供一个足够的变量空间就可以避免这个错误。严格意义上讲，这不算是Oracle的bug，只不过Oracle在处理的时候，前期检查不严格而已。
Oracle在11.2.0.2中解决了这个问题，小于这个版本都可能出现这个错误。

Posted in BUG | Tagged , , , | Leave a comment

11.2单实例ASM启动报错ORA-15186

Posted on 2012/01/22 by yangtingkun

客户安装了一个Oracle 11.2.0.2 for Linux X64环境，使用了ASM方式，重启后发现数据库没有启动。
检查操作系统进程，发现ASM已经启动，CLUSTER环境也启动完成，但是数据库并未启动，尝试手工启动数据库，报错找不到对应的SPFILE。
登录ASM实例，查询发现找不到任何的ASM磁盘组信息：

[grid@rptdb trace]$ sqlplus / AS sysasm
SQL*Plus: Release 11.2.0.2.0 Production ON Tue DEC 20 18:41:41 2011
Copyright (c) 1982, 2010, Oracle. ALL rights reserved.
 
Connected TO:
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
WITH the Automatic Storage Management OPTION
SQL> SELECT * FROM v$asm_diskgroup;
no ROWS selected

查询V$ASM_DISK可以看到磁盘信息，但是磁盘头的头状态是UNKNOWN：

SQL> SELECT GROUP_NUMBER, DISK_NUMBER, MOUNT_STATUS, HEADER_STATUS, PATH FROM V$ASM_DISK;
GROUP_NUMBER DISK_NUMBER MOUNT_S HEADER_STATU PATH
------------ ----------- ------- ------------ ----------------------------------
           0           1 CLOSED  UNKNOWN      ORCL:FRAVOL
           0           0 CLOSED  UNKNOWN      ORCL:DATAVOL

显然Oracle并没有去加载磁盘组，利用当前ASM的SPFILE生成PFILE后发现，只有最基本的参数：

*.asm_power_limit=1
*.diagnostic_dest='/u01/app/grid'
*.instance_type='asm'
*.large_pool_size=12M
*.remote_login_passwordfile='EXCLUSIVE'

连ASM_DISKGROUPS参数都没有，难怪查询V$ASM_DISKGROUP找不到任何数据，添加下面的参数：

asm_diskgroups='DATA','FRA'
asm_diskstring='ORCL:*VOL'

重启ASM实例，在加载磁盘组时报错：

[grid@rptdb ~]$ sqlplus / AS sysasm
SQL*Plus: Release 11.2.0.2.0 Production ON Tue DEC 20 18:25:03 2011
Copyright (c) 1982, 2010, Oracle.  ALL rights reserved.
Connected TO:
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
WITH the Automatic Storage Management OPTION
SQL> shutdown immediate
ORA-15100: invalid OR missing diskgroup name
ASM instance shutdown
SQL> startup pfile=/home/grid/init+ASM.ora
ASM instance started
Total System Global Area  283930624 bytes
Fixed SIZE                  2225792 bytes
Variable SIZE             256539008 bytes
ASM Cache                  25165824 bytes
ORA-15032: NOT ALL alterations performed
ORA-15017: diskgroup "FRA" cannot be mounted
ORA-15063: ASM discovered an insufficient NUMBER OF disks FOR diskgroup "FRA"
ORA-15017: diskgroup "DATA" cannot be mounted
ORA-15063: ASM discovered an insufficient NUMBER OF disks FOR diskgroup "DATA"

导致这个错误的原因有很多，比如权限，多路径设置，存储设置等等，检查告警日志寻找进一步的信息：

Tue DEC 20 18:25:47 2011
* instance_number obtained FROM CSS = 1, checking FOR the existence OF node 0...
* node 0 does NOT exist. instance_number = 1
Starting ORACLE instance (normal)
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 42000 free: 42000)
DFLT Huge Pages allocation successful (allocated: 0)
***********************************************************
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
USING LOG_ARCHIVE_DEST_1 parameter DEFAULT VALUE AS /u01/app/grid/product/11.2.0/grid/dbs/arch
Autotune OF undo retention IS turned ON.
IMODE=BR
ILAT =0
LICENSE_MAX_USERS = 0
SYS auditing IS disabled
Starting up:
Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
WITH the Automatic Storage Management OPTION.
USING parameter settings IN client-side pfile /home/grid/init+ASM.ora ON machine rptdb
System parameters WITH non-DEFAULT VALUES:
  large_pool_size          = 12M
  instance_type            = "asm"
  remote_login_passwordfile= "EXCLUSIVE"
  asm_diskstring           = "ORCL:*VOL"
  asm_diskgroups           = "DATA"
  asm_diskgroups           = "FRA"
  asm_power_limit          = 1
  diagnostic_dest          = "/u01/app/grid"
Tue DEC 20 18:25:48 2011
PMON started WITH pid=2, OS id=14718
Tue DEC 20 18:25:48 2011
PSP0 started WITH pid=3, OS id=14722
Tue DEC 20 18:25:49 2011
VKTM started WITH pid=4, OS id=14726 at elevated priority
VKTM running at (1)millisec PRECISION WITH DBRM quantum (100)ms
Tue DEC 20 18:25:49 2011
GEN0 started WITH pid=5, OS id=14732
Tue DEC 20 18:25:49 2011
DIAG started WITH pid=6, OS id=14736
Tue DEC 20 18:25:49 2011
DIA0 started WITH pid=7, OS id=14740
Tue DEC 20 18:25:49 2011
MMAN started WITH pid=8, OS id=14744
Tue DEC 20 18:25:49 2011
DBW0 started WITH pid=9, OS id=14748
Tue DEC 20 18:25:49 2011
LGWR started WITH pid=10, OS id=14752
Tue DEC 20 18:25:49 2011
CKPT started WITH pid=11, OS id=14756
Tue DEC 20 18:25:49 2011
SMON started WITH pid=12, OS id=14760
Tue DEC 20 18:25:49 2011
RBAL started WITH pid=13, OS id=14764
Tue DEC 20 18:25:49 2011
GMON started WITH pid=14, OS id=14768
Tue DEC 20 18:25:49 2011
MMON started WITH pid=15, OS id=14772
Tue DEC 20 18:25:49 2011
MMNL started WITH pid=16, OS id=14776
ORACLE_BASE NOT SET IN environment. It IS recommended
that ORACLE_BASE be SET IN the environment
Tue DEC 20 18:25:49 2011
SQL> ALTER DISKGROUP ALL MOUNT
NOTE: Diskgroups listed IN ASM_DISKGROUPS are
         DATA
         FRA
NOTE: cache registered GROUP DATA NUMBER=1 incarn=0x157c40a1
NOTE: cache began mount (FIRST) OF GROUP DATA NUMBER=1 incarn=0x157c40a1
NOTE: cache registered GROUP FRA NUMBER=2 incarn=0x158c40a2
NOTE: cache began mount (FIRST) OF GROUP FRA NUMBER=2 incarn=0x158c40a2
NOTE: Loaded library: /opt/oracle/extapi/64/asm/orcl/1/libasm.so
ORA-15186: ASMLIB error FUNCTION = [asm_open(global)],  error = [1],  mesg = [Operation NOT permitted]
ORA-15025: could NOT OPEN disk "ORCL:DATAVOL"
ORA-15186: ASMLIB error FUNCTION = [asm_open(global)],  error = [1],  mesg = [Operation NOT permitted]
ORA-15025: could NOT OPEN disk "ORCL:FRAVOL"
ERROR: no PST quorum IN GROUP: required 2, found 0
NOTE: cache dismounting (clean) GROUP 1/0x157C40A1 (DATA)
NOTE: dbwr NOT being msg'd to dismount
NOTE: lgwr not being msg'd TO dismount
NOTE: cache dismounted GROUP 1/0x157C40A1 (DATA)
NOTE: cache ending mount (fail) OF GROUP DATA NUMBER=1 incarn=0x157c40a1
NOTE: cache deleting context FOR GROUP DATA 1/0x157c40a1
GMON dismounting GROUP 1 at 2 FOR pid 17, osid 14779
ERROR: diskgroup DATA was NOT mounted
ERROR: no PST quorum IN GROUP: required 2, found 0
NOTE: cache dismounting (clean) GROUP 2/0x158C40A2 (FRA)
NOTE: dbwr NOT being msg'd to dismount
NOTE: lgwr not being msg'd TO dismount
NOTE: cache dismounted GROUP 2/0x158C40A2 (FRA)
NOTE: cache ending mount (fail) OF GROUP FRA NUMBER=2 incarn=0x158c40a2
NOTE: cache deleting context FOR GROUP FRA 2/0x158c40a2
GMON dismounting GROUP 2 at 4 FOR pid 17, osid 14779
ERROR: diskgroup FRA was NOT mounted
ORA-15032: NOT ALL alterations performed
ORA-15017: diskgroup "FRA" cannot be mounted
ORA-15063: ASM discovered an insufficient NUMBER OF disks FOR diskgroup "FRA"
ORA-15017: diskgroup "DATA" cannot be mounted
ORA-15063: ASM discovered an insufficient NUMBER OF disks FOR diskgroup "DATA"
ERROR: ALTER DISKGROUP ALL MOUNT

这里发现了ORA-15186和ORA-15025错误。而ORA-15186错误发生在ASMLIB调用上，根据这个错误更容易定位到问题的原因。
在MOS上，有专门的文章描述这个问题：Mount ASM Disk Group Fails : ORA-15186, ORA-15025, ORA-15063 [ID 1384504.1]，根据问题描述，导致这个错误的原因是多路径的配置存在问题：

[grid@rptdb ~]$ /etc/init.d/oracleasm listdisks
DATAVOL
FRAVOL
[grid@rptdb ~]$ cat /proc/partitions
major minor  #blocks  name
   8     0  285155328 sda
   8     1     104391 sda1
   8     2  285049327 sda2
   8    16 1073741824 sdb
   8    17  322119283 sdb1
   8    18  429497775 sdb2
   8    19  322119315 sdb3
   8    32 1073741824 sdc
   8    33  322119283 sdc1
   8    34  429497775 sdc2
   8    35  322119315 sdc3
   8    48 1073741824 sdd
   8    49  322119283 sdd1
   8    50  429497775 sdd2
   8    51  322119315 sdd3
   8    64 1073741824 sde
   8    65  322119283 sde1
   8    66  429497775 sde2
   8    67  322119315 sde3
 253     0  150896640 dm-0
 253     1  134119424 dm-1
 253     2 1073741824 dm-2
 253     3  322119283 dm-3
 253     4  429497775 dm-4
 253     5  322119315 dm-5
[grid@rptdb ~]$ ls -l /dev/oracleasm/disks
total 0
brw-rw---- 1 grid oinstall 8, 18 Dec 20 17:42 DATAVOL
brw-rw---- 1 grid oinstall 8, 19 Dec 20 17:42 FRAVOL

可以看到，DATAVOL和FRAVOL没有对应到多路径设备dm-n上，而是对应到了sdb2和sdb3上。
修改/etc/sysconfig/oracleasm文件，将ORACLEASM_SCANORDER参数和ORACLEASM_SCANEXCLUDE修改如下：

ORACLEASM_SCANORDER="mpath dm"
ORACLEASM_SCANEXCLUDE="sd"

修改后重启服务器，由于ASM中的SPFILE还是存在问题的，所以先关闭，然后重新启动：

[grid@rptdb ~]$ sqlplus / AS sysasm
SQL*Plus: Release 11.2.0.2.0 Production ON Tue DEC 20 19:05:33 2011
Copyright (c) 1982, 2010, Oracle.  ALL rights reserved.
Connected.
SQL> shutdown abort
ASM instance shutdown
SQL> startup pfile=/home/grid/init+ASM.ora
ASM instance started
Total System Global Area  283930624 bytes
Fixed SIZE                  2225792 bytes
Variable SIZE             256539008 bytes
ASM Cache                  25165824 bytes
ASM diskgroups mounted
SQL> CREATE spfile='+DATA' FROM pfile='/home/grid/init+ASM.ora';
File created.

磁盘组已经顺利启动，创建一个SPFILE文件，确保下次ASM自动启动可以加载磁盘组。切换到Oracle用户打开数据库：

[root@rptdb ~]# su - oracle
[oracle@rptdb ~]$ sqlplus / AS sysdba
SQL*Plus: Release 11.2.0.2.0 Production ON Tue DEC 20 19:06:27 2011
Copyright (c) 1982, 2010, Oracle.  ALL rights reserved.
Connected TO an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 6.4939E+10 bytes
Fixed SIZE                  2242560 bytes
Variable SIZE            3.0467E+10 bytes
DATABASE Buffers         3.4360E+10 bytes
Redo Buffers              109195264 bytes
DATABASE mounted.
DATABASE opened.
SQL> exit
Disconnected FROM Oracle DATABASE 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
WITH the Partitioning, Automatic Storage Management, OLAP, DATA Mining
AND REAL Application Testing options

数据库顺利打开，最后检查一下ASM磁盘的设置：

[oracle@rptdb ~]$ ls -l /dev/oracleasm/disks
total 0
brw-rw---- 1 oracle oinstall 253, 4 Dec 20 19:00 DATAVOL
brw-rw---- 1 oracle oinstall 253, 5 Dec 20 19:00 FRAVOL
[oracle@rptdb ~]$ cat /proc/partitions 
major minor  #blocks  name
   8     0  285155328 sda
   8     1     104391 sda1
   8     2  285049327 sda2
   8    16 1073741824 sdb
   8    17  322119283 sdb1
   8    18  429497775 sdb2
   8    19  322119315 sdb3
   8    32 1073741824 sdc
   8    33  322119283 sdc1
   8    34  429497775 sdc2
   8    35  322119315 sdc3
   8    48 1073741824 sdd
   8    49  322119283 sdd1
   8    50  429497775 sdd2
   8    51  322119315 sdd3
   8    64 1073741824 sde
   8    65  322119283 sde1
   8    66  429497775 sde2
   8    67  322119315 sde3
 253     0  150896640 dm-0
 253     1  134119424 dm-1
 253     2 1073741824 dm-2
 253     3  322119283 dm-3
 253     4  429497775 dm-4
 253     5  322119315 dm-5

调整oracleasm的配置后，多路径的配置恢复正常。

Posted in ORACLE | Tagged , , , , , , , , , | Leave a comment

ORA-600(kohfrm771)错误

Posted on 2012/01/21 by yangtingkun

一个空间数据库相关的bug。
错误信息如下：

Thu Jan 6 08:24:16 2011
Errors IN file /oracle/admin/oasisdb/udump/oasisdb1_ora_5597.trc:
ORA-00600: 内部错误代码, 参数: [kohfrm771], [], [], [], [], [], [], []
ORA-13234: 无法访问 R-tree-INDEX 表 [MDRT TABLE]
ORA-29400: 数据插件错误Error - OCI_NODATA

根据ORA-600 [kohfrm771]错误以及ORA-13234、ORA-29400错误进行查询，发现这是空间数据库的一个bug。详细信息参考文档Spatial Query Fails With ORA-7445 [kghufree()]/[kghuclientasp()] & ORA-13236, ORA-29400 Errors [ID 1291495.1]。
从错误信息分析，显然是空间数据库内部的PL/SQL过程异常处理存在错误，才会出现类似OCI_NODATA之类的报错，当然也有可能是内部的配置存在异常。
Oracle在10.2.0.5和11.2解决了这个Bug:7643987。

Posted in BUG | Tagged , , , , , | Leave a comment

ORA-600(prsHintQbLevel-1)错误

Posted on 2012/01/20 by yangtingkun

客户数据库出现ORA-600(prsHintQbLevel-1)错误信息。
错误信息如下：

Thu Jun 10 13:05:09 2010
Errors IN file /oracle/admin/oasisdb/udump/oasisdb1_ora_13644.trc:
ORA-00600: internal error code, arguments: [prsHintQbLevel-1], [316], [], [], [], [], [], []
Thu Jun 10 13:05:11 2010
Trace dumping IS performing id=[cdmp_20100610130511]

从错误名称不难看出，导致ORA-600错误的原因与HINT有关，而且多半与QB_NAME的设置有关，不过由于Oracle内部的HINT多半也会使用QB的方式，且错误中还有LEVEL的信息，不排除错误是Oracle内部添加QB导致的。
查询MOS，Bug 5503938 – OERI[prsHintQbLevel-1] for some HINTS [ID 5503938.8]描述的就是这个问题，确认影响版本是10.2.0.3和10.2.0.4，而当前的版本是10.2.0.4，可以肯定是这个BUG所致。
导致这个错误是由于一些未使用的HINT，导致SQL解析时报错。显然这个错误对于系统影响不大，改变或去除HINT即可避免这个错误。Oracle在10.2.0.5和11.1.0.6中已经fixed了这个bug。

Posted in BUG | Tagged , , , | Leave a comment

ORA-600(20084)错误

Posted on 2012/01/19 by yangtingkun

数据库告警日志中出现错误ORA-600(20084)。
错误信息如下：

Mon Aug 31 14:56:51 2009
Errors IN file /oracle/admin/oasisdb/udump/oasisdb1_ora_4787.trc:
ORA-00600: 内部错误代码, 参数: [20084], [18125507], [60], [18125507], [60], [], [], []

这个错误是由于索引内部存在损坏，导致部分键值没有按照顺序存储，而一旦根据索引来顺序访问，或者获取顺序的编号，就会导致错误的产生。
Oracle在MOS文档Ora-00600: Internal Error Code, Arguments: [20084] [ID 434871.1]详细描述了这个问题，给出的解决方法也很简单，根据trace文件中SQL的执行计划，找到发生错误的问题索引，然后对其REBUILD即可。

Posted in BUG | Tagged , , , | Leave a comment

安装11g RAC出现PRCT-1011错误

Posted on 2012/01/18 by yangtingkun

安装RAC数据库出现PRCT-1011错误。
详细错误信息为：

An internal error occurred WITHIN cluster verification framework 
Unable TO obtain network interface list FROM Oracle
ClusterwarePRCT-1011: Failed TO run “oifcfg”. Detailed error: NULL

导致这个错误的原因ORA_NLS1环境变量设置有误。可以将不设置这个环境变量，或将其设置到正确的位置：

unset ORA_NLS10

ORA_NLS10的正确的位置指向$GRID_HOME/nls/data，取消设置或将其设置到正确的位置后，重新启动图形化安装工具既可。
PRCT-1011错误还有可能是OCR中记录的网络设置不正确，具体描述可以参考metalink文档 [ID 1380183.1]。

Posted in ORACLE | Tagged , , | Leave a comment

ORA-600(13030)错误

Posted on 2012/01/17 by yangtingkun

在ITPUB上看到的一个UPDATE RETURN引发的ORA-600错误。
告警日志中错误如下：

Mon Jan 16 09:50:13 2012
Errors IN file /DATA/dir1/app/oracle/admin/moyzkf1/udump/moyzkf1_ora_27801.trc:
ORA-00600: internal error code, arguments: [13030], [1], [], [], [], [], [], []

从对应的TRACE中可以看出，执行的是一个UPDATE RETURN语句：

*** 2012-01-16 09:50:13.236
*** SERVICE NAME:(moyzkf1) 2012-01-16 09:50:13.179
*** SESSION ID:(1981.62963) 2012-01-16 09:50:13.179
updrow: CR error TABLE 0 - rowid: 0001b9c9.0360371b.2 code 1
*** 2012-01-16 09:50:13.236
ksedmp: internal OR fatal error
ORA-00600: internal error code, arguments: [13030], [1], [], [], [], [], [], []
CURRENT SQL statement FOR this SESSION:
UPDATE T_Y_CN20111002_PRIZE SET REMAIN = REMAIN - 1 WHERE ID = (SELECT ID FROM (SELECT ID FROM T_Y_CN20111002_PRIZE WHERE GRADE = :B3 AND REMAIN > 0 AND :B2 BETWEEN BEGINDATE AND ENDDATE AND INSTR(NVL(COVEREDPROVINCES, ',' || :B1 || ','), ',' || :B1 || ',') > 0 ORDER BY DBMS_RANDOM.VALUE(1, 100000)) WHERE ROWNUM < 2) AND REMAIN > 0 AND CAST(DBMS_RANDOM.VALUE(1, PROBABILITY) AS INTEGER) = CAST(DBMS_RANDOM.VALUE(1, PROBABILITY) AS INTEGER) RETURN ID, TITLE, PRESENTFIGURES INTO :O0 ,:O1 ,:O2 
----- PL/SQL Call Stack -----
  object      line  object
  handle    NUMBER  name
0x24fdcddf8      1007  package body P_YZKF.PKG_Y_CN20111002
0x29bb96108         1  anonymous block
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
ksedst()+31          CALL     ksedst1()            000000000 ? 000000001 ?
                                                   7FFFCCDF1840 ? 7FFFCCDF18A0 ?
                                                   7FFFCCDF17E0 ? 000000000 ?
ksedmp()+610         CALL     ksedst()             000000000 ? 000000001 ?
                                                   7FFFCCDF1840 ? 7FFFCCDF18A0 ?
                                                   7FFFCCDF17E0 ? 000000000 ?
ksfdmp()+21          CALL     ksedmp()             000000003 ? 000000001 ?
                                                   7FFFCCDF1840 ? 7FFFCCDF18A0 ?
                                                   7FFFCCDF17E0 ? 000000000 ?
kgeriv()+176         CALL     ksfdmp()             000000003 ? 000000001 ?
                                                   7FFFCCDF1840 ? 7FFFCCDF18A0 ?
                                                   7FFFCCDF17E0 ? 000000000 ?
kgesiv()+119         CALL     kgeriv()             006728580 ? 01D3DFEA0 ?
                                                   000000000 ? 000000000 ?
                                                   7FFFCCDF17E0 ? 000000000 ?
ksesic1()+215        CALL     kgesiv()             006728580 ? 01D3DFEA0 ?
                                                   0000032E6 ? 000000001 ?
                                                   7FFFCCDF25C0 ? 000000000 ?
updrow()+4930        CALL     ksesic1()            0000032E6 ? 000000000 ?
                                                   000000001 ? 000000000 ?
                                                   000000000 ? 000000001 ?
qerupRowProcedure()  CALL     updrow()             25EC23040 ? 000007FFF ?
+80                                                2B16DFD2A018 ? 000000000 ?
                                                   000000000 ? 000000001 ?
qerupFetch()+667     CALL     qerupRowProcedure()  25EC23040 ? 000007FFF ?
                                                   2B16DFD2A018 ? 000000000 ?
                                                   000000000 ? 000000001 ?
updaul()+1065        CALL     qerupFetch()         000000001 ? 000000000 ?
                                                   25EC1AC58 ? 000007FFF ?
                                                   000000000 ? 25EC1AF18 ?
updThreePhaseExe()+  CALL     updaul()             25EC23040 ? 7FFFCCDF3850 ?
3016                                               000000000 ? 2B16DFA5AC78 ?
                                                   000000000 ? 25EC1AF18 ?

查询MOS确认感觉和ORA-600 [13030] On Update Statement [ID 744937.1]描述的Bug 7411865 – OERI:13030 / ORA-1407 / block corruption from UPDATE .. RETURNING DML with trigger非常接近，只有一点感觉有所出入，就是当前的版本是10203，而Bug 7411865是10204补丁集解决bug 5115882时，引入的新的错误。因此，如果当前的10203没有专门取应用patch 5115882，那么应不会碰到这个错误。
因此根据这个推断，Bug 4549673 ORA-30926 / OERI:13030 during update描述的就更为接近一些。
判断到底是哪个问题其实并不复杂，只需要将数据库升级到10.2.0.4既可。在10204中Bug 4549673被fixed，而7411865则仍然存在。
如果将版本升级到10.2.0.4.2或10.2.0.5则这两个bug都会被fixed。

Posted in BUG | Tagged , , , | Leave a comment

收集统计信息报错ORA-1422

Posted on 2012/01/16 by yangtingkun

10.2.0.4环境执行DBMS_STATS包时出现ORA-1422错误。
详细错误信息为：

SQL> EXECUTE  dbms_stats.gather_table_stats(ownname=> USER, tabname=> 'X$KTFBUE')
 BEGIN dbms_stats.gather_table_stats(ownname=> USER, tabname=> 'X$KTFBUE'); END;
 ORA-01422: 实际返回的行数超出请求的行数
 ORA-06512: 在 "SYS.DBMS_STATS", line 13437
 ORA-06512: 在 "SYS.DBMS_STATS", line 13457
 ORA-06512: 在 line 2

查询发现是Oracle10g上的bug，描述信息为：Bug 7430745 ORA-1422 from DBMS_STATS.GATHER_TABLE_STATS on X$KTFBUE。
这个错误是10.2.0.4为了解决bug 5259025而引入的，影响的数据库版本10.2.0.4以及11.1。
解决方法除了Oracle提到的升级到10.2.0.5版本外，将X$KTFBUE表的统计信息LOCK住，从而避免收集这个表的统计应该也可以解决问题。

Posted in BUG | Tagged , , | Leave a comment

ORA-600(2141)错误

Posted on 2012/01/15 by yangtingkun

客户数据库在将STANDBY数据库启用为主库时出现了这个错误。
错误信息为：

Thu Jan 12 08:57:50 2012
Errors IN file /oracle/admin/qtsys/udump/qtsys2_ora_21561380.trc:
ORA-00600: internal error code, arguments: [2141], [3099815372], [0], [], [], [], [], []
Thu Jan 12 08:57:50 2012
Errors IN file /oracle/admin/qtsys/udump/qtsys2_ora_21561380.trc:
ORA-00600: internal error code, arguments: [2141], [3099815372], [0], [], [], [], [], []
Thu Jan 12 08:57:50 2012
Error: Controlfile was changed externally while mounted
Please CHECK IF another Oracle DATABASE IS running
AND accessing the same controlfile

其实从随后的控制文件错误信息也可以基本推断出错误的原因。当前应该还存在另一个实例也在读取相同的控制文件，导致这个问题的原因很可能是之前打开的一个数据库还没有完全关闭导致的。
为了验证这个问题查询了MOS，果然发现了类似的情况：Bug 6908933: ORA-600 [KCBZ_CHECK_OBJD_TYP_3] AND DB CRASH，虽然当前并没有出现ORA-600 [KCBZ_CHECK_OBJD_TYP_3]的错误信息，但是在这篇文章介绍的案例中确实出现ORA-600 [2141]的错误，而且同样的Error: Controlfile was changed externally while mounted信息。
这个bug最终被关闭，由于当前的数据库被两个实例同时打开。由于客户经常需要通过备份建立STANDBY环境并打开，因此出现这个问题也不足为奇。

Posted in ORACLE | Tagged , , | Leave a comment