首页    技术博客    PHP教程    数据库技术    前端开发   HTML5    Nginx    php论坛
新用户注册 | 会员登录
加入会员，解锁专属内容
取消
热门标签 | HotTags
当前位置:  开发笔记 > 数据库 > 正文

Oracle数据库恢复教程之resetlogs操作

作者：mobiledu2502853397 | 来源：互联网 | 2021-08-19 00:29
这篇文章主要给大家介绍了关于Oracle数据库恢复教程之resetlogs操作的相关资料，文中通过示例代码介绍的非常详细，对大家学习或者使用Oracle数据库具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧

实验环境：RHEL 5.4 + Oracle 11.2.0.3

如果是一名合格的Oracle DBA，对resetlogs这种关键字都应该是极其敏感的，当确认需要这种操作时一定要三思而后行，如果自己不是特别确认，哪怕多花些时间申请去让高级DBA人员协助你一起确认，也不要擅自去尝试执行，避免误操作造成既定损失后追悔莫及。

1.哪些场景可以resetlogs

首先要明确resetlogs操作非常危险的，也只有在进行不完全恢复开库时会使用到。

SQL> alter database open resetlogs;
-> open the database and reset the online logs

官方的描述如下：

Incomplete recovery, also called database point-in-time recovery, results in a noncurrent version of the database. In this case, you do not apply all of the redo generated after the restored backup. Typically, you perform point-in-time database recovery to undo a user error when Flashback Database is not possible.
To perform incomplete recovery, you must restore all data files from backups created before the time to which you want to recover and then open the database with the RESETLOGS option when recovery completes. Resetting the logs creates a new stream of log sequence numbers starting with log sequence 1.

官方的描述其实很清晰，但是实际很多初级DBA小伙伴们在实际工作中遇到这样的场景时却总是有些困惑，甚至误操作引发灾难。

我这里以一个实验来具体说明常见场景：

需求：A机数据库PROD1，现需在B机不同目录下用A机的备份集恢复出来；

A机：

--A机当前current redolog的sequence是57:
SQL> select * from v$log;

 GROUP# THREAD# SEQUENCE#  BYTES BLOCKSIZE MEMBERS ARC STATUS   FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
   1   1   55 52428800  512   1 YES INACTIVE    2051572 19-MAY-19  2060361 19-MAY-19
   2   1   56 52428800  512   1 YES INACTIVE    2060361 19-MAY-19  2060436 19-MAY-19
   3   1   57 52428800  512   1 NO CURRENT    2060436 19-MAY-19 2.8147E+14

--A机做了一次数据库备份：
RMAN> backup database include current controlfile plus archivelog delete all input;


Starting backup at 19-MAY-19
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=23 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=189 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=21 device type=DISK
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=57 RECID=3 STAMP=1008670991
channel ORA_DISK_1: starting piece 1 at 19-MAY-19
channel ORA_DISK_1: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0cu1u68l_1_1.bak tag=TAG20190519T102315 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_57_860888149.dbf RECID=3 STAMP=1008670991
Finished backup at 19-MAY-19

Starting backup at 19-MAY-19
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
channel ORA_DISK_1: starting compressed full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/u01/app/oracle/oradata/PROD1/sysaux01.dbf
channel ORA_DISK_1: starting piece 1 at 19-MAY-19
channel ORA_DISK_2: starting compressed full datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/PROD1/system01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/PROD1/users01.dbf
channel ORA_DISK_2: starting piece 1 at 19-MAY-19
channel ORA_DISK_3: starting compressed full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
input datafile file number=00005 name=/u01/app/oracle/oradata/PROD1/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/PROD1/undotbs01.dbf
channel ORA_DISK_3: starting piece 1 at 19-MAY-19
channel ORA_DISK_3: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0fu1u68p_1_1.bak tag=TAG20190519T102319 comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:00:26
channel ORA_DISK_3: starting compressed full datafile backup set
channel ORA_DISK_3: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_3: starting piece 1 at 19-MAY-19
channel ORA_DISK_3: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0gu1u69j_1_1.bak tag=TAG20190519T102319 comment=NONE
channel ORA_DISK_3: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0du1u68p_1_1.bak tag=TAG20190519T102319 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:03
channel ORA_DISK_2: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0eu1u68p_1_1.bak tag=TAG20190519T102319 comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:01:23
Finished backup at 19-MAY-19

Starting backup at 19-MAY-19
current log archived
using channel ORA_DISK_1
using channel ORA_DISK_2
using channel ORA_DISK_3
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=58 RECID=4 STAMP=1008671084
channel ORA_DISK_1: starting piece 1 at 19-MAY-19
channel ORA_DISK_1: finished piece 1 at 19-MAY-19
piece handle=/home/oracle/backup/0hu1u6bg_1_1.bak tag=TAG20190519T102446 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_58_860888149.dbf RECID=4 STAMP=1008671084
Finished backup at 19-MAY-19

Starting Control File and SPFILE Autobackup at 19-MAY-19
piece handle=/home/oracle/backup/control/c-2082231315-20190519-01 comment=NONE
Finished Control File and SPFILE Autobackup at 19-MAY-19

RMAN> 

--可以看到备份数据库的日志前后都自动归档了当前的redolog（57和58），所以备份完成后，当前日志sequence变为59.
SQL> select * from v$log;

 GROUP# THREAD# SEQUENCE#  BYTES BLOCKSIZE MEMBERS ARC STATUS   FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
   1   1   58 52428800  512   1 YES INACTIVE    2060691 19-MAY-19  2060767 19-MAY-19
   2   1   59 52428800  512   1 NO CURRENT    2060767 19-MAY-19 2.8147E+14
   3   1   57 52428800  512   1 YES INACTIVE    2060436 19-MAY-19  2060691 19-MAY-19

此时把备份集传输到B机，比如/u03/backup目录下，期望恢复到/u03/oradata/PROD1目录下。如果最终只是根据这个备份集去恢复，那最多恢复完sequence 58就结束了，找不到sequence 59（因为59还是当前current的redolog）。Oracle认为这就是最基本的不完全恢复，需要resetlogs操作。

--指定恢复到/u03/oradata/
RMAN> run {
2> set newname for database to '/u03/oradata/PROD1/%U';
3> restore database;
4> }

--切换到上步恢复出来的copy复本：
RMAN> switch database to copy;

datafile 1 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-SYSTEM_FNO-1"
datafile 2 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-SYSAUX_FNO-2"
datafile 3 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-UNDOTBS1_FNO-3"
datafile 4 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-USERS_FNO-4"
datafile 5 switched to datafile copy "/u03/oradata/PROD1/data_D-PROD1_TS-EXAMPLE_FNO-5"

--尝试恢复数据库：
RMAN> recover database;

Starting recover at 19-MAY-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=102 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=9 device type=DISK
allocated channel: ORA_DISK_3
channel ORA_DISK_3: SID=112 device type=DISK

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=58
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/0hu1u6bg_1_1.bak
channel ORA_DISK_1: errors found reading piece handle=/home/oracle/backup/0hu1u6bg_1_1.bak
channel ORA_DISK_1: failover to piece handle=/u03/backup/0hu1u6bg_1_1.bak tag=TAG20190519T102446
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/u01/app/oracle/product/11.2.0/db_1/dbs/arch1_58_860888149.dbf thread=1 sequence=58
unable to find archived log
archived log thread=1 sequence=59
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/19/2019 11:04:21
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 59 and starting SCN of 2060767

RMAN>

可以看到最后有报错信息，就是告诉你找不到sequence 59的日志，这是必然的，因为59还是A机current的redo日志。

2.resetlogs前必须确认路径正确

2.1 先查看控制文件和数据文件头记录的scn是否一致

SQL> select checkpoint_change# from v$datafile;

CHECKPOINT_CHANGE#
------------------
   2060767
   2060767
   2060767
   2060767
   2060767

SQL> select checkpoint_change# from v$datafile_header;

CHECKPOINT_CHANGE#
------------------
   2060767
   2060767
   2060767
   2060767
   2060767

2.2 此时如果尝试直接OPEN会报错

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

提示我们开库必须使用RESETLOGS或者NORESETLOGS选项。

2.3 重点来了，现在可以open resetlogs吗？

当然不行！记得一定要确认好路径！！

--查询发现临时文件以及redo日志的路径都不是我们所期望的：
SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u03/oradata/PROD1/data_D-PROD1_TS-SYSTEM_FNO-1
/u03/oradata/PROD1/data_D-PROD1_TS-SYSAUX_FNO-2
/u03/oradata/PROD1/data_D-PROD1_TS-UNDOTBS1_FNO-3
/u03/oradata/PROD1/data_D-PROD1_TS-USERS_FNO-4
/u03/oradata/PROD1/data_D-PROD1_TS-EXAMPLE_FNO-5

SQL> select name from v$tempfile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/PROD1/temp01.dbf

SQL> select member from v$logfile;

MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/PROD1/redo03.log
/u01/app/oracle/oradata/PROD1/redo02.log
/u01/app/oracle/oradata/PROD1/redo01.log

--rename重命名为我们期望的目录：
SQL> alter database rename file '/u01/app/oracle/oradata/PROD1/temp01.dbf' to '/u03/oradata/PROD1/temp01.dbf';

Database altered.

SQL> alter database rename file '/u01/app/oracle/oradata/PROD1/redo01.log' to '/u03/oradata/PROD1/redo01.log';

Database altered.

SQL> alter database rename file '/u01/app/oracle/oradata/PROD1/redo02.log' to '/u03/oradata/PROD1/redo02.log';

Database altered.

SQL> alter database rename file '/u01/app/oracle/oradata/PROD1/redo03.log' to '/u03/oradata/PROD1/redo03.log';

Database altered.

--再次检查确认：
SQL> select name from v$tempfile;

NAME
--------------------------------------------------------------------------------
/u03/oradata/PROD1/temp01.dbf

SQL> select member from v$logfile;

MEMBER
--------------------------------------------------------------------------------
/u03/oradata/PROD1/redo03.log
/u03/oradata/PROD1/redo02.log
/u03/oradata/PROD1/redo01.log

--最终尝试open开库：
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.

总结：

很多初级人员有可能是对set newname for database这个有误解，以为这里的database包括了临时文件，redo日志文件，误以为自己已经把新库所有路径都指向到了期望位置。但实际并不是这样，这也说明了不确认的操作一定要在测试环境测试验证后才可以在生产环境操作。大家可以想象一下，如果是理解有误没确认日志路径直接执行了resetlogs，那么如果B机正好有别的库用到同名的这些路径，亦或是整个恢复操作就是直接在A机的本机其他目录临时基于某个时间点恢复出一套库，那将会是一场大的生产事故。

好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。


推荐阅读
  • sql

    StoredProcedure “存储过程名” 的TextHeader 中存在语法错误

    StoredProcedure “存储过程名” 的TextHeader 中存在语法错误
    修改存储过程的时候出现StoredProcedure“存储过程名”的TextHeader中存在语法错误出现这样的问题的解决方法（本人修改已成功）在创建存 ... [详细]
  • database

    解决ORA-00227错误：控制文件中检测到损坏块

    本文详细介绍了如何处理Oracle数据库中的ORA-00227错误，即控制文件中检测到损坏块的问题，并提供了具体的解决方案。 ... [详细]
  • sql

    SharePoint BDC 集成挑战与解决方案

    本文探讨了在SharePoint环境中使用BDC（Business Data Catalog）时遇到的问题及其解决策略，包括XML文件导入SSP后的不可见性问题以及与远程SQL Server 2005连接的难题。 ... [详细]
  • sql

    2021年度精选：新手必知的数据分析工具指南

    面对众多的数据分析工具，如何选择最适合自己的那一个？对于初学者而言，了解并掌握几种核心工具是快速入门的关键。本文将从数据处理的不同阶段出发，推荐三种广泛使用的数据分析工具。 ... [详细]
  • sql

    详解MyBatis二级缓存的启用与配置

    详解MyBatis二级缓存的启用与配置
    本文深入探讨了MyBatis二级缓存的启用方法及其配置细节，通过具体的代码实例进行说明，有助于开发者更好地理解和应用这一特性，提升应用程序的性能。 ... [详细]
  • sql

    深入解析Socket结构与实现

    本文详细介绍了Socket在Linux内核中的实现机制，包括基本的Socket结构、协议操作集以及不同协议下的具体实现。通过这些内容，读者可以更好地理解Socket的工作原理。 ... [详细]
  • sql

    HDU 2537 键盘输入处理

    HDU 2537 键盘输入处理
    题目描述了一个名叫Pirates的男孩想要开发一款键盘输入软件，遇到了大小写字母判断的问题。本文提供了该问题的解决方案及实现方法。 ... [详细]
  • sql

    利用JavaScript处理鼠标移出浏览器窗口的事件

    本文探讨了如何通过JavaScript检测鼠标是否离开了浏览器窗口，包括使用原生方法和第三方库的不同解决方案。 ... [详细]
  • sql

    ACM经典书籍推荐

    ACM经典书籍推荐
    本文介绍了几本在算法和计算机科学领域具有重要影响力的书籍，包括由Donald E. Knuth编著的《计算机程序设计艺术》第一卷，以及潘氏兄弟的数论经典教材等。这些书籍不仅是学习相关领域的宝贵资源，也是专业人士不可或缺的参考书。 ... [详细]
  • sql

    基于角色的权限管理在AspNetForums中的应用

    本文探讨了在AspNetForums平台中实施基于角色的权限控制系统的方法，旨在为不同级别的用户提供合适的访问权限，确保系统的安全性和可用性。 ... [详细]
  • sql

    C/C++ 中 #define 的高级用法与技巧

    本文总结了 #define 在 C/C++ 编程中的多种用途和技巧，包括定义常量、函数、宏以及条件编译等，并提供了详细的示例和注意事项。 ... [详细]
  • join

    Excel技巧：单元格中显示公式而非结果的解决方法

    Excel技巧：单元格中显示公式而非结果的解决方法
    本文探讨了在Excel中如何通过简单的方法解决单元格显示公式而非计算结果的问题，包括使用快捷键和调整单元格格式两种方法。 ... [详细]
  • mysql

    深入解析：Hive JDBC编程实践

    本文详细介绍了如何通过JDBC连接Hive进行数据操作，包括Hive服务的启动、相关依赖的配置以及具体代码示例，适合对Hive和JDBC有一定了解的开发者阅读。 ... [详细]
  • mysql

    Linux线程中私有数据的管理与保护

    本文探讨了Linux环境下线程私有数据(Thread-Specific Data, TSD)的概念及其重要性，介绍了如何通过TSD技术避免多线程间全局变量冲突的问题，并提供了具体的实现方法和示例代码。 ... [详细]
  • mysql

    利用R语言实现搜狗细胞词库的转换与处理

    本文介绍如何使用R语言中的相关包来解析和转换搜狗细胞词库（.scel格式），并将其导出为CSV文件，以便于后续的数据分析和文本挖掘任务。 ... [详细]
author-avatar
mobiledu2502853397
这个家伙很懒，什么也没留下！
Tags | 热门标签
RankList | 热门文章
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有