dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复
环境:
OS: CentOS 6.5
DB: Oracle 10.2.0.5 

1.主备库环境
主库:
SQL> select dbid,name,LOG_MODE,open_mode,db_unique_name,DATABASE_ROLE,PROTECTION_MODE from v$database;

      DBID NAME      LOG_MODE	  OPEN_MODE  DB_UNIQUE_NAME	  DATABASE_ROLE    PROTECTION_MODE
---------- --------- ------------ ---------- -------------------- ---------------- --------------------
 351758316 NETDATA   ARCHIVELOG   READ WRITE netdata_pd 	  PRIMARY	   MAXIMUM PERFORMANCE

SQL> archive log list;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       /u01/app/oracle/archive/netdata
Oldest online log sequence     65
Next log sequence to archive   67
Current log sequence	       67
SQL> 

备库:
SQL> select dbid,name,LOG_MODE,open_mode,db_unique_name,DATABASE_ROLE,PROTECTION_MODE from v$database;

      DBID NAME       LOG_MODE	   OPEN_MODE  DB_UNIQUE_ DATABASE_ROLE	  PROTECTION_MODE
---------- ---------- ------------ ---------- ---------- ---------------- --------------------
 351758316 NETDATA    ARCHIVELOG   MOUNTED    netdata_sd PHYSICAL STANDBY MAXIMUM PERFORMANCE

SQL> archive log list;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       /u01/app/oracle/archive/netdata
Oldest online log sequence     63
Next log sequence to archive   0
Current log sequence	       67
SQL> 

2.模拟归档丢失
备库操作:
备库取消归档应用
SQL> ALTER DATABASE recover managed standby DATABASE cancel;

Database altered.

备库以只读模式打开
SQL> alter database open read only;

Database altered.

SQL>
这张表是我建的测试表,用一个job跑的插入数据(每隔3S插入一条
SQL> select count(*) from hr.test;

  COUNT(*)
----------
     28501

SQL> 

主库操作:
SQL> select count(*) from hr.test;

  COUNT(*)
----------
     31143

SQL>
可以看到记录数不一致,这是因为归还没有传输过来 

主备归档情况
主库操作
SQL> set line 200
SQL> set pagesize 200
SQL> col name format A50
SQL> select name,SEQUENCE#,APPLIED from  v$archived_log where dest_id=1;

/u01/app/oracle/archive/netdata/1_52_857898543.arc	   52 NO
/u01/app/oracle/archive/netdata/1_53_857898543.arc	   53 NO
/u01/app/oracle/archive/netdata/1_54_857898543.arc	   54 NO
/u01/app/oracle/archive/netdata/1_55_857898543.arc	   55 NO
/u01/app/oracle/archive/netdata/1_56_857898543.arc	   56 NO
/u01/app/oracle/archive/netdata/1_57_857898543.arc	   57 NO
/u01/app/oracle/archive/netdata/1_58_857898543.arc	   58 NO
/u01/app/oracle/archive/netdata/1_59_857898543.arc	   59 NO
/u01/app/oracle/archive/netdata/1_60_857898543.arc	   60 NO
/u01/app/oracle/archive/netdata/1_61_857898543.arc	   61 NO
/u01/app/oracle/archive/netdata/1_62_857898543.arc	   62 NO
/u01/app/oracle/archive/netdata/1_63_857898543.arc	   63 NO
/u01/app/oracle/archive/netdata/1_64_857898543.arc	   64 NO
/u01/app/oracle/archive/netdata/1_65_857898543.arc	   65 NO
/u01/app/oracle/archive/netdata/1_66_857898543.arc	   66 NO

64 rows selected.
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS	    FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
	12	    1	      65  104857600	     2 YES INACTIVE		   715138 13-SEP-14
	13	    1	      66  104857600	     2 YES INACTIVE		   715158 13-SEP-14
	14	    1	      67  104857600	     2 NO  CURRENT		   715164 13-SEP-14

SQL> 

备库操作
SQL> set line 200
SQL> set pagesize 200
SQL> col name format A50
SQL> select name,SEQUENCE#,APPLIED from  v$archived_log where dest_id=1;

NAME						    SEQUENCE# APP
-------------------------------------------------- ---------- ---
/u01/app/oracle/archive/netdata/1_64_857898543.arc	   64 YES
/u01/app/oracle/archive/netdata/1_65_857898543.arc	   65 YES
/u01/app/oracle/archive/netdata/1_66_857898543.arc	   66 YES
/u01/app/oracle/archive/netdata/1_63_857898543.arc	   63 YES

SQL> select * from v$Log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS	    FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
	12	    1	      65  104857600	     2 YES CLEARING		   715138 13-SEP-14
	13	    1	      63  104857600	     2 YES CLEARING		   714611 13-SEP-14
	14	    1	      67  104857600	     2 YES CLEARING_CURRENT	   715164 13-SEP-14

主库操作
SQL>  ALTER system SET log_archive_dest_state_2 = ‘defer‘;

System altered.

SQL> 

SQL> alter system archive log current;

System altered.

SQL> alter system archive log current;

System altered.

SQL> alter system archive log current;

System altered.

SQL> alter system archive log current;

System altered.

SQL> alter system archive log current;

System altered.

SQL> 

删除归档
SQL> archive log list;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       /u01/app/oracle/archive/netdata
Oldest online log sequence     70
Next log sequence to archive   72
Current log sequence	       72
SQL> 

删除归档
[[email protected] netdata]$ rm -rvf 1\_7*
已删除"1_70_857898543.arc"
已删除"1_71_857898543.arc"
已删除"1_7_857893401.dbf"
主库开启备库归档
SQL>  ALTER system SET log_archive_dest_state_2 = ‘enable‘;

备库重新开启应用
SQL> ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;

Database altered.

SQL>
System altered.

SQL> 

查询备库alert.log
Waiting for all non-current ORLs to be archived...
Media Recovery Waiting for thread 1 sequence 67
Fetching gap sequence in thread 1, gap sequence 67-70
Sat Sep 13 21:00:27 CST 2014
Completed: ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Sat Sep 13 21:00:57 CST 2014
FAL[client]: Failed to request gap sequence
 GAP - thread 1 sequence 67-70
 DBID 351758316 branch 857898543
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------

有gap产生了

备库查询
select name,sequence#,applied from v$archived_log a where a.sequence#=(select max(sequence#) from v$archived_log);

NAME						    SEQUENCE# APP
-------------------------------------------------- ---------- ---
/u01/app/oracle/archive/netdata/1_66_857898543.arc	   66 YES

主库查询
SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# FROM v$archived_log WHERE SEQUENCE# > 67 ORDER BY 1;

 SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
	68	  745961       745971
	69	  745971       745984
	70	  745984       745988
	71	  745988       746005

SQL> 

主库
基于SCN增量备份
RMAN> backup device type disk incremental from scn 715164 database format ‘/u01/backup/netdata_incre%U.bbk‘;

Starting backup at 13-SEP-14
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u01/app/oracle/oradata/netdata/system01.dbf
input datafile fno=00003 name=/u01/app/oracle/oradata/netdata/sysaux01.dbf
input datafile fno=00005 name=/u01/app/oracle/oradata/netdata/example01.dbf
input datafile fno=00006 name=/u01/app/oracle/oradata/netdata/HTSDK_01.dbf
input datafile fno=00007 name=/u01/app/oracle/oradata/netdata/HTSDK_INDEX_01.dbf
input datafile fno=00002 name=/u01/app/oracle/oradata/netdata/undotbs01.dbf
input datafile fno=00004 name=/u01/app/oracle/oradata/netdata/users01.dbf
channel ORA_DISK_1: starting piece 1 at 13-SEP-14
channel ORA_DISK_1: finished piece 1 at 13-SEP-14
piece handle=/u01/backup/netdata_incre0jpie810_1_1.bbk tag=TAG20140913T212904 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:18
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 13-SEP-14
channel ORA_DISK_1: finished piece 1 at 13-SEP-14
piece handle=/u01/backup/netdata_incre0kpie83e_1_1.bbk tag=TAG20140913T212904 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04
Finished backup at 13-SEP-14

RMAN> 

主库重新生成控制文件

SQL> ALTER DATABASE CREATE standby controlfile AS ‘/u01/backup/standby.ctl‘;   

Database altered.

拷贝文件至备库
[[email protected] backup]$ scp * [email protected]:/u01/backup/
[email protected]‘s password:
netdata_incre0jpie810_1_1.bbk                                                                       100%   17MB   8.5MB/s   00:02
netdata_incre0kpie83e_1_1.bbk                                                                       100% 7200KB   7.0MB/s   00:01
standby.ctl                                                                                         100% 7120KB   7.0MB/s   00:01  

备库操作
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup nomount;
ORACLE instance started.

Total System Global Area  704643072 bytes
Fixed Size		    2098912 bytes
Variable Size		  192940320 bytes
Database Buffers	  503316480 bytes
Redo Buffers		    6287360 bytes
SQL> quit

恢复控制文件
RMAN> restore controlfile from ‘/u01/backup/standby.ctl‘;

Starting restore at 13-SEP-14
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=541 devtype=DISK

channel ORA_DISK_1: copied control file copy
output filename=/u01/app/oracle/oradata/netdata/control01.ctl
output filename=/u01/app/oracle/oradata/netdata/control02.ctl
output filename=/u01/app/oracle/oradata/netdata/control03.ctl
Finished restore at 13-SEP-14

RMAN> 

RMAN> catalog start with ‘/u01/backup‘
2> ;

searching for all files that match the pattern /u01/backup

List of Files Unknown to the Database
=====================================
File Name: /u01/backup/netdata_incre0jpie810_1_1.bbk
File Name: /u01/backup/standby.ctl
File Name: /u01/backup/control01.ctl
File Name: /u01/backup/netdata_incre0kpie83e_1_1.bbk

Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /u01/backup/netdata_incre0jpie810_1_1.bbk
File Name: /u01/backup/standby.ctl
File Name: /u01/backup/control01.ctl
File Name: /u01/backup/netdata_incre0kpie83e_1_1.bbk

RMAN>  recover DATABASE noredo;

Starting recover at 13-SEP-14
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /u01/app/oracle/oradata/netdata/system01.dbf
destination for restore of datafile 00002: /u01/app/oracle/oradata/netdata/undotbs01.dbf
destination for restore of datafile 00003: /u01/app/oracle/oradata/netdata/sysaux01.dbf
destination for restore of datafile 00004: /u01/app/oracle/oradata/netdata/users01.dbf
destination for restore of datafile 00005: /u01/app/oracle/oradata/netdata/example01.dbf
destination for restore of datafile 00006: /u01/app/oracle/oradata/netdata/HTSDK_01.dbf
destination for restore of datafile 00007: /u01/app/oracle/oradata/netdata/HTSDK_INDEX_01.dbf
channel ORA_DISK_1: reading from backup piece /u01/backup/netdata_incre0jpie810_1_1.bbk
channel ORA_DISK_1: restored backup piece 1
piece handle=/u01/backup/netdata_incre0jpie810_1_1.bbk tag=TAG20140913T212904
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04

Finished recover at 13-SEP-14

RMAN> 

查询alert 日志
Sat Sep 13 22:04:34 CST 2014
RFS LogMiner: Client disabled from further notification
Sat Sep 13 22:04:54 CST 2014
Incremental restore complete of datafile 4 /u01/app/oracle/oradata/netdata/users01.dbf
  checkpoint is 753898
Incremental restore complete of datafile 2 /u01/app/oracle/oradata/netdata/undotbs01.dbf
  checkpoint is 753898
  last deallocation scn is 669702
Incremental restore complete of datafile 5 /u01/app/oracle/oradata/netdata/example01.dbf
  checkpoint is 753898
  last deallocation scn is 399417
Incremental restore complete of datafile 6 /u01/app/oracle/oradata/netdata/HTSDK_01.dbf
  checkpoint is 753898
Incremental restore complete of datafile 7 /u01/app/oracle/oradata/netdata/HTSDK_INDEX_01.dbf
  checkpoint is 753898
Incremental restore complete of datafile 3 /u01/app/oracle/oradata/netdata/sysaux01.dbf
  checkpoint is 753898
  last deallocation scn is 421688
Incremental restore complete of datafile 1 /u01/app/oracle/oradata/netdata/system01.dbf
  checkpoint is 753898
  last deallocation scn is 472342

备库重新应用
SQL>  ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;

Database altered.

SQL> 

测试归档是否
SQL> alter system switch logfile;

System altered.

SQL> 

查询主备
备库操作

archive log list;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       /u01/app/oracle/archive/netdata
Oldest online log sequence     71
Next log sequence to archive   0
Current log sequence	       73
col name format A50;
col dest_name format A40
col error format A20
set line 200;
select name,sequence#,applied from v$archived_log a where a.sequence#=(select max(sequence#) from v$archived_log);

NAME						    SEQUENCE# APP
-------------------------------------------------- ---------- ---
/u01/app/oracle/archive/netdata/1_72_857898543.arc	   72 YES

col dest_name format A40
SQL>  select dest_name,status,error from v$archive_dest where rownum<3; 

DEST_NAME				 STATUS    ERROR
---------------------------------------- --------- --------------------
LOG_ARCHIVE_DEST_1			 VALID
LOG_ARCHIVE_DEST_2			 VALID

SQL> 

主库操作

archive log list;
col name format A50;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       /u01/app/oracle/archive/netdata
Oldest online log sequence     71
Next log sequence to archive   73
Current log sequence	       73
col dest_name format A40
col error format A20
set line 200;
select name,sequence#,applied from v$archived_log a where a.sequence#=(select max(sequence#) from v$archived_log);

NAME						    SEQUENCE# APP
-------------------------------------------------- ---------- ---
/u01/app/oracle/archive/netdata/1_72_857898543.arc	   72 NO
netdata_sd						   72 YES

col dest_name format A40
SQL>  select dest_name,status,error from v$archive_dest where rownum<3; 

DEST_NAME				 STATUS    ERROR
---------------------------------------- --------- --------------------
LOG_ARCHIVE_DEST_1			 VALID
LOG_ARCHIVE_DEST_2			 VALID

SQL>
时间: 2024-10-06 14:42:37

dataguard 归档丢失(主库中无此丢失归档处理),备库基于SCN恢复的相关文章

Oracle Dataguard中备库中归档日志不同步

环境:RAC+单机 Dataguard问题:启动备库到ADG模式时,发现后台归档日志并不同步 1.在备库中发现日志的归档日志不同步,内容如下:MRP0: Background Media Recovery process shutdown (strac)Managed Standby Recovery Canceled (strac)Completed: alter database recover managed standby database cancelSun Mar 04 16:35:

oracle11g dataguard物理备库搭建

Dataguard 环境: 操作系统:Redhat6.4 Primary数据库: IP 地址:192.168.1.122 数据库SID:ora11g DB_UNIQUE_NAME:ora11g_primary Standby数据库: IP 地址:192.168.1.123 数据库SID:ora11g DB_UNIQUE_NAME:ora11g_standby (注:oracle数据库版本是11.2.0.1.0) 1.Primary端的配置 (1).检查数据库是否支持 Data Guard(企业版

DG备库磁盘空间满导致无法创建归档

上周五去某客户那里做数据库巡检,是window 2008系统上10g的一套NC系统的库,已经配置了DG,但是巡检时发现数据库报错: Tue Nov 11 10:13:57 2014 LNS: Standby redo logfile selected for thread 1 sequence 3945 for destination LOG_ARCHIVE_DEST_2 Tue Nov 11 10:14:29 2014 Errors in file d:\oracle\product\10.2

模拟主库创建数据文件,dg备库空间不足时问题处理

本篇文档测试目的: 模拟实际环境中,主库对表空间添加数据文件,备库空间不足,最终导致MRP进程自动断开,处理方式. 1.问题环境模拟 1)正常情况下的dg 主库创建数据文件,备库接受日志,自动创建表空间及数据文件. RFS[49]: Selected log 4 for thread 1 sequence 115 dbid 699220720 branch 994543603 Fri Feb 22 23:20:36 2019 Media Recovery Log /u01/app/oracle/

Oracle主库归档丢失,备库日志有gap,在不重建备库的情况下,恢复备库

本文主要描述Oracle备库日志与主库日志之间有gap,切主库这部分gap的归档日志已经删除或丢失,如何在不重建备库的情况下,恢复备库. 欢迎转载,请注明作者.出处. 作者:张正 blog:http://space.itpub.net/26355921 QQ:176036317 如有疑问,欢迎联系. 在dataguard环境中,由于主库archivelog丢失,且尚未同步到standby,问如何在避免 重建standby的情况下来将standby恢复成功的. 下面是我的测试过程,供参考! —-主

Redhat 6中syslog信息丢失

我们采用Linux的syslog来记录产品的debug log.调用其中的一个可执行文件,执行完命令之后,查看debug log的信息,居然从某一条log之后的log都丢失了.多次尝试后,发现每次都在某条固定的log之后的log都丢失了.这篇博文就让我们一起来探个究竟. 一. 问题发现 在发现真正问题之前我做了以下尝试: (1) 进程是否在固定log之后某种逻辑退出?或者在固定log打印之后的语句中会产生信号导致进程终止? 在程序末尾打印一个消息到屏幕,可以看到程序正常运行,并退出. (2) 是

Kafka 生产者无消息丢失配置

prodcer同步发送的机制虽然能保证消息不丢失,但是不推荐生产环境使用,性能很差.一般都是采用异步方式发送消息,把消息先放入缓冲区,然后再由IO线程推送出去,存在消息丢失的风险,而且可能发生乱序. 下面给出Kafka无消息丢失的配置: Producer端配置 block.on.buffer.full = true0.9版本后已经废弃,改用max.block.ms代替,推荐用户显示设置为true,使得缓冲期填满时,producer处于阻塞状态并停止接收新的消息而不是抛出异常. acks = al

完全解决asp.net MVC中的session丢失问题

http://user.qzone.qq.com/136234428/blog/1410260445 完全解决asp.net MVC中的session丢失问题 http://user.qzone.qq.com/136234428/blog/1410260445 完全解决asp.net MVC中的session丢失问题 http://user.qzone.qq.com/136234428/blog/1410260445 完全解决asp.net MVC中的session丢失问题 http://use

EXT3文件系统误删除导致文件系统中的邮件丢失恢复方法

一.故障描述 由8块盘组成的RAID5, 上层是EXT3文件系统,由于误删除导致文件系统中的邮件丢失 二.镜像磁盘为防止数据恢复过程中由于误操作对原始磁盘造成二次破坏, 使用winhex软件为每块磁盘做镜像, 以后所有的数据恢复操作都在镜像盘上进行, 不会对原始磁盘造成影响镜像结果如下:图一 三.组建RAID通过分析数据在硬盘中分布的规律, 获取RAID类型, RAID条带的大小,以及每块磁盘的顺序.根据分析结果使用UFS组建RAID.结果如下:图二 四.导出目标分区 从组建好的RAID中可以看