一生产库上有张表，做关联查询的时候便报ora-8103的错误，怀疑是有坏块，但是select count(*) 该表，不报错。
但是create table tt as 该表，依然报错ora-8103.
APPLIES TO:Oracle Database - Enterprise Edition - Version 184.108.40.206 to 220.127.116.11 [Release 8.1.5 to 12.2]
Information in this document applies to any platform.
This article provides information about error ORA-8103 and possible actions.
This note is intended for general audience as initial starting point for beginning diagnosis of ORA-8103.
ORA-8103 is reporting that a SQL statement found a block that no longer belongs to the object referenced in the statement.
ORA-8103 is caused by an invalid block type. The block header has an invalid block type or the block type inside the block is not expected; e.g. a data block (Type = 6) was expected but the actual block information is not a data block (Type != 6).
ORA-8103 is also caused by an unexpected data_object_id where it is concurrently changing for the involved object while the affected SQL statement is executed.
These two causes might be due to an expected behavior or other problems. Details are:
Tables are being dropped/truncated while a SQL statement for those tables is still in execution. In the case of an index, it might be caused by an index rebuild. In other words the object has been deleted by another session since the operation began.
Look if dba_objects.data_object_id is changing for the affected object while queries are being executed.
data_object_id is changed by DDL statements like:
For a truncate look for column TRUNCATED in DBA_TAB_MODIFICATIONS. Note that it indicates whether the table has been truncated since the last analyze. See documentation.
In 11g+ parameter enable_ddl_logging can be set to TRUE to print DDL statements in the alert log or in 12c in the log/ddl sub-directory of the ADR home (example <diagostic_dest>/rdbms/<sid>/<dbname>/log/ddl_$ORACLE_SID.log) and identify what DDL's are run that may potentially cause this error.
Hardware, IO subsystem or OS problems may cause block corruptions overwriting the Block Type in the block header causing the error ORA-8103.
The block is healthy but it is an "OLD/STALE" block. These kind of corruptions might be caused by LOST IO/LOST WRITE or a bug in external non-oracle tools that migrate file systems while the database is OPEN. In that case the data_object_id for the affected object could have changed but the actual block does not reflect it.
Note that the block may also be temporarily corrupted in the buffer cache (SGA Memory).
Overlapped Extents means that two or more segments incorrectly use the same block. This is a LMT Bitmap Extent inconsistency or Data Dictionary inconsistency.
To identify overlapped extents run the next checks:
For LMT (Locally Managed Tablespaces) run :
- Note that the session running dbms_space_admin does not say in the screen if an inconsistency is detected. dbms_space_admin will generate a trace file instead. So check if "oradebug tracefile_name" provides a trace file.
- If ORA-8103 is produced by tablespace_verify, it means that a block associated to the segment header is affected. Identify the affected object as explained in the section below and drop it. It may convert the segment to temporary which may need the usage of dbms_space_admin.segment_corrupt and dbms_space_admin.segment_drop to completely remove the segment.
For Data Dictionary managed tablespaces run the hcheck script in:
Note 136697.1 (it checks for overlapped extents through fet$/uet$).
Overlapped ASM extent.
If using ASM: overlapped ASM extents is when 2 different files and 2 different extents use the same Allocation Unit (AU) in the same ASM disk.
From the ASM instance run:
In ASM alert log the next message is registered:
Meaning that ASM file number 3551 Physical Extent 3819 is using Allocation unit 78 in Disk 254 and at the same time ASM File Number 3564 has Physical Extent pointing to the same Allocation unit.
It can be an Oracle bug. See section "known issues" below.
Identify the affected object
Sometimes the SQL statement producing the ORA-8103 involves several tables and the affected object can be an index. Follow the next procedures to identify the affected object:
Get the SQL statement that is causing the error.
Reproduce the error from SQL*Plus if possible by running the affected SQL statement.
Identify the affected object in trace file section "dump suspect buffer".
In some cases when a trace file is generated, either by default with no error printed or by enabling the 8103 errorstack event mentioned later, there is a section "dump suspect buffer" that can be used to extract the object_id of the affected segment and query dba_objects to identify it. Example from a trace file:
Identify the affected object with ANALYZE.
Is it a TABLE or an INDEX causing the error?. Exectute the analyze command and if there is an error, open the trace file as it may contain the suspect buffer:
For a TABLE run:For an INDEX run:
Alternatively identify if a full table scan is producing the error.
Identify the object with event 10236.
In 18.104.22.168 or above if ktrget is in the call stack trace for an ORA-8103, setting Event 10236 will include the block number in the trace file causing the error:
Open the trace file, it may have:
Meaning that the error is produced in rdba=0x32810e06
Convert that number to decimal and get the relative_fno, block#:
Then use Note 819533.1 to identify the object; section "Identify the Corrupt Object".
In some cases the event 10236 may produce the next information, meaning that the error is produced by rdba=0x1965ee16:
Identify the object with event 10200.
Event 10200 can be used to identify the last accessed block when this error is produced. event trace_buffer_on can be used to generate a smaller trace file. Errorstack and event 10236 can be added to get a more complete trace file:
In the trace file generated locate last information about:
Trace output example:
The error is produced while reading rdba=0x00405303 (File=1,Block=21251) as there is NOT a message like:
"Consistent read finished for block 0 : 00405303"
Then use Note 819533.1 to identify the object; section "Identify the Corrupt Object".
Identify object affected by Block Corruption.
Use DBVerify or RMAN to identify corrupted blocks associated to the datafiles where the object is stored.
A common corruption is when the block has been zeroed out (block type is also zero). DBVerify reports it as:
Use sections "DBVerify - Identify Datafile Block Corruptions" or "RMAN - Identify Datafile Block Corruptions" in Note 836658.1 and Note 819533.1 to identify the affected object.
Identify object affected by Overlapped Extents.
If overlapped extents in Locally Managed Tablespace is identified, use Note 887263.1 to identify the segments involved.
ORA-8103 in XML objects
XDB status may be INVALID in DBA_registry or it could be due to XDB metadata corruption. Check Doc ID 1553078.1 for reference; although it mentions an ORA-1410 the treatment is the same. Contact Oracle XDB support for futher information.
- Setting event "8103 trace name errorstack level .." will report all the ORA-8103 errors produced in the database; it will also include those cases where the error is internally handled by the Oracle rdbms. This may give the false impression of an issue; there are cases where the error is handled internally by Oracle and the server process will not report the error to the user even though there is a trace reported for the ORA-8103. If the error is not reported to the application then the error should not be a concern.
Fix Block Corruption.
If error ORA-8103 is constantly reproduced by ANALYZE and if it has been determined that it is not the expected behavior, then it means that there is a possible block corruption. The possible solutions are:
Flush the buffer cache.It might be a corruption only in the SGA memory (Buffer cache):
In a RAC system, flushing the buffer cache may be needed in the additional rac instances.
If error persists, continue with the next steps:
Flush the shared pool.
In some cases the problem can be caused by an cursor invalidation problem for which flushing the shared_pool can be a workaround:
If error still persists, then it could be a permanent problem present on disk. Continue with next steps:
Index Corruption.Drop and recreate the index.
Table Corruption.1. Consider to apply media recovery if it is determined that the problem was caused by a corrupt block (Like zeroed out blocks). RMAN BLOCKRECOVER can be used to repair a zeroed out block.
2. TRUNCATE or DROP it and reload the data from export dump. If the the same error is produced by dropping/truncating a PARTITION, then consider to EXCHANGE:
Note: <new_table> has to have the same structure as <table_name>.
3. If recover from a backup is not an option, table data can be saved skipping the blocks that are causing the ORA-8103 error:
OPTION 1 - No backup
If the table has an index use the plsql script provided in Note 1527738.1
OPTION 2 - No backupIf the table does not have an index, use script provided in Note 422547.1
Another solution is to determine if dbms_repair can be used to skip these blocks or if procedure described in Note 61685.1 can be used to skip corrupted blocks using rowid scans.
Temporary Segment CorruptionIf it is identified that the ORA-8103 is caused by a temporary segment, use dbms_space_admin to drop the temporary segment and rebuild the tablespace bitmap:
Fix Overlapped Extents.
If the error is caused by Overlapped extents in a LOCALLY MANAGED Tablespace (LMT):
- Drop one of the affected objects. If the segment is converted to temporary then use dbms_space_admin.segment_corrupt and dbms_space_admin.segment_drop to remove the segment.
- Make sure that there are not more overlap extents by running dbms_space_admin.assm_tablespace_verify or dbms_space_admin.tablespace_verify
- Fix the overlap inconsistency by running dbms_space_admin.tablespace_rebuild_bitmaps. Note that it will not fix the current affected blocks producing ORA-8103.
For a DICTIONARY MANAGED tablespace determine if the database has to be recreated.