Re: [Networker] Can you use saveset recover for an RMAN saveset createdwith NMO?
2007-01-19 05:19:59
Bhaskar Mylavarapu wrote:
Interesting idea. BUT, OK, Let's suppose that you set up a file type
device
on the primary backup server, and then you label that into a clone pool
and then you clone the desired save set from original tape to the primary
backup server's local disk. All well and fine, but now, how are you
going to
get RMAN recover from the Oracle client to see that disk area? Assuming
that this disk/directory could not be NFS exported to the Oracle
client, or vice
versa, how would you do it? Could you copy it there and then point the
RMAN
restore at that?
The recovery would still need to be done via NetWorker - not directly
from the disk. It would still be in NetWorker format. This is why the
answer to the original question is "Not possible under any
circumstances". So NFS mounting the disk device to a client would be
like a broken pencil - pointless.
I'm not aware that a client can create file type devices, only backup
server?
Although this point is irrelevant - yes a client can have a file type
device attached, BUT only if you upgrade it to a storage node - in which
case it's no longer just a client.
Bhaskar
Curtis Preston wrote:
The only thing I can think of doing is cloning your tape backup to disk.
Then RMAN can recover it via that.
---
W. Curtis Preston
Author of O'Reilly's Backup & Recovery and Using SANs and NAS
VP Data Protection
GlassHouse Technologies
-----Original Message-----
From: networker-bounces AT backupcentral DOT com
[mailto:networker-bounces AT backupcentral DOT com] On Behalf Of George
Sinclair
Sent: Thursday, January 18, 2007 9:02 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Can you use saveset recover for an RMAN saveset
createdwith NMO?
Is it possible to use a standard save set recover (recover -s server
-S ssid/cloneid) to recover
a saveset that was backed up using RMAN from an Oracle client via NMO?
We'd like to be able to recover an RMAN saveset to disk and then try
pointing RMAN at the recovered disk
area to restore it, but after running mminfo to get the ssid for the
affected save set (contains the control file),
when we ran recover, we received a cross platform error as follows:
# recover -d /oracle_test -s server_name -S ssid
Recovering files within RMAN:\oracle10.2\oracle10.2\SCRIPTS\ into
/oracle_test
recover: Permission denied by server server_name: Cross platform
recovery not supported
recover: Warning: Could not change working directory to to remove
relocate directory /oracle_test
In fact, we tried numerous such savesets (originals and clones) and they
all produce the same error. I tried this on both
the Oracle client and the primary backup server. I was running this
as the root user. We're running 7.2.2
on a Solaris 9 primary backup server. The Oracle server is running Linux
with Oracle 10 g (NMO 4.2) and
NetWorker client 7.2.2. All our save sets have the same name since we're
using the path name to the script as
the save set name for the NSR client resource, and nsrnmo for the backup
command field, but the names
are distinguished between full and incremental and catalog database
versus production database. We can
also identify which saveset has the control file based on time, size and
Oracle log file. We can recover
regular (non-RMAN) save sets to disk from tape just dandy, and using
RMAN, we're able to recover the
savesets that we backed up using NMO fine, too, but they appear to be
treated very differently.
Is it the case that because RMAN was used to back up the original
save set, you can't then use a normal conventional recover
to recover it? In other words, NetWorker sees that the backup save
set was created via RMAN and therefore requires RMAM
to be used for the recover, too?
I understand that you have 7 days (default) you can go back for the
catalog database, and adjusting the MAXDAYS parameter
would allow it to be able to go back farther, but it will still take the
most recent control file it can find. We want to be able to tell it
to take the cf before that, or the one before that, etc. So, if there
was a bad spot on the tape, for example,
and NetWorker still thought everything was OK, we'd be able to move
it back one at a time until it worked.
Otherwise, the normal RMAN/NMO recover might fail in this case since
it would insist on using the most recent
one. Yes, we can go back as far as we want for the catalog once we
have the control file, but specifying the desired date
for the control file isn't an option. Of course, the regular database
uses the catalog to allow it to recover as far back as we
need so that's moot. We were thinking, therefore, that in some
extreme case that if we could also do a normal
saveset recover then we could recover the catalog cf from any point
in time to disk and then use RMAN to restore from there. This would
only be
for the control file. Otherwise, doing a cold backup and/or export
and backup is the only other option?
Thanks.
George
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with
this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
-e ===========================================================
This email has been verified as Virus free
Virus Protetion and more available at http://www.plus.net
===========================================================
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
|
|