Re: Impact on changing an enabled validated constraint to enable novalidate ?

Hello,

The gain is not on the main database.

We make an export data=no and retrieve the script to refresh other environments every day. (import data + rebuild index & contraint later)

Having the constraint validated in the production environment, we retrieve a script with "VALIDATE" and so our "refresh" validates data coming from production that have been already validated. (and it's pretty long to validate again)

I hope i've been understandable.

Thanks

JM

On Apr 2, 5:23 pm, "hpuxrac" <johnbhur..._at_sbcglobal.net> wrote:
> On Apr 2, 11:14 am, zejea..._at_gmail.com wrote:
>
>
>
> > Hello,
>
> > We would like to change constraints that are enabled and validated to
> > "ENABLE NOVALIDATE" state.
>
> > I think that there is no problem doing that : any new line or update
> > will be checked thanks to the "ENABLE" state.
> > I feel that once validated there is no point in keeping the constraint
> > in "VALIDATE" state. "ENABLE NOVALIDATE" is sufficient.
> > VALIDATE seems only useful when we create a constraint on existing
> > data.
>
> > Am i right ?
> > Is there a (hidden) danger changing the constraint to NOVALIDATE ?
>
> > Thanks in advance
>
> > Jean-Michel
>
> Why exactly do you want to make this change?
>
> Is there some kind of benefit to the business? Have you compared the
> amount of overhead for a given workload of some importance?
>
> Typically enable novalidate is only useful when you need to accept
> that there are some problems with the existing data in a table but new
> data coming in will all have to be correct.
>
> If all the data is "already in there" and has been validated, there is
> no gain at all by changing it from validate to novalidate.
Received on Mon Apr 02 2007 - 10:45:05 CDT