标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,670)
- DB2 (22)
- MySQL (73)
- Oracle (1,532)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (65)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (560)
- Oracle安装升级 (91)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (78)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
- Oracle 19c RAC 替换私网操作
- 监听报TNS-12541 TNS-12560 TNS-00511错误
- drop tablespace xxx including contents恢复
- Linux 8 修改网卡名称
标签归档:kccpb_sanity_check_2
ORA-600 2131故障说明
oracle 12c数据库启动报ORA-600 2131错误
Mon Nov 26 09:43:57 2018 starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'... starting up 1 shared server(s) ... ORACLE_BASE from environment = D:\app\Administrator alter database mount exclusive Mon Nov 26 09:44:00 2018 Using default pga_aggregate_limit of 2048 MB Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_ora_3040.trc (incident=375524): ORA-00600: ??????, ??: [2131], [9], [8], [], [], [], [], [], [], [], [], [] Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\incident\incdir_375524\orcl12c_ora_3040_i375524.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. ORA-600 signalled during: alter database mount exclusive...
这个日志比较明显,数据库无法mount,在mount操作的时候报ORA-600 2131错误.
trace文件报错
Error: kccpb_sanity_check_2 Control file sequence number mismatch! fhcsq: 497844 bhcsq: 497849 cfn 0 rpbn 16 ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedst1()+92 CALL??? skdstdst() 000000001 000004000 000030000 016301338 kccpb_sanity_check( CALL??? ksedst1() 1492761E0 0000798B4 0000798B9 )+834 000000000 kccbmp_get()+275 CALL??? kccpb_sanity_check( 000000000 000000000 000000000 ) 000004000 kccsed_rbl()+174 CALL??? kccbmp_get() 000017E28 015A67E14 015592200 000000001 kccocx()+1399 CALL??? kccsed_rbl() 100000010 100000001 0000354D8 000035508 kccocf()+167 CALL??? kccocx()+528 016303990 000000000 7FF00000001 000000000 kcfcmb()+1254 CALL??? kccocf() 000000000 000000000 000000000 000000000 kcfmdb()+69 CALL??? kcfcmb() 000000000 7FF59FFF856 000000007 7FE00000000 adbdrv_options()+43 CALL??? kcfmdb() 0163083E0 14903FF2C 000000005 724 000000000 adbdrv()+149 CALL??? adbdrv_options() 000000000 000000000 0163084A0 851F2CC90B75 opiexe()+22668 CALL??? adbdrv() 7FF00000023 000000003 000000000 016309380 opiosq0()+6009 CALL??? opiexe() 000000000 000000000 016309990 000000000 kpooprx()+410 CALL??? opiosq0() 000000003 000000000 000000000 0000000A4 kpoal8()+994 CALL??? kpooprx() 0146A57FC 000000001 0146A5820 000000001 opiodr()+1601 CALL??? kpoal8() 000000000 015523288 015523270 0159FCDD0 ttcpip()+1223 CALL??? opiodr() 7FE0000005E 00000001F 01630DA20 7FE00000000 opitsk()+2160 CALL??? ttcpip() 0146C0690 000000000 000000000 000000000 opiino()+1079 CALL??? opitsk() 000000007 000000000 01630F200 01630E970 opiodr()+1601 CALL??? opiino() 00000003C 000000000 01630F470 000000000 opidrv()+842 CALL??? opiodr() 00000003C 000000004 01630F470 000000000 sou2o()+94 CALL??? opidrv()+156 10000003C 7FE00000004 01630F470 0154E6A30 opimai_real()+276 CALL??? sou2o() 1D4851F4C467583 00A9D55E0 8001A000B07E2 1004B0039001E opimai()+170 CALL??? opimai_real() 000000000 851F2CB1B179 00A9D55E0 01630F628 OracleThreadStart() CALL??? opimai() 000000000 149031F90 000000050 +713 0000005C8 00000000775259CD CALL??? OracleThreadStart() 000000000 000000000 000000000 000000000 000000007765A561 CALL??? 00000000775259C0 000000000 000000000 000000000 000000000 --------------------- Binary Stack Dump ---------------------
这个错误和以往版本中的kccpb_sanity_check_2比较类似,由于数据库异常关闭导致ctl写丢失导致
ORA-600 2131/kccpb_sanity_check_2解释
DESCRIPTION: This internal error is raised when the sequence number (seq#) of the current block of the controlfile is greater than the seq# in the controlfile header. The header value should always be equal to, or greater than the value held in the control file block(s). This extra check was introduced in Oracle 10gR2 to detect lost writes or stale reads to the header. ARGUMENTS: Arg [a] seq# in control block header. Arg [b] seq# in the control file header. Arg 1 FUNCTIONALITY: Kernel Cache layer Control file component.
数据库恢复的敏感性—重建控制文件使用不合适数据文件
有客户数据库由于某种原因无法open,请求我们技术支持.通过检查alert日志发现数据库是由于ORA-600 kccpb_sanity_check_2错误.并且他们已经重建控制文件,通过我们的Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)
datafile 6 异常
通过这里我们发现datafile 6 数据文件头是干净的,而且对应的redo seq为5270,而其他文件头都是fuzzy,而且对应的redo为295902613.这里怀疑datafile 6 可能是错误的.当然对于这样scn相距比较大的情况,我们可以通过隐含参数,修改scn等方法强制让该库起来(或者该文件online),但是从现在看到的情况,文件很可能异常,这样强制恢复,可能没有实际意义.
分析alert日志
这个里面可以发现是先删除了sde表空间,然后创建了同一个表空间,只是数据文件路径不一样了.而且正好在seq为5270的地方操作的.现在出现datafile 6异常的原因已经清楚,就是创建数据控制文件的时候,使用了错误的数据文件导致.
完美恢复数据库
D:\>sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 7月 30 16:31:01 2016 Copyright (c) 1982, 2005, Oracle. All rights reserved. 连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options SQL> shutdown immediate; ORA-01109: 数据库未打开 已经卸载数据库。 ORACLE 例程已经关闭。 SQL> STARTUP NOMOUNT ORACLE 例程已经启动。 Total System Global Area 5133828096 bytes Fixed Size 2011360 bytes Variable Size 2382368544 bytes Database Buffers 2734686208 bytes Redo Buffers 14761984 bytes SQL> CREATE CONTROLFILE REUSE DATABASE "LANDDB" NORESETLOGS ARCHIVELOG 2 MAXLOGFILES 16 3 MAXLOGMEMBERS 3 4 MAXDATAFILES 100 5 MAXINSTANCES 8 6 MAXLOGHISTORY 292 7 LOGFILE 8 GROUP 1 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_1_4JCM05KL_.LOG' SIZE 50M, 9 GROUP 2 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_2_4JCM064D_.LOG' SIZE 50M, 10 GROUP 3 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_3_4JCM06PG_.LOG' SIZE 50M 11 DATAFILE 12 'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSTEM_4JCLYY6T_.DBF', 13 'F:\ORADATA\LANDDB\DATAFILE\O1_MF_UNDOTBS1_4JCLYY8S_.DBF', 14 'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSAUX_4JCLYY7B_.DBF', 15 'F:\ORADATA\LANDDB\DATAFILE\O1_MF_USERS_4JCLYY98_.DBF', 16 'F:\ORADATA\LANDDB\DATAFILE\FUJIAN', 17 'D:\data\sde.dbf' 18 CHARACTER SET ZHS16GBK 19 ; 控制文件已创建。 SQL> recover database; 完成介质恢复。 SQL> alter database open; 数据库已更改。 SQL>
这个库比较幸运,客户发现异常之后,里面停止了有风险性的操作(比如使用_allow_resetlogs_corruption参数,resetlogs库等),使得数据完美恢复0丢失.如果条件允许最好使用老的控制文件来重建新控制文件,而不要通过人工去系统中找数据文件来实现恢复,这样很可能有遗落或者使用错误的数据文件
ORA-600 kccpb_sanity_check_2故障恢复
今天是有人在淘宝旺旺上找我,需要oracle数据库恢复支持
远程登录上去一看发现数据库mount的时候报ORA-600[kccpb_sanity_check_2]错误
C:\Documents and Settings\Administrator>sqlplus / as sysdba SQL*Plus: Release 10.2.0.3.0 - Production on Wed Jul 29 16:23:18 2015 Copyright (c) 1982, 2006, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production With the Partitioning, OLAP and Data Mining options SQL> alter database mount; alter database mount * ERROR at line 1: ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [14169], [14160], [0x0], [], [], [], []
尝试重建控制文件
SQL> shutdown immediate; ORA-01507: database not mounted ORACLE instance shut down. SQL> startup pfile='D:\database\m104\pfile\init.ora' nomount ORACLE instance started. Total System Global Area 444596224 bytes Fixed Size 1291072 bytes Variable Size 155192512 bytes Database Buffers 281018368 bytes Redo Buffers 7094272 bytes SQL> SHOW PARAMETER CONT; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_file_record_keep_time integer 7 control_files string D:\DATABASE\M104\CTRL\CONTROL0 2.CTL global_context_pool_size string SQL> ALTER DATABASE MOUNT; ALTER DATABASE MOUNT * ERROR at line 1: ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [14169], [14160], [0x0], [], [], [], [] SQL> SQL> CREATE CONTROLFILE REUSE DATABASE "m104_db" NORESETLOGS FORCE LOGGING NOAR CHIVELOG 2 MAXLOGFILES 16 3 MAXLOGMEMBERS 3 4 MAXDATAFILES 100 5 MAXINSTANCES 8 6 MAXLOGHISTORY 2921 7 LOGFILE 8 GROUP 1 'D:\database\m104\log\redo01.log' SIZE 51200K, 9 GROUP 2 'D:\database\m104\log\redo02.log' SIZE 51200K, 10 GROUP 3 'D:\database\m104\log\redo03.log' SIZE 51200K 11 DATAFILE 12 'd:\database\m104\data\system01.dbf', 13 'd:\database\m104\data\sysaux01.dbf', 14 'd:\database\m104\data\USERS01.DBF', 15 'd:\database\m104\data\UNDOTBS01.DBF', 16 'd:\database\m104\data\INDX01.DBF' 17 CHARACTER SET WE8ISO8859P1 18 ; CREATE CONTROLFILE REUSE DATABASE "m104_db" NORESETLOGS FORCE LOGGING NOARCHIVE LOG * ERROR at line 1: ORA-01503: CREATE CONTROLFILE failed ORA-00600: internal error code, arguments: [kccsga_update_ckpt_4], [1], [8], [], [], [], [], [] SQL> SQL> CREATE CONTROLFILE REUSE DATABASE "m104_db" RESETLOGS FORCE LOGGING NOARCH IVELOG 2 MAXLOGFILES 16 3 MAXLOGMEMBERS 3 4 MAXDATAFILES 100 5 MAXINSTANCES 8 6 MAXLOGHISTORY 2921 7 LOGFILE 8 GROUP 1 'D:\database\m104\log\redo01.log' SIZE 51200K, 9 GROUP 2 'D:\database\m104\log\redo02.log' SIZE 51200K, 10 GROUP 3 'D:\database\m104\log\redo03.log' SIZE 51200K 11 DATAFILE 12 'd:\database\m104\data\system01.dbf', 13 'd:\database\m104\data\sysaux01.dbf', 14 'd:\database\m104\data\USERS01.DBF', 15 'd:\database\m104\data\UNDOTBS01.DBF', 16 'd:\database\m104\data\INDX01.DBF' 17 CHARACTER SET WE8ISO8859P1 18 ; CREATE CONTROLFILE REUSE DATABASE "m104_db" RESETLOGS FORCE LOGGING NOARCHIVELO G * ERROR at line 1: ORA-01503: CREATE CONTROLFILE failed ORA-00600: internal error code, arguments: [kccsga_update_ckpt_4], [1], [8], [], [], [], [], []
无论是使用noresetlogs还是resetlogs,重建控制文件都报ORA-600[kccsga_update_ckpt_4]错误.比较奇怪,无解指定控制文件新名称重建试试看
修改控制文件路径
SQL> SHUTDOWN ABORT ORACLE instance shut down. SQL> startup pfile='D:\database\m104\pfile\init.ora' nomount ORACLE instance started. Total System Global Area 444596224 bytes Fixed Size 1291072 bytes Variable Size 155192512 bytes Database Buffers 281018368 bytes Redo Buffers 7094272 bytes SQL> SHOW PARAMETER CONT; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ control_file_record_keep_time integer 7 control_files string D:\DATABASE\M104\CTRL\CONTROL0 4.CTL global_context_pool_size string SQL> CREATE CONTROLFILE REUSE DATABASE "m104_db" RESETLOGS FORCE LOGGING NOARCH IVELOG 2 MAXLOGFILES 16 3 MAXLOGMEMBERS 3 4 MAXDATAFILES 100 5 MAXINSTANCES 8 6 MAXLOGHISTORY 2921 7 LOGFILE 8 GROUP 1 'D:\database\m104\log\redo01.log' SIZE 51200K, 9 GROUP 2 'D:\database\m104\log\redo02.log' SIZE 51200K, 10 GROUP 3 'D:\database\m104\log\redo03.log' SIZE 51200K 11 DATAFILE 12 'd:\database\m104\data\system01.dbf', 13 'd:\database\m104\data\sysaux01.dbf', 14 'd:\database\m104\data\USERS01.DBF', 15 'd:\database\m104\data\UNDOTBS01.DBF', 16 'd:\database\m104\data\INDX01.DBF' 17 CHARACTER SET WE8ISO8859P1 18 ; Control file created.
使用新的控制文件位置,这次终于数据库重建控制文件成功
尝试指定redo进行恢复,数据库正常打开
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; ORA-00279: change 3643108240801 generated at 07/26/2015 20:15:22 needed for thread 1 ORA-00289: suggestion : D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC00567_0866390669.001 ORA-00280: change 3643108240801 for thread 1 is in sequence #567 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} D:\database\m104\log\redo01.log ORA-00310: archived log contains sequence 566; sequence 567 required ORA-00334: archived log: 'D:\DATABASE\M104\LOG\REDO01.LOG' ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: 'D:\DATABASE\M104\DATA\SYSTEM01.DBF' SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; ORA-00279: change 3643108240801 generated at 07/26/2015 20:15:22 needed for thread 1 ORA-00289: suggestion : D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC00567_0866390669.001 ORA-00280: change 3643108240801 for thread 1 is in sequence #567 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} D:\database\m104\log\redo02.log Log applied. Media recovery complete. SQL> ALTER DATABASE OPEN RESETLOGS; Database altered.
数据库恢复完成。整个数据库恢复比较简单,但是注意这里的ORA-600[kccsga_update_ckpt_4]通过修改控制文件路径规避,具体原因待查。
知识点补充:ORA-600 [kccpb_sanity_check_2] [a] [b] {c}
VERSIONS: Versions 10.2 to 11.2 DESCRIPTION: This internal error is raised when the sequence number (seq#) of the current block of the controlfile is greater than the seq# in the controlfile header. The header value should always be equal to, or greater than the value held in the control file block(s). This extra check was introduced in Oracle 10gR2 to detect lost writes or stale reads to the header. ARGUMENTS: Arg [a] seq# in control block header. Arg [b] seq# in the control file header. Arg {c}