一则关于控制文件全部丢失后如何重新编目RMAN元数据的简单实验

主题：一则简单的RMAN元数据编目实验，来自于博客园AskScuti。

场景：RMAN备份完整情况下，未使用Catalog目录库。删除了所有的控制文件，在手工重建后，导致记录在控制文件中的RMAN备份元数据丢失。

目录

1. RMAN备份

2. 删除所有控制文件

3. 重建控制文件

4. 重新编目元数据

5. 验证可用性

1. RMAN备份

更改RMAN控制文件自动全备选项（建议开启）

RMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name PROD1 are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F‘; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128‘; # default
CONFIGURE COMPRESSION ALGORITHM ‘BASIC‘ AS OF RELEASE ‘DEFAULT‘ OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘/u01/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_PROD1.f‘; # default

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

RMAN进行全备

RMAN> backup database format ‘/u01/app/oracle/backup/%U_%s_%d.full.bak‘;

Starting backup at 2019-05-22 12:34:33
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=44 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=/u01/app/oracle/oradata/PROD1/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/PROD1/sysaux01.dbf
input datafile file number=00010 name=/u01/app/oracle/oradata/PROD1/aaa02.dbf
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
input datafile file number=00008 name=/u01/app/oracle/oradata/PROD1/tbs_c01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/PROD1/users01.dbf
input datafile file number=00009 name=/u01/app/oracle/oradata/PROD1/aaa01.dbf
input datafile file number=00006 name=/u01/app/oracle/oradata/PROD1/abc01.dbf
input datafile file number=00007 name=/u01/app/oracle/oradata/PROD1/abcd01.dbf
channel ORA_DISK_1: starting piece 1 at 2019-05-22 12:34:34
channel ORA_DISK_1: finished piece 1 at 2019-05-22 12:35:11
piece handle=/u01/app/oracle/backup/01u26b2p_1_1_1_PROD1.full.bak tag=TAG20190522T123433 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:38
Finished backup at 2019-05-22 12:35:12

Starting Control File and SPFILE Autobackup at 2019-05-22 12:35:12
piece handle=/u01/app/oracle/fast_recovery_area/PROD1/autobackup/2019_05_22/o1_mf_s_1008938112_gg9nd0oc_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 2019-05-22 12:35:13

查看RMAN备份集

RMAN> list backup;

List of Backup Sets
===================

BS Key  Type LV Size  Device Type Elapsed Time Completion Time
------- ---- -- ----- ----------- ------------ -------------------
1       Full    1.70G DISK        00:00:37     2019-05-22 12:35:10
        BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20190522T123433
        Piece Name: /u01/app/oracle/backup/01u26b2p_1_1_1_PROD1.full.bak
  List of Datafiles in backup set 1
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----
  1       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/system01.dbf
  2       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/sysaux01.dbf
  3       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/undotbs01.dbf
  4       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/users01.dbf
  5       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/example01.dbf
  6       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/abc01.dbf
  7       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/abcd01.dbf
  8       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/tbs_c01.dbf
  9       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/aaa01.dbf
  10      Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/aaa02.dbf

BS Key  Type LV Size  Device Type Elapsed Time Completion Time
------- ---- -- ----- ----------- ------------ -------------------
2       Full    9.36M DISK        00:00:00     2019-05-22 12:35:12
        BP Key: 2   Status: AVAILABLE  Compressed: NO  Tag: TAG20190522T123512
        Piece Name: /u01/app/oracle/fast_recovery_area/PROD1/autobackup/2019_05_22/o1_mf_s_1008938112_gg9nd0oc_.bkp
  SPFILE Included: Modification time: 2019-05-22 11:54:09
  SPFILE db_unique_name: PROD1
  Control File Included: Ckp SCN: 1757737      Ckp time: 2019-05-22 12:35:12

2. 删除所有控制文件

删除当前系统所有控制文件

SQL> select name from v$controlfile;

NAME
-----------------------------------------------------
/u01/app/oracle/oradata/PROD1/control01.ctl
/u01/app/oracle/oradata/PROD1/control02.ctl
/u01/app/oracle/oradata/PROD1/control03.ctl
/u01/app/oracle/oradata/PROD1/control04.ctl
/u01/app/oracle/oradata/PROD1/control05.ctl
/u01/app/oracle/oradata/PROD1/control06.ctl
/u01/app/oracle/oradata/PROD1/control07.ctl
/u01/app/oracle/oradata/PROD1/control08.ctl

8 rows selected.

SQL> !rm -rf /u01/app/oracle/oradata/PROD1/*.ctl

SQL> startup force;
ORACLE instance started.

Total System Global Area  830930944 bytes
Fixed Size            　　 2232920 bytes
Variable Size          　　591400360 bytes
Database Buffers      　　 234881024 bytes
Redo Buffers            　 2416640 bytes
ORA-00205: error in identifying control file, check alert log for more info

3. 重建控制文件

重启失败，手工重建控制文件。重建前，请确认好所有数据文件、日志文件具体路径。如果之前没有单独备份控制文件，可参考官方文档11g Release 2 (11.2) Database Backup and Recovery User‘s Guide：To create a new control file and recover the database 语句进行重建。

手工编写脚本

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "PROD1" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 ‘/u01/app/oracle/oradata/PROD1/redo01.log‘  SIZE 50M BLOCKSIZE 512,
  GROUP 2 ‘/u01/app/oracle/oradata/PROD1/redo02.log‘  SIZE 50M BLOCKSIZE 512,
  GROUP 3 ‘/u01/app/oracle/oradata/PROD1/redo03.log‘  SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  ‘/u01/app/oracle/oradata/PROD1/system01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/sysaux01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/undotbs01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/users01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/example01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/abc01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/abcd01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/tbs_c01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/aaa01.dbf‘,
  ‘/u01/app/oracle/oradata/PROD1/aaa02.dbf‘
CHARACTER SET AL32UTF8
;

运行脚本

SQL> shutdown abort;
ORACLE instance shut down.
SQL> @con.sql

Control file created.

注意：控制文件会根据参数文件里面指定的具体路径被重新创建，但是，因为SCN号与数据文件不同，所以无法直接打开，也就是需要恢复Recover。

直接打开会报错

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: ‘/u01/app/oracle/oradata/PROD1/system01.dbf‘

动态性能视图 v$recover_file 里面记录了需要恢复的所有数据文件

SQL> select * from v$recover_file;

进行恢复：由于控制文件被重建，所以恢复必须使用 using backup controlfile 语句进行恢复，且必须以 resetlogs 方式打开数据库。

SQL> recover database using backup controlfile;
ORA-00279: change 1757718 generated at 05/22/2019 12:34:34 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/archive1/1_67_1001001677.dbf
ORA-00280: change 1757718 for thread 1 is in sequence #67

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: cannot open archived log ‘/u01/app/oracle/archive1/1_67_1001001677.dbf‘
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

ORA-00308: cannot open archived log ‘/u01/app/oracle/archive1/1_67_1001001677.dbf‘
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

这时候自动应用归档的时候提示错误，是因为，没有此归档（没有生成），介质恢复需要用的数据应该在日志文件里面，尝试下

SQL> recover database using backup controlfile;
ORA-00279: change 1757718 generated at 05/22/2019 12:34:34 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/archive1/1_67_1001001677.dbf
ORA-00280: change 1757718 for thread 1 is in sequence #67

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/PROD1/redo01.log
Log applied.
Media recovery complete.

证明需要恢复的数据是在 redo01.dbf 在线日志文件中，因此完成了恢复。

最后，以 resetlogs 方式打开数据库

SQL> alter database open resetlogs;

Database altered.

4. 重新编目元数据

此时连接 RMAN ，运行命令 list backup; 是没有任何元数据信息的。因为之前存在控制文件中，但是由于被删除，后手工重建，所以元数据丢失。

[[email protected] ~]$ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Wed May 22 13:05:02 2019

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PROD1 (DBID=2222344843)

RMAN> list backup;

using target database control file instead of recovery catalog
specification does not match any backup in the repository

接下来，找到之前RMAN的备份片，进行重新编目（手工注册）

RMAN> catalog backuppiece ‘/u01/app/oracle/backup/01u26b2p_1_1_1_PROD1.full.bak‘;

cataloged backup piece
backup piece handle=/u01/app/oracle/backup/01u26b2p_1_1_1_PROD1.full.bak RECID=1 STAMP=1008940142

RMAN> catalog backuppiece ‘/u01/app/oracle/fast_recovery_area/PROD1/autobackup/2019_05_22/o1_mf_s_1008938112_gg9nd0oc_.bkp‘;

cataloged backup piece
backup piece handle=/u01/app/oracle/fast_recovery_area/PROD1/autobackup/2019_05_22/o1_mf_s_1008938112_gg9nd0oc_.bkp RECID=2 STAMP=1008940181

这时候，再次运行 list backup;命令即可显示

RMAN> list backup;

List of Backup Sets
===================

BS Key  Type LV Size  Device Type Elapsed Time Completion Time
------- ---- -- ----- ----------- ------------ -------------------
1       Full    1.70G DISK        00:00:00     2019-05-22 12:34:33
        BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20190522T123433
        Piece Name: /u01/app/oracle/backup/01u26b2p_1_1_1_PROD1.full.bak
  List of Datafiles in backup set 1
  File LV Type Ckp SCN    Ckp Time            Name
  ---- -- ---- ---------- ------------------- ----
  1       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/system01.dbf
  2       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/sysaux01.dbf
  3       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/undotbs01.dbf
  4       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/users01.dbf
  5       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/example01.dbf
  6       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/abc01.dbf
  7       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/abcd01.dbf
  8       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/tbs_c01.dbf
  9       Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/aaa01.dbf
  10      Full 1757718    2019-05-22 12:34:34 /u01/app/oracle/oradata/PROD1/aaa02.dbf

BS Key  Type LV Size  Device Type Elapsed Time Completion Time
------- ---- -- ----- ----------- ------------ -------------------
2       Full    9.36M DISK        00:00:00     2019-05-22 12:35:12
        BP Key: 2   Status: AVAILABLE  Compressed: NO  Tag: TAG20190522T123512
        Piece Name: /u01/app/oracle/fast_recovery_area/PROD1/autobackup/2019_05_22/o1_mf_s_1008938112_gg9nd0oc_.bkp
  SPFILE Included: Modification time: 2019-05-22 11:54:09
  SPFILE db_unique_name: PROD1
  Control File Included: Ckp SCN: 1757737      Ckp time: 2019-05-22 12:35:12

5. 验证可用性

验证下可用性，手工直接删除某数据文件，并重启

SQL> select name from v$datafile;

NAME
--------------------------------------------------
/u01/app/oracle/oradata/PROD1/system01.dbf
/u01/app/oracle/oradata/PROD1/sysaux01.dbf
/u01/app/oracle/oradata/PROD1/undotbs01.dbf
/u01/app/oracle/oradata/PROD1/users01.dbf
/u01/app/oracle/oradata/PROD1/example01.dbf
/u01/app/oracle/oradata/PROD1/abc01.dbf
/u01/app/oracle/oradata/PROD1/abcd01.dbf
/u01/app/oracle/oradata/PROD1/tbs_c01.dbf
/u01/app/oracle/oradata/PROD1/aaa01.dbf
/u01/app/oracle/oradata/PROD1/aaa02.dbf

10 rows selected.

SQL> !rm -rf /u01/app/oracle/oradata/PROD1/abc01.dbf

SQL> startup force;
ORACLE instance started.

Total System Global Area  830930944 bytes
Fixed Size            2232920 bytes
Variable Size          591400360 bytes
Database Buffers      234881024 bytes
Redo Buffers            2416640 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: ‘/u01/app/oracle/oradata/PROD1/abc01.dbf‘

报错后，通过RMAN进行6号文件的还原与恢复

[[email protected] ~]$ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Wed May 22 13:11:18 2019

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: PROD1 (DBID=2222344843, not open)

RMAN> restore datafile 6;

Starting restore at 2019-05-22 13:11:40
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 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 00006 to /u01/app/oracle/oradata/PROD1/abc01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/backup/01u26b2p_1_1_1_PROD1.full.bak
channel ORA_DISK_1: piece handle=/u01/app/oracle/backup/01u26b2p_1_1_1_PROD1.full.bak tag=TAG20190522T123433
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 2019-05-22 13:11:42

RMAN> recover datafile 6;

Starting recover at 2019-05-22 13:11:49
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 67 is already on disk as file /u01/app/oracle/archive1/1_67_1001001677.dbf
archived log file name=/u01/app/oracle/archive1/1_67_1001001677.dbf thread=1 sequence=67
media recovery complete, elapsed time: 00:00:00
Finished recover at 2019-05-22 13:11:49

原文地址：https://www.cnblogs.com/askscuti/p/10905449.html

时间： 2024-11-16 20:51:35

一则关于控制文件全部丢失后如何重新编目RMAN元数据的简单实验的相关文章

【练习】trace文本重建控制文件

这个小练习是针对控制文件全部丢失后怎么能快速的重建一个控制文件,快速的起库 1.备份控制文件到trace下 SQL> alter database backup controlfile to trace; Database altered. 2.trace文本放在user_dump_dest的路径下 SQL> show parameter dump; NAME TYPE VALUE ------------------------------------ ----------- -------

ORACLE数据库文件丢失后的恢复测试

一.测试环境 数据库版本是11GR2,在做完一份完全备份之后,关机,做一份快照,每一次开机之后都执行数次alter system switch logfile以产生归档日志. 之后的测试都是基于这么一个完全备份来恢复. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/%F'; backup incremental level 0 format '/backup/%T_%f' database; 二.

Oracle DB备份恢复篇之丢失控制文件

实验目的 本篇主要模拟控制文件丢失后,如何根据实际情况恢复数据库,才能使数据库尽可能不丢失数据. 实验环境 1)Linux系统环境 [[email protected] ~]$ lsb_release -a LSB Version: :core-3.1-ia32:core-3.1-noarch:graphics-3.1-ia32:graphics-3.1-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Ente

MyISAM表的.frm文件丢失后的恢复方法

MyISAM表的.frm文件丢失后的恢复方法: 1.创建实验用的MyISAM表t1,并插入数据: mysql> create table t1(id int) engine=myisam; Query OK, 0 rows affected (0.01 sec) mysql> insert into t1 values(1),(2),(3),(4),(5),(6),(7),(8); Query OK, 8 rows affected (0.00 sec) Records: 8  Duplica

Oracle 控制文件(CONTROLFILE)

--============================= -- Oracle 控制文件(CONTROLFILE) --============================= 一.Oracle 控制文件 为二进制文件,初始化大小由CREATE DATABASE指定,可以使用RMAN备份 记录了当前数据库的结构信息,同时也包含数据文件及日志文件的信息以及相关的状态,归档信息等等 在参数文件中描述其位置,个数等等.通常采用分散放开,多路复用的原则.在mount阶段被读取,open阶段一直被使

【oracle11g，9】控制文件

一.控制文件作用: 1.记录了数据库的物理状态. 2.维护数据库的一致性.控制文件中记录了数据库系统scn号.数据文件scn号与数据文件头里的开始scn号,如果这三个scn号一致说明数据库可以启动.如果不一致就要恢复. 3.在参数文件中定义控制文件的位置和个数. 控制文件最少1个,最多8个,多个文件是镜像的关系. 定义控制文件 *.control_files='/opt/oracle/oradata/orcl/control01.ctl','/opt/oracle/oradata/orcl/co

Oracle 控制文件和日志文件

管理控制文件 在Oracle数据库中,控制文件是一个很小(大小一般在10MB范围内)的二进制文件,含有数据库的结构信息,包括数据文件和日志文件的信息.可以将控制文件理解为物理数据库的一个元数据存储库.控制文件在数据库创建时被自动创建,并在数据库发生物理变化时更新.控制文件被不断更新,并且在任何时候都要保证控制文件是可用的.只有Oracle进程才能够安全地更新控制文件的内容,所以,任何时候都不要试图手动编辑控制文件. 由于控制文件在数据库中的重要地位,所以保护控制文件的安全非常重要,为此Oracl

Oracle 物理结构（四） 文件-控制文件

一.什么是控制文件 控制文件是Oracle数据库中十分重要的文件.Oracle启动时,首先会读取参数文件,读取了参数文件,实例所需要的共享内存和后台进程就可以启动了,这就是数据库实例的nomunt阶段.完成这个步骤后,就需要通过参数文件中的control_file参数,找到数据库的控制文件,然后打开控制文件,对控制文件进行校验.这就是Oracle数据库实例启动过程中的Mount阶段. 二.控制文件包含哪些信息 控制文件中包含了Oracle数据库十分重要的信息,其中包括整个数据库的物理结构.所有数

Oracle RMAN 备份控制文件/恢复控制文件

--备份控制文件 rman target / RMAN> startup RMAN> configure controlfile autobackup on; --启动自动备份 RMAN> show CONTROLFILE AUTOBACKUP;  --显示是否自动备份控制文件 RMAN> configure controlfile autobackup format for device type disk to '/backup/%F'; --设置控制文件备份路径 RMAN&g