ORA-1499. Table/Index row count mismatch [ID 563070.1]
Applies to:
Oracle Server - Enterprise Edition - Version: 8.1.7.0 to 11.1.0.7 - Release: 8.1.7 to 11.1Oracle Server - Enterprise Edition - Version: 8.1.7.0 to 11.1.0.7 [Release: 8.1.7 to 11.1]
Information in this document applies to any platform.
Oracle Server Enterprise Edition - Version: 8.1.7.0 to 11.2.0.2
***Checked for relevance on 15-Sep-2011***
Symptoms
Analyze table with "validate structure cascade" fails with ORA-1499 and the trace file contains message "Table/Index row count mismatch". Example:analyze table test validate structure cascade
*
ERROR at line 1:
ORA-01499: table/index cross reference failure - see trace file
The associated trace file contains:
table 6559 : index 10000, 0
Index root = tsn: 6 rdba: 0x01400091
It means: A table scan returned 6559 rows and an index scan returned 10000 rows.
"Index root" is the segment header information for the index:
rdba: 0x01400091 is the Index segment header relative data block address. It is decimal 20971665 which is Rfile#=5 Block#=145 :
2 ,dbms_utility.data_block_address_block(20971665) "Block#"
3 from dual;
Rfile# Block#
---------- ----------
5 145
Running the next query can identify the associated index:
SQL> select owner, segment_name, segment_type
2 from dba_segments
3 where header_file = 5
4 and header_block = 145;
OWNER SEGMENT_NAME SEGMENT_TYPE
-------- --------------- ------------------
SCOTT I_TEST INDEX
Cause
There is a logical inconsistency between a table and its index. This kind of logical inconsistencies is commonly due to a problem with the High Water Mark (HWM) in the table where a full table scan may return less rows than an Index Scan.
This logical inconsistency can also be manifested with an ORA-600 [kdsgrp1] in 10g or ORA-600 [12700] in lower versions.
Solution
The rows retrieved through the index that are not retrieved by a full table scan can be identified by running this query:
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from
where
minus
select /*+ FULL(
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from
Example:
select /*+ INDEX_FFS(TEST I_TEST) */ rowid
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from test
where c2 is not null
minus
select /*+ FULL(TEST)*/ rowid
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from test;
The missing values from a full table scan can be stored in another table using the index with the next plsql (SCRIPT. 1):
create table test_copy as select * from test where 1=2;
declare
cursor missing_rows is
select /*+ INDEX_FFS(TEST I_TEST) */ rowid rid
from test
where c2 is not null
minus
select /*+ FULL(TEST)*/ rowid rid
from test;
begin
for i in missing_rows loop
insert into TEST_COPY
select /*+ ROWID(TEST) */ * from TEST where rowid = i.rid;
end loop;
end;
/
SOLUTION
- When the index has less rows than the table, recreating the index may solve this problem.
- When the index has more rows than the table, recreating the index or raising the HWM by running dummy inserts into the table may eventually fix this logical corruption. In this case the logical corruption is fixed but these rows may be "lost" for which there is the option to recover them by using "SCRIPT. 1" above before applying any of these solutions.
- To prevent this inconsistency see for the list of Known Issues below.
If additional help is required from Oracle Support, please provide:
1. The trace file generated by the analyze command.
2. The result of "QUERY 1" above.
3. The trace file generated by dumping the segment header for the base table:
from dba_segments
where owner = upper('&table_owner') and segment_name = upper('&table_name');
alter system dump datafile &header_file block &header_block;
This trace file will be used to identify the HWM.
@
@ Extent Control Header
@ -----------------------------------------------------------------
@ Extent Header:: spare1: 0 spare2: 0 #extents: 4 #blocks: 31
@ last map 0x00000000 #maps: 0 offset: 4128
@ Highwater:: 0x014000d6 ext#: 3 blk#: 5 ext size: 8
@
@ So, HWM is located at RDBA 0x014000d6 in extent_id=5 and block#=5 in that extent.
4. The result of this query to identify the extent id's for the additional rows retrieved by the index:
from (select /*+ INDEX_FFS(
相關文章
- MySQL裡的found_row()與row_count()MySql
- plsql_index by_table of_count_next_prior_last,first語法小測SQLIndexAST
- Getting Approximate Row Count of a Huge FileAPP
- index table (IOT)Index
- 0317TABLE ACCESS BY INDEX ROWID BATCHEDIndexBAT
- partition table and partition indexIndex
- 有關mysql中ROW_COUNT()的小例子MySql
- 安裝mysql遇到ERROR: 1136 Column count doesn't match value count at row 1MySqlError
- TABLE size (including table,index,lob,lobindex)Index
- 317TABLE ACCESS BY INDEX ROWID BATCHED2IndexBAT
- 317TABLE ACCESS BY INDEX ROWID BATCHED3IndexBAT
- analyze table/index validate structure加鎖的問題IndexStruct
- hint IGNORE_ROW_ON_DUPKEY_INDEXIndex
- alter table using indexIndex
- 【優化】COUNT(1)、COUNT(*)、COUNT(常量)、COUNT(主鍵)、COUNT(ROWID)等優化
- 啟用oracle table rowdependencies trace row modificationOracle
- pymysql.err.OperationalError: (1136, “Column count doesn‘t match value count at row 1“)報錯反省。MySqlError
- SQL最佳化-COUNT_ INDEX的巧用SQLIndex
- 收集full table / index scan sqlIndexSQL
- MySQL中的FOUND_ROWS()與ROW_COUNT()函式MySql函式
- 查詢使用表空間的TABLE,INDEX,INDEX SUBPARTITIONIndex
- CREATE INDEX index1 ON table1(col1)Index
- Oracle 12c新特性之——TABLE ACCESS BY INDEX ROWID BATCHEDOracleIndexBAT
- SELECT COUNT(*) 索引會走 index fast full scan索引IndexAST
- Index-Organized Tables with Row Overflow Area (230)IndexZed
- MySQL JDBC row_count()數字不準確的問題MySqlJDBC
- MySQL中 found_rows()和row_count()解釋及用法MySql
- 資料庫表--index organized table資料庫IndexZed
- 資料庫表--index clustered table資料庫Index
- Get table and index DDL in the easy way(轉)Index
- Oracle Index-organized table (IOT)概述OracleIndexZed
- 索引組織表(Index Organizied Table)索引Index
- 【MySQL】select for update 的Row Lock 與Table LockMySql
- css中display設定為table、table-row、table-cell後的作用及其注意點CSS
- Redo內部解析-Insert Single Row with Index(七)Index
- rfs (PID:146054): Database mount ID mismatch案例Database
- Oracle DataGuard Standby database ID mismatch錯誤OracleDatabase
- #1118 - Row size too large. The maximum row size for the used table type, not counting BLOBs