<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>《ORACLE 8.0.5 ORA-01207故障恢复》的评论</title>
	<atom:link href="https://www.xifenfei.com/2014/02/oracle-8-0-5-ora-01207%e6%95%85%e9%9a%9c%e6%81%a2%e5%a4%8d.html/feed" rel="self" type="application/rss+xml" />
	<link>https://www.xifenfei.com/2014/02/oracle-8-0-5-ora-01207%e6%95%85%e9%9a%9c%e6%81%a2%e5%a4%8d.html</link>
	<description>提供7*24专业数据库(Oracle,SQL Server,MySQL,PostgreSQL等)恢复和技术支持@Tel:17813235971</description>
	<lastBuildDate>Thu, 11 Dec 2025 02:46:14 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>作者：惜分飞</title>
		<link>https://www.xifenfei.com/2014/02/oracle-8-0-5-ora-01207%e6%95%85%e9%9a%9c%e6%81%a2%e5%a4%8d.html/comment-page-1#comment-3854</link>
		<dc:creator><![CDATA[惜分飞]]></dc:creator>
		<pubDate>Fri, 14 Feb 2014 09:34:40 +0000</pubDate>
		<guid isPermaLink="false">https://www.xifenfei.com/?p=5099#comment-3854</guid>
		<description><![CDATA[[shell]
ORA-600[4147][a][b] it’s a corruption in the undo segment. 
Block not new enough (Undo) Sequences match but count wrong. 

[a] Record number from the UBA we want to look at. 
[b] Count on the Undo block header. 

This error is raised when we are looking at a data block, and need to read the undo pointed at by the UBA(eg. for CR) but the record number from the UBA we want to look at doesn’t exist in the undo block header. 

The UNDO block we are looking at is dumped to the trace file before the ORA-600[4147] and call stack. 

E.g. in 10.1.0.5

 The undo record shows:

2007-07-10 10:48:48.467 
*** SERVICE NAME:(SYS$USERS) 2007-07-10 10:48:48.466 
*** SESSION ID:(281.26013) 2007-07-10 10:48:48.466 
Dump of buffer cache at level 3 
BH (0x0x72fcbfe0) file#: 2 rdba: 0x00802fdc (2/12252) class: 42 ba: 0x0x72618000 
  set: 6 blksize: 8192 bsi: 0 set_flg: 0 pwbcnt: 0 
  dbwrid: 0 obj: -1 objn: 0 tsn: 1 afn: 2 
  hash: [53faf870,ac20da50] lru: [53fd885c,57fb57ec] 
  ckptq: [60fe6408,53fd8830] fileq: [77fed448,68fe2cf0] 
  use: [NULL] wait: [NULL] 
  st: XCURRENT md: NULL tch: 2 txn: 0xac793324 
  flags 0x2002009: buffer_dirty private gotten_in_current_mode redo_since_read 
  LRBA: [0xba99.1bd30.0] HSCN: [0x0.132c41a1] HSUB: [1] 
  buffer tsn: 1 rdba: 0x00802fdc (2/12252) 
  scn: 0x0000.132c41a1 seq: 0x06 flg: 0x00 tail: 0x41a10206 
  frmt: 0x02 chkval: 0x0000 type: 0x02=KTU UNDO BLOCK 
  
******************************************************************************** 
UNDO BLK:   
xid: 0x000d.024.00004a96  seq: 0x13ae cnt: 0xa   irb: 0xa   icl: 0x0   flg: 0x0000  --&gt; cnt: 0xa   = 10 
The problem undo segment is usn#=13(d in hex) 
--&gt; cnt: 0xa   = 10 means this TX has only 10 chained records 

 *** 2007-07-10 10:50:13.794 
ksedmp: internal or fatal error 
ORA-00600: internal error code, arguments: [4147], [12], [10], [], [], [], [],  
Current SQL statement for this session: 
UPDATE POTENTIAL_VIOS .... 

Block header dump:  0x09004664 
 Object id on Block? Y 
 seg/obj: 0x17adb  csc: 0x00.132c4258  itc: 2  flg: O  typ: 1 - DATA 
     fsl: 0  fnx: 0x9004665 ver: 0x01 
  
 Itl           Xid            Uba               Flag  Lck        Scn/Fsc 
0x01   0x000d.024.00004a96  0x00802fdc.13ae.0c  ----  1  fsc 0x0000.00000000   
0x02   0x000d.020.00004a96  0x00802fdc.13ae.02  C---  0  scn 0x0000.132c4193 

 

We need to update a record that is part of an uncommitted TX  
and the changes are in Uba: 0x00802fdc.13ae.0c.    
   
Uba is the UndoBlockAddress =   dba.seq#.rec# 
The Uba shows rec#= 0c -&gt; the change is in  rec chain 12,  
however the undo header shows this TX has only 10 chain records. 

Because of this mismatch we raise the ora-600[4147[12][10] 
[/shell]]]></description>
		<content:encoded><![CDATA[<pre class="brush: bash; title: ; notranslate">
ORA-600[4147][a][b] it’s a corruption in the undo segment. 
Block not new enough (Undo) Sequences match but count wrong. 

[a] Record number from the UBA we want to look at. 
[b] Count on the Undo block header. 

This error is raised when we are looking at a data block, and need to read the undo pointed at by the UBA(eg. for CR) but the record number from the UBA we want to look at doesn’t exist in the undo block header. 

The UNDO block we are looking at is dumped to the trace file before the ORA-600[4147] and call stack. 

E.g. in 10.1.0.5

 The undo record shows:

2007-07-10 10:48:48.467 
*** SERVICE NAME:(SYS$USERS) 2007-07-10 10:48:48.466 
*** SESSION ID:(281.26013) 2007-07-10 10:48:48.466 
Dump of buffer cache at level 3 
BH (0x0x72fcbfe0) file#: 2 rdba: 0x00802fdc (2/12252) class: 42 ba: 0x0x72618000 
  set: 6 blksize: 8192 bsi: 0 set_flg: 0 pwbcnt: 0 
  dbwrid: 0 obj: -1 objn: 0 tsn: 1 afn: 2 
  hash: [53faf870,ac20da50] lru: [53fd885c,57fb57ec] 
  ckptq: [60fe6408,53fd8830] fileq: [77fed448,68fe2cf0] 
  use: [NULL] wait: [NULL] 
  st: XCURRENT md: NULL tch: 2 txn: 0xac793324 
  flags 0x2002009: buffer_dirty private gotten_in_current_mode redo_since_read 
  LRBA: [0xba99.1bd30.0] HSCN: [0x0.132c41a1] HSUB: [1] 
  buffer tsn: 1 rdba: 0x00802fdc (2/12252) 
  scn: 0x0000.132c41a1 seq: 0x06 flg: 0x00 tail: 0x41a10206 
  frmt: 0x02 chkval: 0x0000 type: 0x02=KTU UNDO BLOCK 
  
******************************************************************************** 
UNDO BLK:   
xid: 0x000d.024.00004a96  seq: 0x13ae cnt: 0xa   irb: 0xa   icl: 0x0   flg: 0x0000  --&gt; cnt: 0xa   = 10 
The problem undo segment is usn#=13(d in hex) 
--&gt; cnt: 0xa   = 10 means this TX has only 10 chained records 

 *** 2007-07-10 10:50:13.794 
ksedmp: internal or fatal error 
ORA-00600: internal error code, arguments: [4147], [12], [10], [], [], [], [],  
Current SQL statement for this session: 
UPDATE POTENTIAL_VIOS .... 

Block header dump:  0x09004664 
 Object id on Block? Y 
 seg/obj: 0x17adb  csc: 0x00.132c4258  itc: 2  flg: O  typ: 1 - DATA 
     fsl: 0  fnx: 0x9004665 ver: 0x01 
  
 Itl           Xid            Uba               Flag  Lck        Scn/Fsc 
0x01   0x000d.024.00004a96  0x00802fdc.13ae.0c  ----  1  fsc 0x0000.00000000   
0x02   0x000d.020.00004a96  0x00802fdc.13ae.02  C---  0  scn 0x0000.132c4193 

 

We need to update a record that is part of an uncommitted TX  
and the changes are in Uba: 0x00802fdc.13ae.0c.    
   
Uba is the UndoBlockAddress =   dba.seq#.rec# 
The Uba shows rec#= 0c -&gt; the change is in  rec chain 12,  
however the undo header shows this TX has only 10 chain records. 

Because of this mismatch we raise the ora-600[4147[12][10] 
</pre>
]]></content:encoded>
	</item>
	<item>
		<title>作者：惜分飞</title>
		<link>https://www.xifenfei.com/2014/02/oracle-8-0-5-ora-01207%e6%95%85%e9%9a%9c%e6%81%a2%e5%a4%8d.html/comment-page-1#comment-3853</link>
		<dc:creator><![CDATA[惜分飞]]></dc:creator>
		<pubDate>Fri, 14 Feb 2014 09:26:38 +0000</pubDate>
		<guid isPermaLink="false">https://www.xifenfei.com/?p=5099#comment-3853</guid>
		<description><![CDATA[ORA-600 [3668] &quot;Media Recovery Required After CREATE CONTROLFILE&quot; (Doc ID 93665.1)
[shell]
ERROR:
  ORA-600 [3668] [a] [b] [c] [d] [e]

VERSIONS:
  versions 7.0 to 9.2

DESCRIPTION:

  This is the FIRST time an attempt has been made to start an instance 
  after a CREATE CONTROLFILE command has been issued.

  At least one data file needs MEDIA RECOVERY.

  The error has been externalised in Oracle 9.2.x as :

      ORA-1113: file &lt;name&gt; needs media recovery.

ARGUMENTS:
   Arg [a]  File number needing media recovery
   Arg [b]  Control file status 
   Arg [c]  Control file checkpoint count
   Arg [d]  File header checkpoint count
   Arg [e]  File header status
 
FUNCTIONALITY:
  CACHE RECOVERY COMPONENT
 
IMPACT:
  INSTANCE FAILURE - Usually unable to start the instance when
                     receiving this error.
 
SUGGESTIONS:        

  This should only ever be signalled if a CREATE CONTROLFILE has just been 
  performed and one or more files need media recovery.

  In this case it is best to:

  o  recreate the controlfile again.

        Prior to doing this, check that the create controlfile statement
        is accurate in all respects.

        For example, check that it contains the correct number of 
        datafiles for each tablespace and that these files exist.

        Check that it contains the correct number of redo log groups.

  o  Perform the appropriate media recovery

         The type of recovery to be performed depends on the circumstances. 

         Doing a complete media recovery :

             RECOVER DATABASE (if create controlfile was NORESETLOGS)
             ALTER DATABASE OPEN;

         Doing an incomplete recovery (for example time based, change based
         or until CANCEL) :

             RECOVER DATABASE USING BACKUP CONTROLFILE (if using RESETLOGS)
             ALTER DATABASE OPEN RESETLOGS;

             You may need to supply the names of the ONLINE logs to complete 
             the &#039;BACKUP CONTROLFILE&#039; recovery.
[/shell]]]></description>
		<content:encoded><![CDATA[<p>ORA-600 [3668] &#8220;Media Recovery Required After CREATE CONTROLFILE&#8221; (Doc ID 93665.1)</p>
<pre class="brush: bash; title: ; notranslate">
ERROR:
  ORA-600 [3668] [a] [b] [c] [d] [e]

VERSIONS:
  versions 7.0 to 9.2

DESCRIPTION:

  This is the FIRST time an attempt has been made to start an instance 
  after a CREATE CONTROLFILE command has been issued.

  At least one data file needs MEDIA RECOVERY.

  The error has been externalised in Oracle 9.2.x as :

      ORA-1113: file &lt;name&gt; needs media recovery.

ARGUMENTS:
   Arg [a]  File number needing media recovery
   Arg [b]  Control file status 
   Arg [c]  Control file checkpoint count
   Arg [d]  File header checkpoint count
   Arg [e]  File header status
 
FUNCTIONALITY:
  CACHE RECOVERY COMPONENT
 
IMPACT:
  INSTANCE FAILURE - Usually unable to start the instance when
                     receiving this error.
 
SUGGESTIONS:        

  This should only ever be signalled if a CREATE CONTROLFILE has just been 
  performed and one or more files need media recovery.

  In this case it is best to:

  o  recreate the controlfile again.

        Prior to doing this, check that the create controlfile statement
        is accurate in all respects.

        For example, check that it contains the correct number of 
        datafiles for each tablespace and that these files exist.

        Check that it contains the correct number of redo log groups.

  o  Perform the appropriate media recovery

         The type of recovery to be performed depends on the circumstances. 

         Doing a complete media recovery :

             RECOVER DATABASE (if create controlfile was NORESETLOGS)
             ALTER DATABASE OPEN;

         Doing an incomplete recovery (for example time based, change based
         or until CANCEL) :

             RECOVER DATABASE USING BACKUP CONTROLFILE (if using RESETLOGS)
             ALTER DATABASE OPEN RESETLOGS;

             You may need to supply the names of the ONLINE logs to complete 
             the 'BACKUP CONTROLFILE' recovery.
</pre>
]]></content:encoded>
	</item>
</channel>
</rss>
