数据库ORA-01196故障-归档日志丢失恢复详解

问题:

由于机房停电,其中一DG备库无法open,启动时报错

启动数据库时报下面的错误

SQL> alter database open;
alter database open
*

第 1 行出现错误:

ORA-10458: standby database requiresrecovery
ORA-01196: 文件 1 由于介质恢复会话失败而不一致
ORA-01110: 数据文件 1:'+DATA/htdb7/datafile/system.313.884996245'

查看归档日志应用情况,发现一部分日志没应用

SQL> Select Name,Sequence#,applied,completion_time From v$archived_log Order By Sequence# Desc;
Name,                                                               Sequence# applied completion_time
+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328776.705.939567729   328776   YES  NO  2017/3/2515:02
+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328775.713.939567727   328775   YES  NO  2017/3/2515:02
+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328774.777.939567727   328774   YES  NO  2017/3/2515:02
+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328773.771.939567725   328773   YES  NO  2017/3/2515:02
+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328772.422.939567721   328772   YES  NO  2017/3/2515:02
+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328771.482.939567721   328771   YES  NO  2017/3/2515:02
+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328770.755.939567721   328770   YES  NO  2017/3/2515:02
+FRA/htdb7/archivelog/2017_03_24/thread_1_seq_328757.1255.939481573  328757   YES  NO  2017/3/2415:06
+FRA/htdb7/archivelog/2017_03_24/thread_1_seq_328756.795.939480431   328756   YES  YES  2017/3/2414:47
+FRA/htdb7/archivelog/2017_03_24/thread_1_seq_328755.543.939479395   328755   YES  YES  2017/3/2414:29
+FRA/htdb7/archivelog/2017_03_24/thread_1_seq_328754.390.939478683   328754   YES  YES  2017/3/2414:18
+FRA/htdb7/archivelog/2017_03_24/thread_1_seq_328753.1845.939477943  328753   YES  YES  2017/3/2414:05

--再和其它备库或主库的归档日志做对比,很明显发现这个备库没有同步并应用主库的日志
--此备库:
[oracle@hotel07 ~]$ asmcmd -p
ASMCMD [+fra/htdb7/ARCHIVELOG] > cd 2017_03_24/
ASMCMD [+fra/htdb7/ARCHIVELOG/2017_03_24]> ls
......
thread_1_seq_328754.390.939478683
thread_1_seq_328755.543.939479395
thread_1_seq_328756.795.939480431
thread_1_seq_328757.1255.939481573

--其它正常的备库
[oracle@hotel05 ~]$ asmcmd -p
ASMCMD [+fra/htdb5/ARCHIVELOG/2017_03_24]> ls
thread_1_seq_328754.4124.939478683
thread_1_seq_328755.349.939479395
thread_1_seq_328756.852.939480431
thread_1_seq_328757.1420.939481575
thread_1_seq_328758.3356.939510647
thread_1_seq_328759.4592.939510649
thread_1_seq_328760.3205.939510647
thread_1_seq_328761.5308.939510649
thread_1_seq_328762.5227.939510653
.....

解决办法:

需要从其它备库或主库上面把此备库缺失的归档日志手动传输过来,然后再进行open操作

步骤如下:

1. 在另一正常的备库用rman备份缺失的归档日志

[oracle@hotel05 ~]$ rman target /
RMAN> copy archivelog'+fra/htdb5/ARCHIVELOG/2017_03_24/thread_1_seq_328759.4592.939510649' to'/home/oracle/arcbak/thread_1_seq_328759.4592.939510649';

启动 backup 于 25-3月 -17

使用通道 ORA_DISK_1

通道 ORA_DISK_1: 正在开始复制归档日志

输入归档日志线程=1 序列=328759 RECID=328754 STAMP=939510652

输出文件名=/home/oracle/arcbak/thread_1_seq_328759.4592.939510649 RECID=328794STAMP=939571923

通道 ORA_DISK_1: 归档日志复制完成, 经过时间: 00:00:03

完成 backup 于 25-3月 -17
......

. 备份完成后,把归档传输到丢失归档的备库
[oracle@hotel05 arcbak]$ scp * hotel07:/home/oracle/arcbak/

3. 然后在此备库上进行恢复操作

-- 编制归档文件目录
[oracle@hotel07 ~]$ rman target /

恢复管理器: Release 11.2.0.2.0 - Production on 星期六 3月 25 15:42:112017
Copyright (c) 1982, 2009, Oracle and/or itsaffiliates.  All rights reserved.
已连接到目标数据库: HTDB4 (DBID=1083719948, 未打开)

RMAN> catalog start with '/home/oracle/arcbak';

搜索与样式 /home/oracle/arcbak 匹配的所有文件

数据库未知文件的列表
=====================================
文件名: /home/oracle/arcbak/thread_1_seq_328763.4773.939510653
文件名: /home/oracle/arcbak/thread_1_seq_328767.2765.939511033
文件名: /home/oracle/arcbak/thread_1_seq_328766.5854.939511023
文件名: /home/oracle/arcbak/thread_1_seq_328759.4592.939510649
文件名: /home/oracle/arcbak/thread_1_seq_328758.3356.939510647
文件名: /home/oracle/arcbak/thread_1_seq_328760.3205.939510647
文件名: /home/oracle/arcbak/thread_1_seq_328762.5227.939510653
文件名: /home/oracle/arcbak/thread_1_seq_328761.5308.939510649
文件名: /home/oracle/arcbak/thread_1_seq_328757.1420.939481575
文件名: /home/oracle/arcbak/thread_1_seq_328764.5801.939510653
文件名: /home/oracle/arcbak/thread_1_seq_328765.3298.939510657

是否确实要将上述文件列入目录(输入 YES 或 NO)? y

正在编制文件目录...

目录编制完毕

已列入目录的文件的列表
=======================
文件名: /home/oracle/arcbak/thread_1_seq_328763.4773.939510653
文件名: /home/oracle/arcbak/thread_1_seq_328767.2765.939511033
文件名: /home/oracle/arcbak/thread_1_seq_328766.5854.939511023
文件名: /home/oracle/arcbak/thread_1_seq_328759.4592.939510649
文件名: /home/oracle/arcbak/thread_1_seq_328758.3356.939510647
文件名: /home/oracle/arcbak/thread_1_seq_328760.3205.939510647
文件名: /home/oracle/arcbak/thread_1_seq_328762.5227.939510653
文件名: /home/oracle/arcbak/thread_1_seq_328761.5308.939510649
文件名: /home/oracle/arcbak/thread_1_seq_328757.1420.939481575
文件名: /home/oracle/arcbak/thread_1_seq_328764.5801.939510653
文件名: /home/oracle/arcbak/thread_1_seq_328765.3298.939510657
-- 恢复归档日志
RMAN> copy archivelog '/home/oracle/arcbak/thread_1_seq_328757.1420.939481575' to '+fra';

启动 backup 于 25-3月 -17

使用通道 ORA_DISK_1

通道 ORA_DISK_1: 正在开始复制归档日志

输入归档日志线程=1 序列=328760 RECID=149368 STAMP=939573701
输出文件名=+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328760.474.939573739RECID=149375 STAMP=939573738

通道 ORA_DISK_1: 归档日志复制完成, 经过时间: 00:00:01

完成 backup 于 25-3月 -17
......

4. 最后就可以open数据库了

SQL> alter database open;
SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY WITH APPLY

-- 查看日志 ,归档日志正常进行应用
alter database open
Data Guard Broker initializing...
Data Guard Broker initialization complete
Beginning standby crash recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real TimeApply
Media Recovery Log+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328757.499.939573737
Media Recovery Log/home/oracle/arcbak/thread_1_seq_328758.3356.939510647
Sat Mar 25 16:43:57 2017
Incomplete Recovery applied until change91347484119 time 03/24/2017 15:06:26
Completed standby crash recovery.
Sat Mar 25 16:43:58 2017
SMON: enabling cache recovery
Dictionary check beginning
Dictionary check complete
Database Characterset is ZHS16GBK
No Resource Manager plan active
replication_dependency_tracking turned off(no async multimaster replication found)
Physical standby database opened for readonly access.
Completed: alter database open
Sat Mar 25 16:44:01 2017
ALTER DATABASE RECOVER MANAGED STANDBYDATABASE THROUGH ALL SWITCHOVERDISCONNECT USING CURRENT LOGFILE
Attempt to start background Managed StandbyRecovery process (htdb7)
Sat Mar 25 16:44:01 2017
MRP0 started with pid=47, OS id=9619
MRP0: Background Managed Standby Recoveryprocess started (htdb7)
 started logmerger process
Sat Mar 25 16:44:06 2017
Managed Standby Recovery starting Real TimeApply
Parallel Media Recovery started with 16slaves
Waiting for all non-current ORLs to bearchived...
All non-current ORLs have been archived.
Media Recovery Log /home/oracle/arcbak/thread_1_seq_328758.3356.939510647
Media Recovery Log+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328759.1574.939573739
Completed: ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE THROUGH ALL SWITCHOVERDISCONNECT USING CURRENT LOGFILE
Media Recovery Log+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328760.922.939573741
Media Recovery Log+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328761.695.939573743
Media Recovery Log+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328762.1769.939573745
Media Recovery Log+FRA/htdb7/archivelog/2017_03_25/thread_1_seq_328763.1422.939573745

总结:

在由于停电和网络原因,造成主备数据不同步,日志丢失的情况,主要学会使用rman工具把归档文件在fs和asm之间传输。在数据库恢复时会经常用到。

另外,如果数据库开启了闪回功能 ,也可以使用闪回数据库的某个时点进行恢复。可以参考另一篇博文:oracle数据库ORA-01196错误解决办法分享。

希望对大家有所帮助,感谢阅读。

(0)

相关推荐

  • oracle日志操作模式(归档模式和非归档模式的利与弊)

    笔者今天就谈谈自己对这两种操作模式的理解,并且给出一些可行的建议,跟大家一起来提高Oracle数据库的安全性. 一.非归档模式的利与弊. 非归档模式是指不保留重做历史的日志操作模式,只能够用于保护例程失败,而不能够保护介质损坏.如果数据库采用的是日志操作模式的话,则进行日志切换时,新的日志会直接覆盖原有日志文件的内容,不会保留原有日志文件中的数据. 这么说听起来可能比较难理解.笔者举一个简单的例子,就会清楚许多.如现在Oracle数据库中有四个日志组,日志序列号分别为11. 12.13.14.当

  • oracle的归档模式 ORACLE数据库归档日志常用命令

    --连接恢复管理器 C:\Documents and Settings\mengzhaoliang>rman target/ --归档日志列表 RMAN> list archivelog all; --删除物理文件不存在的归档日志 RMAN> delete expired archivelog all; --删除7天前的归档日志 RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'; oracle的归档模式 一.查看ora

  • Oracle切换为归档模式的步骤及问题解决

    直接如题 查看当前数据库模式 连接进入数据库,键入以下命令: 复制代码 代码如下: SQL> archive log list; 可查看当前数据库的模式,若"数据库日志模式    非存档模式"则有必要进行以下的切换流程. 在切换之前,请确保以下参数的设置 log_archive_dest_n 参数设置归档日志目标,其中n用数字替换.在Oracle9i中n的范围是1~5,在Oracle10g中n可以取值1~10.设置方式如下: 复制代码 代码如下: SQL> alter sy

  • 数据库ORA-01196故障-归档日志丢失恢复详解

    问题: 由于机房停电,其中一DG备库无法open,启动时报错 启动数据库时报下面的错误 SQL> alter database open; alter database open * 第 1 行出现错误: ORA-10458: standby database requiresrecovery ORA-01196: 文件 1 由于介质恢复会话失败而不一致 ORA-01110: 数据文件 1:'+DATA/htdb7/datafile/system.313.884996245' 查看归档日志应用情

  • Redhat持久化日志实战示例详解

    目录 持久化日志 实战练习:收集信息 持久化日志 默认情况下,Red Hat Enterprise Linux 7将系统日志存储在/run/log/journal中,该日志存储在tmpfs(临时文件系统)上.这意味着在重新启动时,所有存储的信息都将丢失.如果目录/var/log/journal存在,日志将存储在那里,从而在重新引导后启用持久日志. 可以通过使用以下步骤来启用持久性日志: mkdir/var/log/journal chown root:systemd-journal /var/l

  • springboot整合mybatis将sql打印到日志的实例详解

    在前台请求数据的时候,sql语句一直都是打印到控制台的,有一个想法就是想让它打印到日志里,该如何做呢? 见下面的mybatis配置文件: <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-

  • JS大坑之19位数的Number型精度丢失问题详解

    More 本项目仅供爬取体验,每次访问都会实时爬取数据,所以数据返回速度会比较慢,实际操作应该是定时爬取数据然后将数据存进数据库,数据从数据库返回从而提高数据返回效率. 但项目很基础,可以作为以上各个node模块最基础的练手使用,希望可以帮到大家

  • Oracle数据库服务器修改操作系统时间的注意事项详解

    Oracle 数据库服务器修改操作系统时间的注意事项: 对单机或者ha 1.对数据库本身而言,其实是没有影响的.因为scn不依赖于os时间 2.对app(应用程序)而言,若是app中使用了sysdate之类的,那确实是有影响的. 基于这个情况,我们一般推荐:改os时间 不往之前的时间去改,而是往今后的时间去改. 推荐:安装oracle10g时候注意事项&修改oracle数据库字符集编码 [安装oracle10g时候注意事项:1. 关闭网络连接2.--修改oracle数据库字符集编码:先用syst

  • MySQL数据归档小工具mysql_archiver详解

    一.主要概述 MySQL数据库归档历史数据主要可以分为三种方式:一.创建编写SP.设置Event:二.通过dump导入导出:三.通过pt-archiver工具进行归档.第一种方式往往受限于同实例要求,往往被大家舍弃.第二种,性能相对较好,但是归档表较多时运维也是比较头疼的事.所以很多DBA往往采用第三种方式--pt-archiver. pt-archiver是Percona-Toolkit工具集中的一个组件,是一个主要用于对MySQL表数据进行归档和清除的工具.它可以将数据归档到另一张表或者是一

  • MySQL数据库设计之利用Python操作Schema方法详解

    弓在箭要射出之前,低声对箭说道,"你的自由是我的".Schema如箭,弓似Python,选择Python,是Schema最大的自由.而自由应是一个能使自己变得更好的机会. Schema是什么? 不管我们做什么应用,只要和用户输入打交道,就有一个原则--永远不要相信用户的输入数据.意味着我们要对用户输入进行严格的验证,web开发时一般输入数据都以JSON形式发送到后端API,API要对输入数据做验证.一般我都是加很多判断,各种if,导致代码很丑陋,能不能有一种方式比较优雅的验证用户数据呢

  • python logging日志模块的详解

    python logging日志模块的详解 日志级别 日志一共分成5个等级,从低到高分别是:DEBUG INFO WARNING ERROR CRITICAL. DEBUG:详细的信息,通常只出现在诊断问题上 INFO:确认一切按预期运行 WARNING:一个迹象表明,一些意想不到的事情发生了,或表明一些问题在不久的将来(例如.磁盘空间低").这个软件还能按预期工作. ERROR:更严重的问题,软件没能执行一些功能 CRITICAL:一个严重的错误,这表明程序本身可能无法继续运行 这5个等级,也

  • 关于jsp中cookie丢失问题(详解)

    jsp中设置cookie如果不设置路径,会出现cookie丢失问题 Cookie cookie = new Cookie(cookieName, value); cookie.setMaxAge(3600); cookie.setPath("/"); response.addCookie(cookie); 以上这篇关于jsp中cookie丢失问题(详解)就是小编分享给大家的全部内容了,希望能给大家一个参考,也希望大家多多支持我们.

  • Android Doze模式启用和恢复详解

    从Android 6.0(API level 23)开始,Android提出了两个延长电池使用时间的省电特性给用户.用户管理可以在没有充电的情况下管理app的行为.当用户一段时间没有使用手机的时候,Doze模式通过延缓app后台的CPU和网络活动减少电量的消耗.App Stanbdy延缓用户最近没有使用app的后台网络活动. 作为移动开发人员,我们开发的App需要有推送功能,不希望在锁屏或者不充电的时候被Doze模式干掉.那么如何检测手机进入Doze模式之后App的状态呢? 一.模拟未充电状态

随机推荐