惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
Microsoft Azure Blog
Microsoft Azure Blog
MongoDB | Blog
MongoDB | Blog
小众软件
小众软件
Apple Machine Learning Research
Apple Machine Learning Research
O
OpenAI News
酷 壳 – CoolShell
酷 壳 – CoolShell
The GitHub Blog
The GitHub Blog
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
博客园 - 聂微东
Engineering at Meta
Engineering at Meta
W
WeLiveSecurity
Hacker News: Ask HN
Hacker News: Ask HN
大猫的无限游戏
大猫的无限游戏
Vercel News
Vercel News
D
Docker
F
Full Disclosure
AI
AI
罗磊的独立博客
博客园 - 【当耐特】
U
Unit 42
S
SegmentFault 最新的问题
Stack Overflow Blog
Stack Overflow Blog
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
P
Palo Alto Networks Blog
博客园_首页
H
Help Net Security
量子位
月光博客
月光博客
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
博客园 - 司徒正美
F
Fortinet All Blogs
D
DataBreaches.Net
B
Blog RSS Feed
Webroot Blog
Webroot Blog
TaoSecurity Blog
TaoSecurity Blog
S
Secure Thoughts
爱范儿
爱范儿
I
InfoQ
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
www.infosecurity-magazine.com
www.infosecurity-magazine.com
Attack and Defense Labs
Attack and Defense Labs
Application and Cybersecurity Blog
Application and Cybersecurity Blog
C
CERT Recently Published Vulnerability Notes
Martin Fowler
Martin Fowler
Blog — PlanetScale
Blog — PlanetScale
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
S
Securelist

博客园 - 孙晓东

perl多线程理解 ORA-00020: No more process state objects available故障一例 SOA架构设计经验分享—架构、职责、数据一致性 ORACLE之ASM概念 Oracle Dataguard的原理与基本配置 oracle之报错:ORA-00054: 资源正忙,要求指定 NOWAIT linux挂载windows上的共享文件夹 oracle操作之传输表空间 dba诊断之IO 用SecureCRT在windows和CentOS间上传下载文件 Centos6.5下设置静态IP oracle 11g dataguard创建的简单方法 linux下mysql安装、目录结构、配置 dba诊断之lock oracle11G在linux环境下的卸载操作 Ubuntu 14.04(32位)安装Oracle 11g(32位)全过程 linux系统下设置oracle开机自动启动 Redhat6.5 安装64位oracle11.2.0.1 异机恢复perform restores
利用增量备份恢复因归档丢失造成的DG gap
孙晓东 · 2016-01-18 · via 博客园 - 孙晓东

故障现象:
data guard归档出现gap,悲剧的是丢失的归档在主库上被rman备份时删除了,丢失的归档大约有20几个,数据库大小约2T,如果重建DG将非常耗时间,因此决定利用增量备份的方式恢复DG,主要步骤如下:
1.备份备库spfile文件
SQL> create pfile='/home/ora/pfileRdg.ora' from spfile;

2、查看当前备库scn
SQL> select to_char(current_scn) from v$database;

TO_CHAR(CURRENT_SCN)
----------------------------------------
19652214434
3、查看缺失的archivelog
SQL> select * from v$archive_gap;

   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
         1        160163         160170
         2        151303         151309
、在主库执增量备份

[ora@jzhRAC1 ~]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Sat May 23 18:10:52 2015

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: JZH (DBID=2072634265)
RMAN> run
2> {
3> allocate channel d1 type disk;
4> allocate channel d2 type disk;
5> allocate channel d3 type disk;
6> backup as compressed backupset incremental from SCN 19652214434 database format '/home/ora/full_db_%d_%T_%s.bak' include current controlfile for standby 

filesperset=5 tag 'FOR STANDBY';
7> release channel d1;
8> release channel d2;
9> release channel d3;
10> }
channel d1: backup set complete, elapsed time: 00:00:35
channel d1: starting compressed full datafile backupset
channel d1: specifying datafile(s) in backupset
input datafile fno=00124 name=/oradata/JZH/TP_CTEST15.ORA
input datafile fno=00186 name=/oradata/JZH/TP_LEARNING01.ORA
input datafile fno=00187 name=/oradata/JZH/TP_LEARNING02.ORA
input datafile fno=00188 name=/oradata/JZH/TP_LEARNING03.ORA
input datafile fno=00191 name=/oradata/JZH/TP_LEARNING06.ORA
channel d1: starting piece 1 at 23-MAY-15
channel d3: finished piece 1 at 23-MAY-15
piece handle=/home/ora/full_db_JZH_20150523_232604.bak tag=FOR STANDBY comment=NONE
channel d3: backup set complete, elapsed time: 00:00:36
channel d3: starting compressed full datafile backupset
channel d3: specifying datafile(s) in backupset
input datafile fno=00192 name=/oradata/JZH/TP_LEARNING07.ORA
input datafile fno=00239 name=/oradata/JZH/TP_LEARNING08.ORA
input datafile fno=00250 name=/oradata/JZH/TP_LEARNING09.ORA
input datafile fno=00261 name=/oradata/JZH/TP_CTEST16.ORA
input datafile fno=00267 name=/oradata/JZH/TP_LEARNING10.ORA
channel d3: starting piece 1 at 23-MAY-15
channel d2: finished piece 1 at 23-MAY-15
piece handle=/home/ora/full_db_JZH_20150523_232602.bak tag=FOR STANDBY comment=NONE
channel d2: backup set complete, elapsed time: 00:01:08
channel d2: starting compressed full datafile backupset
channel d2: specifying datafile(s) in backupset
input datafile fno=00272 name=/oradata/JZH/TP_CTEST17.ORA
input datafile fno=00284 name=/oradata/JZH/TP_CTEST18.ORA
input datafile fno=00288 name=/oradata/JZH/TP_LEARNING11.ORA
input datafile fno=00296 name=/oradata/JZH/TP_CTEST19.ORA
input datafile fno=00313 name=/oradata/JZH/TP_LEARNING12.ORA
channel d2: starting piece 1 at 23-MAY-15
channel d1: finished piece 1 at 23-MAY-15
piece handle=/home/ora/full_db_JZH_20150523_232606.bak tag=FOR STANDBY comment=NONE
channel d1: backup set complete, elapsed time: 00:00:32
channel d1: starting compressed full datafile backupset
channel d1: specifying datafile(s) in backupset
input datafile fno=00338 name=/oradata/JZH/TP_LEARNING15.ORA
input datafile fno=00342 name=/oradata/JZH/TP_CTEST22.ORA
channel d1: starting piece 1 at 23-MAY-15
channel d3: finished piece 1 at 23-MAY-15
piece handle=/home/ora/full_db_JZH_20150523_232607.bak tag=FOR STANDBY comment=NONE
channel d3: backup set complete, elapsed time: 00:00:32
channel d3: starting compressed full datafile backupset
channel d3: specifying datafile(s) in backupset
including standby control file in backupset
channel d3: starting piece 1 at 23-MAY-15
channel d1: finished piece 1 at 23-MAY-15
piece handle=/home/ora/full_db_JZH_20150523_232609.bak tag=FOR STANDBY comment=NONE
channel d1: backup set complete, elapsed time: 00:00:06
channel d1: starting compressed full datafile backupset
channel d1: specifying datafile(s) in backupset
including current SPFILE in backupset
channel d1: starting piece 1 at 23-MAY-15
channel d3: finished piece 1 at 23-MAY-15
piece handle=/home/ora/full_db_JZH_20150523_232610.bak tag=FOR STANDBY comment=NONE
channel d3: backup set complete, elapsed time: 00:00:08
channel d1: finished piece 1 at 23-MAY-15
piece handle=/home/ora/full_db_JZH_20150523_232611.bak tag=FOR STANDBY comment=NONE
channel d1: backup set complete, elapsed time: 00:00:02
channel d2: finished piece 1 at 23-MAY-15
piece handle=/home/ora/full_db_JZH_20150523_232608.bak tag=FOR STANDBY comment=NONE
channel d2: backup set complete, elapsed time: 00:00:32
Finished backup at 23-MAY-15

released channel: d1

released channel: d2

released channel: d3

5、将备份传至备库
scp full_db_JZH_20150523_*.bak 192.168.110.115:~/20150523_recover/ 
6、恢复备库
[ora@jzhDG ~]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Sat May 23 20:17:59 2015

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: JZH (DBID=2072634265, not open)

RMAN> catalog start with '/home/ora/20150523_recover';

[ora@jzhDG ~]$ rman target /

Recovery Manager: Release 10.2.0.4.0 - Production on Sat May 23 20:25:44 2015

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: JZH (DBID=2072634265, not open)

RMAN> run
2> {
3> allocate channel d1 type disk;
4> allocate channel d2 type disk;
5> allocate channel d3 type disk;
6> restore standby controlfile to '/home/ora/control01.ctl';
7> recover database noredo;
8> release channel d1;
9> release channel d2;
10> release channel d3;
11> }
7、关闭备库,将恢复出来的control01.ctl覆盖备库控制文件
[ora@jzhDG ~]$ cp control01.ctl /oradata/JZH/standby.ctl
8、启动备库至mount状态
SQL> startup mount
ORACLE instance started.
Total System Global Area 1795162112 bytes
Fixed Size                  2084648 bytes
Variable Size             301990104 bytes
Database Buffers         1476395008 bytes
Redo Buffers               14692352 bytes
Database mounted.
9、查看gap
SQL> select * from v$archive_gap;
no rows selected
10、开启备库recover模式
SQL> recover managed standby database disconnect from session;
Media recovery complete.
11、查看日志,正在恢复
Sat May 23 21:17:53 2015
Media Recovery Log /oradata/standby_arch/1_161210_706979804.log
Sat May 23 21:18:15 2015
Media Recovery Log /oradata/standby_arch/1_161211_706979804.log
Media Recovery Log /oradata/standby_arch/2_152328_706979804.log
Sat May 23 21:19:14 2015
Media Recovery Log /oradata/standby_arch/1_161212_706979804.log
Sat May 23 21:20:06 2015
Media Recovery Log /oradata/standby_arch/2_152329_706979804.log
Sat May 23 21:20:29 2015
Media Recovery Log /oradata/standby_arch/1_161213_706979804.log
Media Recovery Log /oradata/standby_arch/2_152330_706979804.log
Sat May 23 21:20:50 2015
Media Recovery Log /oradata/standby_arch/2_152331_706979804.log
Media Recovery Log /oradata/standby_arch/1_161214_706979804.log
Sat May 23 21:21:10 2015
Media Recovery Log /oradata/standby_arch/1_161215_706979804.log
Sat May 23 21:21:20 2015
Media Recovery Log /oradata/standby_arch/2_152332_706979804.log
Sat May 23 21:21:31 2015
Media Recovery Log /oradata/standby_arch/1_161216_706979804.log
Sat May 23 21:21:41 2015
Media Recovery Log /oradata/standby_arch/2_152333_706979804.log
Sat May 23 21:21:53 2015
Media Recovery Waiting for thread 1 sequence 161217