RE: Flashback on Primary

From: Goulet, Richard <Richard.Goulet_at_parexel.com>
Date: Mon, 20 Oct 2008 11:44:53 -0400
Message-ID: <23C4836D8E9C5F4280A66C0C247BC16F1EB192F4@US-BOS-MX011.na.pxl.int>

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_at_gmail.com] Sent: Monday, October 20, 2008 11:23 AM
To: Goulet, Richard
Cc: gurenich_at_gmail.com; oracle-l_at_freelists.org 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_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:44:53 CDT