Re: Oracle Backup to new SID

steven_nospam_at_yahoo.ca wrote:
> joel garry wrote:
> > I don't think RMAN will be faster than a cp, since rman has to both
> > extract the data to the backup area and then write it to the new
> > database for duplicate database, while the cp just has to write it to
> > where the duplicate database can see it.
> >
> > But I'm wondering about 4 hours for 10G, that seems awfully slow for
> > cp. I guess you have some really old hardware, perhaps from the 8i
> > days? My RMAN backup takes about 2 hours, versus 1/2 hour for a
> > DIRECT=Y export. My export is 24G (note that that export does not
> > include indices aside from create statements, and takes 10x longer to
> > import). I haven't looked to see how long a cp takes lately, but it is
> > certainly less than rman.
>
> Hi Joel,
>
> Thx for the input.
>
> These systems are quite old but I don't expect a big difference on the
> newer systems from a disk to disk standpoint. The system that has the
> production (PROD1) and end of month (EOM1) SIDs on it is an RS/6000
> Model H70. They are still running AIX 4.3 with Oracle 8i and I am
> trying to get new pSeries servers with AIX 5L and Oracle 9i installed
> in its place.
>
> System Model: IBM,7026-H70
> Processor Type: PowerPC_RS64-II
> Number Of Processors: 4
> Memory Size: 8192MB
>
> For the record, below in pseudocode is what we do and I wrote down the
> actual times from the server for each step of the way. I found out that
> it is actually only about two hours from beginning to end, but then the
> legacy system has another 40-50 minutes that it has to do its thing so
> this is why the users were reporting longer times to me. From their
> perspective they are off the system over 3 hrs if you include that
> process and the time it taes for them all to get off at the start.
>
> Here is what we do:
>
> 07:08:14 PM - Confirm OLD DATA tablespace has been dropped from EOM
> database
> 07:08:21 PM - Shutdown IMMEDIATE and re-open to disconnect any sessions
> 07:08:51 PM - Placing DATA tablespace in READ-ONLY mode...
> 07:08:54 PM - List DATA tablespace files
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data01
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data02
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data03
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data04
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data05
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data06
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data07
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data08
> -rwxrwxrwx 1 oracle dba 1048580096 Aug 30 16:44 data09
>
> 07:08:55 PM - Copying data file #1 using /bin/cp
> 07:10:02 PM - Copying data file #2 using /bin/cp
> 07:11:16 PM - Copying data file #3 using /bin/cp
> 07:12:35 PM - Copying data file #4 using /bin/cp
> 07:14:00 PM - Copying data file #5 using /bin/cp
> 07:15:28 PM - Copying data file #6 using /bin/cp
> 07:16:46 PM - Copying data file #7 using /bin/cp
> 07:18:02 PM - Copying data file #8 using /bin/cp
> 07:19:21 PM - Copying data file #9 using /bin/cp
>
> 07:20:26 PM - Rereating deleted user in EOM database...
> 07:20:27 PM - Exporting DATA transportable tablespace from LIVE
> Export terminated successfully without warnings.
> 07:21:31 PM - Importing DATA transportable tablespace into EOM
> Import terminated successfully without warnings.
> 08:15:19 PM - Adjusting EOM user default tablespace...
> 08:15:20 PM - Copying Legacy Software - LIVE to EOM..
> 08:19:44 PM - Changing DATA tablespace to READ-WRITE in LIVE
> 08:19:48 PM - Changing DATA tablespace to READ-WRITE in EOM
> 08:19:58 PM - Recreating dropped descending indexes in LIVE...
> 08:50:54 PM - Recreating dropped descending indexes in EOM...
>
> Steve

Looks more like less than an hour for the transport to me! (cp and index rebuilds). You'll need to test, but I think the RMAN duplicate may be competive by not having to deal so radically with the indices. The rest is, as you say, the legacy system doing its thing.

Something to think about for O9:

You might want to rethink the shutdown. Eventually you will likely run into things like the Intelligent Agent or other sessions disallowing shutdown immediate, and will likely want to use OS scripts to kill off specific sessions and perhaps restrict logins, instead of shutting down.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/uniontrib/20060829/news_1b29pru.html