RE: Flashback on Primary
- From: "Goulet, Richard" <Richard.Goulet@xxxxxxxxxxx>
- To: "Andrew Kerber" <andrew.kerber@xxxxxxxxx>
- Date: Mon, 20 Oct 2008 11:44:53 -0400
Andrew,
True, SOX is only applicable to US companies & financially
reportable information (public of non-public, IRS likes to ask the same
questions and they really don't care about SOX). As well there is HIPPA
in the US for medical information, and other similar rule sets that get
applied by more people than I care to think about lately. As well some
foreign countries are creating their own versions of SOX & HIPPA as well
as others to deter identity theft and/or falsification of records
(remember that physicist who made some claim about Nuclear fusion or
some such a couple of years ago, all based on falsified records). I
won't say that it's a bad idea to enable flashback database on a
production db, but I believe it does leave a number of hard to answer
questions laying around best avoided by NOT enabling the feature.
Dick Goulet
Senior Oracle DBA
PAREXEL International
978.313.3426
information transmitted in this communication is intended only for the
person or entity to which it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this information
by persons or entities other than the intended recipient is prohibited.
If you received this in error, please destroy any copies, contact the
sender and delete the material from any computer.
________________________________
From: Andrew Kerber [mailto:andrew.kerber@xxxxxxxxx]
Sent: Monday, October 20, 2008 11:23 AM
To: Goulet, Richard
Cc: gurenich@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Flashback on Primary
Sarbanes-Oxley is not applicable to all companies. It applies only to
publicly held companies subject to US law.. And it would apply to only
those databases where accounting type information is stored, not purely
technical information. In addition, Sarbanes-Oxley only requires that
you do the best you can using reasonable means, it does not require that
you keep a logically corrupt database. In an case, best practices would
require a full backup before a flashback so that you can restore the
database to the state before the flashback.
On Mon, Oct 20, 2008 at 9:51 AM, Goulet, Richard
<Richard.Goulet@xxxxxxxxxxx> wrote:
I have to question the need/desire/advisability of allowing a
database flashback in a production database. One very simple reason is
the needs of Sarbanes-Oxley and other similar mandated things that
require you to prove that no one is illicitly changing data to suit
their needs, aka "cooking the books". How do you explain to an auditor
that say a weeks worth of data entries "never happen". Think of it, if
you flashed back all of last weeks transactions because something
horrible was done that the officers of the company don't want anyone
knowing about how do you explain the lack of work for last week??
Dick Goulet
Senior Oracle DBA
PAREXEL International
978.313.3426
information transmitted in this communication is intended only
for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please destroy
any copies, contact the sender and delete the material from any
computer.
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Maria Gurenich
Sent: Monday, October 20, 2008 10:30 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: Flashback on Primary
Hi people!
Oracle 10.2.0.3 RHEL4 + physical Standby
I am going to enable flashback feature on the production
database and I have a couple of questions regarding this.
1) I've heard a lot of talks about the difficulty of
implementing FLASHBACK DATABASE command on primary if standby is not
configured with flashback. Thinking about it, I am realizing indeed that
I don't see an easy way of doing that. Let's say, I had to flashback my
primary database. What will happen with the standby? I will need to open
it in RO, find the data, and then make sure that MRP have synced with
the primary. And I was told that this does not work with MAXIMUM
PROTECTION. So I guess, my question is as follows: could you please
advise me where can I read (or describe it in a few words) how the
process of flashing back standby if flashback feature is not enabled on
it will look like. And also, how it will look like, if I enable
flashback feature on the standby (I think I would better just recreate
the standby after the enabling flashback on primary).
2) If i am not enabling flashback on standby can I have
different ARCHIVELOG_DEST on primary and stanby? Will my ARCHIVELOGS
(not flashback log) still be shipped to standby?
3) I know that some folks do it in the opposite way, i.e.
enabling flashback on standby only instead of primary. That is not my
case. I do need flashback on primary only and I am trying to avoid
enabling it on standby. (But I will do it if you guys tell me so.)
4) Please let me know about any pitfalls that I've missed.
Thanks in advance.
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
Other related posts:
