Oracle 无备份情况下的恢复--临时文件/在线重做日志/ORA-00205

13.5 恢复临时文件

临时文件没有也不应该备份。通过V$TEMPFILE可以找到所有的临时文件。

此类文件的损坏会造成需要使用临时表空间的命令执行失败，不至于造成实例崩溃或session中断。由于临时表空间不用保存永久性数据，所以RMAN不会对其备份，一旦损坏采用的恢复策略是替换或者重建。

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE ...

13.6 恢复在线重做日志

所谓恢复在线日志是指其损坏后，创建新的日志取代受损的日志，最终的目的是能够让LGWR进程和实例顺利工作。

本节介绍的恢复策略的前提是实例尚未崩溃

场景1：每个日志组有两个在线日志，1号组的一个日志redo01A.log丢失

这种情况相当于日志没有损坏，同组的多个日志互为镜像，只要不是同一组的全部日志丢失就行，在alert日志中

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1 : /u01/app/oracle/oradata/orcl/redo01A.log

ORA-27037: unable to obtain file status

采用删除后再添加的方法可以恢复正常，不过需要注意只有inactive的状态的日志是可以被删除的，所以需要先查看状态。

SQL> select group#,status from v$log;

    GROUP# STATUS

---------- ----------------

     1 INACTIVE

     2 CURRENT

     3 INACTIVE

如果状态为current，就还不能立即恢复，应该先利用一次日志切换和一次完全检查点将损坏的日志组设置为inactive状态

SQL> alter system switch logfile;

SQL> alter system checkpoint;

然后先将旧配置删除

SQL> alter database drop logfile member ‘/u01/app/oracle/oradata/orcl/redo01A.log’;

SQL> alter database add logfile member ‘/u01/app/oracle/oradata/orcl/redo01A.log’ to group 1;

场景2：每个日志组中有两个在线日志，1号组的所有日志（redo01A.log和redo01B.log）丢失

一个日志组内所有日志丢失并不直接导致SQL命令无法执行，但是会因为无法完成归档导致LGWR不能覆盖日志，以至于日志缓冲被写满，所有的ddl\dml都无法执行

SQL> select event,seconds_in_wait from v$session where wait_class <>'Idle' order by 2 desc;

--log file switch (archiving needed)

在alter 日志中

ORA-00313

ORA-00312

ORA-27037

修复此类问题使用alter database clear unarchived logfile，同样要求被clear的日志应该处于inactive状态

SQL> alter database clear unarchived logfile group 1; ##切记归档日志会消失一组，应立即全备

SQL> select sequence#,name from v$archived_log;

上述两个场景中， 数据库都没有必要关闭或重启，切记处理在线日志丢失或损坏的问题时不加分析就将数据库关闭，这样做将会导致不必要的不完全恢复。

补充场景：启动数据库时发现所有控制文件和test01.dbf数据文件一并丢失，数据库报错ORA-00205

SQL> startup force;

ORA-00205: error in identifying control file, check alert log for more info

现在情况：没有使用catalog、控制文件没有任何形式的备份（快照也不在）、test01.dbf的备份在备份集bol_fullbak0du7i4id_1_1_20190725中、所有日志（归档和在线）健康

经过粗略的分析，可能会得出以下回复步骤

--1 既然控制文件没有备份就用create controlfile重建

--2 test01.dbf文件可以从备份集还原

--3 然后用recover恢复整个数据库

--4 最后打开数据库

可以在实际操作时create controlfile报错

SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  ARCHIVELOG

ORA-01503：CREATE CONTROLFILE failed

ORA-01565: error in identifying file /u01/app/oracle/oradata/orcl/test01.dbf

ORA-27037: unable to obtain file status

在create controlfile要求datafile子句中的所有文件必须存在，错误ORA-01565表示找不到数据文件，无法创建控制文件。

先从备份集还原数据文件这样就能重建控制文件了，求助RMAN

RMAN> restore datafile 5 from ‘bol_fullbak0du7i4id_1_1_20190725’;

ORA-01507: database not mounted

RMAN报错数据库没有mount，其原因是RMAN资料库无法访问，如果有catalog

$ rman target / catalog rcowner/oracle@oid

RMAN> restore datafile 5;

可惜没有使用catalog。

创建控制文件时报数据文件不存在，从备份集中还原数据文件报错控制文件不在无法mount数据库。

利用RMAN功能包--dbms_backup_restore就能够在nomount状态，且无catalog的情况下从备份片中提取输入文件。

但因oracle不提供该pl/sql包的文档，就要google充分研究dbms_backup_restore的使用案例

declare

device varchar2(100);

done_out boolean;

outhandle_out varchar2(100);

outtag_out varchar2(100);

failover_out boolean;

begin

sys.dbms_backup_restore.restoresetdatafile;

sys.dbms_backup_resotre.restoredatafileto(

 dfnumber =>5,

 toname => '/u01/app/oracle/oradata/orcl/test01.dbf');

device := sys.dbms_backup_restore.deviceallocate;

sys.dbms_backup_restore.restoresetpiece(

 handle => '/home/oracle/backup/bol_fullbak0du7i4id_1_1_20190725',

 tag => 'BOL_FULLBAK',

 fromdiak => true,

 recid =>0,

 stamp =>0);

sys.dbms_backup_restore.restorebackuppiece(

 done =>done_out,

 params =>null,

 outhandle =>outhandle_out,

 outtag =>outtag_out,

 failover =>failover_out);

 end;

 /

第8行启动了RMAN的还原会话，第9行指定了被还原的数据文件编号和路径

第12行分配默认的disk通道，第13行指定还原所使用的备份片

第19行执行了还原操作，该操作执行后test01.dbf回归，就可以创建控制文件了

SQL> CREATE CONTROLFILE ...

后面的恢复就可以参考前面的几篇