Re: Flashback database versus RMAN

There are some interesting twists on flashback in 11g that makes it even more usable. Flashback transaction, in particular, is an interesting feature. Now, one can roll back a given *committed* transaction AND (optionally) and dependent transactions. I will say that at this time Flashback Transaction *can* be a bit slow to implement due to it's dependency with Log Miner, but in the testing I've done it works quite well. There is also a nice interface into OEM that makes it's use quite easy.

That being said, it makes the flashback features of Oracle more usable as a recovery operation.

Cheers!!

Robert  

Robert G. Freeman
Author:
Oracle Database 11g New Features (Oracle Press) Portable DBA: Oracle (Oracle Press)
Oracle Database 10g New Features (Oracle Press) Oracle9i RMAN Backup and Recovery (Oracle Press) Oracle9i New Feature
Blog: http://robertgfreeman.blogspot.com (Oracle Press)

• Original Message ---- From: Jeremiah Wilton <jeremiah_at_ora-600.net> To: kevin.lidh_at_gmail.com; niall.litchfield_at_gmail.com Cc: moabrivers_at_gmail.com; Oracle L <oracle-l_at_freelists.org> Sent: Thursday, February 21, 2008 11:13:47 AM Subject: RE: Flashback database versus RMAN

Kevin
Lidh
wrote:

>

...recently
we
had
a
failover
situation
with
one
of
our
DG
primary
>

databases.
We
were
able
to
flashback
the
original
primary
to
the
SCN
>

where
the
failover
occurred
and
start
it
up
as
the
standby...
Then
>

we
switched
back
seamlessly.
It
was
very
handy.

I
think
this
just
points
out
one
of
the
reasons
database
flashback
was
a
source
of
concern
for
the
original
poster.
Although
you
were
able
to
flash
back
the
former
primary
back
to
the
failover
SCN,
that
must
have
meant
throwing
out
all
changes
that
had
been
made
on
the
original
primary
subsequent
to
that
SCN.
Perhaps
the
number
of
such
changes
was
very
low
for
you.
In
failover
situations,
the
primary
may
not
be
taking
changes
anyway,
but
a
lot
depends
on
how
contemporary
the
logs
on
the
standby
are.
For
businesses
with
continuous
operations,
there
are
few
situations
in
which
any
such
data
loss
would
be
acceptable.

Database
flashback
flashes
the
whole
database
back,
negating
all
changes
made
subsequent
to
the
SCN
to
which
you
revert.
Much
literature
touts
flashback
as
a
good
way
to
back
out
logical
corruption,
such
as
application
and
user-initiated
data
loss.
However,
because
of
the
necessity
of
data
loss
when
using
DB
flashback,
I
question
how
realistic
it
is
for
the
vast
majority
of
deployments.

Most
people
responding
to
this
thread
have
stated
they
use
DB
flashback
for
test
labs
and
benchmarking,
to
allow
repeatable
activities
on
a
single
database
from
a
known
starting
point.
I
also
use
it
in
a
similar
manner
alongside
DB
replay,
so
that
when
I
am
testing
a
particular
change
such
as
an
initialization
parameter,
I
can
test
with
identical
workload
iteratively
with
a
variety
of
settings,
from
the
starting
point
of
that
workload.

Regards,

Jeremiah
Wilton
ORA-600
Consulting
http://www.ora-600.net

--
http://www.freelists.org/webpage/oracle-l





--
http://www.freelists.org/webpage/oracle-l