理解 using backup controlfile

        using backup controlfile 通常用于恢复由于当前控制文件丢失且原来备份的控制文件较当前发生变化的情形之下。using backup controlfile
的 recover 方式一旦使用之后,常用的recover database命令将不可再使用,且必须要使用resetlogs方式来打开数据库,下面是具体的演示描述。

 

一、演示 using backup controlfile 时的相关变化

-->查看数据库SYBO2SZ控制文件的时间信息
sys@SYBO2SZ> ho ls -hltr /u02/database/SYBO2SZ/controlf/
total 29M
-rw-r----- 1 oracle oinstall 9.7M 2012-09-10 11:59 cntl3SYBO2SZ.ctl
-rw-r----- 1 oracle oinstall 9.7M 2012-09-10 11:59 cntl2SYBO2SZ.ctl
-rw-r----- 1 oracle oinstall 9.7M 2012-09-10 11:59 cntl1SYBO2SZ.ctl

-->查看系统时间
sys@SYBO2SZ> ho date
Mon Sep 10 12:00:09 CST 2012

-->查看数据库SYBO2SZ的状态,此时数据库处于关闭状态
sys@SYBO2SZ> ho ps -ef | grep pmon_SYBO2SZ
oracle     440 32067  0 12:01 pts/4    00:00:00 /bin/bash -c ps -ef | grep pmon_SYBO2SZ
oracle     442   440  0 12:01 pts/4    00:00:00 grep pmon_SYBO2SZ

sys@SYBO2SZ> startup mount;
ORACLE instance started.

Total System Global Area  599785472 bytes
Fixed Size                  2074568 bytes
Variable Size             381683768 bytes
Database Buffers          209715200 bytes
Redo Buffers                6311936 bytes
Database mounted.

-->当mount数据库后,控制文件的状态及时间信息被更新
sys@SYBO2SZ> ho ls -hltr /u02/database/SYBO2SZ/controlf/
total 29M
-rw-r----- 1 oracle oinstall 9.7M 2012-09-10 12:02 cntl3SYBO2SZ.ctl
-rw-r----- 1 oracle oinstall 9.7M 2012-09-10 12:02 cntl2SYBO2SZ.ctl
-rw-r----- 1 oracle oinstall 9.7M 2012-09-10 12:02 cntl1SYBO2SZ.ctl

sys@SYBO2SZ> select instance_name,status,database_status from v$instance;

INSTANCE_NAME    STATUS       DATABASE_STATUS
---------------- ------------ -----------------
SYBO2SZ          MOUNTED      ACTIVE

-->此时数据库文件的时间并没有被更新,依旧为11:23
sys@SYBO2SZ> ho ls -hltr /u02/database/SYBO2SZ/oradata/sys*
-rw-r----- 1 oracle oinstall 501M 2012-09-10 11:23 /u02/database/SYBO2SZ/oradata/sysSYBO2SZ.dbf
-rw-r----- 1 oracle oinstall 301M 2012-09-10 11:23 /u02/database/SYBO2SZ/oradata/sysauxSYBO2SZ.dbf

sys@SYBO2SZ> alter session set nls_date_format='yyyymmdd hh24:mi:ss';

-->Author : Robinson Cheng  -->Blog: http://blog.csdn.net/robinson_0612-->也可以看到此时controlfile_type为current,open_resetlogs为NOT ALLOWED
sys@SYBO2SZ> SELECT controlfile_type, controlfile_sequence#, controlfile_change#,controlfile_time,open_resetlogs
  2   FROM v$database;

CONTROL CONTROLFILE_SEQUENCE# CONTROLFILE_CHANGE# CONTROLFILE_TIME  OPEN_RESETL
------- --------------------- ------------------- ----------------- -----------
CURRENT                  6012             1151639 20120910 04:30:14 NOT ALLOWED

-->使用带using backup controlfile的recover 命令,出现Specify log提示
-->此时再开另一个session连接到实例,下面以idle开头的sql提示符即为另一个session
sys@SYBO2SZ> recover database using backup controlfile;
ORA-00279: change 1160803 generated at 09/10/2012 11:23:59 needed for thread 1
ORA-00289: suggestion : /u02/database/SYBO2SZ/archive/arch_793474012_1_3.arc
ORA-00280: change 1160803 for thread 1 is in sequence #3

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.

    -->session2 的操作
	idle> conn / as sysdba
	Connected.
	idle> alter session set nls_date_format='yyyymmdd hh24:mi:ss';

	Session altered.

	-->下面的查询在使用recover database using backup controlfile后此时controlfile_type为BACKUP
	-->且open_resetlogs为REQUIRED,相应的sequence以及change#全部发生了变化
	idle> SELECT controlfile_type, controlfile_sequence#, controlfile_change#,controlfile_time,open_resetlogs
	  2  FROM v$database;

	CONTROL CONTROLFILE_SEQUENCE# CONTROLFILE_CHANGE# CONTROLFILE_TIME  OPEN_RESETL
	------- --------------------- ------------------- ----------------- -----------
	BACKUP                   6014             1160803 20120910 11:23:59 REQUIRED

-->上面的查询完成后,输入cancel,提示Media recovery cancelled
-->尝试使用open方式打开数据库,提示必须使用RESETLOGS or NORESETLOGS选项
sys@SYBO2SZ> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

-->使用resetlogs选项打开数据库,注意,此时如果使用noresetlogs选项,会重复出现上述提示
-->此时提示file1需要介质恢复
sys@SYBO2SZ> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u02/database/SYBO2SZ/oradata/sysSYBO2SZ.dbf'

-->根据recover的提示,查看arch_793474012_1_3.arc文件,此时文件并不存在
sys@SYBO2SZ> ho ls -hltr /u02/database/SYBO2SZ/archive/arch_793474012_1_3.arc
ls: /u02/database/SYBO2SZ/archive/arch_793474012_1_3.arc: No such file or directory

-->再次尝试恢复,依然提示需要arch_793474012_1_3.arc归档日志,此时在session2中查看状态信息
sys@SYBO2SZ> recover database using backup controlfile;
ORA-00279: change 1160803 generated at 09/10/2012 11:23:59 needed for thread 1
ORA-00289: suggestion : /u02/database/SYBO2SZ/archive/arch_793474012_1_3.arc
ORA-00280: change 1160803 for thread 1 is in sequence #3

-->将组3的联机日志路径复制到Specify log处实现完全恢复
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u02/database/SYBO2SZ/redolog/log3aSYBO2SZ.log
Log applied.
Media recovery complete.

	-->session2
	-->可以看到控制文件的sequence#发生了几次变化
	idle> SELECT controlfile_type, controlfile_sequence#, controlfile_change#,controlfile_time,open_resetlogs
	  2  FROM v$database;

	CONTROL CONTROLFILE_SEQUENCE# CONTROLFILE_CHANGE# CONTROLFILE_TIME  OPEN_RESETL
	------- --------------------- ------------------- ----------------- -----------
	BACKUP                   6014             1160803 20120910 11:23:59 REQUIRED

	idle> /

	CONTROL CONTROLFILE_SEQUENCE# CONTROLFILE_CHANGE# CONTROLFILE_TIME  OPEN_RESETL
	------- --------------------- ------------------- ----------------- -----------
	BACKUP                   6015             1160803 20120910 11:23:59 REQUIRED

	-->查看当前联机日志信息
	idle> select * from v$logfile;

	    GROUP# STATUS  TYPE    MEMBER                                                  IS_
	---------- ------- ------- ------------------------------------------------------- ---
	         3         ONLINE  /u02/database/SYBO2SZ/redolog/log3aSYBO2SZ.log          NO
	         3         ONLINE  /u02/database/SYBO2SZ/redolog/log3bSYBO2SZ.log          NO
	         4         ONLINE  /u02/database/SYBO2SZ/redolog/log4aSYBO2SZ.log          NO
	         4         ONLINE  /u02/database/SYBO2SZ/redolog/log4bSYBO2SZ.log          NO

	-->此时日志组3为current状态,因此将组3的联机日志路径复制到Specify log处实现完全恢复
	idle> select * from v$log;

	    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
	---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- -----------------
	         4          1          2   20971520          2 YES INACTIVE               1124329 20120909 09:00:49
	         3          1          3   20971520          2 NO  CURRENT                1150957 20120910 04:00:06

-->完全恢复成功后,使用open方式依旧不成功
sys@SYBO2SZ> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

-->使用open resetlogs方式成功打开数据库
sys@SYBO2SZ> alter database open resetlogs;

Database altered.

    -->session 2
    -->此时session 2中controlfile_type已经被置为CURRENT,open_resetlogs方式也被置为NOT ALLOWED
	idle> SELECT controlfile_type, controlfile_sequence#, controlfile_change#,controlfile_time,open_resetlogs
	  2  FROM v$database;

	CONTROL CONTROLFILE_SEQUENCE# CONTROLFILE_CHANGE# CONTROLFILE_TIME  OPEN_RESETL
	------- --------------------- ------------------- ----------------- -----------
	CURRENT                  6073             1160878 20120910 12:09:58 NOT ALLOWED

-->查看数据文件的时间信息,此时已被更新到最新状态
sys@SYBO2SZ> ho ls -hltr /u02/database/SYBO2SZ/oradata/sys*
-rw-r----- 1 oracle oinstall 501M 2012-09-10 12:09 /u02/database/SYBO2SZ/oradata/sysSYBO2SZ.dbf
-rw-r----- 1 oracle oinstall 301M 2012-09-10 12:09 /u02/database/SYBO2SZ/oradata/sysauxSYBO2SZ.dbf

sys@SYBO2SZ> ho date
Mon Sep 10 12:10:42 CST 2012

-->相应的新的incarnation已经产生
sys@SYBO2SZ> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /u02/database/SYBO2SZ/archive/
Oldest online log sequence     1
Next log sequence to archive   1
Current log sequence           1

二、总结
1、using backup controlfile用于恢复备份的控制文件与当前的控制文件不一致的情形
2、一旦使用了using backup controlfile方式,控制文件的类型将由 current 转移到 backup 类型,同时open_resetlogs为required
3、一旦使用了using backup controlfile方式,后续再次使用recover database将变得无效
4、必须要使用 resetlogs 方式打开数据库,即使我们做的是完全恢复
5、注意理解演示中时间状态的更新情况。实际上来说是实例的启动过程,即:
    nomount:    根据pfile 或 spfile 启动相关后台进程,分配SGA
    mount:         打开控制文件,检查控制文件状态一致性,将数据库与实例关联起来
    open:            根据控制文件中记录的数据文件日志文件对其进行逐一检查无误后,整个数据库置于open状态

 

三、更多参考

有关基于用户管理的备份和备份恢复的概念请参考

    Oracle 冷备份

    Oracle 热备份

    Oracle 备份恢复概念

    Oracle 实例恢复

    Oracle 基于用户管理恢复的处理(详细描述了介质恢复及其处理)

    SYSTEM 表空间管理及备份恢复

    SYSAUX表空间管理及恢复

   Oracle 基于备份控制文件的恢复(unsing backup controlfile)

 

有关RMAN的备份恢复与管理请参考

    RMAN 概述及其体系结构

    RMAN 配置、监控与管理

    RMAN 备份详解

    RMAN 还原与恢复

    RMAN catalog 的创建和使用

    基于catalog 创建RMAN存储脚本

    基于catalog 的RMAN 备份与恢复

    RMAN 备份路径困惑(使用plus archivelog时)

 

有关ORACLE体系结构请参考

    Oracle 表空间与数据文件

    Oracle 密码文件

    Oracle 参数文件

    Oracle 联机重做日志文件(ONLINE LOG FILE)

    Oracle 控制文件(CONTROLFILE)

    Oracle 归档日志

    Oracle 回滚(ROLLBACK)和撤销(UNDO)

    Oracle 数据库实例启动关闭过程

    Oracle 10g SGA 的自动化管理

    Oracle 实例和Oracle数据库(Oracle体系结构)

 

 

时间: 2024-08-03 09:54:05

理解 using backup controlfile的相关文章

Oracle 基于备份控制文件的恢复(unsing backup controlfile)

    Oracle 基于备份控制文件的恢复(unsing backup controlfile)     有关RMAN的备份恢复与管理请参考     RMAN 概述及其体系结构     RMAN 配置.监控与管理     RMAN 备份详解     RMAN 还原与恢复     RMAN catalog 的创建和使用     基于catalog 创建RMAN存储脚本     基于catalog 的RMAN 备份与恢复     RMAN 备份路径困惑     使用RMAN实现异机备份恢复(WIN

详解using backup controlfile

using backup controlfile 通常用于恢复由于当前控制文件丢失且原来备份的控制文件较当前发生变化的情形之下.using backup controlfile 的 recover 方式一旦使用之后,常用的recover database命令将不可再使用,且必须要使用resetlogs方式来打开数据库,下面是具体的演示描述. 一.演示 using backup controlfile 时的相关变化 -->查看数据库SYBO2SZ控制文件的时间信息 sys@SYBO2SZ> ho

using backup controlfile和 until cancel 区别

                                                    using backup controlfile和 until cancel 区别 1. recover database using backup controlfile 2. recover database until cancel 3. recover database using backup controlfile until cancel; 4. recover database

RMAN duplicate from active 时遭遇 ORA-17627 ORA-12154

    最近在从活动数据库进行异机克隆时碰到了ORA-17629,ORA-17627,ORA-12154的错误,起初以为是一个Bug呢.Oracle Bug着实太多了,已经成了习惯性思维了.汗!错误提示是无法连接到连接到远程数据库,连接字符串无法解析.咦,配置了从auxiliary DB到target DB的tnsnames,且都是连通的阿......   1.故障现象    --下面的操作在auxiliary DB所在的机器上完成    [oracle@linux4 ~]$ export OR

如何使用 orachk 工具

      Oracle RAC 安装完毕后的健壮性是一个令人头疼的问题.之前Oracle为之专门推出了raccheck工具,确实方便了我们这些个苦逼的DBA.现在Oracle在raccheck的基础之上又推出了orachk. orachk包含了EXAchk 的功能并替换了流行的 RACcheck 工具,扩大根据用户报告的最重要问题的优先次序的覆盖面,并且主动扫描E-Business Suite Financials Accounts Payables.Oracle Database.Sun S

中小型数据库 RMAN CATALOG 备份恢复方案(二)

      中小型数据库呈现的是数据库并发少,数据库容量小,版本功能受限以及N多单实例等特点.尽管如此,数据库的损失程度也会存在零丢失的情形.企业不愿意花太多的钱又要保证数据库的可靠稳定,可是苦煞了我这些搞DB的.接上一篇文章,中小型数据库 RMAN CATALOG 备份恢复方案(一),我们继续来给出基于中小型数据库的恢复的脚本与其部署.   1.RMAN还原shell脚本 --下面的shell脚本用于实现数据库的自动还原,还原成功后,数据库被关闭.因为我们在Prod数据库无异常的情形下,不需要

Linux 5 下安装MySQL 5.6(RPM方式)

    MySQL在很多领域被广泛使用,尤其是很多互联网企业,诸如腾讯,阿里等等.本文主要介绍在Linux 5下通过rpm方式来安装Mysql,这是比较简单的一种安装方式,具体详见下文.   1.准备对应的安装文件下载页面:http://dev.mysql.com/downloads/mysql/找到对应的版本及所需的文件进行下载,如果下载的为tar文件,请使用tar解压本人在Oracle Edelivery 下载,所以为V44331-01.zip#安装环境[root@linux1 Mysql_

Oracle 基于 RMAN 的不完全恢复(incomplete recovery by RMAN)

      Oracle 数据库可以实现数据库不完全恢复与完全恢复.完全恢复是将数据库恢复到最新时刻,也就是无损恢复,保证数据库无丢失的恢复.而不完全恢复则是根据需要特意将数据库恢复到某个过去的特定时间点或特定的SCN以及特定的Sequence.我们可以通过基于用户管理的不完全恢复实现,也可以通过基于RMAN方式来实现.本文主要描述是基于RMAN的不完全恢复的几种情形并给出示例.有关数据库备份恢复,RMAN备份恢复的概念与实战可以参考文章尾部给出的链接.   一.不完全恢复的步骤    a.关闭

基于 RMAN 的同机数据库克隆

Oracle数据库克隆,也叫着Oracle数据库复制,可以通过基于用户管理的方式来完成,也可以基于RMAN方式来实现.而且Oracle建议使用RMAN方式来实现,因为它简单易用,隐藏其复杂的逻辑,仅仅是执行一条duplicate命令就可以喝茶了.当然,前期的准备工作也是不可少滴,如创建相应的dump目录,准备参数文件,配置监听等等.本文描述了Oracle 11g下如何使用RMAN实现同机克隆数据库.   1.RMAN克隆的几种类型    a.利用RMAN备份克隆并访问目标数据库(也就是原数据库)