"A DBA is only as good as their last backup."
Your welcome!
On Mon, Aug 21, 2017 at 8:06 AM Chris Stephens <cstephens16@xxxxxxxxx>
wrote:
i implicitly test my car every morning to get to work. i guess it would
no longer be a daily test if i lost my job because my database wasn't
recoverable. i get your point though.
thanks for the link Kellyn!
On Mon, Aug 21, 2017 at 8:55 AM Mladen Gogala <gogala.mladen@xxxxxxxxx>
wrote:
Why would you want to rest rman backups? Do you have any doubts of their
quality? You can do "restore validate" is you suspect a problem. I
understand that you should be cautious, but rman has proven itself many
times over, there is no need to test it whether it will work. Do you test
your car every morning?
On 08/21/2017 09:39 AM, Chris Stephens wrote:
We are looking for an efficient way to regularly test RMAN backups across
a large (and growing) Exadata database environment.
After watching this video https://youtu.be/Ds1xrfdlZRc i thought about
doing the following:
create a dedicated, small tablespace in all databases to hold a single
table with a single date/timestamp column. create a scheduler job to
insert current sysdate/systimestamp value once per day and delete all rows
older than recovery window setting for RMAN.
write a script to 1) randomly pick a database on each Exadata system 2)
randomly pick a day that falls within the recovery window requirement for
that database 3) converts that day to a valid SCN 4) uses the new table
PITR functionality to restore the table 4) confirm expected table content
5) sends success/failure summary email.
execute the script with a frequency that makes us feel comfortable with
our backups.
we also intend to have a process that utilizes the "restore preview" RMAN
command to get a list of backup pieces to run the RMAN "validate" command
against for a randomly chosen SCN that falls within recovery window.
Does anyone see any big issues with this process? Any other ideas for
efficiently testing database backups? our databases will soon be large
enough to make testing through full restores infeasible.
any feedback is greatly appreciated!
thanks,
chris
--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217
--
