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)

 

  1. 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.
  2. 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

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569