ORA-01410 INVAILD ROWID 无解之题啊
上个月2周内同一个库同一个用户下报了两次INVAILD ROWID 。
采用重建索引和FLUSH BUFFER 解决了。
可是无法找到原因,也没有办法如何去预防。
ORACLE 11G ACTIVE DATA GURAD 是的物理备库。 11.2.0.1 OPEN READ ONLY
主库和备库都构建在VM WARE 5.1的虚拟机器上。
虚拟机的磁盘模式 (独立,持久,非持久) 发现都没有选定,不知道默认是啥! 会不会有缓存写呢?
实体机是IBM PC SYSTEM PC服务器,RAID5,阵列。
数据库没有开启 直接路径和异步IO。
操作系统RED HAT LINUX 5.3 。
触发ORA-1410错误的,即在对数据块做逻辑读时运行到kcbz_check_objd_typ函数时,检测到OBJD 不一致的问题。由于seg.obj和diskobj不一致,而10g以后的kcbz_check_objd_typ函数负责验证块上的objd是否mistmatch,若不一致则触发ORA-1410错误。
造成objd mimatch的主要可能有几种:
1、 写丢失 Lost Write, 写丢失造成相关数据块没有为现有对象正常格式化,导致虽然该数据块的checksum是正确的,但对应数据字典却是不一致的。 写丢失也可能由磁盘或卷组镜像同步软件的不完整复制造成。
2、 一些DDL操作例如Exchange Partition 造成block级别的不一致,同一个数据块被2个数据对象所使用,而当这2个对象被使用时都可能覆盖问题数据块。 实际上这种情况也可能是Lost Write所引起的。
3、 文档Summary Of Bugs Containing ORA 1410 (Doc ID 422771.1)介绍了引起ORA-1410的主要BUG,其中BUG 4592596(Corruption (ORA-1410) from multi-table insert with direct load) 和 BUG 3868753 (Concurrent export / INSERT of ASSM segment can fail with ORA-1410 / ORA-8103)均为对表的Direct path/Parallel INSERT引起后续对表的SELECT操作报ORA-1410错误。
这说明了Direct Path/Parallel Insert操作有小概率引发ORA-1410错误发生的可能,而常规的conventional insert则不会引发ORA-1410。
4、 objd mimatch也可能仅仅是Oracle Buffer Cache内存中的block存在不一致,而Disk磁盘上的block仍是完好的。这一般是Oracle Buffer层的BUG引起的,对于该种现象一般flush buffer_cache即可解决问题。
ORA-1410问题相关的一些BUG罗列如下:
Bug 5637976
Abstract: ORA-8103/ORA-1410 from concurrent INSERT / export on ASSM tables
This occurs in 10gR2 when there are concurrent inserts and direct path exports. The newly created/updated blocks are not being flushed to disk, so the export is getting a stale version of the block from disk.
Fixed in 10.2.0.4 and 11.1.0.6
Unpublished Bug 4592596
Abstract: Corruption (ORA-1410) from multi-table insert with direct load
This error occurs if a SQL plan is compiled for a parallel run with a Degree of Parallelism (DOP) > 1, but at the time of running, due to lack of resources, it runs serial. Then the problem of invalid rowid will happen.
Fixed in 10.2.0.4 and 11.1.0.6.
Bug 5596325
Abstract: Text query gives wrong results or fails with ORA-1410 ORA-29903
If CONTAINS queries return ORA-1410: invalid rowid errors, and there are more than 200,000,000 documents in the index, then you may have encountered this bug.
Fixed in 10.2.0.4 and 11.1.0.6
Unpublished Bug 6444339
Abstract: TRUNCATE/PURGE DOES NOT CLEAN DEPENDENCIES PROPERLY.
DDL statements to an object were not invalidating all dependencies, so a stale rowid could remain in cache and produce a ORA-1410 if used.
Fixed in 11.2 and 10.2.0.5
Bug 8740993
Abstract: ORA-1410 OCCURRED ON ADG STANDBY DATABASE DURING TABLE SCAN.
This bug applies to standby databases and occurs when the standby is re-applying DDL for table drops/truncates/shrinks. The buffer cache is not being updated for the new object numbers.
Fixed in 12.1, 11.2.0.2
我的现象符合第4个原因和Bug 8740993 一部分。 when the standby is re-applying DDL for table drops/truncates/shrinks.
这个原因有点不可能。那两周没有做过这样的操作,在那两周之前,只是删除了个用户而已。
最后 ALTRE.LOG里面根本找不到ORA-的关键字!
开启了参数好像也没有效果样
在主库和备库都设置 三个参数 好像也没有用,又报了无效ROWID 这次是某个表的内存不匹配
ALTER SYSTEM set DB_BLOCK_CHECKSUM=full scope=both;
ALTER SYSTEM set DB_BLOCK_CHECKING=full scope=both;
ALTER SYSTEM set DB_LOST_WRITE_PROTECT=TYPICAL scope=both;