Re: FLASHBACK ANY TABLE

From: MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
Date: Wed, 18 Mar 2015 20:37:24 -0400
Message-ID: <CAAaXtLD9QWGbHg2ieyjvaP0faAjdb1U4HE1=A1nLY5GrD7ZFPQ_at_mail.gmail.com>



I have a horrible vision of some sort of "batch" job, designed and coded to perform work of some sort with incremental COMMITs, and relying -- by design -- on the ability to FLASHBACK to the original state of the data in the event that the job goes awry.

On Wed, Mar 18, 2015 at 8:27 PM, Mark Burgess < mark_at_burgess-consulting.com.au> wrote:

> Kumar,
>
> I can’t see any reason why you would want to give flashback table to the
> APPS schema - the potential for damage on the core eBS tables is too high.
> A flashback table on an eBS table would likely introduce major data
> integrity issues let alone support issues.
>
> Perhaps flashback query is something that the developers are looking for?
>
> Regards,
>
> Mark
>
> > On 18 Mar 2015, at 10:50 pm, Kumar Madduri <ksmadduri_at_gmail.com> wrote:
> >
> > Hello:
> > Our developers have requested flashback any table to be given to apps
> (in an ebusiness environment). They would not have the apps password in
> production. I think they are using it to build some feature in a custom app.
> > Regardless of their motivation, I think this is a security risk because
> why would a developer want this privilege in a production environment.
> >
> > I cant think like a hacker but it does not sound right to me.
> > Want to confirm with the list if I am missing something ?
> >
> > Thank you
> > Kumar
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Mar 19 2015 - 01:37:24 CET

Original text of this message