标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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)
- 操作系统 (103)
- 数据库 (1,763)
- DB2 (22)
- MySQL (76)
- Oracle (1,605)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (588)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
年归档:2013
使用_allow_resetlogs_corruption导致ORA-00704/ORA-01555故障
以前写过一篇乱用_allow_resetlogs_corruption参数导致悲剧的文章,昨天晚上又遇到一个朋友不谨慎使用_allow_resetlogs_corruption导致ORA-00704/ORA-01555故障
环境描述
系统环境:solaris
数据库版本:10.2.0.5.7
数据存储方式:ASM
数据量:15T以上
补充事宜:数据库SCN距离headroom只有54天
报ORA-00020错误,实例crash
数据库因为超过了系统的进程数,出现dbwn进程写数据文件异常
Sun Aug 25 16:00:41 CST 2013 Errors in file /opt/oracle/admin/orcl/bdump/orcl_dbw0_7490.trc: ORA-01148: 无法刷新数据文件 22 的文件大小 ORA-01110: 数据文件 22: '+DATA/orcl/datafile/index_jh.dbf' ORA-00020: 超出最大进程数 () Sun Aug 25 16:00:41 CST 2013 Errors in file /opt/oracle/admin/orcl/bdump/orcl_dbw0_7490.trc: ORA-01242: 数据文件出现介质故障: 数据库处于 NOARCHIVELOG 模式 ORA-01110: 数据文件 22: '+DATA/orcl/datafile/index_jh.dbf' Sun Aug 25 16:00:41 CST 2013 DBW0: terminating instance due to error 1242 Termination issued to instance processes. Waiting for the processes to exit Sun Aug 25 16:00:51 CST 2013 Instance termination failed to kill one or more processes Instance terminated by DBW0, pid = 7490
ORA-00600[kcbtema_10]
实例恢复出现ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], []
Sun Aug 25 19:19:23 CST 2013 ALTER DATABASE OPEN Sun Aug 25 19:19:38 CST 2013 Beginning crash recovery of 1 threads parallel recovery started with 16 processes Sun Aug 25 19:19:40 CST 2013 Started redo scan Sun Aug 25 19:20:07 CST 2013 Completed redo scan 12016413 redo blocks read, 93405 data blocks need recovery Sun Aug 25 19:20:19 CST 2013 Started redo application at Thread 1: logseq 53681, block 1091966 Sun Aug 25 19:20:19 CST 2013 Recovery of Online Redo Log: Thread 1 Group 1 Seq 53681 Reading mem 0 Mem# 0: +DATA/orcl/onlinelog/redo_1_1.log Mem# 1: +DATA/orcl/onlinelog/redo_1_2.log Sun Aug 25 19:20:21 CST 2013 Errors in file /opt/oracle/admin/orcl/bdump/orcl_p011_16944.trc: ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], [] Sun Aug 25 19:20:23 CST 2013 Errors in file /opt/oracle/admin/orcl/bdump/orcl_p011_16944.trc: ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], [] Sun Aug 25 19:20:23 CST 2013 Aborting crash recovery due to slave death, attempting serial crash recovery Sun Aug 25 19:20:23 CST 2013 Beginning crash recovery of 1 threads Sun Aug 25 19:20:23 CST 2013 Started redo scan Sun Aug 25 19:20:47 CST 2013 Completed redo scan 12016413 redo blocks read, 93405 data blocks need recovery Sun Aug 25 19:20:54 CST 2013 Started redo application at Thread 1: logseq 53681, block 1091966 Sun Aug 25 19:20:54 CST 2013 Recovery of Online Redo Log: Thread 1 Group 1 Seq 53681 Reading mem 0 Mem# 0: +DATA/orcl/onlinelog/redo_1_1.log Mem# 1: +DATA/orcl/onlinelog/redo_1_2.log Sun Aug 25 19:20:54 CST 2013 Errors in file /opt/oracle/admin/orcl/udump/orcl_ora_16751.trc: ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], [] Sun Aug 25 19:20:56 CST 2013 Aborting crash recovery due to error 600 Sun Aug 25 19:20:56 CST 2013 Errors in file /opt/oracle/admin/orcl/udump/orcl_ora_16751.trc: ORA-00600: 内部错误代码, 参数: [kcbtema_10], [1], [], [], [], [], [], [] ORA-600 signalled during: ALTER DATABASE OPEN...
使用隐含参数
ALTER SYSTEM SET _allow_resetlogs_corruption=TRUE SCOPE=SPFILE;
报ORA-00704/ORA-01555
因为在前面的恢复中进行了不完全恢复,因此这里加入隐含参数,然后尝试resetlogs,然后报如下错误
Sun Aug 25 20:11:54 CST 2013 alter database open resetlogs Sun Aug 25 20:12:10 CST 2013 RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 13429649847189 Resetting resetlogs activation ID 1312390734 (0x4e397e4e) Sun Aug 25 20:16:25 CST 2013 Setting recovery target incarnation to 2 Sun Aug 25 20:16:42 CST 2013 ************************************************************ Warning: The SCN headroom for this database is only 54 days! ************************************************************ Sun Aug 25 20:16:43 CST 2013 Assigning activation ID 1352200163 (0x5098efe3) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: +DATA/orcl/onlinelog/redo_1_1.log Current log# 1 seq# 1 mem# 1: +DATA/orcl/onlinelog/redo_1_2.log Successful open of redo thread 1 Sun Aug 25 20:16:43 CST 2013 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Sun Aug 25 20:16:52 CST 2013 SMON: enabling cache recovery Sun Aug 25 20:16:52 CST 2013 ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0c36.d582339b): Sun Aug 25 20:16:52 CST 2013 select ctime, mtime, stime from obj$ where obj# = :1 Sun Aug 25 20:16:52 CST 2013 Errors in file /opt/oracle/admin/orcl/udump/orcl_ora_2859.trc: ORA-00704: 引导程序进程失败 ORA-00704: 引导程序进程失败 ORA-00604: 递归 SQL 级别 1 出现错误 ORA-01555: 快照过旧: 回退段号 143 (名称为 "_SYSSMU143$") 过小 Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Termination issued to instance processes. Waiting for the processes to exit Sun Aug 25 20:17:02 CST 2013 Instance termination failed to kill one or more processes Instance terminated by USER, pid = 2859 ORA-1092 signalled during: alter database open resetlogs...
数据库当前SCN
SQL > select CHECKPOINT_CHANGE# from v$database; CHECKPOINT_CHANGE# ------------------ 13429649947222 SQL > select distinct CHECKPOINT_CHANGE# from v$datafile_header; CHECKPOINT_CHANGE# ------------------ 13429649947222
解决方法
因为该数据库版本为10.2.0.5.7,已经包含了scn patch,因此不能使用event或者隐含参数来修改scn,而且该库容量15T以上(asm),因此也无法使用bbed修改数据文件头,最后决定使用ordebug来解决该问题
使用oradebug DUMPvar SGA kcsgscn_
使用oradebug poke
sqlplus / as sysdba startup mount oradebug setmypid oradebug DUMPvar SGA kcsgscn_ oradebug poke recover database; alter database open;
事后总结
查询MOS,发现ORA-00600[kcbtema_10] Raised During Recovery Operations (Doc ID 472282.1)
--故障原因 The cause of this problem has been identified and verified in unpublished Bug 5184359 ORA-600 [KCBTEMA_10]. Due to this bug, during recovery, the class designation of a data block has changed. --处理方法 SQL>startup mount SQL>recover database; SQL>alter database open;
因为MOS上给的解决思路在该数据库中已经无法尝试,不能确定该方法一定可行,但是对于本次的恢复过程中,没有任何直接recover database操作(只有一次不完全恢复)确实让人有无限的遗憾和可惜。对于本次应该先查询MOS,尝试该种方法,慎重使用_allow_resetlogs_corruption参数
ORACLE 12C Windows-Linux 部署DATAGURAD
环境描述
win 64中的ORACLE 12C(primary)与Linux 64中的ORACLE 12C(standby)搭建datagurad
primary force logging
C:\Users\XIFENFEI>sqlplus / as sysdba SQL*Plus: Release 12.1.0.1.0 Production on 星期六 8月 24 16:59:53 2013 Copyright (c) 1982, 2013, Oracle. All rights reserved. 连接到: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options CDB_CDB$ROOT@SYS> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production PL/SQL Release 12.1.0.1.0 - Production CORE 12.1.0.1.0 Production TNS for 64-bit Windows: Version 12.1.0.1.0 - Production NLSRTL Version 12.1.0.1.0 - Production CDB_CDB$ROOT@SYS> alter database force logging ; 数据库已更改。
primary rman backup
backup filesperset = 5 as compressed backupset database format 'd:/backup/rman/full_%U.rman';
primary 生成standby controlfile
CDB_CDB$ROOT@SYS> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'c:/control01.ctl'; 数据库已更改。 CDB_CDB$ROOT@SYS> create pfile='e:/pfile.txt' from spfile; 文件已创建。
standby 参数文件
DB_CREATE_FILE_DEST='+DATA' db_create_online_log_dest_1='+DATA' db_unique_name='cdb_dg' service_names='cdb' log_archive_dest_1='LOCATION=/u02/app/oracle/archivelog/ valid_for=(all_logfiles,all_roles)' log_archive_dest_2='service=primary lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=cdb' log_archive_config='dg_config=(cdb,cdb_dg)' standby_file_management=auto db_file_name_convert='E:\APP\XIFENFEI\ORADATA\','+DATA\CDB_DG\DATAFILE\' log_file_name_convert='E:\APP\XIFENFEI\ORADATA\','+DATA\CDB_DG\LOGFILE\' fal_server=primary
primary 修改参数
CDB_CDB$ROOT@SYS> alter system set log_archive_config='dg_config=(cdb,cdb_dg)'; 系统已更改。 CDB_CDB$ROOT@SYS> alter system set log_archive_dest_2=' 2 service=standby lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=cdb_dg'; 系统已更改。 CDB_CDB$ROOT@SYS> alter system set log_archive_dest_1= 2 'LOCATION=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles)'; 系统已更改。 CDB_CDB$ROOT@SYS> alter system set fal_server=standby; 系统已更改。 CDB_CDB$ROOT@SYS> alter system set standby_file_management=auto; 系统已更改。 CDB_CDB$ROOT@SYS> alter system set db_file_name_convert='+DATA\CDB_DG\DATAFILE\','E:\APP\XIFENFEI\ORADATA\' scope=spfile; 系统已更改。 CDB_CDB$ROOT@SYS> alter system set log_file_name_convert='+DATA\CDB_DG\LOGFILE\','E:\APP\XIFENFEI\ORADATA\' scope=spfile; 系统已更改。
primary and standby tns
STANDBY = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.30.32 )(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = cdb) ) ) PRIMARY = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.30.1 )(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = cdb) ) )
standby restore controlfile
ASMCMD> cp /tmp/CONTROL01.CTL control01.ctl copying /tmp/CONTROL01.CTL -> +data/cdb/control01.ctl
standby password file
[oracle@xifenfei dbs]$ pwd /u01/app/oracle/product/12.1/db_1/dbs [oracle@xifenfei dbs]$ cp /tmp/rman/PWDcdb.ora orapwcdb
standby mount
SYS% cdb> create spfile from pfile='initcdb.ora'; File created. SYS% cdb> startup mount; ORACLE instance started. Total System Global Area 521936896 bytes Fixed Size 2290264 bytes Variable Size 314576296 bytes Database Buffers 197132288 bytes Redo Buffers 7938048 bytes Database mounted. SYS% cdb> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production PL/SQL Release 12.1.0.1.0 - Production CORE 12.1.0.1.0 Production TNS for Linux: Version 12.1.0.1.0 - Production NLSRTL Version 12.1.0.1.0 - Production SYS% cdb> select name from v$datafile; NAME -------------------------------------------------------------------------------- E:\APP\XIFENFEI\ORADATA\CDB\SYSTEM01.DBF E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSTEM01.DBF E:\APP\XIFENFEI\ORADATA\CDB\SYSAUX01.DBF E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSAUX01.DBF E:\APP\XIFENFEI\ORADATA\CDB\UNDOTBS01.DBF E:\APP\XIFENFEI\ORADATA\CDB\USERS01.DBF E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSAUX01.DBF E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF 9 rows selected.
standby rman restore
--清理控制文件中的备份集垃圾 DELETE noprompt OBSOLETE; crosscheck backup; delete noprompt expired backup; --注册新备份集 catalog start with '/tmp/rman/'; --还原数据文件 run { set newname for database to '+data'; restore database; switch datafile all; }
standby clear redo
SYS% cdb> select group# from v$log; GROUP# ---------- 4 6 5 SYS% cdb> alter database clear logfile group 4; Database altered. SYS% cdb> alter database clear logfile group 5; Database altered. SYS% cdb> alter database clear logfile group 6; Database altered.
standby add standby redolog
SYS% cdb> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 size 50M; Database altered. SYS% cdb> ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 size 50M; Database altered. SYS% cdb> ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 size 50M; Database altered. SYS% cdb> ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 size 50M; Database altered.
primary add standby redolog
CDB_CDB$ROOT@SYS> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10 'E:\APP\XIFENFEI\ORADATA\CDB\std_redo10.log' size 50M; 数据库已更改。 CDB_CDB$ROOT@SYS> ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 'E:\APP\XIFENFEI\ORADATA\CDB\std_redo11.log' size 50M; 数据库已更改。 CDB_CDB$ROOT@SYS> ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 'E:\APP\XIFENFEI\ORADATA\CDB\std_redo12.log' size 50M; 数据库已更改。 CDB_CDB$ROOT@SYS> ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 'E:\APP\XIFENFEI\ORADATA\CDB\std_redo13.log' size 50M; 数据库已更改。
standby readonly
SYS% cdb> ALTER DATABASE OPEN READ ONLY; Database altered.
standby start mrp
SYS% cdb> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered.
DATAGURAD 是否正常检查
--primary CDB_CDB$ROOT@SYS> archive log list; 数据库日志模式 存档模式 自动存档 启用 存档终点 USE_DB_RECOVERY_FILE_DEST 最早的联机日志序列 374 下一个存档日志序列 376 当前日志序列 376 --standby Mon Aug 12 13:56:51 2013 All non-current ORLs have been archived. Mon Aug 12 13:56:53 2013 Media Recovery Log /u02/app/oracle/archivelog/1_370_820595806.dbf Mon Aug 12 13:56:57 2013 Media Recovery Log /u02/app/oracle/archivelog/1_371_820595806.dbf Mon Aug 12 13:57:02 2013 Media Recovery Log /u02/app/oracle/archivelog/1_372_820595806.dbf Mon Aug 12 13:57:04 2013 Media Recovery Log /u02/app/oracle/archivelog/1_373_820595806.dbf Mon Aug 12 13:57:05 2013 Media Recovery Log /u02/app/oracle/archivelog/1_374_820595806.dbf Media Recovery Waiting for thread 1 sequence 375 Mon Aug 12 13:57:19 2013 Primary database is in MAXIMUM PERFORMANCE mode RFS[2]: Assigned to RFS process (PID:26114) RFS[2]: No standby redo logfiles created for thread 1 RFS[2]: Opened log for thread 1 sequence 376 dbid 1937199326 branch 820595806 Mon Aug 12 13:57:19 2013 RFS[3]: Assigned to RFS process (PID:26118) RFS[3]: Opened log for thread 1 sequence 375 dbid 1937199326 branch 820595806 Mon Aug 12 13:57:19 2013 Archived Log entry 16 added for thread 1 sequence 375 rlc 820595806 ID 0x7377d8de dest 2: Mon Aug 12 13:57:22 2013 Media Recovery Log /u02/app/oracle/archivelog/1_375_820595806.dbf Media Recovery Waiting for thread 1 sequence 376 (in transit)