Failure to change REDO log locations

Question

Hi
We're restoring a copy of a production database on another host for the use of Analysts. Following the guide http://www.oracledistilled.com/oracle-database/restore-database-to-another-host-using-rman/ we get down to renaming the REDO logs when it fails. I should note the Production database is running on Linux and the Analyst's sytem is on Windows Server - both are running 11.2g.
Problem Example:
RMAN> SQL "ALTER DATABASE RENAME FILE ''/XXX/oradata/PROD/redo_01a.log'' TO ''C:\Oracle\Base\oradata\PROD\redo_01a.log'' ";
sql statement: ALTER DATABASE RENAME FILE ''/XXX/oradata/PROD/redo_01a.log'' TO ''C:\Oracle\Base\oradata\PROD\redo_01a.log''
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 12/13/2013 09:28:25
RMAN-11003: failure during parse/execution of SQL statement: ALTER DATABASE RENAME FILE '/XXX/oradata/PROD/redo_01a.log' TO 'C:\Oracle\Base\oradata\PROD\redo_01a.log'
ORA-01511: error in renaming log/data files
ORA-01516: nonexistent log file, data file, or temporary file "/XXX/oradata/PROD/redo_01a.log"
RMAN>
The redo log in the control file is currently pointing to '/XXX/oradata/PROD/redo_01a.log' but we need to update it to 'C:\Oracle\Base\oradata\PROD\redo_01a.log' to allow the recovery to run (the restore completes without any error)...
Is there another way to change the REDO file locations that wont generate an error?

Answer 1

We are trying to restore a copy of a full nightly backup of a Production database onto another machine - well up to the last SCN as following the documentation linked in the initial post. I assume that while the database is being backed up, its still being used so applying the redo logs that were created during the backup is quite important to bring the database back into a consistent state. I tried to work around this, but I don't think its possible - the database wont open if its not in a consistent state.
To get past that particular error, we just recreated the exact same folder structure as on the Production Server, which means we no longer have to run the RENAME command on the log files. It seems '/XXX/oradata/PROD/' is equivalent to 'C:\XXX\oradata\PROD\' as far as Oracle DB is concerned.
So originally before we tried to rename the log files, the restore ran into an internal error during Recovery, which we thought had to do with the location of the log files. But since we are no longer renaming them and still get that error, they can't be related errors.
Original Error
starting media recovery
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=38549
channel ORA_DISK_1: reading from backup piece C:\ORACLE\BACKUP\PROD_ARCH_####.########_#_#.BKP
channel ORA_DISK_1: piece handle=C:\ORACLE\BACKUP\PROD_ARCH_####.########_#_#.BKP tag=TAG#
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
archived log file name=C:\ORACLE\BASE\ARCHIVES\PROD_1_#_#.ARC thread=1 sequence=38549
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 12/15/2013 16:09:43
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile 'C:\ORACLE\BASE\ARCHIVES\PROD_1_#_#.ARC'
ORA-10562: Error occurred while applying redo to data block (file# 20, block# 57428)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 20: 'C:\XXX\ORADATA\PROD\SYSAUX01.DBF'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 245371
ORA-00600: internal error code, arguments: [6122], [0], [52692], [0], [], [], [], [], [], [], [], []
<apologies for the #'s, a college insisted on "identity protection", although I think its kind of silly to censor most numbers that relate to the state of a db>
With the error ORA-00600 internal error, we think it could be a bug specific to this version, a bad backup or is simply incompatible with the Windows machine.
Our next endeavor has been to download one of the Oracle Developer Day VM's and set it up to be the host of the restore. If it succeeds, then its likely a bug in the version we're running or possibly it has a compatibility issue and is not restorable on windows.
Anyway, will post the result of the experiment, otherwise we'll probably have to shelve this project until after xmas...