Backup Fails with Invalid RECID Error

Question

Hi All,
Please help me to understand Caution -section
below text is from
[http://download.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmtroub.htm#447765]
Backup Fails with Invalid RECID Error: Solution 2
This solution is more difficult than solution 1:
To create the control file with SQL*Plus:
   1. Connect to the target database with SQL*Plus. For example, enter:
      % sqlplus 'SYS/oracle@trgt AS SYSDBA'
   2. Mount the database if it is not already mounted:
      SQL> ALTER DATABASE MOUNT;
   3. Back up the control file to a trace file:
      SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
   4. Edit the trace file as necessary. The relevant section of the trace file looks something like the following:
      # The following commands will create a new control file and use it
      # to open the database.
      # Data used by the recovery manager will be lost. Additional logs may
      # be required for media recovery of offline data files. Use this
      # only if the current version of all online logs are available.
      STARTUP NOMOUNT
      CREATE CONTROLFILE REUSE DATABASE "TRGT" NORESETLOGS  ARCHIVELOG
      --  STANDBY DATABASE CLUSTER CONSISTENT AND UNPROTECTED
          MAXLOGFILES 32
          MAXLOGMEMBERS 2
          MAXDATAFILES 32
          MAXINSTANCES 1
          MAXLOGHISTORY 226
      LOGFILE
        GROUP 1 '/oracle/oradata/trgt/redo01.log'  SIZE 25M,
        GROUP 2 '/oracle/oradata/trgt/redo02.log'  SIZE 25M,
        GROUP 3 '/oracle/oradata/trgt/redo03.log'  SIZE 500K
      -- STANDBY LOGFILE
      DATAFILE
        '/oracle/oradata/trgt/system01.dbf',
        '/oracle/oradata/trgt/undotbs01.dbf',
        '/oracle/oradata/trgt/cwmlite01.dbf',
        '/oracle/oradata/trgt/drsys01.dbf',
        '/oracle/oradata/trgt/example01.dbf',
        '/oracle/oradata/trgt/indx01.dbf',
        '/oracle/oradata/trgt/tools01.dbf',
        '/oracle/oradata/trgt/users01.dbf'
      CHARACTER SET WE8DEC
      # Take files offline to match current control file.
      ALTER DATABASE DATAFILE '/oracle/oradata/trgt/tools01.dbf' OFFLINE;
      ALTER DATABASE DATAFILE '/oracle/oradata/trgt/users01.dbf' OFFLINE;
      # Configure RMAN configuration record 1
      VARIABLE RECNO NUMBER;
      EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','DEVICE TYPE DISK
      DEBUG 255');
      # Recovery is required if any of the datafiles are restored backups,
      # or if the last shutdown was not normal or immediate.
      RECOVER DATABASE
      # All logs need archiving and a log switch is needed.
      ALTER SYSTEM ARCHIVE LOG ALL;
      # Database can now be opened normally.
      ALTER DATABASE OPEN;
      # Commands to add tempfiles to temporary tablespaces.
      # Online tempfiles have complete space information.
      # Other tempfiles may require adjustment.
      ALTER TABLESPACE TEMP ADD TEMPFILE '/oracle/oradata/trgt/temp01.dbf' REUSE;
      # End of tempfile additions.
   5. Shut down the database:
      SHUTDOWN IMMEDIATE
   6. Execute the script to create the control file, recover (if necessary), archive the logs, and open the database:
      STARTUP NOMOUNT
      CREATE CONTROLFILE ...;
      EXECUTE ...;
      RECOVER DATABASE
      ALTER SYSTEM ARCHIVE LOG CURRENT;
      ALTER DATABASE OPEN ...;
Caution:
      If you do not open with the RESETLOGS option,
then two copies of an archived redo log for a given log sequence number may
exist--even though these two copies have completely different contents.
For example, one log may have been created on the original host and the other on the new host.
If you accidentally confuse the logs during a media recovery,
then the database will be corrupted but Oracle and RMAN cannot detect the problem.

Answer 1

Please help me to understand Caution -section
Caution:
If you do not open with the RESETLOGS option,
then two copies of an archived redo log for a given log sequence number may
exist--even though these two copies have completely different contents.
For example, one log may have been created on the original host and the other on the new host.
If you accidentally confuse the logs during a media recovery,
then the database will be corrupted but Oracle and RMAN cannot detect the problem.As per my understanding it says. If you don't open database with RESETLOGS option then there may be archived logs with log sequence number which is already archived on the source host. This may happen due to difference in RECIDs. Now when the database needs media recovery for this particular log sequence, you may provide any of them. So in this case, RMAN and Oracle will not be able to differentiate the two files and can accept any of the archived log files during recovery. Since the contents of two archived logs are different, because they are generated at different times and they contains different transactions. So, internally it corrupts your database.
Rgds.