一个RMAN恢复中的逻辑悖论

[复制链接]
查看11 | 回复9 | 2010-3-1 11:04:58 | 显示全部楼层 |阅读模式
问题是用rman的restore controlfile from autobackup命令在逻辑上不能成功执行。
现做9i i的备份恢复实验,没有catalog库,用的是control file保存备份/恢复信息。备份介质是disk, 已经用rman备份了全库,归档日志,并启动了control file的备份,备份都是是成功的。
这里关键一点是,备份control file时用的不是缺省目录和缺省格式,而是自定义的,如
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/orabk/data/%d_CTLF_%F.ORABK';

现假设数据库的控制文件,数据文件,重做日志,联机日志全部损坏,试图用现有备份恢复到可能的最近程度。
登录rman,
rman TARGET /
以非mount方式启动database
startup nomount;
重置DBID
SET DBID 3981547501;#这个DBID值来自控制文件备份的名称(即%F的作用);
运行
run {

allocate channel c1 device type disk;

set controlfile autobackup format for device type disk to '/orabk/data/%d_CTLF_%F.ORABK';

restore controlfile from autobackup

maxdays 7;
}

不成功,
因为找不到正确的控制文件备份。set语句实际未生效。
试图用另外一条命令重置当前控制文件备份的路径和格式,
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/orabk/data/%d_CTLF_%F.ORABK';
执行不成功,因为这需要database在mount在状态下才能执行,当前的control file的format参数是缺省目录,缺省的'%F'。
因为当前状态是非mount的,这个参数不可能修改成功,因此restore controlfile from autobackup也不可能成功。
只好手工指定最近的备份的控制文件来恢复,如
restore controlfile from '/orabk/data/B3_CTLF_c-3981547501-20060815-01.ORABK';
控制文件可以恢复成功。
之后再运行
alter database mount;
恢复数据库,
run {

allocate channel c1 device type disk;

restore database;

restore archivelog all;
};
登录sqlplus,
recover database until cancel using backup controlfile;
选择auto,
最后会有报错信息,不管。继续执行下列语句,
alter database open resetlogs;
数据库可以打开,数据恢复到可能的最近状态。

但是oracle官方手册《Recovery Manager User's Guide》称,
即使在上述条件下,用restore controlfile from autobackup恢复控制文件也是可行的,只是需要重置control file的format。
我的实验证明它在实际中是不可行的,在逻辑上也不可行:没有蛋就没有鸡。在控制文件丢失的情况,rman是以缺省配置启动,我不可能修改rman的任何当前缺省配置,因为database在此情况也不可能mount。

请网友们指点一下,是oracle手册错了?还是我理解有问题,或另有其它方法?
谢谢。
回复

使用道具 举报

千问 | 2010-3-1 11:04:58 | 显示全部楼层
能不能把oracle官方手册中的那一段貼出來看看
回复

使用道具 举报

千问 | 2010-3-1 11:04:58 | 显示全部楼层
up ....
回复

使用道具 举报

千问 | 2010-3-1 11:04:58 | 显示全部楼层
那就用 restorecontrolfilefrom backup_file ;
不就好了。
至于文档中这个问题描述的不清楚,你认为是错误那就是错误好了,也不多这一处


回复

使用道具 举报

千问 | 2010-3-1 11:04:58 | 显示全部楼层
文档中的
10. Restoring and Recovering with Recovery Manager
Performing Recovery with a Backup Control File and No Recovery Catalog
This section assumes that you have RMAN backups of the control file, but do not use a recovery catalog. Assuming that you enabled the control file autobackup feature for the target database, you can restore an autobackup of the control file. Because the autobackup uses a default format, RMAN can restore it even though it does not have a repository available that lists the available backups. You can restore the autobackup to the default or a new location. RMAN replicates the control file to all CONTROL_FILES locations automatically.

--------------------------------------------------------------------------------
Note:
If you know the backup piece name (for example, from the media manager or because the piece is on disk), then you can specify the piece name using the RESTORE CONTROLFILE FROM 'filename' command. The server records the location of every autobackup in the alert log.
--------------------------------------------------------------------------------

Because you are not connected to a recovery catalog, the control file must have a record of all needed backups. If any backups are not listed in the control file, then RMAN cannot restore them. If datafile copies are located on disk but are not in the control file, however, then you can add them to the control file repository with the CATALOG command. This cataloging procedure is described in "Cataloging Archived Logs and User-Managed Copies".
Because the repository is not available when you restore the control file, run the SET DBID command to identify the target database. You should only run the SET DBID command in the following specialized circumstances:
You are not connected to a recovery catalog and want to restore the control file or server parameter file.
You are connected to a recovery catalog want to restore the control file, but the database name is not unique in the recovery catalog.
The server parameter file is lost and you want to restore it.
To recover the database with an autobackup of the control file without a recovery catalog:
Start RMAN and connect to the target database. For example, run:
CONNECT TARGET /

Start the target instance without mounting the database. For example:
STARTUP NOMOUNT;

Set the database identifier for the target database with SET DBID. RMAN displays the DBID whenever you connect to the target. You can also obtain it by running LIST, querying the catalog, or looking at the filenames of control file autobackup. (refer to "Restoring When Multiple Databases in the Catalog Share the Same Name: Example&quot

. For example, run:
SET DBID 676549873;

Restore the autobackup control file, then perform recovery. Do the following:
Optionally, specify the most recent backup time stamp that RMAN can use when searching for a control file autobackup to restore.
[B]If a nondefault format was used to create the control file, then specify a nondefault format for the restore of the control file. [/B]
If the channel that created the control file autobackup was device type sbt, then you must allocate one or more sbt channels. Because no repository is available, you cannot use automatic channels. If the autobackup was created on a disk channel, however, then you do not need to manually allocate a channel.
Restore the autobackup of the control file, optionally setting the maximum number of days backward that RMAN can search (up to 366) and the initial sequence number that it should use in its search for the first day.
Mount the database. Note that because the repository is now available, any automatic channels that you configured are also available.
If the online logs are inaccessible, then restore and recover the database as described in "Performing Incomplete Restore and Recovery". You must terminate recovery by setting the UNTIL clause to a time, log sequence, or SCN before the online redo logs. If the online logs are usable, then restore and recover the database as described in "Performing Complete Restore and Recovery".
In this example, the online redo logs have been lost. This example limits the restore of the control file autobackup, then performs recovery of the database to log sequence 13243, which is the most recent archived log:
RUN
{
# Optionally, set upper limit for eligible time stamps of control file backups
# SET UNTIL TIME '09/10/2000 13:45:00';
# Specify a nondefault autobackup format only if required
# SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '?/oradata/%F.bck';
ALLOCATE CHANNEL c1 DEVICE TYPE sbt; # manually allocate one or more channels
RESTORE CONTROLFILE FROM AUTOBACKUP
MAXSEQ 100 # start at sequence 100 and count down
MAXDAYS 180; # start at UNTIL TIME and search back 6 months
ALTER DATABASE MOUNT DATABASE;
}
# uses automatic channels configured in restored control file
RESTORE DATABASE UNTIL SEQUENCE 13243;
RECOVER DATABASE UNTIL SEQUENCE 13243; # recovers to most recent archived log

If recovery was successful, then open the database and reset the online logs:
ALTER DATABASE OPEN RESETLOGS;

It is recommended that you immediately back up the database, preferably with the database mounted (to avoid possible data loss in an open database). Because the database is a new incarnation, the backups made before the RESETLOGS are not easily usable. For example, enter:
SHUTDOWN IMMEDIATE
STARTUP MOUNT
BACKUP DATABASE;
ALTER DATABASE OPEN;
回复

使用道具 举报

千问 | 2010-3-1 11:04:58 | 显示全部楼层
写文档的人并不一定是真正开发程序的人,文档和程序开发 可能是同步进行的……
而 文档中的bug也有不少的
也许最初设计的时候是这么个想法,但是最后开发人员没有实现这个,也是有这种可能的。 作为我们应用者,就是找到解决问题的办法。 至于文档中这个问题,知道就行了,你要是有兴趣,可以给oracle 一个建议让他们修正文档。
回复

使用道具 举报

千问 | 2010-3-1 11:04:58 | 显示全部楼层
试一试allocate channel,set 这些在这样的情况下没有意义
回复

使用道具 举报

千问 | 2010-3-1 11:04:58 | 显示全部楼层
如果修改过控制文件自动备份的路径,那新路径本来就是写在控制文件中的。
当然,控制文件没有了,他就不知道备份路径在哪里了,这个时候,手工指定特定的文件名称即可。
回复

使用道具 举报

千问 | 2010-3-1 11:04:58 | 显示全部楼层
学习了:-)
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行