Re: RMAN duplicate RAC to single instance - how to not duplicate redo threads and temp tablspace
Date: Wed, 28 Mar 2012 10:32:12 +0100
> Using 188.8.131.52 and trying to work out if I can do an RMAN duplicate from 4 node RAC to single instance without
> the duplicate generating the 4 threads of redo?
Ok, I'm not an RMAN expert by any means, nor do I play one on TV, but, I'm doing a bit of RMAN at the moment - duplicating terabyte databases over a network to a different server - and while not RAC, I'm pretty sure that RMAN only takes the redo that it needs to restore the backup to surrent. If you had a block updated by all 4 nodes, then you would need all 4 redos to bring said block up to date.
> Also, I wondered if it was possible to have the duplicate NOT create the TEMP tablespace as part of the duplicate?
No. As far as I know, TEMP is recreated at the auxiliary database end as opposed to being copied over. You could, maybe, try the skip tablespace option to the duplicate command? The docs seem to indicate that any tablespace can be skipped, except SYSTEM.
> I am running the duplicate as part of an automated script, and it is a simple statement as follows
> duplicate database PROD to TEST pfile='/u01/app/oracle/test/pfile.test' backup location='/orabackup'
Have you tried the duplication from active database so you don't need the dump? That's what I'm doing.
Startup nomount the aux database with a pfile containing db_name='whatever' only, then creating a password file and a listener.
On the target database server I've got a tnsnames.ora entry pointing at the listener and I can connect sys/sys_at_auxiliary as sysdba with no problems.
Then rman target / on the target database server and:
duplicate target database to auxiliary
from active database
log_file_name_convert='/srv/SRC/oradata/SRC_SID','/srv/DST/oradata/DST_SID','/srv/SRC/flashback_area/SRC_SID','/srv/DST/flashback_area/DST_SID' db_file_name_convert='/srv/SRC/oradata/SRC_SID','/srv/DST/oradata/DST_SID' ;
I had to put quite a lot into the parameter_value_convert because some paths were not being converted until I added in the final 4 entries. Strange - other clones worked fine.
Apologies if granny already knows how to suck eggs!
> This works very well, but the reason behind the requirement to not create additional threads and TEMP tablespace is the limited amount of space
> in the TEST environment at the moment. Removing the threads and TEMP tablespace would free up 48 Gb as the
> test environment doesn't run the batch jobs that use all that TEMP space.
-- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 -- http://www.freelists.org/webpage/oracle-lReceived on Wed Mar 28 2012 - 04:32:12 CDT