在归档模式下,如果系统无法顺利完成归档,当日志切换时,即将被复写的redo日 志没有完成归档,日志切换动作将无法完成。
模拟一下这个故障场景,给出两种一般的处理方法。
1.模拟无法归档及redo日志无法切换故障
1)修改与归档相关的参数
sys@secooler> alter system set log_archive_format='%t_%s_%r.arch' scope=spfile;
System altered.
sys@secooler> show parameter db_recovery_file_dest
NAME TYPE VALUE
--------------------------- ------------ --------------------------------------
db_recovery_file_dest string /oracle/ora11gR2/flash_recovery_area
db_recovery_file_dest_size big integer 4G
sys@secooler> alter system set db_recovery_file_dest='' scope=spfile;
System altered.
sys@secooler> alter system set log_archive_dest_1='location=/archivelog' scope=spfile;
System altered.
2)重新启动数据库使参数修改生效
sys@secooler> shutdown immediate;
sys@secooler> startup;
3)修改“/archivelog”目录的属性,模拟归档无法完成
secooler@secDB /oracle/ora11gR2/oradata$ su - root
Password:
[root@secDB ~]# chown -R root:root /archivelog/
4)此时尝试归档
sys@secooler> alter system archive log current;
alter system archive log current
*
ERROR at line 1:
ORA-16014: log 2 sequence# 131 not archived, no available destinations
ORA-00312: online log 2 thread 1: '/oracle/ora11gR2/oradata/secooler/redo02.log'
模拟的现象已经出现,此时系统无法完成归档。
5)尝试切换日志
sys@secooler> alter system switch logfile;
此时系统将长时间处于hang住 的状态。
2.故障处理方法一
既然是我们模拟的故障,处理这个故障的终极方法当然是将 “/archivelog”目录的权限属性归还给oracle用户。
3.故障处理方法二
使用极端的clear日志方法“临时”处理这个问题。
1)单独开启一个session来查看当前日志组状态
sys@secooler> select GROUP#,THREAD#,MEMBERS,ARCHIVED,STATUS from v$log;
GROUP# THREAD# MEMBERS ARC STATUS
---------- ---------- ---------- --- ----------------
1 1 1 NO CURRENT
2 1 1 NO INACTIVE
3 1 1 NO INACTIVE
可见,此时日志即将切换到第2组日志。
2)使用clear unarchived logfile命令清除即将覆盖的日志组
sys@secooler> alter database clear unarchived logfile group 2;
Database altered.
3)此时无法切换日志的问题已经被临时处理完毕
回到无法完成切换的窗口,查看命令执行状态,此时已经可以顺利切换。
sys@secooler> alter system switch logfile;
System altered.
4.小结
使用clear日志组的方法仅仅是权宜之计,在某些具体场景中可以考虑使用,但要充分理解这个动作背后对应的风险(比如恢复问题)。
当出现日志无法切换或归档无法完成时,最好从长计议,发现故障的真实原因,从源头上根除故障。
Good luck.
secooler
10.04.13
-- The End --
模拟一下这个故障场景,给出两种一般的处理方法。
1.模拟无法归档及redo日志无法切换故障
1)修改与归档相关的参数
sys@secooler> alter system set log_archive_format='%t_%s_%r.arch' scope=spfile;
System altered.
sys@secooler> show parameter db_recovery_file_dest
NAME TYPE VALUE
--------------------------- ------------ --------------------------------------
db_recovery_file_dest string /oracle/ora11gR2/flash_recovery_area
db_recovery_file_dest_size big integer 4G
sys@secooler> alter system set db_recovery_file_dest='' scope=spfile;
System altered.
sys@secooler> alter system set log_archive_dest_1='location=/archivelog' scope=spfile;
System altered.
2)重新启动数据库使参数修改生效
sys@secooler> shutdown immediate;
sys@secooler> startup;
3)修改“/archivelog”目录的属性,模拟归档无法完成
secooler@secDB /oracle/ora11gR2/oradata$ su - root
Password:
[root@secDB ~]# chown -R root:root /archivelog/
4)此时尝试归档
sys@secooler> alter system archive log current;
alter system archive log current
*
ERROR at line 1:
ORA-16014: log 2 sequence# 131 not archived, no available destinations
ORA-00312: online log 2 thread 1: '/oracle/ora11gR2/oradata/secooler/redo02.log'
模拟的现象已经出现,此时系统无法完成归档。
5)尝试切换日志
sys@secooler> alter system switch logfile;
此时系统将长时间处于hang住 的状态。
2.故障处理方法一
既然是我们模拟的故障,处理这个故障的终极方法当然是将 “/archivelog”目录的权限属性归还给oracle用户。
3.故障处理方法二
使用极端的clear日志方法“临时”处理这个问题。
1)单独开启一个session来查看当前日志组状态
sys@secooler> select GROUP#,THREAD#,MEMBERS,ARCHIVED,STATUS from v$log;
GROUP# THREAD# MEMBERS ARC STATUS
---------- ---------- ---------- --- ----------------
1 1 1 NO CURRENT
2 1 1 NO INACTIVE
3 1 1 NO INACTIVE
可见,此时日志即将切换到第2组日志。
2)使用clear unarchived logfile命令清除即将覆盖的日志组
sys@secooler> alter database clear unarchived logfile group 2;
Database altered.
3)此时无法切换日志的问题已经被临时处理完毕
回到无法完成切换的窗口,查看命令执行状态,此时已经可以顺利切换。
sys@secooler> alter system switch logfile;
System altered.
4.小结
使用clear日志组的方法仅仅是权宜之计,在某些具体场景中可以考虑使用,但要充分理解这个动作背后对应的风险(比如恢复问题)。
当出现日志无法切换或归档无法完成时,最好从长计议,发现故障的真实原因,从源头上根除故障。
Good luck.
secooler
10.04.13
-- The End --
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/519536/viewspace-659668/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/519536/viewspace-659668/