如何恢复日志文件

为了防止数据库日志文件本身的故障或丢失，Oracle强烈建议使用镜像日志(mirrored redo log)，如果LGWR跟踪文件或者ALERT文件中的消息表LGWR，经常不得不因为检查点尚未完成或者组尚未归档而等待，就需要添加组。

添加联机重做日志组

语法：
ALTER DATABASE [database]
ADD LOGFILE [GROUP integer] filespec
[, [GROUP integer] filespec]...]
可以通过文件说明来指定成员名称和位置可以选择每个重做日志文件组GROUP 参数值。如果省略了该参数，Oracle服务器将自动生成其值。

添加重做日志成员

使用下面的ALTER DATABASE ADD LOGFILE MEMBER 命令向现有的重做日志文件组添加新成员
ALTER DATABASE [database]
ADD LOGFILE MEMBER
[ 'filename' [REUSE]
[, 'filename' [REUSE]]...
TO {GROUP integer
|('filename'[, 'filename']...)
}
]

重新定位或者重命名联机重做日志文件

语法：
ALTER DATABASE [database]
RENAME FILE 'filename'[, 'filename']...
tO 'filename'[, 'filename']...
注意：
这个命令仅仅是修改了控制文件中的日志文件的信息，并没有真实的移动日志文件的位置，所以需要手工用操作系统命令移动日志文件的位置。

删除不要的日志文件组

语法：
ALTER DATABASE [database]
DROP LOGFILE
{GROUP integer|('filename'[, 'filename']...)}
[,{GROUP integer|('filename'[, 'filename']...)}]...
注意：
一个例程至少需要两组联机重做日志文件；
无法删除活动组或者当前组；
如果数据库运行在ARCHIVELOG 模式下并且未将日志文件组归档那么无法删除该组；
在删除联机重做日志组时并没有删除操作系统文件，所以需要手工用操作系统命令删除日志文件。

删除日志文件

当一个联机重做日志成员状态为INVALID的时候，如果想丢弃一个或者多个联机日志成员，使用命令：
ALTER DATABASE [database]
DROP LOGFILE MEMBER 'filename'[, 'filename']...
注意：
不能删除组内的最后一个有效成员
不能删除当前组，所以在删除该成员之前必须强制日志文件切换
如果数据库正运行在ARCHIVELOG 模式下并且未将该成员所属日志文件组归档否则无法删除该成员
在删除联机重做日志成员时并未删除操作系统文件，所以还需要手工用操作系统命令完成实际的删除文件的工作

清除联机日志组

如果一个联机日志文件组的所有成员都已破坏，可以通过重新初始化这些日志文件来解决问题。
语法：
ALTER DATABASE [database]
CLEAR [UNARCHIVED] LOGFILE
{GROUP integer|('filename'[, 'filename']...)}
[,{GROUP integer|('filename'[, 'filename']...)}]...
注意：
无论联机重做日志文件是否归档，都可以清除它。但是，在其没有归档时，您必须包含关键字UNARCHIVED。如果恢复需要该联机重做日志文件，这将使得备份不可用。

查询v$log获得联机
重做日志文件组的信息

下面的项是v$log视图中STATUS 列的常见值：
UNUSED  表明从未对联机重做日志组进行写入，这是刚添加的联机重做日志文件的状态。
CURRENT  表明当前的联机重做日志组，这意味着该联机重做日志组是活动的。
ACTIVE  表明联机重做日志组是活动的，但是并非当前联机重做日志组，崩溃恢复需要该状态它可能正用于块恢复，它可能归档也可能不归档。
CLEARING  表明在ALTER DATABASE CLEAR LOGFILE 命令后正在将该日志重建为一个空日志，日志清除后其状态更改为UNUSED。
CLEARING_CURRENT  表明正在清除当前日志文件中的已关闭线程，如果切换时发生某些故障，如写入新日志标题时的I/O错误，则该日志可以停留在该状态。
INACTIVE  表明例程恢复不再需要联机重做日志组，它可能归档也可能不归档。

查询V$LOGFILE获取日志成员信息

下面的项是v$logfile 视图中STATUS 列的常见值：
INVALID  表明该文件不可访问。
STALE  表明该文件内容不完全，例如正在添加一个日志文件成员。
DELETED  表明该文件已不再使用。
空白表明文件正在使用中。

常见故障处理

如果LGWR 至少能够访问一个组内成员，对组内可访问成员的写入将照常进行，LGWR 忽略组内的不可用成员。如果该组不活动，即检查点已完成，那么丢弃和添加一个新的联机日志成员就可以解决问题，否则如果该组是当前活动的日志组，则必须首先强制日志切换。
SQL> SELECT group#, sequence#, bytes, members, status
  2  FROM V$LOG;
    GROUP#  SEQUENCE#      BYTES    MEMBERS STATUS
----------------------------------
         1        411    1048576          2 INACTIVE
         2        412    1048576          2 INACTIVE
         3        413    1048576          2 INACTIVE
         5        414    1048576          2 CURRENT
SQL> select * from  v$logfile;
    GROUP# STATUS  MEMBER
----------------------------------
。。。。。。(其他日志文件)。。。。。。。。。       
         5 INVALID E:/ORACLE1/ORA81/ORADATA/TEST/REDO07.LOG
         5         E:/ORACLE1/ORA81/ORADATA/TEST/REDO08.LOG
8 rows selected
SQL>
但是这时候数据还可以忽略这个损坏的文件而正常使用。要修复这个文件，我们需要做：
SQL> shutdown
SQL> host
E:/>COPY E:/ORACLE1/ORA81/ORADATA/TEST/REDO08.LOG E:/ORACLE1/ORA81/ORADATA/TEST/
REDO07.LOG
改写 E:/ORACLE1/ORA81/ORADATA/TEST/REDO07.LOG 吗? (Yes/No/All): YES
已复制 1 个文件。
上面这一步需要注意的是，如果新的日志文件的位置或文件名称需要改变（如，介质失效），则在数据库加载（Startup Mount）后需要对这个改变位置或名称的日志文件重命名，然后再打开数据，具体过程参见“重新定位或者重命名联机重做日志文件”。
E:/>exit
SQL> select * from  v$logfile;
    GROUP# STATUS  MEMBER
----------------------------------
。。。。。。(其他日志文件)。。。。。。。。。
         5 UNKNOWN E:/ORACLE1/ORA81/ORADATA/TEST/REDO07.LOG
         5 STALE   E:/ORACLE1/ORA81/ORADATA/TEST/REDO08.LOG
8 rows selected
我们看到该日志文件的状态为UNKNOWN；表示是刚添加的联机重做日志文件的状态。等到数据库在使用完该文件或者手工用命令：alter system switch logfile强制数据库发生log switch以后，文件的状态就会显示为空白，即，正常状态。
注意：在恢复了数据库以后，立刻完全关闭数据（Normal），进行一个冷备份。
上面关于日志文件损坏和修复的相关部分会被记录在Alert.log文件中。
如果在日志切换时LGWR 无法访问下一个组的所有成员或者损坏的日志文件时该组中日志成员，则该实例关闭。如果组不活动，那么丢弃和添加一个新的日志组就可解决问题；如果活动，数据库可能需要从联机重做日志文件残留物进行介质恢复。
为了模拟日志组中有一个成员损坏的情况，我们打开文本编辑器，并且破坏E:/ORACLE1/ORA81/ORADATA/TEST/ REDO07.LOG文件，然后，我们看到：
SQL> ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM SWITCH LOGFILE
ORA-00313: 无法打开日志组  (线程 ) 的成员
SQL> STARTUP MOUNT
SQL> ALTER DATABASE
2  DROP LOGFILE GROUP 5;
数据库已更改。
SQL> ALTER DATABASE OPEN;
数据库已更改。
现在一切正常了，则完全关闭数据（Normal），进行一个冷备份。
上面关于日志文件损坏和修复的相关部分会被记录在Alert.log文件中。
在归档模式下，我们需要用alter database clear logfile group来恢复数据库：
现在GROUP 4中只有一个MEMBER，并且不是CURRENT，我们损坏这个GROUP（F:/ORACLE1/ORA81/ORADATA/TEST/REDO07.LOG），然后，当SWITCH到这个损坏的组以后，数据库会HANG，或者严重的话会CRASH，这时候我们可能收到下面的错误：
SQL> ALTER　DATABASE　CLEAR　LOGFILE
  2  'F:/oracle1/ora81/oradata/test/REDO07.LOG';
ALTER　DATABASE　CLEAR　LOGFILE
*
ERROR 位于第 1 行:
ORA-12571: TNS:packet writer failure
SQL> conn intenral@test
请输入口令:
ERROR：
ORA-01092: ORACLE instance terminated. Disconnection forced
SQL>
这时候，我们可以退出SQLPLUS，然后重新进来：
SQL> exit
E:/>sqlplus internal
进来后，shutdown abort数据库，然后，再startup mount：
SQL> shutdown abort
SQL> startup mount
可以看到，数据库没有CRASH。现在我们CLEAR GROUP4，先用alter database clear logfile group 4;（如果不行就用alter database clear unarchived logfile group 4;）：
SQL> alter database clear logfile group 4;
数据库已更改。
SQL> alter database open;
数据库已更改。
SQL>
好了，数据库已经恢复了
如果正在写入当前组的所有成员时，LGWR 突然无法访问这些成员，则该数据库例程关闭，在这种情况下，数据库可能需要从联机日志文件残留物进行介质恢复。
确定GROUP4是CURRENT，现在毁坏GROUP4。当你发现这个错误：
SQL> alter database open;
alter database open
*
ERROR 位于第 1 行:
ORA-00313: ??????? 4 (?? 1) ???
ORA-00312: ???? 4 ?? 1: 'F:/ORACLE1/ORA81/ORADATA/TEST/REDO07.LOG'
SQL>
那么，然后SHUTDOWN，并且MOUNT数据库：
SQL> shutdown
ORA-01109: ??????
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
恢复数据库：
SQL>  recover database until cancel;
完成介质恢复。
SQL> alter database open resetlogs;
数据库已更改。
以前的ARCHIVE 已经不可用了，需要SHUTDOW，然后作一个FULL BACKUP，之后，再重新STARTUP数据库，就可以了.