Re: restore using rman
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