ORA-600[2662]错误的触发原因是ORACLE发现居然有数据块的SCN号要比我系统当前的SCN还要大，这是不被允许的，这通常说明 在前滚过程中应用的redo是不完整的，这导致系统SCN要比一些已经写到磁盘上的块的SCN还小一点。对于这种问题常见的方案就是调整SCN adjust scn 《手动递增SCN号的几种方法：How to increase System Change Number by manual》
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
与ORA-00600[2662]相关一些 bug如下：
Bug 4453449 Abstract: Flashback to guaranteed restore point in orphan inc may result in ORA-600[3020] Versions affected: 10.2.0.1 Fixed in versions: 10.2.0.2 & 11.0 Backportable: Yes Symptoms: The symptom of this bug include ORA-600[3020], ORA-600[2662] after flashback database and ORA-600[flashback_validation] during flashback database. There may also be other symptoms. Details: ORA-600[3020] / ORA-600 [2662] / ORA-600 [flashback_validation] can occur after/during multiple flashback/recovery through multiple database resetlogs without opening the database. There may also be other symptoms which appear as recovery related corruption errors. Workaround: 1. If you flashback a crashed primary database, follow flashback database with open resetlogs. Alternatively, if you'd like to completely undo flashback database, follow flashback database with recover database without shutting down the instance first. 2. Restore backup and recover. Patch details: Currently there is no one-off patch available for any platform and versions. Bug 2899477 (Unpublished) Abstract:ORA-600[2662] CAUSES INSTANCE CRASH Versions affected: 9.2.0.4 Fixed in versions: 9.2.0.4 & 10.1 Backportable: Yes Symptoms: When you have a corrupted SCN and if the corruption is found in selexe, getting uninitialized selenv from opiexe, then this may be the bug. Details: It is possible for an uninitialized variable to be passed on for a select statement which could result in a false ORA-600 [2662] error. Workaround: None Patch details: One-off patch available for few platforms on top of 9.2.0.4 Check the Metalink for Patch 2899477 availability. Bug 2764106 Abstract: ORA-600 [2662] BRINGS THE DATABASE DOWN Versions affected: 8.1.7.4 & 9.2.0.4 Fixed in versions: 9.2.0.5 & 10.1 Backportable: Yes Symptoms: OERI(2662) even The dependent scn present in the disk blocks are fine. Details: A false ORA-600 [2662] error can occur on SELECT operations which can result in an instance crash even though there is no underlying problem with the on disk SCN. Workaround: None Patch details: One-off patch available for few platforms on top of 8.1.7.4 & 9.2.0.4 Check the Metalink for Patch 2764106 availability. Bug 2216823 (Unpublished) Abstract:OERI(2662) REPORTED WHEN REUSING TEMPFILE WITH RESTORED DB Versions affected: 9.2.0 Fixed in versions: 10.1.0 Backportable: No Symptoms: eg: 1. Create a TEMP tablespace. 2. Shutdown a database. 3. Copy control file, data files, and log files to another directory (but not tempfile). 4. Restart a database. 5. Create a temporary table and insert into it, thereby causing tempfile to be updated. 6. Shutdown a database. 7. Restore a database. 8. Restart a database. 9. Create a temporary table and insert into it. 10. Commit ^- ORA-600 [2662] Details: ORA-600 [2662] can occur when reusing a TEMPFILE with a restored database. Workaround: The workaround is not to use the pre-existing tempfile. Instead either backup the tempfile with rest of the database or remove the tempfile then recreate a new tempfile once the database is open. Patch details: Currently there is no one-off patch available for any platforms and versions Bug 2054025 (Unpublished) Abstract:ORA-600 [2662] RELATED TO KDIT.C Versions affected: 9.0.1.2 Fixed in versions: 9.0.1.3 9.2.0.1 Backportable: No Symptoms: OERI:2662 possible on new TEMPORARY index block Details: ORA-600 [2662] possible on new TEMPORARY index block Workaround: None Patch details: Currently there is no one-off patch available for any platforms and versions Bug 851959 Abstract : ORA-600 [2662] OCCURRED DURING CREATE SNAPSHOT AT MASTER SITE Details : It is possible to get ORA-600 [2662] caused by mis-adjustment of the Oracle7 SCN (in PARALLEL SERVER mode) when an Oracle8 instance selects from it over a DBLINK Version affected : 7.3.4.X Fixed in version: 7.3.4.5 Workaround : None Patch details : Currently there is no one-off patch available for any versions/platforms. Bug 647927 (Unpublished) Abstract : LOCK PROCESS DIES WITH ORA-600 [2662], [0], [40057943], [0], [40063994] Version affected 8.0.4.X Fixed in version : 8.0.4.2 8.0.5.0 Symptoms : Digital Unix ONLY: OERI:2662 could occur under heavy load Workaround : None Patch details : Currently there is no one-off patch available for any versions/platforms. Bug 5612217 (Unpublished) Abstract : ORA-7445 [KDKBIN] LEADING TO ORA-600 [2662] DUE TO BUFFER CORRUPTION Version affected : 9.2.0.X Workaround : None Patch details : One-off patch available for few platforms on top of 9.2.0.7 Check the Metalink for Patch 5612217 availability. Bug 4599505 (Unpublished) Abstract : ORA-600 [2662] error Version affected : 10.2.0.X Fixed in version : 11.0 Symptoms : ORA-600[2662] after flashback database. Workaround : This problem may disappear by itself after the database has been opened for a while and its SCN has passed the SCN of the problematic block. This is however not a guaranteed workaround Patch details : Currently there is no one-off patch available for any versions/platforms. Bug 2998110 Abstract :ORA-600 [2662] LARGE QUERIES ON STANDBY WITH LOCALLY MANAGED TMP TBLSP Version affected : 9.2.0.X 10.1.0.X Fixed in version : 10.2 Symptoms : The scn of the tempfiles is advanced but not on any other files when the database is opened in read only mode. Workaround : 1) Increase the sort_area_size to avoid sort on disk thus avoiding the use of the tempfiles --OR-- 2) After opening the database read only and BEFORE executing any queries against the standby database, drop and recreate the tempfiles. --OR-- 3) If you are on 10.1 release you can set the following parameter: _init_tempfile_on_open=TRUE in your init.ora/spfile and bounce the database. Setting this parameter will clear all tempfile bitmaps when the database is opened so the database open may be take a little longer. Patch details : Currently there is no one-off patch available for any versions/platforms. This bug is fixed in 10.2 and is not backportable to previous releases. Note 356583.1 has been linked to this scenario. Bug 3517013 (Unpublished) Abstract :OPEN DB RESETLOG AFTER FLASHBACK DB FAILS ORA-600 [KCLCHKBLK_4], [1904] Symptoms : 1) When restored the database from backup and did an incomplete recovery. 2) Opened the database with resetlogs. 3) After opening the database, you start getting following errors: ORA-00600 [kclchkblk_4] ORA-00600 [2662] 4) Stack trace is:- kclchkblk kcbzib kcbgcur ktfbhget ktftfcload Cause : 1) Error, ORA-600[KCLCHKBLK_4], is signaled because the SCN in a tempfile block is too high. The same reason caused the ORA-600[2662]s in the alert logs. 2) This issue is because the tempfiles may not get reinitialized during open resetlogs. Patch details : Currently there is no one-off patch available for any versions/platforms. Note 275902.1 has been linked to this scenario and solution given under this note. Many other bugs were filed with development for this issue. Those bugs are not progressed due to -- Lack of response from the customers -- one-time occurances -- Vendor OS Problem
Current SCN WRAP Arg 
Current SCN BASE Arg 
dependent SCN WRAP Arg 
dependent SCN BASE Arg 
Where present this is the DBA where the dependent SCN came from. Check the SCN difference [argument d]-[argument b]. If the SCNs in the error are very close, then try to shutdown and startup the instance several times. 1. Create pfile: $sqlplus / as sysdba SQL>create pfile from spfile; 2. Add the following parameter in init.ora: UNDO_MANAGEMENT=MANUAL _ALLOW_RESETLOGS_CORRUPTION = TRUE 3. Startup the database using pfile: SQL>startup mount pfile=’/…./initORCL.ora’ SQL>show parameter corrupt; 4. Recover and open the database: SQL>RECOVER DATABASE UNTIL CANCEL; Cancel SQL>ALTER DATABASE OPEN RESETLOGS; Please use the following steps to force open the database: 1. Get all the rollback segment information: $strings /u01/database/system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u > listSMU ==>Please replace the path and system01.dbf to the datafile name of the system tablespace. 2. Create pfile: $sqlplus / as sysdba SQL>create pfile from spfile; 3. Add the following parameter in init.ora: UNDO_MANAGEMENT=MANUAL _ALLOW_RESETLOGS_CORRUPTION = TRUE _CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, …etc) ==>In the generated file listSMU, there will be many rollback segments listed, please add these rollback segments to the () Please don’t forget to rename the _SYSSMU9 to _SYSSMU9$ (add $ in the end)… 4. Startup the database using pfile: SQL>startup mount pfile=’/…./initORCL.ora’ SQL>show parameter corrupt; 5. Recover and open the database: SQL>RECOVER DATABASE UNTIL CANCEL; Cancel SQL>ALTER DATABASE OPEN RESETLOGS; 6. Then check if the database can be opened successfully. If startup failed with error: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 … Need to follow Note 741227.1 to adjust SCN: SQL>startup pfile=’…’; SQL>select checkpoint_change# from v$database; 1450301 Found the following expected SCN in the trace file: Searching by the “seg/obj”: data scn 0x0000.00000132 306 fsc 0x0000.0016a414 hex: 0x0000.0016a414 ==>decimal: 1483796 so 1450301 <1483796, which is not correct SQL> select ceil(&decimal_scn_expected/1024/1024/1024) from dual; Enter value for decimal_scn_expected: 1483796 old 1: select ceil(&decimal_scn_expected/1024/1024/1024) from dual new 1: select ceil(1483796/1024/1024/1024) from dual ; CEIL(1483796/1024/1024/1024) —————————— 1 那么需要调整SCN， 请在参数文件中添加下面的参数 _minimum_giga_scn= 然后再： SQL> startup pfile=’…’; SQL>RECOVER DATABASE UNTIL CANCEL; Cancel SQL>ALTER DATABASE OPEN RESETLOGS; 请注意上面的命令会把SCN跳高，不要让这个数据库和其他数据库通过dblink连接，否则可能把其他数据库的SCN也跳高。 Note: After opened the database, it is a desupported DB and you must export , recreate a new DB and import the data to the new DB. Be aware that the use of _OFFLINE_ROLLBACK_SEGMENTS may lead to the recreation of the database, depending on whether there were active transactions in the dropped undo segments. If so, then this may lead to logical corruption, and hence to the recreation of the database. (Refer Note:106638.1 that explains how to check the transaction table : you can use the same SELECT statements) Be aware that the use of _CORRUPTED_ROLLBACK_SEGMENTS requires the recreation of the database. Handling Rollback Segment Corruptions in Oracle7.3 to 8.1.7 ( Doc ID 106638.1 ) _offline_rollback_segment 和_corrupt_rollback_segment 的作用不一致，有些时候必须用_corrupt_rollback_segment 才能强制打开损坏的数据库。 _OFFLINE_ROLLBACK_SEGMENTS 的作用： 允许数据库的逻辑corruption，用了这个参数之后，在删除回滚段时，Oracle不会检查这个回滚段是否有active的transaction, 你可以删除一个拥有active transaction的rollback segment，这时会导致字典表corruption。 这个参数也可以阻止SMON对某些回滚段中的事务进行恢复，所以当SMON在recovery transaction时如果发生异常导致数据库不断crash，那么这时使用这个参数有用。 _CORRUPTED_ROLLBACK_SEGMENTS 的作用： Oracle不会访问这个参数中列出的任何回滚段的段头，而且认为这些回滚段的所有事物都是commit的。 对于使用了_OFFLINE_ROLLBACK_SEGMENTS的回滚段，它们的 transaction table 仍然可以读取。但是对于_CORRUPTED_ROLLBACK_SEGMENTS 中列出的回滚段，它们的transaction table就不被读取了。 如果不是万不得已，要谨慎使用上面的这些参数，尤其是_CORRUPTED_ROLLBACK_SEGMENTS，因为使用了_CORRUPTED_ROLLBACK_SEGMENTS之后的数据库Oracle就不支持了，必须要重建。 1. Use Trial Recovery to determine the extent of the problem: SQL> recover database test; This will tell you how many blocks (n) would be left corrupted after recovery – check the alert log for details of the blocks affected. If there are a large number of corruptions reported you may decide to restore from backup and issue point in time recovery. However, if only a few blocks are reported as corrupt you could proceed with recovery : 2. Skip the corrupted block(s) SQL> recover database allow 1 corruption; Do this times, being the number of blocks reported as corrupt in step 1 above. This will allow recovery to continue, ‘skipping’ the blocks that cannot be recovered and leaving them marked as ‘corrupt’ after which the database can be opened. SQL> alter database open ; 3. Take the corrupt blocks reported in the alert log and for each, identify the object that the block belongs to:: SQL> SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = and between block_id AND block_id + blocks – 1; Replacing and with the file# and block ids reported in the alert log. For each object identified – take steps to resolve the corruption: – if it belongs to an index then simply drop and recreate the index – if it belong to a user object then consider recreating the object or extracting what you can from the object; if necessary raise a Service Request with Oracle and request assistance with extracting data from a corrupt object. Resolving ORA-600[3020] Raised During Recovery ( Doc ID 361172.1 )
Leave a Reply