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
--
George Sinclair - NOAA/NESDIS/National Oceanographic Data Center
SSMC3 4th Floor Rm 4145 | Voice: (301) 713-3284 x210
1315 East West Highway | Fax: (301) 713-3301
Silver Spring, MD 20910-3282 | Web Site: http://www.nodc.noaa.gov/
- Any opinions expressed in this message are NOT those of the US Govt. -
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
|
