使用using backup controlfile恢复db之后为什么需要resetlogs

这篇文章主要为大家展示了“使用using backup controlfile恢复db之后为什么需要resetlogs”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“使用using backup controlfile恢复db之后为什么需要resetlogs”这篇文章吧。

这个问题我想可能不仅仅困挠我一个人，不过很多时候我们却又解释不清，觉得oracle似乎使用using backup controlfile恢复db之后没必要resetlogs，但是我觉得resetlogs似乎又有些道理…

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
–冷备份
SQL> startup
ORACLE instance started.

Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 83887484 bytes
Database Buffers 75497472 bytes
Redo Buffers 7139328 bytes
数据库装载完毕。
数据库已经打开。
SQL> select group#,status,sequence# ,archived,first_change# from v$log;

GROUP# STATUS SEQUENCE# ARC FIRST_CHANGE#
———- —————- ———- — ————-
1 CURRENT 2 NO 1090927
2 INACTIVE 1 YES 1090926
3 UNUSED 0 YES 0

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。

Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 83887484 bytes
Database Buffers 75497472 bytes
Redo Buffers 7139328 bytes
数据库装载完毕。
–目前controlfile是最新的，如果controlfile不损坏，查看一下db能最终恢复到的scn是1092089
SQL> select file#,checkpoint_change# from v$datafile;

FILE# CHECKPOINT_CHANGE#
———- ——————
1 1092089
3 1092089
4 1092089
7 1092089

SQL>

SQL> shutdown immediate
ORA-01109: 数据库未打开

已经卸载数据库。
ORACLE 例程已经关闭。
–删除了controlfile和datafile，拷贝备份时的controlfile和datafile
SQL> startup
ORACLE 例程已经启动。

Total System Global Area 167772160 bytes
Fixed Size 1247876 bytes
Variable Size 83887484 bytes
Database Buffers 75497472 bytes
Redo Buffers 7139328 bytes
数据库装载完毕。
ORA-00314: 日志 1 (用于线程 1) 要求的序号 与 不匹配
ORA-00312: 联机日志 1 线程 1: 'D:ORADATATESTREDO01.LOG'

SQL> recover database using backup controlfile;
ORA-00279: 更改 1091621 (在 07/31/2010 14:33:23 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1_

2_%U_.ARC
ORA-00280: 更改 1091621 (用于线程 1) 在序列 #2 中

指定日志: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 更改 1091764 (在 07/31/2010 14:35:30 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1_

3_%U_.ARC
ORA-00280: 更改 1091764 (用于线程 1) 在序列 #3 中
ORA-00278: 此恢复不再需要日志文件
'E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1

_2_6595S2CQ_.ARC'

ORA-00279: 更改 1091766 (在 07/31/2010 14:35:31 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1_

4_%U_.ARC
ORA-00280: 更改 1091766 (用于线程 1) 在序列 #4 中
ORA-00278: 此恢复不再需要日志文件
'E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1

_3_6595S400_.ARC'

ORA-00279: 更改 1091769 (在 07/31/2010 14:35:36 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1_

5_%U_.ARC
ORA-00280: 更改 1091769 (用于线程 1) 在序列 #5 中
ORA-00278: 此恢复不再需要日志文件
'E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1

_4_6595S8RF_.ARC'

ORA-00279: 更改 1091771 (在 07/31/2010 14:35:37 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1_

6_%U_.ARC
ORA-00280: 更改 1091771 (用于线程 1) 在序列 #6 中
ORA-00278: 此恢复不再需要日志文件
'E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1

_5_6595S9TC_.ARC'

ORA-00279: 更改 1091774 (在 07/31/2010 14:35:43 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1_

7_%U_.ARC
ORA-00280: 更改 1091774 (用于线程 1) 在序列 #7 中
ORA-00278: 此恢复不再需要日志文件
'E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1

_6_6595SHSW_.ARC'

ORA-00308: 无法打开归档日志
'E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1

_7_%U_.ARC'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

SQL>

SQL> recover database using backup controlfile;
ORA-00279: 更改 1091774 (在 07/31/2010 14:35:43 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1_

7_%U_.ARC
ORA-00280: 更改 1091774 (用于线程 1) 在序列 #7 中

指定日志: {=suggested | filename | AUTO | CANCEL}
D:oradatatestredo01.log
ORA-00310: 归档日志包含序列 5; 要求序列 7
ORA-00334: 归档日志: 'D:ORADATATESTREDO01.LOG'

SQL> recover database using backup controlfile;
ORA-00279: 更改 1091774 (在 07/31/2010 14:35:43 生成) 对于线程 1 是必需的
ORA-00289: 建议:
E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREATESTARCHIVELOG2010_07_31O1_MF_1_

7_%U_.ARC
ORA-00280: 更改 1091774 (用于线程 1) 在序列 #7 中

指定日志: {=suggested | filename | AUTO | CANCEL}
D:oradatatestredo02.log
已应用的日志。
完成介质恢复。
SQL> select file#,checkpoint_change# from v$datafile;

FILE# CHECKPOINT_CHANGE#
———- ——————
1 1092088
3 1092088
4 1092088
7 1092088

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#
———- ——————
1 1092088
3 1092088
4 1092088
7 1092088

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项
–=======================================
–最终db恢复到了1092088，和完全恢复到的scn1092089仅仅相差了1，难道相差1这就是使用using backup controlfile恢复db之后需要resetlogs的理由？其实我觉得肯定不是，之所以需要resetlogs
的原因是controlfile里记录了大量的和redo相关的信息，现在最新的controlfile损坏之后，很多有关
redo的信息不明确了，这可能是最终使用using backup controlfile恢复db之后需要resetlogs的理由
毕竟oracle 打开db使用的是resetlogs而不是resetscn…
–=======================================
SQL> alter database open resetlogs;

数据库已更改。

SQL> select file#,checkpoint_change# from v$datafile;

FILE# CHECKPOINT_CHANGE#
———- ——————
1 1092091
3 1092091
4 1092091
7 1092091

SQL> select file#,checkpoint_change# from v$datafile_header;

FILE# CHECKPOINT_CHANGE#
———- ——————
1 1092091
3 1092091
4 1092091
7 1092091

SQL>

以上是“使用using backup controlfile恢复db之后为什么需要resetlogs”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！