dataguard日志损坏处理

===== 问题 =====

日志损坏无法应用日志（开启MRP应用系统会因无法应用日志而关闭）

Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION

Incomplete read from log member '/arch/2_1119_997386564.dbf'. Trying next member.

Incomplete read from log member '/arch/2_1119_997386564.dbf'. Trying next member.

Errors in file /oracle/app/oracle/diag/rdbms/orcldg/orcl/trace/orcl_pr00_40712.trc  (incident=108241):

ORA-00353: log corruption near block 2056 change 15781869802803 time 07/31/2019 06:57:33

ORA-00334: archived log: '/arch/2_1119_997386564.dbf'

Incident details in: /oracle/app/oracle/diag/rdbms/orcldg/orcl/incident/incdir_108241/orcl_pr00_40712_i108241.trc

Errors with log /arch/2_1119_997386564.dbf

Fri Aug 02 08:53:53 2019

Dumping diagnostic data in directory=[cdmp_20190802085353], requested by (instance=1, osid=40712 (PR00)), summary=[incident=108241].

MRP0: Detected read corruption! Retry recovery once log is re-fetched...

Errors in file /oracle/app/oracle/diag/rdbms/orcldg/orcl/trace/orcl_pr00_40712.trc:

ORA-00354: corrupt redo log block header

ORA-00353: log corruption near block 2056 change 15781869802803 time 07/31/2019 06:57:33

ORA-00334: archived log: '/arch/2_1119_997386564.dbf'

Managed Standby Recovery not using Real Time Apply

Recovery interrupted!

Fri Aug 02 08:53:54 2019

Sweep [inc][108241]: completed

==== 备库损坏的日志 ====

ORA-00334: archived log: '/arch/1_1091_997386564.dbf'

ORA-00334: archived log: '/arch/2_1119_997386564.dbf'

ORA-00334: archived log: '/arch/1_1093_997386564.dbf'

RA-00334: archived log: '/arch/2_1120_997386564.dbf'

==== 手动传输损坏的日志到备库 ====
分几种情况
1、主库归档日志还保留，直接将备库损坏的日志scp至备库
2、主库归档日志已清理，rman备份还保留，rman恢复归档日志后传输到备库
3、主库归档日志已清理，无备份，只能重新搭建adg了

#下面说一下第二种情况

1、查看归档日志备份信息

rman target /

RMAN>list backup of archivelog from logseq 1080 until logseq 1100;

2、主库恢复1091日志文件至本地

RMAN> run{

2> set archivelog destination to '/rman_bak/archbak';

3> restore archivelog SEQUENCE BETWEEN 1080 AND 1100;

4> }

executing command: SET ARCHIVELOG DESTINATION

Starting restore at 02-AUG-19

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=872 instance=orcl1 device type=DISK

archived log for thread 1 with sequence 1092 is already on disk as file +ARCH/archivelog/1_1092_997386564.dbf

archived log for thread 1 with sequence 1093 is already on disk as file +ARCH/archivelog/1_1093_997386564.dbf

archived log for thread 1 with sequence 1094 is already on disk as file +ARCH/archivelog/1_1094_997386564.dbf

archived log for thread 1 with sequence 1095 is already on disk as file +ARCH/archivelog/1_1095_997386564.dbf

archived log for thread 1 with sequence 1096 is already on disk as file +ARCH/archivelog/1_1096_997386564.dbf

archived log for thread 1 with sequence 1097 is already on disk as file +ARCH/archivelog/1_1097_997386564.dbf

archived log for thread 1 with sequence 1098 is already on disk as file +ARCH/archivelog/1_1098_997386564.dbf

archived log for thread 1 with sequence 1099 is already on disk as file +ARCH/archivelog/1_1099_997386564.dbf

archived log for thread 1 with sequence 1100 is already on disk as file +ARCH/archivelog/1_1100_997386564.dbf

channel ORA_DISK_1: starting archived log restore to user-specified destination

archived log destination=/rman_bak/archbak

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1080

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1081

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1082

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1083

channel ORA_DISK_1: reading from backup piece /rman_bak/bak/arch_20190801_23241_1

channel ORA_DISK_1: piece handle=/rman_bak/bak/arch_20190801_23241_1 tag=TAG20190801T022702

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

channel ORA_DISK_1: starting archived log restore to user-specified destination

archived log destination=/rman_bak/archbak

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1084

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1085

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1086

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1087

channel ORA_DISK_1: reading from backup piece /rman_bak/bak/arch_20190801_23242_1

channel ORA_DISK_1: piece handle=/rman_bak/bak/arch_20190801_23242_1 tag=TAG20190801T022702

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

channel ORA_DISK_1: starting archived log restore to user-specified destination

archived log destination=/rman_bak/archbak

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1088

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1089

channel ORA_DISK_1: reading from backup piece /rman_bak/bak/arch_20190801_23243_1

channel ORA_DISK_1: piece handle=/rman_bak/bak/arch_20190801_23243_1 tag=TAG20190801T022702

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

channel ORA_DISK_1: starting archived log restore to user-specified destination

archived log destination=/rman_bak/archbak

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1090

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=1091

channel ORA_DISK_1: reading from backup piece /rman_bak/bak/arch_20190802_23296_1

channel ORA_DISK_1: piece handle=/rman_bak/bak/arch_20190802_23296_1 tag=TAG20190802T022801

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:03

Finished restore at 02-AUG-19

3、将1091#日志文件传输到备库
4、备库开启MRP应用并查看日志应用情况

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

SELECT NAME,applied FROM v$archived_log where applied='NO';

日志部分输出：

Media Recovery Log /arch/2_1125_997386564.dbf

Fri Aug 02 10:49:25 2019

Media Recovery Log /arch/1_1098_997386564.dbf

Fri Aug 02 10:49:36 2019

Media Recovery Log /arch/2_1126_997386564.dbf

Fri Aug 02 10:50:43 2019

Media Recovery Log /arch/1_1099_997386564.dbf

Fri Aug 02 10:50:57 2019

#查看进程状态：

select process,status,thread#,sequence# from v$managed_standby order by 3,1;

PROCESS   STATUS	       THREAD#  SEQUENCE#

--------- ------------ ---------- ----------

RFS	        IDLE			       0	   0

RFS	        IDLE			       0	   0

RFS	        IDLE			       0	   0

ARCH	     CLOSING		       1	1457

ARCH	     CLOSING		       1	1073

MRP0	     APPLYING_LOG		   1	1095

RFS	       WRITING		       1	1458

ARCH	     CLOSING		       2	1485

ARCH	     CLOSING		       2	1483

RFS	       WRITING		       2	1486

ORA-00334: archived log: '/arch/1_1156_997386564.dbf'

Incomplete read from log member '/arch/2_1183_997386564.dbf'. Trying next member.

Incomplete read from log member '/arch/2_1183_997386564.dbf'. Trying next member.

Errors in file /oracle/app/oracle/diag/rdbms/orcldg/orcl/trace/orcl_pr00_1605.trc  (incident=108235):

ORA-00353: log corruption near block 6152 change 15781873869856 time 07/31/2019 13:22:46

ORA-00334: archived log: '/arch/2_1183_997386564.dbf

MRP0: Background Media Recovery process shutdown (orcl)

Fri Aug 02 13:10:28 2019

#手动传输日志：1_1156_997386564.dbf、/arch/2_1183_997386564.dbf

Media Recovery Log /arch/1_1156_997386564.dbf

Media Recovery Log /arch/2_1183_997386564.dbf

Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION

Media Recovery Log /arch/2_1184_997386564.dbf

Fri Aug 02 14:53:11 2019

#核查以下日志是否applied

ORA-00334: archived log: '/arch/1_1166_997386564.dbf'

ORA-00334: archived log: '/arch/1_1163_997386564.dbf'

/arch/1_1091_997386564.dbf

/arch/2_1119_997386564.dbf

/arch/1_1093_997386564.dbf

/arch/2_1120_997386564.dbf

/arch/2_1124_997386564.dbf

/arch/1_1156_997386564.dbf

/arch/2_1183_997386564.dbf

/arch/1_1158_997386564.dbf

/arch/1_1159_997386564.dbf

/arch/1_1160_997386564.dbf

/arch/1_1161_997386564.dbf

/arch/2_1190_997386564.dbf

/arch/1_1163_997386564.dbf

/arch/1_1166_997386564.dbf

/arch/2_1228_997386564.dbf

ORA-16014: log 18 sequence# 1487 not archived, no available destinations

ORA-00312: online log 18 thread 2: '/oradata/orcldg/onlinelog/stdby_redo18.log

ORA-00334: archived log: '/arch/2_1230_997386564.dbf'

ORA-00334: archived log: '/arch/2_1243_997386564.dbf'

ORA-00334: archived log: '/arch/2_1245_997386564.dbf'

ORA-00334: archived log: '/arch/1_1223_997386564.dbf'

ORA-00334: archived log: '/arch/2_1254_997386564.dbf'

ORA-00334: archived log: '/arch/1_1228_997386564.dbf'

SQL> SELECT NAME,applied FROM v$archived_log where name like '%2_1254%';

NAME			       APPLIED

------------------------------ ---------

/arch/2_1254_997386564.dbf     NO

/arch/2_1254_997386564.dbf     YES

#以下日志已应用（展示的为未应用的状态）：
tips:重新应用的日志有两个状态，实际以数据库日志和MRP进程状态为准


NAME			       APPLIED

------------------------------ ---------

/arch/1_1091_997386564.dbf     NO

/arch/2_1119_997386564.dbf     NO

/arch/1_1092_997386564.dbf     NO

/arch/1_1093_997386564.dbf     NO

/arch/2_1124_997386564.dbf     NO

/arch/1_1156_997386564.dbf     NO

/arch/1_1158_997386564.dbf     NO

/arch/1_1159_997386564.dbf     NO

/arch/1_1160_997386564.dbf     NO

/arch/1_1161_997386564.dbf     NO

/arch/2_1190_997386564.dbf     NO

/arch/1_1163_997386564.dbf     NO

/arch/1_1166_997386564.dbf     NO

/arch/2_1228_997386564.dbf     NO

/arch/2_1243_997386564.dbf     NO

/arch/2_1245_997386564.dbf     NO

/arch/1_1223_997386564.dbf     NO

/arch/2_1254_997386564.dbf     NO

/arch/1_1228_997386564.dbf     NO

/arch/1_1203_997386564.dbf     NO

#查看进程状态

select process,status,thread#,sequence# from v$managed_standby order by 3,1;
PROCESS STATUS THREAD# SEQUENCE#
--------- ------------ ---------- ----------
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
ARCH CLOSING 1 1457
ARCH CLOSING 1 1073
MRP0 APPLYING_LOG 1 1095
RFS WRITING 1 1458
ARCH CLOSING 2 1485
ARCH CLOSING 2 1483
RFS WRITING 2 1486

dataguard日志损坏处理的更多相关文章

大话RAC介质恢复---联机日志损坏
对联机日志的损坏要根据日志状态进行分析,联机日志一般会有Current.Active和Inactive三种状态.Inactive状态不会造成数据丢失.而Active和Current状态的日志一般会造成 ...
sql日志损坏造成数据库置疑解决办法
--如果确定是日志损坏造成,请用下面的方法恢复日志文件.--第一步--use mastergo sp_configure 'allow updates', 1reconfigure with over ...
dataguard日志自动删除
dataguard日志自动删除 1.判断日志是否已经应用到今天.2.删除3天前的日志.3.主机.备机分别配置 ----check_del_arch.sh#!/bin/shORACLE_HOME=/ho ...
Oracle redo 日志损坏的几种情况下的恢复
Oracle redo 日志损坏的几种情况下的恢复第一:损坏的redo为非正在使用的redo log 1.归档模式,不是当前正在日志损坏,数据库打开模式. 模拟损坏:SQL> select * ...
Oracle联机日志损坏解决办法
关于此问题,在网上找到一篇不错的文章. 大家都清楚,联机日志分为当前联机日志和非当前联机日志. ---------------------------------------------------- ...
ORACLE DATAGUARD 日志传输状态监控
ORACLE DATAGUARD的主备库同步,主要是依靠日志传输到备库,备库应用日志或归档来实现.当主.备库间日志传输出现GAP,备库将不再与主库同步.因此需对日志传输状态进行监控,确保主.备库间日志 ...
模拟状态为active的日志损坏的数据恢复实验（不完全恢复）
1查看当前日志状态首先不完全恢复是会丢失数据的,由此在当前打开的数据中我们创建一些测试数据,用来验证当我们进行完不完全恢复后该数据是否还存在. 2模拟删除CURRENT状态的日志 3启动数据验证错误 ...
模拟状态为inactive的日志损坏的恢复实验(完全恢复)
1查看当前日志状态从这里可以看到我们现在有三组日志,每组日志中只有1个成员.为了演示这个实验,我们为每个组增加1个成员. 2为每组增加组成员添加后我们验证一下目前各日志成员的状态: 从上面的视图中 ...
SQL 2005 日志损坏的恢复方法
SQL 在突然停电或者非正常关机下,可能会出现日期文件错误,导致数据库不正常.恢复数据库方法如下 1.数据库服务停掉将数据库文件备份例如数据库名为 DTMS 则将 DTMS.mdf 备份出来. 2 ...

随机推荐

web php wrong nginx config
web php wrong nginx config 目录 web php wrong nginx config 题目描述解题过程信息收集 robots.txt hint.php Hack.php ...
MySQL分页优化_别再用offset和limit分页了
终于要对MySQL优化下手了,本文将对分页进行优化说明,希望可以得到一个合适你的方案. 开始之前,先分享一套MySQL教程,小白入门或者学习巩固都可以看 MySQL基础入门-mysql教程-数据库实战 ...
ElasticSearch第三弹之存储原理
我们上文中介绍的ES内部索引的写处理流程是在ES的内存中执行的,而数据被分配到特定的主.副分片上之后,最终是存储到磁盘上的,这样在断电的时候就不会丢失数据.具体的存储路径可在配置文件 ../confi ...
如何解决 shell 脚本重复执行的问题
在开发过程中,经常会使用shell脚本去完成定时备份的任务,普遍的做法是通过系统的定时任务定时执行备份脚本设想这样一种场景,本次备份时间到了,自动执行备份脚本,如果备份比较耗时的话,会一直持续到下一 ...
云服务器Apache+MySQL(远程连接)+PHP等环境安装2021.5.9号配置
云服务器Apache+MySQL(远程连接)+PHP等环境安装2021.5.9号配置 Linux版本:centos8.2 (其他版本提供适配) 安装方式:yum 今天使用centos8系统搭建了下云主 ...
jQuery两种方法添加数据表格到HTML
jQ创建表格的两种方法 1.模板字符串法 $(function () { //模板字符串的方式添加到页面 $('#btn').click(function ...
ARM64平台编译stream、netperf出错解决办法解决办法：指定编译平台为alpha [root@localhost netperf-2.6.0]# ./configure –build=alpha
ARM64平台编译stream.netperf出错解决办法 http://ilinuxkernel.com/?p=1738 stream编译出错信息: [root@localhost stream]# ...
字体：等宽字体与比例字体 - Monospaced font & Proportional font
字体:等宽字体与比例字体 - Monospaced font & Proportional font 量子波儿 2013-08-24 16:54:12 7101 收藏 1分类专栏: 计算机常识 ...
Job for ssh.service failed because the control process exited with error code. See "systemctl status ssh.service" and "journalctl -xe" for details.
1.按照提示 systemctl status ssh.service 查看报错原因 sshd -t 2.结果 /etc/ssh/sshd_config line 34: missing argume ...
在Linux中通过Top运行进程查找最高内存和CPU使用率
按内存使用情况查找前15个进程,在批处理模式下为"top" 使用top命令查看有关当前状态,系统使用情况的更详细信息:正常运行时间,负载平均值和进程总数. 分类:Linux命令操作 ...

dataguard日志损坏处理

dataguard日志损坏处理的更多相关文章

随机推荐

热门专题