10.2.0.4 for both target and catalog database
We run RMAN backup on primary using catalog. On physical standby, if I also connect to the catalog (rman target / catalog rman/password@ctlg), it seems, some time later back on the primary, there'll be inconsistency between list expired archivelog and crosscheck archivelog:
RMAN> crosscheck archivelog all;
...
Crosschecked 25 objects
validation failed for archived log
archive log filename=+FRA/edmsp/2_14402_638201400.arc recid=36154 stamp=679226228
Crosschecked 1 objects
RMAN> list expired archivelog all;
specification does not match any archive log in the recovery catalog
So, why does list expired not list the not found archivelog? In fact, delete expired won't find it either. To clean up, I just delete the actual file. Note the status (column S below) shows "X":
RMAN> delete noprompt archivelog '+FRA/edmsp/2_14402_638201400.arc';
released channel: ORA_DISK_1
released channel: ORA_DISK_2
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=2275 instance=edmsp1 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=2295 instance=edmsp1 devtype=DISK
List of Archived Log Copies
Key Thrd Seq S Low Time Name
------- ---- ------- - ----------------- ----
2677243 2 14402 X 20090219 09:02:04 +FRA/edmsp/2_14402_638201400.arc
deleted archive log
archive log filename=+FRA/edmsp/2_14402_638201400.arc recid=36154 stamp=679226228
Deleted 1 objects
Since the standby uses the same DB ID, key, and name as primary, and even our ASM file path is the same, an implicit resync from the standby controlfile adds confusing records to the catalog. So I guess
we should not connect standby to the same catalog. But I can't find this warning on Google or Metalink. The only discussion maybe relevant is
501567
where oradba guessed the cause. On the other hand, I think the catalog actually knows a record is from primary or standby (is_standby column of rc_archived_log). Why the confusion then?
Any comments are welcome.
Yong Huang
yong321 @ yahoo.com
Edited by: yong321 on Feb 25, 2009 12:19 PM