Re: Lightweight method for testing database backup processes

From: Kellyn Pot'Vin-Gorman <>
Date: Mon, 21 Aug 2017 15:36:02 +0000
Message-ID: <>

"A DBA is only as good as their last backup."

Your welcome!

On Mon, Aug 21, 2017 at 8:06 AM Chris Stephens <> 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 <>
> 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 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
>> --

[image: Kellyn Pot'Vin on]

Kellyn Pot'Vin-Gorman

Received on Mon Aug 21 2017 - 17:36:02 CEST

Original text of this message