How do you recover the NetWorker save set onto disk? We'd like to try
pointing RMAN at the recovered disk area to resore it, but we ran mminfo
to get
the ssid for the affected save set (contains the control file), but 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
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.
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 should note that we can recover regular (non-RMAN) save sets to disk
from tape just dandy.
I understand that you have 7 days you can go back, and adjusting the
MAXDAYS parameter would allow
it to be able to go back farther, but it will still take the first cf it
can find. We want to be able to tell it
to take the one 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.
Thanks.
George
Alternatively, if you know the Networker name of the saveset that
includes the controlfile you want to restore, you can just restore
this saveset somewhere on disk and tell RMAN to 'restore controlfile
from 'filename''.
Uwe Weber wrote:
Hi,
George Sinclair schrieb:
The problem we see is that while we can recover the production
database for any given time, including the control file (the catalog
gives us this capability), we can only recover the control file for
the catalog database itself from the most recent backup. We are
unable to go back to any previous versions.
You do not need a catalog to restore to previous versions.
If you loose your catalog db including the current controlfile
you can either restore the controlfile from autobackup
(of course controlfile autobackup has to be enabled for this)
or you can use dbms_backup_restore.
Restoring from autobackup is much easier, so you should enable
controlfile autobackup at least on the catalog db. After restoring
the cf, you can do something like:
RUN
{
SET UNTIL TIME 'Nov 15 2002 09:00:00';
# SET UNTIL SCN 1000; # alternatively, specify SCN
# SET UNTIL SEQUENCE 9923; # alternatively, specify log sequence
number
RESTORE DATABASE;
RECOVER DATABASE;
}
But there could be a situation
wherein we needed to recover some previous version of the
production database using the catalog, but maybe for whatever
reasons, we experience problems with recovering the most recent
version of the control file for the catalog. e.g. bad area on tape,
maybe the clone wasn't successful, whatever.
If using controlfile autobackup, RMAN will look for a good
controlfile backuppiece in it's default location or on the channel
you specified. By default it looks back seven days and takes the most
recent readable cf it finds. By changing the MAXDAYS parameter
you can influence how many days RMAN will go back to find a cf.
Alternatively, if you know the Networker name of the saveset that
includes the controlfile you want to restore, you can just restore
this saveset somewhere on disk and tell RMAN to 'restore controlfile
from 'filename''.
In this case, we'd
be stuck. so we we thinking maybe it would be prudent to also make a
cold backup of the catalog database as an additional precaution.
o A script would run on the Oracle server as a cron job wherein it
would shut down the catalog database, copy all the files to a
separate location and the restart the database. That location would
then be a specified saveset for another NSR client resource that
would then run daily fulls against that path. This way, we can always
recover the catalog database from any point in time if necessary, but
under normal circumstances, the most recent copy (using rman) would
be used, of course.
If you are really paranoid about your catalog db, you should rather make
an export of the catalog schema user every day, instead of a cold
backup. You could than import the this into any surviving db, if you
loose the orginal db.
Regards,
uwe
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
--
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
|
