原文链接 个人博客http://www.killdb.com/?p=201

昨天准备研究11g的query cache result 特性，准备用10g的老方法来直接通过
show parameter xxxx的方式来查看隐含参数，发现下面的创建视图语句居然报错ora-08102
如下是创建视图的脚本，后面是错误：

 create or replace view show_hidden_v$parameter(INST_ID, NUM , NAME , TYPE , VALUE , DISPLAY_VALUE, ISDEFAULT ,
ISSES_MODIFIABLE , ISSYS_MODIFIABLE , ISINSTANCE_MODIFIABLE,ISMODIFIED,
ISADJUSTED , ISDEPRECATED, DESCRIPTION, UPDATE_COMMENT, HASH)asselect x.inst_id,x.indx + 1,ksppinm,ksppity,ksppstvl,ksppstdvl,ksppstdf,decode(bitand(ksppiflg / 256, 1), 1, 'TRUE', 'FALSE'),decode(bitand(ksppiflg / 65536, 3),1,'IMMEDIATE',2,'DEFERRED',3,'IMMEDIATE','FALSE'),decode(bitand(ksppiflg, 4),4,'FALSE',decode(bitand(ksppiflg / 65536, 3), 0, 'FALSE', 'TRUE')),decode(bitand(ksppstvf, 7), 1, 'MODIFIED', 4, 'SYSTEM_MOD', 'FALSE'),decode(bitand(ksppstvf, 2), 2, 'TRUE', 'FALSE'),decode(bitand(ksppilrmflg / 64, 1), 1, 'TRUE', 'FALSE'),ksppdesc,ksppstcmnt,ksppihashfrom x$ksppi x, x$ksppcv ywhere (x.indx = y.indx);
ORA-08102: index key not found, obj# 39, file 1, block 59847 (2)
从上面的8102错误来看，很明显是数据字典信息不一致了，也就是说该记录在ind$可能已经被清除了，
而在obj$中还存在。我们来看看obj# 39是什么对象？
SQL> SELECT relative_fno, owner, segment_name, segment_type2  FROM dba_extents3  WHERE file_id = 14  AND 59847 BETWEEN block_id AND block_id + blocks - 1;
RELATIVE_FNO OWNER   SEGMENT_NAME                   SEGMENT_TYPE
------------ ------- ------------------------------ ------------------1 SYS     I_OBJ4                         INDEX
SQL>
SQL> select owner,object_name,object_type,object_id from                                                               2  dba_objects where object_name='I_OBJ4';                                                                           OWNER                OBJECT_NAME               OBJECT_TYPE          OBJECT_ID
-------------------- ------------------------- ------------------- ----------
SYS                  I_OBJ4                    INDEX                       39                                          SQL>
对于ora-08102错误，如果是发生在index上，那么我们直接drop index然后重建就ok了。
那我们来试试直接重建会怎么样？
SQL> alter system set event='38003 trace name context forever, level 10' scope=spfile;
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area  167395328 bytes
Fixed Size                  1335220 bytes
Variable Size             104857676 bytes
Database Buffers           58720256 bytes
Redo Buffers                2482176 bytes
Database mounted.
Database opened.
SQL> alter index I_OBJ4 rebuild;
alter index I_OBJ4 rebuild
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00060: deadlock detected while waiting for resource
SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup migrate;
ORACLE instance started.
Total System Global Area  167395328 bytes
Fixed Size                  1335220 bytes
Variable Size             104857676 bytes
Database Buffers           58720256 bytes
Redo Buffers                2482176 bytes
Database mounted.
Database opened.
SQL> alter index I_OBJ4 rebuild;
alter index I_OBJ4 rebuild
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00060: deadlock detected while waiting for resource
SQL> drop index I_OBJ4;
drop index I_OBJ4*
ERROR at line 1:
ORA-00701: object necessary for warmstarting database cannot be altered  
SQL> alter index I_OBJ4 rebuild online;
alter index I_OBJ4 rebuild online
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-08102: index key not found, obj# 39, file 1, block 59847 (2)
SQL> analyze table obj$ VALIDATE STRUCTURE CASCADE;
analyze table obj$ VALIDATE STRUCTURE CASCADE
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file
到这里，可能有人会问，为什么使用event 38003或migrate 模式无法rebuild 该index呢？
很简单，该index的obj# <56, 换句话说，也就是对于bootstrap$核心对象是无法通过上面
的2种方式来完成重建的。
通常来说到这个地步，如果不使用其他手段的话，那么只能使用ODU或DUL进行抽取数据然后重建数据库了。
其实对于这个问题，我们可以借助BBED来进行修复。
既然是数据不一致，那么我就想知道到底是哪儿不一致了？metalink 提供处理ora-8102的方法：
SQL> SELECT /*+ FULL(t1) */ DATAOBJ#, TYPE#,OWNER#,rowid2  FROM obj$ t13  MINUS4  SELECT /*+ index(t I_OBJ4) */ DATAOBJ#, TYPE#,OWNER#,rowid5  FROM obj$ t;
  DATAOBJ#      TYPE#     OWNER# ROWID
---------- ---------- ---------- ------------------73416          2          0 AAAAASAABAAAPt8AAB73419          0          0 AAAAASAABAAAADxAAb
SQL> select obj#,OWNER#,NAME,TYPE#,STATUS,FLAGS from obj$ where rowid='AAAAASAABAAAPt8AAB';
      OBJ#     OWNER# NAME                                TYPE#     STATUS      FLAGS
---------- ---------- ------------------------------ ---------- ---------- ----------73416          0 TEST01                                  2          1          0
SQL> select obj#,OWNER#,NAME,TYPE#,STATUS,FLAGS from obj$ where rowid='AAAAASAABAAAADxAAb';
      OBJ#     OWNER# NAME                                TYPE#     STATUS      FLAGS
---------- ---------- ------------------------------ ---------- ---------- ----------1          0 _NEXT_OBJECT                            0          0          0
SQL>
SQL> select case when (NextObjNum - MaxObjNum) > 02              then 'GOOD'else 'BAD'end "OBJ_NUM_STATE"from  (select (select dataobj#3    4    5    6                      from   sys.obj$7                      where  name = '_NEXT_OBJECT') NextObjNum,8                     (select max(obj#)9                      from   sys.obj$) MaxObjNum10              from dual);
OBJ_
----
GOOD
从这里来看，_NEXT_OBJECT是ok的。那么我们重点就放在TEST01上了。
到这里，看到test01，我才想起这是很久以前做关于手工构造某个由于数据字典信息不一致而引发的某个600错误
而留下的隐患。
根据前面的报错，我们找到相应的trace，发现如下信息：
oer 8102.2 - obj# 39, rdba: 0x0040e9c7(afn 1, blk# 59847)
kdk key 8102.2:ncol: 4, len: 16key: (16):  04 c3 08 23 14 01 80 01 80 06 00 40 00 f1 00 1bmask: (2048):    这里简单的进行说明：ncol   ---表示列数目len    ---表示长度key: (<length>):<hexadecimal value>

关于ora-08012错误，大家可以参考 OERR: ORA-8102 "index key not found, obj# %s, file %s, block %s (%s)" [ID 8102.1]
下面我们继续，既然该block有问题，那么我就dump该block。
alter system dump datafile 1 block 59847
确定为如下2行数据：
row#131[2131] flag: ---D--, lock: 3, len=18
col 0; len 4; (4):  c3 08 23 0a
col 1; len 1; (1):  80
col 2; len 1; (1):  80
col 3; len 6; (6):  00 40 00 f1 00 1b
row#133[2113] flag: ------, lock: 3, len=18
col 0; len 4; (4):  c3 08 23 0f
col 1; len 1; (1):  80
col 2; len 1; (1):  80
col 3; len 6; (6):  00 40 00 f1 00 1b
SQL> select 2131+44+24*3 from dual;
2131+44+24*3
------------2247
BBED> set file 1 block 59847FILE#           1BLOCK#          59847
BBED> set offset 2247OFFSET          2247
BBED> d /vFile: /oracle/product/oradata/roger/system01.dbf (1)Block: 59847   Offsets: 2247 to 2758  Dba:0x0040e9c7
-------------------------------------------------------010304c3 08230a01 80018006 004000f1 l .....#.......@..001b0000 04c30823 0202c102 01800600 l .......#........40fb7c00 1a010003 c3082302 c1020180 l @.|.......#.....060040fb 7c001b00 0004c308 226402c1 l ..@.|......."d..03018006 00402750 00090100 04c30822 l .....@'P......."6202c102 01800600 40fb7c00 1a010004 l b.......@.|.....c3082263 02c10201 80060040 fb7c001c l .."c.......@.|..010004c3 08230501 80018006 004000f1 l .....#.......@..001b0100 04c30822 6002c102 01800600 l ......."`.......40fb7c00 1a010004 c3082264 01800180 l @.|......."d....06004000 f1001b01 0004c308 225e02c1 l ..@........."^..02018006 0040fb7c 001c0100 04c30822 l .....@.|......."5d02c102 01800600 40fb7c00 1b010004 l ].......@.|.....c308225b 02c10201 80060040 fb7c001c l .."[.......@.|..010004c3 08225a02 c1020180 060040fb l ....."Z.......@.7c001a01 0004c308 225f0180 01800600 l |......."_......4000f100 1b010004 c3082256 02c11501 l @........."V....80060040 fb7c0019 000004c3 08225702 l ...@.|......."W.c1150180 060040fb 7c001801 0004c308 l ......@.|.......225502c1 14018006 0040fb7b 000f0000 l "U.......@.{....04c30822 5402c114 01800600 40fb7c00 l ..."T.......@.|.17010004 c308225a 01800180 06004000 l ......"Z......@.f1001b01 0004c308 225202c1 15018006 l ........"R......0040fb7c 00160000 04c30822 5302c115 l .@.|......."S...01800600 40fb7c00 15010004 c3082251 l ....@.|......."Q02c11401 80060040 fb7b000c 000004c3 l .......@.{......08225002 c1140180 060040fb 7c001401 l ."P.......@.|...0004c308 22550180 01800600 4000f100 l ...."U......@...1b010004 c308224e 02c11501 80060040 l ......"N.......@fb7c0013 000004c3 08224f02 c1150180 l .|......."O.....060040fb 7c001201 0004c308 224d02c1 l ..@.|......."M..14018006 0040fb7b 00090000 04c30822 l .....@.{......."
 <16 bytes per line>
BBED>
BBED> modify /x 14 offset 2253File: /oracle/product/oradata/roger/system01.dbf (1)Block: 59847            Offsets: 2253 to 2764           Dba:0x0040e9c7
------------------------------------------------------------------------14018001 80060040 00f1001b 000004c3 08230202 c1020180 060040fb 7c001a010003c308 2302c102 01800600 40fb7c00 1b000004 c3082264 02c10301 8006004027500009 010004c3 08226202 c1020180 060040fb 7c001a01 0004c308 226302c102018006 0040fb7c 001c0100 04c30823 05018001 80060040 00f1001b 010004c308226002 c1020180 060040fb 7c001a01 0004c308 22640180 01800600 4000f1001b010004 c308225e 02c10201 80060040 fb7c001c 010004c3 08225d02 c1020180060040fb 7c001b01 0004c308 225b02c1 02018006 0040fb7c 001c0100 04c308225a02c102 01800600 40fb7c00 1a010004 c308225f 01800180 06004000 f1001b010004c308 225602c1 15018006 0040fb7c 00190000 04c30822 5702c115 0180060040fb7c00 18010004 c3082255 02c11401 80060040 fb7b000f 000004c3 08225402c1140180 060040fb 7c001701 0004c308 225a0180 01800600 4000f100 1b010004c3082252 02c11501 80060040 fb7c0016 000004c3 08225302 c1150180 060040fb7c001501 0004c308 225102c1 14018006 0040fb7b 000c0000 04c30822 5002c11401800600 40fb7c00 14010004 c3082255 01800180 06004000 f1001b01 0004c308224e02c1 15018006 0040fb7c 00130000 04c30822 4f02c115 01800600 40fb7c0012010004 c308224d 02c11401 80060040 fb7b0009 000004c3 08224c02 c1140180
 <32 bytes per line>
BBED> sum apply
Check value for File 1, Block 59847:
current = 0xe5a9, required = 0xe5a9
BBED> modify /x 14 offset 2235File: /oracle/product/oradata/roger/system01.dbf (1)Block: 59847            Offsets: 2235 to 2746           Dba:0x0040e9c7
------------------------------------------------------------------------14018001 80060040 00f1001b 010304c3 08231401 80018006 004000f1 001b000004c30823 0202c102 01800600 40fb7c00 1a010003 c3082302 c1020180 060040fb7c001b00 0004c308 226402c1 03018006 00402750 00090100 04c30822 6202c10201800600 40fb7c00 1a010004 c3082263 02c10201 80060040 fb7c001c 010004c308230501 80018006 004000f1 001b0100 04c30822 6002c102 01800600 40fb7c001a010004 c3082264 01800180 06004000 f1001b01 0004c308 225e02c1 020180060040fb7c 001c0100 04c30822 5d02c102 01800600 40fb7c00 1b010004 c308225b02c10201 80060040 fb7c001c 010004c3 08225a02 c1020180 060040fb 7c001a010004c308 225f0180 01800600 4000f100 1b010004 c3082256 02c11501 80060040fb7c0019 000004c3 08225702 c1150180 060040fb 7c001801 0004c308 225502c114018006 0040fb7b 000f0000 04c30822 5402c114 01800600 40fb7c00 17010004c308225a 01800180 06004000 f1001b01 0004c308 225202c1 15018006 0040fb7c00160000 04c30822 5302c115 01800600 40fb7c00 15010004 c3082251 02c1140180060040 fb7b000c 000004c3 08225002 c1140180 060040fb 7c001401 0004c30822550180 01800600 4000f100 1b010004 c308224e 02c11501 80060040 fb7c0013000004c3 08224f02 c1150180 060040fb 7c001201 0004c308 224d02c1 14018006
 <32 bytes per line>
BBED> sum apply
Check value for File 1, Block 59847:
current = 0xfea9, required = 0xfea9
BBED> verify
DBVERIFY - Verification starting
FILE = /oracle/product/oradata/roger/system01.dbf
BLOCK = 59847
Block Checking: DBA = 4254151, Block Type = KTB-managed data block
**** row 132: key out of order
---- end index block validation
Block 59847 failed with check code 6401
DBVERIFY - Verification complete
Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 1
Total Blocks Failing   (Index): 1
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED
BBED>
最后重启后，创建成功，再次检查发现一切ok。
BBED> verify
DBVERIFY - Verification starting
FILE = /oracle/product/oradata/roger/system01.dbf
BLOCK = 59847
DBVERIFY - Verification complete
Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 1
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED     
最后尝试创建视图，发现一切正常，如下：
SQL>  create or replace view show_hidden_v$parameter2   (INST_ID, NUM , NAME , TYPE , VALUE , DISPLAY_VALUE, ISDEFAULT , ISSES_MODIFIABLE , ISSYS_MODIFIABLE , ISINSTANCE_MODIFIABLE,3   ISMODIFIED , ISADJUSTED , ISDEPRECATED, DESCRIPTION, UPDATE_COMMENT, HASH)4   as5   select x.inst_id,6          x.indx + 1,7          ksppinm,8          ksppity,9          ksppstvl,10          ksppstdvl,11          ksppstdf,12          decode(bitand(ksppiflg / 256, 1), 1, 'TRUE', 'FALSE'),13          decode(bitand(ksppiflg / 65536, 3),14                 1,15                 'IMMEDIATE',16                 2,17                 'DEFERRED',18                 3,19                 'IMMEDIATE',20                 'FALSE'),21          decode(bitand(ksppiflg, 4),22                 4,23                 'FALSE',24                 decode(bitand(ksppiflg / 65536, 3), 0, 'FALSE', 'TRUE')),25          decode(bitand(ksppstvf, 7), 1, 'MODIFIED', 4, 'SYSTEM_MOD', 'FALSE'),26          decode(bitand(ksppstvf, 2), 2, 'TRUE', 'FALSE'),27          decode(bitand(ksppilrmflg / 64, 1), 1, 'TRUE', 'FALSE'),28          ksppdesc,29          ksppstcmnt,30          ksppihash31     from x$ksppi x, x$ksppcv y32    where (x.indx = y.indx);
View created.           
SQL>

转载于:https://www.cnblogs.com/lovewifelovelife/archive/2011/08/28/3295141.html

bootstrap$核心对象数据不一致导致ORA-08102相关推荐

  1. 成功解决pandas.core.frame.DataFrame格式数据与numpy.ndarray格式数据不一致导致无法运算问题

    成功解决pandas.core.frame.DataFrame格式数据与numpy.ndarray格式数据不一致导致无法运算问题 目录 解决问题 解决思路 解决方法 解决问题 pandas.core. ...

  2. 揭露数据不一致的利器 —— 实时核对系统

    本文首发于"Shopee技术团队"微信公众号. 摘要 随着企业业务发展,以及微服务化大趋势下单体服务的拆分,服务间的通信交互越来越多.与单体服务不同,微服务间的数据往往需要通过额外 ...

  3. 我在MongoDB年终大会上获二等奖文章：由数据迁移至MongoDB导致的数据不一致问题及解决方案...

    作者 | 上海小胖 来源 | Python专栏(ID:xpchuiit) 故事背景 企业现状 2019年年初,我接到了一个神秘电话,电话那头竟然准确的说出了我的昵称:上海小胖. 我想这事情不简单,就回 ...

  4. 由数据迁移至MongoDB导致的数据不一致问题及解决方案

    故事背景 企业现状 2019年年初,我接到了一个神秘电话,电话那头竟然准确的说出了我的昵称:上海小胖. 我想这事情不简单,就回了句:您好,我是小胖,请问您是? "我就是刚刚加了你微信的 xx ...

  5. 直接修改html文本页面没变化,VUE 直接通过JS 修改html对象的值导致没有更新到数据中解决方法分析...

    本文实例讲述了VUE 直接通过JS 修改html对象的值导致没有更新到数据中解决方法.分享给大家供大家参考,具体如下: 业务场景 我们在使用vue 编写 代码时,我们有一个 多行文本框控件,希望在页面 ...

  6. 关于对象流两端的数据不一致的问题：

    关于对象流两端的数据不一致的问题: 下图为服务器端收发数据时的状态:此时players列表中有两个对象但是到客户端接收时,却只有一个对象了,经过多次测试,发现每次只有GameMessage这个类有问题 ...

  7. PB9核心之——数据窗口对象使用

    概要 最近这几天一直在用pb做一个小系统,经过这几天对pb9的使用,发现pb9的核心是数据窗口对象的使用,通过使用数据窗口对象可以将数据库的记录显示到界面上,并且可以直接在前台对数据库的记录进行增删改 ...

  8. mysql缓存淘汰机制_Redis缓存总结：淘汰机制、缓存雪崩、数据不一致....

    在实际的工作项目中, 缓存成为高并发.高性能架构的关键组件 ,那么Redis为什么可以作为缓存使用呢?首先可以作为缓存的两个主要特征: 在分层系统中处于内存/CPU具有访问性能良好, 缓存数据饱和,有 ...

  9. mysql主从字符集不一致_MySQL多字节字符集造成主从数据不一致问题

    问题产生线上一直有个历史遗留问题,最近DBA提了出来,所以跟了下代码,作了下简单分析,问题描述如下: 在master-slave的环境下,对master上的某个表中的数据插入,会导致master-sl ...

最新文章

  1. mysql字符集查看_查看和设置mysql字符集
  2. 配置虚拟主机 和 打war包
  3. SharePoint2010沙盒解决方案基础开发——开发webpart读取绑定列表数据，并以一定的格式显示（加css样式）...
  4. linux配置tomcat内存配置文件,Linux与Windows下tomcat内存设置
  5. 如何从数学角度解释何恺明新作Masked Autoencoders (MAE)？
  6. 避免jquery的click多次绑定方法
  7. linux github中文官网,GitHub使用简介
  8. QT接收Linux内核,QT界面程序经过网路与普通的linux应用程序进行数据传送的情况...
  9. 【快捷键】—— 键盘篇
  10. 拓端tecdat|Python时间序列选择波动率预测指数收益算法分析案例
  11. springboot的多数据源配置(多库/主从等等场景)
  12. html获取url后面的参数_【python量化】用Python获取基金历史净值数据
  13. 一起学Hive——总结复制Hive表结构和数据的方法
  14. Python开胃菜(1):搭建开发环境
  15. google font 字体下载方式
  16. 华为 GaussDB 首席架构师 武新离职，出任易鲸捷CEO
  17. Windows创建快捷方式的几种方法你用过哪些？
  18. 【NOIP2006】【Luogu1063】能量项链
  19. dkp管理系统 php,RB!DKP v3.1.8 Build
  20. MTK 使用iptable 命令来完成网络路由(android WIFI/4G分享网络)

热门文章

  1. mac air上archlinux的安装及优化
  2. CC00384.CloudKubernetes——|KuberNetesCI/CD.V22|——|Jenkins.v02|自动构建Java应用.v02|
  3. 借书场景领域建模浅析
  4. 已经阻止此发布者在你的计算机上运行软件win10,win10系统打开软件提示已经阻止此发布者在你的计算机上运行软件怎么办...
  5. C1任务01植物大战僵尸修改
  6. profiles配置多环境
  7. HDU 4200 Bad Wiring（高斯消元）
  8. 无锡设计类——CAD设计在机械制图中的优势
  9. vue前端生成二维码并提供二维码下载
  10. tedu斌-Web笔记2112-5