catalog with无法识别所有的备份copy

在dg搭建的时候，经常会有路径不一致的问题

restore完成后数据文件在新的目录，但是controlfile从主库来的，不知道新目录在哪，所以需要catalog with让rman去发现备份文件或copy

 

我start with '+data'后，switch datafile to copy无法转换
RMAN> list copy;

specification does not match any archive log in the recovery catalog

List of Datafile Copies
Key     File S Completion Time Ckp SCN    Ckp Time        Name
------- ---- - --------------- ---------- --------------- ----
27      1    A 05-JUN-20       105923818414 28-MAY-20       +DATA/lisdb_new/datafile/system.342.1042250593
26      2    A 05-JUN-20       105923818418 28-MAY-20       +DATA/lisdb_new/datafile/undotbs1.298.1042250561
23      3    A 05-JUN-20       105923818414 28-MAY-20       +DATA/lisdb_new/datafile/sysaux.332.1042250501
31      4    A 05-JUN-20       105923818412 28-MAY-20       +DATA/lisdb_new/datafile/users.350.1042250647
29      5    A 05-JUN-20       105923818420 28-MAY-20       +DATA/lisdb_new/datafile/example.328.1042250641
25      6    A 05-JUN-20       105923818414 28-MAY-20       +DATA/lisdb_new/datafile/undotbs2.319.1042250561
24      46   A 05-JUN-20       105923818412 28-MAY-20       +DATA/lisdb_new/datafile/apply.336.1042250527
22      47   A 05-JUN-20       105923818412 28-MAY-20       +DATA/lisdb_new/datafile/report.326.1042248599
30      107  A 05-JUN-20       105923818420 28-MAY-20       +DATA/lisdb_new/datafile/bfuser_data.349.1042250643
12      107  A 17-OCT-17       39054767633 17-OCT-17       /oracle/oracle/product/10.2.0/db_1/dbs/D:oracleoradataOracle9ibfuser_data.dbf
7       107  A 17-OCT-17       39054767633 17-OCT-17       /oracle/oracle/datafile107.bak
28      108  A 05-JUN-20       105923818418 28-MAY-20       +DATA/lisdb_new/datafile/bf1user_data.334.1042250619
13      108  A 17-OCT-17       39051781996 17-OCT-17       /oracle/oracle/datafile108.bak
9       108  A 17-OCT-17       39051781996 17-OCT-17       /oracle/oracle/product/10.2.0/db_1/dbs/D:oracleoradataOracle9ibf1user_data.dbf

List of Control File Copies
Key     S Completion Time Ckp SCN    Ckp Time        Name
------- - --------------- ---------- --------------- ----
6       A 22-DEC-15       22292804510 22-DEC-15       /home/oracle/enmo/rda/temp/TMP_output/DB_BR_T20114_01_control.tmp
5       A 22-DEC-15       22292507019 22-DEC-15       /home/oracle/enmo/rda/temp/TMP_output/DB_BR_T07434_01_control.tmp
4       A 26-JUN-14       10435301876 26-JUN-14       /oracle/oracle/hcheck/rda/output/TMP_RDA/RDA_BR_T24104_01_control.tmp
3       A 26-JUN-14       10434533599 26-JUN-14       /oracle/oracle/hcheck/rda/output/TMP_RDA/RDA_BR_T05937_01_control.tmp
2       A 26-JUN-14       10434398615 26-JUN-14       /oracle/oracle/hcheck/rda/output/TMP_RDA/RDA_BR_T19736_01_control.tmp
21      A 04-JUN-20       106573424837 04-JUN-20       /backup/controlfile.ora
20      A 04-JUN-20       106530552261 04-JUN-20       /backup/controlfinal
19      A 02-JUN-20       106400293784 02-JUN-20       /backup/control123
18      A 02-JUN-20       106372428919 02-JUN-20       /backup/control.ora
17      A 02-JUN-20       106352951262 02-JUN-20       /backup/controlfile

检查发现，

asmcmd中的数据文件为135个，跟主库的datafile数量一致，说明我的restore没有问题

但是list copy明显没有那么多，说明catalog没有识别到我的copy

 rman有catalog datafilecopy指定数据文件copy

 

下面我就使用asmcmd中的数据文件名，通过批量编辑命令和目录，在rman中执行

catalog datafilecopy指定所有数据文件

RMAN>  catalog datafilecopy '+DATA/lisdb_new/datafile/BISREPORT.394.1042242155'

此处省略133行···
catalog datafilecopy '+data/lisdb_new/datafile/USERS.350.1042250647'

 

全部注册成功

switch切换数据库到copy，这个时候控制文件中记录的文件路径就由主库的datafile转换成了备库asm上的正确路径
RMAN> switch database to copy;

datafile 1 switched to datafile copy "+DATA/lisdb_new/datafile/system.342.1042250593"
datafile 2 switched to datafile copy "+DATA/lisdb_new/datafile/undotbs1.298.1042250561"
datafile 3 switched to datafile copy "+DATA/lisdb_new/datafile/sysaux.332.1042250501"
...
datafile 135 switched to datafile copy "+DATA/lisdb_new/datafile/bisreport.331.1042247189"

 

随后指定归档备份的路径，开始recover

RMAN> catalog start with '/backup';

searching for all files that match the pattern /backup
no files found to be unknown to the database

RMAN> recover database;

Starting recover at 05-JUN-20
using channel ORA_DISK_1

starting media recovery

channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=22017
channel ORA_DISK_1: reading from backup piece /backup/lisdb_full_6323_1_1041644764
channel ORA_DISK_1: restored backup piece 1
piece handle=/backup/lisdb_full_6323_1_1041644764 tag=TAG20200529T014604
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
archive log filename=+ARCH/lisdb_new/archivelog/2020_06_05/thread_1_seq_22017.285.1042279325 thread=1 sequence=22017
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=2 sequence=21546
channel ORA_DISK_1: reading from backup piece /backup/lisdb_full_6322_1_1041644764
channel ORA_DISK_1: restored backup piece 1
piece handle=/backup/lisdb_full_6322_1_1041644764 tag=TAG20200529T014604
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
archive log filename=+ARCH/lisdb_new/archivelog/2020_06_05/thread_2_seq_21546.284.1042279327 thread=2 sequence=21546
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=22018
channel ORA_DISK_1: reading from backup piece /backup/thread_1_seq_22018.835.1042009611
channel ORA_DISK_1: restored backup piece 1
piece handle=/backup/thread_1_seq_22018.835.1042009611 tag=TAG20200604T103859
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
archive log filename=+ARCH/lisdb_new/archivelog/2020_06_05/thread_1_seq_22018.283.1042279337 thread=1 sequence=22018
unable to find archive log
archive log thread=2 sequence=21547
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/05/2020 10:02:20
RMAN-06054: media recovery requesting unknown log: thread 2 seq 21547 lowscn 105997593635

查看到备库需要使用seq21547，该归档在主库上，可以打开dg同步了

SQL> /

NAME                                                                                                    THREAD#  SEQUENCE# ARC APP S COMPLETION_T
---------------------------------------------------------------------------------------------------- ---------- ---------- --- --- - ------------
+FRA/lisdb/archivelog/2020_06_01/thread_2_seq_21547.493.1041912007                                            2      21547 YES NO  A 01-JUN-20
lisdb_new                                                                                                     2      21547 YES YES A 04-JUN-20
+FRA/lisdb/archivelog/2020_06_02/thread_2_seq_21548.826.1042063871                                            2      21548 YES NO  A 02-JUN-20
...                                                                                                 1      22020 YES YES A 03-JUN-20
+FRA/lisdb/archivelog/2020_06_04/thread_1_seq_22021.392.1042228871                                            1      22021 YES NO  A 04-JUN-20
+FRA/lisdb/archivelog/2020_06_04/thread_1_seq_22022.338.1042229359                                            1      22022 YES NO  A 04-JUN-20
lisdb_new                                                                                                     1      22022 YES NO  A 04-JUN-20

19 rows selected.

SQL> l
  1* select NAME,THREAD#,SEQUENCE#,ARCHIVED,APPLIED,STATUS,COMPLETION_TIME from v$archived_log where name is not null order by 3,1

 

配置standby logfile

alter database add standby logfile thread 1 group 10 '+data' size 500m;
alter database add standby logfile thread 1 group 11 '+data' size 500m;
alter database add standby logfile thread 1 group 12 '+data' size 500m;
alter database add standby logfile thread 1 group 13 '+data' size 500m;
alter database add standby logfile thread 1 group 14 '+data' size 500m;
alter database add standby logfile thread 1 group 15 '+data' size 500m;
alter database add standby logfile thread 1 group 16 '+data' size 500m;
alter database add standby logfile thread 1 group 17 '+data' size 500m;

打开dg同步
alter database recover managed standby database using current logfile disconnect from session;

 

检查dg同步正常就ok了

#主库，查看archive dest是否有报错

col DESTINATION for a50

 SELECT DESTINATION, STATUS, ERROR FROM V$ARCHIVE_DEST ;

#检查进程情况

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

 

#检查日志间隔

select thread#,low_sequence#,high_sequence# from v$archive_gap;

 

col name for a25

 col value for a20

col unit for a30

 set lines 120

select name,value,unit,time_computed from v$dataguard_stats where name in ('transport lag','apply lag');