ORA-279 signalled during: alter database recover logfile

在RMAN的RECOVER还原过程中,RMAN界面正常,但是检查、刷新告警日志,发现告警日志里面有ORA-279,如下所示:

alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16228_g6oznpbv_.arc‘
Thu Feb 21 08:49:48 CST 2019

Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16228_g6oznpbv_.arc

Thu Feb 21 08:50:58 CST 2019

ORA-279 signalled during: alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16228_g6oznpbv_.arc‘...

Thu Feb 21 08:50:59 CST 2019

alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16229_g6ozp2pv_.arc‘

Thu Feb 21 08:50:59 CST 2019

Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16229_g6ozp2pv_.arc

Thu Feb 21 08:51:12 CST 2019

ORA-279 signalled during: alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16229_g6ozp2pv_.arc‘...

Thu Feb 21 08:51:12 CST 2019

alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16230_g6ozrswb_.arc‘

Thu Feb 21 08:51:12 CST 2019

Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16230_g6ozrswb_.arc

Thu Feb 21 08:51:39 CST 2019

ORA-279 signalled during: alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16230_g6ozrswb_.arc‘...

Thu Feb 21 08:51:39 CST 2019

alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16231_g6ozsj8q_.arc‘

Thu Feb 21 08:51:39 CST 2019

Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16231_g6ozsj8q_.arc

Thu Feb 21 08:51:54 CST 2019

ORA-279 signalled during: alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16231_g6ozsj8q_.arc‘...

Thu Feb 21 08:51:54 CST 2019

alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16232_g6ozt53s_.arc‘

Thu Feb 21 08:51:54 CST 2019

Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16232_g6ozt53s_.arc

Thu Feb 21 08:52:13 CST 2019

ORA-279 signalled during: alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16232_g6ozt53s_.arc‘...

Thu Feb 21 08:52:13 CST 2019

alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16233_g6p6ojcz_.arc‘

Thu Feb 21 08:52:13 CST 2019

Media Recovery Log /u06/archivelog/2019_02_19/o1_mf_1_16233_g6p6ojcz_.arc

Thu Feb 21 08:52:46 CST 2019

ORA-279 signalled during: alter database recover logfile ‘/u06/archivelog/2019_02_19/o1_mf_1_16233_g6p6ojcz_.arc‘...

Thu Feb 21 08:52:46 CST 2019

alter database recover cancel

Thu Feb 21 08:52:46 CST 2019

Media Recovery Canceled

Completed: alter database recover cancel

其实这个场景下,告警日志中ORA-279更像是“输出消息”, 而不是“错误信息”,它是在提示需要请求的归档日志才能继续恢复。以前在使用RMAN进行RECOVER时没有留意过这个细节信息。顺便记录一下。以免初次遇到这个提示信息的时候,还以为出现了什么异常或错误。

[root@DB-Server  2019_02_16]$ oerr ora 279

00279, 00000, "change %s generated at %s needed for thread %s"

// *Cause: The requested log is required to proceed with recovery.

// *Action:  Please supply the requested log with "ALTER DATABASE RECOVER

//           LOGFILE <file_name>" or cancel recovery with "ALTER DATABASE

//           RECOVER CANCEL".

Yes, you can ignore the ORA-279s. Treat them as "messages" rather then "errors".

You need to ensure that all archivelogs are being applied by the recovery process.

参考资料:

https://community.oracle.com/thread/638113

原文地址:https://www.cnblogs.com/kerrycode/p/10455520.html

时间: 2024-10-16 14:48:37

ORA-279 signalled during: alter database recover logfile的相关文章

Oracle DG故障诊断一则:alter database recover to logical standby new_logical_dbname卡住

我们在基于物理standby的基础上搭建逻辑备库过程过程中,在运行: alter database recover to logical standby READDB; 卡住不动,而且alert也没有报错信息,无比郁闷,咨询了别人,聊天记录例如以下: 我们的业务是passport应用,无法停止或者停掉很麻烦,总之,药不能停. 经过摸索,我们得到一个经验:须要等到MRP应用日志到跟主库一致,此时运行该命令才不会hang住. 详细流程大概是这种: 1. 开启实时日志应用 ALTER DATABASE

alter database open resetlogs时 alert的输出

SQL> alter database open resetlogs; Database altered. 时的提示: ORA-279 signalled during: ALTER DATABASE RECOVER  datafile 5  ... ALTER DATABASE RECOVER    CANCEL Media Recovery Canceled Completed: ALTER DATABASE RECOVER    CANCEL Sat Apr 18 18:41:33 201

丢失全部控制文件,noresetlogs重建控制文件,alter database open

測试2: (1)一致性的全备 SQL> shutdown immediate; $ cp -rf $ORACLE_BASE/oradata/boss/*.dbf /oradata/bossbak/20140610allbackup $ cp -rf $ORACLE_BASE/oradata/boss/*.log /oradata/bossbak/20140610allbackup $ cp -rf $ORACLE_BASE/oradata/boss/*.ctl /oradata/bossbak/

丢失所有控制文件,noresetlogs重建控制文件,alter database open

测试2: (1)一致性的全备 SQL> shutdown immediate; $ cp -rf $ORACLE_BASE/oradata/boss/*.dbf /oradata/bossbak/20140610allbackup $ cp -rf $ORACLE_BASE/oradata/boss/*.log /oradata/bossbak/20140610allbackup $ cp -rf $ORACLE_BASE/oradata/boss/*.ctl /oradata/bossbak/

[Hive - LanguageManual] Create/Drop/Alter Database Create/Drop/Truncate Table

Hive Data Definition Language Hive Data Definition Language Overview Create/Drop/Alter Database Create/Drop/Truncate Table Alter Table/Partition/Column Create/Drop/Alter View Create/Drop/Alter Index Create/Drop Function Create/Drop/Grant/Revoke Roles

alter database open resetlogs

使用resetlogs选项,会把当前的日志序号(log sequence number)重设为1,并抛弃所有日志信息.在以下条件时需要使用resetlogs选项: 在不完全恢复(介质恢复): 使用备份控制文件. 使用resetlogs打开数据库后,务必要完整地进行一次数据库备份. 不完全恢复只能做一次吗? 采用rman的默认设置,对数据库进行了backup database备份,进行了一些操作后,然后直接关闭启动到mount状态 RMAN> run{ 2> set until time &qu

backup, file manipulation operations (such as ALTER DATABASE ADD FILE) and encryption changes on a database must be serialized.

昨天在检查YourSQLDba备份时,发现有台数据库做备份时出现了下面错误信息,如下所示: <Exec>   <ctx>yMaint.ShrinkLog</ctx>   <inf>Log Shrink</inf>   <Sql> --  ======================================================================== -- Shrink of log file E:\SQ

不完全回复-alter database open resetlogs

先要弄清楚alter database open resetlogs是什么意思,为什么要用resetlogs打开数据库,这个命令发出后oracle都做了什么? alter database open resetlogs是要打开数据时,重置重做日志,即将重做日志的sequence置零,为什么要重置重做日志呢? 不完全恢复后,原来的online redo log里面包含的是未做恢复前的数据,而这些数据对于恢复后的数据库不再有效,所以数据库会要求在Open之前先对online redo log的seq

Use ALTER DATABASE to Move Databases

Follow Our Daily Tips •facebook.com/TechNetTips• twitter.com/TechNetTips• blogs.technet.com/tnmag• TechNet Tips library You can use the ALTER DATABASE statement to move any system or user-defined database files except for Resource database files.To m