欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

基于SCN增量恢复DG同步

程序员文章站 2022-04-15 14:05:33
问题描述:做scn恢复备库的测试,吭哧了几天,今天终于可以记录一下,遇到了很多坑,作为初学者可以更好地理解DG,主要先关闭备库,在主库做归档丢失备库无法同步,备库产生GAP,然后增量备份恢复备库,版本:SQL*Plus: Release 11.2.0.4.0 Production on Thu No ......

问题描述:做scn恢复备库的测试,吭哧了几天,今天终于可以记录一下,遇到了很多坑,作为初学者可以更好地理解dg,主要先关闭备库,在主库做归档丢失备库无法同步,备库产生gap,然后增量备份恢复备库,版本:sql*plus: release 11.2.0.4.0 production on thu nov 28 09:33:14 2019

1.备库操作:关闭备库,关闭之前首先要检查一下主备是否同步,否则会产生一些不必要的麻烦

sql> select process,client_process,sequence#,status,block#,blocks from v$managed_standby;    检查一下备库进程,mrp进程正在等待应用进程,然后就需要重新应用一下保持dg同步

基于SCN增量恢复DG同步

 

 

sql> recover managed standby database cancel;                  关闭一下实时应用

sql> select process,client_process,sequence#,status,block#,blocks from v$managed_standby;        这个时候实时应用关闭,mrp进程是被关掉的,日志中都可以看到

基于SCN增量恢复DG同步

 

 

sql> alter database recover managed standby database using current logfile disconnect from session;    开启实时同步,这个时候mrp进程是起来的

基于SCN增量恢复DG同步

 

 

 sql> select process,client_process,status,sequence#,block#,blocks from v$managed_standby;   查询一下wait状态变成了applying应用状态

基于SCN增量恢复DG同步

 

 

2.关闭备库,前边都是废话,检查一下备库是否同步,下边取消实时应用,也就是关掉

sql> recover managed standby database cancel;

sql> shutdown immediate

基于SCN增量恢复DG同步

 

 

3.主库上操作:模拟归档丢失,这时备库的已经关掉

sql> alter system switch logfile;

 基于SCN增量恢复DG同步

 

 

sql> select max(sequence#) from v$archived_log;   查询一下归档序号到了24号

基于SCN增量恢复DG同步

 

 

sql> archive log list                          这里写一下查找归档路径的方法,不用在意我这里的归档号,这是后来补上的图,当时没做这个操作,查到路径在use_db_recovery_file_dest,这是系统默认的闪回去内,这里也可以修改的。

基于SCN增量恢复DG同步

 

 

sql> show parameter log_archive_dest_1

基于SCN增量恢复DG同步

 

 

sql> desc v$archived_log

基于SCN增量恢复DG同步

 

 

sql> select name from v$archived_log;                 按照这个步骤来可以找到归档的路径

基于SCN增量恢复DG同步

 

 

[root@orcl ~]# cd /home/oracle/flashdata/orcl/archivelog/2019_11_27/                找到该路径,我切换了两次,所以序列号到24

基于SCN增量恢复DG同步

 

 

 

4.这里对比一下备库的序列号,注意这里是备库截至到序列号是22,下边是我遇到的一个大坑

基于SCN增量恢复DG同步

 

 

这里让主库模拟丢失的本来是23和24,但是备库一直出现不了gap的状态,后来一看备库日志说的是23已经再被运输中(in transit),所以说这里如果备库重新启动23是直接被应用的,如果把23号归档mv掉,是产生不了gap的,所以要模拟mv掉归档 就mv 24号归档,也就是切换的第二个归档,这里需要注意下

 

 

 

 基于SCN增量恢复DG同步

 

5.主库继续模拟丢失归档

[root@orcl 2019_11_27]# mv o1_mf_1_24_gxx0qq27_.arc /tmp    这里我随便挪到一个目录下

 

 基于SCN增量恢复DG同步

 

 

6.备库上:启动备库,查看gap

sql> startup mount

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

sql> select process,client_process,sequence#,status,block#,blocks from v$managed_standby;       已经可以看到mrp进程正在等待gap24号

基于SCN增量恢复DG同步

 

 

基于SCN增量恢复DG同步

 

 

这个是日志截图都是gap24号

sql>  select * from v$archive_gap;   这些都可以查到

基于SCN增量恢复DG同步

 

 

7.主库上:查询到24号归档的scn号,然后做增量备份,这里要做的是在主库上查询到24号归档的scn号,也就是在对24号归档做操作之前的记录,然后在备库增量恢复

sql> select first_change#  from v$archived_log where sequence#  =24;    查询到24号归档之前的操作

基于SCN增量恢复DG同步

 

 

sql> select current_scn from v$database;   确认一下24号scn号的范围怎么样,这里是当前的归档号

基于SCN增量恢复DG同步

 

 

8.主库上做基于1110582的备份

[oracle@orcl ~]$ rman target /

rman> backup as compressed backupset incremental from scn 1110582 database format '/home/oracle/standby_%d_%t_%u.bak' include current controlfile for standby filesperset=5 tag 'for standby';       这里要看一下哪个是控制文件,以及rman备份文件的权限问题

基于SCN增量恢复DG同步

 

这里查看一下备份的文件

 

基于SCN增量恢复DG同步

 

 

9.传输到备库  /home/oracle下

[oracle@orcl ~]$ scp *.bak 192.168.1.5:/home/oracle

基于SCN增量恢复DG同步

 

10.在备库上进行恢复scn号,首先恢复控制文件

 

[root@orclstd oracle]# su - oracle
[oracle@orclstd ~]$ rman target /

rman> restore standby controlfile from '/home/oracle/standby_orcl_20191127_0euhv1rm_1_1.bak';

基于SCN增量恢复DG同步

 

 

rman> alter database mount;     到mount状态

rman> catalog start with'/home/oracle';     注册一下传输过来的备份,这里rman有一个文件头损坏的报错,这里不影响后边的报错,但是我没有理解

基于SCN增量恢复DG同步

 

 

 基于SCN增量恢复DG同步

 

 

 rman> recover database noredo; 增量恢复备份文件

基于SCN增量恢复DG同步

 

 

11.验证,这里状态都变成了应用日志,这里也可以在主库多切换几次日志,看看备库有没有实时同步

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

media recovery complete.
sql> select process,status,sequence# from v$managed_standby;

基于SCN增量恢复DG同步

 

基于SCN增量恢复DG同步