You may have seen my two blog posts about Oracle supplied objects and Oracle supplied user schema and roles a few days ago, One person commented asking about what to do with these. And I agree: It looks a bit harsh to deal with two external files to query Oracle supplied stuff. But actually (as Patrick Hurley commented as well) there is a much easier way since Oracle Database 12c to deal with objects created and supplied by Oracle: the
ORACLE_MAINTAINED attribute can be pretty helpful.
ORACLE_MAINTAINED attribute can be pretty helpful
In Oracle Database 184.108.40.206 we added a column to several dictionary views:
ORACLE_MAINTAINED. And of course others have blogged about it already a while ago:
These tables have this helpful
ORACLE_MAINTAINED column attribute in common. We mark objects and schemas and roles and users maintained by Oracle with it. You find a full list of dictionary views containing the column below:
CDB_OBJECTS_AE (for EBR)
DBA_OBJECTS_AE (for EBR)
ALL_OBJECTS_AE (for EBR)
USER_OBJECTS_AE (for EBR)
At the moment we use this
ORACLE_MAINTAINED column in a transportable tablespace project. With
ORACLE_MAINTAINED we determine whether we want to gather the object definition with DBMS_METADATA.GET_DDL or not. If yes, we generate the creation scripts.
Things to be aware of
Please be aware that for instance a Data Pump export may not export certain objects – those who are marked as
- MOS Note:2114233.1 – Why Can an Object Not Be Exported? Expdp of SYSTEM User’s Table Returns ORA-39166 or ORA-31655
In addition Data Pump ignores objects in
KU_NOEXP_VIEW which is a UNION of
Be aware (I received this question just a week ago) that APEX is classified as ORACLE_MAINTAINED as well. In case you’ll do an expdp/impdp migration you’ll have to migrate your APEX applications with the APEX interface.
This behaviour is great and all for the regular use case where you want to protect people from harming themselves. But in the case that you know what you are doing this is severly limiting your options … there should be a least a switch to choose otherwise.
not sure what you concern is here.
Actually we are using the attribute as well, e.g. during the preupgrade.jar checks.
hi Mike i got a db with apex users set ORACLE_MAINTAINED = ‘N’, and i want to change it to ‘Y’.
Is it possible to change the value of ORACLE_MAINTAINED for apex users? I have not found documentation about it for days.
why do you want to change the APEX user to ORACLE_MAINTAINED?
You should never manipulate the dictionary by yourself.
Can you tell me a bit more about your motivation please?
Hi Mike, I haven’t changed it. I am given a database in this state, with the apex users with the column value oracle_maintained = ‘N’.
The db is migrated from 11g to 18.c.
All the installations we have of Apex 19.2 on db 18.3, are installed with that column in ‘Y’ for these users. Default.
Looking for a reason why objects in the apex schemas are invalidated, I find that these users have been manipulated.
As a DBA, making apex have oracle_maintained = ‘Y’ as Oracle does by default, resolves no one to manipulate these users again.
I did not change them, someone did.
I try to reassure it by assigning ‘Y’.
Perhaps the only alternative is to remove apex and reinstall to get it right.
Is there another way to set the default value back to those users?
thanks for your answer
I guess the only supported way – as you proposed – would be to remove APEX, and reinstall it afterwards again.
Make sure you export applications and images if there are any inside as they’d be lost when you remove APEX.
We did that, seeking to normalize and protect the environment. Thanks Mike for your response and your publications that contribute so much to us. Greetings!
in my company someone has wrongly created “normal users” as Oracle-managed users using
alter session set “_ORACLE_SCRIPT”=true;
Do you know I change this attribute for those users? (I want ORACLE_MAINTAINED = N instead of Y)
please check with Support on this.
This can lead to serious issues with the next upgrade. And I personally don’t know exactly which dictionary tables you need to update to revert this.