ORA-7445(kdodpm)错误
===========================================================
作者: yangtingkun(http://yangtingkun.itpub.net)
发表于: 2009.07.31 23:02
分类: ORACLE , Bug
出处: [url]http://yangtingkun.itpub.net/post/468/488625[/url]
---------------------------------------------------------------
在进行LOGMINER操作的时候碰到了这个错误。
由于要查看程序删除的一些记录,因此通过LOGMINER对重做日志进行LOGMINER操作:
SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
会话已更改。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
------ ------- --------- ---------- ------- --- --------- ------------- -------------------
1 1 3285 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-28 00:00:08
2 1 3286 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-28 00:02:20
3 1 3287 1073741824 2 NO CURRENT 1.1124E+12 2009-07-28 01:00:13
4 1 3284 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-27 01:00:30
5 2 1457 1073741824 2 NO CURRENT 1.1124E+12 2009-07-27 23:53:27
6 2 1454 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-26 00:25:45
7 2 1455 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-26 00:26:39
8 2 1456 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-26 23:53:34
已选择8行。
发现要处理的是当前的日志文件:
SQL> select member from v$logfile where group# in (3, 5);
MEMBER
--------------------------------------------------
/dev/vx/rdsk/datadg/tradedb_redo1_3_1_1g
/dev/vx/rdsk/datadg/tradedb_redo1_3_2_1g
/dev/vx/rdsk/datadg/tradedb_redo2_1_1_1g
/dev/vx/rdsk/datadg/tradedb_redo2_1_2_1g
SQL> exec dbms_logmnr.add_logfile('/dev/vx/rdsk/datadg/tradedb_redo1_3_1_1g', dbms_logmnr.new)
PL/SQL 过程已成功完成。
SQL> exec dbms_logmnr.add_logfile('/dev/vx/rdsk/datadg/tradedb_redo2_1_1_1g', dbms_logmnr.addfile)
PL/SQL 过程已成功完成。
SQL> exec dbms_logmnr.start_logmnr(options=> dbms_logmnr.dict_from_online_catalog)
PL/SQL 过程已成功完成。
SQL> create table t_logminer tablespace sysaux
2 as select * from v$logmnr_contents where seg_owner = 'ZHEJIANG' and seg_name = 'LP_PRICE_PROCESS';
create table t_logminer tablespace sysaux
*第 1 行出现错误:
ORA-03113: 通信通道的文件结束
SQL> exec dbms_logmnr.end_logmnr
ERROR:
ORA-03114: 未连接到 ORALCE
前台出现ORA-3113错误,后台多半出现ORA-7445或ORA-600错误,检查alert文件:
Tue Jul 28 16:04:24 2009
Errors in file /opt/oracle/admin/tradedb/udump/tradedb1_ora_10798.trc:
ORA-07445: 出现异常错误: 核心转储 [kdodpm()+2068] [SIGSEGV] [Invalid permissions for mapped object] [0xFFFFFFFF79270002] [] []
果然出现了ORA-7445错误,错误参数为kdodpm,检查对应的trace文件:
*** 2009-07-28 15:59:15.046
*** SERVICE NAME:(SYS$USERS) 2009-07-28 15:59:15.027
*** SESSION ID:(282.47827) 2009-07-28 15:59:15.027
* kjdrpkey2hv: called with pkey 207480, options x8
*** 2009-07-28 16:04:24.179
Exception signal: 11 (SIGSEGV), code: 2 (Invalid permissions for mapped object), addr: 0xffffffff79270002, PC: [0x10285aa34, kdodpm(
)+2068]
*** 2009-07-28 16:04:24.186
ksedmp: internal or fatal error
ORA-07445: 出现异常错误: 核心转储 [kdodpm()+2068] [SIGSEGV] [Invalid permissions for mapped object] [0xFFFFFFFF79270002] [] []
Current SQL statement for this session:
create table t_logminer tablespace sysaux
as select * from v$logmnr_contents where seg_owner = 'ZHEJIANG' and seg_name = 'LP_PRICE_PROCESS'
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+744 CALL ksedst() 000000300 ? 1066DE17C ?
000000000 ? 1066DAC70 ?
1066D99D8 ? 1066DA3D8 ?
ssexhd()+1240 CALL ksedmp() 000106400 ? 10652D264 ?
10652D000 ? 00010652D ?
000106400 ? 10652D264 ?
__sighndlr()+12 PTR_CALL 0000000000000000 10652A000 ? 1066E1EF0 ?
10652722C ? 00010652A ?
00000000B ? 000000067 ?
call_user_handler() CALL __sighndlr() 00000000B ? 1066E1EF0 ?
+992 1066E1C10 ? 10033B1C0 ?
000000000 ? 00000000A ?
在metalink没有发现和当前现象一致的描述。
显然问题是LOGMINER操作造成的,如果说这个LOGMINER操作与其他普通的LOGMINER有什么不同的话,那么主要是两点,一个是当前是RAC环境,LOGMINER同时对两个实例的日志进行分析;另一个是当前分析的是系统当前的日志。
由于RAC环境的日志对于任何一个实例都是可以访问的,因此理论上不大可能出现上面的问题,莫非是当前日志造成的问题,切换当前日志,然后再次执行同样的操作:
SQL> conn / as sysdba已连接。
SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
会话已更改。
SQL> select group#, status from v$log where status = 'CURRENT';
GROUP# STATUS
---------- ----------------
3 CURRENT
5 CURRENT
已选择2行。
SQL> select member from v$logfile where group# in (3, 5);
MEMBER
--------------------------------------------------
/dev/vx/rdsk/datadg/tradedb_redo1_3_1_1g
/dev/vx/rdsk/datadg/tradedb_redo1_3_2_1g
/dev/vx/rdsk/datadg/tradedb_redo2_1_1_1g
/dev/vx/rdsk/datadg/tradedb_redo2_1_2_1g
已选择4行。
SQL> alter system archive log current;
系统已更改。
SQL> select group#, status from v$log where status = 'CURRENT';
GROUP# STATUS
---------- ----------------
4 CURRENT
6 CURRENT
已选择2行。
SQL> exec dbms_logmnr.add_logfile('/dev/vx/rdsk/datadg/tradedb_redo1_3_1_1g', dbms_logmnr.new)
PL/SQL 过程已成功完成。
SQL> exec dbms_logmnr.add_logfile('/dev/vx/rdsk/datadg/tradedb_redo2_1_1_1g', dbms_logmnr.addfile)
PL/SQL 过程已成功完成。
SQL> exec dbms_logmnr.start_logmnr(options=> dbms_logmnr.dict_from_online_catalog)
PL/SQL 过程已成功完成。
SQL> create table t_logminer tablespace sysaux
2 as select * from v$logmnr_contents
3 where seg_owner = 'ZHEJIANG'
4 and seg_name = 'LP_PRICE_PROCESS';
表已创建。
问题解决。在出现错误的时候不要着急,冷静的思考当前的操作有何特殊之处,往往可以迅速的定位并解决问题。
===========================================================
作者: yangtingkun(http://yangtingkun.itpub.net)
发表于: 2009.07.31 23:02
分类: ORACLE , Bug
出处: [url]http://yangtingkun.itpub.net/post/468/488625[/url]
---------------------------------------------------------------
在进行LOGMINER操作的时候碰到了这个错误。
由于要查看程序删除的一些记录,因此通过LOGMINER对重做日志进行LOGMINER操作:
SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
会话已更改。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
------ ------- --------- ---------- ------- --- --------- ------------- -------------------
1 1 3285 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-28 00:00:08
2 1 3286 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-28 00:02:20
3 1 3287 1073741824 2 NO CURRENT 1.1124E+12 2009-07-28 01:00:13
4 1 3284 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-27 01:00:30
5 2 1457 1073741824 2 NO CURRENT 1.1124E+12 2009-07-27 23:53:27
6 2 1454 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-26 00:25:45
7 2 1455 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-26 00:26:39
8 2 1456 1073741824 2 YES INACTIVE 1.1124E+12 2009-07-26 23:53:34
已选择8行。
发现要处理的是当前的日志文件:
SQL> select member from v$logfile where group# in (3, 5);
MEMBER
--------------------------------------------------
/dev/vx/rdsk/datadg/tradedb_redo1_3_1_1g
/dev/vx/rdsk/datadg/tradedb_redo1_3_2_1g
/dev/vx/rdsk/datadg/tradedb_redo2_1_1_1g
/dev/vx/rdsk/datadg/tradedb_redo2_1_2_1g
SQL> exec dbms_logmnr.add_logfile('/dev/vx/rdsk/datadg/tradedb_redo1_3_1_1g', dbms_logmnr.new)
PL/SQL 过程已成功完成。
SQL> exec dbms_logmnr.add_logfile('/dev/vx/rdsk/datadg/tradedb_redo2_1_1_1g', dbms_logmnr.addfile)
PL/SQL 过程已成功完成。
SQL> exec dbms_logmnr.start_logmnr(options=> dbms_logmnr.dict_from_online_catalog)
PL/SQL 过程已成功完成。
SQL> create table t_logminer tablespace sysaux
2 as select * from v$logmnr_contents where seg_owner = 'ZHEJIANG' and seg_name = 'LP_PRICE_PROCESS';
create table t_logminer tablespace sysaux
*第 1 行出现错误:
ORA-03113: 通信通道的文件结束
SQL> exec dbms_logmnr.end_logmnr
ERROR:
ORA-03114: 未连接到 ORALCE
前台出现ORA-3113错误,后台多半出现ORA-7445或ORA-600错误,检查alert文件:
Tue Jul 28 16:04:24 2009
Errors in file /opt/oracle/admin/tradedb/udump/tradedb1_ora_10798.trc:
ORA-07445: 出现异常错误: 核心转储 [kdodpm()+2068] [SIGSEGV] [Invalid permissions for mapped object] [0xFFFFFFFF79270002] [] []
果然出现了ORA-7445错误,错误参数为kdodpm,检查对应的trace文件:
*** 2009-07-28 15:59:15.046
*** SERVICE NAME:(SYS$USERS) 2009-07-28 15:59:15.027
*** SESSION ID:(282.47827) 2009-07-28 15:59:15.027
* kjdrpkey2hv: called with pkey 207480, options x8
*** 2009-07-28 16:04:24.179
Exception signal: 11 (SIGSEGV), code: 2 (Invalid permissions for mapped object), addr: 0xffffffff79270002, PC: [0x10285aa34, kdodpm(
)+2068]
*** 2009-07-28 16:04:24.186
ksedmp: internal or fatal error
ORA-07445: 出现异常错误: 核心转储 [kdodpm()+2068] [SIGSEGV] [Invalid permissions for mapped object] [0xFFFFFFFF79270002] [] []
Current SQL statement for this session:
create table t_logminer tablespace sysaux
as select * from v$logmnr_contents where seg_owner = 'ZHEJIANG' and seg_name = 'LP_PRICE_PROCESS'
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+744 CALL ksedst() 000000300 ? 1066DE17C ?
000000000 ? 1066DAC70 ?
1066D99D8 ? 1066DA3D8 ?
ssexhd()+1240 CALL ksedmp() 000106400 ? 10652D264 ?
10652D000 ? 00010652D ?
000106400 ? 10652D264 ?
__sighndlr()+12 PTR_CALL 0000000000000000 10652A000 ? 1066E1EF0 ?
10652722C ? 00010652A ?
00000000B ? 000000067 ?
call_user_handler() CALL __sighndlr() 00000000B ? 1066E1EF0 ?
+992 1066E1C10 ? 10033B1C0 ?
000000000 ? 00000000A ?
在metalink没有发现和当前现象一致的描述。
显然问题是LOGMINER操作造成的,如果说这个LOGMINER操作与其他普通的LOGMINER有什么不同的话,那么主要是两点,一个是当前是RAC环境,LOGMINER同时对两个实例的日志进行分析;另一个是当前分析的是系统当前的日志。
由于RAC环境的日志对于任何一个实例都是可以访问的,因此理论上不大可能出现上面的问题,莫非是当前日志造成的问题,切换当前日志,然后再次执行同样的操作:
SQL> conn / as sysdba已连接。
SQL> alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';
会话已更改。
SQL> select group#, status from v$log where status = 'CURRENT';
GROUP# STATUS
---------- ----------------
3 CURRENT
5 CURRENT
已选择2行。
SQL> select member from v$logfile where group# in (3, 5);
MEMBER
--------------------------------------------------
/dev/vx/rdsk/datadg/tradedb_redo1_3_1_1g
/dev/vx/rdsk/datadg/tradedb_redo1_3_2_1g
/dev/vx/rdsk/datadg/tradedb_redo2_1_1_1g
/dev/vx/rdsk/datadg/tradedb_redo2_1_2_1g
已选择4行。
SQL> alter system archive log current;
系统已更改。
SQL> select group#, status from v$log where status = 'CURRENT';
GROUP# STATUS
---------- ----------------
4 CURRENT
6 CURRENT
已选择2行。
SQL> exec dbms_logmnr.add_logfile('/dev/vx/rdsk/datadg/tradedb_redo1_3_1_1g', dbms_logmnr.new)
PL/SQL 过程已成功完成。
SQL> exec dbms_logmnr.add_logfile('/dev/vx/rdsk/datadg/tradedb_redo2_1_1_1g', dbms_logmnr.addfile)
PL/SQL 过程已成功完成。
SQL> exec dbms_logmnr.start_logmnr(options=> dbms_logmnr.dict_from_online_catalog)
PL/SQL 过程已成功完成。
SQL> create table t_logminer tablespace sysaux
2 as select * from v$logmnr_contents
3 where seg_owner = 'ZHEJIANG'
4 and seg_name = 'LP_PRICE_PROCESS';
表已创建。
问题解决。在出现错误的时候不要着急,冷静的思考当前的操作有何特殊之处,往往可以迅速的定位并解决问题。