Re: "If you have already found something inside the database that uses such
functionality, the only way out is, as you have stated, a *full* export /
import."
Ah yes, but what if your database is 2TB, 10TB, XTB etc. in size? Datapump
full export/import isn't feasible if the sizing is generally beyond 2TB in
my experience. What I have done in this scenario is leverage transportable
tablespaces metadata and unplug the data tablespaces from the source
database, and plug them into a new "fresh" database on the very same
environment. I have done this on a 4TB 11204 RAC environment in just a few
minutes downtime. It therefore leaves the accidental feature usage behind
in the dictionary metadata of the old source, and you get a clean new
database...
You also are not spending any time copying data across the network or to a
new environment (It simply stats in situ). Its a neat option if you have a
relatively large database and if downtime is an issue.
Regards,
Ruan
On Fri, Nov 17, 2017 at 5:51 AM, Stefan Knecht <knecht.stefan@xxxxxxxxx>
wrote:
The four options you are concerned with, can't be disabled. It would be
simple for Oracle to implement a mechanisms to do so, but I suppose all the
accidental violations that netted them money, outweigh the benefit of doing
so.
Particularly advanced security or advanced compression are tricky because
they can be used outside of the database as well (think Data Guard Redo
Compression or RMAN backup compression, for example).
What I have seen some people do is run a job in the database that scans
for objects that would violate their allowed functionality, and produce an
alert when something was found. My framework, zztat, can also run checks
like this.
If you have already found something inside the database that uses such
functionality, the only way out is, as you have stated, a full export /
import.
Stefan
--
//
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at zztat.net | Support our Indiegogo campaign at igg.me/at/zztat
| @zztat_oracle
