Re: restore using rman

From: Charles Hooper <hooperc2000_at_yahoo.com>
Date: Sun, 15 Feb 2009 09:41:18 -0800 (PST)
Message-ID: <8ac3338c-68ac-4383-8729-b017d568db29_at_r24g2000vbp.googlegroups.com>



On Feb 14, 1:46 pm, Anthony <akkha1..._at_gmail.com> wrote:
> I mentioned in my original posting that I have tried this on a small
> test database and it is okay. So the script is fine.
> The rationale behind this I was asked to give a copy of the production
> database (6 months old) to an outside vendor. What I have is some
> extra disk space on the production box. I do not want to create
> another instance on the production box just to do this. I do not have
> another box with similar configuration to duplicate a database. I
> cannot shutdown or bounce the database. Tell me what option I have
> besides my script? Also can someone tell me why I have the error? I am
> not writing to the original location.
>
> I am using Oracle 10gR2 on a windows 2003 server box.

If anyone disagrees with the following advice, please say so, and why.

A couple more ideas for you:
1. Since you need to give the database to an outside vendor, consider using expdp (Datapump Export) or exp (the old export utility). A dump file created by one of these utilities will probably be easier for the outside vendor to use, especially if the outside vendor is not using the same operating system platform. (Note that this will not provide the database as of 6 months ago.) RMAN does apparently have the ability to migrate between little endian and big endian platforms (see page 485 of the book I previously referenced), and working with an RMAN backup would likely be faster than working with an export file. 2. If the database is configured to use a flash recovery area, try the following in RMAN:

   SQL "ALTER SYSTEM SWITCH LOGFILE";
   BACKUP AS COPY DATABASE;
   SQL "ALTER SYSTEM SWITCH LOGFILE";
   SQL "ALTER DATABASE BACKUP CONTROLFILE TO TRACE";  The second of the four commands above will create image copies of the data files from the production database (note that this will not provide the database as of 6 months ago). The third command will make certain that the online redo log file is archived after the data files are copied (to make certain that all changes made during the data file copy are available). The fourth command will write a file to the udump directory on the server which lists commands to recreate the control file, the online redo logs and the temp files - this file may be modified by the vendor to point to the new file locations on their system. You will probably need to rename the data file copies which are created so that instead of having names like O1_MF_SYSTEM_4SJLL9JF_.DBF, they have the original names. You will then need to give to the vendor a copy of the spfile, the archived redo logs created between the execution of the backup as copy and the backup controlfile to trace commands.
3. If the database is configured to use a flash recovery area, try the following in RMAN:

   SQL "ALTER SYSTEM SWITCH LOGFILE";
   BACKUP DATABASE INCLUDE CURRENT CONTROLFILE;    SQL "ALTER SYSTEM SWITCH LOGFILE";
 The second of the above commands will create a new hot backup of the production database (note that this will not provide the database as of 6 months ago). You will then need to give to the vendor a copy of the spfile, the archived redo logs created between the execution of the backup and the final switch of the logfile, and the RMAN backup files. The vendor will then need an identical directory structure (this can be adjusted during the restore) so that RMAN can restore the control file from the backup, mount the database, and restore the database from the RMAN backup.

If you need the database as of 6 months ago, I suggest that you try the solution that I originally suggested, which used a new auxiliary database instance to restore the old copy of the database. Once the restore completes, you should be able to issue a SHUTDOWN IMMEDIATE; against the auxiliary database to make certain that the new database is consistent, copy all of the related files (the spfile, control files, data files, undo, redo logs, etc.) for the vendor, and then use ORADIM to remove the service for the auxiliary database instance.

Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. Received on Sun Feb 15 2009 - 11:41:18 CST

Original text of this message