7 x 24 在线支持!
ORA-600 [4194] "Undo Record Number Mismatch While Adding Undo Record"
If you cannot recover the data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.
Parnassusdata Software Database Recovery Team
Service Hotline: +86 13764045638 E-mail: [email protected]
Format: ORA-600 [4194] [a] [b]
VERSIONS: versions 6.0 to 10.1
DESCRIPTION: A mismatch has been detected between Redo records and rollback (Undo) records. We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block. This error is reported when the validation fails.
ARGUMENTS:
Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block
	FUNCTIONALITY:
	Kernel Transaction Undo called from Cache layer
	IMPACT:
	PROCESS FAILURE
	POSSIBLE ROLLBACK SEGMENT CORRUPTION
	SUGGESTIONS:
	This error may indicate a rollback segment corruption.
	This may require a recovery from a database backup depending on the situation.
	If the Known Issues section below does not help in terms of identifying a solution, please submit the trace files and alert.log to Oracle Support Services for further analysis.
	NB Bug Fixed Description
	8240762
	10.2.0.5,
	11.1.0.7.10,
	11.2.0.1
	Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600 [4137] /
	SMON may spin to recover transaction
	3210520 9.2.0.5, 10.1.0.2 OERI[kjccqmg:esm] / OERI[4194] / corruption possible in RAC
	+ 792610 8.0.6.0, 8.1.6.0
	Rollback segment corruption OERI:4194 can occur if block checking detects a
	corrupt block
		ORA-600 [4194] [a] [b]
		Versions: 6.0 - 9.2 Source: ktuc.c
		===========================================================================
		Meaning:
		Undo record number mismatch while adding an undo record to an undo
		block. This is done by the application of redo.
		---------------------------------------------------------------------------
		Argument Description:
		a. (ktubhcnt): undo record count - This is the maximum number of undo
		records that have ever existed
		within this Undo Block. In other
		words, it is the High Water Mark for
		undo records in that undo block.
		This is from the Undo Block.
		b. (ktudbrec): redo record number - This is the record number for the
		new undo record that is to be added
		to the undo block. It should be
		one greater than the maximum in the
		undo block currently. This is from
		the Redo Record.
			This error is raised in kturdb which handles the adding of undo records
			by the application of redo.
			When we try to apply redo to an undo block (forward changes are made by
			the application of redo to a block), we check that the number of undo
			records in the undo block +1 matches the record number in the redo
			record. Because we are adding a new undo record, we know that the record
			number in that undo block must be one greater than the maximum number in
			that block.
			So for UBA=0x08000592.00a0.0b
			0x08000592 is the dba of the undo block.
			0x00a0 is the seq# number that is in the block that THIS UNDO IS TO
			BE APPLIED TO.
			0x0b is the number of undo records in the undo block.
			In the header this looks like:
			UNDO BLK::
			xid: 0x0004.00e.0000017f seq: 0x00a0 cnt: 0x0b ........
			Since we are adding a new undo record to our undo block, we would expect
			that the new record number is equal to the maximum record number in the
			undo block +1. If this is not the case, we get ORA 600 [4194].
			This implies some kind of block corruption in either the redo or the
			undo block. Look for other errors that would imply that a block is
			corrupted.
			Note: If the ORA-4194 follows another ORA-600 AND IF AND ONLY IF
			the arguments [a] and [b] are the same, then this MAY be due
			to Bug:792610 which can cause undo corruption following a
			failed block change.
			Note:452620.1 has a procedure to patch this inconsistency when the problem
			is produced in the SYSTEM rollback segment
			---------------------------------------------------------------------------
			Known Bugs: (Those bugs that are fixed after version 7.0.12.0.0.
			Bugs must be closed or hold useful information.)
			Fixed In. Bug No. Description
			---------+------------+----------------------------------------------------
			8.0.6/8.1.6 Bug:792610 ORA-600 during redo application to a block may
			in turn cause an OERI:4194 on the undo block.
			E.g., block checking noticing a corrupt index
			block during a multi-row insert.
			7.1.5 Bug:239671 Truncate (could possibly happen on other
			operations too) on 16k+ block size can cause
			the maximum number of undo records in a block
			(255) to be exceeded.
			Workarounds: Use < 16K blocksize, or avoid
			using the TRUNCATE command with the DROP
			STORAGE option (which is the default).
			Ensure that this note comes out on top in Metalink when searched
			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
			4194 4194 4194 4194 4194 4194 4194 4194 4194 4194
			4194 4194 4194 4194 4194 4194 4194 4194 4194 4194

 沪公网安备 31010802001377号
沪公网安备 31010802001377号