yangtingkun

ORA-600(KSFD_DECAIOPC)和ORA-600(kfioReapIO00)错误

Posted on 2012/09/20 by yangtingkun

由于共享磁盘问题导致的两个ORA-600错误。
客户的10.2.0.4 RAC for Linux X86-64，在告警日志中出现了大量的错误信息：

Tue Apr 24 16:15:04 2012
Errors IN file /u01/admin/orcl/udump/orcl1_ora_10437.trc:
ORA-00600: internal error code, arguments: [KSFD_DECAIOPC], [0xFC213CBF0], [], [], [], [], [], []
ORA-07445: exception encountered: core dump [<0x9293a0>] [SIGSEGV] [Address NOT mapped TO object] [0x0000007CA] [] []
ORA-07445: exception encountered: core dump [<0xb5814a>] [SIGSEGV] [Address NOT mapped TO object] [0xFFFFFFFFFFFFFFF9] [] []
ORA-00333: redo log READ error block 2 COUNT 8192
ORA-00202: control file: '+ASM_DISK1/orcl/controlfile/current.256.757170241'
ORA-15081: failed TO submit an I/O operation TO a disk
Tue Apr 24 16:15:14 2012
WARNING: kfk failed TO OPEN a disk[/dev/oracleasm/disks/DISK4]
Tue Apr 24 16:15:14 2012
Errors IN file /u01/admin/orcl/udump/orcl1_ora_10437.trc:
ORA-15025: could NOT OPEN disk '/dev/oracleasm/disks/DISK4'
ORA-27041: unable TO OPEN file
Linux-x86_64 Error: 24: Too many OPEN files
Additional information: 3
ORA-00600: internal error code, arguments: [KSFD_DECAIOPC], [0xFC213CBF0], [], [], [], [], [], []
ORA-07445: exception encountered: core dump [<0x9293a0>] [SIGSEGV] [Address NOT mapped TO object] [0x0000007CA] [] []
ORA-07445: exception encountered: core dump [<0xb5814a>] [SIGSEGV] [Address NOT mapped TO object] [0xFFFFFFFFFFFFFFF9] [] []
ORA-00333: redo log READ error block 2 COUNT 8192
ORA-00202: control file: '+ASM_DISK1/orcl/controlfile/current.256.757170241'
ORA-15081: failed TO submit an I/O operation TO a disk
WARNING: kfk failed TO OPEN a disk[/dev/oracleasm/disks/DISK2]

当前的版本10.2.0.4和ORA-600错误信息KSFD_DECAIOPC，都符合bug 8433026的描述，但是当前数据库并未配置STREAM环境，虽然当前库配置了DSG的复制应用，但是毕竟和流应用还是有所区别。
从错误信息可以判断，当前的问题要问题来自ASM磁盘组中部分磁盘存在异常，导致读取时出现错误。
除了KSFD_DECAIOPC错误外，由于底层共享存储的问题，还导致了另外的ORA-600错误：

Tue Jul 10 10:39:53 2012
Errors IN file /u01/admin/orcl/udump/orcl1_ora_19546.trc:
ORA-00600: internal error code, arguments: [kfioReapIO00], [0], [52], [], [], [], [], []
ORA-00333: redo log READ error block 2 COUNT 8192
ORA-00600: internal error code, arguments: [KSFD_DECAIOPC], [0xFC7D6ADB8], [], [], [], [], [], []
ORA-07445: exception encountered: core dump [<0x9293a0>] [SIGSEGV] [Address NOT mapped TO object] [0x0000007CA] [] []
ORA-07445: exception encountered: core dump [<0xb5814a>] [SIGSEGV] [Address NOT mapped TO object] [0xFFFFFFFFFFFFFFF9] [] []
ORA-00333: redo log READ error block 2 COUNT 8192
ORA-00202: control file: '+ASM_DISK1/orcl/controlfile/current.256.757170241'
ORA-15081: failed TO submit an I/O operation TO a disk

显然这两个ORA-600都是由于底层磁盘错误所引起的，而当硬件人员解决了共享磁盘错误后，ASM实例没有经过重启就恢复了正常，此后也没有类似错误的出现。

Posted in BUG | Tagged ASM, kfioReapIO00, KSFD_DECAIOPC, ora-15025, ora-15081, ora-202, ORA-27041, ora-333, ORA-600, ORA-7445 | Leave a comment

ORA-7445(kghfrf)错误

Posted on 2012/09/19 by yangtingkun

又是一个EXADATA上的错误。
数据库版本为11.2.0.2 RAC，错误信息为：

Tue DEC 06 10:34:33 2011
Exception [TYPE: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x908F8BC, kghfrf()+94] [flags: 0x0, COUNT: 1]
Errors IN file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_ora_12085.trc  (incident=42231):
ORA-07445: exception encountered: core dump [kghfrf()+94] [SIGSEGV] [ADDR:0x0] [PC:0x908F8BC] [SI_KERNEL(general_protection)] []
Incident details IN: /u01/app/oracle/diag/rdbms/orcl/orcl1/incident/incdir_42231/orcl1_ora_12085_i42231.trc
USE ADRCI OR Support Workbench TO package the incident.
See Note 411.1 at My Oracle Support FOR error AND packaging details.

根据MOS文档Bug 13780035 Updated fix for bug 13340182 to address additional ORA-7445的信息，这个bug是Oracle在解决问题一个bug时引入的，确认影响的版本包括11.2.0.3和11.2.0.2。Oracle计划在11.2.0.4和12.1中来FIXED这个问题。
不过这个问题并不是每次都可以重现，且并不会造成严重的后果，因此暂时没有解决的方法还尚可接受。

Posted in BUG | Tagged exadata, kghfrf, ORA-7445 | Leave a comment

PLSQL声明部分异常捕获

Posted on 2012/09/18 by yangtingkun

近期在看PL/SQL的文档，发现了很多有趣的小知识点，有的以前知道，也有很多以前并不了解的，写出来和大家分享一下。
这篇描述异常捕获的作用范围。
PL/SQL的异常捕获只针对执行部分，在声明部分产生的异常是无法捕获的：

SQL> SET serverout ON SIZE 100000
SQL> DECLARE
2 v_num NUMBER;
3 BEGIN
4 v_num := 'a';
5 exception
6 WHEN others THEN
7 dbms_output.put_line('Exception captured!');
8 END;
9 /
Exception captured!
PL/SQL PROCEDURE successfully completed.
SQL> DECLARE
2 v_num NUMBER := 'a';
3 BEGIN
4 NULL;
5 exception
6 WHEN others THEN
7 dbms_output.put_line('Exception captured!');
8 END;
9 /
DECLARE
*
ERROR at line 1:
ORA-06502: PL/SQL: NUMERIC OR VALUE error: CHARACTER TO NUMBER conversion error
ORA-06512: at line 2

想要解决声明部分的异常捕获，解决方法是在外面嵌套一层，在外层进行异常的捕获：

SQL> BEGIN
2 DECLARE
3 v_num NUMBER := 'a';
4 BEGIN
5 NULL;
6 exception
7 WHEN others THEN
8 dbms_output.put_line('Exception captured!');
9 END;
10 exception
11 WHEN others THEN
12 dbms_output.put_line('Outer exception captured!');
13 END;
14 /
OUTER exception captured!
PL/SQL PROCEDURE successfully completed.

除了声明部分，异常处理部分本身导致的异常同样也是无法捕获的，解决方法和声明部分一样，需要在外层进行捕获。

Posted in ORACLE | Tagged declare, exception, pl/sql | Leave a comment

SQLPLUS小技巧带行号PLSQL的粘贴

Posted on 2012/09/17 by yangtingkun

前两天写了一篇如何在SQLPLUS中粘贴SQL语句，但是改方法对于SQL有效，对于PL/SQL语句则存在一些小问题。
SQLPLUS小技巧带行号SQL的粘贴：https://yangtingkun.net/?p=1167
还是在sqlplus中粘贴带行号的问题，对于PL/SQL，之前给出的方法存在问题：

SQL> DECLARE
  2  V_NUM NUMBER;
  3  BEGIN
  4  FOR I IN 1..10000 LOOP
  5  NULL;
  6  END LOOP;
  7  END;
  8  /
PL/SQL PROCEDURE successfully completed.
SQL> DECLARE
  2  .
SQL>   2  V_NUM NUMBER;
SQL>   3  BEGIN
SQL>   4  FOR I IN 1..10000 LOOP
SQL>   5  NULL;
SQL>   6  END LOOP;
SQL>   7  END;
SQL> R
  1  DECLARE
  2   V_NUM NUMBER
  3   BEGIN
  4   FOR I IN 1..10000 LOOP
  5   NULL
  6   END LOOP
  7*  END
 BEGIN
 *
ERROR at line 3:
ORA-06550: line 3, COLUMN 2:
PLS-00103: Encountered the symbol "BEGIN" WHEN expecting one OF the following:
:= . ( @ % ; NOT NULL range DEFAULT CHARACTER
The symbol ";" was substituted FOR "BEGIN" TO continue.
ORA-06550: line 6, COLUMN 2:
PLS-00103: Encountered the symbol "END" WHEN expecting one OF the following:
;

其实导致问题的根源很简单，就是分号;造成的。对于SQL语句，分号作为语句的结束符，而对于PL/SQL语句则不然，因此在粘贴的过程中，所有的分号丢失，造成了PL/SQL语句的错误。
解决这个问题很简单，方法和粘贴SQL并无差别，唯一需要做的是，在粘贴PL/SQL代码前将SQL语句的终结符改为/：

SQL> SHOW SQLT
sqlterminator ";" (hex 3b)
SQL> SET SQLT '/'
SQL> DECLARE
  2  .
SQL>   2  V_NUM NUMBER;
SQL>   3  BEGIN
SQL>   4  FOR I IN 1..10000 LOOP
SQL>   5  NULL;
SQL>   6  END LOOP;
SQL>   7  END;
SQL> R
  1  DECLARE
  2   V_NUM NUMBER;
  3   BEGIN
  4   FOR I IN 1..10000 LOOP
  5   NULL;
  6   END LOOP;
  7*  END;
PL/SQL PROCEDURE successfully completed.

Posted in ORACLE | Tagged line number, paste, pl/sql, sql, sqlplus, SQLTERMINATOR | Leave a comment

Oracle10g升级时出现主目录不兼容错误

Posted on 2012/09/16 by yangtingkun

客户咨询在Windows环境下升级10201到10204，碰到一个错误。

由于是电话沟通，有些内容不是很清楚，大概了解的情况包括：客户是Windows 2003上的10201数据库，从官方下载到10204的升级包，在执行升级过程时，出现了一个错误。

由于没有具体的ORA错误号，电话沟通时也没有听的很清楚具体的错误信息，根据客户反馈的错误信息，ORACLE_HOME不能安装当原有的ORACLE_HOME路径下，而只能安装到新的路径下。

从Oracle 11.2.0.2开始，Oracle采用了新的升级方式，补丁不再安装在原始的ORACLE_HOME路径上，而是安装在一个新的路径中，这样一旦升级出现问题，可以确保ORACLE_HOME的快速恢复。

但是这个11.2开始新特性，印象中10g是没有这个问题的，虽然Windows下的升级日常接触的不多，但是类似的测试总做过几次，印象中没有碰到过类似的情况。

要求客户确认数据库和监听等影响安装的服务都已经处于关闭状态。此外，确认了Oracle没有跳过检查或者强制覆盖的选项，而是报错后直接推出。排除了上面的因素，那么导致升级失败的原因就不多了。

随后客户咨询能否将目录安装在其他位置，然后通过改变ORACLE_HOME以及改变现有SERVICE的方式，来实现升级。由于对于客户目前的问题感到困惑，在没有搞清楚问题的原因之前，建议他不要进行下一步的操作，而是将详细的错误信息发送给我：

上面就是我接收到的安装截图信息。注意我提到的是安装截图，而非升级截图。

很多时候仅凭客户的电话描述是远不够的，但是如果看到现场报错信息，就一目了然了。显然这是在进行数据库的安装操作，而非是升级操作，这也是为什么Oracle强调不能安装在原始ORACLE_HOME目录上的原因。

再次和客户电话沟通，确认了客户所谓从官方下载的升级包，并不是从metalink上下载的，而是从oracle.com上下载的Oracle Database 10g Release 2 (10.2.0.4) for Microsoft Windows Vista x64, Microsoft Windows Server 2008 R2 x64, Windows 7 x64版本，这是一个安装版本而不是升级版本，而且也不是客户Windows2003上可以正确安装的版本。

那么最大的可能性是安装报错，不过如果客户万一安装成功，尝试利用这个版本加载数据库，那么后果可能会非常严重。

看来任何时候都不能相信客户的描述，对于关键性信息，一定要眼见为实。

Posted in ORACLE | Tagged INSTALL, ORACLE_HOME, UPGRADE | Leave a comment

11gr2出现ORA-29280错误

Posted on 2012/09/15 by yangtingkun

客户的11.2.0.3 RAC环境自动运行的JOB报错ORA-29280。
详细错误信息为：

Sat Sep 15 05:59:59 2012 
VKRM started WITH pid=54, OS id=32622 
Sat Sep 15 06:00:09 2012 
Errors IN file /opt/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_j001_32634.trc: 
ORA-12012: error ON auto EXECUTE OF job "ORACLE_OCM"."MGMT_CONFIG_JOB_2_1" 
ORA-29280: invalid directory path 
ORA-06512: at "ORACLE_OCM.MGMT_DB_LL_METRICS", line 2436 
ORA-06512: at line 1

这个问题在升级之前的11.2.0.2版本上没有出现过，显然这是升级到11.2.0.3带来的bug。而报错的JOB所属用户ORACLE_OCM是Oracle配置管理的专属用户。根据文档”ORA-12012: error on auto execute of job ORACLE_OCM.MGMT_CONFIG_JOB_2_1″ And “ORA-29280: invalid directory path” In Database AlertLog [ID 1453959.1]，导致问题的原因是数据库升级到11.2.0.3后，Oracle会启用自动OCM collection，在这个过程中Oracle尝试使用目录ORACLE_OCM_CONFIG_DIR2，但这个目录在创建过程中并未建立。
解决该问题并不复杂，对于不需要使用配置管理器的用户而言，可以简单的DISABLE掉这个JOB，或者直接将ORACLE_OCM用户删除：

EXEC dbms_scheduler.disable('ORACLE_OCM.MGMT_CONFIG_JOB')
EXEC dbms_scheduler.disable('ORACLE_OCM.MGMT_STATS_CONFIG_JOB')

如果需要使用配置管理器，可以通过ORACLE_HOME/ccr/admin/scripts/installCCRSQL脚本来重新设置配置管理器。如果上面的脚本缺失，可以通过先执行ORACLE_HOME/ccr/bin/setupCCR脚本的方式来进行配置。

Posted in BUG | Tagged dbms_scheduler, DISABLE, installCCRSQL, MGMT_CONFIG_JOB, MGMT_CONFIG_JOB_2_1, MGMT_DB_LL_METRICS, MGMT_STATS_CONFIG_JOB, OCM, ORA-12012, ORA-29280, ORACLE_OCM, ORACLE_OCM_CONFIG_DIR2, setupCCR | Leave a comment

ORA-7445(kkfipbr)错误

Posted on 2012/09/14 by yangtingkun

在客户的10.2.0.4 RAC for X86-64环境中碰到了这个错误。
错误信息为：

Fri Apr 27 13:40:20 2012
Errors IN file /opt/app/oracle/admin/ora/udump/ora1_ora_1851.trc:
ORA-07445: exception encountered: core dump [kkfipbr()+8] [SIGSEGV] [Address NOT mapped TO object] [0x000000000] [] []

对应的TRACE文件内容为：

*** 2012-04-27 13:40:20.422
ksedmp: internal OR fatal error
ORA-07445: exception encountered: core dump [kkfipbr()+8] [SIGSEGV] [Address NOT mapped TO object] [0x000000000] [] []
CURRENT SQL statement FOR this SESSION:
SELECT * FROM (SELECT pagetable.*,rownum recordid FROM (SELECT s.id sid,p.id pid,p.name pname, … WHERE rownum <= 7) WHERE recordid >0
----- Call Stack Trace -----
calling              CALL     entry                argument VALUES IN hex      
location             TYPE     point                (? means dubious VALUE)     
-------------------- -------- -------------------- ----------------------------
ksedst()+31          CALL     ksedst1()            000000000 ? 000000001 ?
                                                   2A97153D50 ? 2A97153DB0 ?
                                                   2A97153CF0 ? 000000000 ?
ksedmp()+610         CALL     ksedst()             000000000 ? 000000001 ?
                                                   2A97153D50 ? 2A97153DB0 ?
                                                   2A97153CF0 ? 000000000 ?
ssexhd()+629         CALL     ksedmp()             000000003 ? 000000001 ?
                                                   2A97153D50 ? 2A97153DB0 ?
                                                   2A97153CF0 ? 000000000 ?
__funlockfile()+64   CALL     ssexhd()             00000000B ? 2A97154D70 ?
                                                   2A97154C40 ? 2A97153DB0 ?
                                                   2A97153CF0 ? 000000000 ?
kkfipbr()+8          signal   __funlockfile()      2A976A69B8 ? 000000000 ?
                                                   7FBFFF7C10 ? 000000038 ?
                                                   000000000 ? 000000000 ?
kkfiPatchQbc()+235   CALL     kkfipbr()            2A976A69B8 ? 000000000 ?
                                                   7FBFFF7C10 ? 000000038 ?
                                                   000000000 ? 000000000 ?
qkadrv()+554         CALL     kkfiPatchQbc()       2A976A69B8 ? 000000000 ?
                                                   7FBFFF7C10 ? 000000038 ?
                                                   000000000 ? 000000000 ?
qkadrv()+6219        CALL     qkadrv()             2A972E9D08 ? 000000001 ?
                                                   7FBFFF7C10 ? 000000038 ?
                                                   000000000 ? 000000000 ?
opitca()+1875        CALL     qkadrv()             2A972EAAB8 ? 000000001 ?
                                                   7FBFFF7C10 ? 000000038 ?
                                                   000000000 ? 000000000 ?
kksLoadChild()+9360  CALL     opitca()             2A9779FF20 ? 319327A70 ?
                                                   7FBFFF7C10 ? 000000038 ?
                                                   000000000 ? 000000000 ?
kxsGetRuntimeLock()  CALL     kksLoadChild()       0067B4700 ? 259299DD8 ?
+1353                                              7FBFFFA4D0 ? 000000000 ?
                                                   30DD70C10 ? 2A9779FF20 ?
kksfbc()+15084       CALL     kxsGetRuntimeLock()  0067B4700 ? 2A9779FF20 ?
                                                   7FBFFFA4D0 ? 000000000 ?
                                                   30DD70C10 ? 2A9779FF20 ?
kkspsc0()+1548       CALL     kksfbc()             2A9779FF20 ? 000000003 ?
                                                   000000108 ? 2A975D2188 ?
                                                   00000070D ? 000000000 ?
kksParseCursor()+14  CALL     kkspsc0()            2A97311D08 ? 2A975D2188 ?
2                                                  00000070D ? 000000003 ?
                                                   300A400000006 ? 0000300A4 ?
opiosq0()+1641       CALL     kksParseCursor()     7FBFFFAF18 ? 2A975D2188 ?
                                                   00000070D ? 000000003 ?
                                                   300A400000006 ? 0000300A4 ?
kpooprx()+315        CALL     opiosq0()            000000003 ? 00000000E ?
                                                   7FBFFFB108 ? 0000000A4 ?
                                                   300A400000006 ? 0000300A4 ?
kpoal8()+799         CALL     kpooprx()            7FBFFFE2B4 ? 2A975D2188 ?
                                                   00000070C ? 000000001 ?
                                                   000000000 ? 0000300A4 ?
opiodr()+984         CALL     kpoal8()             00000005E ? 000000017 ?
                                                   7FBFFFE2B0 ? 000000001 ?
                                                   000000001 ? 0000300A4 ?
ttcpip()+1012        CALL     opiodr()             00000005E ? 000000017 ?
                                                   7FBFFFE2B0 ? 000000000 ?
                                                   0059DF750 ? 0000300A4 ?
opitsk()+1322        CALL     ttcpip()             0067BC3D0 ? 000000003 ?
                                                   7FBFFFE2B0 ? 000000000 ?
                                                   7FBFFFDDA8 ? 7FBFFFE418 ?
opiino()+1026        CALL     opitsk()             000000003 ? 000000000 ?
                                                   7FBFFFE2B0 ? 000000001 ?
                                                   000000000 ? 683197600000001 ?
opiodr()+984         CALL     opiino()             00000003C ? 000000004 ?
                                                   7FBFFFF478 ? 000000000 ?
                                                   000000000 ? 683197600000001 ?
opidrv()+547         CALL     opiodr()             00000003C ? 000000004 ?
                                                   7FBFFFF478 ? 000000000 ?
                                                   0059DF200 ? 683197600000001 ?
sou2o()+114          CALL     opidrv()             00000003C ? 000000004 ?
                                                   7FBFFFF478 ? 000000000 ?
                                                   0059DF200 ? 683197600000001 ?
opimai_real()+163    CALL     sou2o()              7FBFFFF450 ? 00000003C ?
                                                   000000004 ? 7FBFFFF478 ?
                                                   0059DF200 ? 683197600000001 ?
main()+116           CALL     opimai_real()        000000002 ? 7FBFFFF4E0 ?
                                                   000000004 ? 7FBFFFF478 ?
                                                   0059DF200 ? 683197600000001 ?
__libc_start_main()  CALL     main()               000000002 ? 7FBFFFF4E0 ?
+219                                               000000004 ? 7FBFFFF478 ?
                                                   0059DF200 ? 683197600000001 ?
_start()+42          CALL     __libc_start_main()  0007139F8 ? 000000002 ?
                                                   7FBFFFF628 ? 0052B4BD0 ?
                                                   000000000 ? 000000002 ?
--------------------- Binary Stack Dump ---------------------

*** 2012-04-27 13:40:20.422 ksedmp: internal or fatal error ORA-07445: exception encountered: core dump [kkfipbr()+8] [SIGSEGV] [Address not mapped to object] [0x000000000] [] [] Current SQL statement for this session: select * from (select pagetable.*,rownum recordid from (select s.id sid,p.id pid,p.name pname, … where rownum <= 7) where recordid >0 ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedst()+31 call ksedst1() 000000000 ? 000000001 ? 2A97153D50 ? 2A97153DB0 ? 2A97153CF0 ? 000000000 ? ksedmp()+610 call ksedst() 000000000 ? 000000001 ? 2A97153D50 ? 2A97153DB0 ? 2A97153CF0 ? 000000000 ? ssexhd()+629 call ksedmp() 000000003 ? 000000001 ? 2A97153D50 ? 2A97153DB0 ? 2A97153CF0 ? 000000000 ? __funlockfile()+64 call ssexhd() 00000000B ? 2A97154D70 ? 2A97154C40 ? 2A97153DB0 ? 2A97153CF0 ? 000000000 ? kkfipbr()+8 signal __funlockfile() 2A976A69B8 ? 000000000 ? 7FBFFF7C10 ? 000000038 ? 000000000 ? 000000000 ? kkfiPatchQbc()+235 call kkfipbr() 2A976A69B8 ? 000000000 ? 7FBFFF7C10 ? 000000038 ? 000000000 ? 000000000 ? qkadrv()+554 call kkfiPatchQbc() 2A976A69B8 ? 000000000 ? 7FBFFF7C10 ? 000000038 ? 000000000 ? 000000000 ? qkadrv()+6219 call qkadrv() 2A972E9D08 ? 000000001 ? 7FBFFF7C10 ? 000000038 ? 000000000 ? 000000000 ? opitca()+1875 call qkadrv() 2A972EAAB8 ? 000000001 ? 7FBFFF7C10 ? 000000038 ? 000000000 ? 000000000 ? kksLoadChild()+9360 call opitca() 2A9779FF20 ? 319327A70 ? 7FBFFF7C10 ? 000000038 ? 000000000 ? 000000000 ? kxsGetRuntimeLock() call kksLoadChild() 0067B4700 ? 259299DD8 ? +1353 7FBFFFA4D0 ? 000000000 ? 30DD70C10 ? 2A9779FF20 ? kksfbc()+15084 call kxsGetRuntimeLock() 0067B4700 ? 2A9779FF20 ? 7FBFFFA4D0 ? 000000000 ? 30DD70C10 ? 2A9779FF20 ? kkspsc0()+1548 call kksfbc() 2A9779FF20 ? 000000003 ? 000000108 ? 2A975D2188 ? 00000070D ? 000000000 ? kksParseCursor()+14 call kkspsc0() 2A97311D08 ? 2A975D2188 ? 2 00000070D ? 000000003 ? 300A400000006 ? 0000300A4 ? opiosq0()+1641 call kksParseCursor() 7FBFFFAF18 ? 2A975D2188 ? 00000070D ? 000000003 ? 300A400000006 ? 0000300A4 ? kpooprx()+315 call opiosq0() 000000003 ? 00000000E ? 7FBFFFB108 ? 0000000A4 ? 300A400000006 ? 0000300A4 ? kpoal8()+799 call kpooprx() 7FBFFFE2B4 ? 2A975D2188 ? 00000070C ? 000000001 ? 000000000 ? 0000300A4 ? opiodr()+984 call kpoal8() 00000005E ? 000000017 ? 7FBFFFE2B0 ? 000000001 ? 000000001 ? 0000300A4 ? ttcpip()+1012 call opiodr() 00000005E ? 000000017 ? 7FBFFFE2B0 ? 000000000 ? 0059DF750 ? 0000300A4 ? opitsk()+1322 call ttcpip() 0067BC3D0 ? 000000003 ? 7FBFFFE2B0 ? 000000000 ? 7FBFFFDDA8 ? 7FBFFFE418 ? opiino()+1026 call opitsk() 000000003 ? 000000000 ? 7FBFFFE2B0 ? 000000001 ? 000000000 ? 683197600000001 ? opiodr()+984 call opiino() 00000003C ? 000000004 ? 7FBFFFF478 ? 000000000 ? 000000000 ? 683197600000001 ? opidrv()+547 call opiodr() 00000003C ? 000000004 ? 7FBFFFF478 ? 000000000 ? 0059DF200 ? 683197600000001 ? sou2o()+114 call opidrv() 00000003C ? 000000004 ? 7FBFFFF478 ? 000000000 ? 0059DF200 ? 683197600000001 ? opimai_real()+163 call sou2o() 7FBFFFF450 ? 00000003C ? 000000004 ? 7FBFFFF478 ? 0059DF200 ? 683197600000001 ? main()+116 call opimai_real() 000000002 ? 7FBFFFF4E0 ? 000000004 ? 7FBFFFF478 ? 0059DF200 ? 683197600000001 ? __libc_start_main() call main() 000000002 ? 7FBFFFF4E0 ? +219 000000004 ? 7FBFFFF478 ? 0059DF200 ? 683197600000001 ? _start()+42 call __libc_start_main() 0007139F8 ? 000000002 ? 7FBFFFF628 ? 0052B4BD0 ? 000000000 ? 000000002 ? --------------------- Binary Stack Dump ---------------------

导致错误的原因是由于SQL语句中出现了ROWNUM，因此Oracle尝试使用FIRST_ROW_N优化模式来进行CBO执行计划的评估，并导致了错误。Oracle在文档Bug 7378625 – Assorted Dumps and Wrong Results from first_rows_k optimization [ID 7378625.8]对这个问题进行了描述。
该问题确认影响10.2.0.4和11.1.0.7版本，并在11.2.0.1和10.2.0.5中进行了解决。除了按照补丁外，对于出现ROWNUM的查询情况，可以考虑设置隐含参数_optimizer_rownum_pred_based_fkr为FALSE来解决。

Posted in BUG | Tagged first_rows_k, kkfipbr, ORA-7445, rownum, _optimizer_rownum_pred_based_fkr | Leave a comment

ORA-7445(opitca)错误

Posted on 2012/09/13 by yangtingkun

10.2.0.4 RAC环境出现ORA-7445[opitca]错误。
错误信息如下：

Wed Oct 19 17:50:41 2011
Errors IN file /opt/app/oracle/admin/ora/udump/ora1_ora_26638.trc:
ORA-07445: exception encountered: core dump [opitca()+4618] [SIGSEGV] [Address NOT mapped TO object] [0x000000000] [] []
Wed Oct 19 17:50:42 2011
Trace dumping IS performing id=[cdmp_20111019175042]
Wed Oct 19 17:53:12 2011
Errors IN file /opt/app/oracle/admin/ora/udump/ora1_ora_12642.trc:
ORA-07445: exception encountered: core dump [opitca()+4618] [SIGSEGV] [Address NOT mapped TO object] [0x000000000] [] []
Wed Oct 19 17:53:13 2011
Trace dumping IS performing id=[cdmp_20111019175313]
Wed Oct 19 17:54:13 2011
Errors IN file /opt/app/oracle/admin/ora/udump/ora1_ora_29512.trc:
ORA-07445: exception encountered: core dump [opitca()+4618] [SIGSEGV] [Address NOT mapped TO object] [0x000000000] [] []
Wed Oct 19 17:54:14 2011
Trace dumping IS performing id=[cdmp_20111019175414]
Wed Oct 19 18:23:02 2011
Errors IN file /opt/app/oracle/admin/ora/udump/ora1_ora_25383.trc:
ORA-07445: exception encountered: core dump [opitca()+4618] [SIGSEGV] [Address NOT mapped TO object] [0x000000000] [] []
Wed Oct 19 18:23:03 2011
Trace dumping IS performing id=[cdmp_20111019182303]

根据MOS文档Bug 6316585 – Dump / OERI from complex view merging [ID 6316585.8]，导致该错误的由于复杂视图合并操作时，在外联接查询块中包含了算术或布尔表达式。
这个错误确认影响的版本包括10.2.0.3和10.2.0.4，Oracle在10.2.0.5和11.1.0.7中FIXED了该问题。由于问题和COMPLEX VIEW MERGE有关，因此设置隐患参数”_complex_view_merging”为FALSE同样可以避免这个错误的产生。

Posted in BUG | Tagged opitca, ORA-7445, outer join, _complex_view_merging | Leave a comment

ORA-7445(_intel_fast_memcpy.A)错误

Posted on 2012/09/12 by yangtingkun

在10.2.0.4 RAC for X86-64环境上出现了ORA-7445[_intel_fast_memcpy.A]的错误。
以前碰到过几次的memcpy有关的错误，但是这个错误函数是第一次碰到：

Sat Apr 7 17:27:11 2012
Errors IN file /opt/app/oracle/admin/orcl/bdump/orcl1_j002_16579.trc:
ORA-07445: exception encountered: core dump [_intel_fast_memcpy.A()+10] [SIGSEGV] [Address NOT mapped TO object] [0x2A9734C000] [] []

本以为这个错误不是太常见，结果查询MOS采发现，原来类似的错误还是很常见的，于是进一步比对详细的TRACE信息：

*** 2012-04-07 17:27:11.099
*** ACTION NAME:() 2012-04-07 17:27:11.099
*** MODULE NAME:() 2012-04-07 17:27:11.099
*** SERVICE NAME:(SYS$USERS) 2012-04-07 17:27:11.099
*** CLIENT ID:() 2012-04-07 17:27:11.099
*** SESSION ID:(4124.53396) 2012-04-07 17:27:11.099
Exception signal: 11 (SIGSEGV), code: 1 (Address NOT mapped TO object), addr: 0x2a9734c000, PC: [0x2a95575608, _intel_fast_memcpy.A()+10]
*** 2012-04-07 17:27:11.129
ksedmp: internal OR fatal error
ORA-07445: exception encountered: core dump [_intel_fast_memcpy.A()+10] [SIGSEGV] [Address NOT mapped TO object] [0x2A9734C000] [] []
CURRENT SQL statement FOR this SESSION:
UPDATE E_INVENTORY SET FREEZN_SIZE = FREEZN_SIZE + (:B2 ) WHERE ID = :B1 
----- PL/SQL Call Stack -----
  object      line  object
  handle    NUMBER  name
0x223a947d8        15  PROCEDURE ECOMMERCE.FREEZEN_UPDATE_JOB
0x3e6922098         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 ?
                                                   2A97153D50 ? 2A97153DB0 ?
                                                   2A97153CF0 ? 000000000 ?
ksedmp()+610         CALL     ksedst()             000000000 ? 000000001 ?
                                                   2A97153D50 ? 2A97153DB0 ?
                                                   2A97153CF0 ? 000000000 ?
ssexhd()+629         CALL     ksedmp()             000000003 ? 000000001 ?
                                                   2A97153D50 ? 2A97153DB0 ?
                                                   2A97153CF0 ? 000000000 ?
__funlockfile()+64   CALL     ssexhd()             00000000B ? 2A97154D70 ?
                                                   2A97154C40 ? 2A97153DB0 ?
                                                   2A97153CF0 ? 000000000 ?
_intel_fast_memcpy.  signal   __funlockfile()      2A9734C000 ? 2A9734C000 ?
A()+10                                             FFFFFFFFFFFFF82E ?
                                                   1FFFFFFFFFFFE12C ?
                                                   2A9733D130 ? 2A9733A430 ?
updgrh()+2927        CALL     _intel_fast_memcpy.  2A9733D138 ? 2A9734C000 ?
                              A()                  1FFFFFFFFFFFE12C ?
                                                   1FFFFFFFFFFFE12C ?
                                                   2A9733D130 ? 2A9733A430 ?
upduaw()+115         CALL     updgrh()             3AB891A30 ? 2A97339F10 ?
                                                   3AB891A30 ?
                                                   1FFFFFFFFFFFE12C ?
                                                   400000001 ? 401C1F878 ?
kdusru()+528         CALL     upduaw()             2A9733B1F8 ? 000000000 ?
                                                   2A9733A1E8 ? 24A9A9EF0 ?
                                                   400000001 ? 401C1F878 ?
kauupd()+450         CALL     kdusru()             2A9733CFA4 ? 000000000 ?
                                                   2A97339F10 ? 000000000 ?
                                                   E1E797900000000 ? 401C1F878 ?
updrow()+1658        CALL     kauupd()             2A9733CFA0 ? 000000000 ?
                                                   2A97339F10 ? 000000000 ?
                                                   3D5FAA0A0 ? 000000007 ?
qerupRowProcedure()  CALL     updrow()             3B3C43ED0 ? 000007FFF ?
+80                                                2A97339F10 ? 000000000 ?
                                                   3D5FAA0A0 ? 000000007 ?
qerupFetch()+667     CALL     qerupRowProcedure()  3B3C43ED0 ? 000007FFF ?
                                                   2A97339F10 ? 000000000 ?
                                                   3D5FAA0A0 ? 000000007 ?
updaul()+1065        CALL     qerupFetch()         000000007 ? 000000000 ?
                                                   226024078 ? 000007FFF ?
                                                   3D5FAA0A0 ? 2260242A8 ?
updThreePhaseExe()+  CALL     updaul()             3B3C43ED0 ? 7FBFFF7290 ?
379                                                000000000 ? 2A9733AF40 ?
                                                   3D5FAA0A0 ? 2260242A8 ?
updexe()+600         CALL     updThreePhaseExe()   3B3C43ED0 ? 000000000 ?
                                                   2A97339F10 ? 7FBFFF73B0 ?
                                                   3D5FAA0A0 ? 2260242A8 ?
opiexe()+4577        CALL     updexe()             3B3C43ED0 ? 000000000 ?
                                                   2A97339F10 ? 7FBFFF73B0 ?
                                                   000000000 ? 2260242A8 ?
opipls()+2025        CALL     opiexe()             000000004 ? 000000005 ?
                                                   7FBFFF89BC ? 00000000D ?
                                                   000000000 ? 2260242A8 ?
opiodr()+984         CALL     opipls()             000000066 ? 000000006 ?
                                                   7FBFFFA0B0 ? 000000000 ?
                                                   2A9769E410 ? 400000000 ?
rpidrus()+198        CALL     opiodr()             000000066 ? 000000006 ?
                                                   7FBFFFA0B0 ? 00000000D ?
                                                   0059DF890 ? 400000000 ?
skgmstack()+158      CALL     rpidrus()            7FBFFF96F8 ? 000000006 ?
                                                   7FBFFFA0B0 ? 00000000D ?
                                                   0059DF890 ? 400000000 ?
rpidru()+116         CALL     skgmstack()          7FBFFF96D0 ? 0067B42E0 ?
                                                   00000F618 ? 0022F61B8 ?
                                                   7FBFFF96F8 ? 400000000 ?
rpiswu2()+420        CALL     rpidru()             7FBFFF9D90 ? 0067B42E0 ?
                                                   00000F618 ? 0022F61B8 ?
                                                   7FBFFF96F8 ? 400000000 ?
rpidrv()+1519        CALL     rpiswu2()            42167D498 ? 000000044 ?
                                                   7FBFFF9D70 ? 000000002 ?
                                                   7FBFFF9DD8 ? 000000044 ?
psddr0()+438         CALL     rpidrv()             00000000D ? 000000066 ?
                                                   7FBFFFA0B0 ? 000000038 ?
                                                   7FBFFF9DD8 ? 000000044 ?
psdnal()+386         CALL     psddr0()             00000000D ? 000000066 ?
                                                   7FBFFFA0B0 ? 000000030 ?
                                                   7FBFFF9DD8 ? 000000044 ?
pevm_EXECC()+376     CALL     psdnal()             7FBFFFABF0 ? 7FBFFFADE0 ?
                                                   7FBFFFA0B0 ? 2A97332EE8 ?
                                                   00000000F ? 000000044 ?
pfrinstr_EXECC()+80  CALL     pevm_EXECC()         2A97335640 ? 7FBFFFADE0 ?
                                                   000000020 ? 2A97332EE8 ?
                                                   00000000F ? 000000044 ?
pfrrun_no_tool()+65  CALL     pfrinstr_EXECC()     2A97335640 ? 18DD12140 ?
                                                   2A973356A8 ? 2A97332EE8 ?
                                                   00000000F ? 7F00000020 ?
pfrrun()+906         CALL     pfrrun_no_tool()     2A97335640 ? 18DD12140 ?
                                                   2A973356A8 ? 2A97332EE8 ?
                                                   00000000F ? 7F00000020 ?
plsql_run()+841      CALL     pfrrun()             2A97335640 ? 000000000 ?
                                                   2A973356A8 ? 7FBFFFABF0 ?
                                                   00000000F ? 3CA6A9264 ?
peicnt()+298         CALL     plsql_run()          2A97335640 ? 000000001 ?
                                                   000000000 ? 7FBFFFABF0 ?
                                                   00000000F ? 900000000 ?
kkxexe()+503         CALL     peicnt()             7FBFFFABF0 ? 2A97335640 ?
                                                   2A97308830 ? 7FBFFFABF0 ?
                                                   2A973067D8 ? 900000000 ?
opiexe()+4691        CALL     kkxexe()             2A97336890 ? 2A97335640 ?
                                                   2A97308830 ? 4095E69F0 ?
                                                   0040F066F ? 900000000 ?
opiodr()+984         CALL     opiexe()             000000004 ? 000000004 ?
                                                   7FBFFFCFB0 ? 000000005 ?
                                                   0040F066F ? 900000000 ?
rpidrus()+198        CALL     opiodr()             000000004 ? 000000004 ?
                                                   7FBFFFCFB0 ? 000000005 ?
                                                   0059DE940 ? 900000000 ?
skgmstack()+158      CALL     rpidrus()            7FBFFFC808 ? 000000004 ?
                                                   7FBFFFCFB0 ? 000000005 ?
                                                   0059DE940 ? 900000000 ?
rpidru()+116         CALL     skgmstack()          7FBFFFC7E0 ? 0067B42E0 ?
                                                   00000F618 ? 0022F61B8 ?
                                                   7FBFFFC808 ? 900000000 ?
rpiswu2()+420        CALL     rpidru()             7FBFFFCEA0 ? 0067B42E0 ?
                                                   00000F618 ? 0022F61B8 ?
                                                   7FBFFFC808 ? 900000000 ?
rpidrv()+1519        CALL     rpiswu2()            42167D498 ? 000000044 ?
                                                   7FBFFFCE80 ? 000000002 ?
                                                   7FBFFFCEE8 ? 100000044 ?
rpiexe()+65          CALL     rpidrv()             000000005 ? 000000004 ?
                                                   7FBFFFCFB0 ? 00000000A ?
                                                   7FBFFFCEE8 ? 100000044 ?
kkjex1e()+7155       CALL     rpiexe()             000000005 ? 000000004 ?
                                                   7FBFFFCFB0 ? 00000000A ?
                                                   7FBFFFCEE8 ? 100000044 ?
kkjsexe()+339        CALL     kkjex1e()            7FBFFFDD4C ? 0000001B9 ?
                                                   000000000 ? 7FBFFFDD30 ?
                                                   4285C8110 ?
                                                   BFFF000700000001 ?
kkjrdp()+892         CALL     kkjsexe()            7FBFFFDD4C ? 0000001B9 ?
                                                   000000000 ? 000000001 ?
                                                   4285C8110 ?
                                                   BFFF000700000001 ?
opirip()+1140        CALL     kkjrdp()             7FBFFFDD4C ? 0000001B9 ?
                                                   000000000 ? 000000001 ?
                                                   4285C8110 ?
                                                   BFFF000700000001 ?
opidrv()+582         CALL     opirip()             000000032 ? 000000004 ?
                                                   7FBFFFF438 ? 000000001 ?
                                                   4285C8110 ?
                                                   BFFF000700000001 ?
sou2o()+114          CALL     opidrv()             000000032 ? 000000004 ?
                                                   7FBFFFF438 ? 000000001 ?
                                                   4285C8110 ?
                                                   BFFF000700000001 ?
opimai_real()+317    CALL     sou2o()              7FBFFFF410 ? 000000032 ?
                                                   000000004 ? 7FBFFFF438 ?
                                                   4285C8110 ?
                                                   BFFF000700000001 ?
main()+116           CALL     opimai_real()        000000003 ? 7FBFFFF4A0 ?
                                                   000000004 ? 7FBFFFF438 ?
                                                   4285C8110 ?
                                                   BFFF000700000001 ?
__libc_start_main()  CALL     main()               000000003 ? 7FBFFFF4A0 ?
+219                                               000000004 ? 7FBFFFF438 ?
                                                   4285C8110 ?
                                                   BFFF000700000001 ?
_start()+42          CALL     __libc_start_main()  0007139F8 ? 000000001 ?
                                                   7FBFFFF5E8 ? 0052B4BD0 ?
                                                   000000000 ? 000000003 ?
--------------------- Binary Stack Dump ---------------------

*** 2012-04-07 17:27:11.099 *** ACTION NAME:() 2012-04-07 17:27:11.099 *** MODULE NAME:() 2012-04-07 17:27:11.099 *** SERVICE NAME:(SYS$USERS) 2012-04-07 17:27:11.099 *** CLIENT ID:() 2012-04-07 17:27:11.099 *** SESSION ID:(4124.53396) 2012-04-07 17:27:11.099 Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x2a9734c000, PC: [0x2a95575608, _intel_fast_memcpy.A()+10] *** 2012-04-07 17:27:11.129 ksedmp: internal or fatal error ORA-07445: exception encountered: core dump [_intel_fast_memcpy.A()+10] [SIGSEGV] [Address not mapped to object] [0x2A9734C000] [] [] Current SQL statement for this session: UPDATE E_INVENTORY SET FREEZN_SIZE = FREEZN_SIZE + (:B2 ) WHERE ID = :B1 ----- PL/SQL Call Stack ----- object line object handle number name 0x223a947d8 15 procedure ECOMMERCE.FREEZEN_UPDATE_JOB 0x3e6922098 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 ? 2A97153D50 ? 2A97153DB0 ? 2A97153CF0 ? 000000000 ? ksedmp()+610 call ksedst() 000000000 ? 000000001 ? 2A97153D50 ? 2A97153DB0 ? 2A97153CF0 ? 000000000 ? ssexhd()+629 call ksedmp() 000000003 ? 000000001 ? 2A97153D50 ? 2A97153DB0 ? 2A97153CF0 ? 000000000 ? __funlockfile()+64 call ssexhd() 00000000B ? 2A97154D70 ? 2A97154C40 ? 2A97153DB0 ? 2A97153CF0 ? 000000000 ? _intel_fast_memcpy. signal __funlockfile() 2A9734C000 ? 2A9734C000 ? A()+10 FFFFFFFFFFFFF82E ? 1FFFFFFFFFFFE12C ? 2A9733D130 ? 2A9733A430 ? updgrh()+2927 call _intel_fast_memcpy. 2A9733D138 ? 2A9734C000 ? A() 1FFFFFFFFFFFE12C ? 1FFFFFFFFFFFE12C ? 2A9733D130 ? 2A9733A430 ? upduaw()+115 call updgrh() 3AB891A30 ? 2A97339F10 ? 3AB891A30 ? 1FFFFFFFFFFFE12C ? 400000001 ? 401C1F878 ? kdusru()+528 call upduaw() 2A9733B1F8 ? 000000000 ? 2A9733A1E8 ? 24A9A9EF0 ? 400000001 ? 401C1F878 ? kauupd()+450 call kdusru() 2A9733CFA4 ? 000000000 ? 2A97339F10 ? 000000000 ? E1E797900000000 ? 401C1F878 ? updrow()+1658 call kauupd() 2A9733CFA0 ? 000000000 ? 2A97339F10 ? 000000000 ? 3D5FAA0A0 ? 000000007 ? qerupRowProcedure() call updrow() 3B3C43ED0 ? 000007FFF ? +80 2A97339F10 ? 000000000 ? 3D5FAA0A0 ? 000000007 ? qerupFetch()+667 call qerupRowProcedure() 3B3C43ED0 ? 000007FFF ? 2A97339F10 ? 000000000 ? 3D5FAA0A0 ? 000000007 ? updaul()+1065 call qerupFetch() 000000007 ? 000000000 ? 226024078 ? 000007FFF ? 3D5FAA0A0 ? 2260242A8 ? updThreePhaseExe()+ call updaul() 3B3C43ED0 ? 7FBFFF7290 ? 379 000000000 ? 2A9733AF40 ? 3D5FAA0A0 ? 2260242A8 ? updexe()+600 call updThreePhaseExe() 3B3C43ED0 ? 000000000 ? 2A97339F10 ? 7FBFFF73B0 ? 3D5FAA0A0 ? 2260242A8 ? opiexe()+4577 call updexe() 3B3C43ED0 ? 000000000 ? 2A97339F10 ? 7FBFFF73B0 ? 000000000 ? 2260242A8 ? opipls()+2025 call opiexe() 000000004 ? 000000005 ? 7FBFFF89BC ? 00000000D ? 000000000 ? 2260242A8 ? opiodr()+984 call opipls() 000000066 ? 000000006 ? 7FBFFFA0B0 ? 000000000 ? 2A9769E410 ? 400000000 ? rpidrus()+198 call opiodr() 000000066 ? 000000006 ? 7FBFFFA0B0 ? 00000000D ? 0059DF890 ? 400000000 ? skgmstack()+158 call rpidrus() 7FBFFF96F8 ? 000000006 ? 7FBFFFA0B0 ? 00000000D ? 0059DF890 ? 400000000 ? rpidru()+116 call skgmstack() 7FBFFF96D0 ? 0067B42E0 ? 00000F618 ? 0022F61B8 ? 7FBFFF96F8 ? 400000000 ? rpiswu2()+420 call rpidru() 7FBFFF9D90 ? 0067B42E0 ? 00000F618 ? 0022F61B8 ? 7FBFFF96F8 ? 400000000 ? rpidrv()+1519 call rpiswu2() 42167D498 ? 000000044 ? 7FBFFF9D70 ? 000000002 ? 7FBFFF9DD8 ? 000000044 ? psddr0()+438 call rpidrv() 00000000D ? 000000066 ? 7FBFFFA0B0 ? 000000038 ? 7FBFFF9DD8 ? 000000044 ? psdnal()+386 call psddr0() 00000000D ? 000000066 ? 7FBFFFA0B0 ? 000000030 ? 7FBFFF9DD8 ? 000000044 ? pevm_EXECC()+376 call psdnal() 7FBFFFABF0 ? 7FBFFFADE0 ? 7FBFFFA0B0 ? 2A97332EE8 ? 00000000F ? 000000044 ? pfrinstr_EXECC()+80 call pevm_EXECC() 2A97335640 ? 7FBFFFADE0 ? 000000020 ? 2A97332EE8 ? 00000000F ? 000000044 ? pfrrun_no_tool()+65 call pfrinstr_EXECC() 2A97335640 ? 18DD12140 ? 2A973356A8 ? 2A97332EE8 ? 00000000F ? 7F00000020 ? pfrrun()+906 call pfrrun_no_tool() 2A97335640 ? 18DD12140 ? 2A973356A8 ? 2A97332EE8 ? 00000000F ? 7F00000020 ? plsql_run()+841 call pfrrun() 2A97335640 ? 000000000 ? 2A973356A8 ? 7FBFFFABF0 ? 00000000F ? 3CA6A9264 ? peicnt()+298 call plsql_run() 2A97335640 ? 000000001 ? 000000000 ? 7FBFFFABF0 ? 00000000F ? 900000000 ? kkxexe()+503 call peicnt() 7FBFFFABF0 ? 2A97335640 ? 2A97308830 ? 7FBFFFABF0 ? 2A973067D8 ? 900000000 ? opiexe()+4691 call kkxexe() 2A97336890 ? 2A97335640 ? 2A97308830 ? 4095E69F0 ? 0040F066F ? 900000000 ? opiodr()+984 call opiexe() 000000004 ? 000000004 ? 7FBFFFCFB0 ? 000000005 ? 0040F066F ? 900000000 ? rpidrus()+198 call opiodr() 000000004 ? 000000004 ? 7FBFFFCFB0 ? 000000005 ? 0059DE940 ? 900000000 ? skgmstack()+158 call rpidrus() 7FBFFFC808 ? 000000004 ? 7FBFFFCFB0 ? 000000005 ? 0059DE940 ? 900000000 ? rpidru()+116 call skgmstack() 7FBFFFC7E0 ? 0067B42E0 ? 00000F618 ? 0022F61B8 ? 7FBFFFC808 ? 900000000 ? rpiswu2()+420 call rpidru() 7FBFFFCEA0 ? 0067B42E0 ? 00000F618 ? 0022F61B8 ? 7FBFFFC808 ? 900000000 ? rpidrv()+1519 call rpiswu2() 42167D498 ? 000000044 ? 7FBFFFCE80 ? 000000002 ? 7FBFFFCEE8 ? 100000044 ? rpiexe()+65 call rpidrv() 000000005 ? 000000004 ? 7FBFFFCFB0 ? 00000000A ? 7FBFFFCEE8 ? 100000044 ? kkjex1e()+7155 call rpiexe() 000000005 ? 000000004 ? 7FBFFFCFB0 ? 00000000A ? 7FBFFFCEE8 ? 100000044 ? kkjsexe()+339 call kkjex1e() 7FBFFFDD4C ? 0000001B9 ? 000000000 ? 7FBFFFDD30 ? 4285C8110 ? BFFF000700000001 ? kkjrdp()+892 call kkjsexe() 7FBFFFDD4C ? 0000001B9 ? 000000000 ? 000000001 ? 4285C8110 ? BFFF000700000001 ? opirip()+1140 call kkjrdp() 7FBFFFDD4C ? 0000001B9 ? 000000000 ? 000000001 ? 4285C8110 ? BFFF000700000001 ? opidrv()+582 call opirip() 000000032 ? 000000004 ? 7FBFFFF438 ? 000000001 ? 4285C8110 ? BFFF000700000001 ? sou2o()+114 call opidrv() 000000032 ? 000000004 ? 7FBFFFF438 ? 000000001 ? 4285C8110 ? BFFF000700000001 ? opimai_real()+317 call sou2o() 7FBFFFF410 ? 000000032 ? 000000004 ? 7FBFFFF438 ? 4285C8110 ? BFFF000700000001 ? main()+116 call opimai_real() 000000003 ? 7FBFFFF4A0 ? 000000004 ? 7FBFFFF438 ? 4285C8110 ? BFFF000700000001 ? __libc_start_main() call main() 000000003 ? 7FBFFFF4A0 ? +219 000000004 ? 7FBFFFF438 ? 4285C8110 ? BFFF000700000001 ? _start()+42 call __libc_start_main() 0007139F8 ? 000000001 ? 7FBFFFF5E8 ? 0052B4BD0 ? 000000000 ? 000000003 ? --------------------- Binary Stack Dump ---------------------

根据错误堆栈对比，确认属于ORA-07445 [_memcpy] And/Or [_memmove] And/Or ORA-07445 [kgidum] And/Or [kgscDump]during updates in 9.2.0.8 or 10.2.0.4 [ID 729206.1]描述的未发布BUG 5868257。
这个错误是在进行UPDATE操作时导致了内存结构损坏，这个错误发生在9.2.0.8和10.2.0.4环境下，是由于解决了Bug 4549673而引入的。
解决方法包括升级到10.2.0.5或11.1.0.6，或者针对特定的平台打Patch 5868257。除了这些方法外，由于问题和行迁移有关，对出现错误的表进行MOVE来消除行迁移，也可以避免错误的产生。

Posted in BUG | Tagged ORA-7445, row migrate, update, _intel_fast_memcpy.A | Leave a comment

ORA-7445(kqlSubheapPin)错误

Posted on 2012/09/11 by yangtingkun

Oracle 10.2.0.4 for X86-64数据库出现ORA-7445[kqlSubheapPin]错误。
错误信息为：

Tue Jul 26 13:27:05 2011
Errors IN file /opt/app/oracle/admin/ora/udump/ora1_ora_6729.trc:
ORA-07445: exception encountered: core dump [kqlSubheapPin()+84] [SIGSEGV] [Address NOT mapped TO object] [0x000000110] [] []

根据MOS文档Bug 7280764 – Dump from concurrent CREATE MV and query rewrite or DDL [ID 7280764.8]的记录，这个bug是在创建物化视图日志的同时，对物化视图的基表执行了DDL操作，导致物化视图创建会话在一定时间内无法获取锁而导致的异常错误。
这个问题在10.2.0.4.3和10.2.0.5中被fixed，这个错误对数据库的影响不大，也不一定要通过补丁来解决该问题，在创建物化视图的时候避免对基表的操作就可以避免该错误的产生。

Posted in BUG | Tagged DDL, kqlSubheapPin, LOCK, Materialized view, MV, ORA-7445, QUERY REWRITE | Leave a comment

yangtingkun

ORA-600(KSFD_DECAIOPC)和ORA-600(kfioReapIO00)错误

ORA-7445(kghfrf)错误

PLSQL声明部分异常捕获

SQLPLUS小技巧带行号PLSQL的粘贴

Oracle10g升级时出现主目录不兼容错误

11gr2出现ORA-29280错误

ORA-7445(kkfipbr)错误

ORA-7445(opitca)错误

ORA-7445(_intel_fast_memcpy.A)错误

ORA-7445(kqlSubheapPin)错误

Recent Posts

Recent Comments

Archives

Categories

Meta