记trace目录下不停增长cdump文件，trc文件中有oer 8102.2错误
机房断电，重启服务器显示有坏块，用发送窗口fsck命令修复后开机正常，连上业务后trace目录下每隔几秒报一次错，创建一个cdump文件。alert日志内容
Tue Aug 27 10:59:03 2019 Errors in file
/oracle/app/oracle/diag/rdbms/dsjf6102/DSJF6102/trace/DSJF6102_ora_457.trc:
Tue Aug 27 10:59:04 2019 Trace dumping is performing
id=[cdmp_20190827105904] Tue Aug 27 10:59:45 2019 Errors in file
/oracle/app/oracle/diag/rdbms/dsjf6102/DSJF6102/trace/DSJF6102_ora_1040.trc:
Tue Aug 27 10:59:47 2019 Trace dumping is performing
id=[cdmp_20190827105947] Tue Aug 27 11:00:28 2019 Errors in file
/oracle/app/oracle/diag/rdbms/dsjf6102/DSJF6102/trace/DSJF6102_ora_1562.trc:
Tue Aug 27 11:00:29 2019 Trace dumping is performing
id=[cdmp_20190827110029] Tue Aug 27 11:01:11 2019 Errors in file
/oracle/app/oracle/diag/rdbms/dsjf6102/DSJF6102/trace/DSJF6102_ora_2201.trc:
Tue Aug 27 11:01:12 2019 Trace dumping is performing
id=[cdmp_20190827110112]
.trc内容
Trace file
/oracle/app/oracle/diag/rdbms/dsjf6102/DSJF6102/trace/DSJF6102_ora_26659.trc
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit
Production With the Partitioning, OLAP, Data Mining and Real
Application Testing options ORACLE_HOME =
/oracle/app/oracle/product/11.1.0/db_1 System name: Linux Node
name: SJF6102 Release: 2.6.32-431.20.3.el6.x86_64 Version: #1 SMP Thu
Jun 26 11:55:21 ICT 2014 Machine: x86_64 Instance name: DSJF6102 Redo
thread mounted by this instance: 1 Oracle process number: 28 Unix
process pid: 26659, image: oracle@SJF6102*** 2019-08-27 10:51:13.051
*** SESSION ID:(297.2826) 2019-08-27 10:51:13.051
*** CLIENT ID:() 2019-08-27 10:51:13.051
*** SERVICE NAME:(SYS$USERS) 2019-08-27 10:51:13.051
*** MODULE NAME:(JDBC Thin Client) 2019-08-27 10:51:13.051
*** ACTION NAME:() 2019-08-27 10:51:13.051 oer 8102.2 - obj# 122720, rdba: 0x26400cb4(afn 153, blk# 3252) kdk key 8102.2: ncol: 2, len:
13 key: (13): 05 c4 05 07 4f 38 06 26 40 0c b0 00 42 mask:
(4096):
出现oer 8102.2的错误，有两种可能:1.坏块,2.表和索引数据不一致
通过obj# 122720信息，在dba_objects表中找出对象名及类型和拥有者
select object_name,object_type,owner from dba_objects where object_id=122720;
分析表的有效性，验证表结构
SQL> ANALYZE TABLE sys.WRI$_SEGADV_OBJLIST VALIDATE STRUCTURE CASCADE;
ANALYZE TABLE sys.WRI$_SEGADV_OBJLIST VALIDATE STRUCTURE CASCADE
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file
分析坏块
SQL> ANALYZE INDEX WRI$_SEGADV_OBJLIST_IDX_TS VALIDATE STRUCTURE;Index analyzed.SQL> ANALYZE TABLE WRI$_SEGADV_OBJLIST VALIDATE STRUCTURE;Table analyzed.[oracle@bas bdump]$ dbv file=/opt/app/oracle/oradata/BAS/system01.dbfDBVERIFY: Release 10.2.0.1.0 - Production on Sat Dec 24 21:14:38 2011Copyright (c) 1982, 2005, Oracle. All rights reserved.DBVERIFY - Verification starting : FILE = /opt/app/oracle/oradata/BAS/system01.dbfDBVERIFY - Verification completeTotal Pages Examined : 552960
Total Pages Processed (Data) : 360156
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 167596
Total Pages Failing (Index): 0
Total Pages Processed (Other): 1961
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 23247
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Highest block SCN : 2890198330 (2750.2890198330)
检测证明，对象以及对象所属的数据文件，无坏块现象
分析表和索引数据是否不一致
--找出index对应列
SQL> SELECT table_name , column_name from dba_ind_columns 2 WHERE index_name='WRI$_SEGADV_OBJLIST_IDX_TS' order by table_name; TABLE_NAME COLUMN_NAME
------------------------------ --------------------
WRI$_SEGADV_OBJLIST TS_ID--确定对应列是否允许为null
SQL> desc WRI$_SEGADV_OBJLISTName Null? Type----------------------------------------- -------- ----------------------------AUTO_TASKID NUMBERTS_ID NUMBEROBJN NUMBEROBJD NUMBERSTATUS VARCHAR2(40)TASK_ID NUMBERREASON VARCHAR2(40)REASON_VALUE NUMBERCREATION_TIME TIMESTAMP(6)PROC_TASKID NUMBEREND_TIME TIMESTAMP(6)SEGMENT_OWNER VARCHAR2(30)SEGMENT_NAME VARCHAR2(81)PARTITION_NAME VARCHAR2(30)SEGMENT_TYPE VARCHAR2(18)TABLESPACE_NAME VARCHAR2(30)--确认在表中对应列是否有空值
SQL> SELECT /*+ FULL(t1) */ count(TS_ID)2 FROM WRI$_SEGADV_OBJLIST t1 3 WHERE t1.TS_ID IS NULL;COUNT(TS_ID)
------------0
--表比index多数据
SQL> SELECT /*+ FULL(t1) */ TS_ID2 FROM WRI$_SEGADV_OBJLIST t13 MINUS4 SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ TS_ID5 FROM WRI$_SEGADV_OBJLIST t where ts_id is not null;no rows selected--index中数据条数
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ count(TS_ID)2 FROM WRI$_SEGADV_OBJLIST t3 where ts_id is not null;COUNT(TS_ID)
------------901--表中数据条数
SQL> SELECT /*+ FULL(t1) */ count(TS_ID)2 FROM WRI$_SEGADV_OBJLIST t1 ;COUNT(TS_ID)
------------937--index中不同值数量
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ 2 COUNT(DISTINCT TS_ID)3 FROM WRI$_SEGADV_OBJLIST t WHERE TS_ID IS NOT NULL;COUNT(DISTINCTTS_ID)
--------------------5
--表中不同值数量
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ TS_ID2 FROM WRI$_SEGADV_OBJLIST t WHERE ts_id IS NOT NULL3 MINUS4 SELECT /*+ FULL(t1) */ TS_ID5 FROM WRI$_SEGADV_OBJLIST t1 ;TS_ID
----------4
--对比可以知道index中的唯一值比表中，这个也就解释了，为什么表中总条数多，
--但是他们两做减法的时候，记录为空--索引表比表多数据
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ TS_ID2 FROM WRI$_SEGADV_OBJLIST t WHERE ts_id IS NOT NULL3 MINUS4 SELECT /*+ FULL(t1) */ TS_ID5 FROM WRI$_SEGADV_OBJLIST t1 ;TS_ID
----------4
上面的检测证明:1.表中有索引中无的数据,2.索引中有表中不存在数据
重建索引
SQL> alter index WRI$_SEGADV_OBJLIST_IDX_TS rebuild online;Index altered.--测试index中总条数
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ count(TS_ID)2 FROM WRI$_SEGADV_OBJLIST t3 where ts_id is not null;COUNT(TS_ID)
------------937--无多余index项(以前唯一值为4的记录已经不存在)
SQL> SELECT /*+ index(t WRI$_SEGADV_OBJLIST_IDX_TS) */ TS_ID2 FROM WRI$_SEGADV_OBJLIST t WHERE ts_id IS NOT NULL3 MINUS4 SELECT /*+ FULL(t1) */ TS_ID5 FROM WRI$_SEGADV_OBJLIST t1 ;no rows selected--通过上述测试，证明表和index不一致问题解决，检查trace目录，已没有新的cdump文件产生。
官方文档号1199014.1
You could be getting a lot of traces generated, filling up the alert
log as below:Fri Sep 3 05:05:48 2010 Errors in file
/u01/app/oracle/product/db10g/admin/orcl/udump/orcl_ora_15618.trc: Fri
Sep 3 05:05:52 2010 Errors in file
/u01/app/oracle/product/db10g/admin/orcl/udump/orcl_ora_15618.trc: Fri
Sep 3 05:05:54 2010 Errors in file
/u01/app/oracle/product/db10g/admin/orcl/udump/orcl_ora_15618.trc: Fri
Sep 3 05:05:55 2010 Errors in file
/u01/app/oracle/product/db10g/admin/orcl/udump/orcl_ora_15653.trc:And the trace itself has the following call stack trace:
ksedst <- ksedmp <- kdiknf <- kdimod0 <- kauupd <- updrow <- qerupRow
<- Procedure <- qerupFetch <- updaul <- updThreePhaseExe <- 277 <-
updexe <- opiexe <- opipls <- opiodr <- rpidrus <- skgmstack <- rpidru
<- rpiswu2 <- rpidrv <- psddr0 <- psdnal <- pevm_EXECC <- pfrinstr_ <-
EXECC <- pfrrun_no_tool <- pfrrun <- plsql_run <- peicnt <- kkxexe <-
opiexe <- kpoal8 <- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <-
opidrv <- sou2o <- opimai_real <- main <- libc_start_mainThe trace file will also show a part like the below:
*** SESSION ID:(113.1417) 2010-09-06 11:34:27.434 oer 8102.2 - obj# 60445, rdba: 0x01405e5e(afn 5, blk# 24158) kdk key 8102.2: ncol: 4,
len: 22 key: (22):CAUSE The message ‘oer 8102.2 - obj# 60445, rdba: 0x01405e5e(afn 5,
blk# 24158)’ in the trace file is indicating that the object with the
ID 60445 is giving an ORA-08102 error, and that error is described as
below:OERR: ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)”
Error: ORA-08102 (ORA-8102) Text: index key not found, obj# %s, file
%s, block %s (%s)
--------------------------------------------------------------------------- Cause: Internal error: possible inconsistency in index Action: Send
trace file to your customer support representative, along with
information on reproducing the errorSOLUTION
- Find the object which ID is given in the error ‘oer 8102.2 - obj# 60445, rdba: 0x01405e5e(afn 5, blk#
24158)’ message from the trace file, in this case, the object with the ID 60445.- Drop and recreate this object.
NOTE: This issue could be similar to many other issues, but the key
symptom here is the ‘oer 8102.x’ error given in the trace file. If you
can’t find that, then you are NOT hitting this issue, and please log
an SR with Oracle Support for diagnosis.
记trace目录下不停增长cdump文件，trc文件中有oer 8102.2错误相关推荐
- linux查找日期目录,详解Linux查找目录下的按时间过滤的文件
在维护项目中,有时会指定都一些条件进行过滤文件,并对该批文件进行操作:这时我们将使用shell命令进行操作:直接上代码 #!/bin/sh #BEGIN #`find ./ ! -name " ...
- 位于/var/log目录下的20个Linux日志文件
位于/var/log目录下的20个Linux日志文件[译] from:http://buptguo.com/2014/01/16/linux-var-log-files/ 原文地址:20 Linux ...
- python文件操作2：在指定目录下查找指定后缀名的文件
在指定目录下查找指定后缀名的文件,要查找所有子目录,返回文件路径名列表 import osdef get_full_filelist(base_dir='.', target_ext='') -> ...
- linux依据时间过滤文件,详解Linux查找目录下的按时间过滤的文件
在维护项目中,有时会指定都一些条件进行过滤文件,并对该批文件进行操作:这时我们将使用shell命令进行操作:直接上代码 #!/bin/sh #BEGIN #`find ./ ! -name " ...
- linux模糊查找目录文件,详解Linux查找目录下的按时间过滤的文件
在维护项目中,有时会指定都一些条件进行过滤文件,并对该批文件进行操作:这时我们将使用shell命令进行操作:直接上代码 #!/bin/sh #BEGIN #`find ./ ! -name " ...
- C++查找一个目录下所有特定扩展名的文件
记录一个小技巧,查找一个目录下所有特定扩展名的的文件名.代码所示是查找所有后缀为".txt"的文件名,并将结果存储于名为statfileurllist的vector中 注:也可以查 ...
- linux中etc目录下没有source,Linux /etc/profile文件详解及修改后如何立即生效（使用source命令）...
Linux /etc/profile文件的改变会涉及到系统的环境,也就是有关Linux环境变量的东西,学习Linux要了解Linux profile文件的相关原理,这里对则以文件进行具体分析.这里修改 ...
- java删除指定的文件夹_java脚本删除指定目录下的所有指定名称的文件夹
前阵子出差,经常拷贝项目源码,源码里面总是包括.svn文件夹,使得拷贝起来很麻烦,而且文件大了很多,所以自己编写小程序删除,基于同事也经常让我传这段代码,干脆制作成可执行文件.并且是通用的删除小程序. ...
- 2. linux的日志文件在哪个目录,位于/var/log目录下的20个Linux日志文件
如果你多数时间都在使用Linux系统,那么你有必要知道系统的日志文件位于哪里,以及每个日志文件是关于哪些内容的.在系统正常的时候学习理解各种日志文件的内容,有助于在遇到紧急情况时通过日志文件定位问题所 ...
最新文章
- Java中 synchronized 关键字的理解
- python2中的unicode_在python 3和2中工作的Unicode文字
- YOLOv3实现鱼类目标检测
- 集群、RAC和MAA
- Node.js入门 - 回调函数
- MongoDB与Spring集成教程
- python爬取json数据_Python爬取数据保存为Json格式的代码示例
- git 使用http方式的一个小问题
- ICCV-2021 Oral | AdaFocus：利用空间冗余性实现高效视频识别
- Multi-task中的多任务loss平衡问题
- 多标签分类问题中的评价指标：准确率，交叉熵代价函数
- 英雄无敌Ⅲ之游戏修改器DIY
- 逃跑h5小游戏源码熊出没手机游戏
- Julia学习笔记（一）——入门
- android 发短信 oppo,OPPO R11短信发送失败怎么办？OPPO手机短信发送失败的解决方法...
- 混淆矩阵、召回率、精确率、正确率、F1、真阳性率、假阳性率、ROC、AUC
- 2023-2028年中国黄酒行业市场预测与投资规划分析报告
- 欧拉定理，费马小定理证明
- 七段显示器显示整数C语言答案,C语言程序设计试卷(含答案)（7页）-原创力文档...
- 你的眼睛应该是灰色的，像钢铁一般的颜色