RE: RMAN physical backup verification - incrementals
- From: "MacGregor, Ian A." <ian@xxxxxxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 24 Mar 2004 16:53:31 -0800
If I understnd correctly, the validate command only verifies that the database
can be restored to a consistent state bsed on the latest level 0 backup,
assuming incremental backups are used. It does not confirm the ability to
recover to a point-in-time more recent than that.
There was the idea of using until time, but does this really do anything with
the validate command:
-------------------------------------------------------------------------
RMAN> run
{
allocate channel c1 type 'sbt_tape' format 'df_%t_%s_%p'
PARMS='ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin/tdpo.opt)';
restore database validate until time 'sysdate +1';
release channel c1;
----------------------------------------------------------------------------------------------------------
This runs. Restoring the database to a future date could be very profitable
for ESPN or stock market DBA's.
The until time is an upper limit, and there was the off chance that the lack of
errors meant the validate was going throgh the backed up redo logs plus the
online ones and found no breaks, though this was highly doubtful. I then
switched through the redo logs, so the online ones did not contain the data
needed to recover, and the online logs were not backed up. I moved the not yet
backed up archived logs to another directory
I ran the restore validate statement with
until time 'sysdate'
Again no errors.
Ian MacGregor
Stanford Linear Accelerator Center
ian@xxxxxxxxxxxxxxxxx
-----Original Message-----
From: Tim Gorman [mailto:tim@xxxxxxxxxxxxx]
Sent: Wednesday, March 24, 2004 5:38 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: RMAN physical backup verification - incrementals
Rich,
It could be that, from a validation standpoint, incremental backups at level
> 0 simply do not matter -- only FULL and LEVEL=0 backups matter for
recoverability. I have a report against the RMAN repositories to do the same
validation, but I also completely ignore incremental backups where level > 0,
because they exist only to expedite recovery (and worrying about them only
complicates the report). I don't know if Oracle uses this same reasoning for a
validation operation, but they might...
While RESTORE VALIDATE is excellent, another equally valid recovery test is a
DUPLICATE TARGET DATABASE operation. If you're short on space and running 9i,
you can exclude all but a few small tablespaces so as not to consume too much
disk space with the duplicated database. That operation should certainly
utilize incremental backups.
Just my $0.02...
-Tim
on 3/23/04 11:08 AM, Rich Holland at holland@xxxxxxxxxxxxxxxx wrote:
> We run a weekly incr level 0 and daily incr 1 backups via RMAN. I'd
> like to verify that whatever we write to tape is good; normally I'd do
> this by requesting a restore to test it.
>
> Rman has a nice 'validate' feature that I tried to take advantage of
> via something like this:
>
> connect target;
> run {
> allocate channel c1 type sbt;
> restore database validate;
> }
>
> This works, but I noticed that it always requests a restore of the
> last INCR 0 backup -- even if several days since then have passed.
> How do others verify that their INCR backups > 0 are cleanly written to tape?
>
> Thanks!
> Rich
> --
> Rich Holland (913) 645-1950 SAP Technical Consultant
> print unpack("u","92G5S\=\"!A;F]T:&5R(\'!E<FP\@:&%C:V5R\"\@\`\`");
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
> 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe'
in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
