ORA-279 signalled during: alter database recover logfile

最新推荐文章于 2022-07-07 18:09:36 发布
最新推荐文章于 2022-07-07 18:09:36 发布
阅读量674 收藏
点赞数
原文链接：http://www.cnblogs.com/kerrycode/p/10455520.html
版权

 

在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

oracle recover datafile,recover datafile和alter database recover datafile；
weixin_34223525的博客
04-03 2029
recover datafile和alter database recover datafile；。alter database recover datafile：当恢复需要在线的日志文件的时候，恢复会自动进行；当恢复需要归档的日志文件的时候，数据库会提示警告，不会自动的进行，数据库处于media recovery状态，可以使用alter database recover logfile；。rec...
记一次异常断电导致ora-600、ORA-25153的处理经过
shilukun的博客
10-25 484
朋友突然联系我说，他们项目的数据库宕机起不来了，报错全是600，请我帮他处理下，现在记录处理过程如下： 首先看下报错日志： alter database mount ORA-1100 signalled during: alter database mount ... Fri Oct 25 08:53:37 2019 alter database open Beginning crash ...
ORA-279 standby指定时间恢复时遇到报错解决
weixin_30340745的博客
04-26 473
环境 rac+双standbystandbystandby2按时间恢复报找不到归档Media Recovery Log /home/oracle/oradata/rac/archive/3_59241_681301512.arcErrors with log /home/oracle/oradata/rac/archive/3_59241_681301512.arcORA-279 signalle...
断电oracle 00279,停机一致性备份 - Oracle备份与恢复系列_数据库技术_Linux公社-Linux系统门户网站...
weixin_35607383的博客
04-06 515
关闭数据库的备份与恢复关闭数据库备份原理很简单，就像我们备份照片、备份word文档一样。复制一份原文件并放置在其它位置备用，如果磁盘空间紧张通常会复制到移动硬盘或网盘上。当原文件损坏时，将备份再复制回来就可以了。当然数据库有自己的备份专属地，磁带库，而不会备份到移动硬盘上。本次试验分为以下步骤1，创建备份脚本2，运行备份脚本3，删除数据文件4，运行还原脚本5，打开数据库6，确认数据库还原在其它窗口...
数据文件丢失, 没有备份, 拥有文件创建以来的全部归档, 'Alter Database recover datafile ' Fails with ORA-279...
cuibiaoyan1920的博客
04-14 444
数据文件丢失, 没有备份, 拥有文件创建以来的全部归档,使用RMAN恢复, 报错RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 726...
存储重启,oracle无法启动故障处理----惜分飞
07-07 1867
有客户由于机房要停电,正常关闭两个节点数据库，数据库无法正常启动案例处理
ORA-16433: The database must be opened in read/write mode.
S1156578253的博客
07-27 3788
今天上午刚回到公司，接到开发组同事电话，测试数据库主机被新来的小伙非正常关机了，现在数据库起不来了。 数据库open时，提示需要介质恢复，恢复时就会报ORA-16433错误。 SQL> alter database open; alter database open * ERROR at line 1: ORA-01113: file 1 needs media recovery ORA-01110: data file 1: '/u01/oradata/orcl/system01.dbf'
ORA-38500 USING CURRENT LOGFILE option not available withou
ffuygggh的博客
02-11 517
ORA-38500 USING CURRENT LOGFILE option not available withou
ora-01092: oracle 实例终止.强制断开连接,undo表空间故障特殊恢复（二）------ORA-01092: ORACLE 实例终止。强制断开连接...
weixin_42652674的博客
04-06 1844
原文出处：http://blog.csdn.net/wyzxg/archive/2010/09/10/5874726.aspxundo表空间故障特殊恢复(二)------ORA-01092: ORACLE 实例终止。强制断开连接这个测试的是instance recover(单实例里就是crash recovery)的恢复需要故障undo里的数据，一般的情况instance recover使用联机日...
ora-01113 oracle8i,分享一次ORA-01113 ORA-01110故障处理过程
weixin_36155560的博客
04-03 677
近期编写了小工具,对于此类问题,可以实现一键恢复,参考:一键恢复ORA-01113 ORA-01110—Oracle Recovery Tools数据库报ORA-01113 ORA-01110无法正常openSQL> alter database open;alter database open*ERROR at line 1:ORA-01113: file 1 needs media re...
oracle执行成功以后需要comit,oracle恢复完成后报错
weixin_34342091的博客
04-15 288
各位前辈好，小弟碰到一个这样的问题，急急急，就是数据库recover完毕，在alert日志已经提示完成，如下：hncrm1app4:/oracle/app/admin/pild/bdump$>tail -f alert_pild.logORA-279 signalled during: alter database recover logfile '/usr/test/arc_1_5562_...
Oracle BBED单个数据文件跳过丢失的归档继续恢复(一)
dbhang的博客
10-09 506
场景描述：       数据库利用备份进行恢复时，需要执行restore+recover，restore利用备份片恢复数据文件，recover是进行归档日志应用到最新状态，当我们归档日志断档丢失时，可以利用bbed跳过丢失的归档日志，继续恢复下去，在生产环境中bbed是极其危险的操作，谨慎使用，本次测试是单个数据文件测试。 环境构建： SQL> archive log list; Database log mode
oracle数据库重建数据文件,Oracle Study之案例--重建数据库控制文件
weixin_30847063的博客
04-05 606
系统环境：操作系统： Linux RH6数据库： Oracle 11gR2案例分析：Oracle数据库中所有的控制文件被意外破坏，非归档的库，在有trace备份的情况下，重建控制文件。1、控制文件trace脚本[oracle@rh6 ~]$ cat crctr.sqlCREATE CONTROLFILE REUSE DATABASE "TEST3" NORESETLOGS NOARCHIVE...
DG知识点记录
weixin_43475880的博客
07-19 2521
搭建操作 alter databaes recover managed standby database disconnect from session 此时备库是归档日志传输，所以需要在主库进行alter system switch logfile 若再执行一次alter database recover managed standby database disconnect from session.此时数据库的状态为read only with apply.主库传输文件时只需要commit就可以.
resetlog oracle,用RMAN的全备恢复resetlog之前的数据
weixin_39943442的博客
04-10 386
OS：win2000 server DB:92010现状：从RMAN全备份完成的那个时刻起到resetlogs之前这个时间段的归档全部丢失。所有数据文件丢失。目的：将数据库恢复到RMAN全备份完成的那个时刻。步骤：1.从rman无法restore数据文件。虽然list backup可以显示备份集，但是已经没有办法再进行恢复了，错误为RMAN-06026RMAN> restore data...
Oracle 备份与恢复学习笔记（6_2）
weixin_33842328的博客
11-15 93
第六章： 手工不完全恢复 案例3： ---------在做完全恢复时，丢失了部分归档日志 1）基于cancel 的不完全恢复 -------模拟环境 06:01:59 SQL> select table_name,tablespace_name from user_tables;...
Oracle Rman 数据库的不完全恢复
cuantangnie3915的博客
01-19 260
前提条件： 1、数据库运行在归档模式； 2、必须有要恢复时间点前的所有数据文件备份和在恢复时间点和数据文件备份时刻之间的所有归档日志。 下面的恢复假设如下条件： 1、恢复使用当前的 incarnation； ...
丢失全部控制文件后从RMAN备份集中恢复示例
还不算晕的专栏
10-27 4908
丢失全部控制文件 后用RMAN恢复的大致步骤可以写为： startup nomount; restore controlfile from autobackup;或者指定的有控制文件 备份的备份集 alter  database mount; recover  database;  alter  database open resetlogs; 1.先备份当前控制文件 [
在oracle下我们如何正确的执行数据库恢复
weixin_33958585的博客
02-20 156
当数据库需要进行介质恢复时，为了确保数据库能够顺利的执行恢复过程，恢复数据库到当前状态。我们要做的就是验证！验证什么呢？当然是验证备份集和归档是否能够进行有效的恢复。防止我们restore后，执行recover时却发现归档缺少了一堆，顿时傻眼。比方说，在数据库当前日志序列号为3时我们完全备份了数据库。在数据库当前联机日志序列号为13时数据库损坏需要恢复。假设数据库联机日志组为3组，则可以推断数据库...
ALTER DATABASE MOUNT ORA-59 signalled during: ALTER DATABASE MOUNT...
最新发布
03-13
<think>好的，我现在需要处理用户关于在Oracle数据库中执行ALTER DATABASE MOUNT时遇到ORA-00659错误的问题。首先，我需要回忆一下ORA-00659错误的常见原因。这个错误通常与控制文件相关，比如控制文件无法访问、损坏或者配置不正确。 用户之前已经询问过在创建SPFILE后无法挂载数据库的问题，现在又遇到了具体的错误代码，所以我应该结合之前的回答，进一步细化解决方案。首先，我需要确认用户是否按照之前的步骤检查过警报日志，因为警报日志中的详细信息是诊断问题的关键。 接下来，用户提到错误发生在执行ALTER DATABASE MOUNT时，这可能意味着实例已经启动到NOMOUNT状态，但挂载数据库时失败。这时候控制文件的问题可能性最大。我需要考虑控制文件的路径是否正确，权限是否足够，文件是否存在，或者是否损坏。 另外，用户之前执行了CREATE SPFILE FROM MEMORY，可能导致参数文件中的控制文件路径不正确，或者内存中的参数与控制文件的实际位置不匹配。因此，可能需要检查SPFILE中的control_files参数是否正确，是否指向了有效的控制文件。 还可能存在的情况是控制文件本身损坏，或者存储控制文件的磁盘空间不足，或者权限问题导致Oracle进程无法访问这些文件。此外，如果控制文件是镜像的，可能部分副本损坏，而Oracle尝试访问这些损坏的副本。 我需要建议用户检查警报日志，确认具体的错误信息，然后根据日志中的提示进行相应的处理。比如，如果日志显示无法找到控制文件，则需要验证control_files参数的值，并确保文件存在。如果文件存在但权限不对，需要调整权限。如果是控制文件损坏，可能需要从备份恢复，或者重建控制文件。 此外，用户可能需要使用PFILE启动实例，绕过SPFILE，以排除参数文件的问题。如果通过PFILE能够成功挂载数据库，那么问题可能出在SPFILE的参数配置上，需要重新生成SPFILE。 如果控制文件全部丢失且没有备份，用户可能需要通过CREATE CONTROLFILE命令重建控制文件，这需要用户了解数据库的结构，如数据文件、日志文件的位置等信息，因此在操作前需要确保这些信息是可用的。 最后，需要提醒用户在进行任何修复操作前备份现有文件，避免数据丢失，并建议在操作困难时联系Oracle支持。</think>以下是针对 **ORA-00659** 错误（在执行 `ALTER DATABASE MOUNT` 时触发）的逐步解决方案： --- ### **1. 错误背景分析** - **ORA-00659** 表示数据库无法找到或访问控制文件（Control File）。常见原因包括： - 控制文件路径配置错误（`control_files` 参数不正确）。 - 控制文件被删除、损坏或权限不足。 - 存储控制文件的磁盘空间不足或I/O故障。 --- ### **2. 检查警报日志 (Alert Log)** - **步骤**： 1. 定位警报日志路径： ```sql SELECT value FROM v$diag_info WHERE name = 'Diag Trace'; ``` 文件名为 `alert_<SID>.log`。 2. 搜索 `ORA-00659` 相关条目，确认具体错误描述（例如找不到文件、权限拒绝等）。 --- ### **3. 验证控制文件路径** - **关键操作**： 1. 检查当前参数 `control_files` 配置： ```sql SHOW PARAMETER control_files; ``` 2. 确认操作系统路径是否存在且权限正确： ```bash # 示例：检查控制文件是否存在及权限 ls -l /u01/app/oracle/oradata/ORCL/control01.ctl ``` 3. **权限修复**（如有必要）： ```bash chown oracle:dba /path/to/controlfile.ctl chmod 660 /path/to/controlfile.ctl ``` --- ### **4. 尝试通过PFILE启动** - **适用场景**：SPFILE参数错误导致路径配置异常。 - **步骤**： 1. 创建PFILE（若已有SPFILE）： ```sql CREATE PFILE='/tmp/init_temp.ora' FROM SPFILE; ``` 2. 手动编辑PFILE，修正 `control_files` 路径为实际有效路径。 3. 使用PFILE启动到 `NOMOUNT` 状态： ```sql STARTUP NOMOUNT PFILE='/tmp/init_temp.ora'; ``` 4. 尝试挂载数据库： ```sql ALTER DATABASE MOUNT; ``` --- ### **5. 恢复控制文件** - **场景**：控制文件丢失或损坏。 - **情况1：存在有效备份** 从RMAN备份恢复控制文件： ```sql RMAN> RESTORE CONTROLFILE FROM '/backup/controlfile.bkp'; RMAN> ALTER DATABASE MOUNT; ``` - **情况2：无备份但数据库未崩溃** 通过其他副本恢复（若配置了多路复用）： ```bash cp /path/to/controlfile_copy.ctl /path/to/missing_controlfile.ctl ``` - **情况3：无备份且所有控制文件丢失** 必须重建控制文件（需提前记录数据库结构）： ```sql CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 292 LOGFILE GROUP 1 '/u01/app/oracle/oradata/ORCL/redo01.log' SIZE 50M, GROUP 2 '/u01/app/oracle/oradata/ORCL/redo02.log' SIZE 50M DATAFILE '/u01/app/oracle/oradata/ORCL/system01.dbf', '/u01/app/oracle/oradata/ORCL/sysaux01.dbf' CHARACTER SET AL32UTF8; ``` --- ### **6. 检查存储状态** - **可能问题**：磁盘空间不足或硬件故障。 - 检查控制文件所在磁盘空间： ```bash df -h /path/to/controlfile_directory ``` - 检查I/O错误日志（操作系统级）： ```bash dmesg | grep -i error ``` --- ### **7. 重建SPFILE（若参数修正有效）** - **步骤**： 1. 若通过PFILE成功挂载数据库，重新生成SPFILE： ```sql CREATE SPFILE FROM PFILE='/tmp/init_temp.ora'; ``` 2. 重启数据库验证： ```sql SHUTDOWN IMMEDIATE; STARTUP; ``` --- ### **注意事项** - **备份优先**：操作前备份所有控制文件及参数文件。 - **多路复用控制文件**：建议至少配置2个控制文件副本，避免单点故障。 - **日志分析**：警报日志中的时间戳和错误链是诊断关键。 若仍无法解决，请提供警报日志中的完整错误上下文或联系Oracle支持。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值