Bug No. 1334388 Filed 20-JUN-2000 Updated 03-APR-2001 Product Oracle Server - Enterprise Edition V7 Product Version 8.1.6 Platform Sun Solaris V2 Sparc Platform Version 2.7 Database Version 8.1.6 Affects Platforms Generic Priority Severe Loss of Service Status Q/A To Development Base Bug N/A Fixed in Product Version 9.0.1 Problem statement: ALLOCATE CHANNEL CONNECT-CLAUSE DOES WORK WITH NON-OPS ENVIRONMENT -------------------------------------------------------------------------------- ========================================= PROBLEM: 1. Clear description of the problem encountered: The RMAN command "allocate channel ... connect system/manager@db" should be more robust. It MUST check either if the target databaseid matches the databaseid of the database mentioned in the connect clause, or it MUST check if the target and database mentioned in the connect clause are part of the same OPS environment. 2. Pertinent configuration information (MTS/OPS/distributed/etc): N/A 3. Indication of the frequency and predictability of the problem: Always. 4. Sequence of events leading to the problem: Following configuration: 1. Cst is using DISK based backup with RMAN; 2. TARGET database runs on MachineB (with inadequate diskspace to accomodate RMAN backup to disk); 3. RCVCAT database run on MachineA (with plenty diskspace available to accomodate the backup); 4. Cst (mis)used the "allocate channel ... connect system/manager@db" to re-direct the TARGET database backup to be stored on MachineA. See the RMAN script: RMAN> connect rcvcat rmancat/secure@mon; 2> connect target sys/memphis@bak; 3> 4> run 5> { 6> allocate channel d00 type disk format '/db/orabackup/bak/%n.full.%s.%p.%u' connect sys/memphis@mon; 7> set limit channel d00 kbytes 2097150 ; 8> sql 'alter system archive log current'; 9> backup 10> tag 'bak_full' 11> database; 12> sql 'alter system archive log current'; 13> } 14> => RMAN backup is successfull! 5. Technical impact on the customer. Include persistent after effects: This is an unwanted situation, cause the backup for the target cannot be restored for the target cause it is not 'logged' in the RCVCAT with the TARGET databaseid (A RMAN list backup for target returns no rows. ========================================= DIAGNOSTIC ANALYSIS: Allthough the RMAN command "allocate channel ... connect-clause" is intended to be used in an OPS environment it can also be used in a 'normal' (non-OPS) database environment. RMAN should check whether the DBID of the TARGET matches the DBID of the database which is connect to in the "allocate channel" command. ========================================= WORKAROUND: Do not use the "allocate channel" with the "connect clause" with RMAN in a non-OPS environment. ========================================= RELATED BUGS: None found ========================================= REPRODUCIBILITY: Always. ========================================= TESTCASE: Here is the complete script AND output from RMAN: RMAN> connect rcvcat rmancat/secure@mon; 2> connect target sys/memphis@bak; 3> 4> run 5> { 6> allocate channel d00 type disk format '/db/orabackup/bak/%n.%s.%p.%u' connect sys/memphis@mon; 7> set limit channel d00 kbytes 2097150 ; 8> backup 9> tag 'bak_full' 10> database; 11> } 12> 13> RMAN-06008: connected to recovery catalog database RMAN-06005: connected to target database: BAK (DBID=836505560) RMAN-03022: compiling command: allocate RMAN-03023: executing command: allocate RMAN-08030: allocated channel: d00 RMAN-08500: channel d00: sid=17 devtype=DISK RMAN-03022: compiling command: set limit RMAN-03023: executing command: set limit RMAN-03022: compiling command: backup RMAN-03023: executing command: backup RMAN-08008: channel d00: starting full datafile backupset RMAN-08502: set_count=14 set_stamp=400435935 creation_time=16-JUN-00 RMAN-08010: channel d00: specifying datafile(s) in backupset RMAN-08522: input datafile fno=00001 name=/db/oradata/bak/sysbak01.ora RMAN-08011: including current controlfile in backupset RMAN-08522: input datafile fno=00002 name=/db/oradata/bak/rollback01.ora RMAN-08522: input datafile fno=00003 name=/db/oradata/bak/users01.ora RMAN-08013: channel d00: piece 1 created RMAN-08503: piece handle=/db/orabackup/bak/BAKxxxxx.14.1.0ebtsamv comment=NONE RMAN-08525: backup set complete, elapsed time: 00:00:25 RMAN-03023: executing command: partial resync RMAN-08003: starting partial resync of recovery catalog RMAN-08005: partial resync complete RMAN-08031: released channel: d00 Recovery Manager complete. ========================================= STACK TRACE: N/A ========================================= SUPPORTING INFORMATION: N/A at the moment ========================================= 24 HOUR CONTACT INFORMATION FOR P1 BUGS: N/A ========================================= DIAL-IN INFORMATION: N/A ========================================= IMPACT DATE: High impact cause a backup created as described above cannot be restored. I logged this with P2, after this bug is read and assigned you can set it to P3 if you like, or leave it at P2 if you find this a serious bug. *** EBANGMA 06/20/00 09:46 am *** (CHG: Sta->11) *** NIRELAND 06/20/00 10:34 am *** (CHG: Asg->BZANE) *** EBANGMA 09/03/00 11:46 pm *** Will this bug be looked at? Please update, thanks. *** BZANE 09/04/00 04:28 am *** I'll have a look as soon as I get done with the backports I'm doing. Please stay tuned. *** MJAEGER 09/28/00 10:18 pm *** Assigning to me, as I am the owner of RMAN. *** MJAEGER 09/28/00 10:19 pm *** (CHG: Asg->MJAEGER) *** SWERTHEI 10/24/00 11:18 pm *** (CHG: DevPri->3) *** MJAEGER 10/26/00 12:01 pm *** Over to you, Francisco. *** MJAEGER 10/26/00 12:02 pm *** (CHG: Asg->FSANCHEZ) *** EBANGMA 11/30/00 11:33 pm *** Please update, is there any progress? *** FSANCHEZ 12/01/00 03:33 pm *** The solution to this 'simple' problem is not trivial. I'm working in the solution and I'm testing my current implementation. This will appear in 9.0 Production. I do not think that it will be feasible to backport as it requires substantial changes to several files. So pretty much this will not help customers waiting for a fix. *** EBANGMA 12/04/00 12:36 am *** Thanks vary much for the update. *** FSANCHEZ 04/03/01 05:49 pm *** }ADE Transaction Information: }TRANSACTION: fsanchez_bug-1334388 }TRANS_LOCATION: /net/dlsun708//private/fsanchez/.ade/fsanchez_bug-1334388.t2t }BASE_LABEL: RDBMS_MAIN_SOLARIS_010402 }OWNING VIEW: NONE }TRANS_STATE: CLOSED }BRANCHED FILES: } rdbms/src/client/tools/rcvman/krmc.c } rdbms/src/client/tools/rcvman/krmg.y } rdbms/src/client/tools/rcvman/krmi.c } rdbms/src/client/tools/rcvman/krmk.h } rdbms/src/client/tools/rcvman/krmk.pc } rdbms/src/client/tools/rcvman/krmpa.c } rdbms/src/client/tools/rcvman/krmpp.c } rdbms/src/client/tools/rcvman/krmpp.h } rdbms/src/client/tools/rcvman/krms.c } rdbms/src/client/tools/rcvman/krms.h } rdbms/src/client/tools/rcvman/krms0.h } rdbms/src/client/tools/rcvman/recover.txt } rdbms/utl/rmask2.sed } tk_backup_restore/tkrm/log/tkrmcnac.log } tk_backup_restore/tkrm/log/tkrmcnan.log } tk_backup_restore/tkrm/log/tkrmct.log } tk_backup_restore/tkrm/log/tkrmfv07.log } tk_backup_restore/tkrm/log/tkrmfv08.log } tk_backup_restore/tkrm/log/tkrmfx15n.log } tk_backup_restore/tkrm/log/tkrmfx20.log } tk_backup_restore/tkrm/src/tkrmct.tsc }NEW FILES: } tk_backup_restore/tkrm/log/tkrmct.log } tk_backup_restore/tkrm/src/tkrmct.tsc }DIRECTORIES TO BE VERSIONED: } tk_backup_restore/tkrm/log } tk_backup_restore/tkrm/src INTERNAL DESCRIPTION: Any connection failure when trying to allocate the channels was considered a fatal error, the fix consisted of finding the status of the database when the first (default) channel is connected, and then set the expectations for the next channels, so that if the database is started the dbid and mid of the database is obtained, this allows a thorough verification of to what database the channel is connected. If the target is not mounted, only partially verification is possible, and similarly if the target is just statrted almost no verification is possible. Due to OPS it is possible that one instance is down when the 'target' instance is not, so this is allowed. With this new code the possibility of connecting to a different databases than the 'real' target are significantly reduced. A new test tkrmct.tsc uses all possible combinations of states od the database to validate the new code. As an aside the connection error is not treated as a fatal error, thus bug 1480579 is also fixed. ** FSANCHEZ 04/03/01 05:55 pm *** (CHG: Sta->80) ** FSANCHEZ 04/03/01 05:55 pm *** (CHG: Fixed->9.0.1) *** FSANCHEZ 04/03/01 05:55 pm *** REDISCOVERY INFORMATION: This bug shows quickly in case that the connect string of the allocate channel connects to a database with different filenames, then the customer sees that filenames that do not belong to the target database are being backed up. OIn the best of cases the mismatch is such that an error is signal;ed immediately (for example for archivelogs). At worst the 'third' database can be backed up and RMAN finishes succesfully while it actually did not backup the target database. In this case the bug is not discovered until a restore is attempted and the datafiles are not found, or even worse when the restored files do not have the expected information. This bug is most likely to occur when using channels of type DISK instead of SBT, as those chhannels require host specific initializations to work most of the time.