JR50151: CDC FAILED WITH 'THE ORACLE DATABASE DOES NOT CONTAIN VALID REDO LOG FILE...' MESSAGE BECAUSE IT CAN NOT FIND THE ARCHIVED LOGS

Fix list for IBM InfoSphere Change Data Capture

APAR status

• Closed as program error.

Error description

• CDC subscriptioin failed with message. E.g.
  .
  Redo log file information not found for subscription
  SHAREDSCRAPE. The Oracle database does not contain valid redo
  log file information corresponding to the log position
  '6380367593029.0.0.0.0.0.0' for the current database
  incarnation. Error detected in file OracleRedoNativeApi.java at
  line 1178. This may be caused by any of the following: a) The
  SCN portion of the log position 6380367593029.0.0.0.0.0.0 is
  invalid. b) The SCN associated with log position
  6380367593029.0.0.0.0.0.0 does not correspond to a current
  on-line redo log file and ARCHIVELOG mode is not enabled. c) The
  redo log file(s) corresponding to log position
  6380367593029.0.0.0.0.0.0 does not currently exist, exists but
  is inaccessible or exists and is corrupt. d) The control file
  contains invalid information. e) The database was shut down
  abort. Re-start replication will resolve this issue. f) There
  was error archiving redo logs because of insufficient disk
  space. Try to resolve this issue by doing the following and
  re-start replication: a) Change the log position to specify a
  correct SCN value. b) Examine the views V$LOG and V$ARCHIVED_LOG
  to determine a valid SCN for which a corresponding online or
  archived redo log file exists. Change the log position to
  specify a valid SCN for the current database incarnation. c)
  Restore a valid copy of the required redo log file(s) from
  backup. d) Ensure the disk space for archived redo logs is not
  full.
  .
  
  If customer had reset database with a future timestamp (probably
  by setting the system time to a future time for some testing),
  and then reset it again after the system time is set to current,
  then we can have 2 entries in v$database_incarnation where the
  resetlogs_time of current incarnation might be earlier than the
  resetlogs_time of previous incarnation, and since our query to
  get the resetlogs_change# is based on the latest resetlogs_time,
  so we could end up getting incorrect resetlogs_change#. We
  should use the resetlogs_change# with status='CURRENT'
  E.g.
  Executing query: select * from v$database_incarnation
  INCARNATION#    RESETLOGS_CHANGE#    RESETLOGS_TIME
  PRIOR_RESETLOGS_CHANGE#    PRIOR_RESETLOGS_TIME    STATUS
  RESETLOGS_ID    PRIOR_INCARNATION#    FLASHBACK_DATABASE_ALLOWED
  1    6380363283400    2015-06-30 11:30:35.0    6380354690974
  2013-12-09 20:12:58.0    PARENT    883740635    0    NO
  2    6380363439274    2014-01-23 18:43:07.0    6380363283400
  2015-06-30 11:30:35.0    CURRENT    837628987    1    NO
  .
  

Local fix

• Spoof the v$database_incarnation view as this:
  create view <CDC schema name>.v$database_incarnation as select *
  from sys.v_$database_incarnation where status = 'CURRENT'
  

Problem summary

• IIDR 10.2 and 10.2.1 for Oracle Redo can stop mirroring with
  "Information not found" error.
  
  This issue affects users running IIDR 10.2 Interim Fix 14 for
  Oracle Red (and below) and IIDR 10.2.1 Interim Fix 2 for Oracle
  Redo (and below).
  

Problem conclusion

• This issue is fixed by applying the following interim fixes
  depending on the product version:
  - IIDR 10.2 Interim Fix 15 for Oracle Redo; or
  - IIDR 10.2.1 Interim Fix 3 for Oracle Redo.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  IS CDC ORACLE

• Fixed component ID

  5725E30OR

Applicable component levels

• RA20 PSY

     UP