RE: rman restore
- From: "Zelli, Brian" <Brian.Zelli@xxxxxxxxxxxxxxx>
- To: Seth Miller <sethmiller.sm@xxxxxxxxx>
- Date: Fri, 17 Oct 2014 11:58:29 +0000
Thx Seth, that will be a good start. Several googles that I looked at made a
lot of assumptions too and that’s what made it confusing. That’s why I posted
to the list. Hall’s site looks like a good one to start with. Basically, all
I am concerned with at this point is to simulate a recovery if I had to. Using
the files that I backed up with rman, I want to see if I have everything to
recover.
Brian
From: Seth Miller [mailto:sethmiller.sm@xxxxxxxxx]
Sent: Thursday, October 16, 2014 11:01 PM
To: Zelli, Brian
Cc: oracle-l (oracle-l@xxxxxxxxxxxxx)
Subject: Re: rman restore
"I am using rman with no catalog since I am not archiving."
You may be misunderstanding the purpose of a catalog. There is no relationship
between archivelogs and a catalog, but it doesn't matter. Having a catalog in
your case makes no difference.
You will have a much easier time of creating a copy of your database with the
RMAN DUPLICATE command, especially if you plan to make this a regular process.
In fact, you can use the FROM ACTIVE DATABASE clause to avoid the need of
taking a backup at all (this would require archivelog mode).
The instructions you posted make so may assumptions, they are almost guaranteed
not to work. They also severely limit the capabilities of RMAN. For example,
there is no requirement to restore your datafiles to the same location as those
of your source database. I'm also not sure why the script sets the DBID if the
controlfile is already mounted. It's all very confusing.
Anyway, don't use that script. If you want a good walk-through, Tim
Hall<http://www.oracle-base.com/articles/11g/duplicate-database-using-rman-11gr2.php>'s
site is always a good start. There are literally dozens of ways to duplicate
or restore a database and most of the methods I see make the process way too
difficult. Spend some time on Tim's site and find the method that works best
for you. When (not if, this isn't easy and none of us get it right the first
time) you have questions because something doesn't work, post them on the list
and there will be plenty of help available.
Seth Miller
On Tue, Oct 14, 2014 at 12:43 PM, Zelli, Brian
<Brian.Zelli@xxxxxxxxxxxxxxx<mailto:Brian.Zelli@xxxxxxxxxxxxxxx>> wrote:
Ok, I am using rman for backups and I capture a bunch of backup files and
controlfile. I am using rman with no catalog since I am not archiving.
If I want to restore to another server (finally a test box to restore), do I
just bring all the files over and issue an rman restore? Is there a cheat
sheet around to kind of guide me? I found this:
Restore Example
There are many ways to restore a database using an RMAN backup - this example
assumes you are performing a Disaster-Recovery restore of all data and
recovering the entire database with the same SID and the same disk/tablespace
layout.
You will need the following information:
Database SID: ________
Database SYS password: ________
Disk layout and sizes: ________
Database ID (DBID): ________
There are 5 steps to recover the database:
1) Create a new (empty) database instance
2) Mount the instance
3) Restore the datafiles
4) Recover the database
5) Reset the logs
1) Create a new (empty) database instance
Configure the new server with same disk layout as the original database - if
necessary use Symbolic Links (or in Windows use disk manager to re-assign drive
letters.)
Ensure you have enough disk space for both the backup files plus the restored
database files.
Create a new database with the database configuration assistant (DBCA) and set
the SYS password and global database_name to the same as the original database.
If the database to be restored is in archive log mode, set the
LOG_ARCHIVE_FORMAT parameter to match the setting in the original database.
The ORAPWD utility can also be used to change the SYS password.
Set the environment variable NLS_LANG for your character set -
NLS_LANG=American_America.WE8ISO8859P1
2) Mount the empty instance
SQL> Shutdown immediate;
SQL> Startup mount;
or specifying the pfile explicitly:
SQL> CREATE PFILE='C:\oracle\Database\initLive.ora' FROM SPFILE;
SQL> Shutdown immediate;
SQL> Startup mount pfile=C:\oracle\Database\initLive.ora
3) Restore the datafiles
In this case we have copied the RMAN backup files and archive logs to R:\Rman\
Change the dbid to match that of the database being restored
RMAN> SET dbid = 477771234;
RMAN> run {
ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT 'R:\Rman\%U';
restore database;
}
At this point the datafiles and tablespaces will be re-created. For a large
database it can take a long time to restore each tablespace - for better
performance during a restore place the RMAN backup files on a separate disk to
the Oracle datafiles to reduce disk contention.
4) Recover the database
SQL> Recover from 'L:\oradata\live' database until cancel using backup
controlfile;
SQL> cancel
5) Reset the logs
SQL> alter database open resetlogs;
This will update all current datafiles and online redo logs and all subsequent
archived redo logs with a new RESETLOGS SCN and time stamp.
As soon as you have done a resetlogs run a full backup, this is important as
should you suffer a second failure you will not be able to perform a second
recovery because after resetting the logs the SCN numbers will no longer match
any older backup files.
Notes:
The DBID can be retrieved in several places, if the database is running: Select
dbid from V$DATABASE;
The RMAN client displays the dbid at startup when connecting to a database:
Copyright (c) 1995, 2003, Oracle. All rights reserved.
connected to target database: RDBMS (DBID=7776644123)
The default filename format for an RMAN controlfile autobackup is
c-IIIIIIIIII-YYYYMMDD-QQ, where: IIIIIIIIII is the DBID.
Brian
This email message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or agent
responsible for the delivery of this message to the intended recipient(s), you
are hereby notified that any disclosure, copying, distribution, or use of this
email message is prohibited. If you have received this message in error, please
notify the sender immediately by e-mail and delete this email message from your
computer. Thank you.
This email message may contain legally privileged and/or confidential
information. If you are not the intended recipient(s), or the employee or
agent responsible for the delivery of this message to the intended
recipient(s), you are hereby notified that any disclosure, copying,
distribution, or use of this email message is prohibited. If you have received
this message in error, please notify the sender immediately by e-mail and
delete this email message from your computer. Thank you.
Other related posts:
