Oracle RMAN针对丢失控制文件的场景

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638    QQ号:47079569    邮箱:service@parnassusdata.com

RMAN 从丢失的控制文件
当没有备份文件可用,但是重做日志不完整时

第五情景

Bob 丢失了所有的控制文件,删除了控制文件的RMAN备份,Bob 需要创建一个新的控制文件,以便不丢失重做日志文件中的数据,他使用故障发生之前生成的sql 命令, 创建控制文件,恢复数据库。

现在问题很严重,Bob已经失去了所有的控制文件,最糟糕的是,他没有任何备份。 所以,他需要重建控制文件,幸运的是,通过使用create controlfile 命令重建控制文件,Oracle帮助 Bob 解决了问题,看一下这个案例。

首先, Bob 会移动控制文件,在这种情况下请注意,需要重做日志完整,使用重做日志和归档日志,我们和Bob 能够打开数据库,为了模拟控制文件丢失,将其移动到另一个位置。  

SQL>
alter
database backup controlfile to trace;
$ mv *.ctl control_backup/

因为 Bob丢失了控制文件, 他立刻使用 abort选项终止了实例。

SQL> shut
abort;
ORACLE instance shut down.

为了再次创建控制文件, Bob 需要这个文件存储的所有数据库信息,并且这必须和数据库结构完全匹配,通过使用下列命令,获得当前结构和创建命令是可能的:

alter database backup controlfile to trace.

这将在用户转储目的地(10g)或诊断目的地(11g)创建基于文本的跟踪文件,如果我们没有对数据库结构做任何改变,我们可以简单地留下该文件并使用它,这个文件包括两个部分:  有重设日志的和没有重设日志的。不完全恢复需要重设日志选项。

同时, 这里因为控制文件比剩下的数据库更旧,我们需要使用备份控制文件选项通知Oracle,一个旧的控制文件正被使用,如下:

recover database using backup controlfile;

幸运的是, 所有的这些都已经存在于我们将要从alter database 选项中获得的跟踪文件中,跟踪本身包含大量的信息,这可能并不需要; 跟踪文件中最好只有我们需要的内容,作为SYS 用户连接时我们需要运行这个脚本,它具有和剩余进程一起向前的所有命令,以下是该文件的来源:

startup nomount
create controlfile reuse database “orcl” noresetlogs  archivelog
maxlogfiles 16
maxlogmembers 3
maxdatafiles 100
maxinstances 8
maxloghistory 292
logfile
group 1 ‘/u01/app/oracle/oradata/orcl/redo01.log’  size 50m,
group 2 ‘/u01/app/oracle/oradata/orcl/redo02.log’  size 50m
group 3 ‘/u01/app/oracle/oradata/orcl/redo03.log’  size 50m
datafile
‘/u01/app/oracle/oradata/orcl/system01.dbf’,
‘/u01/app/oracle/oradata/orcl/undotbs01.dbf’,
‘/u01/app/oracle/oradata/orcl/sysaux01.dbf’,
‘/u01/app/oracle/oradata/orcl/users01.dbf’,
‘/u01/app/oracle/oradata/orcl/example01.dbf’,
character set we8iso8859p1;
recover database;

因此Bob将该命令置于一个名叫 create_controlfile.sql 的脚本中并运行,如下:

SQL>
@/home/oracle/create_controlfile.sql
ORACLE instance started.

Total System Global Area  171573248 bytes
Fixed Size                  1298668 bytes
Variable Size             138415892 bytes
Database Buffers           25165824 bytes
Redo Buffers                6692864 bytes
Control file created.|
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/orcl/redo01.log
Log applied.
Media recovery complete.

创建控制文件并执行恢复之后,Bob使用重设日志选项打开数据库 (如果他运行create controlfile resetlogs):

SQL>
alter database
open resetlogs;
Database altered.

创建控制文件时,有可能出现仅仅使用默认的给定文件向前在这里可能是不够的,一种情况可能是我们已经添加了一个新的表空间,然后丢失了控制文件,没有备份或只有旧的备份,不会有新添加的表空间,在这种情况中,新添加的表空间上的信息保存到之前的控制文件,并且使用带有恢复数据库的备份控制文件选项是很重要的 ,如果没有已存在某处的的旧控制文件的备份,我们正在使用跟踪选项从头创建它,我们需要注意新添加的所有数据文件的路径和所有表空间的名称 存在于该控制文件的列表中。

为了证明这一点, 看这里的相同案例,下面是数据库中的文件和表空间:

SQL>
select
name
from
v$datafile;

NAME
—————————————-/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf
/u01/app/oracle/oradata/orcl/example01.dbf

SQL>
select * from
v$tablespace;

     TS# NAME                           INC BIG FLA ENC
—— —————————— — — — —
0 SYSTEM                         YES NO  YES
1 SYSAUX                         YES NO  YES
2 UNDOTBS1                       YES NO  YES
4 USERS                          YES NO  YES
3 TEMP                           NO  NO  YES
6 EXAMPLE                        YES NO  YES

6 rows selected.

现在另外添加一个空间到列表中:

SQL> create
tablespace new
2  datafile ‘/u01/app/oracle/oradata/orcl/new.dbf’ SIZE 1m;
Tablespace created.

SQL>
select
count(*)
from
v$tablespace;

COUNT(*)
———-
7

因此现在我们已经添加一个空间文件备份中没有的文件到数据库中 ,控制文件丢失后,我们尝试从备份中恢复它,如下:

RMAN> restore controlfile from ‘/u01/app/oracle/
flash_recovery_area/ORCL/backupset/2009_11_19/
o1_mf_ncnnf_TAG20091119T083712_5j9fm60b_.bkp’;
RMAN> alter database mount;
RMAN> recover database;
……….
……….
……….
archived log file name=/u01/app/oracle/oradata/
orcl/redo02.log thread=1 sequence=8
creating datafile file number=6 name=/u01/app/
oracle/oradata/orcl/new.dbf
RMAN-00571: ===========================================================
RMAN-00569: =============== error message stack follows ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/19/2009 09:11:12
ORA-01119: error in creating database file ‘/
u01/app/oracle/oradata/orcl/new.dbf’
ORA-27038: created file already exists
Additional information: 1

从归档重做日志文件中恢复数据库,应用信息时, RMAN 尝试创建新的数据文件 new.dbf,因为关于new.dbf创建的信息写入到归档重做日志文件中,不存在于控制文件中,因为原始文件就在这里,我们需要重命名并恢复它,如下:

SQL> recover
database using backup controlfile;
ORA-00283: recovery session canceled due to errors
ORA-01111: name for data file 6 is unknown – rename to correct file
ORA-01110: data file 6: ‘/u01/app/oracle/product/11.1.0/db_1/dbs/UNNAMED00006’
SQL> alter
database rename file ‘/u01/app/oracle/product/11.1.0/db_1/dbs/UNNAMED00006’ TO
‘/u01/app/oracle/oradata/orcl/new.dbf’;
Database altered.

SQL>
recover
database using backup controlfile;
ORA-00279: change 564920 generated at 11/19/2009 08:43:22 needed for thread 1
ORA-00289: suggestion :
/u01/app/oracle/flash_recovery_area/ORCL/archivelog/2009_11_19/o1_mf_1_8_%u_.arcORA-00280:
change 564920 for thread 1 is in
sequence #8
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oradata/orcl/redo02.log
Log applied.
Media recovery complete.
SQL>

SQL> alter
database open resetlogs;
Database altered.

SQL> select * from
v$tablespace;

  TS# NAME                           INC BIG FLA ENC
—– —————————— — — — —
0 SYSTEM                         YES NO  YES
1 SYSAUX                         YES NO  YES
2 UNDOTBS1                       YES NO  YES
4 USERS                          YES NO  YES
3 TEMP                           NO  NO  YES
6 EXAMPLE                        YES NO  YES
7 NEW                            YES NO  YES

7 rows selected.

在一个更糟糕的案例情景中, 所有的控制文件损坏或移动,没有控制文件备份可用, 不幸的是,数据库关闭,同时, 之前没有采用控制文件跟踪,另外 , 使用 alter database backup controlfile to trace采用控制文件跟踪万泉寺不可能的; 因为运行该命令,数据库必须在, MOUNTed OPENed 状态下。

在这种情况下,必须使用create controlfile 命令人工创建控制文件,但是为此 需要记住所有数据文件、重做日志文件和字符设置细节的合格的路径,为这样的问题,在某处保存一个控制文件跟踪的副本,是一个很好的做法。 

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569