Is it true that the archives can be so far away that they don't exist in
the v$archived_log table and therefore... the control_file, or oracle
does not know the starting archive?
-----Original Message-----
From: Kerber Andrew
[mailto:oracledba-ezmlmshield-x19678752.[Email address protected]
Sent: Tuesday, March 29, 2005 11:37 AM
To: LazyDBA Discussion
Subject: RE: Re[4]: JUST CURIOUS WHAT ANSWERS I WILL GET ...
We export key schemas each night, the export files are named for days of
the week so we always have 1 week of exports available.
Archive logs are kept for years, though we would have to bring them from
our off site storage to recover more than one month past. We keep an
online backup for 1 day (refreshed each day) that is also used for
reporting. The online backup is read only.
-----Original Message-----
From: jsf
[mailto:oracledba-ezmlmshield-x34414352.[Email address protected]
Sent: Tuesday, March 29, 2005 10:03
To: LazyDBA Discussion
Subject: RE: Re[4]: JUST CURIOUS WHAT ANSWERS I WILL GET ...
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
>
>
--------
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