数据库在启动过程中会检查SCN是否相同，才可以正常启动数据库。SCN 是system checkpoint number的简称，它可以简单的理解为是数据库时间，数据库用SCN记录数据的更改，它在数据库的故障恢复中非常重要。
SCN按照存储位置和作用分为4种，其中3种保存在controlfile中，一种保存在每个数据文件的文件头中，他们分别是：
1.System checkpoint SCN in the control file. --当发生checkpoint完成后，oracle将 system checkpoint SCN保存在控制文件中 select checkpoint_change# from v$database;
2.Datafile Checkpoint SCN individually in the control file for each datafile. -- 当发生checkpoint完成后，oracle将 datafile checkpoint SCN分别保存在控制文件和数据文件中 select name,checkpoint_change# from v$datafile;
oracle在启动过程中首先检车是否需要media recoery，在检查是否需要instance recovery。
我们需要另开一个文章阐述SCN号与数据库启动、关闭以及恢复的关系，在这里就不多说了，下面来开始我们的测试。
场景：丢失一个数据文件，用rman备份还原，但是无法提供归档日志
目标：修改文件头推进SCN，跳过归档实现完全恢复
1、首先通过RMAN 备份需要测试的数据文件，这里我们测试datafile 1
2、产生归档并删除datafile 1，重启数据库产生故障场景
3、在RMAN还原datafile 1 ，但是归档已经丢失 肯定无法recover。 我们这里删除的system数据文件，不然的话我们可以把数据文件offline 启动数据库（当然，缺少undo也不可以的）。也就说必须system是online的才可以打开数据库。
4、再次检查SCN号， 在 v$datafile_header发现system 的SCN 和 v$recover_file 的SCN 现在均为1060266 控制文件的SCN号为1060672
5、使用BBED修改数据文件头 是SCN号一致
6、再次在数据库验证，数据文件的start SCN 是否跟其他SCN一致，并尝试打开数据库。至此，通过BBED修改数据文件的SCN号跳过归档文件完全打开数据库完成。
7、需要思考的地方
7.1 通过BBED修改ckp SCN号时，dump的数据采用十六进制存储， 在BBED中需要修改的十六进制数（402f10 ）与我们通过to_char计算的十六进制数（102f40）正好相反，我们的实验环境是linux，属于little字节序。
7.2 是否尝试使用_allow_resetlog_corruption参数来修复数据，跳过归档实现完全恢复呢？ 答案是可以的
7.3 加深了对BBED工具的使用，进一步了解数据文件的存储结构。
SCN按照存储位置和作用分为4种，其中3种保存在controlfile中，一种保存在每个数据文件的文件头中，他们分别是：
1.System checkpoint SCN in the control file. --当发生checkpoint完成后，oracle将 system checkpoint SCN保存在控制文件中 select checkpoint_change# from v$database;
2.Datafile Checkpoint SCN individually in the control file for each datafile. -- 当发生checkpoint完成后，oracle将 datafile checkpoint SCN分别保存在控制文件和数据文件中 select name,checkpoint_change# from v$datafile;
3.Checkpoint SCN value in the header of each datafile, which also reffered as Start SCN --该SCN 用于检查是否需要做media recovery 。 select name,checkpoint_change# from v$datafile_header;
4.The stop SCN is held in the control file for each datafile. ---保存在控制文件中，该SCN 用于检查是否需要做instance recovery ，正常情况下 可读可写的online的数据文件的SCN值为null 。 select name,last_change# from v$datafile;
数据库在启动时检查的SCN是那几个呢 ，他们分别是System checkpoint SCN、Datafile Checkpoint SCN、Checkpoint SCN，这3个相同数据库就可以正常启动。当其中一个不相同时就需要做media recovery。oracle在启动过程中首先检车是否需要media recoery，在检查是否需要instance recovery。
我们需要另开一个文章阐述SCN号与数据库启动、关闭以及恢复的关系，在这里就不多说了，下面来开始我们的测试。
场景：丢失一个数据文件，用rman备份还原，但是无法提供归档日志
目标：修改文件头推进SCN，跳过归档实现完全恢复
1、首先通过RMAN 备份需要测试的数据文件，这里我们测试datafile 1
点击(此处)折叠或打开
- [oracle@Primary bbed_10g_64]$ rman target /
- Recovery Manager: Release 11.2.0.4.0 - Production on Sat Jul 23 07:00:15 2016
- Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
- connected to target database: JINGFAN (DBID=2726520687)
- RMAN> backup datafile 1;
- Starting backup at 2016-07-23 07:01:36
- using target database control file instead of recovery catalog
- allocated channel: ORA_DISK_1
- channel ORA_DISK_1: SID=152 device type=DISK
- channel ORA_DISK_1: starting full datafile backup set
- channel ORA_DISK_1: specifying datafile(s) in backup set
- input datafile file number=00001 name=/oracle/database/oradata/jingfan/system01.dbf
- channel ORA_DISK_1: starting piece 1 at 2016-07-23 07:01:36
- channel ORA_DISK_1: finished piece 1 at 2016-07-23 07:02:01
- piece handle=/oracle/database/fast_recovery_area/JINGFAN/backupset/2016_07_23/o1_mf_nnndf_TAG20160723T070136_cs59gkx6_.bkp tag=TAG20160723T070136 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 2016-07-23 07:02:05
- channel ORA_DISK_1: finished piece 1 at 2016-07-23 07:02:06
- piece handle=/oracle/database/fast_recovery_area/JINGFAN/backupset/2016_07_23/o1_mf_ncsnf_TAG20160723T070136_cs59hf4h_.bkp tag=TAG20160723T070136 comment=NONE
- channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
- Finished backup at 2016-07-23 07:02:06
点击(此处)折叠或打开
- #创建一个表 为了更好的产生归档日志
- SQL> create table tt as select * from all_objects;
- Table created.
- SQL> update tt set object_id=10;
- 84995 rows updated.
- SQL> commit;
- Commit complete.
-
- SQL> select count(*) from tt;
- COUNT(*)
- ----------
- 84995
- SQL> column name format a50
- /*
- 未切换日志，发现数据库的数据文件system01 的 system checkpoint SCN、datafile checkpoint SCN和 start SCN in the header of datafile 是不同的。
- */
- SQL> select checkpoint_change# from v$database;
- CHECKPOINT_CHANGE#
- ------------------
- 1051981
- SQL>
- SQL> select file#,name,checkpoint_change#,last_change#,status from v$datafile;
-
FILE# NAME CHECKPOINT_CHANGE# LAST_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ ------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060266 SYSTEM
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1051981 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1051981 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1051981 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1051981 ONLINE
-
- SQL> select file#,name,checkpoint_change#,status from v$datafile_header;
-
FILE# NAME CHECKPOINT_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060266 ONLINE
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1051981 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1051981 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1051981 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1051981 ONLINE
- SQL> select file#,online_status,change# from v$recover_file;
- no rows selected
- SQL> alter system switch logfile;
- System altered.
- SQL> /
- System altered.
- SQL> /
- System altered.
- /*
-
通过切换日志，使数据库的数据文件system01 的 system checkpoint SCN、datafile checkpoint SCN和 start SCN in the header of datafile 变的相同。
- */
- SQL> select checkpoint_change# from v$database;
-
-
CHECKPOINT_CHANGE#
------------------
1060589
-
- SQL> select file#,name,checkpoint_change#,last_change#,status from v$datafile;
-
-
FILE# NAME CHECKPOINT_CHANGE# LAST_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ ------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060589 SYSTEM
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1060589 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1060589 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1060589 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1060589 ONLINE
-
- SQL> select file#,name,checkpoint_change#,status from v$datafile_header;
-
FILE# NAME CHECKPOINT_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060589 ONLINE
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1060589 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1060589 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1060589 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1060589 ONLINE
- SQL> select file#,online_status,change# from v$recover_file;
- no rows selected
- SQL> ! rm /oracle/database/oradata/jingfan/system01.dbf
- SQL> alter system switch logfile;
- System altered.
- SQL> /
- System altered.
- SQL> /
- System altered.
- /*
- shutdown abort 数据库，启动发现datafile 1
- */
-
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 776646656 bytes
Fixed Size 2257272 bytes
Variable Size 478154376 bytes
Database Buffers 289406976 bytes
Redo Buffers 6828032 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '/oracle/database/oradata/jingfan/system01.dbf'
SQL> host oerr ora 1157
01157, 00000, "cannot identify/lock data file %s - see DBWR trace file"
// *Cause: The background process was either unable to find one of the data
// files or failed to lock it because the file was already in use.
// The database will prohibit access to this file but other files will
// be unaffected. However the first instance to open the database will
// need to access all online data files. Accompanying error from the
// operating system describes why the file could not be identified.
// *Action: Have operating system make file available to database. Then either
// open the database or do ALTER SYSTEM CHECK DATAFILES.
SQL> host oerr ora 01110
01110, 00000, "data file %s: '%s'"
// *Cause: Reporting file name for details of another error. The reported
// name can be of the old file if a data file move operation is
// in progress.
// *Action: See associated error message.
# 再次查询各个SCN，记录在数据文件中的start SCN丢失 -
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
1060672
SQL> select file#,name,checkpoint_change#,status from v$datafile_header;
FILE# NAME CHECKPOINT_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ --------------
1 0 ONLINE
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1060672 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1060672 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1060672 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1060672 ONLINE
SQL> select file#,name,checkpoint_change#,last_change#,status from v$datafile;
FILE# NAME CHECKPOINT_CHANGE# LAST_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ ------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060672 SYSTEM
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1060672 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1060672 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1060672 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1060672 ONLINE
SQL> select file#,online_status,change# from v$recover_file;
FILE# ONLINE_STATUS CHANGE#
---------- -------------- ----------
1 ONLINE 0 - # 继续模拟丢失归档日志的情况
-
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 22
Next log sequence to archive 24
Current log sequence 24
SQL> show parameter recover
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_recovery_file_dest string /oracle/database/fast_recovery
_area
db_recovery_file_dest_size big integer 4182M
db_unrecoverable_scn_tracking boolean TRUE
recovery_parallelism integer 0
SQL> host
[oracle@Primary ~]$ cd /oracle/database/fast_recovery_area/
jingfan/ JINGFAN/ primary/ PRIMARY/
[oracle@Primary ~]$ rm -rf /oracle/database/fast_recovery_area/JINGFAN/archivelog/*
[oracle@Primary ~]$ ll !$
ll /oracle/database/fast_recovery_area/JINGFAN/archivelog/*
ls: cannot access /oracle/database/fast_recovery_area/JINGFAN/archivelog/*: No such file or directory
[oracle@Primary JINGFAN]$ exit
exit
SQL>
点击(此处)折叠或打开
- [oracle@Primary bbed_10g_64]$ rman target /
- Recovery Manager: Release 11.2.0.4.0 - Production on Sat Jul 23 07:31:37 2016
- Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
- connected to target database: JINGFAN (DBID=2726520687, not open)
- RMAN> restore datafile 1;
- Starting restore at 2016-07-23 07:31:42
- using target database control file instead of recovery catalog
- allocated channel: ORA_DISK_1
- channel ORA_DISK_1: SID=10 device type=DISK
- channel ORA_DISK_1: starting datafile backup set restore
- channel ORA_DISK_1: specifying datafile(s) to restore from backup set
- channel ORA_DISK_1: restoring datafile 00001 to /oracle/database/oradata/jingfan/system01.dbf
- channel ORA_DISK_1: reading from backup piece /oracle/database/fast_recovery_area/JINGFAN/backupset/2016_07_23/o1_mf_nnndf_TAG20160723T070136_cs59gkx6_.bkp
- channel ORA_DISK_1: piece handle=/oracle/database/fast_recovery_area/JINGFAN/backupset/2016_07_23/o1_mf_nnndf_TAG20160723T070136_cs59gkx6_.bkp tag=TAG20160723T070136
- channel ORA_DISK_1: restored backup piece 1
- channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
- Finished restore at 2016-07-23 07:32:18
- RMAN> recover datafile 1; #完全恢复不可行
- Starting recover at 2016-07-23 07:32:39
- using channel ORA_DISK_1
- starting media recovery
- RMAN-00571: ===========================================================
- RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
- RMAN-00571: ===========================================================
- RMAN-03002: failure of recover command at 07/23/2016 07:32:40
- RMAN-06053: unable to perform media recovery because of missing log
- RMAN-06025: no backup of archived log for thread 1 with sequence 23 and starting SCN of 1060669 found to restore
- RMAN-06025: no backup of archived log for thread 1 with sequence 22 and starting SCN of 1060666 found to restore
- RMAN-06025: no backup of archived log for thread 1 with sequence 21 and starting SCN of 1060604 found to restore
- RMAN-06025: no backup of archived log for thread 1 with sequence 20 and starting SCN of 1060592 found to restore
- RMAN-06025: no backup of archived log for thread 1 with sequence 19 and starting SCN of 1060589 found to restore
- RMAN-06025: no backup of archived log for thread 1 with sequence 18 and starting SCN of 1059998 found to restore
- RMAN> recover datafile 1 until sequence 17; #完全恢复不可行
- Starting recover at 2016-07-23 07:33:27
- using channel ORA_DISK_1
- RMAN-00571: ===========================================================
- RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
- RMAN-00571: ===========================================================
- RMAN-03002: failure of recover command at 07/23/2016 07:33:28
- RMAN-06556: datafile 1 must be restored from backup older than SCN 1059913
- RMAN>
- SQL> select checkpoint_change# from v$database;
-
CHECKPOINT_CHANGE#
------------------
1060672
- SQL> select file#,name,checkpoint_change#,last_change#,status from v$datafile;
-
FILE# NAME CHECKPOINT_CHANGE# LAST_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ ------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060672 SYSTEM
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1060672 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1060672 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1060672 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1060672 ONLINE
- SQL> select file#,name,checkpoint_change#,status from v$datafile_header;
-
FILE# NAME CHECKPOINT_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060266 ONLINE
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1060672 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1060672 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1060672 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1060672 ONLINE
- SQL> select file#,online_status,change# from v$recover_file;
-
FILE# ONLINE_STATUS CHANGE#
---------- -------------- ----------
1 ONLINE 1060266
-
-
SQL> select to_char(1060266,'xxxxxxx'),to_char(1060672,'xxxxxxx') from dual; #十进制转换为十六进制
TO_CHAR(1060266, TO_CHAR(1060672,
---------------- ----------------
102daa 102f40
-
SQL>
点击(此处)折叠或打开
- [oracle@Primary bbed_10g_64]$ bbed parfile=/home/oracle/bbed_10g_64/bbed.par
- Password:
- BBED: Release 2.0.0.0.0 - Limited Production on Sat Jul 23 07:40:49 2016
- Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
- ************* !!! For Oracle Internal Use only !!! ***************
- BBED> info
-
File# Name Size(blks)
----- ---- ----------
1 /oracle/database/oradata/jingfan/system01.dbf 97280
2 /oracle/database/oradata/jingfan/sysaux01.dbf 69120
3 /oracle/database/oradata/jingfan/undotbs01.dbf 14720
4 /oracle/database/oradata/jingfan/users01.dbf 640
5 /oracle/database/oradata/jingfan/example01.dbf 44320
- BBED> show
-
FILE# 1 FILE# 1
BLOCK# 1
OFFSET 0
DBA 0x00400001 (4194305 1,1)
FILENAME /oracle/database/oradata/jingfan/system01.dbf
BIFILE bifile.bbd
LISTFILE /home/oracle/bbed_10g_64/file.txt
BLOCKSIZE 8192
MODE Edit
EDIT Unrecoverable
IBASE Dec
OBASE Dec
WIDTH 80
COUNT 512
LOGFILE log.bbd
SPOOL No
- BBED>print kcvfhckp
-
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x00102daa
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x36b6a2d0
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000012
ub4 kcrbabno @504 0x0000102b
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
- BBED> dump /v dba 1,1 offset 484 count 32
- File: /oracle/database/oradata/jingfan/system01.dbf (1)
- Block: 1 Offsets: 484 to 515 Dba:0x00400001
- -------------------------------------------------------
- aa2d1000 00000000 d0a2b636 01000000 l .-.........6....
- 12000000 2b100000 1000a868 02000000 l ....+......h....
- <16 bytes="" per="" line="">
-
- BBED> modify /x 402f10 dba 1,1 offset 484 count 32
- BBED-00203: incomplete/malformed command
- BBED> modify /x 402f10 dba 1,1 offset 484
- Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
- File: /oracle/database/oradata/jingfan/system01.dbf (1)
- Block: 1 Offsets: 484 to 515 Dba:0x00400001
- ------------------------------------------------------------------------
- 402f1000 00000000 d0a2b636 01000000 12000000 2b100000 1000a868 02000000
- <32 bytes="" per="" line="">
- BBED> dump /v offset 484 count 32
- File: /oracle/database/oradata/jingfan/system01.dbf (1)
- Block: 1 Offsets: 484 to 515 Dba:0x00400001
- -------------------------------------------------------
- 402f1000 00000000 d0a2b636 01000000 l @/.........6....
- 12000000 2b100000 1000a868 02000000 l ....+......h....
- <16 bytes="" per="" line="">
-
BBED> print kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x00102f40
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x36b6a2d0
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000012
ub4 kcrbabno @504 0x0000102b
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
- BBED>
点击(此处)折叠或打开
- SQL> select checkpoint_change# from v$database;
-
-
CHECKPOINT_CHANGE#
------------------
1060672
- SQL> select file#,name,checkpoint_change#,last_change#,status from v$datafile;
-
-
FILE# NAME CHECKPOINT_CHANGE# LAST_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ ------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060672 SYSTEM
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1060672 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1060672 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1060672 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1060672 ONLINE
- SQL> select file#,name,checkpoint_change#,status from v$datafile_header;
-
FILE# NAME CHECKPOINT_CHANGE# STATUS FILE# NAME CHECKPOINT_CHANGE# STATUS
---------- -------------------------------------------------- ------------------ --------------
1 /oracle/database/oradata/jingfan/system01.dbf 1060672 ONLINE
2 /oracle/database/oradata/jingfan/sysaux01.dbf 1060672 ONLINE
3 /oracle/database/oradata/jingfan/undotbs01.dbf 1060672 ONLINE
4 /oracle/database/oradata/jingfan/users01.dbf 1060672 ONLINE
5 /oracle/database/oradata/jingfan/example01.dbf 1060672 ONLINE
- SQL> select file#,online_status,change# from v$recover_file;
-
FILE# ONLINE_STATUS CHANGE# FILE# ONLINE_STATUS CHANGE#
---------- -------------- ----------
1 ONLINE 1060672
- SQL> recover datafile 1;
- Media recovery complete.
- SQL> select file#,online_status,change# from v$recover_file;
- no rows selected
- SQL> alter database open;
- Database altered.
- SQL>
7.1 通过BBED修改ckp SCN号时，dump的数据采用十六进制存储， 在BBED中需要修改的十六进制数（402f10 ）与我们通过to_char计算的十六进制数（102f40）正好相反，我们的实验环境是linux，属于little字节序。
7.2 是否尝试使用_allow_resetlog_corruption参数来修复数据，跳过归档实现完全恢复呢？ 答案是可以的
7.3 加深了对BBED工具的使用，进一步了解数据文件的存储结构。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/27039319/viewspace-2122512/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
最新文章
- 闪回技术-闪回查询
- 闪回技术-闪回数据库01
- 配置ADG 产生ORA-10458错误
- oracle RAC 迁移votedisk
- ORACL RAC 环境下添加磁盘组提示ORA-15032 ORA-15201
- create database提示ORA-01501 ORA-00200 ORA-00202 ORA-27038错误提示
- 手动创建实例时提示ORA-00845的解决方法
- RAC环境中ORA-01157: cannot identify/lock data file 9 - see DBWR trace file
- 在RAC环境中recreate controlfile 提示ORA-01503和ORA-12720 错误
- RMAN-Configuring an Archived Redo Log Deletion Policy
