使用以下过程来还原备从的控制文件如果永久性的介质故障损坏数据库的所有控制文件和你有一个控制文件的备份。如果控制文件是不可访问的，你可以启动实例，但不挂载数据库。当控制文件不可用时，如果你尝试挂载数据库，那么你会收到以下错误信息：
ORA-00205: error in identifying control file, check alert log for more info
注：定位跟踪文件和alert日志的最简单方式是运行SQL查询：SELECT NAME, VALUE FROM V$DIAG_INFO。
你不可以挂载和打开数据库直到控制文件是可以再次访问的。如果你还原一个备份的控制文件，那么你必须使用RESETLOGS选项打开数据库。
如下表中指示的，还原控制文件的过程取决于在线redo日志是否是可用的。
| 在线日志的状态 | 数据文件的状态 | 还原过程 |
|---|---|---|
| 可用的 | 当前的 | 如果在线日志包含必要的redo用于恢复，那么在恢复期间还原备份控制文件和应用日志。你必须指定包含更改的在线日志的文件名称来打开数据库。在恢复之后，使用RESETLOGS选项打开数据库。 注：如果你重建控制文件，那么当在线redo日志可以访问时在恢复之后不需要使用OPEN RESETLOGS选项。 |
| 不可用的 | 当前的 | 如果在线日志包含必要的redo用于恢复，那么重建控制文件。因为在线redo日志是不可访问的，使用RESETLOGS选项打开。 |
| 可用的 | 备份 | 还原备份控制文件，执行完全恢复，然后使用RESETLOGS选项打开数据库。 |
| 不可用的 | 备份 | 还原备份控制文件，执行不完全恢复，然后使用RESETLOGS选项打开数据库。 |
1．使用缺省位置中的备份控制文件恢复
如果可能，还原控制文件到它的原始位置。在这种方式中，你可以避免必须在初始化参数文件中指定新的控制文件位置。
还原备份控制文件到它的缺省位置：
1）如果实例仍在运行，关闭它：
SQL> SHUTDOWN ABORT
2）纠正导致介质故障的硬件问题。
3）还原备份控制文件到spfile或初始化参数文件中的CONTROL_FILES中指定的所有位置。例如，如果/disk1/oradata/trgt/control01.dbf和/disk2/oradata/trgt/control02.dbf是列在spfile中的控制文件位置，那么使用操作系统工具还原备份控制文件到这些位置：
% cp /backup/control01.dbf /disk1/oradata/trgt/control01.dbf
% cp /backup/control02.dbf /disk2/oradata/trgt/control02.dbf
4）启动新实例和挂载数据库。
SQL> STARTUP MOUNT
5）通过执行RECOVER命令和USING BACKUP CONTROLFILE子语句开始恢复。如果执行不完全恢复，指定UNTIL CANCEL。
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
6）应用提示的归档文件。如果收到另外一个日志称需要的归档日志是缺失的，那么它可能意味着必要的redo记录位于在线redo日志。当实例故障时非归档的更改位于在线日志中，这个情形可能发生。
例如，假设你看到以下信息：
ORA-00279: change 55636 generated at 11/08/2002 16:59:47 needed for thread 1
ORA-00289: suggestion : /oracle/work/arc_dest/arcr_1_111.arc
ORA-00280: change 55636 for thread 1 is in sequence #111
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
你可以指定在线redo日志的名称和按回车（你可能必须尝试几次直到你找到正确的日志）：
ORACLE_HOME/oradata/redo01.dbf
Log applied.
Media recovery complete.
如果在线日志是不可访问的，那么你可以取消恢复而不应用它们。如果所有数据文件是当前的和如果在线redo日志中的redo需要用于恢复，那么你不能在没有应用在线日志时打开数据库。如果在线日志是不可访问的，那么你必须重建控制文件。
7）在完成恢复之后使用RESETLOGS选项打开数据库：
SQL> ALTER DATABASE OPEN RESETLOGS;
2．使用非缺省位置中的备份控制文件恢复
如果因为介质损坏太严重不能还原控制文件到它的原始位置，那么你必须在spfile中指定新的控制文件位置。有效的控制文件必须在CONTROL_FILES指定的所有位置中可用的。如果不是，数据库会阻止你挂载数据库。
还原备份控制文件到非缺省位置：
1）如果实例仍在运行，关闭它：
SQL> SHUTDOWN ABORT
2）纠正导致介质故障的硬件问题。
3）编辑CONTROL_FILES初始化参数中指定的所有位置来反映新控制文件位置。假设列在spfile中的控制文件位置如下，两个磁盘是不可访问的：
CONTROL_FILES=‘/disk1/oradata/trgt/control01.dbf’,
‘/disk2/oradata/trgt/control02.dbf’
可以编辑初始化参数文件和指定可以访问的位置：
CONTROL_FILES=‘/disk3/cf/control01.dbf’,‘/disk4/cf/control02.dbf’
4）还原备份控制文件到spfile或初始化参数文件中的CONTROL_FILES中指定的所有位置。例如，如果/disk1/oradata/trgt/control01.dbf和/disk2/oradata/trgt/control02.dbf是列在spfile中的控制文件位置，那么使用操作系统工具还原备份控制文件到这些位置：
% cp /backup/control01.dbf /disk1/oradata/trgt/control01.dbf
% cp /backup/control02.dbf /disk2/oradata/trgt/control02.dbf
5）启动新实例和挂载数据库。
SQL> STARTUP MOUNT
6）通过执行RECOVER命令和USING BACKUP CONTROLFILE子语句开始恢复。如果执行不完全恢复，指定UNTIL CANCEL。
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
7）应用提示的归档文件。如果收到另外一个日志称需要的归档日志是缺失的，那么它可能意味着必要的redo记录位于在线redo日志。当实例故障时非归档的更改位于在线日志中，这个情形可能发生。
例如，假设你看到以下信息：
ORA-00279: change 55636 generated at 11/08/2002 16:59:47 needed for thread 1
ORA-00289: suggestion : /oracle/work/arc_dest/arcr_1_111.arc
ORA-00280: change 55636 for thread 1 is in sequence #111
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
你可以指定在线redo日志的名称和按回车（你可能必须尝试几次直到你找到正确的日志）：
ORACLE_HOME/oradata/redo01.dbf
Log applied.
Media recovery complete.
如果在线日志是不可访问的，那么你可以取消恢复而不应用它们。如果所有数据文件是当前的和如果在线redo日志中的redo需要用于恢复，那么你不能在没有应用在线日志时打开数据库。如果在线日志是不可访问的，那么你必须重建控制文件。
8）在完成恢复之后使用RESETLOGS选项打开数据库：
SQL> ALTER DATABASE OPEN RESETLOGS;
3．使用备份控制文件恢复通过增加的数据文件
如果使用备份控制文件进行数据库恢复向前滚动通过CREATE TABLESPACE或ALTER TABLESPACE ADD DATAFILE操作，那么当为增加的文件应用redo记录时数据库停止恢复和让你确认文件名称。
例如，假设以下序列事件发生：
1）备份数据库。
2）创建表空间包含以下数据文件：/disk1/oradata/trgt/test01.dbf和 /disk1/oradata/trgt/test02.dbf。
3）还原备份控制文件和执行介质恢复通过CREATE TABLESPACE操作。
当应用CREATE TABLESPACE的redo数据时你可能看到以下错误：
ORA-00283: recovery session canceled due to errors
ORA-01244: unnamed datafile(s) added to control file by media recovery
ORA-01110: data file 11: '/disk1/oradata/trgt/test02.dbf'
ORA-01110: data file 10: '/disk1/oradata/trgt/test01.dbf
恢复通过ADD DATAFILE操作：
1）查询V$DATAFILE来查看增加的文件。
SELECT FILE#,NAME FROM V$DATAFILE;
FILE# NAME
-------- ---------------------------------------
1 /disk1/oradata/trgt/system01.dbf
...
10 /disk1/oradata/trgt/UNNAMED00001
11 /disk1/oradata/trgt/UNNAMED00002
2）如果多个未命名的文件存在，那么使用以下其中一个方法来确认哪个未命名的文件对应哪个数据文件：
1）打开alert_SID.log，它包含关于每个未命名的文件的原始文件位置的信息。
2）从错误信息和V$DATAFILE中获取每个未命名文件的原始文件位置：每个未命名的文件对应错误信息中相同文件号的文件。
3）执行ALTER DATABASE RENAME FILE语句来重命名数据文件。
ALTER DATABASE RENAME FILE ‘/db/UNNAMED00001’ TO
‘/disk1/oradata/trgt/test01.dbf’;
ALTER DATABASE RENAME FILE ‘/db/UNNAMED00002’ TO
‘/disk1/oradata/trgt/test02.dbf’;
4）通过执行恢复语句继续恢复。
RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
4．使用备份控制文件恢复只读表空间
如果你有只读表空间在只读或缓慢的介质上，那么当使用USING BACKUP CONTROLFILE选项时你可能遇到错误或不佳的性能。这个情况发生当备份控制文件指示当备份控制文件时表空间是读写的。在这种情况中，介质恢复可能尝试写到文件。对于只读介质，数据库报错称它不能写到文件中。对于缓慢的介质，比如通过磁带备份分层存储系统，性能可能会变差。
为了避免这些问题，使用当前的控制文件而不是备份来恢复数据库。如果你必须使用备份控制文件，那么你也可以避免这个问题如果只读表空间没有遭受介质故障。当使用备份控制文件时有以下可选方案来恢复只读表空间和缓慢介质：
1）在使用备份控制文件恢复之前将数据文件从只读表空间中脱机，然后在介质恢复之后将文件联机。
2）使用正确版本的控制文件来恢复。如果当恢复完成时表空间是只读的，那么控制文件备份必须来自表空间是只读的时候。类似地，如果表空间在恢复之后是读写的，那么控制文件必须来自表空间是读写的时候。
来源：《Oracle Database Backup and Recovery User’s Guide，19c》
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
