Chinaunix首页 | 论坛 | 博客
  • 博客访问: 517077
  • 博文数量: 101
  • 博客积分: 1635
  • 博客等级: 上尉
  • 技术积分: 1282
  • 用 户 组: 普通用户
  • 注册时间: 2012-07-05 01:51
文章分类

全部博文(101)

文章存档

2019年(2)

2018年(16)

2013年(14)

2012年(69)

我的朋友

分类: Oracle

2013-02-04 15:07:40

草上飞(530473146) 13:46:45 ORA-07445: exception encountered: core dump [qcdlgcd()+168] [SIGSEGV] [Address not mapped to object] [0x000000037] [] [] Mon Feb 4 12:53:49 2013 SMON: Parallel transaction recovery tried Mon Feb 4 12:54:33 2013 Errors in file /oracle1/u01/app/oracle/admin/centerapp/bdump/centerapp_j001_9517.trc: ORA-07445: exception encountered: core dump [qcdlgcd()+168] [SIGSEGV] [Address not mapped to object] [0x000000037] [] [] 草上飞(530473146) 13:47:18 trace文件的内容 草上飞(530473146) 13:47:21 *** 2013-02-04 12:54:33.058 ksedmp: internal or fatal error ORA-07445: exception encountered: core dump [qcdlgcd()+168] [SIGSEGV] [Address not mapped to object] [0x000000037] [] [] Current SQL statement for this session: INSERT /*+ BYPASS_RECURSIVE_CHECK */ INTO "APP_PRODUCT"."TEXT_ANNEX"("ID","ORIGINALCODE","ANNEXNAME","ANNEXFORMAT","ANNEXCONTE NT","ENTRYTIME","UPDATETIME","GROUNDTIME","RESOURCEID","RECORDID","UPDATEID","ANNEXURL","ANNEXTIME") SELECT "T"."ID","T"."ORIG INALCODE","T"."ANNEXNAME","T"."ANNEXFORMAT","T"."ANNEXCONTENT","T"."ENTRYTIME","T"."UPDATETIME","T"."GROUNDTIME","T"."RESOURCE ID","T"."RECORDID","T"."UPDATEID","T"."ANNEXURL","T"."ANNEXTIME" FROM "TEXT_ANNEX"@CENTER_ADMIN "T" ----- PL/SQL Call Stack ----- object line object handle number name 0x69a84c40 81 package body SYS.DBMS_SNAPSHOT 0x69a84c40 1727 package body SYS.DBMS_SNAPSHOT 0x69a84c40 2220 package body SYS.DBMS_SNAPSHOT 0x69a84c40 2457 package body SYS.DBMS_SNAPSHOT 0x673202a0 685 package body SYS.DBMS_IREFRESH 0x6f88ddc0 195 package body SYS.DBMS_REFRESH 0x69a658f0 1 anonymous block --More--(0%) 草上飞(530473146) 13:47:57 数据库后台进程ora_j000_centerapp运行的比较的频繁 产生了大量类似的centerapp_j000_6002.trctrace文件 change(285727051) 13:50:04 应该是触发了bug 草上飞(530473146) 13:51:03 SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi PL/SQL Release 10.2.0.4.0 - Production CORE 10.2.0.4.0 Production TNS for Linux: Version 10.2.0.4.0 - Production NLSRTL Version 10.2.0.4.0 - Production 草上飞(530473146) 13:51:26 [root@CENTERDB ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.5 (Tikanga) dollar(149679349) 13:57:16 我看到一个网页,关于07445的,http://qtlkw.iteye.com/blog/629488 南京--阳仔(380968195) 13:58:08 满了? dollar(149679349) 13:58:18 这个帖子是这样的 草上飞(530473146) 13:58:23 我查看了一下数据有一个job一直在运行 是物化视图的完全刷新 草上飞(530473146) 13:58:32 是的磁盘都满了 草上飞(530473146) 13:58:49 这个job很奇怪 SQL> select * from dba_jobs where job=121; JOB LOG_USER PRIV_USER SCHEMA_USER LAST_DATE LAST_SEC THIS_DATE THIS_SEC NEXT_DATE NEXT_SEC TOTAL_TIME BROKEN INTERVAL FAILURES WHAT NLS_ENV MISC_ENV INSTANCE ---------- ------------------------------ ------------------------------ ------------------------------ ----------- ---------------- ----------- ---------------- ----------- ---------------- ---------- ------ -------------------------------------------------------------------------------- ---------- -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ---------------------------------------------------------------- ---------- 121 APP_PRODUCT APP_PRODUCT APP_PRODUCT 2013/1/30 1 19:06:52 2013/2/4 13 13:03:27 2013/1/31 1 19:06:52 15217 N SYSDATE+1 0 dbms_refresh.refresh('"APP_PRODUCT"."TEXT_ANNEX"'); NLS_LANGUAGE='AMERICAN' NLS_TERRITORY='AMERICA' NLS_CURRENCY='$' NLS_ISO_CURRENC 0102000200000000 0 草上飞(530473146) 13:59:23 job安排的时间是 上次执行时间是 2013/1/30 1 19:06:52 下次执行的时间是2013/1/31 1 19:06:52 可是真正执行的时间却是 2013/2/4 13 13:03:27 过一会儿执行 之后又停了 之后又开始运行 dollar(149679349) 13:59:52 物化视图有这种问题? dollar(149679349) 14:00:08 我前段时间做的实验是增量刷新的,倒还好 南京--阳仔(380968195) 14:00:33 刷物化视图会占用很多空间么 草上飞(530473146) 14:01:18 我这个是开发他们搞的 用这种REFRESH FORCE ON DEMAND 刷新 我建议他们用fast 看可不可以 dollar(149679349) 14:02:07 刷的过程中是不是占用很多空间,这个我没有注意,但我记得刷新过后,物化视图日志就空了的呀 dollar(149679349) 14:02:18 同步完数据就空了 dollar(149679349) 14:02:36 准确来说是同步完一定时间后空了 草上飞(530473146) 14:04:21 他这个是完全刷新没有建立视图日志啊 dollar(149679349) 14:05:15 那是不是说数据很大才导致的空间满了 change(285727051) 14:05:42 应该是物化视图导致的问题 change(285727051) 14:06:18 检查一下物化视图是否表结构发生变化,可以手动刷新一下试试 dollar(149679349) 14:06:26 明白了,物化视图出现问题的话,会产生很大的bdump和cdump文件 dollar(149679349) 14:06:32 导致空间满了 草上飞(530473146) 14:06:38 是的啊 草上飞(530473146) 14:06:39 -rw-r----- 1 oracle oinstall 4246655 Feb 4 12:51 centerapp_j000_9255.trc -rw-r----- 1 oracle oinstall 4246648 Feb 4 12:52 centerapp_j001_9298.trc -rw-r----- 1 oracle oinstall 4246567 Feb 4 12:53 centerapp_j000_9477.trc -rw-r----- 1 oracle oinstall 4245129 Feb 4 12:54 centerapp_j001_9517.trc -rw-r----- 1 oracle oinstall 4244524 Feb 4 12:55 centerapp_j000_9694.trc -rw-r----- 1 oracle oinstall 4245514 Feb 4 12:56 centerapp_j001_9814.trc -rw-r----- 1 oracle oinstall 4243073 Feb 4 12:57 centerapp_j000_9993.trc -rw-r----- 1 oracle oinstall 4283929 Feb 4 12:58 centerapp_j001_10032.trc -rw-r----- 1 oracle oinstall 4285490 Feb 4 12:59 centerapp_j000_10213.trc -rw-r----- 1 oracle oinstall 4188206 Feb 4 13:01 centerapp_j001_10259.trc -rw-r----- 1 oracle oinstall 4186827 Feb 4 13:02 centerapp_j000_10599.trc -rw-r----- 1 oracle oinstall 4255805 Feb 4 13:03 centerapp_j001_10776.trc 南京--阳仔(380968195) 14:06:58 这些trc都可以干掉的吧 dollar(149679349) 14:07:02 可以的 草上飞(530473146) 14:07:26 可以的 我已经删了 但是现在又生成... 南京--阳仔(380968195) 14:07:32 我这边磁盘空间不足都会报警的 dollar(149679349) 14:07:45 你看看是不是表结构变了 草上飞(530473146) 14:07:50 change(285727051) 14:05:42 应该是物化视图导致的问题 检查一下物化视图是否表结构发生变化,可以手动刷新一下试试 我看看 dollar(149679349) 14:08:00 把物化视图重建一下 草上飞(530473146) 14:08:48 物化视图是这样建立的 草上飞(530473146) 14:08:49 CREATE MATERIALIZED VIEW TEXT_ANNEX REFRESH FORCE ON DEMAND START WITH TO_DATE('31-01-2013 19:06:55', 'DD-MM-YYYY HH24:MI:SS') NEXT SYSDATE+1 FOR UPDATE AS SELECT t.* FROM TEXT_ANNEX@Center_Admin t; 草上飞(530473146) 14:08:58 恩 我先删了 重建一下
阅读(2669) | 评论(0) | 转发(0) |
0

上一篇:rac 的failover

下一篇:oracle rowid

给主人留下些什么吧!~~