Hmm. If that pans out then I wonder what the tradeoff point elapsed time
wise is to import novalidate, no indexes, ctas (possibly in the best
possible physical order to match the most utilized query index or extended
stat column pair if that is in your future, or some such as may befit your
precise situation), do the rename pairs, and then index and validate.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Jonathan Lewis
Sent: Tuesday, May 24, 2016 4:17 AM
To: oracle-l-freelists
Subject: RE: Enable novalidate contains after import?
Another thought -
From 10g Oracle started doing some very strange restarts while doing a big
update by tablescan.
I haven't got any tests to suggest that this could also happen if you did a
large tablescan query that produced lots of delayed block cleanout - which
might be happening after a massive import. Perhaps your 10 tablescans are
actually the same tablescan restarting.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
@jloracle
_____
From: Norman Dunbar [oracle@xxxxxxxxxxxxxxx]
Sent: 24 May 2016 08:18
To: Jonathan Lewis; oracle-l-freelists
Subject: RE: Enable novalidate contains after import?
Morning Jonathan,
The not null constraints are all part of the column definition rather than
added check constraints.
There are definitely only 8 of them, including the pk column. There are a
couple of unique indexes which have been created by the data import, but no
unique constraints.
Interesting.
Cheers,
Norm.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
