Re: rman recovery
- From: Mladen Gogala <gogala.mladen@xxxxxxxxx>
- To: Orlando L <oralrnr@xxxxxxxxx>
- Date: Mon, 18 Jul 2016 02:14:06 -0400
On 07/18/2016 12:16 AM, Orlando L wrote:
I came across this
<http://oracleabout.blogspot.com/2013/01/restore-database-rac.html>
online, and thought maybe this is a new feature I didnt know.
Orlando, that is a new feature, called "affinity". The trick is in
connecting to different nodes using the
CONNECT 'sys/SYSTEM@DUMMYGG1';
addition to the "allocate channel".
That is described here:
https://docs.oracle.com/cd/E18283_01/rac.112/e16795/backup.htm#i470947
https://docs.oracle.com/cd/E18283_01/rac.112/e16795/backup.htm#i472961
Essentially, you are connecting to 3 running instances from the node
which has access to backup. My claim is plain incorrect: you can use
"restore database" with RAC, as long as the database is mounted and the
infrastructure is in place. One thing that must be in place is obviously
the scan listener. The other thing is the service registered with the
scan listener, or you will not be able to connect to the database. That
means that the database is defined and running as a cluster DB.
My statement was meant, but clearly not written, for the complete
database re-creation, with SET DBID in a single step. I don't know how
large is your database, but the procedure described in the blog is
rather complex. I don't know the CPU resources on your RAC nodes, but
in case covered by the blog, the speed gains over all channels on the
single node would probably not be great, while complexity is much, much
greater. I normally use "CONNECT" only for backup, in order to ensure
that backup is taken even if a node goes down.
Also, there are several remarks to the original blog:
* There is absolutely no need for setting undocumented parameters.
Nothing is faster. RMAN has quite sophisticated memory management
and allocating 64M of buffer size (64 buffers, 1M each) will be done
automatically, if necessary. Furthermore, Linux and Unix systems
usually have maximum atomic IO that can be performed in a single
request limited to 1M. Oracle 12c can move that limit to 4M, but not
11G. In that case buffer of 64M will not give you additional speed.
More additional speed can be obtained by specifying LARGE_POOL_SIZE,
although that is rarely done with the dynamic SGA management.
* RMAN catalog is being used which means that RMAN will locate the
proper backup even without unnecessary "FORMAT" clauses.
* There is absolutely no information of any benefits of this complex
procedure. It is much, much simpler to do the following, with a
single instance DB running in nomount mode:
rman target / catalog rman/rman@rcat
set dbid 1235678910;
run {
allocate channel t1 device type disk; # Format is completely
unnecessary, backup will be located in RCAT
..
allocate channel t18 device type disk;
restore database;
recover database until time ".....";
}
sql 'alter database open resetlogs';
The result will be a single instance database which can be converted to
RAC in 5 minutes using srvctl commands. I am not sure that connecting
to other nodes would speed the process up in any way, especially having
in mind the amount of manual labour that must be performed along the way.
--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
Other related posts:
