oracle dataguard 日志 很多no,Oracle DataGuard归档日志丢失处理方法

Oracle DataGuard归档日志丢失处理方法

某数据库配置了Physical DataGuard(以下简称dg),由于没有检查,所以在主库上把归档日志

删除了,而备库又没有完全应用,所以导致备库一直停留在之前的归档日志中.

主库检查,发现dest_id为的25号日志就丢失了.

PRIMARY> select dest_id,sequence#,applied,status,first_change#,next_change# from v$archived_log

where sequence#>20 order by dest_id,sequence#;

DEST_ID  SEQUENCE# APPLIEDS FIRST_CHANGE# NEXT_CHANGE#

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

1   21 NOD1765541      1765764

1   22 NOD1765764      1768228

1   23 NOD1768228      1768269

1   24 NOD1768269      1768400

1   25 NOX1768400      1768516

1   26 NOX1768516      1768531

1   27 NOX1768531      1768611

2   21 YESA1765541      1765764

2   22 YESA1765764      1768228

2   23 YESA1768228      1768269

2   24 NOA1768269      1768400

DEST_ID  SEQUENCE# APPLIEDS FIRST_CHANGE# NEXT_CHANGE#

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

2   26 NOA1768516      1768531

2   27 NOA1768531      1768611

所以备库一直无法使用.这种情况下要么就重做整个备库,或是从备库断点的日志那个时候起恢复数据库.

由于数据库比较大,决定采用第二种方案;

在备库上,我们查看当前的数据文件最大的SCN

STANDBY> select name,file#,checkpoint_change# from v$datafile order by checkpoint_change#;

NAME     FILE# CHECKPOINT_CHANGE#

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

/u01/app/oracle/oradata/dc1stby/undotbs01.dbf 4      1768269

/u01/app/oracle/oradata/dc1stby/sysaux01.dbf 3      1768269

/u01/app/oracle/oradata/dc1stby/system01.dbf 1      1768269

/u01/app/oracle/oradata/dc1stby/users01.dbf 6      1768269

在主库上做一个增量SCN备份,起始的位置就是备库数据文件的最小SCN号.

[oracle@newplat ~]$ rman target / nocatalog

[oracle@newplat ~]$ $ORACLE_HOME/bin/rman target / nocatalog

RMAN> run

2> {

3> allocate channel c3 device type disk;

4>  backup as compressed backupset incremental from scn 1768269 database format '/home/oracle/bak/%U';

5> release channel c3;

6> }

released channel: ORA_DISK_1

allocated channel: c3

channel c3: SID=42 device type=DISK

.....................................................

including current control file in backup set

channel c3: starting piece 1 at 03-APR-16

channel c3: finished piece 1 at 03-APR-16

piece handle=/home/oracle/bak/0rr22q7u_1_1 tag=TAG20160403T022709 comment=NONE

channel c3: backup set complete, elapsed time: 00:00:01

Finished backup at 03-APR-16

备份完成后,我们通过SCP很快把备份文件传到备库的机器上来

[oracle@newplat bak]$ scp *1_1 192.168.56.22:/home/oracle/bak

这时候我们需要关闭备库,然把把实例启动到nomount关态

STANDBY> shutdown immediate;

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

STANDBY> startup nomount;

ORACLE instance started.

Total System Global Area 1224736768 bytes

Fixed Size    2923824 bytes

Variable Size  939524816 bytes

Database Buffers  268435456 bytes

Redo Buffers   13852672 bytes

实例启动到mount状态后,我们进入备库的rman,这时候需要恢复控制文件,原备库的控制文件因为

包含了redo apply老的应用信息所以不能用了.

[oracle@dg2 bak]$ rman target / nocatalog

RMAN> restore standby controlfile from '/home/oracle/bak/0rr22q7u_1_1';

Starting restore at 03-APR-16

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=23 device type=DISK

............................................

很快控制文件就了恢复完成了,我们打开另一个窗口,通过sqlplus把备库以standby的方式mount起来

STANDBY> alter database mount standby database;

Database altered.

数据库mount起来后,我们返回到rman提示符,这个时候我们可以对传过来的备份文件并进行编目了.这样我

们在下一步操作中,就可以使用这些文件来行恢复

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

searching for all files that match the pattern /home/oracle/bak

List of Files Unknown to the Database

=====================================

File Name: /home/oracle/bak/08r1ekse_1_1

File Name: /home/oracle/bak/0or22q7t_1_1

File Name: /home/oracle/bak/0kr22phj_1_1

File Name: /home/oracle/bak/0nr22pic_1_1

File Name: /home/oracle/bak/09r1eku6_1_1

File Name: /home/oracle/bak/0rr22q7u_1_1

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

cataloging files...

cataloging done

文件编目后,我们就可以开始正式恢复数据库了.

RMAN> recover database;

Starting recover at 03-APR-16

using channel ORA_DISK_1

starting media recovery

.....................................

media recovery complete, elapsed time: 00:03:01

Finished recover at 03-APR-16

备库完成恢复完成后,我们就可以启动redo apply 了.

STANDBY> alter database recover managed standby database disconnect from session using current logfile;

Database altered.

STANDBY> select process,client_process,sequence#,status from v$managed_standby;

PROCESS   CLIENT_P  SEQUENCE# STATUS

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

ARCH  ARCH    0 CONNECTED

ARCH  ARCH    0 CONNECTED

ARCH  ARCH    0 CONNECTED

ARCH  ARCH    0 CONNECTED

ARCH  ARCH    0 CONNECTED

RFS  ARCH    0 IDLE

RFS  LGWR   33 IDLE

MRP0  N/A   33 WAIT_FOR_LOG

现在我们查看备库状态,MRP进程已经开始最新的日志应用了.到此我们通过增量SCN备份和恢复来修复

备库归档日志丢失的过程已经全部完成了.

阅读(3152) | 评论(0) | 转发(0) |

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值