Email: service@parnassusdata.com 7 x 24 online support!
Oracle ORA-600 [4097] ORA-00600 [4097] “Corruption”
If you cannot recover data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.
Parnassusdata Software Database Recovery Team
Service Hotline: +86 13764045638 E-mail: service@parnassusdata.com
ERROR:
Format: ORA-600 [4097]
VERSIONS: versions 7.3 to
DESCRIPTION:
We are accessing a rollback segment header to see if a transaction has been committed.
However, the xid given is in the future of the transaction table.
This could be due to a rollback segment corruption issue OR you might be hitting the following known problem.
FUNCTIONALITY: Rollback
IMPACT:
If known issue (see below) this might cause missing data.
Otherwise, this could be a possible rollback segment corruption issue.
Known Bugs
NB |
Bug |
Fixed |
Description |
13340388 |
11.2.0.3.3, 11.2.0.3.BP07, 12.1.0.0 |
ORA-600 [kzaxpopr14 -Error in decoding xml text] when querying V$XML_AUDIT_TRAIL |
|
OERI SECUREFILE TRANSPORT
10249791 11.2.0.2.BP02,on DMLS referencing SECUREFILE plugged
11.2.0.2.7,
11.2.0.3, 12.1.0.0 11.1.0.7.4, 11.2.0.1.2, 11.2.0.2, 12.1.0.0 11.1.0.7.2, 11.2.0.1.1,
11.2.0.2, 12.1.0.0
7687856 11.2.0.1 5653641 11.2.0.1
ORA-600 [4097] / ORA-600 [4000] reported using transportable tablespaces
* 9145541
OERI[25027]/OERI[4097]/OERI[4000]/ORA- 1555 in plugged datafile after CREATE CONTROLFILE in 11g
OERI[4097] after using distributed 8565708 11.2.0.1.BP04,transactions in RAC
3613078
2628232
9.2.0.6,
ORA-600 [4000] from DML on transported ASSM tablespace
Corrupt dictionary from DROP TABLESPACE containing _offline_rollback_segments OERI[4097] from DML on TRANSPORTED tables with ASSM
Block corruption possible on temp files
ORA-600’s from CR served block from a plugged in tablespace
OERI:4097 possible on objects in read only transported tablespace
Tru64: OERI:4097 possible on RAC / OPS
Drop of Rollback segments can cause OERI:4097 / missing data
10.1.0.3 3249755 9.2.0.5, 10.1.0.2 9.2.0.4,
10.1.0.2
8.1.7.4, 2165601 9.0.1.3, 9.2.0.1
P 1885251 * 427389
‘*’ against a bug indicates that an alert exists for that issue. ‘+’ indicates a particularly notable bug.
‘P’ indicates a port specific bug.
‘@’ indicates UNPUBLISHED information
Fixed versions use “BPnn” to indicate Exadata bundle nn. “OERI:xxxx” may be used as shorthand for ORA-600 [xxxx].
9015PSE, 9.2.0.1 7.3.3.3, 7.3.4.0, 8.0.3.0
Some historic info….
Upgrade/install a patchset to bring the database to one of the following levels : 7.3.3.3, 7.3.4.0, 8.0.3.0
To avoid encountering this bug, rollback segments should only be dropped and recreatedaftertheinstancehasbeenshutdownnormalandrestarted. Ifyou have already encountered the bug, use the following workaround:
Possible workaround:
– Drop all rollback segments, except for SYSTEM
– Create the same number of rollback segments, small ones, with different names – recreate the original rollback segments
– drop the small dummy rollback segments
Every time you need to add a rollback segment, first create all of the dummy segments again, to make sure they use up the old segment numbers. Then create the new segment, then drop all dummy segments.
If you are getting this error not because of the above bug — see Description to see how you could run into the bug — then you might have a rollback segmentcorruptionissue. Typicalcausesaremediacorruptiontothe rollbacksegmentblocks,checkyourhardware. Toworkaroundarollback segment corruption problem (not because of known bug above) log the
issue with Oracle support.
ORA-600 [4097]
Versions:7.1.3 -7.3.2
Source:ktu.c
===========================================================================
Meaning:
We are accessing a rollback segment header to see if a transaction has beencommitted. However,thexidgivenisinthefutureofthe transaction table. Ie: the WRAP of the XID is higher than
the current WRAP number on the RBS header.
————————————————————————— Argument Description:
No arguments.
————————————————————————— Diagnosis:
This should be considered as a corruption.
1. Try to identify which object has this TX in its ITL list. (see the trace file)
- If this object is recreatable that may be an option but we cant be sure whether it is the TX table that is too old or the block holding the ITL that is corrupt.
-
You MAY be able to recreate the RBS – It is safest to force
cleanout of all blocks before recreating the RBS (by FTS and recreating indexes).
Typical causes are media corruption to the data or RBS blocks, especially lost writes to RBS header.
This is also possible if rollback segments are recreated after a shutdownabort. SeeBug:427389 fordetails&options.Inthis case no data is corrupt, the rollback segments are just out of step.
Description and Workarounds for Bug:427389 Note:1011003.102
ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600
ora-600 ora-600 ora-600 ora-600 ora-600 ora-600 ora-600
4097 4097 4097 4097 4097
4097 4097 4097 4097 4097 4097 4097 4097 4097 4097 4097 4097 4097 4097 4097