联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
数据库alert日志报ORA-00600[2252]
Wed Jun 06 08:56:02 2012 Thread 1 cannot allocate new log, sequence 552 Checkpoint not complete Current log# 1 seq# 551 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG Thread 1 advanced to log sequence 552 Current log# 2 seq# 552 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG Sun Jun 06 09:39:19 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_3344.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076554712], [], [], [], [], [] Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_3344.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076554712], [], [], [], [], [] Sun Jun 06 10:19:49 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_4904.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076555573], [], [], [], [], [] Sun Jun 06 10:20:49 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_5984.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076555594], [], [], [], [], [] Sun Jun 06 10:21:49 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_4204.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076555614], [], [], [], [], [] Sun Jun 06 10:22:49 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_5896.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076555634], [], [], [], [], [] Sun Jun 06 10:23:49 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_4612.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076555654], [], [], [], [], [] Sun Jun 06 10:24:49 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_4696.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076555676], [], [], [], [], [] Sun Jun 06 10:25:50 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_5568.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076555696], [], [], [], [], [] Sun Jun 06 10:26:50 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_m000_5776.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076555716], [], [], [], [], [] --启动数据库 Mon Jun 07 09:18:39 2010 Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 Mon Jun 07 09:18:49 2010 Picked latch-free SCN scheme 2 Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST Autotune of undo retention is turned on. IMODE=BR ILAT =18 LICENSE_MAX_USERS = 0 SYS auditing is disabled ksdpec: called for event 13740 prior to event group initialization Starting up ORACLE RDBMS Version: 10.2.0.1.0. System parameters with non-default values: processes = 150 __shared_pool_size = 100663296 __large_pool_size = 12582912 __java_pool_size = 4194304 __streams_pool_size = 0 spfile = D:\ORACLE\PRODUCT\10.2.0\DB_1\DBS\SPFILEORCL.ORA nls_language = SIMPLIFIED CHINESE nls_territory = CHINA sga_target = 452984832 control_files = D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL db_block_size = 8192 __db_cache_size = 327155712 compatible = 10.2.0.1.0 db_file_multiblock_read_count= 16 db_recovery_file_dest = D:\oracle\product\10.2.0/flash_recovery_area db_recovery_file_dest_size= 2147483648 undo_management = AUTO undo_tablespace = UNDOTBS1 remote_login_passwordfile= EXCLUSIVE db_domain = dispatchers = (protocol=TCP) shared_servers = 1 job_queue_processes = 10 audit_file_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\ADUMP background_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\BDUMP user_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP core_dump_dest = D:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\CDUMP db_name = orcl open_cursors = 300 pga_aggregate_target = 149946368 PSP0 started with pid=3, OS id=3028 MMAN started with pid=4, OS id=3528 PMON started with pid=2, OS id=2772 DBW0 started with pid=5, OS id=816 CKPT started with pid=7, OS id=3372 SMON started with pid=8, OS id=2584 RECO started with pid=9, OS id=3976 CJQ0 started with pid=10, OS id=1912 MMON started with pid=11, OS id=624 Mon Jun 07 09:19:00 2010 starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'... MMNL started with pid=12, OS id=2696 Mon Jun 07 09:19:00 2010 starting up 1 shared server(s) ... LGWR started with pid=6, OS id=3128 Mon Jun 07 09:19:04 2010 alter database mount exclusive Mon Jun 07 09:19:09 2010 Setting recovery target incarnation to 2 Mon Jun 07 09:19:10 2010 Successful mount of redo thread 1, with mount id 1248834568 Mon Jun 07 09:19:10 2010 Database mounted in Exclusive Mode Completed: alter database mount exclusive Mon Jun 07 09:19:10 2010 alter database open Mon Jun 07 09:19:15 2010 Beginning crash recovery of 1 threads parallel recovery started with 2 processes Mon Jun 07 09:19:18 2010 Started redo scan Mon Jun 07 09:19:19 2010 Completed redo scan 13 redo blocks read, 7 data blocks need recovery Mon Jun 07 09:19:20 2010 Started redo application at Thread 1: logseq 552, block 28631 Mon Jun 07 09:19:20 2010 Recovery of Online Redo Log: Thread 1 Group 2 Seq 552 Reading mem 0 Mem# 0 errs 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG Mon Jun 07 09:19:20 2010 Completed redo application Mon Jun 07 09:19:20 2010 Completed crash recovery at Thread 1: logseq 552, block 28644, scn 12176013920948 7 data blocks read, 7 data blocks written, 13 redo blocks read Mon Jun 07 09:19:28 2010 Errors in file d:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_2688.trc: ORA-00600: 内部错误代码, 参数: [2252], [2834], [4076604085], [], [], [], [], []
通过这些日志可以看出数据库一直在报ORA-00600[2252],在后来因某种原因数据库异常重启后启动不了.仔细观察可以发现系统显示的时间是2010年6月7日和当前时间相差了整整两年.
At any point in time, the Oracle Database calculates a “not to exceed” limit for the number of SCNs a database can have used, based on the number of seconds elapsed since 1988, multiplied by 16,384. This is known as the database’s current maximum SCN limit. Doing this ensures that Oracle Databases will ration SCNs over time, allowing over 500 years of data processing for any Oracle Database.
错误原因
根据错误提示计算scn(2834为现在系统的SCN WRAP，4076604085就是BASE)=2834*2^32+4076604085=12176013920949
根据数据库日志显示系统时间计算最大scn值:
SQL>select to_number( ((to_date('20100607 09:19:28','yyyymmdd hh24:mi:ss')-
2 to_date('19880101','yyyymmdd'))*24*3600*16*1024),'999999999999999999') max_scn from dual;
MAX_SCN
--------------
11598377254912
通过这里的计算可以知道数据库当前的SCN大于系统时间点上允许的最大时间的SCN,从而出现ORA-00600[2252]错误.
解决方法
知道了数据库报该错误的原因,那么解决该问题很简单,修改系统时间到正确的时间点即可
SQL> select to_number(((sysdate-to_date('19880101','yyyymmdd'))*24*3600*16*1024),
2 '999999999999999999') max_scn from dual;
MAX_SCN
--------------
12634899464192
该SCN大于数据库当前SCN所有数据库不会报ORA-00600[2252]错误可以正常启动.