Capture stopped: missing archive due to capture processed old archivedlogs again after database reset.
Event_log entries:
Error 2018-02-27 10:34:23.790166 70434 759891712 Capture: [SP-OCT01001] Unable to find archivelog with sequence#: 174 (thread: 1). SharePlex was unable to locate the redo/archive log for sequence 174 in the database location or under the directory defined by SP_OCT_ARCH_LOC parameter. Restore this archivelog to archive location if missing or set the file's location using SP_OCT_ARCH_LOC. Make sure it is not compressed then restart capture. See 'http://advice.shareplex.com/SP-OCT01001' for additional advice and support. (capturing from o.DATASOURCE) [module oct] Info 2018-02-27 10:34:23.796153 52504 2180519808 Capture exited with code=1, pid = 70434 (capturing from o.DATASOURCE) SYS@o.DATASOURCE>archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination /nfs/xxxxx/xxxxxxarch/xxxxx Oldest online log sequence 164 Next log sequence to archive 173 Current log sequence 173
Capture log entries:
ocap 2018-02-12 00:16:17.372131 123988 897963776 opening seek = 2, since seqno = 1
ocap 2018-02-12 00:16:17.436471 123988 897963776 opening seek = 3, since seqno = 2
ocap 2018-02-12 02:26:56.179476 123988 897963776 opening seek = 4, since seqno = 3
ocap 2018-02-12 02:30:48.750291 123988 897963776 opening seek = 5, since seqno = 4
ocap 2018-02-12 02:34:03.997790 123988 897963776 Got BAD Block error, might be incomplete/transient data block at seqno=5 offset=11416468
ocap 2018-02-12 02:34:04.137254 123988 897963776 opening seek = 6, since seqno = 5
ocap 2018-02-12 02:34:30.906146 123988 897963776 opening seek = 7, since seqno = 6
The source Oracle redologs were reset creating two entries of same sequence# due to resetlogs. The SharePlex reset code will be fixed in a future release above 9 issue logged in SPO-12929. If you run the below query, it shows the same sequence # more than once after resetting the logs and there is a resetlogs_id with each reset and it is tied to the sequence number, see below output when new rest is done on 2/11/2018.
select sequence#, first_time, resetlogs_change#, restlogs_time, resetlogs_id from gv$archived_log;
SEQUENCE# FIRST_TIME RESETLOGS_CHANGE# RESETLOGS_TIME RESETLOGS_ID
--------------------
2 01112018083103 1393223603485 01112018063942 965111982
1 01112018063942 1393223603485 01112018063942 965111982
The new seqno 1 has restlogs_id of 967846887 which the new reset is done on 2/11/2018
SEQUENCE# FIRST_TIME RESETLOGS_CHANGE# RESETLOGS_TIME RESETLOGS_ID
--------------------
1 02112018222127 1424374807498 02112018222127 967846887
Workaround 1:
1. Remove the old archive logs from rman after the Oracle logs were reset
2. Once capture moves onto the new set of logs, run Oracle rman command 'crosscheck archive log all', to get rid of the old entries in gv$archived_log
Workaround 2:
1. run ora_cleansp on source and target
Note: Would need to resync the target if the issue already occurred even with work around of getting rid of old entries in gv$archived_log
