标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,881)
- DB2 (22)
- MySQL (82)
- Oracle (1,706)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (660)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
分类目录归档:Oracle备份恢复
_allow_resetlogs_corruption和adjust_scn解决ORA-01190
一、模拟offline文件然后resetlogs操作
1.设置datafile 5数据文件offline
2.rman备份数据库
3.关闭原数据库,删除数据文件/当前日志和部分归档日志
4.执行不完全恢复,resetlogs打开数据库(如下面操作)
[oracle@xifenfei ora11g]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Mar 15 07:36:59 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> recover database until cancel;
ORA-00279: change 868870 generated at 03/15/2012 03:32:11 needed for thread 1
ORA-00289: suggestion :
/u01/oracle/oradata/archivelog/ora11g/1_29_777766629.dbf
ORA-00280: change 868870 for thread 1 is in sequence #29
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL> alter database open resetlogs;
Database altered.
SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;
FILE# ONLINE_STATUS TO_CHAR(CHANGE#,'999999999
---------- -------------- --------------------------
5 OFFLINE 868810
SQL> alter database datafile 5 online;
alter database datafile 5 online
*
ERROR at line 1:
ORA-01190: control file or data file 5 is from before the last RESETLOGS
ORA-01110: data file 5: '/u01/oracle/oradata/ora11g/xifenfei01.dbf'
SQL> select file#,to_char(checkpoint_change#,'999999999999'),
2 to_char(last_change#,'999999999999') from v$datafile;
FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(LAST_CHANGE#,'9999
---------- -------------------------- --------------------------
1 868874
2 868874
3 868874
4 868874
5 868810 868874
--可以看到offline的数据文件,没有因为resetlogs操作而改变
--CHECKPOINT_CHANGE#和RESETLOGS_CHANGE#信息
SQL> select file#,to_char(checkpoint_change#,'999999999999'),
2 to_char(RESETLOGS_CHANGE#,'999999999999')
3 from v$datafile_header;
FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(RESETLOGS_CHANGE#,
---------- -------------------------- --------------------------
1 868874 868871
2 868874 868871
3 868874 868871
4 868874 868871
5 868810 787897
二、隐含参数设置
SQL> create pfile='/tmp/pfile' from spfile; File created. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. 在pfile中增加 _allow_resetlogs_corruption=true _allow_error_simulation=TRUE(10g及其以上版本需要)
三、打开数据库,online离线文件
SQL> startup pfile='/tmp/pfile' mount;
ORACLE instance started.
Total System Global Area 368263168 bytes
Fixed Size 1345016 bytes
Variable Size 293603848 bytes
Database Buffers 67108864 bytes
Redo Buffers 6205440 bytes
Database mounted.
--在mount状态下执行
SQL> alter session set events '10015 trace name adjust_scn level 2';
Session altered.
--[一定要]在mount状态下执行online操作
SQL> alter database datafile 5 online;
Database altered.
SQL> recover database until cancel;
ORA-00279: change 868810 generated at 03/13/2012 22:19:37 needed for thread 1
ORA-00289: suggestion :
/u01/oracle/oradata/archivelog/ora11g/1_27_777766629.dbf
ORA-00280: change 868810 for thread 1 is in sequence #27
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01190: control file or data file 1 is from before the last RESETLOGS
ORA-01110: data file 1: '/u01/oracle/oradata/ora11g/system01.dbf'
ORA-01112: media recovery not started
SQL> alter database open resetlogs;
Database altered.
SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;
no rows selected
姊妹篇:bbed解决ORA-01190
bbed解决ORA-01190
当我们使用resetlogs方式打开数据库后,发现有数据文件处于offline状态,这个时候很可能就是悲剧降临的时候,很有可能这个文件文件在resetlogs之前就处于offline状态,然后你resetlogs之后,这个文件使用常规方法很难再online,会出现ORA-01190或者ORA-01189之类的错误。
一、模拟offline文件然后resetlogs操作
1.设置datafile 5数据文件offline
2.rman备份数据库
3.关闭原数据库,删除数据文件/当前日志和部分归档日志
4.执行不完全恢复,resetlogs打开数据库(如下面操作)
[oracle@xifenfei ora11g]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Mar 15 07:36:59 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> recover database until cancel;
ORA-00279: change 868870 generated at 03/15/2012 03:32:11 needed for thread 1
ORA-00289: suggestion :
/u01/oracle/oradata/archivelog/ora11g/1_29_777766629.dbf
ORA-00280: change 868870 for thread 1 is in sequence #29
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.
SQL> alter database open resetlogs;
Database altered.
SQL> select file#,online_status,to_char(change#,'999999999999') from v$recover_file;
FILE# ONLINE_STATUS TO_CHAR(CHANGE#,'999999999
---------- -------------- --------------------------
5 OFFLINE 868810
SQL> alter database datafile 5 online;
alter database datafile 5 online
*
ERROR at line 1:
ORA-01190: control file or data file 5 is from before the last RESETLOGS
ORA-01110: data file 5: '/u01/oracle/oradata/ora11g/xifenfei01.dbf'
SQL> select file#,to_char(checkpoint_change#,'999999999999'),
2 to_char(last_change#,'999999999999') from v$datafile;
FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(LAST_CHANGE#,'9999
---------- -------------------------- --------------------------
1 868874
2 868874
3 868874
4 868874
5 868810 868874
--可以看到offline的数据文件,没有因为resetlogs操作而改变
--CHECKPOINT_CHANGE#和RESETLOGS_CHANGE#信息
SQL> select file#,to_char(checkpoint_change#,'999999999999'),
2 to_char(RESETLOGS_CHANGE#,'999999999999')
3 from v$datafile_header;
FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(RESETLOGS_CHANGE#,
---------- -------------------------- --------------------------
1 868874 868871
2 868874 868871
3 868874 868871
4 868874 868871
5 868810 787897
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
二、bbed修改相关项
下面两项与resetlogs相关
kcvfhrlc表示 reset logs count
kcvfhrls表示 resetlogs scn
下面四项与数据库文件scn相关
kscnbas (at offset 140) – SCN of last change to the datafile.
kcvcptim (at offset 148) - Time of the last change to the datafile.
kcvfhcpc (at offset 176) – Checkpoint count.
kcvfhccc (at offset 184) – Unknown, but is always 1 less than thecheckpoint point count.
BBED> set filename '/u01/oracle/oradata/ora11g/system01.dbf'
FILENAME /u01/oracle/oradata/ora11g/system01.dbf
BBED> p kcvfhrlc
ub4 kcvfhrlc @112 0x2e5eed37
BBED> p kcvfhrls
struct kcvfhrls, 8 bytes @116
ub4 kscnbas @116 0x000d4207
ub2 kscnwrp @120 0x0000
BBED> p kcvcpscn
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x000d4495
ub2 kscnwrp @488 0x0000
BBED> p kcvfhcpc
ub4 kcvfhcpc @140 0x00000078
BBED> p kcvfhccc
ub4 kcvfhccc @148 0x00000077
BBED> set filename '/u01/oracle/oradata/ora11g/xifenfei01.dbf'
FILENAME /u01/oracle/oradata/ora11g/xifenfei01.dbf
BBED> p kcvfhrlc
ub4 kcvfhrlc @112 0x2e5bc6e5
BBED> set mode edit
MODE Edit
BBED> m /x 37ed5e2e
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
BBED> p kcvfhrlc
ub4 kcvfhrlc @112 0x2e5eed37
BBED> p kcvfhrls
struct kcvfhrls, 8 bytes @116
ub4 kscnbas @116 0x000c05b9
ub2 kscnwrp @120 0x0000
BBED> m /x 07420d00
BBED> p kcvfhrls
struct kcvfhrls, 8 bytes @116
ub4 kscnbas @116 0x000d4207
ub2 kscnwrp @120 0x0000
BBED> p kcvcpscn
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x000d41ca
ub2 kscnwrp @488 0x0000
BBED> set offset 484
OFFSET 484
BBED> m /x 95440d00
BBED-00209: invalid number (95440d00)
BBED> m /x 9544
BBED> set offset +2
OFFSET 486
BBED> m /x 0d00
BBED> p kcvfhcpc
ub4 kcvfhcpc @140 0x00000003
BBED> m /x 78000000
BBED> p kcvfhcpc
ub4 kcvfhcpc @140 0x00000078
BBED> p kcvfhccc
ub4 kcvfhccc @148 0x00000002
BBED> m /x 77000000
BBED> p kcvfhccc
ub4 kcvfhccc @148 0x00000077
BBED> sum
Check value for File 0, Block 1:
current = 0xe079, required = 0x5940
BBED> sum apply
Check value for File 0, Block 1:
current = 0x5940, required = 0x5940
1
三、数据文件online
[oracle@xifenfei ora11g]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Thu Mar 15 07:48:48 2012
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 368263168 bytes
Fixed Size 1345016 bytes
Variable Size 301992456 bytes
Database Buffers 58720256 bytes
Redo Buffers 6205440 bytes
Database mounted.
Database opened.
SQL> select file#,to_char(checkpoint_change#,'999999999999'),
2 to_char(RESETLOGS_CHANGE#,'999999999999')
3 from v$datafile_header;
FILE# TO_CHAR(CHECKPOINT_CHANGE# TO_CHAR(RESETLOGS_CHANGE#,
---------- -------------------------- --------------------------
1 869528 868871
2 869528 868871
3 869528 868871
4 869528 868871
5 869525 868871
SQL> recover datafile 5;
Media recovery complete.
SQL> alter database datafile 5 online;
Database altered.
rman 备份出现ORA-00245/RMAN-08132
rman备份出现如下错误
RMAN> backup full tag 'dbfull' format '/jfkdata1/rman_bak/full_%d_%u' database 2> include current controlfile plus archivelog format '/jfkdata1/rman_bak/arch_%d_%u'; Starting backup at 13-MAR-12 current log archived using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=297 instance=ykcdb2 device type=DISK channel ORA_DISK_1: starting archived log backup set channel ORA_DISK_1: specifying archived log(s) in backup set input archived log thread=1 sequence=29 RECID=43 STAMP=777808820 input archived log thread=1 sequence=30 RECID=46 STAMP=777816035 input archived log thread=2 sequence=21 RECID=45 STAMP=777816033 channel ORA_DISK_1: starting piece 1 at 13-MAR-12 channel ORA_DISK_1: finished piece 1 at 13-MAR-12 piece handle=/jfkdata1/rman_bak/arch_YKCDB_01n5p1vf tag=DBFULL comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25 Finished backup at 13-MAR-12 Starting backup at 13-MAR-12 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00002 name=/jfkdata1/oradata/ykcdb/sysaux01.dbf input datafile file number=00001 name=/jfkdata1/oradata/ykcdb/system01.dbf input datafile file number=00003 name=/jfkdata1/oradata/ykcdb/undotbs01.dbf input datafile file number=00005 name=/jfkdata1/oradata/ykcdb/undotbs02.dbf input datafile file number=00004 name=/jfkdata1/oradata/ykcdb/users01.dbf channel ORA_DISK_1: starting piece 1 at 13-MAR-12 channel ORA_DISK_1: finished piece 1 at 13-MAR-12 piece handle=/jfkdata1/rman_bak/full_YKCDB_02n5p209 tag=DBFULL comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:25 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 13-MAR-12 channel ORA_DISK_1: finished piece 1 at 13-MAR-12 piece handle=/jfkdata1/rman_bak/full_YKCDB_03n5p213 tag=DBFULL comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 13-MAR-12 Starting backup at 13-MAR-12 current log archived using channel ORA_DISK_1 channel ORA_DISK_1: starting archived log backup set channel ORA_DISK_1: specifying archived log(s) in backup set input archived log thread=2 sequence=22 RECID=48 STAMP=777816102 input archived log thread=1 sequence=31 RECID=47 STAMP=777816101 channel ORA_DISK_1: starting piece 1 at 13-MAR-12 channel ORA_DISK_1: finished piece 1 at 13-MAR-12 piece handle=/jfkdata1/rman_bak/arch_YKCDB_04n5p217 tag=DBFULL comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 13-MAR-12 ORA-00245: control file backup operation failed RMAN-08132: WARNING: cannot update recovery area reclaimable file list RMAN>
从这里可以看出数据库文件,归档日志,spfile和controlfile都备份完成,后面又出现一个controlfile失败,应该是控制文件快照备份失败。
错误原因
RMAN creates a copy of the control file for read consistency, this is the snapshot controlfile. Due to the changes made to the controlfile backup mechanism in 11gR2 any instances in the cluster may write to the snapshot controlfile. Therefore, the snapshot controlfile file needs to be visible to all instances. The same happens when a backup of the controlfile is created directly from sqlplus any instance in the cluster may write to the backup controfile file. In 11gR2 onwards, the controlfile backup happens without holding the control file enqueue. For non-RAC database, this doesn't change anything. But, for RAC database, the snapshot controlfile location must be in a shared file system that will be accessible from all the nodes. The snapshot controlfile MUST be accessible by all nodes of a RAC database.
大致意思就是rman的snapshot controlfile必须放在共享存储之上。
解决方法
The snapshot controlfile MUST be accessible by all nodes of a RAC database, if the snapshot controlfile does not reside in on a shared device this error will raise. 1. Check the snapshot controlfile location: RMAN> show all; 2. Configure the snapshot controlfile to a shared disk: RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '<shared_disk>/snapcf_<DBNAME>.f';

加我微信(17813235971)
加我QQ(107644445)

