Re: Flashback on Primary

From: Andrew Kerber <andrew.kerber_at_gmail.com>
Date: Mon, 20 Oct 2008 10:22:48 -0500
Message-ID: <ad3aa4c90810200822t7977418bx253d2a390ce99c79@mail.gmail.com>


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_at_parexel.com
> 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_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Maria Gurenich
> *Sent:* Monday, October 20, 2008 10:30 AM
> *To:* oracle-l_at_freelists.org
> *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.'

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Oct 20 2008 - 10:22:48 CDT

Original text of this message