Re: FLASH Recovery Area, RMAN and FLASHBACK DATABAE

On Apr 22, 11:58 am, dbaplusp..._at_hotmail.com wrote:
> I am using Oracle 10.1..0.4 (but could use Oracle 10.2 - latest
> version) in future ) on
> Windows 2000 Server. I am currently not using flashback database (have
> not set flash_recover_area). I am doing backup of database using RMAN/
> Nebackup on tape.
>
> I want to use flashback database, so need to set flash recovery area.
> However, I do
> not want to put any of RMAN backups in Flash recovery area. I want to
> continue to use my RMAN backup scripts, which directly write to tape.
>
> a. Can I Use flash_recovery_area only for storing flash back logs and
> not for RMAN backup. If yes, how?

The answer to this is in the fine OracleŽ Database Backup and Recovery Basics
10g Release 2 (10.2) manual, sections 5.3.2 and 5.3.5.

> b. Do I need to backup flash recovery area at all? I will use
> flashback retention target to limit flashback logs.

The answer to this is in the fine OracleŽ Database Backup and Recovery Basics
10g Release 2 (10.2) manual, section 5.3.5.

> c. If I need to backup flash recovery area, how will I backup. Can I
> use my OS level backup (not RMAN) to backup the folder where
> flash_recovery_area is.

RTFM, dangit!

> d. If I loss some data in flash recovery area, will my database
> continue to work fine except I cannot flashback database?

"If the flash recovery area is full, then an archived redo log may be automatically deleted by the flash recovery area to make space for other files." But if you had read the Basics manual, you'd know that.

>
> Really appreciate your response, I did read many articles on metalink
> on flashback database and flash recovery area but did not find answers
> to my question.

Do you really wonder why you get such abuse here? All of the above was found by putting:
flashback log
in the search area of tahiti.oracle.com, then clicking on "Rules for Retention and Deletion of Flashback Logs"

What may not be obvious from the manuals is that flashback database assumes you have a lot of disk compared to your transaction rate, because block changes accumulate rapidly. If you are backing to tape, that implies you have disk limitations.

jg

--
@home.com is bogus.
"The first thing I felt on Earth was the smell." - Mikhail Tyurin