Hi,
This discussion is being very profitable for me, since I'm currently
developing a backup and recovery strategy...
I have a 1,8G production database and I intend to perform three kinds of
backup, daily:
- One full, online backup
- Archived log backups
- Export all the tables in the databse
Recovery should not take more than 4 hours... What do you think about this
strategy?
Another question is about the retention policy... Is there any guidelines
for how long should we keep each kind of backup? Could you guys give me
some advice about it, plz?
Thanks in advance,
JULIANO FREITAS
> If you are on OR able to go to rdbms 10g you could use the flash feature
> to provide some form of protection from user mistakes. The only problem
> I've seen with it is it takes a disk farm to be able to maintain any
> volume of data on a large, rapidly updated system... This feature must
> have been developed with a disk vendor partnership in mind.... 8=)
>
> M
>
>>>> "Kerber Andrew "
> <oracledba-ezmlmshield-x80387004.[Email address protected] 03/29/05 9:46
> AM >>>
> Yes, it would be great to have a standby database, just sitting there.
> Unfortunately, our budget doesnt allow for it. Nor can we wait a day
> until we apply transactions. It would also be nice to be able to keep
> data from being changed once it is entered in the system. However, my
> users get testy about not being able to change their own data. We need
> the exports probably once every three months, or even less often.
> However, when we do need them, there is no real substitute.
>
> When the time came to make the tradeoff between accessibility and data
> protection, we obviously went more to the accessibility side than you
> did.
>
> -----Original Message-----
> From: Paul Murgatroyd
> [mailto:oracledba-ezmlmshield-x35129396.[Email address protected]
> Sent: Tuesday, March 29, 2005 08:22
> To: LazyDBA Discussion
> Subject: Re[4]: JUST CURIOUS WHAT ANSWERS I WILL GET ...
>
>
> If your main use for recovery is because data is being changed or
> deleted accidently, I would say that you have more serious issues than a
> backup strategy :-)
>
> Your application should really not be allowing people to do anything
> "accidently". Backups should primarly be for recovery from media failure
> or site failure. Protecting the system from your users is a secondary
> function (in my view), and I would be looking to find out why this is
> your most common reason for needing backups.
>
> Sounds like a better solution for your current situation would be to
> run a standby database with a 1 day delay on applying transactions.
>
> Regards,
>
> Paul
>
> *********** ORIGINAL MESSAGE ***********
>
> On 29/03/2005 at 8:00 AM Kerber Andrew wrote:
>
> We use a combination of both hot backups and exports. We are not in a
> RAC
> environment. To restore data from backup typically you take the users
> off.
> We dont like to do this since we have a large number of users using
> many
> different applications. Our most common recovery need is restoring
> data
> that has been changed or deleted accidently. We can use daily exports
> to
> selectively reload tables from the previous day while still
> maintaining
> maximum availability.
>
>
>
>
> --------
> website: http://www.LazyDBA.com
> Please don't reply to RTFM questions
> Oracle documentation is here: http://tahiti.oracle.com
> To unsubscribe: see http://www.lazydba.com/unsubscribe.html
> To subscribe: see http://www.lazydba.com
> By using this list you agree to these
> terms:http://www.lazydba.com/legal.html
>
>
>
> --------
> website: http://www.LazyDBA.com
> Please don't reply to RTFM questions
> Oracle documentation is here: http://tahiti.oracle.com
> To unsubscribe: see http://www.lazydba.com/unsubscribe.html
> To subscribe: see http://www.lazydba.com
> By using this list you agree to these
> terms:http://www.lazydba.com/legal.html
>
>
>
> --------
> website: http://www.LazyDBA.com
> Please don't reply to RTFM questions
> Oracle documentation is here: http://tahiti.oracle.com
> To unsubscribe: see http://www.lazydba.com/unsubscribe.html
> To subscribe: see http://www.lazydba.com
> By using this list you agree to these
> terms:http://www.lazydba.com/legal.html
>
>
Oracle LazyDBA home page