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?

I'm not aware that a client can create file type devices, only backup server?

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