JSchneider wrote:
> DA Morgan wrote:
>
>>Be sure you give a lot of thought to Flashback area too.
>
>
>
> hrmmmm.... hey that brings up an interesting question... just
> curious, but what are your general impressions of flashback area?
>
> i tried it out and decided *not* to use it on our production 10g DB.
>
> 1. it doesn't really give you any *new* functionality... well, i mean
> all it enables is "FLASHBACK DATABASE" which is just a faster easier
> way to do PITR. but you can still just restore, recover, roll forward
> to that same PIT the way you've always done it. admittedly, flashback
> database is a *LOT* easier but i can't imagine wanting to flashback the
> ENTIRE database unless it was a rather catastrophic problem...
> especially considering that i have multiple applications each in their
> own schema on that DB and flashing the whole thing back would roll back
> changes in all the apps. anyway... i can still see where it would be
> nice BUT:
>
> 2. it seemed to be generating a fairly decent amount of IO. seems like
> it was generating about as many flashback logs as there were archive
> logs.
>
>
> and my main reason...
>
> 3. i'm using OCFS (v1) on linux... OCFSv1 isn't the most robust
> implementation for handling filesystem metadata. (v2 will supposedly
> be much better but i haven't had a chance to play with it yet.) in
> fact seems like i remember the guys on the OCFS mailing list
> recommending having archive log destinations on different volumes for
> each node to reduce contention for DIRNODES - where the metadata is
> stored for OCFS files. we do this at our site on our production 9i and
> 10g RAC db's.
>
> to enable flashback you have to use OMF which means that all the
> flashback logs have to go in the same location (for both nodes). if
> there is heavy activity then there would be a lot of flashback log
> generation and deletion by both instances in the same OCFS directory.
> odds are it would work fine but i'm not very comfortable with it.
>
> SO... my conclusion was that if i could use ASM them i'd put the
> database in flashback mode. but with OCFS v1 i wasn't comfortable
> going there yet. And of course even without the DB in flashback mode
> you can still do flashback query, flashback table, flashback drop...
> you just can't flashback the whole DB. (But you can still do old
> fashioned PITR - and it's simple with RMAN.)
>
> so i'm curious, has anyone else had any real experience or done any
> heavy testing with the database in flashback mode? do my observations
> seem in line? any other thoughts?
>
>
> jeremy
The flashback area is more than just PITR. It is also recovery to the
SCN. But more importantly it is a solution to finding backup tapes
that, hopefully, were promptly shipped off-site for their protection.
My recommendation would be to dump OCFS, there is talk at Oracle about
deprecating it as it was the solution for a problem that no longer
exists. Move to RAW and ASM and any issues go away.
Our current best practice for RAC is to always have a flashback area.
--
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)
Received on Tue Jun 14 2005 - 11:16:40 CDT
