Re: RMAN RESTORE TO NEW SERVER

From: David Barbour <david.barbour1_at_gmail.com>
Date: Fri, 8 Feb 2008 20:45:03 -0500
Message-ID: <69eafc3f0802081745j44290865w7a59b8c0afbbe6e0@mail.gmail.com>


Larry,

If you've got a lot of files, you can easily use the db_file_name_convert in your init<SID>.ora file.

Because you're 'migrating' these, I'll presume you're using the RMAN duplicate target database command.

Simply list your files (in this example I'm listing ALL my files, the ones that are the same as well as the ones with a changed filesystem/directory) in the init<SID>.ora file like this:

db_file_name_convert=(

'/oracle/PR1/sapdata1/autodata/autodata01.dbf','/oracle/PR1/sapdata1/autodata/autodata01.dbf',
'/oracle/PR1/sapdata2/autoindex/autoindexes01.dbf','/oracle/PR1/sapdata2/autoindex/autoindexes01.dbf',
'/oracle/PR1/sapdata1/bkpfd_1/bkpfd.data1','/oracle/PR1/sapdata1/bkpfd_1/bkpfd.data1',
'/oracle/PR1/sapdata2/bkpfd_2/bkpfd.data2','/oracle/PR1/sapdata2/bkpfd_2/bkpfd.data2',
'/oracle/PR1/sapdata3/bkpfd_3/bkpfd.data3','/oracle/PR1/sapdata3/bkpfd_3/bkpfd.data3',
'/oracle/PR1/sapdata4/bkpfd_4/bkpfd.data4','/oracle/PR1/sapdata4/bkpfd_4/bkpfd.data4',
'/oracle/PR1/sapdata1/bkpfi_1/bkpfi.data1','/oracle/PR1/sapdata5/bkpfi_1/bkpfi.data1',
'/oracle/PR1/sapdata2/bkpfi_2/bkpfi.data2','/oracle/PR1/sapdata6/bkpfi_2/bkpfi.data2',
'/oracle/PR1/sapdata3/bkpfi_3/bkpfi.data3','/oracle/PR1/sapdata7/bkpfi_3/bkpfi.data3',
'/oracle/PR1/sapdata4/bkpfi_4/bkpfi.data4','/oracle/PR1/sapdata8/bkpfi_4/bkpfi.data4',
'/oracle/PR1/sapdata1/bsadd_1/bsadd.data1','/oracle/PR1/sapdata1/bsadd_1/bsadd.data1',
'/oracle/PR1/sapdata2/bsadd_2/bsadd.data2','/oracle/PR1/sapdata2/bsadd_2/bsadd.data2')

Then when you're ready to start the duplicate execute: SQL>startup nomount pfile='<location and name of init<SID>.ora file>;

Then execute your RMAN script in the background and redirect the output to a log file. Here's mine (duplicate_database.sh):

#!/usr/bin/ksh

export ORACLE_HOME=/oracle/QA1/920_64
export ORACLE_SID=qa1
export PATH=$PATH:$ORACLE_HOME/bin
export NLS_DATE_FORMAT='yyyy mon dd hh24:mi'

rman <<EOF

connect target sys/<password>@pr1
connect catalog rmanadmin/<password>@rcat connect auxiliary sys/<password>@qa1

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';

run{
allocate auxiliary channel dupdb1 type 'sbt_tape'; allocate auxiliary channel dupdb2 type 'sbt_tape'; set until time '2008 jan 19 06:00';
duplicate target database to qa1 pfile='/oracle/QA1/920_64/dbs/initQA1.ora'

        nofilenamecheck;}

EOF exit

On 2/8/08, Wolfson Larry - lwolfs <lawrence.wolfson_at_acxiom.com> wrote:
>
> Hi guys,
>
>
>
> I'm migrating a number of 9.2.0.1.0 32 &64 bit DBs to new
> servers with "rman"
>
> At some point we'll be upgrading them there.
>
>
>
>
>
> They asked me to rename all files to new naming (directory)
> standards.
>
> I'm not big "rman" user, but everything has gone well so far until I hit
> the largest DB.
>
>
>
> It's about 800G and at first only 500 was allocated.
>
> When it was pointed out we needed another 500 it was allocated but to
> another 500G directory.
>
>
>
> When doing the restore how can I get some files to go to the new FS?
>
> Or do I have to have them increase old FS?
>
>
>
> I've tried the SET NEWNAME command and when I run it it says it worked
> but the files always want to go to original place.
>
>
>
>
>
> RUN
>
> {
>
> SET NEWNAME FOR DATAFILE '/x/system01.dbf' TO '/y/system01.dbf' ;
>
> SWITCH DATAFILE ALL;
>
> }
>
>
>
> The others were easy. Just changed initora and moved controlfiles to new
> directory.
>
> Then ran
>
> ALTER DB RENAME (had linked old directories to new ones)
>
>
>
> Again this is 9.2.0.1.0.
>
>
>
> THX
>
> Larry
>
> *************************************************************************
> The information contained in this communication is confidential, is
> intended only for the use of the recipient named above, and may be
> legally privileged.
>
> If the reader of this message is not the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited.
>
> If you have received this communication in error, please resend this
> communication to the sender and delete the original message or any copy
> of it from your computer system.
>
> Thank you.
> *************************************************************************
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.18/1254 - Release Date:
> 1/31/2008 8:30 PM
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Feb 08 2008 - 19:45:03 CST

Original text of this message