原来的书文链接 个人博客

一.标题讲述

前些天备选研讨1一g的query cache result 本性,筹算用拾g的老方法来一向通过
show parameter
xxxx的措施来查阅隐含参数,开采上边包车型大巴创导视图语句居然报错ora-0八10二
正如是开创视图的剧本,前面是不对:

当对视图使用的基表进行表结构修改后,会触发视图的无效以及编写翻译出错难题,必须重建视图化解。

 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)   as   select 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,          ksppihash     from x$ksppi x, x$ksppcv y    where (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_type    2  FROM dba_extents    3  WHERE file_id = 1    4  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#,rowid    2  FROM obj$ t1    3  MINUS    4  SELECT /*+ index(t I_OBJ4) */ DATAOBJ#, TYPE#,OWNER#,rowid    5  FROM obj$ t;

  DATAOBJ#      TYPE#     OWNER# ROWID  ---------- ---------- ---------- ------------------       73416          2          0 AAAAASAABAAAPt8AAB       73419          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) > 0    2              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$) MaxObjNum   10              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: 16    key: (16):  04 c3 08 23 14 01 80 01 80 06 00 40 00 f1 00 1b    mask: (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 59847          FILE#           1          BLOCK#          59847

BBED> set offset 2247          OFFSET          2247

BBED> d /v   File: /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 ....@.|......."Q   02c11401 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 2253   File: /oracle/product/oradata/roger/system01.dbf (1)   Block: 59847            Offsets: 2253 to 2764           Dba:0x0040e9c7  ------------------------------------------------------------------------   14018001 80060040 00f1001b 000004c3 08230202 c1020180 060040fb 7c001a01   0003c308 2302c102 01800600 40fb7c00 1b000004 c3082264 02c10301 80060040   27500009 010004c3 08226202 c1020180 060040fb 7c001a01 0004c308 226302c1   02018006 0040fb7c 001c0100 04c30823 05018001 80060040 00f1001b 010004c3   08226002 c1020180 060040fb 7c001a01 0004c308 22640180 01800600 4000f100   1b010004 c308225e 02c10201 80060040 fb7c001c 010004c3 08225d02 c1020180   060040fb 7c001b01 0004c308 225b02c1 02018006 0040fb7c 001c0100 04c30822   5a02c102 01800600 40fb7c00 1a010004 c308225f 01800180 06004000 f1001b01   0004c308 225602c1 15018006 0040fb7c 00190000 04c30822 5702c115 01800600   40fb7c00 18010004 c3082255 02c11401 80060040 fb7b000f 000004c3 08225402   c1140180 060040fb 7c001701 0004c308 225a0180 01800600 4000f100 1b010004   c3082252 02c11501 80060040 fb7c0016 000004c3 08225302 c1150180 060040fb   7c001501 0004c308 225102c1 14018006 0040fb7b 000c0000 04c30822 5002c114   01800600 40fb7c00 14010004 c3082255 01800180 06004000 f1001b01 0004c308   224e02c1 15018006 0040fb7c 00130000 04c30822 4f02c115 01800600 40fb7c00   12010004 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 2235   File: /oracle/product/oradata/roger/system01.dbf (1)   Block: 59847            Offsets: 2235 to 2746           Dba:0x0040e9c7  ------------------------------------------------------------------------   14018001 80060040 00f1001b 010304c3 08231401 80018006 004000f1 001b0000   04c30823 0202c102 01800600 40fb7c00 1a010003 c3082302 c1020180 060040fb   7c001b00 0004c308 226402c1 03018006 00402750 00090100 04c30822 6202c102   01800600 40fb7c00 1a010004 c3082263 02c10201 80060040 fb7c001c 010004c3   08230501 80018006 004000f1 001b0100 04c30822 6002c102 01800600 40fb7c00   1a010004 c3082264 01800180 06004000 f1001b01 0004c308 225e02c1 02018006   0040fb7c 001c0100 04c30822 5d02c102 01800600 40fb7c00 1b010004 c308225b   02c10201 80060040 fb7c001c 010004c3 08225a02 c1020180 060040fb 7c001a01   0004c308 225f0180 01800600 4000f100 1b010004 c3082256 02c11501 80060040   fb7c0019 000004c3 08225702 c1150180 060040fb 7c001801 0004c308 225502c1   14018006 0040fb7b 000f0000 04c30822 5402c114 01800600 40fb7c00 17010004   c308225a 01800180 06004000 f1001b01 0004c308 225202c1 15018006 0040fb7c   00160000 04c30822 5302c115 01800600 40fb7c00 15010004 c3082251 02c11401   80060040 fb7b000c 000004c3 08225002 c1140180 060040fb 7c001401 0004c308   22550180 01800600 4000f100 1b010004 c308224e 02c11501 80060040 fb7c0013   000004c3 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$parameter    2   (INST_ID, NUM , NAME , TYPE , VALUE , DISPLAY_VALUE, ISDEFAULT , ISSES_MODIFIABLE , ISSYS_MODIFIABLE , ISINSTANCE_MODIFIABLE,    3   ISMODIFIED , ISADJUSTED , ISDEPRECATED, DESCRIPTION, UPDATE_COMMENT, HASH)    4   as    5   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          ksppihash   31     from x$ksppi x, x$ksppcv y   32    where (x.indx = y.indx);

View created.           

SQL>                                          

贰.标题再次出现


1.Oracle10g环境

一.壹 创立视图测试用两张基表:TestTable和TestUser

永利开户送38元体验金 1

永利开户送38元体验金 2

一.贰  创制测试视图VW_TABLEUSERALL和VW_TABLEUSER

前者采纳了TestTable.*, 后者显示钦赐列。

永利开户送38元体验金 3

永利开户送38元体验金 4

 查询视图的意况如下:全部都是Valid状态

   永利开户送38元体验金 5

一.叁 修改TestTable表结构:扩大一列Col1

永利开户送38元体验金 6

 再一次询问视图的图景如下:全部是INVALID状态

  永利开户送38元体验金 7

 

1.肆 重新编写翻译两张视图

 
永利开户送38元体验金 8

 重新查询视图的事态如下:全是Valid状态:

  永利开户送38元体验金 9

   查询视图的数量:VW_TableUserAll查询出错。

  永利开户送38元体验金 10

一.伍 视图重建

  永利开户送38元体验金 11

  重新查询视图的多寡:VW_TableUserAll查询平日: 新扩张的Col1冒出了!

    永利开户送38元体验金 12

   2. Oracle11g环境

   二.一 遭逢希图

   和Orale十g下的一.一 和一.2 步骤同样

   二.2 修改TestTable表结构:扩张1列Col一

    永利开户送38元体验金 13

    查询视图的动静如下:全部是VALID状态

    永利开户送38元体验金 14

    二.三 查询视图VW_TableUserAll,一贯不新扩充的Col一那壹列!

    永利开户送38元体验金 15

   可是基表TestTable中留存Col一这一列

   永利开户送38元体验金 16

  二.肆 重新编译视图,依然查不到Col1那一列

  永利开户送38元体验金 17

  二.五 重建视图,难题一挥而就

 
永利开户送38元体验金 18

   永利开户送38元体验金 19

  1. 难点结论

永利开户送38元体验金,Oracle10g环境下:

对视图基表的修改会触发view的失效。如若视图中选取了修改的基表表结构,重新编写翻译视图不可能缓和难题,视图必要重建。**

Oracle11g环境下:

**对视图基表的更换不会触发view的不算。要是视图中选用了改造的基表表结构,重新编写翻译视图不能够化解难点,视图要求重建。**

**因此:**

1旦改换了视图使用到的基表的表结构被修改了,恰如视图中涉嫌了修改后的表结构,重新编写翻译视图操作,仍回天乏术查询到修改的列,必须进行视图重建。

 

 

相关文章